SemiAnalysis 实测 OpenAI Jalapeño 推理芯片：多项性能超过 Nvidia Blackwell

OpenAI 在过去几年里一直在悄悄打造“Jalapeño”，这是一款刚刚在 Hot Chips 上发布的推理芯片。关于成功流片的传闻已经流传了一段时间。但现在我们有了细节。OpenAI 邀请我们查看他们的芯片， 前往他们的实验室看看它有多真实，并用我们的 benchmark 对它进行测试，使用的是我们的 InferenceX 套件。

6 月，OpenAI 公布了该芯片计划，与 Broadcom 合作，从零开始专为 LLM 推理打造。设计工作于 2024 年年中启动，从最初团队招聘到制造流片仅用约 16 个月，这是极其快速的 ASIC 开发周期。

一般来说，第一代芯片没有竞争力，但 OpenAI 逆势而上，做到行业领先，并在多个顶级开源模型上击败了我们能够测试的每一款 Nvidia、AMD 和 Google 芯片。OpenAI 通过极致的硬件软件协同设计实现了这一点。令人惊讶的是，OpenAI 并没有过度专注于模型推理的任何特定部分，而是专注于打造一款在所有场景下都能提供高性能的通用芯片。

在本文中，我们将深入介绍 Jalapeño 在 InferenceX 上的架构细节、软件细节和性能结果。

一款通用推理芯片

大家都说 OpenAI 的芯片是为 OpenAI 模型专门定制的，但这是错的，OpenAI 打造的是一款用于 AI 推理的通用芯片。

时间线简直疯狂。这表明，关于利用 AI 加速芯片设计的说法是真实的。不管时间线有多快，OpenAI 花了一大笔钱，做出了务实的设计决策，而且他们的团队非常强，所以这并不令人意外。

仅看规格，它就是一个立即有力的竞争者：

而 HBM4 的使用使其脱颖而出，可与 NVIDIA 和 AMD 的旗舰 GPU 相媲美：

关于这款芯片的许多媒体报道都跟随着 OpenAI 的一些随口评论，声称该芯片将以其他芯片无法做到的方式针对他们的模型进行优化。这是错误的。Jalapeño 是一款通用推理芯片，能够运行各种模型和各种工作负载，包括我们的基准测试 InferenceX，我们在实验室中与 OpenAI 工程师一起运行了该基准测试。开个玩笑，OpenAI 甚至向我们展示了它运行 Doom，而 Doom 仅通过 Codex 提示就被移植到了他们的芯片上。

以下是我们头条性的性能/功耗结果，考察每 All-in 公用事业 MW 的 token 吞吐量。Jalapeño 碾压其他所有芯片。这一切都是在没有多 Token 预测（MTP）的情况下完成的，而图表中的其他芯片都是各自 SKU 中性能最佳的配置，且都启用了 MTP。

Jalapeño 在几乎所有场景下的性能功耗比都击败了 Blackwell，而且并未针对曲线上的任何特定点进行调优。它不仅擅长低延迟场景，在高吞吐场景中同样表现出色。更公平的对比是与单 token 预测（Single Token Prediction）结果相比，它把所有竞争对手都远远甩在身后。在低并发场景下，Jalapeño 展现出惊人的交互性，在 DeepSeek R1 模型上并发为 1 时，每用户每秒可超过 700 个 token。

令人难以置信的是，这一切都是在单 token 预测（STP）下实现的，没有投机解码，也没有预填充-解码分离。除了 DeepSeek R1，我们还看到了一些其他模型，包括 Kimi-K2.5 和 GPT-OSS，它们大约以每用户每秒 1,400 token 的速度运行。对于所有模型，我们都确认了 Jalapeño 的 GSM8k 评测结果与 Nvidia 芯片相当。

关于这一点有一些注意事项。首先，所有数字都是由 OpenAI 提供给我们的。我们在实验室亲自验证了 InferenceX 的运行，但我们并未运行完整的 InferenceX 基准测试套件，也没有看到 AgentX 的结果。AgentX 是我们比较芯片性能时首选的测试套件，因为其数据集具有长上下文和多轮对话特性，能够反映真实生产工作负载的缓存行为。在 8k1k 上表现良好的框架在 AgentX 上可能表现更差，因为真实生产负载会给路由器、前缀缓存机制、缓存管理、卸载基础设施等组件带来压力。这些都不是单轮 8k1k 所能测试的。更多内容请阅读我们的 AgentX 文章。

其次，我们认为与 Blackwell 的比较有些不完整，也不公平。Jalapeño 真正竞争的是同样使用 HBM4 的 Rubin 等芯片。Vera Rubin 系统现在已经开始向客户出货，而 OpenAI 距离拥有 Jalapeño 的工程样品之外的东西还需要一段时间。

因此，性能实际上应该与 Rubin 比较，而不是 Blackwell；从某种意义上说，我们本就预期像 Jalapeño 这样的定制芯片会胜过 Blackwell。Vera Rubin NVL72 的每兆瓦性能是 GB200 NVL72 的 5.4 倍 正如我们在上个月分析 NVIDIA 与 CoreWeave 发布时性能声明的那篇文章中所述。我们将在下文将 Jalapeño 与 Vera Rubin 7 月的性能数据进行对比。

第三，所测试的模型并不处于开放前沿。NVIDIA 和 AMD 已经使用 AgentX 发布了在更大模型（如 DeepSeek V4 Pro 和 Kimi K3）上的结果。模型越大、发布越新，在新芯片上跑通就越复杂。话虽如此，OpenAI 在 Jalapeño 上跑通的模型也并非小模型。

性能分析

OpenAI 围绕性能功耗比进行设计。原因很简单：OpenAI 目前受限于数据中心的电力，而不是预算或占地面积，因此每兆瓦的 token 数至关重要。在 Computex 2026 上，Jensen 表示性能功耗比、可靠性和长寿命是未来 GPU 的核心特性。引用他的话说：“如果你有 1 吉瓦的电力，那么每瓦吞吐量就是收入。”他还提到，仅仅因为芯片更便宜就选择错误的架构是不合理的。

Nvidia 在 Hot Chips 2026 的 Vera 演讲中强调了这一点，同时展示了同一张营收图表：“如今的数据中心受限于电力。”电力至关重要，并驱动着营收。

运营商无法简单地获取更多兆瓦，因为增加 GPU 和增加电网容量发生在截然不同的时间尺度上。数据中心的电力包络受到诸多约束，例如其公用事业互联、基础设施、冷却能力以及 UPS/备用发电设计。电网延迟屡屡超过硬件和建设时间表，这推动了对 BtM（表后）电力容量的需求：在数据中心自身所在地建设和部署的燃气轮机和现场发电机。这种容量位于公用事业电表之后，而非从公共电网取电。它让运营商无需等待电网互联和公用事业升级即可为设施供电，这正是 xAI 的 Colossus 2 如此重度依赖 BtM、而其实际电网连接远远落后的原因。更多内容请见我们的 能源模型。

正如我们在一条 X 帖子中所写，tok/s/MW 可简化为每焦耳 token 数，因为一瓦特等于每秒一焦耳。这使得 tok/s/MW 能够代表系统将能量转化为 token 的效率和能力。

在这方面，即使与 Rubin 相比，Jalapeño 也胜出。OpenAI 的 Jalapeño 每兆瓦的 STP 输出 token 吞吐量超过了 NVIDIA 和 CoreWeave 在 7 月发布的 Vera Rubin 的 MTP 结果。它也远超 GB200 的 2025 年 MTP 结果。 正如我们在 Vera Rubin 文章中所提到的，VR 之所以与 2025 年 GB200 的结果进行比较，是因为那处于相似的早期启动阶段，而与 2025 年的 GB200 比较可以保持软件成熟度不变。按照这一逻辑，我们比较 Vera Rubin 最新的 2026 年 7 月结果、GB200 2025 年结果以及今天的 Jalapeño 结果。这是一个非常有效的比较，因为这些是最好的公开 Rubin 数据，而 OpenAI 是在 Rubin 之后流片其芯片的。OpenAI 和 Rubin 都仍不成熟，因此性能还会继续提升。

在性能/TCO 方面，Vera Rubin 和 Jalapeño 不相上下，每美元产生的输出 token 数量几乎相同。然而，如前所述，Jalapeño 的结果是在没有投机解码的情况下获得的，而 Vera Rubin 的结果使用了投机解码。投机解码可使每 token 成本降低约 3-5 倍。当在 Jalapeño 上实现投机解码后，这将使 Jalapeño 能够以更具成本效益的方式提供 token 服务。当然，这种 TCO 优势的一部分来自用 Nvidia 的高利润率换取 Broadcom 较低（尽管仍然很高）的利润率。但这并非全部。例如，Meta 和 Microsoft 的 AI ASIC 项目尽管投入时间更长却未能起步，这表明成本只是等式的一部分。关于 Jalapeño 的完整 TCO 明细，请见 SemiAnalysis AI Cloud TCO 模型。

在架构上，OpenAI 选择不将预填充和解码（PD）拆分到独立的芯片池中。草稿模型和主模型共享相同的芯片和互连结构，这种设计理念以牺牲部分理论效率来换取实际运营的便利。其动机在于工作负载组合会随时间变化，例如输入、缓存写入、缓存读取和输出 token 之间的比例，随着我们经历三个模型时代（知识、推理和智能体，正如我们最近文章中讨论的那样）已经发生了显著变化。因此，预先选定固定数量的异构预填充芯片和解码芯片，长期来看可能导致效率低下。OpenAI 在此架构中选择同构芯片池，并努力让芯片在所有任务上都表现出色。

确实如此。在 Kimi K2.5（Cursor Composer 2.5 所基于的模型）上，Jalapeño 达到了接近 700tok/s/user，在 100tok/s/user 时性能超过次优芯片的 9 倍以上。

在 GPT-OSS 上，又是一场血洗。Jalapeño 的等交互性每兆瓦吞吐量几乎是 GB200 最高吞吐点的两倍，并且是 GB200 并发度为 1 时的 50 倍以上。Jalapeño 更高并发的数据点使用了 EP8。

这些结果令人印象深刻！不过，我们必须挑刺：它们只是 8k1k，一个更容易调优的工作负载，而且还没有 AgentX 的运行结果。正如我们在 AgentX 文章中所提到的，多轮、长上下文工作负载会给服务栈的更多方面带来压力，例如路由器和前缀缓存。要在智能体工作负载中表现出色，还需要更多的优化。请阅读 AgentX 文章了解更多。

深入规格与架构

所有这些结果都是在 Jalapeño 的 A0 步进上收集的，项目仅进行了 9 个月。但已经有一个 B0 步进正在晶圆厂中流片！B0 的优化带来了比早期 A0 硅片大约 25% 的每瓦性能提升。具体来说，B0 步进在单个光罩尺寸的计算裸片上提供了 13.4 PFLOPs 的 MXFP4 算力，该裸片采用台积电 N3P 工艺制造。相比之下，单个 Rubin 计算裸片在相似尺寸和相同节点上提供 17.5 PFLOPs 的密集 Rubin NVFP4 算力。

考虑到 Jalapeño 的 TDP 仅为 700W，而 Rubin 每个计算裸片为 900-1,150W，这就更加可观了。由于 Jalapeño 面向推理而非训练，OpenAI 不需要推高 TDP 来最大化 FLOPs 是可以理解的，但无论如何，上述数据表明 Jalapeño 提供了可观的峰值理论 FLOPs。

与其他加速器直接比较时，Jalapeño 拥有最高的每瓦 HBM 带宽和最高的每瓦 FLOPs，与 1,800W 的 Rubin Max-Q 配置相当：

封装外 I/O 由一个 N3E I/O 芯粒提供，具有 32 条 800G SerDes 通道用于计算互连结构，其中 24 条通道（600GB/s）用于机架内的本地扩展，8 条通道（200GB/s）用于全局扩展，即 2,048 XPU 的多机架域。PCIe Gen 5 用于系统 I/O，连接 x86 主机 CPU。

Jalapeño 将搭载 HBM4 出货，使其成为继 Nvidia 和 AMD 之后相对较早的采用者之一，甚至领先于成熟的 TPU 和 Trainium 项目。由于 Jalapeño 背后的关键架构原则之一就是充分利用 HBM 带宽，因此退而求其次选择非最优的 HBM 会与这一目标背道而驰。这带来了每个封装 15.4TB/s 的内存带宽，超越了所有其他采用 HBM3E 出货的加速器。15.4TB/s 的带宽表明其 HBM4 可达到 10Gbps 的引脚速度，这将使其略优于 Nvidia 在 Rubin 中从其 HBM4 获得的 9.6Gbps。该 HBM 很可能由三星提供。

OpenAI 于 2025 年 11 月完成了 Jalapeño 的流片，更准确地说，这是 CoWoS 设计的流片，而不仅仅是顶层裸片硅。在 2025 年 11 月那次流片后的 9 个月内，且仅在实际硅片上进行了 3 个月的调试，OpenAI 就已经用 Jalapeño 交付了非常好的结果。更令人印象深刻的是，该团队是从零开始构建软件栈的。

与此同时，Rubin 的 CoWoS 流片已于 2025 年 10 月完成，早了一个月，然而我们看到的唯一早期结果来自 CoreWeave 的工程样品。Nvidia 没有像 OpenAI 那样让我们测试并发布基准测试，这表明他们的芯片软件仍不成熟。鉴于 OpenAI 能如此迅速地在自家硅片上跑通新模型，CUDA 的护城河可能已经不复存在。

它们距离优化还有很长的路要走，但我们可以看到总体而言 Jalapeño 交出了更好的数字。我们认为并非 Nvidia 硬件更差，而更多是 Jalapeño 的软件调试进展比 Nvidia 更快。这说明了软硬件协同设计的力量，而这正是一家顶尖前沿实验室的 ASIC 团队能够胜过更成熟的商用芯片厂商的主要领域。反直觉的是，从零开始可能也让 OpenAI 受益，因为它可以做出全新的架构决策，而无需顾虑向后兼容性或旧版软件。

虽然 OpenAI 已有 Jalapeño 的工程样品，但量产目前计划在 2027 年逐步爬坡，大部分产出目前计划在明年年底。有关单位产量和 ASP 的更多细节，请参阅 SemiAnalysis Accelerator Model。

可以说，OpenAI Jalapeno 是一款真正的高量产 ASIC。

与 Rubin 的时间线相比，Jalapeño 快得惊人。如前所示，尽管 Rubin 起步更早，Jalapeño 的结果仍优于 Rubin。

Jalapeno 架构

现在深入架构，该芯片的矩阵引擎使用 MXFP 数值格式和权重固定的脉动阵列，类似于 TPU。但与 TPU 直接相比，它支持更小的形状/维度，这意味着它不会出现因较大脉动阵列上形状别扭的矩阵乘法而暴露出的奇怪性能断崖。

它还具有 64 位标量核心和 FP32/INT32 向量核心。OpenAI 还在托盘级别进行了冗余设计，并在核心和通道级别内置了良率收割。他们声称，芯片设计中的 AI 辅助使 SIMD 面积减少了 8%，矩阵引擎面积在设计期间减少了 10%。虽然他们没有说明确切的工艺/电压/温度（PVT）条件，但他们也提到 AI 辅助模块在时序和功耗上优于初始模块。

Jalapeño 架构设计的重点是消除 KVCache 和权重的内存移动，以及固定延迟和开销，从而使其即使在小批量或小形状下，也能比其他加速器更接近原始峰值 flops/带宽。

核心和 HBM 被划分为多个切片，每个核心切片对其自身的 HBM 切片具有低延迟的本地视图。切片之间的同步在专用的高带宽集合网络上进行。这种极简的内存层次结构已经使 Jalapeño 相比 GPU 具有巨大的潜在优势，因为在 GPU 中，内存访问必须经过复杂的内存系统，导致大延迟，必须通过更大的形状来摊销或隐藏。

这种选择是可行的，因为通过仔细放置权重和 KV，核心之间的同步可以限制在有限的、已知的高带宽通信上，例如可以与计算重叠的张量并行通信。

还有一个额外的通用 NoC，用于通用通信和访问 scale-up 网络。总体而言，与 Nvidia 和 Google 相比，OpenAI 通过简化的 NOC 和内存子系统节省了大量功耗并获得了巨大的性能提升。

在核心层面，OpenAI 描述了一个带有 L1 缓存的乱序（OoO）核心。这与我们在其他加速器中看到的模式有很大不同，其他加速器都使用软件管理的暂存器，通常搭配一些异步 DMA 支持。同样，这里提出的论点是，这使 Jalapeño 能够避免固定开销，例如屏障延迟，而在其他加速器（如 GPU）上，这些开销需要通过每个核心更高的工作量来隐藏或摊销，并且更难接近原始峰值带宽/flops。

权衡之处在于，Jalapeño 因此依赖良好的预取来确保内存请求及时到达，这更难以预测，也更难推理。然而，借助 Codex 在良好的框架中并能够访问详细跟踪，为给定形状找到具有最佳预取的最优内核可能只需要很少的人工干预。我们认为，这正是 OpenAI 能够如此迅速地支持 DeepSeek R1、Kimi K2.5 和 GPT-OSS 的原因。

这些核心还支持“小”矩阵维度，这（取决于有多小）应该使其在不同模型和批量维度上更通用，对矩阵维度对齐、填充开销和分块效率低下的敏感度更低。例如，TPU、Trainium 和 Etched 芯片具有非常大的脉动阵列，可能需要大批量或恰好可整除的模型维度来避免分块效率低下。

借助 Jalapeño，OpenAI 专注于消除系统中的固定延迟，以便在帕累托曲线的所有区域尽可能实现接近 roofline 的性能。理论上，这可以在多个工作点上为他们带来相对于 GPU 的优势：

• 在低延迟/小批量推理上具有更好的性能上限，而 GPU 上的这一性能受限于许多固定开销，例如启动延迟、屏障延迟、内存系统延迟

• 即使对于大批量或长上下文，也有潜力实现更接近硬件 roofline 的性能

但需要注意的是，即使理论上可以达到性能上限，对于真实内核而言，实现这一性能可能更加困难。因此，方法似乎是：

1. 针对所有工作负载形态设计最高的性能上限

2. 让 Codex 完成寻找能够达到该上限的内核这一繁琐工作

从 OpenAI 团队在 Jalapeño 上启动 InferenceX 工作负载的极快周转速度来看，我们对这一方法持乐观态度。

如果 Jalapeño 取得成功，这将是一个强烈信号：业界对编程模型和完美通用编译器的执迷，正被前沿 AI 模型所推翻。

软件

OpenAI 像编写汇编一样编写 Jalapeño 内核。每个内核都有手工调优的代码，有些长达约 3,000 行，并配有正确性检查和自定义 sanitizer。早期的内核工作采用人在回路的方式，而非完全自动化，但随着 Codex 内部更大规模版本的推出，这种情况发生了转变，OpenAI 计划将该版本推销给企业客户。内部服务引擎被称为“Teacup”。有趣的是，OpenAI 在用 InferenceX 对 DeepSeek 进行基准测试之前，内部并没有 MLA 内核的实现。Codex 能够如此迅速地编写出功能完整且高效的内核（且没有任何 OpenAI 内核工程团队介入），这展示了该软件流水线的开发能力。

OpenAI 使用 Gluon 对 Jalapeño 进行编程。Gluon 是 OpenAI 的内核编程语言。它构建在 Triton 之上，保留了 Triton 的 SPMD（单程序多数据）编程模型，但暴露了底层编程抽象。例如，对于 NVIDIA GPU，它提供的 API 可映射到 PTX 指令，包括 MMA 指令、TMA 指令、mbarrier 机制等。Gluon 提供的最独特抽象是布局。一般来说，布局定义了硬件资源（例如 warp 9 的第 5 个寄存器）与张量元素（例如第 6 行第 7 列的张量元素）之间的映射。Gluon 的布局抽象基于Linear Layouts，这是 OpenAI 发明的一种布局代数。Linear Layouts 从数学上形式化了布局是什么，并提供了操作布局的工具。这实现了许多功能，例如可证明正确的布局转换和最优内存 swizzling。

就 Jalapeño 的编程模型而言，每个 Gluon 程序映射到一个持久线程。我们认为这暗示 Jalapeño 适合持久内核编程模式，即每个程序在多个 tile 上执行，由程序员而非硬件调度器来分配工作。OpenAI 提到了 TensorInfo，这是一种显式编码布局的抽象。这很可能就是为 Jalapeño 设计的那套布局，将由 Linear Layouts 提供支持。最后，每个核心都提供数据预取和解耦的乱序单元。例如，用户可以编程等待预取的数据，该数据被信号量锁定。

命运的奇妙转折是，像 GPT 5.6 Sol 这样目前运行在 NVIDIA GPU 上的 OpenAI 模型，被用来设计一款对 CUDA 护城河构成真正威胁的芯片——NVIDIA 自己的 GPU 正在实时帮助催生它们潜在的继任者。

跨时间对比，我们也能看到 Jalapeño 的开发速度，在不到 2 周内，在某些交互性上实现了超过 2 倍的吞吐量提升。我们从 Jalapeño 团队拿到的每个 tarball 里都装着一个充满奇迹的世界。

不仅内核性能提升了，在 8 天的时间里，Jalapeño 团队在之前的 TP8 配置基础上启用了 TP32，并超越单一系统，让一个完整的机架级配置在大型模型上运行起来。这真是令人印象深刻的开发速度。

为了在投入真实硬件运行之前验证性能，OpenAI 还有一个模拟器“chilisim”，使用固定宽度 trace 总线，与实测硬件的误差在 5% 以内。A0 上的 tracing 有限，但在 B0 上已大幅改进，很可能得益于 A0 硅片上的实际运行输入。工程师们演示了 Codex CLI 运行一个内部模型，代号“Raiku”或“5.3 Codex Spark”，TPOT 为 1.2ms。

团队还展示了由 Codex 编写、直接在芯片上运行的演示：36 FPS 的 Doom、一个 FP32 流体动力学模拟，以及一个“Liquid Light”鼠标拖拽可视化。

在模型方面，OpenAI 的内部 megakernel 方法，代号“gigakernel”，围绕单个 megakernel 在设备上循环以减少 CPU 开销和启动时间。团队也在进一步倾向于测试时计算策略，内部特别关注如何连贯地使用 100 万次 rollout。

Disagg 还是不 Disagg，这是个问题

我们之前提到，OpenAI 在这些芯片上没有使用 prefill decode 分离。这让我们感到意外，因为 NVIDIA 和 AMD GPU 的性能从 PDD 中获益显著，即使在同构硬件上也是如此。让我们深入探究 Jalapeño 团队为何选择这条路。

当工作负载固定时，prefill-decode 分离（PDD）看起来很有吸引力。Prefill 和 decode 对硬件的压力不同，因此将每个阶段分配给单独调优的资源池，可以在某个选定的输入/输出比下提高效率。然而，生产流量并不会停留在那个比例上。输入和输出序列长度、并发度、缓存命中率、投机接受率和延迟目标都会在一天中不断变化。

一旦设备被划分为预填充池和解码池，过多的预填充需求会让解码芯片闲置，而请求却在排队。但过多的解码需求则相反。运维人员必须持续预测正确的拆分比例，在两侧预留备用容量，并重新平衡一个理想比例始终在变化的系统。

在统一系统中，某些资源在特定阶段可能未被充分利用，但每台设备仍然可用于服务下一个请求。在解耦系统中，整块芯片可能仅仅因为它属于错误的池而闲置。局部利用率看起来更好，但全局利用率可能很差。

解耦还破坏了局部性。预填充工作节点产生大量 KV 缓存，而解码工作节点立即需要这些缓存，因此系统必须在生成继续之前通过网络传输该状态。这增加了带宽消耗、同步、排队以及另一个故障域。成本还会随着输入序列长度增加而上升，因为 KV 缓存会增长。然而，避免 KV 移动在很大程度上是一种功耗和延迟优化；愿意移动一些 KV 可以提高硬件利用率，代价是部分功耗和每请求延迟。

可互换的机群在延迟敏感的请求和面向吞吐量的批处理之间转移容量，而固定拆分则会在流量组合变化时让硬件闲置。此外，上下文长度会改变注意力工作和 FFN 工作之间的平衡，使得任何固定的硬件比例仅在其设计点附近才高效。

同样的约束也适用于投机解码。草稿模型必须以极低延迟将候选 token 提供给验证器。将两者分离到专用池中，会把一个紧密耦合的解码循环变成分布式协议。额外的通信和协调可能会消耗掉草稿所节省的延迟。将两个模型保留在同一设备和低延迟互连上，才能保持使投机解码值得进行的局部性。

然而，在需求足够大、稳定且可预测的情况下，解耦仍然可能胜出，尤其是当传统 GPU 需要大规模阶段特定批处理才能达到良好吞吐量时。但这不是免费的午餐。

从日式到印度式（温和到辛辣）：Katsu、Vindaloo 和 Chana——这些咖喱菜肴是如何组合成机架系统的？

机架单元级别的 Jalapeño 系统由一个 CPU 主机机架和一个 ASIC 机架组成。主机机架容纳 16 个名为“Katsu”的主机 CPU 托盘，每个托盘对应右侧 16 个名为“Vindaloo”的 ASIC 托盘之一。每个主机配备两个 Turin 级 AMD EPYC CPU，每个机架配备 1.5TB DRAM、2 个 E1.S 和 2 个 M.2 SSD。每个托盘还规格配备 400G（2x200G）前端网络。每个 Katsu 托盘通过 8 根外部 PCIe DAC 线缆连接到每个 Vindaloo 托盘，这些线缆在机架前方水平走线。系统级设计是与 Celestica 合作完成的。

ASIC 机架由 16 个 Vindaloo 托盘和 8 个 scale up 交换机托盘（6 个用于本地 + 2 个用于全局）组成，命名为“Chana”。每个 Vindaloo 托盘由 8 个 Jalapeño ASIC 组成，因此每个机架总共包含 128 个 Jalapeño ASIC。这些 ASIC 通过铜缆背板连接到每个 Chana 交换机托盘，就像 Nvidia 的 Oberon 一样。scale up 拓扑分为机架内 128 个 ASIC 的本地域，以及连接最多 16 个机架或 2,048 个 ASIC 的全局域。我们将在下文更详细地解释带宽和拓扑。

为 sidecar 主机机架供电大约需要 50kW 配置功率（生产中为 31kW），而 ASIC 机架需要 130kW，使这个双机架系统的总功耗约为 160kW。就功耗而言，这基本上相当于一个双倍宽度的 GB300 机架。

OpenAI 可以在单个 scale-up 网络内连接最多 2,048 个 Jalapeño XPU。scale-up 网络由两个域组成：一个本地域，通过机架内背板连接全部 128 个 XPU；以及一个全局域，通过铜缆和光学互连的混合方式，跨 16 个机架连接 2,048 个 XPU。每个机架由 8 个 Chana 交换机托盘组成。中间的 6 个 Chana 交换机用于本地域，每个都配备一个 102.4T Tomahawk 6 交换机 ASIC。位于本地交换机顶部和底部的 2 个 Chana 交换机用于全局域，我们认为其可能由 2 个 102.4T Tomahawk 6 交换机组成，每个交换机托盘最高可达 204.8T。

在本地域中，128 个 Jalapeño 芯片中的每一个都具有每 XPU 4.8Tb/s 的单向带宽，并以全对全方式连接到 6 个 102.4Tb/s Tomahawk 6 ASIC。这将达到每个 XPU 48 个差分对（DP）公母连接器对，折算为每个机架总计 6,144 个 DP 的无源铜缆，用于本地 scale-up。

对于全局域，16 个机架共 2,048 个 XPU 通过铜缆背板、电气 204.8T TH6 交换机、1.6T 收发器和光路交换机的组合连接在一起。每个 XPU 的全局链路单向带宽为 1.6Tb/s，即每个 XPU 在 XPU 与全局交换机之间的背板上具有 16 个差分对（DP）公母连接器对。每个全局交换机托盘（各含 2 个 ASIC）输出的带宽在背板和前面板光学器件之间分配。

在本地域和全局域之间，每个机架的背板连接器数量达到每个 XPU 64 个 DP，每个机架总计 8,192 个 DP 的无源铜缆。

全局域采用仅轨道（rail-only）架构，在整个全局域内由 8 条轨道组成。我们认为 OpenAI 通过安装在每个机架中的配线架来路由全局域中的光链路。对于每个 XPU，1.6Tb/s 的全局带宽将通过铜缆背板传输到全局交换机托盘。然后通过前面板上的 1.6T 收发器离开交换机，在离开机架之前连接到配线架。这将 scale-up 世界规模扩展到 2,048 个 XPU，结合 16 个机架，每个机架 128 个 XPU。

由于纵向扩展网络仅占系统总成本的约 10%，这种灵活性为未来 10–20 万亿参数模型或 200–400 万 token 上下文窗口带来了宝贵的可选性。在部署方面，OpenAI 正与 neoclouds 合作，并将在 1 月之前与数据中心合作伙伴一起收集可靠性数据，同时优化从到货到上架的部署时间。

下一步是什么

接下来，我们讨论 Jalapeño 的未来，其首个生产 token 即将到来。下一个目标是 100MW，而障碍将主要是硬件方面的：他们能生产多少、他们部署和运营数据中心的能力如何、他们如何处理监控和弹性等。软件已经得到验证，而有了内部模型，任何软件上的先发优势都很容易被追上。在付费墙后，我们将讨论对 NVIDIA、AMD、Cerebras 以及其他已与 OpenAI 签署未来几年协议的芯片公司的影响。

我们还在 Accelerator 模型中介绍了下一代芯片的产量、单位和时间线。

对 NVIDIA、AMD 和 Cerebras 的直接影响

阅读更多