# 高密机型的九年——一条被友商嘲笑的技术路线 > 基于 2026-07-09 腾讯学堂技术突破奖分享改写 · 第二篇 / 共三篇 2017 年,我们把腾讯云第一代基于 AMD EPYC Naples 的机型(内部代号 SA1)推上了线。 那是一个被全行业盯着骂的时刻。 友商们几乎是同步开始在市场上讲一个论调:"腾讯云不想做京东了,改做拼多多了"——把便宜、劣质的东西给客户用。客户听完开始怀疑:过去十几年你们年年都在讲军备竞赛,今天你们把军备竞赛都不做了,是不是不行了?是不是干脆不玩了? 那时候恰好还有各种其他技术泡沫在同时膨胀,大家更容易得出一个结论:**腾讯没有 To B 的基因,就不应该做这件事**。 九年过去了。到今天——2026 年 7 月——腾讯云的核心机型已经从当年 56 核的顶配走到了 768 核。单位成本降了 50% 以上(跟某些时间点比降得更多)。资源利用率稳定在 90% 以上,而友商大致在 60-70% 之间。CSIG 这两年利润的显著提升,我认为很大一部分来自这条 9 年前被人嘲笑的路线。 但我更想讲的是——**这条路走过来,技术只是其中很小的一部分**。 ## 一、老二和老三的战略同盟 先说清楚一件事:**高密路线不是我们独有的选择**。它更像是"老二和老三"的一次战略同盟。 2017 年的 x86 服务器市场,Intel 是绝对的老大——市占率超过 99.5%。AMD 那时候在服务器市场的份额低到可以忽略。它必须重返服务器市场,重返的策略就是——**不跟 Intel 拼单核性能,拼核数密度**。 AMD 的做法非常聪明: - 把大芯片拆成很多小芯片(**Chiplet**),每一小块叫 CCD(Core Complex Die) - 用**台积电**的工艺(那时候台积电已经在给苹果做 iPhone 芯片),拿到当时最好的封装能力 - 把主频降下来,把核数堆上去,摊薄单位算力的成本 Intel 是靠单核性能天花板收溢价的,AMD 是靠核数密度摊薄成本的。这两条路线的目标客户不一样,AMD 要的正是那些**核数越多越好、单机 CPU 利用率不需要打满**的场景——也就是云。 我们当时的选择跟 AMD 是同一个逻辑:**如果用户的需求本质是 Hosting 而不是 Computing,那我为什么要每一代都强化 Computing?我为什么要每次都跑分给客户看?我跑分跑得漂亮,客户上线之后 CPU 利用率 5%、10%——那这个跑分的意义在哪?** 有没有可能我把每一代的 Computing 单核性能持平甚至略降,但把密度和调度做上去,让用户的成本大幅下降? 这就是 SA1 那天做出的决定。这里我想强调一句:**这个选择并不是我们特别强,而是老二老三在同质化竞争里天然会思考的方向**——AMD 是老二在硬件端的自救,我们是老二在云端的自救,共同点是都不敢正面跟老大打军备竞赛。 ## 二、内核被 8 比特打崩了 这条路一走进去,才发现里面全是坑。 **第一个坑:Linux 内核根本没想过一台机器会有那么多 CPU**。 在 Naples 之前,很少有 x86 单机的核数超过 100 核。Linux 内核(以及 KVM 的核心数据结构)里,很多地方 CPU ID 只用了 8 个比特——也就是最多标识 256 个逻辑 CPU。 AMD 在几年之内就把单机做到了 512 核、768 核。**8 比特直接不够用了**。 你可以想象一下这个场景:一大票工程师本以为自己在做"性能优化"和"硬件适配",突然发现是要挖内核里几十年前的一个数据结构假设。整个虚拟化栈、整个调度器、整个热迁移子系统,全都要重新审视一遍:**哪些地方藏着"CPU 不会超过 256"的隐含假设?** **第二个坑:开机时间 20 分钟**。 一台 768 核的虚拟机,寄存器要初始化、硬件 I/O 要串行处理。默认代码路径全是"一核一核处理"的 for 循环——很多算法复杂度是 O(N) 或 O(N²)。当 N 从 32 涨到 768,这个复杂度直接把开机时间拉到了 20 分钟。 用户能接受 20 分钟吗?技术上他能。心理上他不能。**他会觉得"我用你的高密最终有很多损失,你便宜是便宜了,但体验又不一样"**。 **第三个坑:热迁移**。热迁移的所有算法几乎都是同样的问题——原来 32 核已经算高密,for 循环随便写。到了两三百核,就必须重写。 **第四个坑:故障半径**。SA1 刚推出时,腾讯内部的自研业务还习惯用 Intel 8 核到 32 核的机器。业务方一看到 SA1 的核数就摇头:"这么大的爆炸半径,一台机器出问题波及几十上百个业务,谁扛得住?"整套单机容灾密度、单机故障处理速度、单机替换机制,都要重新设计。 这些坑得靠虚拟化团队、内核团队、智能网卡团队、硬件团队一层一层解决。这九年里,我们的核心团队几乎在每一层都跟 upstream 社区、跟 AMD、跟操作系统内核维护者深度绑定过。 顺便说一句:**直到现在,阿里云都没有超过 256 核的虚拟机上线**——不是因为他们觉得不好,是因为他们解决不了这些工程问题。过去几年他们在市场上一直对客户讲"我们不提供高密,是因为我们觉得不好"。其实是他们不行。不过他们已经快突破了,很快也会出高密机型——到时候他们怎么跟客户解释自己过去几年的话术,就不是我们的问题了。 ## 三、35,000 种装箱方案 如果说内核问题是"工程能不能做",调度问题就是"要不要做"。 **Intel 时代的调度约束相对简单**:主要是 NUMA。跨 NUMA 访问内存慢一大截,所以要把用户的 CPU 和内存尽量绑在同一个 NUMA 域。一个 64 核的虚拟机在 Intel 宿主机上分配,几乎只有一种合理方式:两边各放一半。 **AMD Chiplet 时代复杂了 N 倍**: - CCD 内部的核之间通信最快 - CCD 之间要走 IO Die,跨 CCD 通信慢 - CCD 连到 IO Die 的 GMI 带宽只有 50 GB/s——如果一堆核塞在同一个 CCD 里访问内存,可能会被 GMI 带宽卡住 - 什么时候要跨 CCD 绑定拉开带宽?什么时候要在 CCD 内部亲和降延迟? 同样是 64 核虚拟机的分配问题,在 Intel 宿主机上有 1 种分配方案,**在 AMD 宿主机上有 35,000 种分配方案**。 35,000 种里哪一种最好?这就是装箱算法的核心难题。**装箱算法始终是在做妥协**——你解决了一个约束,可能就牺牲了另一个约束;你找到一个好方法,可能装箱时间又长了。 我 2012 年写这个调度框架最开始那 2,000 行代码的时候,唯一一块心里最没底的就是装箱算法。别的都是工程性工作——想办法解决一点就是多了一点;装箱算法不是这样,它永远在妥协。 后来这一块几乎是团队里学历最高、最聪明的一批人在做。有些学术化的算法(比如乐观无锁装箱)都被引入进来。 ## 四、一个客户的案例 调度做到位之后,会出现一些反直觉的现象。 今年年初,一个非常大的客户找上门来。他从来不上云——因为他觉得自己水平很高。去年他自己采购了一批 AMD EPYC 服务器,在物理机上直接跑容器(Kubernetes)。 按理论讲,物理机跑容器应该比虚拟机跑容器性能更好——少一层虚拟化嘛。 实测结果反过来了:**同样是 Kubernetes 跑同样的业务,跑在腾讯云的 CVM 上性能比他自建的物理机高 20-30%**。 原因很简单:K8s 本身还没有识别到 AMD 的物理拓扑(CCD、IO Die、GMI 那一套)。K8s 给 Pod 分核只看"核数",不知道这几个核之间的关系。而我们在给客户分配虚拟机的时候,已经在 Hypervisor 那一层帮他做好了 CCD 亲和、跨 CCD 反亲和、GMI 带宽平衡。 **他自己买了硬件,但没有能力用好硬件。我们的 CVM 在他看来是"降级产品",实际上是把 AMD 的物理拓扑打包成了他能用的形态**。这就是"高密调度"带来的差异。 如果他跑的不是单机 benchmark 而是集群任务,这个 20-30% 的差距只会更大。因为集群里的调度不匹配是会累积的。 这类反直觉的例子,是我们过去几年真正的护城河。 ## 五、教室装箱、混合装箱、业务画像 再往上一层是**混合装箱**。 一台高密机的 CPU、内存、GPU、网卡都是资源。传统的做法是:不同规格的宿主机装不同规格的虚拟机——1:2 的宿主机装 1:2 的虚拟机,1:4 装 1:4。友商到今天还是这样。结果是:1:2 卖完了、1:4 还有一堆,客户要 1:4 你没货——只能靠冗余解决,冗余越多、利用率越低。 我们的做法是:**同一台高配宿主机可以按用户需求灵活拆分**。客户要 1:2 就给他 1:2,剩下的 CPU 和内存正好装成一个 1:8 卖给另一个客户。到 GPU 时代这个能力更关键——GPU 服务器上除了 GPU 卡,还剩很多 CPU 和内存。友商是让这些资源在 GPU 服务器上闲置(因为规格对不上),我们可以把这部分资源当成标准的 CVM CPU 卖出去。 这就是为什么**腾讯云的 GPU 毛利率会比友商略高一点**——不是我们的 GPU 采购更便宜,是我们把 GPU 服务器上的"边角料"卖出去了。 再上一层是**教室装箱**和**业务画像**。 - **教室装箱**:把不同"性格"的虚拟机安排在同一台宿主机上。有的用户白天高峰、晚上低谷,有的正好反过来;把他们凑在一起,宿主机的整体负载曲线就平了。 - **业务画像**:用机器学习(和最近这两年的大模型能力)识别用户业务的时序特征。**如果我有把握预测某个用户接下来几小时不用 CPU,我就有很多办法把这部分 CPU 卖给别人**。 顺便预告一个即将到来的时代:**AI Agent 应用对 CPU 的占用会比传统互联网应用低得多**——因为它大部分时间都在等大模型返回结果,CPU 是空的。这意味着未来"容易调度的业务"会越来越多。这对 CSIG 的利润来说是巨大的增量。 ## 六、高密的碎片,变成新的资源 高密还带来了一个意想不到的副产品——**碎片**。 一台 768 核的宿主机,即使装箱做到极致,也总会剩下一些"卖不掉的边角料":几十核 CPU、几百 GB 内存,规格上凑不出任何主流机型。过去这些碎片就是"合理损耗",大家默认它不存在。 在近千核宿主机 + 混合装箱 + 热迁移的组合下,这些碎片突然变多了——**规模上到了数百万核**。放在那里也是浪费,尤其现在内存涨价,内存碎片非常珍贵。 那能不能把这些碎片给到 Developing 场景?**给到那些第一次上云、想跑一个小博客、想搭一个测试环境的技术爱好者?几乎可以认为是无成本的**。 这就直接为 Lighthouse(轻量云)提供了几乎无限的低价库存。也为后来 2024 年的帕鲁服务器、2025 年的龙虾装机准备好了弹药——那是下一篇的故事。 ## 七、成绩单 九年之后回头看这些数字: - **单机 CPU 密度**:从 56 核走到了 768 核 - **单位成本**:下降了 50% 以上(不同时点数字不同) - **资源利用率**:稳定在 **90% 以上** - **友商利用率**:大约 **60-70%** 这个 90% vs 60% 是什么概念?换个说法:**公司买了 100 斤面粉,我们把 90 斤做成了包子卖给用户,友商只做出了 60-70 斤,剩下的都在"合理损耗"里**。 在同质化竞争最激烈的云基础设施赛道,这 20-30 个百分点就是利润率的差距。CSIG 这两年的"浮出水面",很大一部分是这里贡献的。 ## 八、真正的护城河 讲到这里,你可能会有一个疑问:这些东西这么值钱,为什么友商没做? 我的答案是——**他们不是没做,是他们没法做**。 **第一,路径依赖**。友商过去 10 年在市场上一直讲"我提供的是最好的 CPU、最好的单核性能",突然要转身讲"你应该买主频低但核数多的机型",商业上是走不通的。这是他们跟自己市场话术的战争。 **第二,工程债**。我们从 2017 年开始踩内核 8 比特的坑、20 分钟开机的坑、35000 种装箱方案的坑。这些坑不是一年两年能补的,是团队每一层都投过血汗的。 **第三——也是最反直觉的一点——护城河反而在客户不在意的地方**。 我们做了这么多技术优化,客户几乎不知道。他们只知道"腾讯云比阿里云便宜一点,或者性能好一点"。我们甚至不太想告诉他们太多——因为一告诉他们,他们下一句就是"那你们能不能再降价一点"。 **技术护城河的价值不在于让客户理解你,而在于让友商追不上你**。我们至少领先友商 1-2 年——直到今天,2026 年 7 月,还有很多客户认为算力是最重要的事(其实他们上线之后使用率极低,只是拿"算力"当谈判筹码)。 ## 九、有过分歧,但过程仍然值得 九年不是没有分歧。 直到现在,团队内部对于"是不是矫枉过正了"仍有不同的声音。有些场景 CPU 算力确实很重要——比如某些高性能计算、某些游戏服务器。我们把行业整体导向低主频高密度之后,这些需要高主频的客户会觉得很孤立,前端行业和售前的同事也承受了不少委屈。 但我们要回到一个基本判断上:**做任何选择都有成本,问题只在于"多少成本换多少收益"**。 我们没有停止对高主频设备的采购,也没有停止对高主频场景的投入。我们只是在引导——**引导行业尽可能选低主频,因为低主频我们买得多、库存多、调度得好、有真正比友商强的技术优势**。这是一种"用组织的资源换组织的经营优势"的引导,不是垄断。 组织的目标是 CSIG 整体的经营提升,那么这条路线对组织目标的贡献,值得所有前端团队一起去承受这个转型的不适。**这一点也是我在过去 9 年反复跟团队强调的:所有的技术选择,最终都必须回到组织目标上来审视**。 --- 九年的高密路线,让我更相信一件事:**同质化竞争的行业里,真正的胜负手不是你比对方多做了什么,而是你比对方少做了什么**。 不再追单核性能,不再刷跑分,不再讲"我们代次更新"——把这些放下,才有空间去解决用户真正的问题(Hosting 而不是 Computing)。 下一篇,我们讲这套世界观在 AI 时代怎么继续走。为什么我们做了龙虾装机?为什么我们又克制了?为什么我不给团队补贴 Token? --- **系列导读** - 第一篇:[[11-文章版1-云的宠物与牛群]] - 第二篇(本文):[[12-文章版2-高密机型的九年]] - 第三篇:[[13-文章版3-AI时代的云]]