SemiAnalysis：OpenAI 自研芯片实测干翻英伟达旗舰？黄仁勋最担心的事发生了

用自研 ASIC 对比 Rubin、Jalapeño 的总拥有成本、每兆瓦吞吐量，以及辛辣细节

过去两年，OpenAI 一直在默默研发“Jalapeño”，这款推理芯片刚刚在 Hot Chips 上公布。流片成功的传闻已经传了一阵。但现在我们拿到了细节。OpenAI 邀请我们查看芯片、进入实验室验证它的真实程度，并用我们的 InferenceX 套件进行基准测试。

今年 6 月，OpenAI 公布了与博通合作的芯片项目，从零开始专为 LLM 推理打造。设计工作始于 2024 年年中，从最初团队招聘到制造流片只用了约 16 个月，这是一个极快的 ASIC 开发周期。

通常第一代芯片没有竞争力，但 OpenAI 反其道而行，在多个顶级开源模型上，它击败了我们能测试的所有英伟达、AMD 和谷歌芯片，处于行业领先地位。OpenAI 靠的是极致的软硬件协同设计。令人意外的是，OpenAI 并没有过度专攻模型推理的某个特定环节，而是专注于做一款在所有场景下都能提供高性能的通用芯片。

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

一款通用推理芯片

所有人都说 OpenAI 的芯片专为 OpenAI 模型定制，但这是错的，OpenAI 做了一款面向 AI 推理的通用芯片。

时间线太疯狂了。这表明“用 AI 加速芯片设计”的说法是真的。尽管时间线很快，OpenAI 花了大量资金、做了务实的设计决策，而且团队非常强，所以这不令人意外。

单看规格，它立刻就是有力竞争者：

而且使用 HBM4 让它足以与英伟达和 AMD 的旗舰 GPU 相提并论：

很多媒体对这款芯片的报道，都跟着 OpenAI 几句随口说的话走，声称它会以其他芯片做不到的方式为自家模型优化。这是错的。Jalapeño 是一款通用推理芯片，能跑各种模型和各种工作负载，包括我们的 InferenceX 基准测试——我们当时和 OpenAI 工程师一起在实验室里跑了这个测试。作为玩笑，OpenAI 甚至给我们展示了它在跑《毁灭战士》，这个游戏只用 Codex 提示词就移植到了他们的芯片上。

下面是我们最重要的性能/瓦特结果，看的是每兆瓦总功耗下的 token 吞吐量。Jalapeño 完胜所有其他芯片。这一切都没有使用多 token 预测（MTP），而图表中的其他芯片都是各自 SKU 的最佳配置，全部开了 MTP。

Jalapeño 在几乎所有场景下，性能/瓦特都超过 Blackwell，而且没有针对曲线上的某个特定点做调优。它不仅在低延迟场景表现优异，在高吞吐场景也同样出色。更公平的比较是看单 token 预测结果，Jalapeño 把每个竞争对手都甩出几条街。在低并发场景下，Jalapeño 展现出惊人的交互性，在 DeepSeek R1 模型上，并发数为 1 时每用户每秒超过 700 个 token。

不可思议的是，这一切都是用单 token 预测（STP）实现的，没有推测解码，也没有预填充-解码分离。除了 DeepSeek R1，我们还看到其他一些模型，包括 Kimi-K2.5 和 GPT-OSS，它们大约跑到每用户每秒 1,400 个 token。对所有模型，我们确认 Jalapeño 的 GSM8k 评测结果与英伟达芯片持平。

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

AgentX - InferenceXv3：CUDA 护城河在智能体推理中还扛得住吗？

第二，我们认为与 Blackwell 的对比有些不完整，也不太公平。Jalapeño 真正的对手是同样使用 HBM4 的 Rubin 等芯片。Vera Rubin 系统目前已经开始向客户发货，而 OpenAI 的 Jalapeño 还只有工程样品，距离量产还需要一段时间。

因此，性能真正应该与 Rubin 对比，而不是 Blackwell。从某种意义上说，我们本来就预期像 Jalapeño 这样的定制芯片会超过 Blackwell。Vera Rubin NVL72 的性能/瓦特是 GB200 NVL72 的 5.4 倍，这一点我们在上个月分析英伟达与 CoreWeave 发布时的性能声明文章中写过。稍后我们会把 Jalapeño 与 Vera Rubin 7 月的性能数据做对比。

Vera Rubin NVL72 对比 GB200 NVL72？推理 TCO 与架构分析

第三，测试的模型并不在开源最前沿。英伟达和 AMD 已经用 AgentX 公布了更大模型的结果，比如 DeepSeek V4 Pro 和 Kimi K3。模型越大、发布越新，在新芯片上跑通就越复杂。话虽如此，OpenAI 在 Jalapeño 上跑通的模型也不算小。

性能分析

OpenAI 的设计目标是性能/瓦特。原因很简单：OpenAI 目前受限于数据中心电力，而不是预算或机房空间，所以每兆瓦的 token 数至关重要。在 Computex 2026 上，黄仁勋说性能/瓦特、可靠性和长寿命是未来 GPU 的核心特性。他原话是：“如果你有 1 吉瓦的电力，那么每瓦的吞吐量就是收入。”他还提到，仅仅因为芯片更便宜就选择错误的架构，没有意义。

英伟达在 Hot Chips 2026 的 Vera 演讲中也强调了这一点，同时展示了同样的收入图表：“如今的数据中心受电力限制。”电力至关重要，并驱动收入。

运营商无法轻易获得更多兆瓦。增加 GPU 和增加电网容量的时间尺度差异巨大。数据中心电力上限受到诸多限制。例如公用事业互联、基础设施、冷却能力以及 UPS/备用发电设计。电网延迟屡屡超过硬件和建设进度，催生了对表后电力容量的需求。即在数据中心本地建造燃气轮机和现场发电机。这些容量位于公用事业电表之后，不依赖公共电网。这让运营商无需等待电网互联和公用事业升级即可为设施供电。这正是 xAI 的 Colossus 2 严重依赖表后电力的原因，而其实际电网连接远远滞后。更多信息见我们的能源模型。

正如我们在 X 帖子中所写，tok/s/MW 可简化为每焦耳 token 数。因为瓦特就是每秒焦耳。因此 tok/s/MW 代表系统效率，以及将能量转化为 token 的能力。

在这方面，即便与 Rubin 相比，Jalapeño 也胜出。OpenAI 的 Jalapeño 每兆瓦 STP 输出 token 吞吐量，超过了 Vera Rubin 的 MTP 结果。该结果由英伟达与 CoreWeave 在七月发布。它也远超 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 势均力敌。每美元产出几乎相同的输出 token 数。然而如前所述，Jalapeño 的结果未使用推测解码。Vera Rubin 的结果则使用了推测解码。推测解码可使每 token 成本降低约 3-5 倍。当 Jalapeño 实现推测解码后，其提供 token 服务的成本效益将更高。当然，部分 TCO 优势来自于避开英伟达的高利润率，转向博通较低（但仍很高）的利润率。但这并非全部原因。例如，Meta 和微软的 AI ASIC 项目投入更久却未能成功落地。这表明成本只是方程式的一部分。Jalapeño 的完整 TCO 拆解，请参见 SemiAnalysis AI Cloud TCO 模型。

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

而它确实做到了。在 Kimi K2.5（Cursor Composer 2.5 基于此模型）上，Jalapeño 达到近 700 tok/s/user。这一速度是第二佳芯片 100 tok/s/user 的 9 倍以上。

在 GPT-OSS 上，又是另一场碾压。Jalapeño 的等交互吞吐量每兆瓦，几乎是 GB200 最高吞吐点的两倍。更是 GB200 并发 1 点的 50 倍以上。更高并发的 Jalapeño 点使用 EP8。

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

AgentX - InferenceXv3：CUDA 护城河在智能体推理中还能守住吗？

深入规格与架构

所有这些结果均来自 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-1150W，这一表现更加可敬。由于 Jalapeño 面向推理而非训练，OpenAI 无需推高 TDP 来最大化 FLOPs。这可以理解。但无论如何，上述结果表明 Jalapeño 提供了可观的峰值理论 FLOPs。

与其他加速器直接对比时，Jalapeño 拥有每瓦最高的 HBM 带宽，以及每瓦最高的 FLOPs。这一水平可与 1800W 的 Rubin Max-Q 配置相提并论。

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 年逐步爬坡，大部分产出目前安排在明年年底。有关单元数量和平均售价的更多细节，请参阅 SemiAnalysis Accelerator Model。

可以说，OpenAI Jalapeno 是一款真正的大规模 ASIC。

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

Jalapeño 架构

深入架构来看，该芯片的矩阵引擎使用 MXFP 数值格式和权重驻留脉动阵列，与 TPU 类似。但与 TPU 直接相比，它支持更小的形状/维度，这意味着它不会像更大脉动阵列上形状不匹配的矩阵乘法那样出现奇怪的性能悬崖。

它还具有 64 位标量核心和 FP32/INT32 向量核心。OpenAI 还在托盘层面投入了冗余设计，并在核心和通道层面内置了良率回收。他们声称，芯片设计中 AI 辅助使 SIMD 面积减少 8%，矩阵引擎面积减少 10%。虽然他们未说明具体工艺/电压/温度（PVT）条件，但也提到 AI 辅助模块相比初始模块改善了时序和功耗。

Jalapeño 架构设计专注于消除 KVCache 和权重的内存搬运，以及固定延迟和开销，以便相比其他加速器，即使在小批量或小形状下也能更接近原始峰值算力/带宽。

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

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

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

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

代价是，Jalapeño 因此依赖良好的预取来确保内存请求及时到达，而这更难预测和推理。然而，借助 Codex 在良好框架中获取详细追踪信息，为给定形状找到具有最佳预取的最优内核，可能几乎不需要人工干预。我们认为这正是 OpenAI 能如此迅速跑通 DeepSeek R1、Kimi K2.5 和 GPT-OSS 的原因。

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

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

低延迟/小批量推理的上限性能远优于 GPU。GPU 受限于启动延迟、屏障延迟、内存系统延迟等固定开销。

即使大批量或长上下文，也有潜力更接近硬件 roofline。

这附带一个警告：即使理论上存在上限性能，实际内核可能更难达到该性能。因此，其方法似乎是：

针对所有工作负载形状，设计最高上限性能

让 Codex 完成繁重工作，找到实现该上限的内核

OpenAI 团队在 Jalapeño 上启动 InferenceX 工作负载，周转速度极快。

我们因此对这一方法感到乐观。

如果 Jalapeño 成功，将释放强烈信号。

行业对编程模型和完美通用编译器的执念，会被前沿 AI 模型打破。

OpenAI 像写汇编一样编写 Jalapeño 内核。

每个内核都有手工调优代码，部分约 3000 行。

还有正确性检查和自定义 sanitizer 支持。

早期内核工作是人在回路，而非全自动。

后来转向更规模化的内部版 Codex。

OpenAI 计划向企业客户推销这一版本。

内部服务引擎叫“Teacup”。

有趣的是，OpenAI 此前没有内部 MLA 内核实现。

直到他们用 InferenceX 对 DeepSeek 做基准测试。

Codex 能如此快速写出可用高效内核，且无需内核工程团队介入。

这展示了软件流水线的开发能力。

OpenAI 用 Gluon 为 Jalapeño 编程。

Gluon 是 OpenAI 的内核编程语言。

Gluon 构建在 Triton 之上，保留 Triton 的 SPMD（Single Program Multiple Data）编程模型。

但它暴露了底层编程抽象。

例如针对 NVIDIA GPU，它提供映射到 PTX 指令的 API。

包括 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 这样的 OpenAI 模型，目前跑在 NVIDIA GPU 上。

它们被用来设计芯片，对 CUDA 护城河构成真实威胁。

NVIDIA 自己的 GPU 正在实时助推潜在继任者。

跨时间比较，我们还能看到 Jalapeño 的开发速度。

不到两周，某些交互场景的吞吐量提升超 2 倍。

我们从 Jalapeño 团队拿到的每个 tarball 都内含奇妙世界。

不仅内核性能提升，8 天内 Jalapeño 团队启用了 TP32。

基于此前 TP8 配置，扩展到单系统之外，实现完整机架级配置跑大模型。

这开发速度确实令人印象深刻。

为在真实硬件运行前验证性能，OpenAI 还有个模拟器“chilisim”。

其精度在实测硬件的 5%以内，使用固定宽度 trace 总线。

A0 上的追踪能力有限，但 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 万次 rollouts。

要不要 Disagg，这是个问题

我们之前提到，OpenAI 没有在这些芯片上使用 prefill-decode 分离。

这让我们惊讶，因为 NVIDIA 和 AMD GPU 性能从 PDD 中显著受益。

即使是在同构硬件上。

我们来深挖 Jalapeño 团队为何这样做。

当工作负载固定时，prefill-decode 分离看起来很有吸引力。

Prefill 和 decode 对硬件压力不同。

将每个阶段分配到单独调优的池子，可在选定输入输出比下提高效率。

但生产流量不会保持该比例。

输入输出序列长度、并发、缓存命中率、推测接受率和延迟目标全天都在变化。

一旦设备被分成 prefill 和 decode 池，prefill 需求过多会让 decode 芯片空闲，请求排队。

但 decode 需求过多则相反。

运营者必须持续预测正确拆分，为两侧预留备用容量。

并重新平衡一个理想比例不断变化的系统。

在统一系统中，某些资源在特定阶段可能利用不足。

但每台设备仍可用于服务下一个请求。

在分离式系统中，整块芯片可能仅因属于错误池子而闲置。

本地利用率看起来更好，但全局利用率可能很差。

分离还会破坏局部性。

prefill worker 产生 decode worker 立即需要的大型 KV cache。

系统必须跨网络传输该状态，生成才能继续。

这增加了带宽消耗、同步、排队和另一个故障域。

成本也随输入序列长度上升，因为 KV cache 在增长。

然而，避免移动 KV 主要是功耗和延迟优化。

愿意移动一些 KV 可提高硬件利用率，代价是功耗和单请求延迟。

可互换集群能在延迟敏感请求和吞吐导向批次间转移容量。

固定拆分则在流量组合变化时闲置硬件。

此外，上下文长度改变 attention 与 FFN 工作之间的平衡。

任何固定硬件比例仅在设计点附近高效。

同样的限制也适用于投机解码。草稿模型必须以极低延迟向验证器提供候选 token。把两者分到不同专用池，会把紧耦合解码循环变成分布式协议。额外的通信和协调可能吃掉草稿省下的延迟。把两个模型放在同一设备和低延迟结构上，才能保住让投机值得做的局部性。

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

从日式到印度（微辣到特辣）：Katsu、Vindaloo 和 Chana——这些咖喱菜如何拼成机架系统？

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

ASIC 机架由 16 个 Vindaloo 托盘和 8 个扩展交换机托盘（6 个本地+2 个全局）组成，名为“Chana”。每个 Vindaloo 托盘包含 8 个 Jalapeño ASIC，每机架总计 128 个 Jalapeño ASIC。ASIC 通过铜缆背板连接到每个 Chana 交换机托盘，类似于 Nvidia 的 Oberon。扩展拓扑分为本地域和全局域。本地域覆盖机架内 128 个 ASIC。全局域连接最多 16 个机架或 2,048 个 ASIC。我们将在下面更详细解释带宽和拓扑。

侧挂主机机架的供电约 50kW（生产中 31kW），ASIC 机架消耗 130kW。整个双机架系统约 160kW。从功耗看，这基本相当于一个双宽 GB300 机架。

OpenAI 可以在单个扩展网络内连接多达 2,048 个 Jalapeño XPU。扩展网络由两个域组成。本地域通过背板连接机架内全部 128 个 XPU。全局域使用铜缆和光互连混合，连接 16 个机架的 2,048 个 XPU。每个机架包含 8 个 Chana 交换机托盘。中间 6 个 Chana 交换机用于本地域。每个带一个 102.4T Tomahawk 6 交换 ASIC。顶部和底部的 2 个 Chana 交换机用于全局域。我们认为可能是 2x 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 的无源铜缆用于本地扩展。

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

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

全局域采用纯 rail 架构，由全局域内的 8 条 rail 组成。我们认为 OpenAI 通过每个机架安装的光电路交换机（OCS）路由全局域中的光链路。每个 XPU 的 1.6Tb/s 全局带宽将通过铜背板到达全局交换机托盘。然后通过前面板的 1.6T 光模块离开交换机。它先进入无源光交换机，再离开机架。这使扩展域规模达到 2,048 个 XPU，由 16 个机架、每个 128 个 XPU 组成。

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

下一步

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

我们还在 Accelerator 模型中涵盖下一代芯片的产量、数量和时程。

之后部分为付费内容，由于权限问题未做更多编译，而前文中已有较多信息反应 OpenAI 对英伟达芯片的挑战。对于关注芯片板块以及英伟达股价的玩家来说，这些信息将提供新鲜且扎实的参考。