推理芯片之战：Groq、Cerebras 与 OpenAI 三条路线，到底在比什么？
大模型的竞争正在从“谁能训练出更大的模型”，扩展到“谁能以更低的延迟、更低的成本和更少的电力，把每一个 Token 送到用户面前”。当推理请求变多，芯片不再只是模型背后的基础设施，而会直接决定产品的速度、价格和体验。
这篇文章整理自硅谷 101 播客 E251《推理芯片之战：聊聊 Groq、Cerebras 与 OpenAI 三大路径与 Bill Dally 的设计哲学》。文章保留节目中的问题意识和技术脉络，补充必要的概念解释，方便暂时不方便观看整期视频的读者快速理解。
本次整理使用视频页面公开简介和章节信息作为结构骨架。由于 YouTube 的字幕接口触发了访问验证，本文不伪造逐字稿；涉及嘉宾的具体论述，均按章节主题做结构化转述，并在可能产生误读的地方保留事实边界。
节目简介以英伟达对 Groq 的 acqui-hire、Cerebras 上市，以及 OpenAI 与博通推进自研推理芯片 Jalapeño 作为讨论背景。这里需要先划清边界：下文是对节目和嘉宾观点的结构化整理，不把节目中的交易结构、估值、产品状态或未来预测改写成独立事实。涉及公司公告、市场数据和芯片型号的信息，应再以对应公司的公告、监管披露和后续报道复核。
一张图看懂：推理到底在搬什么
下面的动画把一条请求拆成 Prefill、KV Cache 和 Decode 三段，同时把 SRAM、HBM、DRAM 与三类芯片路线放到同一张图上。图中流动的光点代表 Token 和中间数据，重点观察 Decode 阶段为什么会反复访问内存。
先说结论：推理芯片比的不是一个峰值算力
整期节目的核心可以压缩成四句话：
- 训练阶段通常更像大规模并行计算问题，推理阶段尤其是 Decode 更像带宽和数据移动问题。
- SRAM、DRAM、HBM 没有绝对的优劣，真正的取舍是容量、带宽、延迟、成本、功耗和软件适配。
- Groq、Cerebras 和 GPU 代表不同的工程路线，差异来自它们主动选择牺牲了什么。
- 下一代推理系统很可能不是单一芯片取胜，而是模型、编译器、内存、互连和芯片一起协同设计。
因此，看到“某芯片比 GPU 快很多”时，不能只问峰值 TOPS 或单次 Demo 的 Token/s，还要继续问：
- 测试的是 Prefill 还是 Decode？
- 输入长度、输出长度和 batch size 是多少？
- 是否把数据搬运、通信、编译和调度时间算进去？
- 使用了什么量化、并行方式、模型版本和软件栈？
- 速度提升是否换来了更高的成本、功耗或部署复杂度？
视频内容索引
| 时间 | 主题 | 这一段解决的问题 |
|---|---|---|
| 04:17 | 为什么训练看算力，推理看带宽 | 解释 Prefill 与 Decode 的工作负载差异 |
| 14:13 | SRAM、DRAM、HBM 的优劣 | 解释容量、延迟、带宽和功耗的基本取舍 |
| 16:39 | Groq 与 Cerebras 的路径选择 | 对比确定性加速和晶圆级大芯片 |
| 19:34 | Groq 的静态编译与调度 | 说明可预测延迟的优势，以及动态性不足的代价 |
| 25:18 | Cerebras 的软肋 | 讨论良率、成本和系统适配问题 |
| 39:19 | SRAM 推理芯片方案 | 解释把数据留在片上能换来什么 |
| 49:04 | 面对模型迭代如何抓住不变量 | 讨论硬件设计如何避免被单个模型绑死 |
| 58:27 | 芯片设计全流程 | 从需求、架构到流片、良率和交付 |
| 01:05:17 | Bill Dally 的设计哲学 | 从局部性和取舍理解芯片创新 |
| 01:17:30 | OpenAI 自研推理芯片解析 | 讨论通用芯片、HBM 和片上异构路线 |
1. Prefill 与 Decode：为什么推理不只是“算力不够”
Prefill 更接近并行计算
用户提交一段 Prompt 后，模型首先需要把整段输入读进来，计算每个位置之间的关系，并建立后续生成所需的中间状态。这个阶段通常可以把较多矩阵运算并行展开，因此更容易吃满计算单元。
可以把 Prefill 想象成一次性处理一整箱原料：只要数据排列得好，计算单元可以同时工作，吞吐量通常比较重要。
Decode 更接近带宽和延迟问题
进入生成阶段后，模型往往一次只产生一个或少量 Token。每生成一个新 Token，都需要读取已有的权重和 KV Cache，再进行一轮计算，最后把新状态写回去。计算并没有消失，但大量时间可能花在等待数据到达，而不是等待乘法器完成运算。
这就是节目里“训练看算力，推理看带宽”这句话的技术背景。更准确地说，它不是一个适用于所有模型和所有推理阶段的绝对定律，而是提醒我们：Decode 的瓶颈经常从计算吞吐转移到内存带宽、访问延迟和数据搬运。
速度为什么会影响“聪明程度”
节目中有一个很有启发性的判断：速度越快，AI 看起来越聪明。它不是说芯片会改变模型参数，而是说低延迟会改变产品形态：
- 用户更愿意进行多轮追问；
- Agent 可以执行更多次工具调用和检索；
- 语音交互不容易出现明显停顿；
- 系统可以在相同时间内尝试更多候选路径；
- 产品可以把更长的上下文和更复杂的工作流放进交互中。
所以“智能体验”是模型能力、推理速度、上下文长度和交互设计的乘积，而不是单独由参数量决定。
2. SRAM、DRAM、HBM：所有路线都在争夺局部性
芯片设计中，一个重要问题是：数据离计算单元有多远，以及它需要被搬运多少次。
| 存储 | 典型位置 | 优势 | 代价 |
|---|---|---|---|
| SRAM | 片上缓存或本地存储 | 延迟低、访问稳定、适合高频复用 | 面积和成本高，容量有限 |
| HBM | 与加速器紧邻的高带宽内存 | 带宽高、容量比片上 SRAM 大 | 封装复杂、功耗和成本高，仍然存在片外访问 |
| DRAM | 系统级主存 | 容量大、供应链成熟 | 延迟更高，数据移动距离更远 |
把权重或 KV Cache 放进 SRAM，可以减少长距离搬运，提升局部性，但片上容量很快会成为约束。HBM 试图在容量和带宽之间取得平衡，却不能消除所有内存访问成本。DRAM 提供更大的容量，却可能让 Decode 阶段在等待数据上花掉更多时间。
节目讨论的重点不是“以后只用 SRAM”，而是：哪些数据值得留在离计算最近的地方，哪些数据可以接受更远的访问，编译器能否让数据复用真正发生。
3. 三条路线：GPU、确定性加速器与晶圆级大芯片
路线一：GPU 加高带宽内存
GPU 路线的核心优势是通用性、成熟的软件生态和较强的模型适配能力。它可以承载不同模型、不同算子和不断变化的推理框架，开发者也更容易复用既有工具链。
它的代价是系统很复杂。计算单元、缓存、HBM、主机内存、网络互连和调度器之间需要协调，很多时候峰值算力没有完全转化成有效 Token 生成速度。模型越动态、batch 越小、请求越碎片化，硬件利用率就越容易下降。
路线二：Groq 的确定性与静态调度
节目把 Groq 的路线概括为：用编译器提前决定数据和指令如何在芯片中流动，把运行时的不确定性尽量移到编译阶段。这样做的好处是延迟更容易预测，数据路径和资源分配也更清晰。
确定性路线尤其适合对响应速度和抖动敏感的场景。用户不只关心平均速度，也关心最慢的那一小部分请求是否突然变慢。
这条路线的代价同样明确：模型结构、算子组合和请求形态越动态，静态规划越难维护。编译器需要快速跟上模型变化，硬件也需要在可预测性和灵活性之间找到平衡。静态调度不是免费获得的性能，而是把更多复杂度交给编译器、模型约束和部署流程。
路线三：Cerebras 的晶圆级大芯片
晶圆级路线的思路是把大量计算和片上通信资源放到一块更大的硅片上，减少跨芯片、跨板卡和跨系统的数据移动。对需要高频交换中间结果的模型来说，片上局部性和互连距离可能带来明显优势。
但芯片面积越大，制造、良率、封装、散热、供电和系统适配的挑战也越集中。大芯片不是把小芯片简单放大，任何局部缺陷、互连问题或软件映射问题，都可能影响整个系统的成本和交付。
节目对 Cerebras 的讨论提醒了一个常被忽略的事实：架构上的优势，必须通过制造、封装、软件和客户部署转化成可交付的系统。
4. 真正的比较维度：速度、性价比和耗电量
芯片创业者不应该只用一个数字证明路线正确。节目把最重要的指标归纳为三项：速度、性价比和耗电量。
速度不是只有平均 Token/s
至少要拆成：
- 首 Token 延迟，也就是用户开始看到回答前等多久；
- Decode 速度，也就是后续 Token 生成有多快；
- p50、p95 或 p99 延迟，观察长尾是否稳定；
- 单请求、批量请求和多租户混合请求下的表现；
- 模型上下文变长后，速度如何变化。
性价比要落到每个有效结果
设备采购价只是成本的一部分。还需要考虑：
- 每个机架能放多少卡或多少系统；
- 电力和散热设施需要投入多少；
- 模型迁移、编译和调优需要多少工程人力；
- 软件栈是否能复用现有的监控、调度和故障恢复系统；
- 设备闲置或模型切换时，资源是否会被浪费。
最终更有意义的指标通常是“在给定延迟目标下，每美元、每瓦能够生成多少有效输出”，而不是一张脱离工作负载的峰值表。
5. 为什么芯片利用率经常跑不满
“芯片算力没有消失，但消失在系统里”是节目中很值得展开的观点。常见原因包括：
- 内存等待：计算单元空闲，数据还没有从 HBM 或 DRAM 到达。
- 通信等待：多卡或多芯片之间需要同步，最快的计算单元也要等最慢的链路。
- 调度开销：请求大小和到达时间不一致，静态批处理难以持续填满计算阵列。
- 算子不匹配：模型中存在小算子、稀疏路径或特殊操作，无法映射到高吞吐单元。
- 上下文变化：输入和输出长度不断变化，缓存和内存布局难以长期稳定。
- 软件栈损耗：框架、编译器、驱动、运行时和监控层层叠加，理论路径没有变成实际路径。
因此，提升利用率不能只靠再增加计算单元。更有效的方法可能是优化数据布局、缓存策略、编译调度、请求合并、模型量化和互连拓扑。
6. 面对模型迭代，硬件应该抓住什么“不变量”
模型会快速变化，芯片却需要较长的设计、验证、流片和交付周期。硬件团队不能押注某一个短期流行模型，否则产品可能还没有量产，目标工作负载就已经改变。
节目提出的思路是寻找“不变量”，例如：
- Transformer 或类似模型长期存在的矩阵计算结构；
- 权重和 KV Cache 需要反复访问的事实；
- 推理对延迟、带宽、功耗和成本的共同约束；
- 模型服务必须经过编译、调度、监控和故障恢复；
- 数据局部性和通信距离始终影响有效性能。
抓住这些不变量，硬件可以保留通用接口和可编程空间，再用专用单元加速最稳定的热点。这样比为单一模型做极端优化更容易穿越模型迭代周期。
7. 芯片设计不是画完架构图就结束
节目把芯片创业拆成一条很长的交付链：
需求
→ 架构
→ 微架构
→ RTL
→ 功能验证
→ 后端实现
→ 流片
→ 封装与测试
→ 良率爬坡
→ 系统适配
→ 客户交付
每一阶段都可能推翻前一阶段的假设。
- 需求阶段要确认客户真正购买的是延迟、吞吐、成本还是能耗。
- 架构阶段要明确哪些数据留在片上，哪些数据跨芯片移动。
- RTL 和验证阶段要证明设计在边界条件下仍然正确。
- 后端阶段要处理时序、面积、功耗、供电和散热。
- 流片之后还要面对封装、测试、良率和批量交付。
- 最终产品还必须接入模型、编译器、驱动、调度系统和客户运维环境。
这也是为什么 AI 芯片创业通常不是“做出一个更快的加速器”这么简单，而是同时在做半导体公司、系统公司和软件平台。
8. Bill Dally 的设计哲学：一切围绕局部性展开
节目借由嘉宾 Mark 与 Bill Dally 的师生关系，讨论了几条更普遍的芯片设计原则。
局部性优先
数据移动往往比计算本身更贵。能在本地完成的事情，不要跨更远的层级；能复用的数据，不要重复从外部读取；能在编译阶段确定的路径，不要全部留给运行时临时决定。
这不是说所有计算都应该堆到片上，而是要先理解访问模式，再决定缓存、内存和互连如何分层。
跳出局部最优，必须先想清楚牺牲什么
工程设计很容易在局部指标上优化：更高频率、更大缓存、更多计算单元、更宽总线。但每个选择都会带来面积、功耗、成本、验证复杂度或软件迁移的代价。
真正的架构创新，往往不是让所有指标同时变好，而是明确选择一个最重要的目标，然后主动放弃一部分通用性、容量、灵活性或短期收益。
为未来补齐强逻辑
如果一个功能长期存在、对性能影响很大、又很难只靠软件解决，就值得考虑把它做成硬件强逻辑。相反，如果功能仍在快速变化，过早固化可能让芯片失去生命力。
这和前面“不变量”的判断是一致的：硬件要固定最稳定的瓶颈，把变化最快的部分留给编译器和软件。
9. OpenAI 自研推理芯片：节目讨论的另一种方向
节目后半段把 OpenAI 与博通推进的 Jalapeño 作为案例，讨论通用芯片、低能耗、HBM4、片上异构和“暗硅”等概念。这里不展开确认其具体产品规格，而只提炼节目中真正有价值的设计问题。
通用性与能效如何平衡
完全通用的芯片可以适配更多模型，但往往承担更多控制、缓存和数据移动开销。完全专用的芯片可能在固定工作负载上更高效，却容易被模型迭代淘汰。
因此，一种现实路径是：保留足够的通用计算和编程能力，再为长期稳定的推理热点提供专用数据路径、片上缓存或低精度计算单元。
“不缺钱，但缺电”
节目用这句话概括推理基础设施的约束：资本可以帮助采购设备，电力、机房、散热、网络和部署周期却不能被简单购买掉。
这会把芯片评价从单卡性能推向系统级能效：在同样的电力和机房条件下，系统能够服务多少请求，长尾延迟是否可控，模型切换时是否仍然有效。
暗硅与片上异构
当芯片面积和功耗预算有限时，不可能让所有单元同时满负载运行。部分电路需要在特定阶段关闭或降频，把功耗预算留给当前最重要的计算路径，这就是节目讨论“暗硅”时的基本背景。
片上异构的价值在于让不同类型的工作负载由更适合的单元处理，例如通用控制、矩阵计算、数据搬运、压缩解压或安全检查分别由不同模块承担。难点是调度和编程模型会变得更复杂。
10. 国内做 AI 芯片的机会与挑战
节目提到，国内的优势可能来自供应链、基础设施和开源生态。这个判断需要拆开看。
机会包括：
- 能够围绕本地客户需求快速迭代部署方案；
- 供应链和系统集成能力可以缩短部分交付路径；
- 开源模型和框架降低了验证新芯片的门槛；
- 推理服务需求增长，为专用场景提供真实工作负载。
挑战同样明显：
- 芯片不是孤立硬件，编译器、驱动、框架和模型适配必须一起成熟；
- 客户更换硬件需要承担迁移和运维风险；
- 没有稳定的批量工作负载，性能优势可能只停留在 Demo；
- 良率、封装、供电、散热和交付能力会直接影响商业化；
- 模型不断变化，专用优化必须保留足够的可编程空间。
创业者真正要和模型厂商竞争的，不是“我也能做一个芯片”，而是能否把客户的有效 Token 成本、延迟和部署风险同时降下来。
11. 读懂一张 AI 芯片性能表
以后看到芯片发布会、Benchmark 或投资材料，可以用下面这张清单快速审查：
工作负载
- 是训练、Prefill、Decode，还是完整端到端推理？
- 模型版本、参数规模、上下文长度和量化方式是什么？
- 单用户、固定 batch 还是多租户混合流量？
指标口径
- 报告的是峰值算力、平均吞吐、首 Token 延迟，还是 p99 延迟？
- 是否把编译、加载、通信、数据预处理和后处理算进去？
- 是否报告每 Token、每请求和每有效输出的能耗与成本？
系统完整性
- 芯片能否接入现有模型和框架？
- 编译器和算子覆盖率如何？
- 发生故障、模型切换或流量突增时，系统能否恢复？
- 结果是否来自可复现的脚本和公开配置？
商业交付
- 设备是否已经量产，还是仍处于样片、演示或早期客户阶段？
- 供应链、封装、良率、机架部署和售后是否准备好？
- 性能优势是否足以覆盖迁移、调优和运维成本？
只要其中几项没有答案，就不应该把一张漂亮的数字表直接等同于生产优势。
最后：推理芯片的终局可能是系统协同
Groq 的确定性路线、Cerebras 的晶圆级路线和 GPU 加 HBM 的通用路线，看起来是在竞争，实际上都在回答同一个问题：如何让数据更快、更近、更稳定地到达计算单元。
未来的胜负手可能不在于某一家做出“万能芯片”，而在于谁能把以下几层组合得更好：
模型结构
+ 编译器与运行时
+ 片上存储与 HBM
+ 芯片间互连
+ 调度与服务系统
+ 功耗、散热与机房
+ 客户真实工作负载
对使用 AI 产品的人来说，最值得关注的不是芯片名字越来越多，而是每一轮模型升级之后，单位成本能否继续下降，响应是否更稳定，Agent 是否能在同样的电力预算里完成更多工作。
对做芯片的人来说，最重要的能力也许不是押中某个短期热点，而是找到不会轻易消失的瓶颈，明确愿意牺牲什么，并把架构、软件和交付一起做成可验证的系统。
原始视频
- 硅谷 101 E251：推理芯片之战：聊聊 Groq、Cerebras 与 OpenAI 三大路径与 Bill Dally 的设计哲学
- 来源频道：硅谷 101 播客
- 视频公开章节：以 YouTube 页面当前展示的章节和时间戳为准
本文为视频内容整理与技术解释，不是逐字稿，也不替代公司公告、监管披露或芯片厂商的可复现实测数据。