五度妙笔
企业透视镜
API商城
数据库OpenAI 自研芯片跑赢英伟达，一文看懂它强在哪
在 SemiAnalysis 最新文章中，作者详细拆解了 OpenAI 自研推理芯片 Jalapeño 的性能、架构、软件栈和系统部署方式。
SemiAnalysis 媒体获得了 OpenAI 提供的测试数据，亲自前往实验室，使用自有的 InferenceX 测试套件对 Jalapeño 的运行情况进行了现场验证。测试结果显示，Jalapeño 在多个开源模型上击败英伟达、AMD 和谷歌的同类芯片，每兆瓦吞吐量超过 Blackwell，甚至在部分指标上领先采用 HBM4 的 Vera Rubin。OpenAI 并没有把它做成只适配自家模型的专用芯片，而是通过通用架构、HBM4、高带宽互连，以及 Codex 驱动的软件适配，打造了一款面向不同模型和工作负载的推理 ASIC。
文章还进一步分析了 Jalapeño 为什么不采用预填充与解码分离、Gluon 和 Codex 如何帮助编写芯片内核，以及 128 颗芯片如何组成一个机架、最终扩展到 2048 个 XPU。
本文编译自 SemiAnalysis 文章《OpenAI Jalapeño: Better Than Nvidia Blackwell》，原文链接https://newsletter.semianalysis.com/p/openai-jalapeno-better-than-nvidia，以下是为编译。
OpenAI 过去几年一直在低调打造一款名为“Jalapeño”的推理芯片，并在 Hot Chips 大会上正式宣布了这款产品。此前，外界已经流传了一段时间关于 Jalapeño 成功流片的消息。但直到现在，我们才真正获得了详细信息。
OpenAI 邀请我们参观这款芯片，前往其实验室确认 Jalapeño 的实际情况，并使用 SemiAnalysis 的 InferenceX 测试套件对它进行基准测试。
今年 6 月，OpenAI 宣布与博通合作启动这项芯片计划。Jalapeño 从一张白纸开始设计，完全针对大语言模型推理场景打造。设计工作始于 2024 年年中，从最初组建团队到完成制造流片，整个过程只用了大约 16 个月，属于极其迅速的 ASIC 开发周期。
一般来说，第一代芯片很难具备竞争力。但 OpenAI 打破了这一规律：在我们能够测试的多个顶级开源模型上，Jalapeño 都处于行业领先水平，击败了英伟达、AMD 和谷歌的所有芯片。
OpenAI 依靠的是极致的软硬件协同设计。更令人意外的是，Jalapeño 并没有针对模型推理中的某一个特定环节进行过度专用化，而是被设计成一款通用芯片，力求在所有场景下都提供高性能。
本文将详细分析 Jalapeño 的架构、软件以及它在 InferenceX 上取得的性能结果。
一颗通用推理芯片
人人都说 OpenAI 的芯片是为自家模型专门定制的，但这是错的——OpenAI 做的是一颗面向 AI 推理的通用芯片。它的研发时间线堪称疯狂，也证明"用 AI 来加速芯片设计"的说法是真的。当然，除了进度快之外，OpenAI 砸了大钱、做了务实的设计决策，团队实力也超强，所以有这样的结果并不令人意外。
光看规格，它立刻就是一个有力的竞争者：
HBM4 的采用，更让它足以与英伟达和 AMD 的旗舰 GPU 相提并论：
许多媒体在报道这款芯片时，引用了 OpenAI 的一些零散表述，认为 Jalapeño 将以其他芯片做不到的方式针对 OpenAI 模型进行优化。这是错的。Jalapeño 是一款通用型推理芯片，能够运行各种模型和各种类型的工作负载，包括我们的 InferenceX 基准测试。我们是在 OpenAI 实验室中与其工程师一起完成这项测试的。OpenAI 甚至开玩笑地给我们演示了在这颗芯片上跑《毁灭战士》（Doom）——仅仅是靠 Codex 的提示词就把它移植了过来。
下面是本文最核心的每瓦性能结果。我们考察的是每兆瓦全系统功耗对应的令牌吞吐量。Jalapeño 击败了其他所有芯片。而且，Jalapeño 在没有使用多令牌预测，也就是 MTP 的情况下取得了这一结果。图表中的其他芯片则都使用了各自型号表现最好的配置，并且全部启用了 MTP。
在几乎所有场景下，Jalapeño 的每瓦性能都击败 Blackwell，而且并没有针对曲线上任何特定点做调优。它不仅在低延迟场景表现出色，在高吞吐场景同样如此。如果采用单令牌预测，也就是 STP，进行更公平的比较，那么 Jalapeño 更是把所有竞争对手远远甩在身后。在低并发场景下，Jalapeño 展现出了非常出色的交互能力。以 DeepSeek R1 为例，在并发数为 1 的情况下，它可以达到每位用户每秒超过 700 个令牌的速度。更令人难以置信的是，这些结果全部基于单令牌预测取得，没有使用推测解码，也没有采用预填充—解码分离。
除了 DeepSeek R1，我们还看到了其他模型的运行结果，包括 Kimi-K2.5 和 GPT-OSS。它们的速度约为每位用户每秒 1400 个令牌。对于所有模型，我们都确认 Jalapeño 在 GSM8K 评测中的结果与英伟达芯片基本相当。当然，这些结果有几个需要注意的地方。首先，所有数据都是由 OpenAI 提供的。我们亲自前往实验室验证了 InferenceX 的运行过程，但没有完整运行 InferenceX 的全部测试，也没有看到 AgentX 的结果。由于 AgentX 使用长上下文和多轮交互数据，能够反映真实生产工作流中的缓存行为，因此相比 InferenceX，AgentX 是我们更偏爱的芯片性能比较套件。某些框架在 8K 输入、1K 输出的测试中表现良好，但在 AgentX 上可能表现更差。原因在于，真实生产负载会给路由器、前缀缓存机制、缓存管理和卸载基础设施等组件带来压力，而单轮 8K1K 测试无法覆盖这些问题。
第二，我们认为，拿 Jalapeño 与 Blackwell 进行比较并不完整，也不完全公平。Jalapeño 真正面对的竞争对手应该是同样使用 HBM4 的 Rubin。Vera Rubin 系统已经开始向客户交付，而 OpenAI 目前距离拥有 Jalapeño 的量产产品还有一段时间。因此，性能更应该拿 Jalapeño 与 Rubin 比较，而不是 Blackwell。从某种意义上说，我们本来就预计一款定制芯片能够超过 Blackwell。正如我们上个月在分析英伟达与 CoreWeave 发布的性能数据时所指出的，Vera Rubin NVL72 的每兆瓦性能是 GB200 NVL72 的 5.4 倍。我们会在后文把 Jalapeño 与 Vera Rubin 今年 7 月公布的性能数据进行比较。
第三，目前测试的模型还不是开放模型领域最前沿的模型。英伟达和 AMD 已经通过 AgentX 公布了更大模型的测试结果，例如 DeepSeek V4 Pro 和 Kimi K3。模型越大、发布时间越新，将它移植到一款新芯片上就越复杂。不过，OpenAI 已经成功运行在 Jalapeño 上的模型也并不算小。
性能分析
OpenAI 设计 Jalapeño 时，核心目标是每瓦性能。原因很简单：OpenAI 当前受到限制的是数据中心电力，而不是预算或机房面积。因此，每兆瓦能够生成多少令牌至关重要。在 Computex 2026 大会上，英伟达 CEO Jensen Huang 表示，未来 GPU 的核心特征将是每瓦性能、可靠性和较长使用寿命。他说：“如果你拥有 1 吉瓦电力，那么吞吐量就是收入。”他还表示，仅仅因为芯片更便宜就选择错误的架构，是没有意义的。
英伟达在 Hot Chips 2026 大会介绍 Vera 时，也展示了同一张收入曲线，并强调了相同观点：“如今，数据中心受到电力限制。”
电力会直接影响收入。运营商不能简单地通过增加 GPU 来获得更多兆瓦，因为增加 GPU 与扩充电网容量所需的时间完全不同。数据中心的电力上限受到多个因素限制，包括公用事业接入、基础设施、冷却能力，以及 UPS 和备用发电系统的设计。
电网建设的延迟一次又一次超过了硬件采购和数据中心建设周期，因此，数据中心越来越需要采用 BtM，也就是“表后电力”。所谓表后电力，是指在数据中心内部建设并部署燃气轮机和现场发电机。这些电力设备位于公用电表之后，而不是直接从公共电网取电。这种方式可以让运营商无需等待电网接入和公用事业升级，就为数据中心供电。这正是 xAI 的 Colossus 2 高度依赖表后电力的原因：它实际接入电网的进度远远落后于数据中心建设。
正如我们在 X 平台的一篇帖子中所写的，每秒每兆瓦 token 数可以化简为"每焦耳 token 数"，因为 1 瓦就是每秒 1 焦耳。这使得每秒每兆瓦 token 数能够代表一个系统的效率，以及它将能量转化为 token 的能力。
在这方面，即使与 Rubin 相比，Jalapeño 依然胜出。OpenAI Jalapeño 的单 token 预测（STP）输出 token 每兆瓦吞吐量，超过了英伟达和 CoreWeave 7 月公布的 Vera Rubin 多 token 预测（MTP）成绩，也远超 GB200 的 2025 年 MTP 成绩。正如我们在 Vera Rubin 文章中所说，VR 当时是与 2025 年的 GB200 成绩对比的，因为两者处于相似的早期适配阶段，与 2025 年的 GB200 对比可以保持软件成熟度一致。按照同样的逻辑，我们在此对比 Vera Rubin 2026 年 7 月的最新成绩、GB200 的 2025 年成绩，以及今天的 Jalapeño 成绩。这是一个非常合理的对比，因为这些都是公开可查的 Rubin 最佳数据，而且 OpenAI 的流片时间晚于 Rubin。OpenAI 和 Rubin 双方都尚未成熟，因此性能还会继续提升。
在每瓦性能和总拥有成本方面，Vera Rubin 与 Jalapeño 几乎势均力敌，两者每美元产生的输出令牌数量基本相同。不过，前面已经提到，Jalapeño 的结果是在没有使用推测解码的情况下取得的，而 Vera Rubin 的结果使用了推测解码。推测解码可以将每个令牌的成本降低约 3 至 5 倍。如果未来 Jalapeño 也实现推测解码，它的令牌服务成本还会进一步下降。当然，这部分总拥有成本优势来自一个明显因素：Jalapeño 使用的是博通的芯片，利润率低于英伟达，尽管博通的利润率依然很高。但这并不是全部原因。例如，Meta 和微软都已经投入了更长时间开发人工智能 ASIC，却仍然没有真正将项目推向成熟。这说明，成本只是问题的一部分。
在架构上，OpenAI 选择不将预填充和解码拆分到不同的芯片池（即不做 PD 分离）。草稿模型和主模型共享同一批芯片和同一片互联网络，这种设计理念牺牲了一部分理论效率，换取了更强的实际运营能力。原因在于，工作负载组合会随着时间发生变化。例如，输入令牌、缓存写入、缓存读取和输出令牌之间的比例，已经随着模型经历知识型、推理型和智能体型三个阶段而发生了明显变化。因此，如果一开始就固定配置一部分异构的预填充芯片和解码芯片，随着时间推移，系统很可能变得低效。OpenAI 在这套架构中选择了一个同质化芯片池，试图让同一款芯片在所有任务上都表现良好。
它确实做到了。在 Kimi K2.5（Cursor Composer 2.5 所基于的模型）上，Jalapeño 达到了每用户每秒近 700 token；在每用户每秒 100 token 的档位上，性能是次优芯片的 9 倍以上。
GPT-OSS 的结果同样非常夸张。在相同交互性下，Jalapeño 每兆瓦的吞吐量接近 GB200 最高吞吐点的两倍，是 GB200 并发数为 1 时吞吐量的 50 多倍。Jalapeño 在更高并发下的测试点使用了 EP8。
这些结果确实令人印象深刻。不过，我们还是必须挑出一些问题：这些测试都只是 8K1K，属于更容易进行调优的工作负载，而且目前还没有 AgentX 测试结果。正如我们在 AgentX 文章中提到的，多轮、长上下文工作负载会给服务系统的更多部分带来压力，包括路由器和前缀缓存。要在智能体工作负载上取得出色表现，还需要进行更多优化。
深入规格与架构
以上所有结果都来自 Jalapeño 的 A0 版本，而此时距离项目启动仅过去了 9 个月。不过，目前 B0 版本也已经进入晶圆厂生产。B0 版本通过多项优化，相比此前的 A0 芯片，每瓦性能提升了约 25%。具体来说，B0 版本在一块采用台积电 N3P 工艺、尺寸达到光罩极限的计算裸片上，可以提供 13.4 PFLOPs 的 MXFP4 性能。
作为对比，尺寸相近、同样采用这一节点的 Rubin 单计算裸片，可以提供 17.5 PFLOPs 的密集型 NVFP4 性能。考虑到 Jalapeño 的 TDP 只有 700 瓦，而 Rubin 每块计算裸片的 TDP 为 900 至 1150 瓦，这个结果就更值得肯定。由于 Jalapeño 面向推理而不是训练，OpenAI 没有必要通过提高 TDP 来最大化 FLOPs，这一点可以理解。但无论如何，以上数据说明 Jalapeño 的理论峰值 FLOPs 仍然相当可观。与其他加速器直接比较时，Jalapeño 拥有最高的每瓦 HBM 带宽和每瓦 FLOPs，其水平接近功耗达到 1800 瓦的 Rubin Max-Q 配置。
芯片封装外部的 I/O 由一块采用 N3E 工艺制造的 I/O 小芯片提供。它配备 32 条 800G SerDes 通道，用于连接计算网络。其中：
24 条通道，也就是 600GB/s，用于机架内部的本地扩展；
8 条通道，也就是 200GB/s，用于全局扩展，连接一个由 2048 个 XPU 组成的多机架域。
系统 I/O 则采用 PCIe Gen 5，用于连接 x86 主机 CPU。Jalapeño 将搭载 HBM4，因此它会成为继英伟达和 AMD 之后较早采用 HBM4 的芯片之一，甚至领先于已经成熟的 TPU 和 Trainium 项目。Jalapeño 的关键架构原则之一，就是尽可能充分利用 HBM 带宽。因此，如果不采用最先进的 HBM，就会与这一目标相悖。每个封装可以提供 15.4TB/s 的内存带宽，超过目前所有采用 HBM3E、正在出货的其他加速器。15.4TB/s 的带宽意味着，Jalapeño 使用的 HBM 可以达到 10Gbps 的引脚速率，这会略高于英伟达 Rubin 中 HBM4 的 9.6Gbps。这批 HBM 很可能由三星提供。
OpenAI 于 2025 年 11 月完成 Jalapeño 的流片——更确切地说，这是 CoWoS 封装设计的流片，而不仅仅是顶部裸片硅片。在 2025 年 11 月流片之后的 9 个月内、实际硅片点亮仅 3 个月，OpenAI 就已经用 Jalapeño 交出了非常好的成绩。尤其令人印象深刻的是，这个团队的软件栈是从零起步的。
与此同时，Rubin 的 CoWoS 流片完成于 2025 年 10 月，还早了一个月，但我们看到的早期结果只有来自 CoreWeave 的工程样品。英伟达没有像 OpenAI 那样让我们测试并发布基准数据，这表明他们的芯片软件仍不成熟。考虑到 OpenAI 能在自家硅片上如此快地适配新模型，CUDA 护城河可能已经名存实亡。
双方都远未优化到位，而我们可以看到 Jalapeño 总体上交出了更好的数字。我们并不认为英伟达的硬件更差，更可能是 Jalapeño 的软件适配进度比英伟达更快。这体现了软硬件协同设计的力量——这正是顶尖前沿实验室的 ASIC 团队能够胜过老牌商用芯片厂商的主要战场。反直觉的是，从零开始可能反而让 OpenAI 受益：它可以在白纸上做架构决策，无需担心向后兼容或旧版软件。
虽然 OpenAI 目前只有 Jalapeño 的工程样品，但量产目前计划在 2027 年内逐步爬坡，大部分产能目前排在明年年底。关于出货量和单价的更多细节，请见 SemiAnalysis 加速器模型。
可以说，OpenAI Jalapeño 是一颗货真价实的大批量 ASIC。
与 Rubin 的时间线相比，Jalapeño 的速度快得惊人。如前所示，尽管 Rubin 起步更早，Jalapeño 的成绩仍然超过了它。
Jalapeño 架构
现在深入架构。这颗芯片的矩阵引擎采用 MXFP 数值格式和权重固定的脉动阵列，与 TPU 类似。但与 TPU 直接相比，它支持更小的形状/维度，这意味着它不像大型脉动阵列那样，在遇到形状别扭的矩阵乘法时暴露出奇怪的性能悬崖。
它还配备 64 位标量核和 FP32/INT32 向量核。OpenAI 还在托盘层面投入了冗余设计，并在核心和通道层面内置了良率收割机制。他们声称，AI 辅助芯片设计在设计阶段使 SIMD 面积减少了 8%，矩阵引擎面积减少了 10%。虽然他们未明确具体的工艺/电压/温度条件，但他们也提到 AI 辅助设计的模块相比最初的模块改善了时序和功耗。
Jalapeño 架构设计的重点是消除 KV 缓存和权重的内存搬移，以及各种固定延迟和开销，从而即使在较小的批次或形状下，也能比其他加速器更接近原始峰值算力和带宽。
核心与 HBM 被划分为若干切片，每个核心切片对自己的那片 HBM 拥有低延迟的本地视图。切片之间的同步通过一条高带宽的专用集合通信网络进行。仅这种极简的内存层次结构，就已经让 Jalapeño 相对 GPU 具备了很大的潜在优势——GPU 的内存访问必须穿越复杂的内存系统，产生的大延迟必须通过更大的形状来摊薄或隐藏。
这一选择之所以可行，是因为只要仔细安排权重和 KV 的放置，核心之间的同步就可以被限制在有限的、已知的高带宽通信上，例如可以与计算重叠的张量并行通信。
此外还有一条额外的通用片上网络（NoC），用于一般通信以及访问扩展网络。总体而言，相比英伟达和谷歌，OpenAI 凭借简化的片上网络和内存子系统，大幅节省了功耗并获得了可观的性能提升。
在核心层面，OpenAI 采用了带 L1 缓存的乱序执行核心，也就是 OoO 核心。这与我们在其他加速器上看到的设计有明显不同。其他加速器通常使用由软件管理的暂存存储器，并搭配某种异步 DMA 支持。
Jalapeño 的设计逻辑仍然是：这样可以避免固定开销，例如屏障延迟。在其他加速器，特别是 GPU 上，这些延迟必须通过提高每个核心的工作量来隐藏或摊平，否则就很难接近理论峰值带宽和 FLOPs。这种设计的代价是，Jalapeño 必须依赖良好的预取机制，以确保内存请求能够及时抵达。而预取的行为更难预测，也更难分析。
不过，如果 Codex 处在一个完善的运行环境中，并且能够访问详细的追踪数据，那么，为某种特定形状寻找具备最佳预取策略的最优内核，可能几乎不需要人工干预。我们认为，OpenAI 正是通过这种方式，迅速让 DeepSeek R1、Kimi K2.5 和 GPT-OSS 在 Jalapeño 上运行起来。Jalapeño 的核心还支持“小型”矩阵维度。
具体能小到什么程度还有待观察，但这一能力应该会让它更适用于不同模型和批量维度，并降低对矩阵维度对齐的敏感性，减少填充开销和分块效率损失。例如，TPU、Trainium 和 Etched 芯片都采用了非常大的脉动阵列。为了避免分块效率低下，它们往往需要较大的批量，或者要求模型维度能够被准确整除。借助 Jalapeño，OpenAI 的重点是消除系统中的固定延迟，让芯片在帕累托曲线的各个区域都尽可能接近理论性能上限。
理论上，这种设计可能让 Jalapeño 在多个运行点上超过 GPU：
在低延迟、小批量推理中提供更高的上限性能。GPU 在这类场景下会受到内核启动延迟、屏障延迟和内存系统延迟等固定开销的限制；
即使面对大批量或长上下文任务，也有潜力更接近硬件理论上限。
当然，即使理论上存在这样的性能上限，真实内核可能仍然很难把它实现出来。因此，这套方法似乎可以概括为两步：
针对各种工作负载形状，设计尽可能高的理论性能上限；
让 Codex 完成繁琐工作，寻找能够达到这一上限的内核。
从 OpenAI 团队在 Jalapeño 上快速启动 InferenceX 工作负载的速度来看，我们对这套方法持乐观态度。如果 Jalapeño 最终成功，它将释放一个强烈信号：整个行业对于编程模型和完美、通用编译器的痴迷，可能正在被前沿人工智能模型打破。
软件
OpenAI 像编写汇编程序一样编写 Jalapeño 内核。每个内核都要经过人工调优，有些内核的代码长度接近 3000 行，同时还要经过正确性检查和定制的代码清理器验证。早期的内核开发仍然依赖人在循环中参与，但后来这一过程逐渐转向一个规模更大的内部 Codex 版本。OpenAI 计划未来将这个版本推向企业客户。OpenAI 内部的服务引擎名为“Teacup”。
有一点非常有意思：直到使用 InferenceX 对 DeepSeek 进行基准测试之前，OpenAI 内部甚至还没有实现 MLA 内核。Codex 能够在没有 OpenAI 内核工程团队介入的情况下，如此迅速地写出功能正常、效率很高的内核，这展示了 OpenAI 软件开发流水线的能力。
OpenAI 使用 Gluon 为 Jalapeño 编程。Gluon 是 OpenAI 开发的内核编程语言，建立在 Triton 之上。它保留了 Triton 的 SPMD，也就是“单程序多数据”编程模型，但同时暴露出更底层的编程抽象。以英伟达 GPU 为例，Gluon 提供了能够映射到 PTX 指令的 API，包括 MMA 指令、TMA 指令、mbarrier 机制等。Gluon 最独特的抽象是“布局”。
通常来说，布局定义的是硬件资源与张量元素之间的映射关系。例如，它可以描述某个硬件资源——比如第 9 个 warp 的第 5 个寄存器——与某个张量元素——比如第 6 行、第 7 列的张量元素——之间的对应关系。Gluon 的布局抽象建立在线性布局之上。线性布局是 OpenAI 发明的一种布局代数。
线性布局用数学方式形式化地定义了什么是布局，并提供了操作布局的工具。这带来了许多能力，例如可以从理论上证明布局转换的正确性，并实现最优的内存交错访问。在 Jalapeño 的编程模型中，每个 Gluon 程序都会映射到一个持久线程。
我们认为，这暗示 Jalapeño 适合采用“持久化内核”编程模式。在这种模式下，每个程序会在多个数据块上持续执行，具体工作由程序员分配，而不是由硬件调度器分配。OpenAI 还提到了 TensorInfo，这是一种能够显式编码布局的抽象。它很可能就是专门为 Jalapeño 设计的一组布局，并由线性布局提供底层支持。此外，每个核心都支持数据预取和解耦式乱序单元。
例如，用户可以编写一个等待预取数据的操作，而这个操作会被信号量锁住，直到数据准备完成。命运有时会出现奇妙的反转。
像 GPT 5.6 Sol 这样的 OpenAI 模型目前运行在英伟达 GPU 上，但这些模型后来被用于设计一款真正威胁 CUDA 护城河的芯片。换句话说，英伟达自己的 GPU 正在实时帮助潜在继任者诞生。
如果比较不同时间点的结果，我们也能看到 Jalapeño 的开发速度。在不到两周的时间里，它在某些交互性测试中实现了超过两倍的吞吐量提升。Jalapeño 团队每次提供的软件压缩包，都像是一个充满惊喜的宝箱。
不仅内核性能得到提升，在短短 8 天内，Jalapeño 团队还启用了 TP32。他们在此前 TP8 配置的基础上，进一步将运行范围从单个系统扩展到整机架，并成功让一个大型模型运行在完整的机架级配置上。这种开发速度非常惊人。
为了在真正运行硬件之前验证性能，OpenAI 还开发了一个名为“chilisim”的模拟器。它使用固定宽度的追踪总线，模拟结果与实际硬件测量值的误差在 5% 以内。A0 版本的追踪能力有限，但 B0 版本已经得到了大幅改进，很可能吸收了 A0 硅片实际运行结果中的信息。工程师还演示了 Codex CLI 运行内部模型的效果。这个内部模型的昵称是“Raiku”，也被称为“5.3 Codex Spark”，其每个输出令牌的时间达到了 1.2 毫秒。
团队还展示了由 Codex 编写、直接运行在 Jalapeño 芯片上的演示程序，包括以每秒 36 帧运行的《毁灭战士》、FP32 流体动力学模拟，以及一个名为“Liquid Light”的鼠标拖动可视化程序。
在模型侧，OpenAI 内部正在采用一种名为“gigakernel”的巨型内核方案。它围绕一个单一巨型内核构建，让内核在设备上循环运行，以减少 CPU 开销和启动时间。OpenAI 还在进一步探索测试时计算策略。内部团队尤其关注如何协调使用 100 万次 rollout。
预填充与解码：到底要不要拆分？
前面我们提到，OpenAI 没有在这些芯片上使用预填充和解码分离。这让我们感到意外，因为英伟达和 AMD 的 GPU 性能从 PDD 中获益显著，即便是在同构硬件上也是如此。让我们深入探讨 Jalapeño 团队为何走这条路。
当工作负载固定不变时，预填充—解码分离，也就是 PDD，看起来很有吸引力。预填充和解码对硬件的压力不同，因此，可以分别建立针对两个阶段优化的芯片池，并在某个特定输入输出比例下提升效率。但生产流量不会始终保持同一个比例。
输入和输出序列长度、并发数、缓存命中率、推测解码接受率以及延迟目标，都会随着一天中的时间不断变化。一旦设备被划分为预填充池和解码池，如果预填充需求过高，解码芯片就会处于空闲状态，而请求会不断排队。如果解码需求过高，情况则会反过来。运营商必须持续预测正确的芯片分配比例，在两侧都预留备用容量，并不断重新平衡一个理想比例始终变化的系统。在统一系统中，某些资源可能在某个阶段没有被充分利用，但每一块设备都可以随时服务下一个请求。而在拆分系统中，一整块芯片可能仅仅因为属于错误的芯片池而处于空闲状态。局部利用率看起来更好，但全局利用率可能更差。
拆分还会破坏局部性。预填充工作节点会生成大量 KV 缓存，而解码工作节点马上就需要使用这些缓存。因此，系统必须先通过网络传输这部分状态，生成过程才能继续。这会带来额外的带宽消耗、同步开销、排队问题，以及另一个潜在的故障域。
随着输入序列变长，成本还会进一步上升，因为 KV 缓存会随之增长。不过，避免搬运 KV 主要是一种功耗和延迟优化。愿意搬运一部分 KV，也可以换取更高的硬件利用率，只是代价是更高的功耗和单请求延迟。
一支可灵活调配的芯片集群，可以在对延迟敏感的请求和追求吞吐量的批处理任务之间转移容量。固定拆分则会在流量组合发生变化时，让部分硬件被闲置。此外，上下文长度还会改变注意力计算和 FFN，也就是前馈网络计算之间的比例。因此，任何固定的硬件比例，都只会在接近设计目标的场景中保持高效。
同样的问题也存在于推测解码。草稿模型必须以极低延迟向验证模型提供候选令牌。如果把两个模型分别部署到不同的专用芯片池中，就会把一个紧密耦合的解码循环变成分布式协议。额外的通信和协调开销，可能抵消推测解码本来节省的延迟。让两个模型继续运行在同一批设备和低延迟互连网络上，可以保留局部性，而这正是推测解码真正有价值的基础。
当然，当需求足够大、稳定且可预测时，拆分仍然可能取得优势，尤其是在传统 GPU 必须依靠较大的阶段专用批量才能实现良好吞吐量的情况下。但它绝不是没有代价的免费午餐。
从 Katsu 到 Vindaloo：Jalapeño 如何组成机架
在机架层面，Jalapeño 系统由一个 CPU 主机机架和一个 ASIC 机架组成。主机机架中安装了 16 个主机 CPU 托盘，这些托盘被命名为“Katsu”。每个 Katsu 托盘分别对应右侧 ASIC 机架中的一个 ASIC 托盘，后者被命名为“Vindaloo”。
每个主机配备两颗 Turin 级 AMD EPYC CPU。每个机架配置 1.5TB DRAM、两块 E1.S SSD 和两块 M.2 SSD。每个托盘还配备 400G 前端网络，也就是两条 200G 网络连接。每个 Katsu 托盘通过 8 条外部 PCIe DAC 线缆连接到对应的 Vindaloo 托盘。这些线缆沿着机架正面水平铺设。
整个系统级设计由 OpenAI 与 Celestica 合作完成。ASIC 机架由 16 个 Vindaloo 托盘和 8 个扩展交换机托盘组成。这 8 个交换机托盘中，6 个用于本地扩展，2 个用于全局扩展，统一被命名为“Chana”。每个 Vindaloo 托盘包含 8 颗 Jalapeño ASIC，因此每个机架总共拥有 128 颗 Jalapeño ASIC。这些 ASIC 通过铜缆背板连接到每个 Chana 交换机托盘，连接方式与英伟达 Oberon 系统类似。
整个扩展网络拓扑被划分为两个域：
机架内部由 128 颗 ASIC 组成的本地域；
最多连接 16 个机架、共 2048 颗 ASIC 的全局域。
下面将进一步解释其带宽和拓扑结构。为侧边主机机架配置的电力容量约为 50kW，量产运行时的实际功耗约为 31kW；ASIC 机架的功耗为 130kW。因此，这套由两个机架组成的完整系统总功耗约为 160kW。如果只看功耗，它基本相当于一个双宽 GB300 机架。
OpenAI 可以在单个扩展网络中连接最多 2048 个 Jalapeño XPU。这套扩展网络由两个域组成：
本地域：通过机架内部的背板连接全部 128 个 XPU；
全局域：通过铜互连和光互连组成的混合网络，跨越 16 个机架连接 2048 个 XPU。
每个机架包含 8 个 Chana 交换机托盘。位于中间的 6 个 Chana 交换机用于本地域。每个交换机托盘配备一颗 102.4T 的 Tomahawk 6 交换 ASIC。位于这 6 个本地交换机顶部和底部的另外两个 Chana 交换机，用于全局域。我们认为，这两个全局交换机托盘可能各自配备两颗 102.4T 的 Tomahawk 6 交换芯片，因此每个交换机托盘的交换能力最高可达 204.8T。在本地域中，128 颗 Jalapeño 芯片中的每一颗，都拥有每个 XPU 单向 4.8Tb/s 的带宽，并以全互连方式连接到 6 颗 102.4Tb/s 的 Tomahawk 6 ASIC。这意味着，每个 XPU 需要 48 对差分信号连接器，也就是 48 对一公一母的连接器组合。换算到整个机架，就是总计 6144 对差分信号连接，对应如此规模的无源铜缆。这些铜缆用于实现机架内部的本地扩展。
对于全局域，16 个机架、总计 2048 个 XPU，通过以下组件连接起来：
铜缆背板；
电连接的 204.8T TH6 交换芯片；
1.6T 收发器；
光路交换机。
每个 XPU 的全局链路单向带宽为 1.6Tb/s。在 XPU 与全局交换机之间的背板上，每个 XPU 对应 16 对差分信号连接器。每个全局交换机托盘包含两颗 ASIC。其输出带宽会在背板连接和前面板光连接之间进行分配。综合本地域和全局域，每个机架中每个 XPU 的背板连接数量达到 64 对差分信号连接。整个机架则需要总计 8192 对差分信号连接，也就是相当于 8192 对差分连接规模的无源铜缆。全局域采用纯 Rail 架构，整个全局域由 8 条 Rail 组成。我们认为，OpenAI 会通过安装在每个机架中的光路交换机，也就是 OCS，对全局域中的光链路进行路由。对于每个 XPU 来说，1.6Tb/s 的全局带宽会先通过铜缆背板传输到全局交换机托盘。随后，这些数据会通过交换机前面板上的 1.6T 收发器离开交换机，进入无源光交换机，最终离开当前机架。通过这种方式，系统的扩展网络规模可以扩大到 2048 个 XPU，也就是由 16 个机架组成、每个机架拥有 128 个 XPU 的完整网络。
由于扩展网络只占整个系统成本的约 10%，这种架构灵活性为未来运行 10 万亿至 20 万亿参数模型，或者使用 200 万至 400 万令牌上下文窗口，提供了宝贵的可选空间。在部署方面，OpenAI 正与新型云服务商合作，并通过数据中心合作伙伴收集可靠性数据。相关工作将持续到明年 1 月。与此同时，OpenAI 也在优化从设备抵达码头，到完成机架部署的整体时间。
接下来会发生什么？
接下来，我们来谈谈 Jalapeño 的未来。这款芯片的第一批量产产品即将问世。OpenAI 的下一阶段目标是部署 100MW 的 Jalapeño 系统。届时，主要障碍将集中在硬件方面：
OpenAI 到底能够生产多少芯片？
它能否高效部署和运营这些数据中心？
如何处理系统监控？
如何确保系统具备足够的韧性和故障恢复能力？
以及其他相关问题。
软件方面已经得到验证。而且，借助 OpenAI 的内部模型，任何软件层面的领先都很容易被追上。
