It's not rocket science：设计一台能大规模使用的 AI 电脑

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

我的 manager 在和我讨论架构的时候，经常会不经意地提到一句 “it’s not rocket science”。这一点我越来越认同，所以干脆拿它做了标题。

做产品和做科研最大的区别，是做产品同样要求新，但风险必须可控：约束条件一大堆，还要把用户可能碰到的每一种 corner case 都想一遍。而架构师设计的不止是一颗芯片，是一台电脑最要紧的那个部件，牵一发而动全身。所以好的架构师不能只懂半导体和应用，还要知道自己的每一个决定会怎么影响这台电脑的其他部分。

最近我一直在想，下一代的 AI 芯片应该是什么形态、什么架构，突破口又在哪里。想来想去，这个问题其实可以收成一句话：怎样设计一台能被大规模使用的电脑，而不是一台非要最先进的制程、最充裕的资金、最专门的团队才玩得转的机器。

一、一个重新由统一归于混沌的时代

现在的体系结构，正处在一个重新由统一归于混沌的时代。

混沌的不只是结论——什么架构更适合越来越大的模型，什么产品大公司更愿意掏钱。结论之所以混沌，本质在于研究手段和未来科技树都不确定。以前大家的 workload 和它的特征相对确定，技术树跟着摩尔定律走就八九不离十，performance 还能比较准确地模拟、量化、预测、分析。

这几年完全不同了。你很难预测明年的大模型是什么量级，很难预测用户会开发出什么新的应用场景，很难 simulate 千卡、万卡节点的性能，也很难预测哪条技术路线会最先成熟、把良率拉上去、把价格打下来——3D DRAM、3D SRAM、HBF、CPO，现在还看不出来。更棘手的是，很多人甚至不会去考虑的问题也接踵而至：reliability、software maturity 这些以前被认为已经"解决"了的东西卷土重来，而且面目更加狰狞。

但有一点值得注意：这些新问题几乎没有一个是"更深的科学问题"。它们不单单是某个物理极限挡在那里等人去突破，而是规模带来的工程问题——卡多了、功耗高了、用的人杂了，于是原本可以靠几个专家扛下来的事情，现在必须靠设计本身解决。换句话说，以前可以只盯着把性能做上去，现在不能只关注性能，还要让这台机器能被成千上万张卡、成千上万个用户真正用起来。

这个转变，恰恰就是这篇文章想讲的事。

二、该赌什么，赌多少

问题这么多，市场又这么疯狂，于是很多公司选择用激进的选型去换取资本的青睐和好看的性能预测。

我并不认为激进本身有什么错。在一个技术路线尚未收敛的行业里，不赌是不可能的——你选的每一个工艺节点、每一种内存、每一种封装形式，都是一次押注。真正的问题是赌注下得清不清楚。

这里有两件事值得算清楚。

一是多个赌注是相乘的，不是相加的。一颗芯片从定义到量产要三年，你赌的从来不是"这项技术会不会成"，而是"它会不会正好在我流片的那个季度，以我需要的良率和价格成熟"。这本身概率就不高。同时押三四项，最终的成功率是它们的乘积；而且它们往往还不独立——激进选型通常会同时改变 floorplan、供电、封装和软件栈，一注落空，其他几注也跟着塌。

二是要看输了之后还剩什么。同样是赌，有的输了产品晚半年、少一档性能，但还能交付；有的输了整个项目直接归零。这两种听上去一样激进，风险的性质却完全不同。

所以判据不该只是"成功概率有多高"，而应该把两个问题连起来问：它成功的概率有多大，以及万一失败，我手里还剩下什么？一个成功率只有五成、但失败了还能降级出货的方案，很多时候比一个成功率八成、失败就得推倒重来的方案更值得下注。

这里火箭和电脑的区别就出来了。一枚火箭可以为了一次任务押上一切，因为它只需要在那一天成功一次，押错了，代价是一次发射。而一台电脑要被造出成千上万台、交到成千上万个你不认识的人手里，一旦押错，代价是整条产品线连同它背后正在生长的软件生态一起消失。目标是大规模使用的东西，赌注天然就该下得更留有余地。

不确定性之下最值钱的不是赌注本身，是期权——是你下注的同时给自己保留的那些别的可能。留后路不是不敢赌，恰恰是为了赌得起。

很多人忽视了，或者忘了：他们不止是在设计一个 number cruncher or a rocket，而是要设计一台 “computer”。

三、芯片架构不是 rocket science

说芯片架构不是 rocket science，不是说它不难，而是说它难的地方和火箭不一样。把几种东西放在一张表上比较，差别就清楚了：

最左和最右两列的差别，几乎全都落在"能不能被大规模使用"这一件事上：价格能不能算得清，产能能不能撑得住，用户是不是需要专业训练，场地是不是特殊的。而中间那两列，是这个行业目前的真实位置。

不过写到这里，我想为火箭说句公道话。

“It’s not rocket science” 的字面意思是"这没有那么难"，而我借它想说的是"我们做的不是火箭"。但有意思的地方恰恰在于：真正把火箭做成生意的那家公司，做的其实也不是 rocket science。猎鹰九号的价值不在于它飞得多高、推力多大，而在于它能回收、能复用、能排班，成本能写进一张报价单。SpaceX 做的事，本质上是把火箭从"一次性的科学奇观"变成了"可量产、可预期的运输产品"。他们赢在工程，不在科学。回头看那张表，火箭那一列真正被他们改写的行，是"量产"和"TCO 可预期性"，而不是"推力"。

所以真正的对立从来不是"电脑 vs 火箭"，而是工程 vs 表演。一台只能在最优条件下跑出漂亮数字、还需要厂商派人驻场调参的加速器，peak FLOPS 再惊人，也还停留在表演阶段。它也许能赢得一轮融资，但赢不了一个客户的第二笔订单。

四、架构师是后厨主管

架构师不是匠人，也不是疯狂科学家；架构师更像是后厨主管：预算有限、时间有限、人手有限，还要给食客定出一份他吃得下、也吃得起的菜单。非要玉盘珍馐、非要米其林级别的助手才肯开火的大厨，不是称职的大厨。

这个比喻其实就是 “it’s not rocket science” 的另一种说法：难的不是掌握某种深不可测的秘技，而是在给定的条件下决定做什么、不做什么。而在 AI 已经如此先进的当下，“拟定菜单"这件事本身也变得越来越可以被替代——真正不可替代的，是在约束条件下做取舍的那份判断力。

至于电脑，它是要让人买回去、任意使用的。一台好用的电脑，应该允许用户自行拓展、魔改、debug，而不是每个问题都要厂商亲自上阵。

所谓"能被大规模使用”，其实是三件事叠在一起：造得出来、铺得下去、用得起来。 这三件事都不是性能指标，但缺任何一件，性能都无从谈起。这一节讲的三个目标，是从产品和公司的角度去看这三件事；下一节的六件事，则是从架构本身去看同样这三件事。

供应链的周期与风险——先得造得出来。 这两年先进封装产线基本全线订满，头部几家客户吃掉了绝大部分份额，下单到交付以年计；HBM 更紧，因为每 GB 消耗的晶圆面积是普通 DRAM 的三四倍，AI 的需求会持续把产能从普通内存那边抽走。这意味着你要在架构还没冻结的时候就先承诺一个数量，而且封装产能往往和 wafer 产能绑在一起排。

同样的道理也适用于工艺。领先节点的产能一样被头部客户锁着，价格贵、良率爬坡慢，而且你未必排得上队。架构师身上容易有一种默认假设：我当然会用上最先进的工艺、最新一代的内存、最激进的封装。但这个假设本身就是一次押注，而且是最贵的那一种——它同时抬高了成本、拉长了周期，还把你放进了别人的队伍里。真正的本事，是在成熟一档的工艺和更普通的物料上，做出仍然有竞争力的东西。做得到这一点，产品才可能便宜、可预期、供得上货，也才谈得上被大规模使用。

所以在定方案的时候，该问的不只是"这个方案跑得多快"，还有一个更本质的问题：我们产品的命运，是不是攥在别人手里？ 这个问题落到具体处，就是几件事：这个选型把我绑在了谁身上，解绑要付出什么代价，如果对方的产能、良率或者优先级发生变化，我还剩下什么。

开发周期与成本——造得出来还得赶得上。 架构太复杂、开发太慢，等你交付的时候底层可能已经迭代过一轮——内存换代了，工艺换节点了，互连标准出了新版本；而市场那边，风口、红利和需求可能都已经过去。你交付的是一个三年前的问题的完美答案。

而且延期的代价不是线性的，是断崖式的。一个晚两个季度的产品，通常不是少赚百分之二十，而是根本没有位置——客户的机柜已经装满了别人的卡，软件栈也已经围着别人长出来了。所以架构复杂度本身就是一种风险，而不只是一种成本。简单的设计能更早交付，更早交付意味着更早拿到真实 workload 的反馈，进入下一轮迭代；复杂设计的惩罚是复利的。

大规模量产与交付的潜力——造得出来、赶得上，还要铺得开。 良率、扩产成本、binning、出问题时的退路，这些后面会细说。但有一条我认为最被低估：架构本身的比例灵活性。IO、带宽、容量、算力这四者的最优配比一直在变——训练和推理不一样，prefill 和 decode 不一样——而变化速度远快于一代芯片的开发周期。问题在于，很多技术选型会把这些资源强耦合在一起：3D DRAM 把 DRAM 直接堆在 compute die 上，你想加容量就必须连带着加算力；HBM 也一样，带宽和容量绑在同一摞里。代价不是"不够灵活"这么轻描淡写，而是你被迫连带着卖给客户几种他不需要的资源，而这些恰恰是最贵的部分。

需要说清楚的是，这里的耦合并不是设计缺陷，它恰恰是这类方案性能优势的来源——解开耦合，带宽就退回去了。所以这是一个真实的 trade-off，同时是这个方案最大的优势和最大的风险。要不要冒这个险没有标准答案，只能由架构师根据自己对市场和技术风口的研判来定。而这恰恰是这个岗位真正不可替代的地方：不是算出哪个方案更快，而是判断未来三年里，这份耦合会变成护城河还是包袱。

五、为此，架构上有六件事尤为重要

展开之前，有一条线索值得先点明：这台机器要在多苛刻的条件下才能成立？

火箭对条件的要求可以极高：专门的发射场、特定的天气窗口、受过专门训练的团队、不计成本的投入，以及一个单一而明确的任务。条件越苛刻，它就越不可能普及——但对火箭来说这不是问题，因为它本来就不需要普及。当然，正如前面说的，SpaceX 正在改变这一点，而他们改变的方式恰恰是把火箭往电脑这一侧推：提高数量、压低单发成本、把保障流程标准化。

电脑正相反。它要被卖出去，被一个你不认识的人，在一个普通的机房里，跑一个你没有预料过的 workload。你不可能要求每个客户都用得上最先进的制程、都有足够的资金、都只跑你调过的那几个模型、都配一支懂你架构的团队。规模本身就是这个区别的来源：一台机器的复杂度可以靠人扛，一万台机器的复杂度只能靠设计。 你的每一份复杂度都会被复制成千上万份，扩散到你永远看不到的地方去。

一个 feature 的复杂度，由验证团队承受；一个激进的封装选型，由后端承受；一个不可观测的设计，由现场承受；一个无法归因的性能 gap，由用户承受；一个没有退路的 bug，由整条产线承受；一个无法复用的接口，由自己承受。

所以下面这六件事，本质上是同一件事：把这台机器成立所需要的条件，一件一件地降下来。这也是 “it’s not rocket science” 这句话对我而言真正的分量——它不是说这件事简单，而是说这件事不该被做成只有少数几家公司、在一堆苛刻的前提条件下才玩得转的样子。回到前面那张表，“用户"那一行的差别，说的就是这件事。

这六件事分别是：

1. 设计要容易被验证——证明它是对的、把边界定义清楚，比设计本身更花时间。
2. 别把难题一股脑推给后端和封装——他们是最后真正要面对物理限制的人。
3. 系统必须能被快速测试和排错——上千张卡的集群里，找不到问题就等于铺不下去。
4. 要替写软件的人着想——用户能不能第一时间跑上最新的模型，和峰值性能同样重要。
5. 芯片要有 Plan B——它不完美的时候，也还要能用。
6. 设计要能复用、能扩展——它决定了产品能覆盖多大的市场、能活多久。

1｜验证友善

验证就是在证明这颗芯片在所有可能的情况下都不会算错。它是整个项目里最花时间的一环，通常吃掉一半以上的人力——每多加一个功能，就像给密码锁多加一圈转盘，要检查的组合是乘出来的。而且真正难的还不是把测试跑完，是先想清楚该测什么，也就是把设计的边界定义清楚。

所以一个设计什么时候算做完了？RTL 写完不算。PPA 收敛和验证签字都是硬门槛，两边都可能成为最后的瓶颈。区别在于，PPA 有面积、频率、功耗这些数字摆在台面上，从第一天起就被反复审视；而验证的代价没有对应的数字，它只体现在日历上——所以它是架构阶段最容易被低估的那一项。

具体有两件事最关键。一是边界要清晰：模块间的接口应该能用协议本身说清楚，而不是靠两个作者互相知道对方会怎么做。边界一旦模糊，验证就无法分而治之，只能整机跑 random，收敛速度掉一个数量级。

二是正确性和性能应该是两个可以分开的命题。正确性要做成好证明的，性能是另一套问题。分开的价值在于失效模式收敛了：性能机制出问题，后果应该是跑得不够快，而不是算错了。worst case 是性能不达标，但东西至少能用。反过来，如果一个为性能而加的优化同时承载了正确性的语义，它一旦出错就是致命的，而且验证时你无法把两个维度拆开分别收敛。

这几年性能验证的分量上升很快，也更难对付，因为它没有天然的 golden model。但我不认为这只能靠事后 profiling 兜底——性能的设计空间同样应该被 assertion 和 rule 约束住：队列深度有上界、仲裁延迟有上界、某个状态不允许超过 N 拍还没推进。做不到这一点，性能就会退化成一个无法 reason about 的黑箱，而黑箱是收敛不了的。

这里我想多说一句。我见过不少设计，为了省掉一两个 cycle 而把边界模糊掉——跨模块直接握手、把两级流水打通、让某个信号提前一拍穿过去。这一两个 cycle 在性能模型上是实打实的收益，但它同时给 PD 和验证都留下了难题：时序上多了一条难收敛的关键路径，验证上多了一个说不清归属的状态。

我的看法是，系统的性能应该靠更好的架构和设计去提升，而不该拿验证和 PD 的复杂度去换。前者的收益是结构性的、可以带到下一代的；后者的收益是一次性的，而代价要在这一代反复支付。

这也反过来要求设计更 deterministic。那些依赖运行时不可预测行为来换取平均性能的机制，本质上是拿可 bound 的性能去换不可 bound 的性能，在 benchmark 上也许赢几个百分点，代价是整个系统的性能无法证明、无法解释，也无法在下一代复用分析结论。一句话：正确性要可证明，性能要可 bound。

最后一点可能最反直觉。在设计空间已经锁定的前提下，AI 其实已经能相当程度地自动化设计本身。但验证不行——因为验证做的事情，恰恰是在定义设计空间。AI 当然可以生成 UVM，但 UVM 所定义的那个空间——哪些行为合法、哪些组合必须覆盖、哪些 corner case 值得花两周去追——仍然来自人。生成 testbench 是执行，划定范围是判断。所以尽管越来越多人试图用 AI 做验证，验证反而会是最长时间里最需要人力的环节。

2｜封装友善

在架构图上，很多事情是没有成本的。画一条线只要一秒钟，但那条线最后要变成实实在在的金属。你可以轻松画出八颗 chiplet 的拓扑、几十 TB/s 的 die-to-die 带宽、堆在逻辑上的 3D SRAM，这些在框图里都成立，放进 slide 里还格外好看。但落到实处，是另一批人要去面对 bump pitch 排不开、IR drop 撑不住、热点疏散不掉、warpage 让良率崩掉、时序在跨 die 边界上迟迟不收敛。这些问题一个都不会出现在架构 spec 里，但每一个都可能让这颗芯片造不出来。

这里存在一个危险的不对称：架构师"提出需求"的成本几乎为零，而后端"实现需求"的成本极高。不主动纠正这个不对称，架构就会系统性地向激进的方向漂移——因为漂移的代价从来不由画图的人承担。

所以封装友善本质上不是一个技术属性，而是一个流程要求。任何一个会把难度推给下游的决定，都必须在做出之前，和后端、封装、热与供电团队一起把风险和收益摊在桌面上讲清楚。这不是要求架构师去做后端的工作，而是要求他承认：自己画的每一条线，最后都是由别人去实现的。

我不是说不能激进。有时候市场就是要求你必须上 3D、必须把带宽堆到极限。区别只在于，那应该是团队共同做出的、清楚自己在赌什么的决定，而不是架构师画完图之后由后端去承受的后果。同一个激进方案，放在提前对齐过风险的团队里，和放在"图画完了你们看着办"的团队里，是两种完全不同的东西。

架构师的图纸终归要由别人去实现。一个不了解实现代价的架构师，画出来的不是架构，只是一份愿望清单。

3｜系统级 testing、debugging 与 profiling

当一个机房里连着上千张卡的时候，“出问题"就不再是意外，而是每天都会发生的事。千卡、万卡集群几乎把所有已知的风险源都叠在了一起：先进制程更薄的电压裕量、极高功耗带来的热循环和供电噪声、HBM 这样的多层堆叠、正在进入系统的光互连和 CPO——激光器有寿命，耦合对温度和形变敏感，失效模式与电互连完全不同。这些单独看都是"低概率”，但乘上卡数就不是了。更麻烦的是同步训练的木桶效应：一万张卡里有一张出问题，整个 job 就停了。

而当稳定性本身就成问题的时候，快速定位问题的能力就不再是运维的便利，而是能不能大规模交付的前提。一批卡装进客户机房，如果每次故障都要花几天才能定位到是哪张卡、能不能换掉继续跑，那么部署速度就被 debug 速度锁死了。你造得出来，但铺不下去——大规模部署的瓶颈会从产线转移到现场。

性能问题比稳定性问题还难查。宕机至少还有一个明确的现场，而集群里的性能问题往往就表现为"比预期慢了 20%"：没有报错，只有一条不好看的曲线。是哪张卡拖后腿？它是真的慢，还是在等别人？跨机器的 trace 有没有共同的时间基准可以对齐？这些问题在单机上都不难，在万卡上每一个都很难。所以片上要有独立于主数据通路、故障态下仍能工作的诊断路径，要有足够精度的跨芯片时间戳同步。scan chain 和 JTAG 在实验室里很有用，在机柜里几乎无用——可观测性必须是一项架构特性，而不是后期打的补丁。

还有一点常被工程师忽略：profiling 其实是一个销售工具。准备下大单的客户一定会先做 POC，如果他跑出来的数字低于标称，而双方又都解释不清为什么，这单大概率就没了——不是因为芯片不够快，而是因为他无法向自己的老板证明这笔钱花得值。反过来，一套能把性能拆解到具体瓶颈、并且指出如何优化的工具链，卖出去的就不只是性能，还有确定性。在大规模采购这件事上，确定性比峰值更值钱。标准很朴素：用户第一次跑出低于预期的性能不会立刻放弃你，但如果他花了两周还是解释不清为什么慢，就不会有第二次。能被解释的性能，用户才敢依赖；能被优化的性能，用户才愿意加购。

4｜软件友善

芯片是硬的，但用户每天打交道的是软件。模型几周就出一个新结构，而一颗芯片要三年。所以一个新模型出来，客户想下周就部署，而你的软件栈支持不了，他损失的不是百分之几的性能，而是这段时间里他本来可以做、却做不了的事情。他的卡还在机房里转，跑的却是上一代的模型。这是一笔极大的机会成本，而且不会出现在任何一张 benchmark 表格上。一颗软件不成熟的芯片，卖给客户的其实是一份需要一直等你的依赖关系——它剥夺的是用户的主动权。

所以架构阶段就应该反复做一个想象练习：当我的芯片被插进八卡服务器、再连成上千卡的集群时，写并行软件的那个人会遇到什么？我能替他保证些什么？

关键词是 guarantee。软件的难度，本质上就是硬件不肯提供的那些保证的总和。内存序有没有明确定义？跨卡的原子操作是不是硬件支持的？集合通信有没有硬件语义支撑？网络交付是否有序、重传由谁负责？同步原语的开销有没有上界？每一个硬件不提供的保证，都会变成软件要处理的一个 case，而在多卡场景下它会变成一个分布式的 case——难度不是加一，是乘一个数量级。单机上一个"偶尔乱序"的接口，加个 barrier 就过去了；一万张卡上同样的问题，可能要花三个月才能复现。

还有一句想特意提醒：不要想当然地以为 AI 能解决这一切。并行软件即使对 AI 来说也是难的。它难的地方不在写代码，而在推理并发行为、在没有确定语义的系统里保证正确性、在无法复现的现象里定位根因。这与验证那一节是同一个道理：AI 擅长在已定义的空间里执行，而并行软件的困难恰恰在于，空间本身就没有被定义清楚。

所以这最终会变成一个特别容易做错的取舍。架构师天然喜欢干净、漂亮、lean 的设计——去掉一致性、去掉硬件同步、去掉那些"软件本来就能做"的东西，架构图立刻优雅了，面积和功耗的数字也好看了。但被省掉的东西并没有消失，只是被搬到了软件那边，而且通常是搬到了最难的那一侧：多卡、异步、无法复现的那一侧。拿架构的整洁去换软件的复杂度，是一笔在纸面上永远划算、在真正铺开时永远昂贵的交易——架构的优雅是一次性的收益，而软件的复杂度是每一个用户、每一次部署都要重新支付一遍的成本。

5｜芯片的 Plan B

硅片一定会有不完美的地方，有的是制造时的随机缺陷，有的是设计里的 bug，等发现的时候已经流片了。这不是悲观，是统计学。所以该问的不是"会不会出问题”，而是"出了问题之后，我手里还有什么"。一颗芯片不该只有"完美"和"报废"两种状态，中间应该有很多档。

先看能不能 survive binning。不完美的 die 是常态，架构要做的是让它们仍然有价格——设计时就要预留可裁剪的维度：tile 数量、频率档、内存通道数。关键在于这些维度必须是软件能透明处理的。如果关掉两个 tile 就会让编译器的划分策略失效、让某些算子跑不起来，那这个维度就无法用来 binning，你的良率曲线上就少了一段。说到底，能不能 bin 取决于软件栈的适应能力，而软件栈能有多适应，很大程度上又取决于架构本身留了多少灵活性。

再看能不能 survive 不同的 composition。chiplet 时代一个产品是若干种 die 的组合，那么当某一种 die 供应出问题、良率不达标、或者被迫换一个版本的时候，其他部分能不能照常工作？这要求组合的自由度是设计里真实存在的，而不是纸面上的——那些组合都应该是验证过、软件也支持的配置，而不是"理论上可以但没人试过"。否则所谓的模块化只是一张框图。

第三，不要留下"难以验证但又关键"的东西，这其实是第 1 条在量产阶段的账单。一个 feature 如果功能上是关键路径、验证上又难以穷尽，那它就是一颗定时炸弹：它大概率能通过所有回归测试，然后在 tapeout 之后、在某个客户的某个 workload 上、以一种谁都没想到的方式炸掉。所以每加一个 feature，都值得专门问一句：它如果错了，我有没有办法绕过它？如果答案是"没有，整颗芯片就废了"，那么它的验证优先级必须提到最高，或者干脆拆成一个可以被关掉的快路径，再加一条慢但确定正确的备份路径。

第四点把上面几条串了起来：要有降级的选项，而不是只有开和关。某条激进的时序路径不稳、某个高带宽模式有 bug 的时候，你应该还有一个中等性能的配置可以退回去。性能损失一部分，但产品还活着。而在这个行业里，一颗慢 20% 的芯片和一颗不能出货的芯片之间的差距，不是 20%，是全部。

这些退路必须在架构阶段就设计进去。等 bug 出现那天再想就晚了——那时候你能改的只有软件，而软件绕不过硬件根本没有留的那条路。

说到底，Plan B 和供应链是同一个问题的两面：那边问的是"我们的命运会不会攥在别人手里"，这边问的是"会不会攥在运气手里"。而 binning 的维度、chiplet 的组合自由度、可绕过的 feature、可降级的配置，就是后一个问题的答案。你在架构阶段花掉的那一点面积和一点优雅，买的是未来某一天出问题时，手里还有牌可以打。

6｜模块化与可拓展

同一份设计能被用几次，决定了一家芯片公司的经济账。而这不只是"为下一代做准备"，在这一代内部就应该开始兑现。

先看纵向的复用。一个 IP 如果参数化做得好，同一份设计就能在同一个 SKU 里以不同配置反复例化。这省下的不只是设计工时，更重要的是验证工时——验证过的东西每多用一次，边际成本就趋近于零，而那恰恰是最贵的资源。再往前一步是 hardened IP：能不能直接 stamp 下去，不用重新跑综合和 PD？如果可以，后端的收敛风险、时序的可预测性、乃至流片进度都会跟着改善，这一次流片就受益。所以参数化的边界要在架构阶段就想清楚：什么都能调的 IP 验证不完，什么都不能调的 IP 用一次就废。

再看横向的 scale。一颗芯片的性能能不能随着互连的片数相对线性地扩展，是这一代产品就要回答的问题。客户买八张卡期待的是接近八倍，实际只有五倍，那三倍就是他白买的硅片、白付的电费、白占的机柜。线性度不会自己出现，它是设计出来的：跨片带宽和片内算力的比例、拓扑的直径和对分带宽、集合通信有没有硬件支撑、同步开销随规模增长是不是有界。这些比例一旦在架构阶段配错，后面用软件是补不回来的——你只能眼看着 scaling 曲线在某个规模上弯下去，而那个拐点往往就是你的产品在市场上的天花板。

更根本的一点是，可拓展性应该被当成基本需求，而不是设计完成之后再看看能不能扩。这意味着在定接口、配比例、划分模块的时候，都要主动留出余量——而留余量是有代价的：多一跳延迟、多一点面积、单卡成本高一些。

我认为这笔钱值得花。单卡成本是可以算清楚的、一次性的损失；而灵活度不够导致的损失是算不清的：它表现为某个客户的配置你满足不了、某个规模上你的 scaling 弯下去、某个市场窗口打开时你来不及做一个新 SKU。前者写在 BOM 上，后者写在你没拿到的订单上。

同样的道理，不同资源要能独立地 scale，否则你能给客户的就只是一条直线上的几个点，而客户的需求是散落在整个平面上的。最后，接口要比实现活得久：tile 内部可以每代重做，但 tile 之间的协议应该稳定，互连尽量走标准。每引入一条私有协议，都是在给未来的兼容性和生态记一笔债——而这笔债往往这一代就开始还了。

说到底，可拓展性从来不是一个技术指标，而是一个经济指标。它衡量的是：你验证过的东西能被用几次，你流过的片能覆盖几个市场，你写过的编译器能服务几代产品。而这些数字加起来，决定的正是这台机器最终能被多少人用上。

六、结语

前面这六件事，没有一件是炫技的。它们讲的全是代价、退路、约束和别人的日程表，而不是什么惊艳的想法。

但这正是我想说的。在一个技术树高度不确定的时代，架构师能贡献的最大价值，不是选中那条最激进的路，而是让整个系统在任何一条路上都还能走下去。留退路不是不敢赌——恰恰相反，那是为了赌得起，是为了输掉一注之后还能坐回牌桌。

而做判断这件事，可能是架构师身上唯一真正不可替代的部分。testbench 可以生成，RTL 可以生成，甚至在设计空间锁定之后，设计本身也可以相当程度地自动化。但决定验什么、赌什么、把哪一份复杂度留给自己而不是推给下游——这些没有一个能被外包，因为它们都不是执行问题，是取舍问题。

而所谓"能被大规模使用"，最终指向的是一件更朴素的事：能不能让更多的人用上这台机器。今天的 AI 算力仍然集中在少数几家公司，一部分原因是资本和产能，但也有一部分原因在我们这些做架构的人身上——如果一颗芯片非要最昂贵的材料和最先进的工艺才造得出来，一台机器非要造它的人守着才跑得好，非要一堆苛刻的前提条件才成立，那它就注定只能属于少数人。

芯片设计确实很难，但它难在约束条件多，不难在道理深。制造是难的，要在纳米尺度下闪转腾挪、控制电子、分析电磁环境。而架构本身更像一门关于取舍的手艺：把一堆互相冲突的约束，收敛成一个别人可以拿走、可以在普通条件下用起来、并且一直用下去的东西。造得出来，铺得下去，用得起来——一台电脑的价值，最终就落在这三件事上。

最好的架构，往往不是让人叹为观止的那一个，而是能被最多人放心用起来的那一个。

所以，芯片架构 is not rocket science。而正如 SpaceX 走通的那条路，就算是 rocket，如今也早就不是 rocket science 了。

——陈士博