谷歌云海外版 GCP谷歌云CPU跑分数据

话说上个月，我为了给一个实时风控服务选云服务器，差点把GCP控制台翻出包浆来——不是因为功能少，而是因为太多选项像极了我大学选修课表：看着都重要，点开全懵圈。尤其是CPU型号那一栏，e2、n2、n2d、c2、c3……字母加数字组合之密集，堪比密码学入门考卷。于是干脆撸起袖子，自费租了12台不同配置的GCP实例，连续三天蹲在terminal里跑分、记日志、骂谷歌文档（它真没写清楚c3和c2到底差在哪，只说‘新一代’，仿佛在说‘你懂的’）。

先说结论：GCP不是跑分玩具厂，但它的CPU梯队确实有迹可循。不是越贵越猛，也不是越新越香——比如c3虽然标榜‘面向计算密集型’，但单核性能在某些场景甚至被n2d反杀；而最便宜的e2系列，跑个Node.js后台+轻量Redis，居然比同价位AWS t4g还稳一丢丢（别声张，AWS听见要发律师函）。

测试环境统一用Ubuntu 22.04 LTS，内核5.15，所有实例启用默认优化（没手动调sched、nohz_full那些骚操作）。基准工具三件套：Geekbench 6（看单核/多核绝对值）、sysbench cpu --threads=1/8/16（压真实线程调度）、stress-ng --cpu 0 --cpu-method matrixprod（暴力榨干浮点和内存带宽）。所有数据跑3轮取中位数，误差＞5%的直接重跑——毕竟我们不是在测玄学，是在选生产机器。

谷歌云海外版 e2系列：GCP的‘经济适用男’
从e2-micro到e2-highcpu-32，全系用Intel Skylake或AMD EPYC 7B12（混用不预告，GCP：这叫弹性）。e2-medium（2vCPU/4GB）跑Geekbench单核1289，多核2451；作为对比，AWS t3.medium同配置单核1252。表面看差不多？但sysbench单线程跑prime计算时，e2-medium平均延迟低3.2%，原因？GCP悄悄给e2开了Intel Speed Shift，而t3还在靠OS调度硬扛。不过提醒一句：e2没有超线程，所以e2-highcpu-16的16vCPU=16物理核心，不是32逻辑核——这点文档小字写着，但藏在‘Machine type details’折叠菜单第三层，我找它时手抖点了五次返回键。

n2系列：稳扎稳打的‘公务员型选手’
n2是GCP老熟人了，全系Intel Cascade Lake，支持AVX-512（对做向量化计算的团队是隐藏彩蛋）。n2-standard-8（8vCPU/32GB）单核Geekbench 1523，多核11842。有趣的是，当sysbench开16线程压它时，性能只涨到12400左右，而非理论翻倍——说明Cascade Lake的内存控制器在高并发下开始喘气。我们还试了n2-highmem-64（64vCPU/416GB），跑stress-ng的matrixprod时，每核心FP运算吞吐比n2-standard-8低8%，原因？GCP给highmem机型配的是 slower memory bus（官方叫‘optimized for memory bandwidth’，翻译成人话：给你堆内存，但别指望它跑得快）。

n2d系列：AMD信徒的春天
n2d全系EPYC 7B12（Zen2），24核起步，最大能到224vCPU。n2d-standard-32单核1375，多核39210——多核暴涨不是因为核心多，而是Zen2的CCX架构让L3缓存共享更高效。重点来了：同样跑ffmpeg视频转码（H.264→H.265，1080p@30fps），n2d-standard-32比同vCPU的n2-standard-32快17%，因为AVX2指令集在Zen2上实现更激进。但注意！n2d不支持嵌套虚拟化，想在上面跑KVM套娃？门儿都没有。GCP官网FAQ里写‘not recommended’，实际就是‘会蓝屏’。

c2系列：‘肌肉猛男’，但得喂对饲料
c2-standard-60（60vCPU/240GB）用Intel Ice Lake，单核1822，多核89300。这是GCP首次在公开机型里塞进PCIe 4.0和DDR4-3200。但实测发现：如果你只跑Java应用，c2未必比n2香——因为Ice Lake的branch predictor在复杂JIT代码路径下反而容易误判，导致SPECjbb分数比n2低5%。但它在科学计算上封神：用OpenBLAS跑DGEMM，c2-standard-60比n2-standard-64快2.3倍。结论？c2不是通用王者，是给数值计算、AI训练前处理、基因比对这类吃满AVX-512+高频内存的场景定制的‘特供餐’。

c3系列：GCP最新王炸，但别急着all-in
c3-standard-88（88vCPU/352GB）基于Intel Sapphire Rapids，支持AMX指令集（AI加速专用）。Geekbench单核2155，多核142800——数字吓人，但实测TensorFlow CPU版推理速度只比c2快12%，因为AMX需要框架深度适配（TF 2.15才刚加experimental支持）。真正起飞的是FFmpeg AV1编码：c3-standard-88用svt-av1跑4K 60fps，比c2快3.1倍。所以，c3现在适合两类人：1）正在用AV1/VP9压片的视频平台；2）自己编译LLM推理引擎、敢啃Intel oneAPI文档的硬核玩家。其余人？建议观望，等PyTorch 2.4正式支持AMX再说。

最后说点掏心窝的：
第一，GCP的‘按秒计费’在跑分时是福也是坑——你租1小时c3，结果跑完stress-ng发现散热降频了，想重跑？再付60秒钱。第二，别迷信‘最新代’，我们用n2d-standard-16跑了半年生产任务，故障率0.003%，而某次试用c3-preview机型，凌晨3点莫名重启两次（support ticket回复：‘已知热节流行为，预计Q3修复’）。第三，GCP的CPU性能波动比AWS小，但网络延迟抖动略大——这对风控类服务很致命，我们最终选了n2-highcpu-32+Premium Tier网络，宁可多花18%费用，也要把P99延迟死死压在8ms内。

所以，下次你在GCP控制台面对那串字母数字组合时，记住：e2适合省钱起步，n2适合求稳落地，n2d适合算力饥渴，c2适合硬核计算，c3适合押注未来。而真正的答案，从来不在文档里，而在你亲手敲下的第一个sysbench命令之后。

（附：所有原始数据已整理成CSV，包含每台实例的详细配置、三次跑分记录、温度监控截图。需要的朋友可以留言‘GCP跑分表’，我发你——当然，不是Google Drive链接，是纯文本，防失效。）