业务与芯片垂直整合的一点思考

编者按：越来越多的互联网大厂纷纷组建半导体部门开始造芯，这背后的逻辑和动力是什么？本文作者破布，耶鲁大学在读博士，研究方向为计算机系统结构，相关研究成果曾落地于多款业界知名芯片。他从自身经验出发，分享了在软件业务与自研硬件垂直整合方面的一些思考。也许他的观点你不一定认可，但这不影响我们给你推荐这篇文章，希望这种思考能对读者们有所裨益。云巅论剑获作者授权发布。

这一次回国，亲身感受了这一轮造芯热潮给我们这个行业带来的巨大变化。涌入的热钱，雨后春笋一般冒头的众多 startup，快速提升的薪资，各家团队对人才的疯抢 ……

因为此前接触过很多金融圈的朋友，他们在新闻上看到阿里、腾讯、头条等互联网大厂纷纷组建半导体部门开始造芯的时候，便会陆续来找我探讨 —— 这背后的逻辑和动力是什么？

和很多业内前辈也聊过这个，其实定性的答案，大家的认知基本一致，例如看到华为海思被制裁之后，痛定思痛开始弥补芯片短板；例如互联网大厂每年的服务器采购量已经达到了可以考虑摊薄芯片自研成本的地步；当然，也包括本文的主题 - 自家软件业务与自家自研硬件的垂直整合。

这一趟回国，刚好参与了与之相关的工作，具体内容不方便透露。而在返回美国前，我开始对这个问题有了更多的一点思考。

（Note:本文下述所有数据皆为公开资料)

从 Instruction Cache 说起

作为互联网巨头，首要关心的自然是运行在服务器上的自家软件业务跑的好不好。

自从 2012 年的 Cloudsuite[1] 和 2015 年的 Goole Datacenter Profiling[2] 两个影响深远的项目之后，大家都开始意识到，服务器应用和桌面应用、移动应用最大的区分点之一在于，CPU Instruction Cache 的压力大很多，MPKI(Miss Per Kilo Insts)这一项指标可以达到 1-2 个数量级的差别。

来自谷歌数据中心的公开数据里提到，自顶向下的性能分析(Top-down approach)表明，CPU front-end 的卡顿占到了性能损失的 20%-40%，而传统桌面、移动应用只有 5%。并且，这个现象在服务器端的广告、大数据、搜索、邮件等业务上普遍存在。

（Intel CPU核心微结构在谷歌数据中心业务的性能分析[1]）

这背后的根本原因，是服务器应用通常具有很大的 binary size（大几百 MB，上 GB 的 binary size 并不罕见）。

OK，既然这已经是一个已知的公开问题，传统的设计巨头们例如 Intel、AMD、以及华为海思，都是可以去上手尝试解决、公平竞争的。

但其实并没有这么简单。这个巨大的 binary size 背后，是这些互联网巨头短则 5 年（例如头条），长则 15 年的（例如阿里淘宝）的业务代码积累。他们使用的软件框架、核心热点函数的分布，分支/函数跳转的 pattern，对这些传统芯片设计巨头都是不透明的。

比如，有的 JAVA 软件框架，其函数调用栈的深度和调用关系之复杂，可以在进入核心热点函数之前，就把 Intel 核心微结构前端的 return stack，和基于 return stack 的指令预取 [3] 给治得没脾气。而这样的现象，无法用公开的流行 CPU benchmark 来复现。[2] 当中提到，哪怕是指令压力最大的 cloudsuite[1]，距离谷歌数据中心业务的指令压力也有明显差距。

这道坎很难跨越，甚至是比传统芯片设计巨头具备的硬件优势更深的一道护城河。我很难想象传统设计巨头们，怎么拉起一个庞大的软件栈，把代码量、在线 QPS等指标积累到能跟业务巨头媲美的程度。

这意味着，传统设计巨头的产品，将不得不送到国外 FLAG / 国内 BATJ 这些大客户手中检验，并聆听这些来自业务端的需求，跟着业务的指挥棒来走。

金融圈的朋友告诉我，两个被广泛引用的数字是，Intel 的服务器 CPU 营收占到整个 x86 服务器市场的 90%，其中大约 40% 被国外 FLAG / 国内 BATJ 等头部大客户吃下。

只有一个来自传统微结构方向的例子，可能暂时不够指向明确的结论。我们可以再来看看新兴的 DSAs(Domain-Specific Accelerators)该怎么办。

DSA 的定义

同样还是来自谷歌数据中心业务的分析，发现 5% 的时间被花在内存分配上 [2]。在 [2] 这项影响深远的工作后，相关研究团队推出了内存分配加速器 [4]，这种加速器有望把这种额外开销削减一半，简单核算一下，这一种加速器的引入可以帮助谷歌节省：

假设服务器数量 100 万台，每台单价 5 万 RMB，100w * 5w * (5% * 50%) = 12.5 亿 RMB，也就是说基本覆盖了一个大几百人的芯片研发团队的研发支出。

互联网巨头搭建自研芯片部门，如果背靠的业务体量足够大，整个团队只要实现这一个 DSA，就离向公司最高管理层证明自己的价值只有半步之遥，这话可能有点夸张但其实真的有道理。

而这种加速器的设计，仍然与业务知识深度绑定。

1）各家的数据中心业务、软件栈分布，和需求各不相同，谷歌需要内存分配加速器，京东可能需要的是 GC 加速器，头条可能需要的是 codec……

2）具体到加速器的设计，例如内存分配，需要知道业务上使用的 memory allocator 类型（本身多半也是业务团队内部自研的），分配请求大小的分布，free-list 的热点，slow-path 和 fast-path 分别在哪里……

3）不少加速器需要引入自定义指令、自定义软硬件接口，没有软件业务团队的配合，这事没有办法做。

知道硬件上 know-how 不管用了，连 know-how 算不算数，都是业务定义的。

护城河，这就是垂直整合、业务知识带来的护城河，对传统设计巨头的降维打击。

不得不引向的结论

芯片好不好，握有业务应用的公司说了算。

下一代芯片的 spec 如何定义，握有业务应用的公司仍然掌握重要话语权。

每年芯片采购，会较大比例地集中给少数头部客户。

所有满足这三个特点的领域，例如本文讨论的服务器 CPU，接下来都会看到三个现象：

1）传统芯片设计巨头的话语权将在垂直整合时代被大大削弱，利润率被压缩，挣的是业务巨头手中分剩下来的钱

2）和业务部门垂直整合的自研芯片会异军突起，哪怕在纯硬件设计上一开始打不过传统设计巨头

3）各种 startup 的日子会比较难过，只能吃头部大客户以外的长尾市场

如果上述推论成立，那么这些互联网巨头们（阿里、腾讯、头条）就是属于我们这波年轻人的机会：绕开那些已经开始内卷的传统设计巨头，驶向垂直整合设计的蓝海。对于我自己身处的 CPU 这条赛道而言，旧时代的打法是照着 benchmark 打，新时代的打法是照着业务打。

掌握业务知识的多寡，会是我们这一代芯片架构师们的胜负手。

风险分析

将职业生涯押注在业务巨头的下属新建半导体公司上，也是可能有问题的。

现在主要有三路公司在自研芯片：

1）AI 赛道

2）手机赛道

3）互联网和移动互联网赛道

AI 赛道已经过于内卷，20-30 家独角兽或接近独角兽级别的公司，就不考虑了。

手机厂商自建的芯片设计部门，靠不住，或者至少没有互联网巨头靠得住。手机 app 对于手机厂商来说是闭源的，手机厂商对业务其实并没有足够的掌控力。

对于互联网巨头来说，因为监管收紧，流量入口改变等因素，对手中所握业务市场的掌控可能被削弱，例如政府/运营商主导的数据中心压倒了阿里云/腾讯云，拼多多 + 头条战胜了阿里+京东的话，由强势的业务所带来的对芯片设计的掌控力也会跟着土崩瓦解。

References

[1] Clearing the Clouds - A Study of Emerging Scale-out Workloads on Modern Hardware. ASPLOS 2012.

[2] Profiling a Warehouse-Scale Computer. ISCA 2015.

[3] RDIP - Return-address-stack Directed Instruction Prefetching. MICRO 2013.

[4] Mallacc - Accelerating Memory Allocation. ASPLOS 2017.

往期精彩推荐