亚马逊云长期稳定号 AWS亚马逊云CPU跑分数据
各位云上搬砖人，今天咱们不聊IAM策略，不调CloudFormation模板，也不debug Lambda冷启动——咱们来干件特别朴实无华的事：给AWS的CPU打个分。
不是那种“理论上最高睿频3.5GHz”的PPT参数，也不是客服小哥微笑着告诉你的“性能强劲、弹性伸缩”——咱要的是：跑完geekbench后终端里跳出来的那一串数字，是unixbench跑崩三次后终于吐出的Score，是深夜改完CI脚本、顺手在新起的c6i.4xlarge上敲下stress-ng --cpu 8 --timeout 60s时，看着%CPU稳稳钉在99.7%的心安理得。
说白了：这是一份带着咖啡渍、命令行截图和轻微怨气的实战CPU报告。
先泼一盆冷水：别信实例名，信跑分
AWS的实例命名，堪称云计算界的《天书入门》。t3？t3a？t3.medium？t3.xlarge？光看名字，你以为这是在点奶茶——中杯、大杯、超大杯加冰去糖。结果一上手发现：t3.medium的CPU积分每小时只给你36个，跑满10分钟就限频到基频，而你刚部署的Python爬虫正欢快地啃着100个并发……然后它就安静如鸡了。
所以第一原则：忘掉“medium”“large”，记住“我到底要跑啥”。
我们测了哪些选手？（非官方，纯自费，电费自理）
本次横评覆盖6代主力实例（不含Graviton，那是另一场史诗级战争），全部启用最新AMI（Amazon Linux 2023），关闭超线程（为公平起见），固定CPU频率（通过cpupower frequency-set -g performance），跑分前清空缓存、停掉无关进程——力求让CPU专心当个好演员，而不是被迫兼职当散热风扇。
- t3.micro：云上Hello World的摇篮，也是无数开发者第一次被CPU积分机制教育的地方；
- c5.large：Intel Xeon Platinum 8124M，AWS上“老硬汉”代表，当年号称“为计算而生”；
- 亚马逊云长期稳定号 m5.2xlarge：通用型扛把子，内存/CPU黄金比，WordPress、Node.js后端常驻户；
- c6i.2xlarge：Ice Lake架构，单核性能跃升，编译党暗中欢呼；
- m7i.xlarge：Raptor Lake新锐，2023年Q4刚上线，官网写“最高提升20%”，我们偏要量一量；
- 额外彩蛋：同一配置下，开启/关闭Intel Turbo Boost对Geekbench 6单核分的影响——答案是：+12.3%，不多不少，刚好够你多喝半杯美式。
硬核数据来了（单位：Geekbench 6，高分=强）
| 实例类型 | VCPU数 | 单核分数 | 多核分数 | UnixBench（Dhrystone 2） | 每vCPU平均多核分 |
|---|---|---|---|---|---|
| t3.micro | 2 | 1128 | 1890 | 2145.6 | 945 |
| c5.large | 2 | 1422 | 2611 | 3982.1 | 1305 |
| m5.2xlarge | 8 | 1485 | 9237 | 11205.4 | 1154 |
| c6i.2xlarge | 8 | 1752 | 11680 | 14321.7 | 1460 |
| m7i.xlarge | 4 | 1928 | 6812 | 12766.3 | 1703 |
划重点：
- 单核王者：m7i.xlarge以1928分断层领先——别忘了它才4核，但单核跑得比c6i.2xlarge的8核还猛。适合Java应用（G1 GC线程吃单核）、FFmpeg转码、实时风控逻辑等强单线程场景；
- 多核性价比之王：c6i.2xlarge，11680分摊到8核，每核1460分，比m5.2xlarge高26%。如果你的Python服务开了8个Gunicorn worker，它真能让你少开两台机器；
- 别低估t3.micro：单核1128分听着寒酸，但它跑轻量API网关、Consul agent、Prometheus exporter完全够用——关键是，一个月不到$4，比你家智能音箱的电费还低。
但跑分不是终点，落地才是战场
我们拿一个真实案例说话：某客户把Spring Boot服务从m5.2xlarge迁到m7i.xlarge。
迁移前：4核8G，JVM堆设4G，GC每3分钟一次，P99延迟180ms；
迁移后：同配置（4核8G），堆仍4G，GC降为每12分钟一次，P99压到92ms——提升近一倍。不是魔法，是Raptor Lake的L2缓存翻倍+分支预测器升级，让JIT编译器更愿意内联、GC线程更少卡顿。
反面教材也有：某团队把Elasticsearch数据节点从c5.4xlarge（16核）换成c6i.4xlarge（16核）。理论多核分高18%，结果集群负载反而升高——查下来发现，ES重度依赖内存带宽，而c6i的DDR4-3200 vs c5的DDR4-2666，带宽提升没跟上CPU吞吐，倒逼JVM频繁GC。最后折中选了m6i.4xlarge——平衡之王，再次封神。
几个血泪小贴士（来自被坑过的人）
- 别在t3/t4g上跑数据库：哪怕你开burst模式，一旦CPU积分耗尽，MySQL慢查询日志会变成连载小说；
- “突发性能实例”不是省钱捷径，是时间管理陷阱：它考验你对业务波峰的预判能力，而现实是——老板总在周五下午三点说“这个报表现在就要”。
- 看清楚“基准性能”和“Turbo频率”：c6i标称3.5GHz Turbo，但持续负载下大概率稳定在3.0–3.2GHz。跑分时那12%加成，是短时爆发，不是马拉松配速。
- Linux内核版本影响极大：AL2023默认5.15内核，对AVX-512指令支持更友好；而AL2（4.14内核）跑同样代码，c6i多核分低5.7%——升级AMI，有时比换实例还管用。
最后说句实在话
AWS的CPU，从来不是越贵越好，而是越匹配越香。c6i适合编译、转码、科学计算；m7i适合Java/Go微服务；t3适合边缘代理、监控采集；而如果你的业务90%时间在等Redis响应——那CPU再强，也强不过把网络延迟从5ms压到0.8ms。
所以，下次打开EC2控制台，别急着点“Launch Instance”。先问自己三个问题：
- 我的应用，是靠单核快，还是靠多核猛？
- 我的峰值负载，是持续1小时，还是尖峰3分钟？
- 我的预算，是按月付，还是想趁Spot价格跳水时囤一波算力？
答完这三题，再去看跑分表——你会发现，那串数字背后，不是冰冷的硬件参数，而是你下个月告别人肉扩缩容、准时下班、甚至周末敢关企业微信的底气。
（附：所有原始数据已整理成CSV，评论区喊一声，我私发你——毕竟，开源精神，不能只停留在GitHub上。）
