# Reiner Pope（MatX 创始人）访谈全文中文翻译
> 原视频：[Reiner Pope (@reinerpope) on X](https://x.com/reinerpope/status/2044525525646119419)
>
> 对话双方：Reiner Pope（MatX 创始人/CEO）与 Youssef Smulki（主持人）
>
> 时长：约1小时14分钟
>
> 主题：MatX 芯片设计、SRAM 与 HBM 架构、数值精度、训练与推理、互连设计、性能建模、Prefill vs Decode
2027年的芯片
Youssef: 好，Reiner，假设现在是2027年，芯片会是什么样子？有什么不同？
Reiner: 2027年嘛，从芯片的发展时间线来看，其实并不算遥远。
Youssef: 是啊。
Reiner: 但从AI的时间线来看，可能就没那么近了。
Youssef: AI那边是按周计算的。
Reiner: 对，确实。从芯片的角度来回答这个问题，其实就是在问：过去一两年里一直在研发的芯片会是什么样的？我觉得有几个大的物理层面的趋势：第一，FLOPs（浮点运算次数）越来越便宜，我们仍然可以把越来越多的算力塞进同等规模的逻辑电路里；第二，功率密度在不断提升，我们能向芯片输送更多的功率，同时也能把热量散出去；第三，如何更好地利用 SRAM（静态随机存取内存）。我认为这是三大主要机遇——利用现有技术实现真正的产品市场契合度。所以我认为短期内，我们应该期待看到很多低延迟芯片，能达到 Groq 和 Cerebras 的水准。
Youssef: 嗯。
Reiner: 这是通过将权重（weights）存入 SRAM 实现的。这里有个关键点：权重放在 SRAM，但 KV（KV cache，键值缓存）可能还是放在 HBM（高带宽内存）里。
Youssef: 嗯。
Reiner: 然后还有更多更多的 FLOPs，因为当你考虑到边际一个 FLOP 对比边际一个字节/秒的 HBM 带宽之间的"汇率"时，增加 FLOPs 的成本要低得多。
Youssef: 嗯。那这个比率现在大概是什么水平？
Reiner: 在 HBM 这一侧，增加一点边际 HBM 带宽，基本上意味着我需要再买一叠 HBM。我最多可以提高引脚速度的频率，但除此之外，就只能买更多的 HBM 叠了。HBM 在芯片总拥有成本中占了很大一部分——在很多情况下，甚至比逻辑芯片本身还贵。而且我们在存储带宽这一侧，已经逼近了物理极限。下一代 HBM 甚至面临散热问题——我们需不需要把它和逻辑芯片分离才能散热？这是巨大的物理挑战。
反观逻辑芯片这边，摩尔定律仍在推进，虽然比过去慢了很多，但每一代还是有提升。而且从架构层面，还有很大的空间可以再多塞进两倍、三倍、四倍的 FLOPs。所以在过去几年以及可见的未来，廉价地增加 FLOPs 的空间明显更大。
Youssef: 好的。我们来聊聊散热。随着越来越多的 FLOPs 被集成进芯片，我们应该会用到水冷吧？
Reiner: 毫无疑问。
Youssef: 那这件事怎么和整体权衡平衡起来？系统建造起来明显更难、成本也更高。在考虑总拥有成本时，你是怎么看这个取舍的？
Reiner: 关键在于选择正确的计量单位。如果你看一整套系统——比如一个机架——的成本，确实在不断攀升。但这个机架能做的事情是原来的两三倍。所以正确的计量单位应该是每 FLOP 成本、每秒每 token 成本，诸如此类。功率提升的原因之一，是它允许你提高芯片的时钟频率——用同等面积的硅，你可以获得两倍、三倍的性能，而散热成本并不会相应翻两三倍。所以这最终是净收益，而且我认为这个趋势还会持续一段时间。
这让我想起了奔腾时代追求4 GHz CPU 主频的那个年代。
Youssef: 是啊。
Reiner: 但有个本质区别：那个年代提高时钟频率是为了提升串行指令的执行速度；而今天，提高时钟频率是为了获得更高的并行吞吐量。从这个角度看，努力更有成效，不是在和墙壁死磕。
Youssef: 对。我记得以前给 CPU 超频的时候，要装那些夸张的液冷系统——
Reiner: 是啊，而且从架构角度，那时候的 CPU 流水线极深——最极端的情况是15级流水线，意味着一次分支预测失败的惩罚就是15个时钟周期。而 AI 芯片上，分支预测失败的惩罚可能是几百个时钟周期，但这完全没问题，因为你根本不会频繁遇到分支。在这段时间里，芯片可以执行数百万甚至数十亿次乘法，完全不影响效率。
Youssef: 从架构层面，我们也许应该回头聊聊 SRAM。现在有什么新进展？我觉得现在市场上对低延迟、高 OTPS（每秒输出 token 数）的芯片有很多关注，而这类芯片的一大亮点是：在实现低延迟的同时还能提供良好的吞吐量。我们来聊聊这是怎么做到的。
Reiner: 好的。首先，SRAM 是每一块芯片上都有的东西。那么当我们说"SRAM 芯片"时，为什么 Google 的 TPU、Amazon 的 Trainium、NVIDIA 的芯片不算 SRAM 芯片呢？
首先，"SRAM 芯片"的意思是将权重（weights）存放在 SRAM 中。Groq 和 Cerebras 一直在做的就是这个。要实现权重常驻于 SRAM，需要满足几个条件：足够大的 SRAM 容量、足够的互连带宽（用来支持 tensor parallelism（张量并行）和 expert parallelism（专家并行）进行数据进出），以及与芯片上 FLOPs 数量的合理配比。所谓"SRAM 芯片"，整个系统必须被正确配置，才能让权重长期驻留在 SRAM 中。
Youssef: 嗯。
Reiner: 这确实能带来比 HBM 更低的延迟。模型的延迟本质上等于将模型权重加载进乘法器所需的时间，即参数量除以带宽。SRAM 的带宽是 HBM 的100倍，因此可以实现更低的延迟。实际上通常只能降低约10倍，而非100倍，但大体上可以实现约一个数量级的改善。
但是，Groq 和 Cerebras 作为独立产品遇到困难的原因在于：SRAM 的容量太小了。面临的挑战是：我能否装得下权重？能否装得下 KV cache？
权重这边还好——可以跨数百甚至数千块芯片做流水线，每块芯片只存一小部分权重，几乎不会产生任何规模损耗，互连开销也不算高，可以展开非常深的流水线。
但 KV cache 做不到同样的事。问题在于：当你把 KV 展开到大量芯片上时，并没有节省任何空间——因为 batch size（批量大小）随着流水线深度增长，每块芯片节省了 N 倍的容量，但 batch size 也增大了 N 倍，两者抵消，净节省为零。
Youssef: 对。
Reiner: 所以结论是：KV 放 SRAM 行不通，容量不够，必须放 HBM。
Youssef: 嗯。
Reiner: 这意味着理想的芯片需要有足够的 SRAM 来让权重长期驻留，同时也要有 HBM 来存放 KV cache。我们在市场上已经能看到一些这方面的苗头——NVIDIA 和 Groq 开始以混合方式部署，把 NVIDIA 机架和 Groq 机架并排放置。但我认为长期来看，正确的做法是将两者更紧密地集成，在同一封装里同时放入大量 SRAM 和大容量 HBM，这样能带来更强的能力。
Youssef: 嗯。对于 NVIDIA 和 Groq 的混合方案，这两个系统目前是分离的。相比你们做的——一块芯片同时拥有大量 SRAM 和大量 HBM——这种用更好互连连接两个系统的方式，有什么取舍？
Reiner: 他们的做法有其合理性，是务实的应对方案。但这样做会在两侧之间竖起一道屏障：左边有一定量的资源，右边有一定量的资源，这个分配是固定的。如果想把资源从一边挪到另一边——比如把一部分 FLOPs 从 NVIDIA 芯片挪到 Groq 芯片——就必须把计算移过去，而计算的移动意味着数据要通过互连传输，这就产生了互连瓶颈。
如果从一开始就为此设计系统，就可以把 HBM 和 SRAM 紧密耦合，从而把所有的 HBM 带宽都用来服务 SRAM。这会带来很多有趣的新机会，比如：可以从 HBM 把某些数据（通常是 KV cache）加载进 SRAM，在 SRAM 里保留相当长的时间，然后再把下一批加载进来——这才是从第一性原理出发设计时自然会采用的方式。
Youssef: 说到你们设计这些芯片的目标，我们来聊一聊。你们在支持哪类模型上有比较明确的定向，你们是如何思考这个问题的？当这些芯片推出时，用户会想训练和运行什么样的模型？
Reiner: 最初的愿景是服务前沿实验室的需求，现在仍然是。具体体现为：非常大的模型、非常大的 batch size，同时保持低延迟，但重点是大 batch size。
这和其他一些芯片过去的思路有所不同。一些芯片会去问："我们能不能支持 batch size 为1的推理？能不能支持小模型，比如卷积或者小 channel 数的操作？"我自己也有参与过类似芯片的经历。
这类做法的挑战在于：你会花费巨量的时间和精力——无论是芯片设计层面还是硅面积层面——来支持这些小模型，而这是个更难的问题。你需要搞清楚如何把一个小卷积核在整个芯片上复制铺开，处理由此带来的片内数据移动问题；或者在 batch size 极小的情况下，设法从单个用户请求中挖掘所有可能的并行性，而不是像我们现在这样——有一万个并发用户，直接从大规模并发中获得并行性。
Youssef: 嗯。
Reiner: 所以我们的回答是：不，谢谢，这条路不走。NVIDIA 一直在尽力支持这些场景，2017年前后的很多芯片创业公司也把大量创新精力投入其中。我们的选择是：让整块芯片在任意时刻专注于做一件连贯的事情。
Youssef: 嗯。
Reiner: 我们依靠的是：工作量足够大、矩阵规模足够大、batch size 足够大，让整块芯片可以一次专注做好这一件事。这带来了简洁得多的设计。我们把省下来的这部分复杂度，用于真正有价值的创新预算——比如，如何在小 attention head size 下高效支持 attention（注意力机制）。
总体来看，最终的方向就是我们现在看到的 LLM 及其演化形态。定性的架构选择之外，产品层面的决策是：低延迟是免费的起点，需要通过 SRAM 加 HBM 的组合来实现；然后塞入海量 FLOPs，因为 FLOPs 是最宝贵的资源之一。
Youssef: 好的。那么有了这么多 FLOPs，你们是怎么思考人们会怎么用它们的？你们有个 ML 团队在研究这些问题，能聊聊他们在做什么吗？
Reiner: 先从最基础的问题说起：这些 FLOPs 应该用在哪里？训练、prefill（预填充）、decode（解码）——其中训练和 prefill 都是计算受限的，你总是可以往里加更多 FLOPs，这比较直接。麻烦在于 decode。
Youssef: 嗯。
Reiner: 常见的顾虑是：decode 完全是 HBM 带宽受限的，你能做的事情不多，别费心在那里加 FLOPs 了。
Youssef: 嗯。
Reiner: 但从几个角度看，这个结论可能是错的，或者至少是短视的。最根本的一点是：如果你的芯片上有大量 FLOPs 在空转，肯定有办法让它们发挥作用。
我知道这听起来有点空泛，所以还是来聊聊具体的方式。这是一个重要的研究方向，我相信很多实验室都在攻关这个问题。我们自己有一些观点，认为某些方向可能具有根本性的重要意义——我们的 ML 团队的一项核心工作，就是思考几年后这个问题会是什么样。
Youssef: 嗯。
Reiner: 拆解来看：模型里有 attention（注意力）层和 FFN（前馈网络）层，或者 MoE（混合专家）层。对于 FFN/MoE，你总是可以加更多 FLOPs——让它更大、降低稀疏度、连续运行几次，等等。怎样最有成效地做出这些改变并真正体现在模型质量上？到某个点，如果把 FFN/MoE 做得足够大，理论上应该能在内存带宽和 FLOPs 之间找到一个平衡点。
Youssef: 嗯。
Reiner: 另一个方向是让 attention 变小。文献里有大量相关工作，比较成熟的思路包括：长短上下文交替、跨连续层复用 KV cache、使用更少的 KV head，以及 MLA（multi-head latent attention，多头潜在注意力）——把注意力头压缩后再展开。更激进的方案是稀疏地访问 KV cache。
这里涉及的想法非常多，如何梳理这个空间是个大问题。我们 ML 团队做的一件事，就是摸清整个设计空间，量化 HBM 带宽和 FLOPs 之间的"汇率"——这两者之间到底存不存在可交换的关系？
SRAM 架构
Reiner: 说到底，核心问题是这样的——假设我想让模型质量提升1%，相当于把模型规模翻倍带来的效果。在算力（FLOPs）维度上，我们知道该怎么做：不断把模型尺寸翻倍，直到质量提升为止。那么，若要达到同等效果，需要把 HBM 带宽翻多少倍？这是一个很好的起点——先把它量化出来，搞清楚现在处于什么水平。这是个很有意思的问题，而且有很多难点，测量方式必须非常谨慎。比如用 loss（损失值）这种简单指标来衡量，结果可能会有误导：它会告诉你最优方案是把上下文长度限制在64个 token，永远不做更长的注意力（attention），然后堆一个巨型模型——从某种意义上说，这确实能在单位成本下最优化 loss。所以我们花了一些时间，尝试更精细地衡量质量，在评估（evals）中对长上下文（long context）相关的质量指标给予更高权重。
目标模型
Youssef: 对，沿着这个思路，模型和硬件都发生了巨大变化的一个维度是数值精度（numerics），对吧？我觉得大家都在朝着越来越低比特数的表示方向推进。
Reiner: 是的。
Youssef: MatX 的芯片会支持哪些数值精度格式？你们是怎么考虑精度方案对机器学习的影响的？
Reiner: 数值精度（numerics）是过去十年间任何人在每瓦 FLOPs 方面取得的单项最大改进，一直都是这样。英伟达（NVIDIA）一次次地将精度减半：从 32 位开始，到 16、8、4 位。这背后是有充分理由的——经验结果非常好。从 32 位降到 8 位，几乎是白送的午餐（free lunch）：降低精度，质量零损失。只要方案正确，甚至不需要增加参数量——完全是免费的收益。
Youssef: 嗯。
Reiner: 我们已经过了那个"显而易见的免费午餐"阶段，现在从 8 位降到 4 位时，质量确实会有所下降。
Youssef: 嗯。
Reiner: 但损失不算太大。举个例子，为了保持同等质量，我可能需要多增加 50% 的参数，但在英伟达上从 8 位降到 4 位可以获得 3 倍加速。这样算下来——参数量翻了1.5倍、速度提升3倍，净收益是2倍加速。
Youssef: 嗯。
Reiner: 我们看到了这个趋势，非常想顺势而为。挑战之一是要与客户和研究现状对齐——硬件的研发周期比机器学习研究周期长得多，这始终是硬件的难题。如果你问"今天大家在为哪种精度格式设计模型"，答案可能是 FP8——但这个视角太向后看了。所以在数值精度上的押注需要一定的前瞻性，同时还要设法管控预测出错的风险。
Youssef: 嗯。
Reiner: 在不透露具体细节的情况下，我们的 ML 团队在"哪些精度格式是我们可以信赖的"这个问题上做了出色的研究。综合成本、灵活性、硬件开销和质量各方面考量，我们芯片中的数值精度（numerics）方案非常优秀。团队已经完整验证了各个方面——我们能够训练（train）模型，清楚地知道质量损失在哪里，而当你权衡质量与速度时，这个方案非常有吸引力。
Youssef: 嗯。
Reiner: 另一个值得关注的方面是：由于预测本身存在不确定性，我们如何管理尾部风险——也许模型对精度的响应比我们预想的更差，或者更好。对此我们也有一些不错的思路。
FLOPs 分配
Youssef: 嗯，很好。还有一点我觉得很有意思——你们是少数几家同时瞄准训练（training）和推理（inference）工作负载的新兴芯片公司之一，对吗？为什么做这个选择？表面上看，推理似乎是更容易、更显而易见的选择，无论从软件角度还是从硬件设计角度来说都是如此。能聊聊为什么选择同时做训练和推理吗？
Reiner: 可以。有一个历史视角：2017年那批芯片公司为什么都选择只做推理？当时推理确实比训练简单得多，因为不需要互连（interconnect）——那时候单芯片方案就够用了，可以跑当时的 LSTM 或卷积网络，5亿参数可以放进一块芯片的内存里——单芯片解决方案，做起来非常简单。
Youssef: 嗯。
Reiner: 但今天完全不是这回事了，对吧？
Youssef: 哈。
Reiner: 现在即使是推理（inference），我们也在用数百块甚至更多的芯片来运行。所以今天任何人做的推理芯片都必须是机架级系统（rack scale systems）甚至更大规模，而这已经咬下了训练方案中大部分的系统复杂度。
Youssef: 嗯。
Reiner: 从推理方案到训练方案，增量差距其实很小。训练可能需要纵向扩展（scale up）方案，推理也可能需要——尤其是当你把权重放在 SRAM 里、需要非常大的互联域（connectivity domains）时。
Youssef: 嗯。
Reiner: 其他的增量差异还有什么？训练时可能需要不同的精度格式——训练有时用更高精度，也有一些技巧只适用于训练而不适用于推理。此外，训练还涉及转置操作（transpose operations）。但所有这些在实际芯片设计影响上都相对较小。所以你需要预判训练会占多大市场份额——我认为至少30%，但可能不到50%，因为强化学习（RL）这部分本质上也大量依赖推理。
Youssef: 嗯。
Reiner: 但只需要多付出约5%的开发工作量，就能额外覆盖大约三分之一的市场——这笔账算起来很划算。这就是背后的逻辑。
Youssef: 嗯。
Reiner: 而且这一点也得到了现实的印证——当前的行业巨头，英伟达、谷歌、亚马逊，都是同时支持训练和推理的芯片。从客户角度来看，这也提供了一种灵活性：我可以买一批推理集群，同时还保留了跑训练的可能性。尤其作为客户，我要对这批芯片承诺使用三年，两年后世界会变成什么样子我根本不知道，完全可能天翻地覆。所以能有一点额外的灵活性，是个不错的加分项。
模型质量衡量
Youssef: 对，这说得通。研发时间线似乎对很多决策都至关重要。我们来聊聊时间线吧——如果我现在开始设计一块芯片，启动设计流程，什么时候能拿到芯片？什么时候能部署到数据中心？
Reiner: 从有一个芯片想法，到做架构设计、RTL（寄存器传输级）、DV（设计验证）、再到流片（tape out）……从产品构想到流片，通常需要好几年。
Youssef: 嗯。
Reiner: 这个周期可能会因为 AI 而有所加速。
Youssef: 嗯。
Reiner: 但加速幅度不如软件领域那么大，很大程度上是因为风险管理的考量——重新流片（respin）的代价不只是流片本身的费用，流片成本"只有"3000万美元。
Youssef: 哈。
Reiner: 现在跑几次模型实验的花费可能都不止这个数。但重新流片的真实成本不只是流片费用，还包括：如果你已经在市场上部署了数十亿美元的芯片，整个项目的风险敞口可能高达几十亿美元，这才是为什么硬件上比软件保守得多的原因。这也反向说明了为什么 AI 应用于芯片设计的成效，迄今为止不如应用于软件那么显著。我相信这种情况会随着时间推移而改变，但——
Youssef: 你觉得哪个环节会是加速最明显的地方？模型写 Verilog 的能力够强了吗，还是在工具链的其他环节？
Reiner: 整个工具链大部分都是软件，或者说具有软件开发的形态。所以模型写 Verilog 已经相当不错了——这占了很大一部分开发工作量。设计验证（DV）也能做。当然，你做完了还要问：你信任它吗？你信任覆盖率（coverage）吗？也许还是要自己审查一下。我觉得在这方面它们表现还不错。但在产品和架构设计层面，目前还没有看到它们表现突出。
Youssef: 嗯。
Reiner: 这也许需要针对产品和架构工作改变工作流程。另外，与软件相比，硬件开发的模式更偏瀑布式（waterfall）——在动手写代码之前，有大量工作要做：写架构文档、性能建模等等。涉及性能建模的部分可以用 Python 来做，模型能干得不错。但很多其他的推理工作更像是散文写作而非编程，目前在这方面还不够适配。还有一块完全不像代码的工作——物理设计（physical design）是基于 GUI 的，有大量手动操作，而且迭代周期极长，一次布局（placement run）可能要跑一两周。这非常不适合当前的 AI 工作流。不过我相信这一切都会变快，但客观来看，从流片到量产部署之间仍然有大约一年到一年半的时间，这是整个实体供应链和流片周期决定的，暂时无法压缩。
数值精度
Youssef: 嗯。既然工具迭代速度慢、迭代周期这么长，有没有到了某个节点直接重写整个工具链的时机？毕竟工具链本质上也是软件——
Reiner: 是。
Youssef: 那有没有人已经在做这件事了？
Reiner: 这是个有意思的问题。要说清楚的是，这里说的工具链是 EDA（电子设计自动化，Electronic Design Automation）工具链，主要由 Cadence 和 Synopsys 提供。这些工具之所以昂贵，首先是因为它们积累了大量经过流片验证的经验——能保证你交付的设计符合台积电（TSMC）的设计规则检查（DRC），能满足时序要求，不会出现电气干扰等各种恼人的物理问题。这就是我们为之付费的核心价值。这与我们这种无晶圆厂（fabless）半导体公司做的事情风格完全不同。我真心希望 Synopsys 和 Cadence 自己在做这方面的重构，我相信也有一些初创公司在做这件事。
Youssef: 嗯。
Reiner: 但这里面沉淀着数十年来"哪些地方可能出错"的痛苦经验，以及确保满足所有设计规则的积累，这某种程度上是一道入门壁垒。或者说，你得先在失败的流片上浪费几亿美元，才能积累到那种经验。
Youssef: 太贵了。
Reiner: 是的。
训练与推理
Youssef: 还有一个印象是，晶圆产能分配和 HBM 都在变得越来越紧缺。现在情况大概是什么样的？在这种背景下，你怎么设计芯片——毕竟有些你原本依赖的东西可能很难拿到，或者比预期贵得多？
Reiner: 是的，这确实很奇怪。你可能和某个供应商签了合同，锁定了某个逻辑晶圆（logic die）的价格，但最终产能可能根本不存在——你锁的价格在供需层面根本无法成立，最终还是得重新谈。这种情况是存在的，而且对逻辑晶圆和存储晶圆（memory die）都有可能发生。面对这种局面，能采取什么策略？最根本的一条是做到更好的经济性：如果你能从每平方毫米硅片里榨出更多性能，那么在按成本定价的情况下，你就能比竞争对手承受更高的晶圆成本。
Youssef: 嗯。
Reiner: 同样的逻辑适用于 HBM 带宽——如果你能让每字节每秒的 HBM 带宽发挥更大价值，你就能在出价高于竞争对手的同时，依然保持性价比（price-performance）持平。这是我们认为自己能建立持续优势的底层逻辑。在此之上，还有日常商业层面的工作——签好合同、建立正确的合作关系。在具体细节上不便多说，但与重要的大玩家保持紧密合作是关键。
Youssef: 嗯。从整体供应来看，HBM 现在是比较难拿到的吗？
Reiner: 是的，HBM 可能是的。逻辑晶圆也有些紧张，先进封装（advanced packaging）也很难获得。整个生态系统都非常紧缺，这是整个供应链所有人都能感受到的。
研发时间线
Youssef: 回到之前的话题——每平方毫米能获得更多 FLOPs 或性能，就能有更好的定价。往后看，你怎么看定价和利润率的走势？过去几年英伟达能维持那么高的利润率，是因为竞争很少，而这种情况正在开始改变，对吧？在一个有多家芯片方案可以有效用于训练和推理的世界里，你们怎么考虑定价策略？
Reiner: 就我们自己的定价策略而言，我们全球大概只有五家客户，完全不需要把价格挂到官网上。我们会直接和最终客户谈判。至于如何制定定价策略——
EDA 工具链
Reiner: 我们会去谈的。但如果对方要求我们按成本价出售，那我们只能拒绝。不过，从更宏观的角度来看：在竞争不充分的市场里，企业自然可以维持较高的利润率；随着竞争加剧，利润率通常会下降。我认为未来几年就会出现这种趋势。不管是现有巨头——Nvidia、谷歌、亚马逊——谷歌已经有一些案例是愿意在自家数据中心之外销售芯片了，谷歌的传统竞争对手也开始采购谷歌的芯片，
Youssef: 嗯。
Reiner: ……而不是单纯依赖 Nvidia，或者与 Nvidia 搭配使用。OpenAI 采购 AMD 芯片也是信号之一。这些都说明，即便在传统芯片领域，利润率也在下滑。我们也从一些交易中看到苗头——Nvidia 不在现金层面打折，但可能通过某种股权安排来变相让利，实质上起到了折扣的效果。
Youssef: 但账面上好看一些。
Reiner: 对。
Youssef: 也许更合适。
Reiner: 对。
Youssef: 是的。
Reiner: 所以我认为利润率确实在下滑。
Youssef: 嗯。
Reiner: 作为初创公司，我们必须做最坏的打算——也就是说，我们可能要按成本加 1% 之类的极低价格出售。
Youssef: 嗯。
Reiner: 不过我不认为价格会低到那种程度。
Youssef: 嗯。
Reiner: 我认为实际售价会比那高得多。我们预期最终被迫接受的，是与最强竞争对手在价格-性能比上持平。到那个时候，我们已经非常满意了。
Youssef: 明白。在这个框架下，"性能"指的是输出结果，对吧？那 MatX 凭什么能在这个维度上胜出？面对未来可能涌现的众多竞争者，MatX 的优势在哪里？
Reiner: 说到性能，要分两个维度来看：吞吐量（throughput）和延迟（latency）。延迟方面，历史上的基准一直由 HBM（高带宽内存）决定——大多数 HBM 世代读取全部内存大约需要 20 毫秒。从 HBM1 到 HBM4，这个数字出奇地稳定，原因其实很简单：带宽提升的同时，容量也在同步增加。这 20 毫秒基本上决定了一次推理前向传播（forward pass）的典型延迟。投机解码（speculative decoding）能带来一些额外优势，但粗略来说，基于 HBM 的系统通常只能达到每秒几百个 OTPS（每秒输出 token 数），这正是 HBM 读取时间的直接体现。我认为，随着行业在未来几年陆续转向将权重（weights）存入 SRAM，这个"基准线"将从 20 毫秒降到约 1 毫秒，也就是大约 1,000 到 2,000 OTPS。
Youssef: 嗯。
Reiner: 我暂时看不到延迟在短期内进一步大幅压缩的路径。这非常依赖模型大小——对于较小的、尤其是密集型的模型，存在一些方法可以突破这个极限。Talos 发布了一个不错的 demo，性能比这个基准高出大约一个数量级，但它依赖于一个非常特定的甜点区间：非稀疏模型、极小模型，小到可以把整个模型装入单张芯片。一旦脱离这个甜点，我认为延迟通常会回归到每次前向传播约 1 毫秒的水平。
Youssef: 嗯。
Reiner: 所以延迟方面，我认为存在一个新的"基准线"，MatX 达到了这个水平，未来也会有更多公司陆续达到，这将成为新的标准起点。
Youssef: 嗯。
Reiner: 在这个新起点上，问题就变成了：你能在吞吐量上胜出吗？
Youssef: 嗯。
Reiner: 这归结为两件事：一是能输出多少 FLOPS（每秒浮点运算次数），或者说每平方毫米能提供多少 FLOPS、每美元能提供多少 FLOPS；二是能否有效支持长上下文，以及如何管理 KV cache（键值缓存）的加载时间。先说 FLOPS——MatX 在所有已公布产品中，每平方毫米的 FLOPS 是最高的，领先幅度相当可观。
Youssef: 嗯。
Reiner: 这部分来自我们在数值精度（numerics）方面的工作，也来自架构层面的设计——我们大幅减少了芯片内部通信的开销，同时避免了其他方案中为支持卷积（convolutions）或小批次（low batch size）等功能而引入的过度灵活性。正如我之前所说，如果你决定不做这些事情，架构可以做得大幅简化。
Youssef: 嗯。
Reiner: 综合下来，我们的 FLOPS 表现要好得多。KV cache 这边，本质上是"权重在 SRAM，KV 在 HBM"的混合方案，关键的模型架构原则是稀疏注意力机制（sparse attention）——也就是每次不读取全部 KV，而只读取一个小子集。这才是在权重存于 SRAM 的条件下实现高吞吐量的方法。
Youssef: 嗯。
Reiner: 如果没有这块 HBM 可用，你就必须把批次大小压得很低才能装下所有的 KV，而批次大小低，就直接限制了性能和吞吐量的上限。
Youssef: 嗯，对。我们聊了不少硬件路线的差异——纯 SRAM 方案、传统的以 HBM 为主的方案，以及 MatX 的做法。现在聊聊软件吧。在我看来，过去十年大多数芯片公司都在尝试构建完整的软件栈——用户写 JAX 或 PyTorch，就能在芯片上跑起来。但你们走的不是这条路。
Reiner: 对。
Youssef: 来聊聊为什么。
Reiner: 这条路有没有成功案例？我认为谷歌是最明显的。谷歌推出了非 GPU 的新硬件，然后把 JAX 做得在上面跑得非常好。以此为案例，结合我在谷歌写 JAX 代码的亲身经历，生产效率确实不错——直接写高层级的 JAX HLO，大概可以达到 50% 左右的 MFU（模型算力利用率）。50% 已经相当不错，但理想状态下希望达到 70%、90%。而要走完这"最后一公里"，实践中几乎总是需要写自定义算子（custom kernels）。我认为这是一个现实：如果你试图教编译器做好优化，工作量巨大——因为编译器可能面对任意输入，你要把针对某一特定情况的优化泛化到一千种不同情况。
Youssef: 嗯。
Reiner: 从工程角度来说，解决一个具体问题显然比解决一千个问题容易得多。所以这个激励机制会推动你去为模型的大部分逻辑编写自定义算子。
Youssef: 嗯。
Reiner: 据我观察，各大 AI 实验室的实际情况就是如此——它们都有大团队在为所用平台编写自定义算子。而且我认为，这样做是值得的——花人力将模型成本压下去，可以带来相当大的收益。所以从我们的角度来看，不如顺势而为。如果你知道客户会写自定义算子，那就不要做一个他们不需要的产品。
Youssef: 对。
Reiner: 不要做一个他们只会用到 10%、其余 90% 用不上的编译器。这对我们也是好事，因为我们不需要花大量时间去开发那个作用有限的编译器。
Youssef: 是的。
Reiner: 这个策略的前提是用户足够专业。如果我们的目标客户是只有十来个工程师的小团队，这套策略完全行不通——他们更需要的是开发效率，而不是极致性能。
Youssef: 嗯。
Reiner: 他们需要的是效率，而不是性能。
Youssef: 是的。我想这个方案遇到阻力的地方可能是研究和训练类的工作负载，对吧？你们暂时不打算覆盖这类场景吗？还是未来有计划支持？毕竟那类场景对灵活性要求很高，把整个模型都写成算子难度不小。
Reiner: 坦率说，目前那不是我们的主要方向。
Youssef: 嗯。
Reiner: 我们不会对实验室说"我们可以承包你 100% 的算力需求"。
Youssef: 嗯。
Reiner: 能占 50%、75% 就很好了。
Youssef: 哈。
Reiner: 那会是一门很好的生意。
Youssef: 是的。
Reiner: 哪怕只有 10% 也不错。这留有足够的空间让你说：研究阶段用那个针对灵活性和生产效率优化的平台，
Youssef: 嗯。
Reiner: ……等到要跑大规模训练（hero runs），或者开始为大规模训练准备、扩展模型，再或者模型训好了要部署，那时候再切换到 MatX 这样的平台。稍微激进一点说，我甚至认为——虽然不是普遍适用——把研究代码库和生产代码库分开是合理的，哪怕两者都跑在 GPU 或谷歌平台上。因为两者要优化的约束条件根本不同。
Youssef: 嗯。
Reiner: 为什么要强迫它们是同一套东西？强迫统一的理由可能是希望从研究到生产的迁移更顺畅——这是一个合理的目标。但另一个同样合理的目标是让研究人员拥有极高的生产效率，不被生产环境那套约束所束缚——毕竟生产环境要追求极高的 MFU 和带宽利用率。所以不要把两种场景过度耦合，这在软件层面成立，
Youssef: 是的。
Reiner: ……在硬件层面更是如此。
Youssef: 对，而且在硬件上来回切换要难得多。这很合理。那具体来说，如果我想在 MatX 芯片上写模型，体验是怎样的？肯定不是 JAX，是 Triton 那样的东西吗？还是更底层？你们会开放 ISA（指令集架构）吗？
Reiner: 对，会开放 ISA，用 Python DSL（领域特定语言）封装起来。
Youssef: 嗯。
Reiner: 这样能给客户他们真正想要的东西——我能看到实际运行的指令，当性能不达预期时可以 debug，知道是什么原因。我们在自己的工作流里也是这样：看指令层面，ALU（算术逻辑单元）有哪些、指令到 ALU 的映射是什么、有没有资源气泡（resource bubbles）。写算子的工程师也会做同样的事，所以充分暴露 ISA 就是在"在用户想要的地方见到他们"。那只是我们能力的最底层。未来的目标，是做出类似 Triton 或 Pallas 的抽象层次——那是一个很不错的抽象高度。OpenAI 和谷歌的团队在这方面做得很好：你不希望抽象层次太高，太高就意味着把本该由你做出的决策交给了编译器，而你本可以做得更好。
Youssef: 嗯。
Reiner: 但同时，你也希望编译器能处理那些对你来说不重要、而计算机可以做得更好的决策。Triton 和 Pallas 在这点上做得很好——用户自己决定 HBM 传输、互联（interconnect）上的数据搬运，以及循环顺序（loop order），这些是最关键的决策，必须手动控制；而 SRAM 的加载/存储和内层循环顺序则交给编译器。这种"选择在哪里划线"的思路是对的。不过对于 TPU 和 GPU 这类 SRAM 带宽或 L1 缓存带宽充裕的芯片，这个抽象层次还是略高了一些，会在性能或芯片面积上留下一些空间。如果想把那部分性能也都榨出来，可能需要再往下降一点抽象层次。
Youssef: 嗯。我们聊了很多 TPU 和谷歌。你在谷歌待了很长时间——具体做了些什么？
Reiner: 我在谷歌待了大约十年。2012 年入职，从网页开发做起，那时候大家都这么起步，我很喜欢这段经历。
Youssef: 你做了 MatX 的网站吗？
Reiner: 我做了早期版本。
Youssef: 哈哈。
Reiner: 那时候很丑，是我做的。让东西好看从来不是我的强项。但 MatX 网站有一个我非常在意的点：我们公司做的是极致效率的芯片，网站也应该体现同样的用心。最初版本的 MatX 网站大概只有 5 到 10 KB，加载极快，没有冗余请求，一个请求全部加载完毕。我在这上面是花了心思的，可能有点偏执，但这正是我喜欢做的事。之后大概五年都在谷歌做这类工作。再后来想转到机器学习团队，就先做了大规模逻辑回归（logistic regression）的软件工作——相当于一个单层神经网络，但那时神经网络革命还没爆发。等革命开始，我转到了一个神经网络芯片团队，那其实是 TPU 的竞争项目，两者有一些共同渊源。Groq 的 Jonathan Ross 在那个项目待了很短时间，随后就出去创办了 Groq。最近的工作是芯片之后转到了 LLM 团队——我在 Brain，参与训练了谷歌的 PaLM，也写了 PaLM 的推理（inference）栈。所以在 LLM 上有过非常深度的实践。
Youssef: 那现在在 MatX……
供应链与产能
Youssef: 你有很多非技术性的工作要处理。
Reiner: 是的。
Youssef: 但当你有时间做技术工作时，你主要把时间花在哪里？
Reiner: 目前，我最深度参与的是 ML 研究和芯片架构两块。MatX 最早期的时候，我也深入参与了一部分软件栈的工作，但后来那部分已经被重新改写，做得比我当时好得多——都是由比我在这方面投入更多、经验更丰富的人来完成的。但我认为，对一家硬件公司来说，与 ML 研究保持非常紧密的联系极其重要。一方面是直接服务于产品——我们整个数值计算栈（numeric stack）就是 ML 研究的直接成果；另一方面，也是为了让我们对模型的发展方向有尽可能准确的预判（crystal ball）。我觉得团队在这方面做的工作既酷又令人兴奋。在架构层面，架构显然是这类公司的核心所在。
Youssef: 是的，没错。
Reiner: 架构工作的范围很广：从宏观层面，比如如何组织一块芯片、如何将芯片上所有核心连接起来，有很多有意思的事情可以做；一直深入到微架构（microarchitecture）层面。举个例子，在协同设计（co-design）方面，你可以这样思考：对于舍入的处理方式，有一个 IEEE 标准叫"就近舍入，中间值取偶"（round to nearest, ties to even）。但这个标准其实是过度设计的。如果你同时关注这个舍入操作对应的电路是什么样的，以及能否通过 ML 建模来证明可以用一个更简单的电路替代，那么微架构与 ML 模型的结合，就是一个非常有吸引力的 co-design 机会。
Youssef: 嗯。说到 co-design，像一些竞争对手——比如 OpenAI 在做自己的芯片，Google 也既做自己的硬件又做自己的模型——作为一家独立于实验室之外的公司，你们是如何针对一个你们并不完全掌握形态的东西来做 co-design，并且还要在竞争中胜出的？
Reiner: 这其实涉及一个更宏观的问题：垂直整合（vertical integration）的优势到底有多大？垂直整合的优势在于，你能获取更多关于自身工作负载的信息；而另一种模式——多个客户向单一芯片厂商购买——则有集中化的优势。从长远来看，哪种模式会胜出，是一个值得思考的问题。
历史上，NVIDIA 是赢家。他们向多个不同买家销售，因此能够将研发资金集中投入到一款产品上；而如果有多个买家各自研发，那些研发资金就会重复花费，效率更低。这反而是一个理由，说明像 MatX 这样的独立公司是有可能成功的——即便面对 OpenAI 自研芯片的竞争。
在短期内，当我们没有这些内部信息时，如何做 co-design？我们只能尽力获取关于模型的信息。2022 年之前相对容易，因为那时大家都会发表模型的详细信息。后来这一趋势停止了，OpenAI 和 Anthropic 大约在 2021 年就停止发布了。现在，除了中国实验室，所有人都停止公开了。所以 open source 作为信息来源仍然相当有用，尤其是 DeepSeek——他们发表了大量非常有参考价值的论文。你也可以和客户交流，但获取的信息有限，因为客户非常珍视自己的 IP。
你能得到一些，然后就需要尽力覆盖可能结果的概率分布——关注分布中间 80% 的部分，忽略两端 10%、20% 的尾部。我们的做法大致如此。具体来说，我们着眼于神经网络所使用的基础原语（primitives）：显然有矩阵乘法、浮点数（floating point）等标准，以及向量运算（vector operations）用于处理各类非线性函数，还有稀疏性（sparsity）相关的操作，以及推理和训练所需的不同路由模式（routing modes）。这套原语作为一个整体，在过去五到十年的神经网络发展中极其稳定。因此，押注在这些原语上，是一个相当安全的出发点——我认为一两年后的模型变化，不太可能超出这套原语的范围。原因在于，这套原语恰好处于"在硬件或物理上高效"与"在梯度下降（gradient descent）中高效"的交叉点上。
在实际 co-design 层面，利用模型知识的一个关键问题就是：各类资源的比例如何分配？这在涉及高成本决策时尤为棘手，比如 interconnect 的配置就是一个成本相当高的决定。而有些地方成本不高，比如排序吞吐量（sorting throughput）配置很便宜，我们可以超额供给。这大体上就是我们的方法论。
落到实处，关于信息优势或劣势——我们认为自己有一个相当准确的预判（crystal ball），这是我们的差异化所在。但外界可能会问：与拥有内部研究人员的实验室相比，你们凭什么能做到这点？坦白说，即使你和那些研究人员交流，他们自己也不知道三年后会发生什么。
Youssef: 哈，是的。
Reiner: 你可以和研究人员聊个尽兴，他们能告诉你他们今天在做什么，但如果你想预测两三年后的情况，你依然需要做出自己的判断。我们认为我们能做好这件事。
Youssef: 嗯。这种预判能力，是从你们在设计芯片过程中所做的数值计算（numerics）和 ML 工作中流淌出来的？
Reiner: 是的，也来自于对神经网络长期发展历史的观察和积累。
Youssef: 嗯，所以你就是那个"水晶球"。
Reiner: 在很大程度上，是的。
Youssef: 哈。
Reiner: 团队里有很多人，我们和 ML 团队有大量的交流，架构团队也与 ML 研究保持非常紧密的联系。综合这些因素，我认为我们已经在这方面做到了最好。
Youssef: 我们之前已经稍微触及到这个话题，不过现在让我们专门聊聊 interconnect（互连）吧。你们的 interconnect 是什么样的？它与现有方案有何不同？它又是如何融入你们在最大化 FLOPS 和尽量简化设计之间所做的权衡取舍的？
Reiner: 好，先从 interconnect 贵在哪里、用来做什么说起。
Youssef: 嗯。
Reiner: 你需要足够的 interconnect，主要是为了跨越某个门槛。这个门槛对基于 HBM 的芯片和基于 SRAM 的芯片是不同的。
对于基于 HBM 的芯片，传统的门槛是：我需要在层内做足够的并行——张量并行（tensor parallelism）或专家并行（expert parallelism）——以将延迟压到某个水平。你需要综合考虑需要多大程度的并行、拥有多少计算吞吐量和 HBM 带宽，再做决策。
而对于基于 SRAM 的芯片，说法稍有不同：我想把模型权重存在 SRAM 里，这意味着在耗尽 SRAM 之前，我只能完成有限的计算，之后就需要切换到下一块芯片。因此，我需要足够的 interconnect，以便在那段极短的时间内完成激活值（activations）的传入和传出。这实际上给出了一个相对清晰的 interconnect 需求门槛——当然还需要结合对模型架构的一些预测。它对模型大小本身并不太敏感，但对模型的其他一些超参数（hyperparameters）是敏感的，所以还是有一定的预测成分在里面。
我们在 interconnect 上的做法是：毫无疑问，配置了大量的 interconnect。这部分在逻辑裸片（logic die）上的成本其实还好。当然，它确实是我们逻辑裸片上的几大主要成本之一——interconnect、SRAM 和计算是三大开销。所以它的比重不低，但也没有失控。线缆和功耗成本方面同样如此——是大头，但也在可控范围内。
有一点比较特别：将权重存放在 SRAM 中有一个额外的好处——它让你可以在使用 interconnect 的同时不消耗 HBM 带宽。这听起来有些出人意料，但我们确实能做到，因此可以将 interconnect 的性能推得比现有竞争对手更高。这里我没有具体说数字或 topology（拓扑结构），但总结一句：我们的 interconnect 非常充裕。
我们也为 interconnect 选择了一个我们认为相当优秀的 topology，它与一些现有的 topology 有所不同。我认为这是我们的创新点之一。在选择 interconnect topology 时需要考量的因素有：首先是主要的集合通信操作（collectives）会是什么；其次是如何将 interconnect 延迟保持在低位；最后是如何实现良好的扩展性。我们与业内其他玩家属于同一大方向，没有什么天马行空的奇特思路，但我们的调优方式，我认为相当出色。
Youssef: 好，说到这里——你们有一块还不存在的芯片，想在上面跑的工作负载也还不存在。所以性能建模（performance modeling）显然非常重要。你对性能建模应该怎么做、你们自己在做什么，有什么见解？
Reiner: 我认为，首先要建立一个基本认知：性能建模在 AI 工作负载的调优优化中，比过去任何时候都重要得多。拿 CPU 上的性能工程师和 GPU/AI 工作负载上的性能工程师做对比：在 AI 工作负载中，我们会谈论"峰值性能利用率百分比"，比如能达到 70%、90%、50%。但"CPU 的峰值性能百分比"是什么意思？你能用尽所有 FLOPS 吗？你能把分支预测器（branch predictor）的性能全部利用起来吗？这根本无从谈起。
所以在优化一个 LLM 时，第一步就是坐下来问自己："我预期的性能是多少？"关于这一点，我记得最早是从 Gaurav Agarwal 那里听到的——他曾在 Google 工作，现在在 OpenAI——他问："做性能建模的目标是什么？"你可能会觉得目标是让性能估算尽可能精确。但这条路没有终点：精确意味着从内存带宽、计算性能这些粗粒度的东西开始建模，然后越来越细，比如指令调度，再往深了还要考虑功耗建模、会不会触发热降频……永无止境。
所以，"在哪里停下来"是一个有趣的根本性问题。答案是：也许你只是在试图回答一个具体的问题。
关于如何近似以更快地得出答案，这是一个永恒的主题。至少对我来说，在学校里学这个是很抵触的——物理课上老师反复说"你应该近似"，而你手里明明有方程可以精确求解，却被要求去近似，感觉在道德审美上难以接受，为什么要把信息丢掉？但当我真正需要快速回答问题、甚至在脑子里快速推演时，才发现近似是完全必要的。
这就引出一个问题：如何判断哪些近似可以做、哪些不能做，背后的原则是什么？我们团队里有一些数学背景很强的人，他们会说："近似？但我想证明一个定理，近似了怎么证？"
这里有一个思路：你不是要证明性能恰好是某个值——那太难了，永远证不完。你可以换一个角度：从"我想证明什么"出发，去给性能确定一个上界——"性能不可能超过这个值"。Roofline 分析（roofline analysis）就是这方面的经典案例，而且这类分析可以在很多不同场景下使用。有时候你也可以反过来证明下界——"性能至少会有这么好"，这更难做到。渐进性能（asymptotic performance）分析也是一种，但它会丢掉太多信息，比如它无法区分 30% MFU 和 90% MFU。所以，"能否证明一个上界"这个思路，我认为是最具可证明性、同时又最实用的思考框架。
当然，这个上界本身有没有用也很重要。如果上界是"性能可能不超过 100%"，那没什么用，因为实际测出来 1% 也算没超过。你还需要思考这个上界的"紧致程度"。比如上界是 50%，实际测出来 30%，那就相当紧致了。如果存在一定的差距，就需要去看实际运行的性能剖析（profile）：哪一个我没有建模的效应影响最大？如果把它加进来……
定价与利润率
Reiner: 在我的建模中，我现在可以说，我的上界不是50%，而是35%。这样一来，它就变得越来越紧。这在某种程度上是一种数学基础，我认为它有扎实的原理可以用来推理。在做性能建模（performance modeling）时，这些始终在我脑海中。当然，我们并不总是将其形式化，因为每次都像证明定理一样太过繁琐了。
Youssef: 嗯。
Reiner: 但这就是你所追求的那种证明方式。有趣的是，如果你想想在其他场景下能证明什么定理，其实有一种分支定界（branch and bound）的思路在里面：我有一个关于芯片设计的搜索空间，然后我会说："好，我可以考虑具有某种特定特性的芯片。"我能否立刻为这类芯片的性能设定一个上界，并说："不管我怎么做，只要做出这一个设计决策，就不可能获得好的性能"？
Youssef: 这就是 HBM vs SRAM 那个问题吧。
Reiner: 对，就是那个例子。确实，在那里你可以做一个证明，看互连跳数（interconnect hops）的数量与容量之间的关系，再通过 Little's law 将容量与批大小（batch size）关联起来，从而证明可利用 FLOPs 的上界。或者，假如我有一个系统，其中两个芯片以完全不同的资源配置相互交互，我能否证明：无论怎么连接它们，这块芯片都会限制那块芯片的性能？
Youssef: 嗯。
Reiner: 所以，我认为这个推导练习的核心，就是先证明下界，然后证明性能的上界可以优于某个值，再从具体实现出发说"我能达到这个水平"，最后审视上下界之间的紧致程度。HBM vs SRAM 是我们做得最扎实的案例之一。从第一性原理来看，这个分析得出的结论是：对于这类工作负载，单纯的 SRAM 是没有吸引力的。你还可以检验关于模型架构的假设，比如"一个模型至少有100层"或"每个 token 至少有多少字节的 KV cache"等，然后探索在不同取值下会落在什么位置。
Youssef: 嗯。能给我们描述一下这个过程在实际中是什么样子吗？是有个大型电子表格在里面填数字，还是在手写证明？这个过程是什么样的？另外，这又是如何融入芯片设计流程的？你们会经历几轮迭代？会有仿真吗？从头到尾，你们怎么最终决定在这个设计空间中选择哪种配置？
Reiner: 我们用了很多大型电子表格。这些表格通常用来表示我们认为可以实现的结果，或者说我们能以高置信度证明"至少能达到这个水平，甚至更好"。大型电子表格、Python 建模脚本、写出指令执行轨迹（instruction traces）——这些都是用来说明"这是可以实现的"。
Youssef: 嗯。
Reiner: 对于上界，我们会尽量减少证明所需的假设，所以这些推导其实相当简短。理想状态是一眼就能看明白——能不能证明一个只涉及三个或五个变量的上界，让我在脑子里就能推算？我们会在这方面做几轮迭代，而且很多工作会在芯片项目的早期就完成。这一过程的目标是尽可能消除上界中的变量，让结论更有力——尤其是能消除模型架构的超参数就更好了。你不希望结论是"这块芯片适用于 d_model 维度为8000的模型，但到16000就不行了"，那样太过局限。
以张量并行（tensor parallelism）为例：正如性能估算相关文献中关于张量并行（tensor parallelism）和专家并行（expert parallelism）所讨论的那样，你往往会得到"每块芯片上矩阵有多大"而非"整体矩阵有多大"的结论。这对于硬件推理其实更友好，因为它直接告诉我 SRAM 应该设计多大。这些早期粗粒度计算覆盖了 HBM、SRAM、互连和 FLOPs。随着项目推进，我们用同样的方法深入细粒度细节，比如排序性能与矩阵性能的比值应该是多少，或者 softmax 与矩阵乘法的性能比应该是多少。在这里，你同样可以进行类似的分析，找出这些比值的约束。
Youssef: 这整个设计流程需要多长时间？也就是在当前设计状态和建模推导之间来回迭代的过程。另外，在这整个设计流程中，哪个步骤耗时最长？是验证，还是写代码、做建模、反复审视假设？
Reiner: 这取决于你希望如何运作这样一个项目。芯片设计有"最小可行产品"的思路，也有更为深思熟虑的设计哲学。我们作为公司更倾向于后者，这在某种程度上有悖于硅谷快速迭代的创业惯例。但这反映了这个市场的现实：芯片流片成本非常高昂，尤其是加上所有下游部署成本之后；同时，我们的竞争对手是 TPUv7 这样的产品，以及非常成熟的 GPU。所以我们选择做一个在多个维度上都足够成熟、足够精密的设计。加上我们在数值计算方式和片上核心互连方式上都做了大量创新，我们在早期架构阶段投入了相当多的时间来调优，并结合我们对模型的认知以及模型的演变动态来不断修正。此后的芯片实现阶段本身也是一个很长的过程。所以一到两年的设计周期对很多团队来说是很常见的。
Youssef: 说到建模，部分问题在于"你在建模什么"。你脑子里想的是某个大语言模型（LLM），但 prefill 和 decode 这两种工作负载差异很大，对吧？
Reiner: 对。
Youssef: 那你们怎么看待这两者之间的分界？我觉得这也从根本上决定了你的芯片是为什么而设计的，以及你在这两者之间怎么权衡？
Reiner: Prefill 和 decode 有什么区别？Prefill 对计算性能（compute performance）要求极高，而对内存带宽的需求相对较低；decode 则正好相反。但我们把它们跑在同一块芯片上——所有人都这么做。NVIDIA 在这方面做过一点点针对性的设计，但基本上还是同一块芯片，改动极小。所以我们面临的约束是：希望两种场景都能在同一硬件上跑好，然而它们的资源需求截然不同。这不可能同时做到最好，肯定有什么地方出了问题。
Youssef: 是的。
Reiner: 而且，不只是硬件层面，从模型训练的方式来看，一切都是为了支持 decode 而设计的。这意味着我可以增量地添加新 token，还有这个因果掩码（causal mask）——因果掩码阻止了双向注意力（bidirectional attention）等机制。decode 的各种约束渗透到了模型训练的方方面面，而这些约束对于 prefill 来说完全无关紧要。我看到这一点，就感觉像是一个警示信号——我们把一些人为的约束引入进来了，这是因为 prefill 和 decode 模型之间存在耦合。
Youssef: 嗯。
Reiner: 那能不能消除这种耦合？我认为这是一个很有意思的问题。这种耦合从何而来？首先，我训练一个模型，将它同时用于 prefill 和 decode；这就意味着 decode 必须能够关注（attend to）prefill 的结果。这个问题有一个历史上的答案：编码器-解码器模型（encoder-decoder models）。我们都听说过，比如 T5 就是这种架构，BERT 是纯编码器（encoder-only）模型，早期的翻译模型也是编码器-解码器结构。这些模型避免了这种耦合，编码器（encoder）和解码器（decoder）可以有相当不同的形态。
Youssef: 嗯。
Reiner: 历史上两者最主要的区别在于编码器使用双向注意力（bidirectional attention）。
Youssef: 嗯。
Reiner: 但在聊天机器人场景中，这种方式实际上行不通，原因有几个。最大的问题是：你对用户的第一轮输入运行编码器，之后的所有内容都必须用 decode 来处理，因为编码器模型根本就不是增量式的。
Youssef: 嗯。
Reiner: 所以在整个对话过程中，只有1%的部分会跑编码器，另外99%都要跑解码器。
Youssef: 嗯。
Reiner: 这正是纯解码器（decoder-only）模型出现并主导这一领域的根本原因。
Youssef: 对。但是，编码器模型一次性接收所有 token，解码器模型每次只处理一个 token，两者之间存在巨大的差距。有没有一种介于两者之间的模型，可以每次处理一批 token，比如每次100个或500个，而不是全部或一个？
Reiner: 这在概念上完全可行。你可以把模型分成两半：前半部分每次处理一批 token，后半部分每次处理一个 token。前半部分称为 prefill 模型，后半部分称为 decode 模型。decode 模型可以通过交叉注意力（cross attention）关注 prefill 模型的输出，方式与编码器-解码器的交叉注意力相同。你可以构造出在任何位置都不违背因果性（causality）的因果掩码（causal mask）。这种架构是可训练的，并且保留了纯解码器训练的所有优势——你可以在序列中的每个 token 上都设置损失函数。
Youssef: 嗯。
Reiner: 这是我们探索过的一个方向，但还比较初步，并不是我们的主要研究方向。不过，如果能解除某些约束，也许就能开辟出新的机会。在视觉 Transformer（vision transformer）领域有非常多有趣的想法——视觉 Transformer 没有因果掩码，它们属于编码器家族而非解码器家族。有大量来自这个领域的有趣想法，因为因果掩码的存在，无法直接应用到纯解码器模型上。
Youssef: 嗯。
Reiner: 比如，专家选择注意力（expert choice attention）就行不通，它会破坏因果掩码。软混合专家（soft mixture of experts）或平滑混合专家（smooth mixture of experts）——比专家选择更为极端的变体——同样可以在这类场景中应用。还有对 token 进行时序下采样的方法，比如漏斗 Transformer（funnel transformer），其思想是"用一个表示来覆盖多个 token，然后将它们合并"，这也会破坏因果掩码，但可以应用于 prefill 模型。我认为这是一个有趣的研究方向，有太多因解码器模型约束而被抛弃的想法，在这里都可能重新焕发生机，值得探索。
Youssef: 是的。在整个对话中让我印象深刻的一点是，我们讨论的范围从模型架构一直延伸到芯片上的微架构（microarchitecture）。构建这样一个芯片项目，似乎需要在整个技术栈的每一层都具备专业知识。我很好奇，你们是怎么考虑招聘和团队建设的，以及随着 MatX 的成长，你们是如何扩张的？
Reiner: 我认为这正是做硬件团队真正令人兴奋的地方。在软件或 ML 团队，你关注的技术栈范围相对更窄。而在硬件公司，我们从 ML 模型一路覆盖到编译器（compiler）——有人在写编译器里的约束求解器（constraint solvers），有人在写 kernel、疯狂优化，这些和你在一个实验室里能做到的事情差不多。但继续往下，我们还做微架构（microarchitecture）——浮点加法器（floating point adder）的电路是什么样的？再往下是物理设计（physical design），以至于机架层面的事情，比如托盘插入机架的插拔力（insertion force）是多少，数据中心的电源功耗是多少，如何避免在数据中心级别出现大的 dI/dT 波动，等等。我做硬件就是因为这个——有更干净的白板，有更广泛的探索空间，是一个更丰富的领域。
在招聘方面，我们招募所有这些不同领域的专家。目前公司大约有100人，其中约三分之二在硬件方向，覆盖我所说的所有领域：逻辑设计（logic design）、物理设计（physical design）、架构（architecture）、设计验证（design verification）、机架系统（rack system）、信号完整性（signal integrity）、电源完整性（power integrity）等。我们还有一支非常强的软件团队，负责 kernel、编译器（compilers）和模拟器（simulators）等，以及一支出色的 ML 团队做我们所讨论的这类 ML 研究。要成为一家成功的公司，我们还需要大幅扩张，我们在所有方向上都热切希望招募更多优秀人才。
Youssef: 在未来一年，你对 MatX 最期待的是什么？
Reiner: 我们有大量工作要做，我觉得会很有意思。第一代芯片的量产爬坡将会是——我们听到的目标规模真的非常大。同时，下一代芯片的研发工作也让我非常期待。如何在不浪费任何潜力的前提下，让芯片真正运行出色，始终是一道有趣的难题。我认为有大量真正令人着迷的问题等待我们去攻克。
Youssef: 太令人期待了，非常期待看到接下来会发生什么。
Reiner: 我也是。
Youssef: 太好了。这次对话非常愉快，谢谢！