文中观点仅代表个人立场。

今年五月初，我们办了一场发布活动，展示了最新的系统和软件栈进展。其中让我印象最深、也最激动的，是这样一张图：中间只有两个词——Run Anything.

后来我恰好有时间听了 Debbie Marr 在 ISCA 上的 keynote（Computing at the Crossroads: Architecture, Economics, and the Next Era）。她讲了三点：现在是做高性能 CPU 的好时候，是做 RISC-V CPU 的好时候，也是做 general purpose computing 的好时候。

在所有人都在聊 LLM 加速的年代，这三句话听起来相当逆流。但我不想停留在复述她的观点，我想聊聊我自己的理由：为什么在当下，我们仍然需要、也应该做 general purpose compute。

先把话说清楚，我这里说的 general purpose，不是"回去做一颗大 CPU"那么窄。我指的是：不要把芯片的架构和微架构，绑死在某一种模型结构、某一种算子形态上。可编程、可重新调度、能在新 workload 出现时不用重新流片，才是这里的关键词。CPU 是其中的一种形态，但不是唯一一种。至于这条线到底该划在哪儿——多通用才算通用——我想放到最后再回答，因为那个答案取决于下面这三点。

一、你没法知道下一代模型长什么样

LLM 的能力增长正在放缓。 这第一个观点大概最有争议，而且它是我很主观的体感。Opus 4.8 其实才发布三个月，但 Anthropic 紧接着就放出了 Fable 5、Opus 5，OpenAI 发布了 GPT-5.6 Sol，国内开源模型这边 GLM-5.2、GLM-5.3、K2.7、K3 也接连出场。可作为一个 power user，我并没有感觉到能力上的质变。我当时用 Opus 4.8 遇到的那些"AI 一时半会儿搞不定"的问题，在 Fable 5 发布第一时间换过去之后，大部分还是搞不定。据传 Opus 5 和 Fable 5 的量级已经到了 5T parameters——如果堆到这个体量，体感提升仍然是线性甚至次线性的，那 scaling law 至少在边际上已经不太灵了。

体感毕竟是体感，所以我去翻了一下 Artificial Analysis 的 Intelligence Index。今年八月的榜单上，第一名 Claude Opus 5 是 63.0，第十名 56.8——整个前十挤在 6.2 分之内，而且这十个位置来自六家不同的团队。更贴近我个人经验的是：我之前用的 Opus 4.8 排在第九，57.3；也就是说我从 4.8 换到 Fable 5（62.1），在这把尺子上总共只挪了不到 5 分。

顶端挤成这样，我认为本身就是个信号。不同路线、不同数据、不同规模、不同算力预算的团队，最后收敛到同一个窄带里，更像是大家撞上了同一堵墙，而不是谁的配方特别灵。真正的能力跃迁应该长成断层，而不是长成一条挤满人的水平线。

另一个卡住的地方是 context length。业界在 1M 这个数量级上已经停了一段时间，而很多真正复杂的问题恰恰需要长 context。就算之后还能再往上推，上限在哪里？不断上升的存储和计算压力又怎么解决？我很希望被 AI model companies 证明是错的，但就目前而言，我认为 transformer 这条路已经开始看见瓶颈了。这就引出第二点。

未来会有更多的模型架构。 其实很早就有人在尝试新架构，JEPA、Mamba、Titans（Beyond LLMs: A Post-Transformer World Emerges），新的尝试一直在慢慢冒出来。不同模态本身也会用到不同的模型或者模型变种，比如 diffusion transformer。我相信在不同的应用场景下，不同架构会有各自独特的优势。

而且这件事远不止发生在聊天框里。蛋白质结构预测、基因组分析、气象和材料模拟，这些领域各自都在长出自己的模型谱系，它们的骨架经常不是 transformer——等变网络、图网络、state space、乃至传统数值方法和神经网络的混合体。它们对硬件的要求也长得不一样：有的极度吃不规则访存，有的吃稀疏，有的根本瓶颈在预处理而不在矩阵乘。如果你只盯着 LLM 那一种形状去设计，你会发现自己在这些场景里跑得并不比别人快多少。

而 LLM 本身会加速这种尝试的速度——这一点有点像 EDA 的出现：人们用当下的算力去设计和探索下一代计算平台；同样地，大家会用当下的 AI 去探索和迭代下一代 AI。

把这两点放在一起看：模型能力在放缓，架构在分化，而芯片的设计、制造、量产、系统稳定天然要比软件晚 2-3 年——你今天定下的架构，是在为两三年后那个你还没见过的 workload 下注。在这样一个组合里，把自己绑死在某一种模型上，风险是巨大的。

二、就算你知道，你要造的也是一台计算机

AI 吃掉很多算力，但不是全部算力。 几乎所有计算机从业者都听过 Amdahl’s law。它的本质是说：如果你只优化计算过程的一部分，那你的整体收益永远有上限。你可以把其中 20% 优化到零，但你比不过把整个计算全都提速 30% 的系统。

今年大概可以称为 agent 元年：AI 拿到了 tool use 的能力，可以自己写代码、自己执行。那作为一个架构师，我的 AI agent 大部分时间在干什么呢？在庞大的代码和数据里搜索某个 pattern（去定位问题）、编译、跑架构模拟、跑 RTL 仿真、跑 CI 测试。我曾经让 agent 跑了一个晚上，它总共只做了三处 edit——因为一次编译要 20 分钟，一次完整的模拟要跑 2 个小时。而这在我们的工作里还不算特别长的。

所以当生成代码的速度快到一秒几千个 token 时，瓶颈就从"写"整个挪到了"验"。而验证这件事，到今天仍然主要落在通用计算上。

我想强调的不是"所以要加一颗大 CPU"。今天任何一颗像样的 SoC 上都已经挂着一堆小加速器——编解码、加解密、压缩、DSP、图像信号处理——它们各司其职，谁也没打算变成矩阵乘。真实的工作负载只会往这个方向走得更远：基因测序有它自己的比对和组装引擎，科学计算有它自己的稀疏和不规则访存需求，数据预处理、检索、序列化这些"不性感"的环节各自都能长出专门的硬件。所以这一部分讲的其实是整机：矩阵乘只是这台机器里的一个部件，剩下的部件同样决定它跑多快。

这也是我在《It’s not rocket science》里写过的那句话的延伸——很多人忘了，他们不止是在设计一个 number cruncher，而是要设计一台 computer。放到今天更具体一点说：我们要造的是一台 AI computer，而不是一个更快的乘法器。乘法器只负责那 20%，而计算机要负责剩下的 80%。

这一点和上一部分不同：它不依赖于我对模型走向的任何判断。哪怕明天 transformer 就是终局、模型架构再也不变了，只要 AI 还需要被验证、被喂数据、被接进真实的系统里，general purpose compute 就还在关键路径上。

这里其实有两条不同的"通用"轴，值得分开说。上一部分讲的是跨模型架构的通用：同一台机器能不能跟着模型形态一起变。这一部分讲的是跨工作负载类型的通用：编译、搜索、预处理、测序、仿真、CI，这些活既不是矩阵乘，也不打算变成矩阵乘。第一条轴考验的是你的 dataflow 和调度留没留余地，第二条轴考验的是你这台机器上到底有没有能接住这些活的部件。

三、越贵的东西，越要被喂饱

2018、2019 年摩尔定律"失效"之后，大家一度假想计算的下一步进步要靠 specialization。这个想法本身是有道理的，但它藏着一个前提：假如我们真的处在一个芯片充裕的世界——任何人都能非常便宜、非常快地流片、封装、测试、编程一颗芯片——那当然可以按每个人、每个场景的需求去定制，专用化的代价几乎为零，前面两部分的担心也就不成立了。

问题是这个前提不成立，而且正在变得更不成立：制造在进步，但同时也在变贵。

我和朋友开玩笑说：十年前用不起 HBM 的人，现在还是用不起。摩尔定律确实失效了，但失效的是它的经济学含义——每颗晶体管的成本不再随着制程往下走，先进节点上单个 reticle 的设计成本和流片成本都在往上抬。制程还在缓慢推进，但真正接棒的是 memory、IO 和 packaging。

要知道 GDDR5（2008）到 GDDR6（2018）整整等了十年，DDR 和 LPDDR 在 2010 年之后也都经历过类似漫长的等待，以至于所有人脑子里都有那张经典的图：memory 的进步远远落后于 compute。而 HBM 从 2013 年到今天已经走到第四代，单 stack 的容量和带宽都翻了十几到几十倍，这在以前是不可想象的。随着 3D DRAM 到来，memory 未来可能还有更大的跃迁。互连这边也是一样：2017 年 AMD 最早公布 chiplet based CPU 的时候，die-to-die 带宽只有 50GB/s 量级；而在最新一代的加速器产品上，单向 die-to-die 已经是 TB/s 级别，不到十年做到了两个数量级的提升。当然这里面有芯片品类和架构差异带来的影响，不是严格的同类比较，但不可忽视的是这十年里 die-to-die 技术的爆炸式进步。

体育迷常说，在天赋面前技巧不值一提。芯片领域也是类似：在巨大的基础数值差异面前，架构可以缩小差距，但很难完全抹平差距。而如果你要提供 best-in-class 的性能，就不可避免地要用最前沿的工艺、最前沿的封装和最前沿的 memory，也就意味着更大的风险、更低的良率、更高的制造溢价、更紧的供应链绑定和更长的 lead time。这把芯片推成了一个烧钱的游戏。

所以回到这一节开头的那个前提：芯片并没有变得充裕。七年过去，“用定制去换性能"这条路不但没有因为摩尔定律的退场而变好走，反而更贵了。

而这件事推出来的结论，和前面两部分其实不太一样。前两部分讲的是对冲：因为你不知道，所以别把自己焊死。这一部分讲的是摊薄：当系统里最贵的东西不再是逻辑，而是 HBM、先进封装和那几个 reticle 的时候，你就必须让它们尽可能一直有活干。

一颗只在跑矩阵乘时才被喂饱的芯片，意味着它的 HBM 和封装在编译、调度、数据预处理、验证的时候都在闲着；而如果你为了避开这一点，去做两套分开的系统，那你就要为昂贵的部件付两次钱。所以我反而觉得，未来 CPU 和 matrix engine 可能会绑得更紧、更多地共用同一套内存和系统，而不是更松。

这里要说清楚：共用系统不等于回到专用。单元可以是专用的，系统是通用的。 通用性在这里不是体现在某个 engine 上，而是体现在"这套昂贵的资源能被多少种不同的活调用”。这也顺带回答了一个很自然的质疑——灵活的 control flow 和 scheduling 要付面积和功耗的代价，值吗？如果这份灵活换来的是同一套 HBM 和封装被多种负载轮流喂饱，那这笔钱不是白花的，它省下的是你本来要买第二套系统的钱。

所以

三部分说的其实是同一件事，只是站在三个距离上看。近处看是"你没法知道"：模型会变，架构会分化，而你的芯片要提前两三年下注。中间看是"就算你知道也一样"：计算里从来不是只有矩阵乘，agent 越强，被推到瓶颈上的反而是那些最不起眼的环节——编译、验证、预处理、以及每个领域自己那一套专门的活。远处看是"越贵的东西越要被喂饱"：当昂贵的不再是算力本身而是承载它的那套系统，通用就从一种保险变成了一种效率。

那为什么大家都在做专用

“现在做芯片的，明明都在往专用走”——这话没错，但它和上面几点并不矛盾，因为大家算的不是同一笔账。最优的专用化程度，由你的市场位置和回本周期共同决定：如果你今天已经在一个真实存在的大市场里占着可观份额，把架构紧绑在今天的 workload 上就是理性的——回本周期短，出货量足够摊薄成本，赌注还在自己手里。

但这笔账在两种情况下会翻过来。一是你的回本周期比模型的迭代周期更长。二是上层已经被榨干了：当你专门优化的那一块被压到接近于零，再堆专用化就买不到更多的加速和吞吐，剩下的时间全在别处——这正是第二部分那条 Amdahl’s law 从另一头咬回来。今天已经在牌桌上、手里握着份额的厂商，想的是怎么在这个已经存在的市场里多切一块蛋糕；我想的是下一代的 AI computer 长什么样。这是两道题。

通用不是对冲，是常态

前面我用了"对冲"这个词，但这个词偷偷预设了一个前提：存在某个稳定的常态，专用化在那里是安全的，而通用只是在等它到来之前买的一份保险。

问题是，计算从来没有收敛过——它既没有集中到某一种负载上，也没有在任何一个形态上停下来过。从大型机到 PC 到移动到云再到今天的 AI，每一轮都有人宣称新的负载已经定型、可以固化进硅了。这里面确实有赌对的：视频编解码、基带 DSP、网络转发，背后都站着冻结了很多年的标准，做进专用硬件是极其划算的买卖。但请注意它们赌的是什么——一个稳定的抽象层，而不是某一个具体实现。反复扑空的，恰恰是把某一代模型、某一种数据流直接焊进硅里的尝试。

GPU 是这中间最值得看的一个。它出生时是一条固定功能的图形管线，此后一路往可编程走，同时又一路往里加专用单元——tensor core、RT core、编解码引擎。它从来没有在"变通用"和"变专用"之间二选一，它走的就是第三部分那句：单元可以是专用的，系统是通用的。而它能一路吃掉图形、HPC、挖矿、深度学习这些没人预料到的负载，靠的是后半句。

所以在我看来，通用不是对不确定性的对冲，它就是计算本来的样子。真正需要被论证的从来不是通用，而是专用——你得说明为什么这一次不一样，为什么这个负载会稳定得足够久，久到能覆盖你的设计、流片、量产和折旧周期。

这不等于通用没有代价：灵活的 dataflow、留有余地的调度、能接住各种活的部件，都要占面积、吃功耗、花设计精力，而一颗把余地全砍掉的芯片在当下这代负载上确实可能把你打得很难看。通用是可能输掉某一代的。但这两种输法性质不同：通用输掉一代，下一代还能接着打；专用一旦绑错了层次，通常不是少一档性能，是直接归零。

那到底多通用才算通用

你可以绑定在计算的某一个大类上，但不要绑定在特定的数据流和控制流上。

架构完全可以是为大规模并行的数值运算而生的——这个类别本身相当稳定，过去十几年里模型范式换了好几轮，“大量并行数学运算"这件事从来没变过。决定一颗芯片能活多久的，不是它峰值算得多快，而是当上层的算子形态、数据流向和调度方式变了之后，它还能不能重新排布过来。所以在算术单元上激进是可以的，在 control flow 和 scheduling 上必须留有余地。

这也给了一个挺实用的自检：想象你目标模型的 dataflow 明年变了——你是改一版编译器和调度，还是得重新流片？如果是后者，那你绑的层次就太低了。

所以 general purpose 不只是一种设计上的优雅，而是这个时代每一个架构师都绕不开的考量。架构师不该为了打榜的一时爽，把一整代产品和自己的判断，押在一场不确定的轮盘赌上。

回到开头那两个词。Run Anything 最容易被读成一句关于覆盖面的承诺——今天能跑多少个模型。但它真正有分量的地方在时间：明年、后年那些还没被发明出来的东西，你也照样跑得动。