内存带宽是衡量服务器性能的重要维度之一，尤其在高性能计算、大数据处理、内存数据库等场景下，内存吞吐能力往往直接决定了应用的整体表现。AWS EC2提供了多种实例类型，不同系列在CPU核数、内存容量与内存通道设计上差异明显。本文将使用业界标准的Stream基准测试工具，对几款常见EC2实例进行内存带宽实测，并分析结果背后的架构原因，帮助你在选型时做出更合理的判断。
Stream测试工具简介与编译方法
Stream是由John McCalpin开发的经典内存带宽基准测试程序，至今仍是学术界和工业界评估内存子系统吞吐能力的事实标准。它包含四个核心测试子项：Copy测量最简单的读写带宽，Scale在读取的同时执行乘法运算，Add涉及三个数组的读写操作，Triad则是三个子项中访问模式最复杂的一个。这四个子项共同刻画了内存系统在不同访问模式下的真实表现。
在Linux环境下编译Stream非常简单，以经典的C版本为例，可以直接下载源码后用gcc编译。为了获得准确的结果，建议开启编译器优化并针对具体CPU架构指定指令集：
# 下载并编译Stream
wget https://www.cs.virginia.edu/stream/FTP/Code/stream.c
gcc -O3 -fopenmp -DSTREAM_ARRAY_SIZE=80000000 \
-DNTIMES=20 -mcmodel=large stream.c -o stream
# 使用全部核心运行测试
export OMP_NUM_THREADS=$(nproc)
./stream
其中STREAM_ARRAY_SIZE决定了测试数组的规模，必须远大于CPU三级缓存容量，否则测出来的是缓存带宽而非内存带宽。一般建议数组总大小至少是L3缓存的4倍以上。NTIMES表示每个子项的执行次数，程序会取除第一次以外的最佳成绩，适当增大该值可以让结果更稳定。
需要注意的是，AWS的许多实例采用了NUMA架构，测试前建议使用lscpu查看NUMA节点分布，必要时配合numactl将进程绑定到特定节点，避免跨节点访问拉低带宽数值。
主流EC2实例实测结果对比
本次测试选取了三款常见实例：通用型的m5.2xlarge（8 vCPU）、计算优化型的c5.4xlarge（16 vCPU）以及内存优化型的r5.4xlarge（16 vCPU）。操作系统统一使用Amazon Linux 2，测试结果取多次运行的最佳值，单位为GB/s：
| 实例类型 | Copy | Scale | Add | Triad |
|---|---|---|---|---|
| m5.2xlarge | 39.8 | 39.5 | 43.2 | 43.0 |
| c5.4xlarge | 62.1 | 61.7 | 67.5 | 67.2 |
| r5.4xlarge | 92.3 | 91.8 | 99.6 | 99.1 |
从数据可以看出几个明显的规律。首先是Add和Triad的成绩普遍高于Copy和Scale，这是因为Add需要读写三个数组，理论上每迭代搬运的数据量是Copy的1.5倍，但总的访问字节数计算方式不同，因此数值看起来更高，属于正常现象。
其次，三款实例的带宽差距相当显著。r5.4xlarge的Triad成绩接近100GB/s，几乎是m5.2xlarge的2.3倍。这背后反映的是内存通道数量与CPU代际的差异：r5系列基于第一代英特尔至强可扩展处理器，配合12条内存通道，而m5.2xlarge仅有8个vCPU，对应的物理内存通道配置更少。这也说明内存带宽与vCPU数量大致呈正相关，小规格实例天然处于劣势。
另外值得注意AWS普遍采用的突发性能机制。M系列、T系列等部分实例存在积分限制，长时间高负载运行时带宽表现可能下降，而C5、R5这类企业级实例则提供持续稳定的性能输出，这一点在长时间运行的生产负载中尤其重要。
测试中的常见误区与结果解读
不少初学者测出的带宽数值明显偏低，往往是踩了以下几种坑。第一种是数组规模设置过小，导致数据完全命中CPU缓存，测出的其实是缓存带宽，数值可能虚高数倍；第二种是没有使用多线程，单线程受限于内存控制器的单队列深度，只能发挥出总带宽的一小部分；第三种是在虚拟化环境下受到了邻居实例的干扰，共享物理主机的实例会互相争抢内存控制器资源。
解读Stream结果时，还要理解理论峰值与实际可达成值的关系。以r5.4xlarge为例，其CPU支持6通道DDR4-2666，理论峰值带宽约为128GB/s，实测99GB/s已经达到了理论值的77%，这在NUMA系统和虚拟化环境下属于相当优秀的水平。一般来说，能够达到理论峰值的60%到80%就已经是健康状态。
如果希望进一步验证NUMA的影响，可以在双节点实例上分别用numactl --cpunodebind=0 --membind=0和跨节点方式运行测试，对比两者的差异。跨节点访问通常会导致带宽下降20%到40%，这也解释了为什么在部署大型应用时，合理的NUMA亲和性绑定能带来可观的性能提升。
基于内存带宽的选型建议
如果你的工作负载属于内存带宽敏感型，例如大规模矩阵运算、基因组测序、实时数据分析或Redis集群，选型时应优先考虑R系列内存优化实例，其次是C系列计算优化实例。同等预算下，选择少量大规格实例比大量小规格实例更划算，因为大规格实例独占更多内存通道，单实例带宽明显更高。
对于带宽要求极高的场景，还可以考虑基于AWS自研Graviton处理器的ARM实例或最新的M7i、R7i系列。新一代实例普遍支持DDR5内存和更多通道，带宽较上一代有30%以上的提升，同时单位vCPU的价格并没有显著上涨，性价比表现更好。
最后提醒一点，Stream测的是顺序访问带宽，代表的是内存子系统的理论上限。实际应用中的随机访问、缓存命中率、访问局部性等因素都会让有效带宽低于Stream数值。因此建议将Stream结果作为选型的参考上限，再结合自身应用的真实压测数据做最终决策，这样才能在成本与性能之间找到最佳平衡点。
AWS EC2Stream内存带宽云服务器性能测试修改时间：2026-08-31 20:08:37