OpenAI 过去几年一直在秘密研发一款代号 Jalapeño 的 AI 推理芯片，并于刚刚举行的 Hot Chips 2026 大会上首次公开亮相。此前业界已传出其成功流片的消息，而随着大会发布，更多技术细节终于浮出水面。OpenAI 还邀请了媒体走进实验室，对芯片进行实机演示，并使用 InferenceX 基准测试套件验证其真实推理性能。据了解，Jalapeño 是 OpenAI 与博通联合打造的定制 ASIC，完全围绕大语言模型推理需求设计。项目于 2024 年中正式启动，从团队组建、架构设计到最终流片，仅用了约 16 个月，对于一款高端 ASIC 而言，这样的研发周期极为罕见。
更令人意外的是，这并非一款“试水之作”。按照半导体行业的惯例，第一代自研芯片往往需要经历数次迭代才能具备竞争力，但 Jalapeño 的首代产品已经展现出极强实力。在 InferenceX 的测试中，它在多个主流开源大模型上的表现超过了我们此前评测过的 NVIDIA、AMD 以及 Google 的同类 AI 芯片。
OpenAI 将这一成绩归功于极致的软硬件协同设计。与许多专门针对单一模型或单一推理环节优化的 AI 芯片不同，Jalapeño 的目标并非追求某一个场景的极限性能，而是打造一款能够覆盖低延迟交互、高吞吐推理等多种工作负载的通用推理处理器。
接下来，我们将结合 InferenceX 的测试结果，深入解析 Jalapeño 的芯片架构、软件栈设计以及实际性能表现。
大家都说 OpenAI 的芯片是专门为 OpenAI 模型设计的，但这是错误的，OpenAI 制造了一款用于 AI 推理的通用芯片。这时间表简直不可思议。这表明，人工智能确实能加速芯片设计的说法并非空穴来风。尽管时间表如此之快，但OpenAI投入了大量资金，做出了务实的设计决策，而且他们的团队实力雄厚，所以取得这样的成绩并不令人意外。而HBM4的使用使其性能足以媲美NVIDIA和AMD的旗舰级GPU：外界关于这款芯片的许多报道，主要来自 OpenAI 在公开场合的几句表述。他们曾提到，这款芯片会针对自家模型进行专门优化，而其他芯片并非如此。但这一说法并不准确。
实际上，Jalapeño 是一款面向通用推理场景的 AI 芯片，能够兼容多种大模型和不同类型的推理负载，并不仅限于 OpenAI 模型。包括我们自研的 InferenceX 基准测试，也曾在实验室中与 OpenAI 工程师共同完成验证。期间，OpenAI 还曾演示过在该芯片上运行《Doom》游戏——这只是将游戏移植到芯片平台，并借助 Codex 提示完成运行。
在每瓦性能（Perf/W）测试中，我们以每兆瓦可提供的实际 Token 吞吐量作为衡量标准。结果显示，Jalapeño 的能效表现明显领先于其他参测芯片。值得注意的是，Jalapeño 的测试成绩未启用多 Token 预测（MTP），而图表中的其他芯片均采用各自 SKU 的最佳配置，并开启了 MTP 加速，因此这一结果更具参考价值。
从实际测试来看，Jalapeño 在几乎所有推理场景中的性能功耗比都优于 NVIDIA Blackwell，而且这种领先并非依赖针对某一特定负载进行调优。无论是低延迟的交互式推理，还是高吞吐量的批量推理，它都保持了较高的能效表现。如果仅比较单 Token 预测（STP）模式，优势则更加明显。在 DeepSeek R1 模型上，当并发数为 1 时，Jalapeño 每位用户的生成速度超过 700 Token/秒；在 Kimi K2.5 和 GPT-OSS 等模型上，这一数字进一步提升至约 1400 Token/秒。更重要的是，这些成绩全部建立在 STP 基础上，无需依赖推测性解码（Speculative Decoding）、多 Token 预测（MTP）或预填充与解码分离等优化技术。同时，针对 GSM8K 的评测结果也显示，其模型精度与 NVIDIA 平台基本保持一致。不过，这组数据仍需结合背景来看待。首先，公开性能数据主要由 OpenAI 提供。虽然实验室已经验证了 InferenceX 的运行结果，但尚未完整复现全部基准测试，也没有验证 AgentX 的全部成绩。相比传统的 8K/1K 单轮测试，AgentX 更贴近真实生产环境，它包含长上下文、多轮交互和复杂缓存访问，会同时考验路由、前缀缓存、缓存管理及卸载等系统能力，因此更能反映实际部署表现。其次，将 Jalapeño 与 Blackwell 对比，本身并不是最合理的参照。真正意义上的竞争对象，应是同样采用 HBM4 的下一代架构 Vera Rubin。目前 Rubin 系统已开始向客户交付，而 Jalapeño 仍处于工程样品阶段，因此两者处在更接近的技术周期。事实上，定制推理芯片在特定工作负载上超越通用 GPU，本就是行业普遍预期。此前 NVIDIA 在 CoreWeave 发布会上公布的数据也显示，Vera Rubin NVL72 的每兆瓦吞吐能力约为 GB200 NVL72 的 5.4 倍，这也成为后续比较的重要基准。第三，目前参与测试的并非最新一代开源旗舰模型。NVIDIA 与 AMD 已陆续公布基于 AgentX、DeepSeek V4 Pro、Kimi K3 等更大模型的测试结果，而模型规模越大、发布时间越新，对新硬件的软件栈要求也越高。尽管如此，OpenAI 此次测试所采用的模型同样属于高性能推理模型，并非轻量级网络。OpenAI 将研发重点放在每瓦性能（Perf/W）上，原因也十分直接：当前 AI 数据中心最大的约束不是资金，而是电力。对于运营商而言，每增加 1 兆瓦可输出多少 Token，直接决定数据中心的收入能力。这一观点也与 NVIDIA 的判断高度一致。在 Computex 2026 上，黄仁勋将每瓦性能、可靠性和寿命列为未来 GPU 的三大核心指标，并表示：“如果你拥有 1GW 电力，每瓦吞吐量就意味着收益。” 随后在 Hot Chips 2026 介绍 Vera Rubin 时，NVIDIA 再次强调，如今数据中心真正受限的是电力供应，而不是芯片数量。原因在于，GPU 可以快速部署，但电力基础设施却无法同步扩张。数据中心容量受到公用事业接入、输电网络、制冷系统、UPS 与备用电源等多重限制，电网建设周期往往远长于硬件交付周期。因此，越来越多运营商开始采用 表后电源（Behind-the-Meter，BtM），即在园区内部建设燃气轮机和现场发电系统，以绕过公共电网扩容的等待时间。xAI 的 Colossus 2 数据中心便大量依赖这种模式，在电网尚未完全到位的情况下提前获得兆瓦级供电能力。从物理意义上看，由于 1 瓦 = 1 焦耳/秒，因此 Token/秒/兆瓦 本质上等价于 每焦耳可生成的 Token 数。换句话说，这一指标衡量的是系统将电能转换为 AI 输出的效率，也是未来大规模推理基础设施最关键的指标之一。按照 OpenAI 公布的数据，Jalapeño 的 STP 每兆瓦 Token 吞吐量甚至超过了 Vera Rubin 在启用 MTP 条件下的公开成绩，同时也大幅领先 GB200 的 2025 年测试结果。值得注意的是，这种比较采用的是 Rubin 2026 年 7 月的最新数据、GB200 2025 年的早期数据，以及 Jalapeño 当前的工程测试结果，三者均处于软件尚未完全成熟的阶段，因此具有较高的可比性。随着编译器、推理框架和系统软件持续优化，无论是 Rubin 还是 Jalapeño，后续性能仍有进一步提升空间。在性能/总拥有成本 (perf/TCO) 方面，Vera Rubin 和 Jalapeño 势均力敌，每美元产出的代币数量几乎相同。然而，如前所述，Jalapeño 的结果是在未采用推测性解码的情况下获得的，而 Vera Rubin 的结果则采用了推测性解码。推测性解码可以将每个代币的成本降低 3 倍以上。当 Jalapeño 实现推测性解码后，其代币成本将大幅降低。当然，这种总拥有成本优势的部分原因在于，Jalapeño 用 Broadcom 较低（但仍然很高）的利润率取代了 Nvidia 的高利润率。但这并非全部原因。例如，Meta 和微软的 AI ASIC 项目尽管投入了更长时间却未能取得成功，这表明成本只是影响因素之一。在架构方面，OpenAI 选择不将预填充和解码 (PD) 功能分散到不同的芯片池中。草案模型和主模型共享相同的芯片和架构，这种设计理念牺牲了一些理论效率来换取实际操作的流畅性。其原因在于工作负载组合会随时间变化，例如，随着模型发展经历了三个阶段（知识模型、推理模型和智能模型，详见我们最近的文章），输入、缓存写入、缓存读取和输出令牌的比例发生了显著变化。因此，预先选择固定数量的异构预填充芯片和解码芯片可能会导致效率下降。OpenAI 在此架构中采用同构芯片池，并力求使芯片在所有任务上都能保持良好的性能。确实如此。在 Kimi K2.5（Cursor Composer 2.5 就是基于该芯片）上，Jalapeño 的运算速度接近 700tok/s/user，是性能第二好的芯片（100tok/s/user）的 9 倍以上。在 GPT-OSS 上，情况更是惨烈。Jalapeño 的每兆字节交互吞吐量几乎是 GB200 最高吞吐量的两倍，并发吞吐量更是 GB200 的 50 倍以上。Jalapeño 的高并发吞吐量数据使用了 EP8。这些结果令人印象深刻！不过，我们还是需要指出一些不足之处：它们只是 8k1k 的测试用例，这种工作负载更容易进行调优，而且目前还没有AgentX 的测试用例。正如我们在AgentX文章中提到的，多轮次、长上下文的工作负载会对服务堆栈的更多方面造成压力，例如路由器和前缀缓存。要想在代理工作负载中脱颖而出，还需要进行更多优化。更多相关信息，请阅读AgentX文章。所有这些结果都是在Jalapeño芯片A0工艺阶段取得的，当时该项目才进行了9个月。但目前B0工艺阶段的芯片已经在晶圆厂生产！B0工艺阶段的优化使其每瓦性能比之前的A0工艺提升了约25%。具体来说，B0工艺阶段的芯片在台积电N3P工艺制造的单个光罩大小的计算芯片上实现了13.4 PFLOPs的MXFP4性能。相比之下，尺寸相近、采用相同工艺节点制造的单个Rubin计算芯片，其高密度Rubin NVFP4性能为17.5 PFLOPs。考虑到 Jalapeño 的 TDP 仅为 700W，而 Rubin 的 TDP 则高达 900-1150W（每个计算芯片），Jalapeño 的表现更加令人满意。由于 Jalapeño 的设计重点在于推理而非训练，OpenAI 无需为了最大化 FLOPs 而提高 TDP 也就不足为奇了。但无论如何，上述数据表明 Jalapeño 能够提供相当可观的峰值理论 FLOPs。与其他加速器直接比较时，Jalapeño 具有最高的每瓦 HBM 带宽和最高的每瓦 FLOPs，可与 1,800W Rubin Max-Q 配置相媲美：非封装 I/O 由一个配备 32 条 800G SerDes 通道的 N3E I/O 芯片提供，用于计算架构。其中 24 条通道（600GB/s）用于机架内的本地扩展，8 条通道（200GB/s）用于全局扩展，即 2048 个 XPU 的多机架域。系统 I/O 使用 PCIe Gen 5 连接到 x86 主机 CPU。Jalapeño 将搭载 HBM4 显存，使其成为继英伟达和 AMD 之后，较早采用该技术的芯片之一，甚至超越了成熟的 TPU 和 Trainium 项目。Jalapeño 的核心架构原则之一是最大限度地利用 HBM 带宽，因此，如果 HBM 并非最佳选择，则违背了这一目标。这使得 Jalapeño 的单封装内存带宽高达 15.4TB/s，优于所有其他采用 HBM3E 的加速器。15.4TB/s 的带宽表明其 HBM4 的引脚速度可达 10Gbps，略胜于英伟达 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 的表现更胜一筹。我们并不认为英伟达的硬件性能较差，而是 Jalapeño 的软件开发进度比英伟达更快。这体现了软硬件协同设计的强大之处，而这正是新兴的 ASIC 实验室团队超越更成熟的商业芯片厂商的关键所在。出乎意料的是，从零开始或许也让 OpenAI 受益，因为它可以做出全新的架构决策，而无需担心向后兼容性或旧版本软件的问题。虽然 OpenAI 已拥有Jalapeño 的工程样品，但目前的生产计划是逐步增加产量，预计在 2027 年后开始，大部分产量将于明年年底交付。可以说，OpenAI Jalapeño 是一款真正的高产量 ASIC 芯片。与Rubin的进度相比，Jalapeño的速度快得惊人。正如之前所示，尽管Rubin起步较早，但Jalapeño的成绩最终还是超过了Rubin。现在深入分析其架构，该芯片的矩阵引擎采用 MXFP 数值格式和权重固定脉动阵列，类似于 TPU。但与 TPU 直接比较时，它支持更小的形状/尺寸，这意味着它不会像 TPU 那样，在处理形状怪异的矩阵乘法运算时，在较大的脉动阵列上出现性能断崖式下降的情况。它还配备了 64 位标量核心和 FP32/INT32 向量核心。OpenAI 还投入资源在芯片托盘级别实现了冗余设计，并在核心和通道级别内置了良率优化机制。他们声称，在芯片设计过程中，AI 辅助使 SIMD 面积减少了 8%，矩阵引擎面积减少了 10%。虽然他们没有详细说明具体的工艺/电压/温度 (PVT) 条件，但他们也提到，与初始模块相比，AI 辅助模块在时序和功耗方面均有所改进。Jalapeño 架构设计着重于消除 KVCache 和权重的内存移动以及固定延迟和开销，以便即使对于小批量或小形状，也能比其他加速器更接近原始峰值浮点运算/带宽。核心和 HBM 被划分成多个切片，每个核心切片都拥有对其自身 HBM 切片的低延迟本地视图。切片间的同步通过高带宽专用网络进行。这种极简的内存层次结构已经赋予 Jalapeño 相对于 GPU 的巨大潜在优势，因为 GPU 的内存访问必须遍历复杂的内存系统，导致较大的延迟，而这些延迟必须通过更大的内存结构来分摊或隐藏。这种选择是可行的，因为通过仔细放置权重和键值，可以将核心之间的同步限制在有限的、已知的、高带宽的通信（例如可以与计算重叠的张量并行通信）上。此外，还有一个额外的通用片上网络（NOC），用于通用通信和访问可扩展网络。总的来说，与英伟达和谷歌相比，OpenAI 通过简化 NOC 和内存子系统，显著节省了功耗并获得了巨大的性能提升。在计算核心设计上，OpenAI 采用了一条与主流 AI 加速器截然不同的路线。Jalapeño 使用的是带 L1 缓存的乱序执行（Out-of-Order，OoO）核心，而不是 GPU、TPU 等常见的软件管理暂存区（Scratchpad）+ 异步 DMA 架构。这种设计最大的意义，在于尽可能消除屏障同步、数据搬运等固定延迟，让硬件无需依赖大量并行任务去掩盖开销，因此更容易逼近理论带宽与算力上限。当然，这种架构也存在取舍。由于更多依赖硬件缓存体系，Jalapeño 对预取（Prefetch）机制提出了更高要求，需要准确预测数据访问模式，系统行为也比 Scratchpad 更难分析和优化。不过，如果结合 Codex 以及底层执行追踪数据，寻找不同模型形状下的最优内核与预取策略，很可能实现高度自动化，而无需工程师大量手工调优。这也被认为是 OpenAI 能够在短时间内完成 DeepSeek R1、Kimi K2.5、GPT-OSS 等多个模型适配的重要原因。另一个值得关注的特点，是 Jalapeño 的计算核心能够高效处理小尺寸矩阵。这意味着它对不同模型结构、批次大小和矩阵维度的适应性更强，不必依赖大规模填充或严格的维度对齐来维持计算效率。相比之下，TPU、Trainium 以及 Etched 等采用大型脉动阵列（Systolic Array）的芯片，往往需要更大的 Batch 或可整除的矩阵维度，否则容易出现分块利用率下降的问题。从整体思路来看，OpenAI 并非单纯追求峰值算力，而是围绕消除固定延迟来优化整个系统，希望在延迟与吞吐构成的帕累托曲线上，都尽量接近最优解。这首先体现在低延迟、小批量推理场景。传统 GPU 的交互式推理，往往受到 Kernel 启动、屏障同步和内存访问等固定开销限制，而 Jalapeño 则试图将这些成本降至最低，从而显著提升单用户响应速度。另一方面，在大批量、长序列推理任务中，其架构也具备持续逼近硬件性能上限的潜力，并不局限于低并发应用。不过，理论峰值并不等于实际性能。真正的挑战在于，如何为各种模型形状编写能够逼近上限的计算内核。OpenAI 给出的答案并不是构建更复杂的通用编译器，而是把这项工作交给 AI 自己——由 Codex 自动搜索、生成并优化内核实现。结合团队快速完成 InferenceX 等工作负载移植的表现，这一路径已经展现出一定可行性。如果 Jalapeño 最终取得成功，它传递出的信号或许比芯片本身更重要：未来 AI 芯片竞争的核心，未必是谁拥有最完美的编程模型或通用编译器，而是谁能够借助大模型，实现软硬件协同优化的自动化。Jalapeño 的内核开发方式，更接近传统的汇编级编程，而不是依赖成熟编译器自动生成代码。OpenAI 透露，每个计算内核都经过人工精细调优，部分核心代码长度超过 3000 行，同时还配备了完整的正确性验证和定制化清理工具。早期开发阶段，这项工作主要依靠内核工程师完成；但随着内部大型 Codex 系统逐渐成熟，内核生成开始迅速向自动化演进。未来，OpenAI 也计划将 Codex 作为企业级开发工具对外提供，其内部推理引擎则被称为 Teacup。一个颇具代表性的案例是，在使用 InferenceX 对 DeepSeek 模型进行性能测试之前，OpenAI 自身并没有 MLA（Multi-head Latent Attention）内核实现。然而，Codex 几乎无需内核团队介入，便快速生成了可运行且性能优异的 MLA 内核，展现出 AI 自动完成底层系统开发的能力。在软件层面，Jalapeño 并非直接编写 CUDA，而是采用 OpenAI 自研的 Gluon 编程语言。Gluon 建立在 Triton 之上，保留了 SPMD（单程序多数据）的编程模型，同时提供更接近硬件的底层抽象。例如，在 NVIDIA GPU 上，它可以直接映射到 PTX 指令，包括 MMA、TMA、mbarrier 等底层能力。Gluon 最核心的创新，是引入了 布局（Layout） 抽象。简单来说，布局定义的是“硬件资源”与“张量元素”之间的映射关系，例如某个 Warp 的寄存器对应矩阵中的哪一个元素。OpenAI 为此设计了一套名为 Linear Layouts（线性布局） 的布局代数，用数学方式统一描述和变换数据布局，使布局转换能够被证明正确，并实现更高效的内存交换与数据组织。Jalapeño 的执行模型也体现出鲜明特色。每个 Gluon 程序都会映射为一个持久线程（Persistent Thread），线程在多个 Tile 上持续运行，任务分配主要由程序本身完成，而非依赖硬件调度器。这意味着它更适合持久内核（Persistent Kernel）的编程模式。与此同时，每个核心都具备数据预取和解耦乱序执行能力，开发者可以通过信号量等待预取数据，在计算与访存之间实现更细粒度的重叠执行。最耐人寻味的一点在于，如今帮助 OpenAI 设计 Jalapeño 的 AI 模型，例如 GPT-5.6 Sol，本身仍运行在 NVIDIA GPU 之上。换句话说，CUDA 生态正在训练和驱动一套可能削弱 CUDA 护城河的新架构——NVIDIA 的 GPU，某种意义上正在加速潜在竞争者的诞生。从公开的开发进度来看，Jalapeño 的迭代速度同样令人印象深刻。仅仅不到两周时间，部分交互式推理场景的吞吐量便提升了 3 倍以上。几乎每一次新的内部版本发布，都伴随着显著的性能突破，也显示出其软硬件协同优化仍处于快速演进阶段。不仅内核性能得到了提升，Jalapeño 团队还在短短 8 天内启用了 TP32，在之前 TP8 配置的基础上，从单个系统扩展到大型机架级配置，实现了完整的机架级运行。这样的开发速度着实令人印象深刻。为了在进行实际硬件运行之前验证性能，OpenAI 还提供了一个名为“chilisim”的模拟器，其精度与实际硬件的测量结果相差不到 5%，该模拟器使用固定宽度的总线。A0 芯片上的跟踪性能有限，但在 B0 芯片上得到了显著提升，这很可能得益于 A0 芯片上实际运行的输入数据。工程师们已经演示了 Codex CLI 运行一个名为“Raiku”或“5.3 Codex Spark”的内部模型，其 TPOT 为 1.2 毫秒。该团队还展示了 Codex 编写的直接在芯片上运行的演示程序：36 FPS 的 Doom、FP32 流体动力学模拟和“Liquid Light”鼠标拖拽可视化。在模型方面，OpenAI 的内部巨型内核方案（昵称“gigakernel”）围绕一个在设备端循环运行的单个巨型内核构建，以降低 CPU 开销和启动时间。该团队也在进一步探索测试时计算策略，尤其关注如何有效地利用 100 万次部署。此前我们曾提到，OpenAI 在 Jalapeño 上没有采用预填充-解码分离（Prefill-Decoding Disaggregation，PDD）。这一点颇为意外，因为在 NVIDIA 和 AMD 的 GPU 平台上，即便使用同构硬件，PDD 往往也能带来可观的推理性能提升。那么，OpenAI 为什么反而放弃了这一路径？原因在于，PDD 的优势建立在工作负载相对稳定的前提之上。由于预填充（Prefill）和解码（Decode）对计算、带宽和缓存的需求截然不同，将两者拆分到各自独立优化的资源池，确实能够在特定输入输出比例下获得更高效率。但真实的数据中心并非静态环境。用户请求的输入长度、输出长度、并发规模、KV Cache 命中率、推测解码接受率以及延迟目标，都在持续波动，理想的 Prefill 与 Decode 比例也随之不断变化。一旦硬件被固定划分为预填充池和解码池，资源错配便会迅速出现：当 Prefill 请求激增时，解码节点可能大量空闲，而新请求却排队等待；反之，若 Decode 压力升高，则预填充节点又会闲置。运营商不得不持续预测流量变化，动态调整两类资源的配比，并在两侧预留冗余容量，以应对不断变化的负载。Jalapeño 选择的是另一种思路——统一资源池。在统一架构下，虽然某些计算单元在特定阶段的利用率未必达到最高，但每一颗芯片都能够随时接手下一项任务，不受 Prefill 或 Decode 身份限制。因此，它牺牲的是局部阶段的极致利用率，换来的是整个集群更高的全局资源利用率和更稳定的调度效率。换句话说，OpenAI 更看重的并非单一工作点的最佳性能，而是在真实生产流量持续波动的情况下，让整套推理系统始终保持接近最优的整体效率。解耦也会破坏局部性。预填充工作进程会生成一个庞大的键值缓存，解码工作进程需要立即使用该缓存，因此系统必须先通过网络传输该状态，才能继续生成。这会增加带宽消耗、同步、排队以及另一个故障域。此外，由于键值缓存会增长，成本也会随着输入序列长度的增加而上升。然而，避免移动键值主要是为了优化功耗和延迟；而允许移动部分键值则可以提高硬件利用率，但代价是增加一些功耗和每次请求的延迟。可互换的资源配置方案会在对延迟敏感的请求和对吞吐量要求较高的批次处理之间灵活切换资源，而固定的资源配置方案则会在流量组合发生变化时自动分配硬件资源。此外，上下文长度会改变注意力机制和前馈神经网络（FFN）工作之间的平衡，因此任何固定的硬件配置比例只有在接近其设计点时才有效。同样的限制也适用于推测性解码。草稿模型必须以极低的延迟向验证者提供候选令牌。将两者分别部署在专用池中，可以将紧密耦合的解码循环转变为分布式协议。额外的通信和协调可能会消耗掉草稿节省的延迟。将两个模型都部署在同一设备和低延迟架构上，可以保持推测性解码的根本价值所在——局部性。然而，在需求足够大、稳定且可预测的情况下，分解处理仍然能够胜出，尤其是在传统GPU需要处理大量特定阶段的批次才能达到良好吞吐量时。但这并非免费午餐。Jalapeño 采用的是CPU 主机机架 + ASIC 计算机架组成的双机架架构，由 OpenAI 与 Celestica 共同完成整机系统设计。
其中，主机机架包含 16 个名为 Katsu 的 CPU 节点，每个节点与 ASIC 机架中的一个 Vindaloo 计算托盘一一对应。每个 Katsu 节点配备两颗 AMD EPYC Turin 处理器、1.5TB DRAM、2 个 E1.S 接口、2 个 M.2 SSD，并提供 400Gbps（2×200G）的前端网络带宽。CPU 与 ASIC 之间则通过 8 根外部 PCIe DAC 铜缆 直连，这些线缆沿机架前部水平布置，实现高速互联。
计算机架由 16 个 Vindaloo 托盘 和 8 个 Chana 扩展交换托盘 组成，其中 6 个负责机架内交换，2 个负责跨机架互联。每个 Vindaloo 托盘集成 8 颗 Jalapeño ASIC，因此单个 ASIC 机架总计部署 128 颗芯片。所有 ASIC 均通过铜缆背板连接至 Chana 交换层，整体拓扑与 NVIDIA Oberon 机架的设计思路较为相似。
整个网络分为两个层级：首先是机架内部的 128 颗 ASIC 本地域，其次是跨机架扩展形成的 全局域，最多可连接 16 个机架、2048 颗 Jalapeño ASIC，为大规模推理集群提供统一互连能力。
在功耗方面，主机机架约需 50kW（量产版本预计降至 31kW），ASIC 机架约 130kW，因此一套完整双机架系统总功耗约 160kW。这一能耗水平与一套双宽配置的 NVIDIA GB300 NVL72 机架基本相当，但计算资源组织方式则明显不同。
Jalapeño 的扩展能力并不依赖单一机架，而是构建了一套最多连接 2048 颗 XPU 的两级交换网络。整个互连体系分为两个层次：机架内部的本地域（Local Fabric），以及跨 16 个机架的全局域（Global Fabric）。
每个机架内部配备 8 个 Chana 交换托盘。其中，6 个负责本地交换，每个托盘集成一颗 102.4Tbps Broadcom Tomahawk 6 交换 ASIC，用于连接机架内全部 128 颗 Jalapeño XPU；另外 2 个则承担全局互连任务，预计每个托盘可容纳两颗 Tomahawk 6，总交换能力达到 204.8Tbps。
在本地域中，128 颗 XPU 通过全连接方式接入 6 颗 Tomahawk 6，每颗 XPU 拥有 4.8Tbps 单向带宽。这一设计意味着，每颗 XPU 需要 48 对差分线（DP） 与背板连接，单个机架仅本地互连就需要 6144 对无源铜缆，形成超高密度的铜缆交换网络。
跨机架通信则由全局域完成。16 个机架、共 2048 颗 XPU 通过铜质背板、电交换机、1.6T 光模块以及光路交换机（OCS）组成混合互连网络。每颗 XPU 分配 1.6Tbps 单向全局带宽，对应背板上的 16 对差分线。数据首先通过铜背板进入全局交换托盘，再由前面板的 1.6T 光收发器 输出，经无源光交换机动态路由至其他机架，实现大规模集群互联。
综合本地域与全局域，每颗 Jalapeño XPU 共需要 64 对差分连接，整个机架的背板铜缆规模达到 8192 对 DP。如此庞大的铜缆数量，也反映出 OpenAI 在机架内部仍坚持以铜互连为主，而将光互连主要用于跨机架扩展。
值得注意的是，全局网络采用的是 8 条 Rail（轨道） 组成的纯 Rail 拓扑，而非传统的胖树（Fat Tree）结构。光路交换机负责在各机架之间动态建立光链路，使 16 个机架能够组成一个统一的 2048 XPU 推理域，在保证带宽的同时，也兼顾了扩展性与网络调度效率。
由于扩展网络成本仅占系统总成本的约 10%，这种灵活性为未来 10-20 万亿参数模型或 200-400 万个令牌上下文窗口提供了宝贵的选择。在部署方面，OpenAI 正与 neoclouds 合作，并与数据中心合作伙伴在 1 月份之前收集可靠性数据，同时优化从对接点到机架的部署时间。
*免责声明：文章内容系作者个人观点，半导体芯闻转载仅为了传达一种不同的观点，不代表半导体芯闻对该观点赞同或支持，如果有任何异议，欢迎联系我们。
喜欢我们的内容就点“在看”分享给小伙伴哦~
五度妙笔
企业透视镜
API商城
数据库
