Jalapeño 拆解：OpenAI 的第一代推理 ASIC，Prefill-Decode 分离不再必要了？

封面图

先把最扎眼的一组数扔出来。

700 W 封装功耗，第一代芯片，A0 流片版本。配置是“素颜”的：STP 单步自回归解码，没开 speculative decoding，没做 prefill/decode 分离。在 SemiAnalysis 的 InferenceX 上，它对 GB200/GB300 拿到 1.5–1.9× 的 throughput-per-kW、1.7–3.6× 的端到端延迟优势，最小 TBT 低 2.7–4.1×。在 GB200/GB300 最优 TBT 区间里，整体吞吐的领先更夸张，达到 8.6–104.3×。

这几个数我第一次看到的时候是不信的。第一代 ASIC 打赢在位旗舰，这事在历史上基本没发生过。

然后我把 Hot Chips 讲稿和 SemiAnalysis 原文都翻了一遍，把带宽账一条条算，算完之后我的判断变了——但不是变成“NVIDIA 完了”，而是变成一个更细的问题：这颗芯片赢在哪一层？

因为这里有个很别扭的事实：Jalapeño 用的是 HBM4，15.4 TB/s；GB200/GB300 用的是 HBM3E，8 TB/s。归一到功耗，Jalapeño 的内存带宽/W 是 GB300 的 3.85×。可它在 peak throughput/W 上的领先只有 1.5–1.7×。领先幅度比代际红利还小。

这就有意思了。如果只是“新一代内存 + 新一代工艺”，那 1.5–1.9× 根本不需要解释，甚至该问它为什么没赢更多。真正需要解释的是另一头：为什么在低延迟侧，它的领先幅度反而超出了任何单项规格比值？

所以本文只回答一个问题：把 Jalapeño 的领先拆成「工艺 + HBM4 代际红利」/「架构与 dataflow」/「系统与网络」/「编译与 kernel 软件」四个桶，每个桶到底装了多少。

顺带说一句，这个名字读作 /ˌhæl.əˈpeɪn.joʊ/，“哈勒-PEI-尼欧”，重音在 pe，ñ 不读 n。别读成 “Jala-pen-o”，我一开始就读错了🤣。

1. 它为什么现在出现，以及那组数字的可信区间

1.1. 约束不是钱，是电

理解 Jalapeño 全部设计取舍的前提只有一句话：OpenAI 的约束是数据中心可用电力，不是资本，也不是机房面积。

SemiAnalysis 写得很直接：OpenAI is currently limited by datacenter power, not by budget or floorspace, and thus tokens per MW is paramount.

有意思的是，NVIDIA 说的是同一件事。Jensen 在 Computex 2026 上的原话是 If you have 1 gigawatt of power, then throughput per watt is revenue；NVIDIA 自己在 Hot Chips 2026 的 Vera 演讲里也放了同一张营收曲线，配的话是 The data center is power limited today。

而 OpenAI 官方讲稿把评价基准写在了非常显眼的位置：Most important spec: perf/W on end-to-end workloads。它甚至专门列了三个 NON GOALS——用了多少颗芯片、单芯片吞吐、以及 TTFT。

TTFT 被明确列为 non-goal，这个后面 Part 4 会咬回来。

为什么电是硬约束？因为加 GPU 和加电网容量的时间常数完全不同。变电站互联、冷却、UPS/备电设计都不是季度级能改的东西，电网审批周期反复跑输硬件和土建周期——这也是 xAI 的 Colossus 2 大量依赖表后（BtM）自建燃机的原因。

所以指标从 per-chip 转到 per-watt / per-MW。而 tok/s/MW 约掉单位之后就是 tokens/joule，一个纯物理量。

1.2. workload 在漂移，这决定了后面所有架构选择

第二层背景是负载本身在动。

模型从 knowledge → reasoning → agentic 走了三个阶段，input / cache-write / cache-read / output token 的配比一直在变。官方讲稿把一个 agentic 请求拆成三段完全不同的硬件画像：

阶段	算力	内存带宽	通信
Prefill（编码上下文）	HIGH	LOW	SMOOTH
Draft model（推测）	小模型、ultra-low batch	—	LATENCY BOUND
Spec-verify（解码验证）	attention 偏算力	MoE 吃 HBM BW	BURSTY

注意这里是三段，不是两段。OpenAI 在 Hot Chips 的演示框架用 MTP=7：7 轮小 draft 模型 + 1 次大模型批量验证，一次最多产出 8 个 token，把昂贵的大模型 pass 数量压到最多 1/8。

阶段种类从 2 变成 3，专用池的组合爆炸风险就从“押一个比例”变成“押一个三维配比”。这是 Part 4 同构池论证的真正起点。

官方给这个取舍留了一句很锋利的话：dark silicon is cheaper than idle accelerators——芯片上暂时没用的模块，比机柜里闲着的整颗加速器便宜。因为后者照样要付封装、HBM、I/O、网络和散热的基线功耗。

1.3. 供应链：Broadcom 出 NetIP 与 Silicon Implementation，Celestica 出系统

第三层是产业侧。Broadcom 是芯片侧伙伴，Celestica 负责 board/rack 的系统级集成——这两家在官方致谢页上被单独点名。

HBM 侧，Jalapeño 成了 HBM4 的一个新需求方，而且是在 NVIDIA 和 AMD 之后、TPU 和 Trainium 之前采用 HBM4 的。SemiAnalysis 推测供应商是 Samsung（原文用的是 likely，属于推测，不是确认）。

一个值得记住的商业观察：SemiAnalysis 认为，即使这颗芯片最终没有大规模部署，OpenAI 也已经赢了——花几亿美元做 ASIC，换来的是和 NVIDIA 谈价格、配额、backstop 时的实际议价权。

1.4. 评测数字：完整对照

官方口径是 InferenceX，nominal ISL/OSL 8k/1k，weight dtype f4，single-turn，按 package TDP 归一（Jalapeño 700 W、GB200 1.2 kW、GB300 1.4 kW、MI355X 1.4 kW）。Jalapeño 侧全部使用 STP。

模型	对比系统	TDP 归一	peak mixed TPS/kW	E2E latency	min TBT	旧最优 TBT 点吞吐
GPT-OSS 120B	GB200（STP）	700 W vs 1,200 W	85,448 vs 44,960（≈1.9×）	1.03 s vs 1.80 s（≈1.7×）	0.69 vs 1.87 ms（≈2.7×） 1,459 vs 535 tok/s/user	22,935 vs 427（≈53.7×） @535.28 tok/s/user
DeepSeek R1 670B MXFP4	GB300（STP）	700 W vs 1,400 W	19,641 vs 11,781（≈1.7×）	1.65 s vs 5.99 s（≈3.6×）	1.43 vs 5.90 ms（≈4.1×） 700 vs 169 tok/s/user	12,258 vs 118（≈104.3×） @169.41 tok/s/user
DeepSeek R1 670B MXFP4	GB300（MTP）	700 W vs 1,400 W	19,641 vs 12,951（≈1.5×）	1.65 s vs 3.69 s（≈2.2×）	1.43 vs 3.04 ms（≈2.1×） 700 vs 329 tok/s/user	1,940 vs 225（≈8.6×） @328.95 tok/s/user
Kimi K2.5 1T MXFP4	GB300（STP）	700 W vs 1,400 W	18,195 vs 11,862（≈1.5×）	1.56 s vs 5.31 s（≈3.4×）	1.44 vs 5.48 ms（≈3.8×） 694 vs 182 tok/s/user	6,744 vs 120（≈56.1×） @182.46 tok/s/user

整体来看，Jalapeño 全方位领先于 GB200/GB300 平台：

交互性：最小 TBT 低 2.1–4.1×，E2E 延迟低 1.7–3.6×。
在同为 GB200/GB300 的最优 TBT 点时，Jalapeño 的 perf/W 高 8.6–104.3×。
peak throughput 下的 perf/W 高 1.5–1.9×。

这里有个必须说清的点，很多二手报道都糊过去了：当 GB300 打开 MTP，四个指标全部收窄——1.7×→1.5×、3.6×→2.2×、4.1×→2.1×，最夸张的 104.3× 直接掉到 8.6×。

所以“对比系统都用了各自最优配置”这个说法要分情况：SemiAnalysis 那张 headline 图（按 all-in utility MW 归一）里对手确实全开了 MTP；但官方讲稿的三组 headline 数字里，只有 R1 那一组给了 STP-vs-MTP 的对照，另外两组是 STP 对 STP。

两套归一方式也不一样：官方按 package TDP，SemiAnalysis headline 按整机 all-in utility MW，混着引用会得到互相矛盾的倍数。

1.5. 这组数字的边界条件（这节比上面那张表重要）

要判断一篇评测能不能信，看的不是它给了多少数，而是它承认了多少边界。这组数据的边界相当清楚：

（1）数据由 OpenAI 产出，不是独立复现。 SemiAnalysis 原文：all numbers are provided to us by OpenAI. We verified the InferenceX runs in person in the lab, but we did not run the full suite of InferenceX benchmarks nor have we seen AgentX results. 现场见证了部分 run，不等于独立跑完整套件。

（2）HBM 代际不对等，作者自己说这个对比“不完整且不公平”。 原文：we believe that comparison to Blackwell is somewhat incomplete and unfair. Jalapeño is really competing against chips like Rubin that also use HBM4. 更麻烦的是时间线：Vera Rubin 系统已经在向客户出货，而 Jalapeño 还只有工程样品。

（3）对 Rubin 的比较，结论要分指标看。 按 tok/s/MW，Jalapeño 的 STP 结果超过 NVIDIA/CoreWeave 七月公布的 Vera Rubin MTP 结果；但按 perf/TCO，原文写的是 Vera Rubin and Jalapeño are head-to-head，每美元产出的 token 数几乎一样。也就是说：Jalapeño 现在最强的卖点不是“更便宜”，而是“同样一兆瓦电能产更多 token”。

（4）AgentX 没跑，而 AgentX 才是真正的考卷。 8k/1k single-turn 是相对好调的负载。长上下文、多轮 agentic 会压测 router、prefix cache 机制、cache 管理、offload 基础设施——These are not tested by single turn 8k1k. 恰好能暴露“不做 PD 分离”代价的实验，就是还没做的那个实验。

（5）测的模型不在开源前沿。 NVIDIA 和 AMD 已经在 AgentX 上发过 DeepSeek V4 Pro、Kimi K3 这类更大更新的模型结果。模型越大越新，在新芯片上 bring-up 越难。

（6）反向加分项，得公平地记上。 一是 Jalapeño 侧没用 MTP/spec decode，而它的对手在 SemiAnalysis 那张图上全开了；二是这批数据全部来自 A0 stepping，B0 已经在 fab 里，perf/W 还有约 25% 的提升空间。这两条都是保守方向。

1.6. 分析框架：Jalapeño 优势的四个来源桶

后面的讨论里，我会把 Jalapeño 领先幅度拆成四个领域（简称桶），每个领域后续分别分析其为整体提升带来的贡献：

桶	内容	回填位置
A · 工艺 + HBM4 代际红利	N3P vs 对手节点、HBM4 15.4 TB/s vs HBM3E 8 TB/s	Part 2 结尾
B · 架构与 dataflow	slice 化局部性、weight-stationary 阵列、消除固定开销	Part 2 结尾 + Part 5
C · 系统与网络	128/2048 两级 scale-up、3:1 带宽分层	Part 3 结尾
D · 编译与 kernel 软件	Gluon、Linear Layouts、Codex 参与优化	Part 4 结尾

先给一个提前预告，免得你读到后面才发现结论反直觉：A 桶足以解释 peak throughput 侧的全部 1.5–1.9×，甚至解释过头了；B 桶的贡献几乎全部落在低延迟侧。

2. 单芯片：规格、两处口径歧义，以及微架构的“为什么”

2.1. 官方规格与两个必须先说清的口径问题

官方讲稿给的完整规格：

项	值
Matrix compute	mxfp8×mxfp8 = 3.4 PFLOP/s mxfp8×mxfp4 = 6.7 PFLOP/s mxfp4×mxfp4 = 13.4 PFLOP/s
Memory system	15.4 TB/s，216 GiB
Scale-up	Local = 128 ASICs @ 600 GB/s Global = 2048 ASICs @ 200 GB/s
Power	700 W
系统（2048 ASICs）	mxfp4 27 EFLOP/s；32 PB/s，432 TiB

制程与封装形态信息来自 SemiAnalysis（第三方）：reticle-size compute die，TSMC N3P；off-package I/O 是一颗独立的 N3E I/O chiplet；封装 floorplan 上是 6 个 HBM4 stack 围着 compute die，I/O chiplet 单独一侧。

HBM4 的 pin speed，这是个很干净的校验：

216 GiB ÷ 6 stacks       = 36 GiB/stack
15.4 TB/s ÷ 6            = 2.567 TB/s/stack
2.567 TB/s × 8 ÷ 2048 bit = 10.03 Gb/s per pin
反算：2048 bit × 10 Gb/s × 6 = 15.36 TB/s ≈ 15.4 TB/s  ✓

10 Gbps pin speed 成立，比 NVIDIA 在 Rubin 上拿到的 9.6 Gbps 略高一档。

关于 TDP 与实测功耗的差值。 700 W 是 package TDP。机柜级有个可以直接除的数：ASIC 机柜实测 130 kW，130 kW ÷ 128 = 1.02 kW，也就是每个 XPU 位置还要摊约 320 W 的机柜级开销（交换、光模块、供电损耗、风扇）。

不过供电侧有个可推算的旁证：机柜里装了 8 个 1U 33 kW power shelf，4 × 33 kW = 132 kW ≈ 130 kW 实测 draw，另 4 个正好构成 2N 冗余。

口径歧义：那个 “800G SerDes” 不是 lane 速率。

SemiAnalysis 原文写的是 an N3E I/O chiplet with 32 lanes of 800G SerDes，其中 24 lanes 给 local（600 GB/s），8 lanes 给 global（200 GB/s）。

这两句话自己打自己。24 lanes 跑出 600 GB/s = 4.8 Tb/s，反推每 lane 是 200 Gb/s，不是 800 Gb/s。

到底哪个对？有硬证据。SemiAnalysis 自己给了差分对数量：local 侧每 XPU 是 48 个差分对（DP），global 侧是 16 DP。

local :  24 lanes × 2（TX+RX）= 48 DP  ✓
global:   8 lanes × 2（TX+RX）= 16 DP  ✓
合计   :  64 DP/XPU × 128 XPU = 8,192 DP/rack  ✓（原文给的就是 8,192）

差分对数量和 lane 数严格对上了。所以：lane 速率是 200 Gb/s，“800G” 指的是编组后的端口速率（4×200G）。 后面所有拆解都以带宽数字为准。

交换机侧还有一条独立旁证。Broadcom Tomahawk 6 有两个 SerDes SKU：

BCM78910：1,024 lane × 106.25G PAM4  → 128×800G（每端口 8 lane）或 512×200G
BCM78914：  512 lane × 212.5G  PAM4  → 128×800G（每端口 4 lane）或 64×1.6T

212.5G PAM4 正是 200 Gb/s 数据速率对应的信号速率。 SemiAnalysis 拓扑图上标的是 128×800G，而每颗 XPU 到每台 TH6 是一条 800G——若走 BCM78914，一个 800G 端口恰好是 4 条 lane，与 XPU 侧 24 lane ÷ 6 台 = 4 lane/台 完全一致。

2.2. 微架构：每个选择解决什么问题

官方讲稿把设计动机讲得很坦白。它先否掉了一个常见归因：

观察到的延迟不是”硬件光速”决定的。长延迟路径来自统一内存子系统的高争用路径、彼此不同步的独立核让全局 memory fence 变得昂贵、以及集中式资源中介网络访问。

也就是说，它认为 GPU 推理的主要损失不在带宽墙，而在“数据在途时算力和内存都在等”。所以四个设计动作都指向同一件事。

（1）core slice 与 HBM slice 一一配对。 官方图上是 HBM slice 1..64 对 Core slice 1..64，每个 core slice 对自己那片 HBM 有 low-latency、high-bandwidth 的 local view。

为什么这么切？因为这是“用局部性换有效带宽利用率”。SemiAnalysis 说得更直白：这种极简内存层级让 Jalapeño 相对 GPU 拿到一个很大的潜在优势，因为 GPU 上的访存必须穿过复杂的内存系统，产生的大延迟只能靠更大的 shape 来摊销或掩盖。

关键词是 shape，不是带宽。这一条是理解 Part 4 的钥匙。

（2）双网络：专用 collective + 通用 NoC。 常见跨核模式走专用 collective 网络（高带宽、低延迟），不需要快路径的流量走共享 NoC（带宽低、延迟高、更灵活），scale-up 以太网桥挂在共享 NoC 上。

这是“分离资源通路，而不是分离芯片”——同一个思路后面在机柜级又出现了一次（TP 走高带宽域、EP 走低带宽域）。

（3）weight-stationary systolic array，但支持小维度。 SemiAnalysis：matrix engine 用 MXFP 数值格式和 weight stationary systolic array，similar to TPU，但支持更小的维度，所以不会像大 systolic array 那样被形状别扭的 matmul 打出性能悬崖。

取舍在哪？权重驻留降低了权重侧的重复搬运，代价是对 batch/序列维度的映射、以及 MoE 稀疏路由，提出了更强的编译期要求。这个代价后面由 Gluon + Codex 来付。

必须标一句：官方讲稿本身只说了 core 里有 tensor / SIMD / scalar engine，没有直接确认 weight-stationary systolic array。这一条是 SemiAnalysis 的解读。

（4）反常识的一条：OoO 标量核 + L1 cache。 多数 AI 加速器走的是 software-managed scratchpad + 异步 DMA。Jalapeño 反而上了乱序执行流水线和 L1。

目的还是消除固定开销——比如 barrier 延迟，在别的加速器上只能靠“每核干更多活”来摊销。代价 SemiAnalysis 写得很清楚：relies on good prefetching to ensure timely arrivals of memory requests, which is less predictable and more difficult to reason about.

更难推理的硬件，怎么办？这就是 Part 4 观点 2 的伏笔。另外，64 位标量核带 OoO 流水线跑在数学引擎前面，把数据流进硬件队列；严格顺序执行的 matrix/vector 核就绪时，数据已经在队列里等着了。

（5）频率与阵列规模的粗算（推算）。 Hot Chips 现场 Q&A 环节，提到芯片频率约 1.8 GHz，若成立：

13.4 PFLOP/s ÷ 2 FLOP/MAC ÷ 1.8 GHz = 3.72×10⁶ MAC/cycle（全芯片）
÷ 64 core slice                      ≈ 5.8×10⁴ MAC/core/cycle ≈ 241²

量级上对应每核一个 240×240 级、或四个 128×128 级的阵列。纯反推，仅作量级参考。

（6）良率与冗余。 tray 级冗余，core 和 channel 级做了 yield harvesting。这对 reticle-size die 是必需品，也解释了为什么 compute die 和 I/O die 要分开——I/O chiplet 放 N3E 而不是 N3P，既省下昂贵节点的面积，又把 SerDes 这种低良率、强 shoreline 需求的部分挪出主 die。

2.3. 横向对比表

这张表是本 Part 的重点交付物，但它不是排行榜，原因见表下的口径注。先看原始规格：

芯片	定位	工艺	低精度算力（口径见注）	片上 SRAM	片外内存	内存带宽	TDP
OpenAI Jalapeño	推理	N3P（compute）+ N3E（I/O chiplet）	MXFP4 13.4 PF；MXFP8 3.4 PF；混合 6.7 PF（封装，dense）	未公开	HBM4 216 GiB	15.4 TB/s	700 W（封装）
NVIDIA GB200 / B200	训练+推理	TSMC 4NP，208B tr，2 die	FP4 dense 10 PF（封装）〔二手〕	未公开	HBM3E 192 GB	8 TB/s	1,200 W（液冷封装）
NVIDIA GB300 / B300	训练+推理	TSMC 4NP，208B tr，2 die	FP4 dense 15 PF（封装）〔二手〕	未公开	HBM3E 288 GB	8 TB/s	1,400 W（液冷封装）
NVIDIA Vera Rubin R200	训练+推理	”3nm”，336B tr，2 die	NVFP4 dense 35 PF（封装）〔一手〕；另有 50 PF “Inference” 口径	未公开	HBM4 288 GB	22 TB/s〔一手〕	未公开（Max-Q 1,800 W / Max-P 2,300 W 为二手）
AMD MI355X	训练+推理	—	FP4 ~20 PF 级，dense/sparse 口径不明	未公开	HBM3E 288 GB	8 TB/s	1,400 W
AMD MI455X / Helios	训练+推理	—	FP4 ~40 PF/GPU（由 2.9 EF ÷ 72 反推）	未公开	HBM4 432 GB	19.6 或 23.3 TB/s，来源冲突	未公开
Google TPU v7 Ironwood	训练+推理〔官方文档〕	未公开	FP8 4,614 TF；BF16 2,307 TF〔一手〕。未见 FP4 口径	未公开	192 GiB（代际未在引用文档中明确）	7,380 GB/s	未公开
Google TPU 8t “Sunfish”	训练	未公开（Broadcom 合作）	FP4 ~12.6 PF〔二手〕	128 MB〔单一弱来源〕	216 GB	~6.5 TB/s	未公开
Google TPU 8i “Zebrafish”	推理	未公开（MediaTek 合作）	~10.1 PF，格式 FP4/FP8 存在冲突	384 MB〔二手〕	288 GB	~8.6 TB/s	未公开
Microsoft Maia 200	推理	TSMC N3	10.1 PetaOPS FP4（微软原文写 OPS 而非 FLOPS）	272 MB	HBM3E 216 GB	7 TB/s	750W
Groq 3 LPX（NVIDIA 品牌）	推理	Samsung SF4X	FP8 1.2 PF/chip〔二手〕	500 MB/chip	无 HBM；节点侧 FPGA 挂载 DRAM 最多 256 GB 供 KV cache	片上 150 TB/s	未公开
Taalas HC1	推理（权重硬连线）	TSMC 6 nm，815 mm²，53B tr	未以 FLOPS 口径公布；Gen1 自定义 3/6-bit，Gen2 转标准 FP4	未单列	无片外内存，权重硬连线	—	2.5 kW 是”每服务器”
Cerebras WSE-3	训练+推理	4T tr，900k cores	125 PFLOPS，精度未说明	44 GB（唯一内存）	无	21 PB/s（片上）	未公布单 wafer TDP

归一化与系统层面：

芯片	FLOPS/W	内存带宽/W	scale-up 域规模与介质	编程模型成熟度
Jalapeño	19.1 TF/W（MXFP4）	22.0 GB/s/W	128（柜内铜背板）/ 2,048（铜+无源光），以太网	早期。自有闭环（Gluon + Linear Layouts + Codex + Teacup）
GB200	8.33 TF/W	6.67 GB/s/W	NVL72 = 72 封装，铜背板，NVLink 1.8 TB/s 双向/GPU	CUDA，最成熟
GB300	10.7 TF/W	5.71 GB/s/W	NVL72 = 72 封装，铜背板，NVLink 1.8 TB/s 双向/GPU	CUDA，最成熟
Vera Rubin R200	19.4 TF/W @1,800 W 假设	12.2 GB/s/W @1,800 W 假设	NVL72 = 72 封装，NVLink 3.6 TB/s/GPU	CUDA，最成熟
MI355X	~14 TF/W（口径不明，慎用）	5.71 GB/s/W	Infinity Fabric，节点级	ROCm，中等
MI455X / Helios	无法计算（TDP 未公开）	无法计算	UALink，200 Gbps/lane，72 GPU/柜，柜级聚合 260 TB/s	ROCm，中等
TPU v7 Ironwood	无法计算（TDP 未公开）	无法计算	9,216 chips，3D torus，ICI 1,200 GB/s 双向	JAX/XLA 成熟；PyTorch 经 TorchTPU
TPU 8t / 8i	无法计算	无法计算	8t 9,600 / 8i 1,152（“Boardfly”）	同上，v8 细节未公开
Maia 200	无法计算（TDP 未公开）	无法计算	ATL 协议，2.8 TB/s 双向/chip，6,144 加速器	早期
Groq 3 LPX	无法计算（TDP 未公开）	无法计算	RealScale C2C mesh，256 chips/柜（= 128 GB SRAM/柜），柜内铜 640 TB/s	专用编译器，模型覆盖窄
Taalas HC1	无法计算（只有服务器级功耗）	—	未公开	模型专用，基本没有通用编程模型
Cerebras WSE-3 / CS-4	归一化无意义，见注⑥	归一化无意义	CS-4 声称 2 µs wafer-to-wafer	专用栈，模型覆盖窄

口径注（不读这几条，上面两张表会被误读）：

① dense vs sparse 。 GB200 常被引用的 20 PF、机架 1.44 EF 是带稀疏口径；GB300 的机架 1.08 EF 是 dense 口径。dense 对 dense 才是 720 → 1,080 PF。表中一律取 dense。

② Rubin 的 35 PF 与 50 PF 都对，但基准不同。 35 PF 是 NVIDIA 自己带 Dense specification 脚注的封装级数字；50 PF 标的是 “NVFP4 Inference” 且没有 dense 脚注。注意 50 ÷ 35 = 1.43，所以 50 PF 不是 2:4 稀疏（那应该是 2×），不要把它当“稀疏 = 2 倍 dense”来用。

③ per-die 与 per-package 必须分清。 Rubin 单 compute die 17.5 PF 正是封装级 35 PF 的一半。流传的“Rubin 每 compute die 900–1,150 W”没有一手出处，是把封装级 1,800/2,300 W 除以 2 得来的。Rubin 的封装 TDP 至今未公开，所以表中它的 per-watt 两列必须挂“@1,800 W 假设”这个前提。

④ TDP 口径以官方讲稿为准。 Jalapeño 700 W / GB200 1.2 kW / GB300 1.4 kW / MI355X 1.4 kW 这一组来自 OpenAI 官方讲稿的归一说明，是本文能拿到的最干净的可比基准。不要用 superchip 级功耗（GB200 约 2.7 kW 含 1 Grace + 2 GPU 封装）去和 700 W 的单封装比。

⑤ Cerebras 无法做 per-watt 归一，这不是数据缺失，是口径不成立。 它没有“芯片 TDP”这个概念，功耗是系统/机柜级的。另外它自己的数字也有未解决的冲突：CS-4 产品页称“由三颗 WSE-3 Turbo 驱动”，但 250 PF / 43.2 PB/s 相对单颗 WSE-3 只有约 2 倍，不是 3 倍。

⑥ Groq 与 Taalas 有几个广泛流传但未经证实的数字：Groq 的 375 W / 750 TOPS INT8 / GlobalFoundries 工艺，以及 Taalas 的“约 250 W 每芯片”。后者的公开口径是每服务器 2.5 kW，不是每芯片。

⑦ NVL144 与 NVL72 是同一个机架。 NVL144 是 GTC 2025 按 die 计数的旧名，CES 2026 改回按封装计数的 NVL72。

分簇点评：

GPGPU（GB200 / GB300 / Rubin / MI355X / MI455X）：容量-带宽-灵活性三项都很均衡，灵活性一项断层领先——它们同时要吃训练。代价是延迟侧：为通用性付出的固定开销（kernel launch、barrier、深内存层级）必须靠大 shape 摊销，所以在小 batch / 低并发区间必然吃亏。Rubin 是唯一在 per-watt 上和 Jalapeño 同量级的对手，而且带宽绝对值（22 TB/s）反而更高——它不是被 Jalapeño 的规格打败的，只是软件成熟度的时间差目前对 Jalapeño 有利。

TPU 类 ASIC（v7 / v8）：路线和 Jalapeño 最像——systolic array + 编译器强耦合 + 大 scale-up 域（9,216 的 3D torus 远超 Jalapeño 的 2,048）。一个明显差别是：Ironwood 公开口径里没有 FP4，最低是 FP8。

云厂自研第一代（Maia 200）：定位与 Jalapeño 高度重合——同样 N3、同样 216 GB 内存、同样纯推理。两处显著差异：Maia 200 有 272 MB 片上 SRAM 这个明确数字（Jalapeño 没公开），而带宽只有 7 TB/s（HBM3E）对 15.4 TB/s（HBM4）。HBM 代际选择上的分野，几乎解释了两者定位的全部差距。 另外它的 scale-up 域是 6,144，比 Jalapeño 大三倍。

SRAM-only dataflow（Groq）：占的是“单位容量带宽极高、总容量极低”这个角。500 MB/chip、256 chip 一柜才 128 GB SRAM——装不下前沿模型的权重。最值得注意的是它现在的产品形态已经妥协了：节点侧挂了最多 256 GB 的 FPGA DRAM 专门放 KV cache。 纯 SRAM 撑不住 KV 增长，这一点它自己的产品路线已经承认了。

硬连线（Taalas）：极端的一端——权重烧进 ASIC 里，没有片外内存，也基本没有通用编程模型，Gen1 跑的是 Llama-3.1-8B 这个量级。能效上限最高，灵活性下限最低。它的适用条件很清楚：模型足够小、足够稳定、部署量足够大到能摊销掉“换模型就要换芯片”的成本。 这三条同时成立的场景存在，但不是前沿模型服务。

wafer-scale（Cerebras）：把“单位容量带宽”推到 21 PB/s 的物理极限，代价是 44 GB 的容量天花板。它和 Groq 死在同一个地方，只是量级更极端。Part 5.3 会算这个容量天花板在 10T 参数下意味着什么。

2.4. 回填 A 桶与 B 桶：1.5–1.9× 里，代际红利解释了多少

现在算这篇文章最想算的一笔账。以下全部是推算，假设写在算式里，你可以换假设重算。

先把两个规格比值摆出来（对 GB300，均按 package 口径）：

内存带宽/W：Jalapeño 15,400 GB/s ÷   700 W = 22.0 GB/s/W
            GB300    8,000 GB/s ÷ 1,400 W =  5.71 GB/s/W
                                    比值 = 3.85×

低精度算力/W：Jalapeño 13.4 PF (MXFP4 dense) ÷   700 W = 19.1 TFLOPS/W
              GB300     15   PF (FP4  dense) ÷ 1,400 W = 10.7 TFLOPS/W
                                        比值 = 1.79×

顺手做一个能验证上面算法没错的交叉校验。SemiAnalysis 有一句很具体的话：Jalapeño 拥有最高的 HBM 带宽/W，以及除 1,800 W 的 Rubin Max-Q 配置之外最高的 FLOPs/W。拿 Rubin 的一手规格（35 PF dense NVFP4、22 TB/s，封装级）套进去：

Rubin @1,800 W：35 PF ÷ 1,800 W = 19.4 TFLOPS/W   > Jalapeño 19.1  ✓ 与原文一致
                22,000 GB/s ÷ 1,800 W = 12.2 GB/s/W < Jalapeño 22.0  ✓ 与原文一致

两条都对上了，说明 700 W / 1,400 W / 1,800 W 这组功耗口径和我的算法是自洽的。

顺便记一个从官方规格表里读出来的架构细节：Jalapeño 从 MXFP8 到 MXFP4 拿到了 13.4 ÷ 3.4 ≈ 4×，而 Blackwell 从 FP8 到 FP4 只有 2×。两个操作数位宽各减半就换来 4 倍算力，是面积正比的理想缩放。 这暗示它的乘法阵列是可重构或位切片式的，而不是在固定 FP8 数据通路上打包 FP4。不过这 属于推断。

然后对照实测（下表均为 Jalapeño 对 GB300 的公开数据比值）：

操作点	实测领先	该点的主导资源	与规格比值的关系
peak mixed TPS/kW	1.5–1.7×（vs GB300）	大 batch，算力与带宽混合	低于带宽/W 的 3.85×
E2E latency	3.4–3.6×	混合	介于两者之间
min TBT（并发≈1）	3.8–4.1×	纯权重流式读取，带宽绑定	接近带宽/W 的 3.85×
旧最优 TBT 点吞吐	56–104×	GPU 在该点被固定开销压死	远超任何规格比值

这张表就是本文的核心判断：

在 peak throughput 点，1.5–1.7× 完全落在 A 桶（工艺 + HBM4）能解释的范围内，甚至还没有把工艺+HBM4的优势全表现出来。 带宽/W 有 3.85× 的优势，最后只兑现出 1.5–1.7×，说明在大 batch 高吞吐区间，Jalapeño 并没有把硬件优势全部转成 token——B 桶在这里贡献接近零，甚至是折价的。

架构红利全部集中在低延迟侧。 min TBT 的 3.8–4.1× 大致就是带宽比值，而“在对手旧最优 TBT 点上的 8.6–104.3×”这个数量级，任何规格比值都解释不了。它只能来自一件事：GPU 在小 batch / 低并发时被 kernel launch、barrier、内存层级延迟这些固定开销压住，而 Jalapeño 把这些开销从设计里拿掉了。

给一个更算术的分解尝试，但假设很强：

假设 DeepSeek R1 测试的 min TBT 点两侧都用 8 芯片 TP 组（Jalapeño 侧 SemiAnalysis 明确说是
eight-chip system；GB300 侧未披露，此为假设）：
  R1 MoE 激活约 37B 参数，FP4 → 每 token 权重读取 ≈ 18.5 GB
  Jalapeño：8 × 15.4 TB/s = 123.2 TB/s → roofline 0.150 ms，实测 1.43 ms → 效率 10.5%
  GB300  ：8 ×  8.0 TB/s =  64.0 TB/s → roofline 0.289 ms，实测 5.90 ms → 效率  4.9%
  分解：4.1× ≈ 1.93×（聚合带宽，A 桶）× 2.1×（roofline 效率，B 桶）

这个分解的弱点必须说明：GB300 侧的芯片数没有公开。 如果它在 min TBT 点用了比 8 更宽的 TP（对最小化 TBT 是合理做法），那 A 桶份额会变小、B 桶份额会变大。也就是说，这个分解在方向上偏保守，但具体的份额完全取决于那个未公开的配置。

3. 机柜与互联：把 “half-flattened two-level Clos” 算到闭环

说实话这是全文我花时间最多的一节。因为拓扑图看着简单，但我第一遍按图上的连线读，带宽账怎么都对不上，特别是 global domain 那部分。后面会讲我错在哪。

3.1. 机柜拆解：Katsu / Vindaloo / Chana

三个代号的对应关系，SemiAnalysis 原文写得很明确：

代号	是什么	构成
Katsu	CPU host tray（2U）	2 颗 Turin 级 AMD EPYC + 1.5 TB RDIMM；每 tray 400G（2×200G）前端网络
Vindaloo	Jalapeño ASIC tray（1U）	8 颗 Jalapeño
Chana	scale-up switch tray	6 个 local（1U，各 1× TH6 102.4T）+ 2 个 global（2U，各 2× TH6 = 204.8T）

系统是双机柜：一个 CPU host rack + 一个 ASIC rack。

ASIC rack（43U）：
  16 × Vindaloo（1U，8 ASIC）        = 128 Jalapeño   ✓
   6 × local Chana（1U，102.4T TH6）
   2 × global Chana（2U，2×TH6）      = 4 颗 global TH6 ASIC
   8 × 1U 33 kW power shelf（6×6.6 kW PSU）
CPU rack（43U）：
  16 × Katsu（2U）                    = 32 颗 EPYC，24 TB DRAM
   4 × 1U 33 kW power shelf + ToR Ethernet switch

Katsu 和 Vindaloo 一一对应，之间走 8 根外部 PCIe DAC 线横穿机柜前面板——8 根线对 8 颗 ASIC，正好每颗 ASIC 一条 PCIe Gen5 到 x86 host。host : ASIC = 1 : 8。

功耗：host rack provisioned 约 50 kW（生产实测 31 kW），ASIC rack 130 kW，双机柜合计约 160 kW，SemiAnalysis 的比喻是“基本等于一个双宽 GB300 机柜”。

机柜级聚合指标（可自行校验）：

算力：13.4 PF × 128 = 1,715 PF = 1.7 EFLOPS MXFP4      ✓
容量：216 GiB × 128 = 27,648 GiB = 27 TiB               ✓（pod 432 TiB ÷ 16）
带宽：15.4 TB/s × 128 = 1,971 TB/s ≈ 1.97 PB/s          ✓（pod 32 PB/s ÷ 16）

铜缆背板，SemiAnalysis 的类比是“和 NVIDIA 的 Oberon 一样”。global 交换托盘“2×TH6 / 204.8T”这一条，原文用的是 we think could consist of，属于推算，虽然机柜 elevation 图上是这么画的。

3.2. Local domain：零上行，一次完美闭环

先看柜内。官方口径：Local = 128 ASICs @ 600 GB/s。

Tomahawk 6 单芯片 = 102.4 Tb/s = 128 × 800G 端口
每颗 XPU → 每台 TH6 一条 800G（= 4 × 200G lane）
每颗 XPU 共 6 × 800G = 4.8 Tb/s = 600 GB/s              ✓

现在做全局校验：

交换侧总容量：6 台 × 102.4 Tb/s = 614.4 Tb/s
XPU 侧总需求：128 颗 × 4.8 Tb/s = 614.4 Tb/s
                                  ─────────  完全相等

两边严丝合缝。这说明一件很重要的事：这 6 台 TH6 的 102.4T 全部朝下给 XPU，零上行。 128 个 800G 端口正好接 128 颗 XPU，一颗不多一颗不少。

线缆侧也对得上：24 lane × 2 DP = 48 DP/XPU，48 × 128 = 6,144 DP 的无源铜缆——原文给的就是 6,144。

这就是 “flattened” 的那一半：柜内是单层全互联，不是 leaf-spine。

3.3. Global domain：8 rails × 8 台交换机

官方口径：Global = 2048 ASICs @ 200 GB/s。SemiAnalysis 补充：global 域采用 rail-only 架构，8 个 rail。

每颗 XPU 的 global 侧用的是 I/O chiplet 剩下的 8 个 lane：

8 lane × 200 Gb/s = 1.6 Tb/s = 200 GB/s                 ✓
8 lane × 2 DP     = 16 DP/XPU                           ✓
48 + 16 = 64 DP/XPU；64 × 128 = 8,192 DP/rack           ✓

这 1.6 Tb/s 先经铜缆背板送到柜内的 global switch tray，然后在前面板侧转成 1.6T 光模块，经无源光交换出柜，接到 rail 上的 TH6。

出柜带宽的账：

每柜 global 总出口：128 × 1.6 Tb/s = 204.8 Tb/s
÷ 4 颗 global TH6 ASIC            =  51.2 Tb/s / ASIC   ← 出柜
+ 51.2 Tb/s 下行（回背板）         = 102.4 Tb/s          ← TH6 满配 ✓
204.8 Tb/s ÷ 1.6T 光口            = 128 个光口 / 柜

SemiAnalysis 图上的原话是 51.2T of bandwidth per ASIC will exit the rack via a passive optical switch，和上面算的一致。原文也确认了这个 50/50 切分：Bandwidth exiting each global switch tray of 2 ASICs each is split between the backplane and front panel optics.

然后是 rail 侧。SemiAnalysis 图上每个 rail 框里画了 Switch 1 … Switch 8，框上标注 16× (2×1.6T)：

每 rail 8 台 TH6 × 8 rails = 64 台 rail 交换机
128 XPU ÷ 8 台/rail = 每台 rail 交换机在每柜下挂 16 颗 XPU
16 颗 × 200 Gb/s = 3.2 Tb/s = 2 × 1.6T   ← 图上的 "2×1.6T"
16 柜 × 3.2 Tb/s = 51.2 Tb/s             ← 图上的 "16×"，单台 rail 交换机下行
64 台 × 51.2 Tb/s = 3,276.8 Tb/s = 2,048 × 1.6 Tb/s  ✓

3.4. 我一开始读错的地方：图面歧义与故障域

现在说我踩的坑。

官方拓扑图上的连线，字面看是 XPU1→rail 0、XPU2→rail 1、XPU3→rail 2…… 也就是“每颗 XPU 只连一个 rail、走单条 1.6T”。我第一遍就是这么读的，然后 rail 侧端口数怎么算都对不上“2×1.6T”这个标注。

结论是：图上的彩色连线是简化画法，图注文字才是权威读法。 SemiAnalysis 那张图在两层之间明确写了一行小字：

Each XPU connects to a switch on each rail

每颗 XPU 在每个 rail 上都连一台交换机。8 个 global lane 对 8 个 rail，一一对应。这也正好解释了为什么 I/O chiplet 的 global lane 数恰好是 8 —— 不是巧合。

读法 A（8×200G，每 rail 一条 lane）：每柜每 rail = 128 XPU × 200 Gb/s = 25.6 Tb/s
读法 B（1×1.6T，只连一个 rail）  ：每柜每 rail = 16 XPU × 1.6 Tb/s  = 25.6 Tb/s
                                                                    ───────── 相同

支持读法 A 的证据有三条：① 图注明确写了 each rail；② I/O chiplet 恰好 8 个 global lane，与 8 个 rail 数量相等；③ “2×1.6T” 这个写法暗示 1.6T 是端口粒度而不是链路粒度。

但两者的实质差别在故障域，这才是值得关心的部分。

单台 rail 交换机故障	读法 A（8×200G）	读法 B（1×1.6T）
受影响 XPU	Rail 下的 256 颗	相同
每颗损失	1/8 全局带宽（200→175 GB/s）	全部全局带宽归零
降级方式	优雅降级	该组只能靠柜内 local 域中继

读法 A 是“所有人都轻微变慢”，读法 B 是“一部分人彻底失联”。对一个 2,048 芯片的 scale-up 域，前者显然是更合理的工程选择——这也从可靠性角度反向支持了读法 A。

3.5. 3:1 的带宽分层，对应到并行策略

官方在拓扑页下方给了一句话结论：Higher BW for Tensor Parallel. Lower BW for Expert Parallel. Low latency for all traffic.

带宽比是硬的：

local : global = 4.8 Tb/s : 1.6 Tb/s = 600 GB/s : 200 GB/s = 3 : 1

为什么这个比例对应 “TP 收在柜内 128 芯片、EP/PP 跨柜”？

因为 TP 的通信模式是每层 forward 都要做的 all-reduce/all-gather，同步、频繁、在关键路径上，延迟和带宽都敏感。EP 的 all-to-all 虽然量大，但 MoE dispatch/combine 每层只做两次，而且更容易和计算重叠。所以把 TP 压进高带宽域、把 EP 放到低带宽域，是按“是否在关键路径上”分的，不是按“通信量大小”分的。

那 EP 宽度超过 128 会怎样？ 这是个值得推演的边界（以下为推算）：

EP 宽度 ≤ 128 时，all-to-all 落在 600 GB/s 一侧。一旦 EP 宽度跨柜，dispatch/combine 的相当一部分流量要走 200 GB/s 一侧，同一个 all-to-all 里出现了 3:1 的带宽不对称。

集合通信的完成时间由最慢的那条链路决定。所以效果不是“平均带宽下降到某个中间值”，而是整个 all-to-all 被拉到 200 GB/s 那一侧的节奏上。这意味着跨柜 EP 的正确做法不是简单加宽，而是要么让专家放置和 rail 对齐、要么做分层 all-to-all（先柜内聚合再跨柜交换）。

一个可观测的旁证：SemiAnalysis 提到 GPT-OSS 的高并发操作点用的是 EP8——EP 宽度只有 8，远在柜内。目前公开的评测数据都没有压到跨柜 EP 的边界上。

3.6. 和 NVL72 / AMD Helios 比

维度	Jalapeño	NVIDIA NVL72	AMD Helios
scale-up 域规模	128（local）/ 2,048（global）	72（按封装计；NVL144 是按 die 计的旧名，同一机架）	72 GPU/柜
介质	铜背板 + 无源光交换	铜背板	铜背板
协议	以太网（Scale-Up Ethernet 类）	NVLink，1.8 TB/s 双向/GPU（Rubin 3.6 TB/s）	UALink，200 Gbps/lane，柜级聚合 260 TB/s
内存语义	显式 tensor 通信	硬件 load/store	由 UALink 规范定义，公开细节有限

3.7. 推演：为什么 128–256 会成为未来 3 年的主流 scale-up 域

SemiAnalysis 给了一个动机侧的解释：scale-up 网络只占系统总成本约 10%，所以即使现在不需要 2,048，做进去也是买未来的 optionality——原文点名的未来场景是 10–20 万亿参数模型和 2–4M token 上下文。

那到底需要多大的域？下面这段是推算，假设全部写出来，你可以换假设重算。

假设： 权重 FP4（0.5 B/param）；KV 用 MLA 压缩，按 DeepSeek-V3 口径每层 576 维、61 层、FP8 存储，约 35 KB/token；单芯片 HBM 可用容量按 216 GiB ≈ 232 GB，实际留 15% 给激活与运行时。

【场景一：10T 参数 + 1M 上下文 + 32 并发】
  权重：10T × 0.5 B = 5.0 TB
  KV  ：35 KB/token × 1M × 32 = 1.12 TB
  合计：6.12 TB ÷ (232 GB × 0.85) = 31 颗

【场景二：20T 参数 + 2M 上下文 + 64 并发】
  权重：20T × 0.5 B = 10.0 TB
  KV  ：35 KB/token × 2M × 64 = 4.48 TB
  合计：14.5 TB ÷ (232 GB × 0.85) = 74 颗

只装得下不等于跑得好。还要留出 TP/EP 的形状余量、专家副本、以及 prefill 峰值的临时缓冲。按经验取 2–4× 的余量，128–256 颗就是这两个场景的落点，而 256 是给场景二留了余量的那一档。

如果单芯片 HBM 低于 200 GB 会怎样？ 换成 144 GB：

场景二：14.5 TB ÷ (144 GB × 0.85) = 118 颗（仅装得下）
       × 2–4× 余量 → 236–474 颗 → 必须推进到 512 级别

所以我们有以下结论：参数迈入 10–20T 后，128–256 颗的单 scale-up 域会成为未来 3 年主流；若单芯片 HBM 低于 200 GB，则需向 512 演进。

这个推演的失效边界在哪？

如果 KV 用 GQA 而不是 MLA，KV 项会大一个量级（GQA 常见量级是每 token 一百多 KB），场景二直接翻倍；
如果出现有效的权重卸载或分层存储，容量约束会被部分解除，域规模需求会下降（但卸载肯定也不是免费的）。

3.8. 以太网又一次证明了自己，但边界在语义层

最后回到网络。用 Broadcom TH6 做 scale-up，我认为是规模 / 容量 / 性能 / 供应链的综合最优，理由是结构性的，不是这一代的偶然：

（1）交换 ASIC 的 radix 与带宽演进节奏更快。 102.4T、128 个 800G 端口，让“一台交换机接满 128 颗 XPU、零上行”这件事成为可能。scale-up 域的规模上限被商用交换芯片的 radix 直接决定，而这条曲线是整个行业在推。

（2）光模块与无源光交换成熟。 1.6T 光模块 + 无源光交换让跨柜域从 128 扩到 2,048，而无源器件没有功耗和故障率负担。

（3）多供应商生态。 这是专有协议给不了的。而且成本上算得过来：scale-up 网络只占系统总成本约 10%，用商用件把域做大，边际成本很低。

（4）scale-up 与 scale-out 介质统一带来的运维收益。 同一套光模块、同一套线缆、同一套监控和故障排查流程。对一个要把机队从工程样品推到 100 MW 的团队来说，这个收益不抽象。

长期来看，NVLink 这类专有 scale-up 在小规模、需要硬件级 load/store 与细粒度一致性语义的顶尖高性能场景仍将存续。scale-up 的物理层与交换生态大概率统一到以太网，而内存语义这一层会分化——一部分上移到编译器，一部分留在专有协议里。

3.9. 回填 C 桶（网络与互联）

网络在四桶里贡献了什么？

C 桶的贡献主要不在“更快”，而在“让 B 桶的低延迟优势能扩展到多芯片”。 官方讲稿把这层的目标写成 Low core-to-core latency，度量方式是“从生产核结果就绪，到消费核用上该结果”——这是个端到端延迟定义，不是带宽定义。

零上行的柜内单层网络，把 128 芯片范围内的 TP 通信压在一跳交换内。这是 min TBT 能做到 1.43 ms 的必要条件之一：如果 TP 通信要走两跳、或者要和 EP 流量抢同一条路，那 batch=1 的延迟地板会被通信抬上去。

但也要说清 C 桶没有贡献什么：目前公开的评测（8k/1k、single-turn、EP8）压根没有压到跨柜全局域。2,048 这个数字在这批数据里是没有被验证的。它是为未来买的选项，不是这次成绩的来源。

4. 为什么 Jalapeño 不做 PD 分离，而 NV GPU 却必须做

4.1. PD 分离在 GPU 上为什么“必要”——落到机制

先把 PD 分离的动机说准。DistServe / Splitwise / Mooncake 这一系工作的核心贡献不是提高吞吐，而是在同时满足 TTFT 和 TPOT 两个 SLO 的前提下提高 goodput。要隔离的是两类干扰：

大 batch prefill 占住 GPU → 正在 decode 的请求 TPOT 劣化；
GPU 长时间跑 decode → 新到请求排队 → TTFT 劣化。

为什么不能靠调度解决，非要物理分池？

CUDA 并非完全没有 preemption 或隔离机制。GPU 已经支持 compute preemption，MIG 也可以通过物理划分 SM、L2 和 memory bandwidth 提供较强的性能隔离。

真正的问题在于：这些机制都不是免费的“细粒度 request-level scheduler”。

stream priority：无法简单把一个已经运行的大 kernel 变成可以任意切片的实时任务；
compute preemption：有状态保存和调度成本；
MIG：虽然隔离更强，却把一块 GPU 静态或半静态地切成资源岛。

也就是说，GPU 能做隔离，但越追求强隔离，往往越接近空间分区；越追求动态共享，又越容易重新暴露干扰。

PDD 的价值就在这里——它干脆把这种资源冲突提升到设备池级处理，用 prefill worker 和 decode worker 的物理隔离换取更稳定的 TTFT/TPOT。

代价也随之出现：KV 要搬、两边要分别预留 headroom，而且理想 P 比例会随 workload 改变。

结论：PDD 更准确的定位不是“GPU 架构失败后的补丁”，而是在 GPU 当前的执行与资源管理粒度下，用设备级空间隔离换取 predictable SLO 的一种非常有效的系统解。

我想强调的是结论部分：这是对架构限制的妥协，不是对系统最优解的追求。 没有人希望把一半机器锁在一个池子里。

而且分离本身会引入新的失效模式。近期对 disaggregated inference 的博弈论分析（以 NVIDIA Dynamo 为案例）指出三重博弈：prefill/decode 资源博弈、KV cache 自利缓存博弈、路由拥塞博弈；系统过了饱和点之后，Price of Anarchy 会显著上升

4.2. Jalapeño 为什么“能”不分离——落到硬件

OpenAI 给的理由，公开材料里主要集中在资源配比和机队利用率，而不是 SLO 隔离。这一点要说准。

（1）同构可替换池（fungible fleet）。 SemiAnalysis 的表述：一旦设备被分成 prefill 池和 decode 池，prefill 需求过多就让 decode 芯片闲着而请求排队，反之亦然。运营方必须持续预测正确的切分比例、在两侧都备冗余、并不停 rebalance 一个理想比例始终在移动的系统。

关键那句是：Local utilization looks better, but global utilization can be bad.

官方讲稿的对应表述是 balanced and fungible，而且明确说“随两者之间的平衡变化而自适应”。

（2）消除搬运优于优化搬运。 分离必然打破 locality：prefill 产出的大块 KV，decode worker 立刻就要用，必须先跨网络传过去。带来带宽占用、同步、排队，以及一个额外的故障域。而且成本随 input 长度线性上涨，因为 KV 随上下文增长。

官方的说法是 Locality is king: keep KV local。

（3）投机解码把这个论证又加强了一层。 draft 模型必须以极低延迟给 verifier 喂候选 token。把两者拆到专用池，等于把一个紧耦合的解码循环变成一个分布式协议——额外的通信和协调可能把 drafting 省下的延迟又吃回去。

不搬 KV 主要是功耗与延迟优化。愿意搬一部分 KV，可以换更高的硬件利用率。原文还留了一句：disaggregation can still win where demand is sufficiently large, stable, and predictable.

所以“PD 分离”不是普适真理，是在特定 workload 分布 + 特定芯片能力 + 电力受限约束下的最优解。

（4）使能条件清单。 这才是本章的落点。Jalapeño 能不分离，靠的是这几件硬件事实：

使能条件	机制	证据来源
slice 化的 core+HBM 局部性	每 core slice 对本地 HBM slice 有低延迟视图	官方
极简内存层级	小 shape 也不必靠大 batch 摊销延迟	官方（机制）/ SemiAnalysis（含义），未量化
KV 显式本地放置	`TensorInfo` 显式编码 layout 与 physical placement	官方
片内异构 + 门控	按阶段改变算力/内存/网络的活跃配比，未用模块 gated	官方
均衡的算力-带宽配比	prefill 和 decode 都不塌陷	官方规格
可预测的编程模型	local tensors + explicit communication + predictable synchronization	官方
资源通路分离	专用 collective + 通用 NoC；TP/EP 分层带宽	官方

4.3. PD 分离不是银弹，但“不分离”也不是

现在可以下判断了：“能不搬就不搬”仍然是系统设计的第一性指导。NVIDIA 今天必须做 GPU 粒度的 PD 池分离才能拿到可预期的 TTFT/TPOT，这是 GPGPU 调度模型带来的受限妥协，而不是目标态。

支持这个判断的关键量化证据，是 headroom 而不是隔离能力。

设 decode 步耗时 $t_D$ 、prefill 抢走的周期占比 $\alpha$ 、TPOT SLO 为 $T$ ：

\text{TPOT} \approx \frac{t_D}{1-\alpha} \quad\Longrightarrow\quad \alpha_{\max} = 1 - \frac{t_D}{T}

代入 GPT-OSS 的实测 min TBT（0.69 ms vs GB200 1.87 ms）：

TPOT SLO $T$	Jalapeño 可容忍干扰 $\alpha_{\max}$	GB200 $\alpha_{\max}$	倍数
10 ms	93.1%	81.3%	1.15×
5 ms	86.2%	62.6%	1.38×
3 ms	77.0%	37.7%	2.04×

SLO 越激进，同构池的相对优势越大。 在 GB200 上，prefill 干扰可能把系统推过 SLO 悬崖，所以必须靠 PDD 隔离；在 Jalapeño 上，同样的干扰量可能还在悬崖之内。

而 PDD 的隔离收益在悬崖之内趋近于零，它的成本（KV 跨芯片传输 + 池失衡）却相对恒定。净收益可能变负。 这就是“GPU 上 PDD 有效”和“Jalapeño 上 PDD 没必要”能同时成立的原因——PDD 的价值与架构相关，并非普适。

还有一个 chunked prefill 侧的支撑证据，来自官方的算力配比。ridge point（进入 compute-bound 所需的算术强度）：

Jalapeño MXFP8：  3.4 PF ÷ 15.4 TB/s =   221 FLOP/byte
Jalapeño MXFP4： 13.4 PF ÷ 15.4 TB/s =   870 FLOP/byte
B200 FP8 dense：   5 PF ÷  8.0 TB/s =   625 FLOP/byte   （封装级，由 FP4 dense 10 PF 折半）
B200 FP4 dense：  10 PF ÷  8.0 TB/s = 1,250 FLOP/byte

但这个论证比它看起来要弱，我必须自己拆掉一半。

同精度对比下：FP8 是 625 ÷ 221 = 2.83×，Jalapeño 的 ridge point 低得多；FP4 只有 1,250 ÷ 870 = 1.44×。差别来自上面提到的 4× vs 2× 缩放——Jalapeño 在 FP4 上把算力拉得太高，反而把自己的 ridge point 推上去了。

而这次评测的口径是 weight dtype = f4。所以真正相关的是 1.44× 那个数字，不是 2.83×。 也就是说，“Jalapeño 能用小得多的 chunk”这个论证在 FP4 下基本不成立。

真正站得住的是另一条，有直接出处但没有量化：SemiAnalysis 指出关键不在 ridge point，而在达到效率所需的最小 shape。GPU 因为内存层级深、延迟大，必须用大 tile 或大 batch 来 amortize；Jalapeño 的 per-slice 本地视图让小 shape 也可能保持效率。这间接支持“细粒度交错的代价更低”。

这个判断的失效边界，必须写清楚：

（1）上下文越长，prefill 对共置资源的占用越接近 1。 令 $L$ 为本次需要执行 prefill 的输入上下文长度（完整 prefix cache miss 时就是整个输入长度）， $B_D$ 为同一调度窗口内活跃的 decode batch size。在一个只看量级的简化模型里，把 prefill 与 decode 的工作量分别写成：

W_P \approx aL^2,\qquad W_D \approx bB_D

那么 prefill 抢走的资源时间占比近似为：

\alpha \approx \frac{W_P}{W_P+W_D} = \frac{aL^2}{aL^2+bB_D} = \frac{L^2}{L^2+cB_D},\qquad c=\frac{b}{a}

这里的 $c$ 不是通用常数，而是把单个 decode 序列的一步工作量换算到 prefill attention 量级的比例系数。它会吸收模型结构、硬件速度、kernel 效率和调度窗口等因素。这个模型还忽略了 decode attention 随 KV 长度增长、请求到达率和 chunk size，只用于说明趋势，不能拿来预测实际的 $\alpha$ 。

在其他条件不变时， $L$ 从 $8\text{k}$ 增加到 $200\text{k}$ ， $L^2$ 项会放大 625 倍。此时 $\alpha$ 可能逼近 1，并超过前面推导的 $\alpha_{\max}=1-t_D/T$ ；一旦 $\alpha>\alpha_{\max}$ ，聚合式调度就无法满足 TPOT SLO，上面那张 headroom 表也随之失效。

而这恰恰是 PDD 收益最大的区间。 所以 8k/1k 不只是“对 Jalapeño 友好”，它同时也是最容易支持 No PDD 这个决策的负载形状。

（2）min TBT 是并发为 1 的延迟地板，不是生产并发下的稳态 $t_D$ 。 真实 batch 下 $t_D$ 更大，headroom 比表中更窄。表里的相对比较仍成立，绝对值偏乐观。

（3）当 workload 极度倾斜时分离会重新占优。 超长 prefill 主导、或 cache 命中率极高的 agentic 复用场景，两个阶段的资源需求差异会大到值得付搬运成本。异构硬件的成本差异足够大时同理。

（4）最重要的一条：公开材料没有证明 PD 共置后 TTFT/TPOT 干扰不会发生。 官方讲稿把 TTFT 明确列为 non-goal；公开的 Pareto 曲线比的是 TTLT、TBT、tokens/joule，没有 p95/p99 的 TTFT 与 TPOT，没有突发到达，没有混合长短上下文，没有生产 trace，也没有同芯片同功耗下 Unified 与 PDD 的 SLO 对照实验。

严格的尾延迟隔离仍然依赖尚未披露的调度、抢占和准入控制机制。persistent kernel（Gluon 每个程序映射到一个 persistent thread）和 gigakernel（在设备上循环的单一 megakernel）是执行形态，不自动等于可抢占或有 QoS。没有显式 yield point、优先级或执行配额，长任务照样会头阻塞。

最稳妥的说法是：Jalapeño 降低了必须使用 PDD 的经济动机，但尚无公开证据表明 PD 共置的头阻塞与尾延迟风险已经消失。

5. Spatial 架构：给 Jalapeño 一个准确的归类

5.1. Spatial 与 Temporal 的坐标

先建坐标。Sze、Chen、Yang、Emer 的 DNN 加速器综述把高度并行架构分成两类：

Temporal：同一组执行资源随时间运行不同指令或线程，靠 SIMT / 多级缓存 / warp 切换 / 大 batch 掩盖延迟。典型是 CPU 的 SIMD 与 GPU 的 SIMT。
Spatial：把运算与数据映射到一组处理单元，借助本地存储与相邻或指定路径转发数据，靠编译期确定的放置与流水消除搬运与调度开销。典型是 DNN ASIC、CGRA、FPGA 数据通路。

维度	Temporal	Spatial
主要复用方式	执行资源随时间复用	运算映射到不同物理资源
控制与调度	硬件动态调度较多	编译器/程序显式规划较多
延迟处理	乱序、多线程、cache、大 batch 掩盖	局部复用、流水、预取、可预测路径
适配能力	更适合控制流与 shape 变化大的工作	更适合规则、可提前分析的数据流
主要代价	取指、调度、同步、远距离搬运开销高	编译映射复杂，shape 不匹配时利用率不足

要强调一句：Temporal 不等于串行或低并行度，它强调的是资源在时间维度上复用。

Spatial 内部还按“哪类数据尽量驻留”细分：Weight Stationary、Output Stationary、Input Stationary、Row Stationary、No Local Reuse。SemiAnalysis 说 Jalapeño 的 matrix engine 是 weight-stationary systolic array，落在 WS 这一支。

5.2. Jalapeño 是混合体，不是纯 Spatial

官方自己的定性是明确的：Jalapeño is a spatial architecture。Gluon 把每个物理 core 编程成一个 thread block，core 内有 tensor / SIMD / scalar engine 共享 L1 和快速本地内存视图，专用 collective 协调物理 core 之间的数据与工作，TensorInfo 显式记录 tensor layout 与 physical placement。

但把它等同于 TPU 式 systolic array 或 Groq 式纯 dataflow 会失真。分层看：

观察层级	已公开信息	较稳妥的判断
core 阵列间	`TensorInfo` 记录 physical placement；映射含 scheduling、pipelining、collective	核间以显式空间映射为主
core 内部	tensor/SIMD/scalar 共享 L1 与本地视图；OoO 标量核	仍存在按时间执行指令与复用资源的过程
core 间通信	专用 collective + 通用 NoC	有局部化数据路径，精确 PE-to-PE 拓扑未公开
主存	保留 HBM 作为主存	不是 SRAM-only
服务系统	同构可替换池	不能反推请求级抢占或 QoS

所以准确的归类是：Jalapeño 是“HBM 时代的 spatial-leaning 架构”，介于 Groq/Cerebras 式纯 SRAM dataflow 与 GPGPU 之间。

它保留了三样 Spatial 通常会放弃的东西：HBM 主存、同构可替换的通用池、跨 slice 的 collective 网络。它放弃的是“硬件调度器决定放置”。

顺便，NVIDIA GPU 也不是纯 Temporal。Hopper 的 Thread Block Cluster 让 cluster 内的 block 可以读写彼此的 shared memory 并做原子操作（DSMEM），TMA 还能在同 cluster 的不同 SM shared memory 之间异步搬数据。这些能力修正了“GPU 执行单元之间不能直接交换数据”的旧概括。更准确的说法是 “Temporal 主导、局部 Spatial 化”。

两条路线正在互相靠近，而不是二选一。

5.3. SRAM-only 的差异化窗口被压缩了，但没有归零

Jalapeño 证明的是：在保留 HBM 容量优势的前提下，通过消除搬运与提高有效带宽利用率，可以拿到过去被认为只有 SRAM-only 路线才能达到的低 TBT。

具体到数字：min TBT 1.43–1.44 ms（约 694–700 tok/s/user，R1 与 Kimi K2.5），GPT-OSS 上到 0.69 ms（1,459 tok/s/user）。官方还给了两个前瞻口径：MTP 能再带来 3–5× 的延迟改善（iso-efficiency），以及“在经济的吞吐点上对前沿模型做到 <1 ms TBT”。

对照 Cerebras：CS-4 声称在前沿模型上 4,000 tok/s/user。若把 OpenAI 的 3–5× guidance 套到 700 tok/s 的基线上，同样的硅片可能到 ~2,000–3,500 tok/s/user。

真正让人下判断的不是 tok/s，是成本侧的对比：

Cerebras：单 wafer 仅 44 GB SRAM
  → 1.6T 参数模型（DeepSeek V4 Pro 级）FP4 约 800 GB 权重
  → 需摊到约 20 片 wafer
  → 约 $20M+ CAPEX、约 1 MW 功耗，在第一次 forward 之前

Jalapeño：8 芯片节点约 1.7 TB 内存（8 × 216 GiB = 1,728 GiB）
  → 同一个 FP4 前沿模型装得下且有余量
  → CAPEX 低于单片 WSE，功耗约 11 kW

同一个模型驻留，1 MW 对 11 kW，约 91×。在一个 per-MW 才是硬约束的世界里，这个比值比 tok/s 的差距重要得多。

而且还有一个收益递减效应：过了某个点之后，更快的 token 就不值得付费了。decode 足够快之后，端到端延迟由 tool call 和网络往返主导，多出来的 tok/s 用户感觉不到。从 2,000 提到 4,000 tok/s，人可能已经分辨不出来。

Groq LPU、Cerebras 等“SRAM”路线的推理专用 ASIC 的空间被极大压缩：

极小模型 + 极低延迟的边缘与实时场景。 当模型权重规模远小于片上 SRAM 总量时，SRAM-only 的能效优势是真实的，因为完全不需要付 HBM 的搬运能量。
确定性延迟要求。 纯 SRAM + 静态 dataflow 能给出比任何带 HBM 和 cache 的架构更硬的延迟界。这在实时控制、金融、某些工业场景里是刚需，不是 nice-to-have。
SRAM 路线真正的死穴是容量趋势。 10–20T 参数把“全部权重放 SRAM”推向经济不可行——上面那个 20 片 wafer / 1 MW 的算式，在 10T 参数下会变成 100+ 片 wafer。这才是压缩其空间的根本变量。

5.4. “芯片逻辑要简单以便快写 kernel”不再是必要条件

现在说这颗芯片对行业最有长期意义的一点。

先摆事实。Jalapeño 的 kernel 用 Gluon 写，OpenAI 自己的 kernel 编程语言，构建在 Triton 之上，保留 SPMD 模型但暴露更底层的抽象。它最独特的抽象是 layout——一个 layout 定义硬件资源（比如“warp 9 的第 5 个寄存器”）与 tensor 元素（比如“第 6 行第 7 列”）之间的映射。Gluon 的 layout 抽象基于 Linear Layouts，一套 OpenAI 自己发明的 layout 代数，把 layout 数学形式化，因此可以做可证明正确的 layout 转换和最优 memory swizzling。

然后是难度：SemiAnalysis 说 OpenAI 写 Jalapeño kernel 是 like assembly，单个 kernel 手工调优代码能到约 3,000 行，配套有正确性检查和自定义 sanitizer。

再看 AI 到底做到了什么，这里我只用官方给的量化数字：

环节	AI 的贡献（官方口径）
kernel 优化	DeepSeek kernels：从功能正确的基线出发，`AI drove most of the optimization`
kernel 优化	GPT-OSS 的 attention 与 MoE block：比既有专家手写实现快 1.5–1.8×
RTL 设计	基础模块改进：BF16 mul 56%、FP4 dot 21%、FP32 acc 10%
RTL 设计	block 级 PPA：Matrix Unit 面积 −10%、SIMD Unit 面积 −8%
项目节奏	重大改动一直落到 RTL freeze 当天

还有两个更有说服力的轶事：OpenAI 在给 DeepSeek 跑 InferenceX 之前，内部根本没有 MLA kernel 的实现，是 Codex 在 kernel 工程团队没有直接介入的情况下写出来的；以及他们把 Doom 移植到了这颗芯片上跑到 36 FPS，据称主要靠 Codex prompt 完成。

SemiAnalysis 把方法论总结成两步：

1. Design for the highest upper-bound performance across all workload shapes
2. Let Codex do the tedious work of finding the kernels that achieve that upper bound

但这里有一个我认为绝大多数转述都读错了的地方。

如果你据此得出“有了 AI 就可以随便做复杂硬件”，那是错的，而且官方讲稿明确不是这个意思。那一页的标题是：

Architecture model: Simple for humans to understand. Easy for frontier AI to program.

页面下方分三栏：

HUMANS REASON ABOUT	FRONTIER AI SEARCHES	HARDWARE EXPOSES
Simple abstraction	The mapping	Clean hierarchy
Local tensors	Placement	Fast local paths
Explicit communication	Scheduling + pipelining	Slower global paths
Predictable synchronization	Collective orchestration	Distributed control

结论句是 Human-simple model + AI-generated mapping = Distributed performance，以及 Spatial programming is onerous for humans. It is easy for frontier AI.

看清楚被让渡给 AI 的到底是什么：是 mapping、placement、scheduling、collective orchestration 这一层，不是编程抽象本身。

所以要区分两个词：

“简单（simple）” ——为人类心智负载而简化。这一层 OpenAI 声称自己保留了（Simple abstraction）。真正被放弃的是“人类能手工完成最优映射”这个要求。
“可预测（predictable）” ——语义可预测、时序可建模。这一层完全没有被放弃，反而被写进了人类要理解的四条之一（Predictable synchronization）。

而可预测性恰恰是编译器与 AI codegen 能工作的前提。失去可预测性的复杂硬件，对 AI 编译同样是灾难——AI 搜索 kernel 依赖的是“我改这个 placement，性能会怎么变”这个可建模关系。语义不可预测的硬件，搜索空间会退化成噪声。

所以观点 2 的准确表述是：“芯片逻辑要简单、以便工程师快速写 kernel”这条约束，从硬性条件降级成了可交易项；但“语义可预测、时序可建模”仍然是硬约束。

这条路把护城河从 CUDA 生态转移到了“自有前沿模型 + 自有编译栈 + 自有 workload”的闭环上。

对没有这个闭环的第三方芯片公司，它不可复制。你需要同时拥有：一个能写 kernel 的前沿模型（OpenAI 用的是 GPT 5.6 Sol 这一级）、一个带详细 tracing 的 harness、一个精度在 5% 以内的模拟器（chilisim）、以及自己的推理服务栈（Teacup）。缺任何一环，“让 AI 去搜”就变成“让 AI 去猜”。

SemiAnalysis 给了个很讽刺的注脚：跑在 NVIDIA GPU 上的 OpenAI 模型，正在设计一颗威胁 CUDA 护城河的芯片。

5.5. 回填 D 桶

D 桶（编译与 kernel 软件）的贡献有一个可以直接引用的量化下界：GPT-OSS 的 attention 与 MoE block，AI 优化后比既有专家手写实现快 1.5–1.8×。

注意这是“相对本芯片上的专家手写基线”，不是“相对 GPU”。所以它不能直接加到对 GB300 的 1.5–1.9× 领先里去。它衡量的是同一颗硬件的性能上限被兑现了多少。

另一个可观测的 D 桶信号是 bring-up 速度：不到 2 周吞吐提升超过 2×，8 天内从 TP8 推进到 TP32 rack-scale 配置。SemiAnalysis 的判断是 Jalapeño's software bring-up has progressed more quickly than Nvidia's，而且明确说“我们不认为 NVIDIA 硬件更差”。

也就是说：这次对比里有一部分领先，来自双方软件成熟度的时间差，而不是硬件差异。 这一部分会随时间收敛。

6. 收尾

我写这篇最大的收获，不是记住了 Jalapeño 有多少 PFLOPS 或多少 TB/s，而是重新意识到一件事：

看一颗推理芯片，规格表只能告诉你资源上限；真正决定产品形态的，是它在不同 workload shape 下能兑现多少。

Jalapeño 最值得注意的也不是“第一代 ASIC 打赢了 NVIDIA”这么简单。

peak throughput-per-kW 一侧：它的领先有相当一部分仍然可以从制程、功耗预算和 HBM4 这些资源条件中得到解释；
low-batch、低延迟区域：真正不同寻常——实测差距已经超过单纯 raw bandwidth 能够解释的范围，开始指向 locality、dataflow、communication path 和 software mapping 的共同作用。

但现在也不应该把故事讲得太满。

公开结果仍然是 A0、8k/1k、single-turn；
AgentX 没跑，真实 agentic trace 没跑；
Unified 与 PDD 的 production SLO 对照也没有公开；
2,048-chip global domain 更是一个尚未被这批 benchmark 真正压到的能力。

（本篇完）

附录 A · 术语表

A.1. 芯片与微架构

reticle-size die：达到光刻机单次曝光面积上限（约 858 mm²）的裸片，是单 die 面积的物理天花板。

chiplet：把原本单一大 die 的功能拆成多颗小 die 并封装在一起。可为不同功能选不同工艺节点，并提高良率。

systolic array（脉动阵列）：数据像脉搏一样在固定物理路径上有节奏地流经处理单元阵列，中间结果在相邻单元间直接传递，不回主存。

weight-stationary（权重驻留）：一种 dataflow 策略，让权重尽量留在计算单元本地，输入与部分和流过。降低权重侧的重复搬运。

core slice / HBM slice：把计算核与 HBM 划成一一配对的分片，每个 core slice 对自己那片 HBM 有低延迟本地视图。

SRAM：静态随机存储器，用作片上 cache 与本地缓冲。速度远高于 HBM，但单位面积容量小得多。

SerDes（串行器/解串器）：把并行数据转成高速串行信号收发的电路，决定芯片对外的电气带宽上限。

lane：SerDes 的单条串行通道。本文中 Jalapeño 的 lane 速率为 200 Gb/s，一个 800G 端口由 4 条 lane 编组而成。

differential pair（DP，差分对）：用两根线传一路信号以抑制共模噪声。一条双向 lane 需要 2 个 DP（收、发各一）。

XLS：一种硬件描述语言，OpenAI 用它作为 AI 参与 RTL 优化的“可控优化面”。

PPA：Performance / Power / Area，芯片实现质量的三个基本维度。

yield harvesting（良率收割）：允许部分单元有缺陷的芯片降级出货，通过屏蔽坏的 core 或内存通道保留可用产能。

Spatial 架构：把计算图在空间上展开、数据在固定物理路径上流动，靠编译期确定的放置与流水消除搬运与调度开销。

Temporal 架构：把算子在时间上依次映射到同一组可复用的通用单元，靠 SIMT、多级缓存与运行时调度掩盖延迟。

dataflow：以数据可用性驱动计算的执行模型，与以指令序列驱动相对。

OoO（out-of-order，乱序执行）：允许指令不按程序顺序完成，以避免因等待数据而停顿。

A.2. 内存与数值格式

HBM4：第四代高带宽内存。堆叠 DRAM 通过硅中介层与计算 die 近距互联，单 stack 接口宽度 2048 bit。

pin speed：内存接口每根数据线的信号速率。Jalapeño 反推为 10 Gb/s，Rubin 上 NVIDIA 取 9.6 Gb/s。

MXFP4：OCP Microscaling 规范下的 4 bit 浮点格式，一组元素（通常 32 个）共享一个缩放因子。

NVFP4：NVIDIA 的 4 bit 浮点格式。与 MXFP4 的缩放粒度不同，因此两者的峰值算力数字不可直接当作等价精度比较。

GiB / GB：GiB 是 2³⁰ 字节，GB 是 10⁹ 字节，相差约 7.4%。216 GiB = 232.0 GB。

KV cache：自回归解码时缓存的历史 token 的 Key/Value 张量，避免重复计算。容量随上下文长度线性增长。

MLA（Multi-head Latent Attention）：DeepSeek 提出的注意力变体，把 KV 压缩到低维潜空间后再缓存，显著降低 KV cache 体积。

GQA（Grouped-Query Attention）：多个 query head 共享一组 KV head，以降低 KV cache 体积，压缩比通常弱于 MLA。

ridge point：roofline 模型中算力受限与带宽受限的分界点，等于峰值算力除以峰值带宽，单位为 FLOP/byte。

roofline：以算术强度为横轴、可达性能为纵轴的性能上界模型。

A.3. 推理服务与指标

prefill：处理输入上下文、生成首个 token 前的阶段。attention 计算量与序列长度平方相关，通常 compute-bound。

decode：逐 token 生成阶段。每步都要读一遍（激活）权重，通常 memory-bandwidth-bound。

PD disaggregation（PDD，PD 分离）：把 prefill 与 decode 放到不同的专用设备池执行，中间跨网络传输 KV cache。

continuous batching：请求到达即插入正在运行的 batch、完成即移出，而非等整批对齐。

chunked prefill：把长 prefill 切成小块，与 decode 步交错执行，以缓解长 prefill 阻塞。

TTFT（Time To First Token）：从请求到达到产出首个 token 的延迟。官方讲稿把它列为 non-goal。

TPOT（Time Per Output Token）：输出阶段的平均单 token 时间。

TBT（Time Between Tokens）：相邻输出 token 的间隔，本文中用作交互性的代理指标。

TTLT（Time To Last Token）：到最后一个 token 的时间，即端到端请求延迟。官方主用指标。

E2E latency：端到端请求延迟，本文中与 TTLT 同义。

STP（Single-Token Prediction）：标准单步自回归解码，每个活跃序列每个目标模型步骤只提交一个 token。没有草拟-验证阶段。

MTP（Multi-Token Prediction）：先草拟多个候选 token 再由目标模型批量验证。官方框架用 MTP=7（7 轮 draft + 1 次批量验证，最多产出 8 token）。

speculative decoding（投机解码）：MTP 的实现路径，用更廉价的 draft 模型或预测头生成候选，由目标模型验证。加速比取决于接受率。

throughput-per-kW / tok/s/MW：单位功率的 token 产出。约掉时间单位后等价于 tokens/joule。

goodput：同时满足全部 SLO 的有效吞吐，区别于不看 SLO 的原始 throughput。

Pareto frontier：延迟-效率权衡下不可再同时改进的操作点集合。比较系统应比整条前沿，而非单点。

InferenceX：SemiAnalysis 的公开、功耗归一推理基准。本次口径为 nominal ISL/OSL 8k/1k、single-turn。

AgentX（InferenceXv3）：SemiAnalysis 面向长上下文、多轮 agentic 负载的基准，压测 router 与 prefix cache 行为。Jalapeño 尚未有结果。

Price of Anarchy：博弈论概念，指各方自利决策的均衡结果相对全局最优解的退化程度。

Gluon：OpenAI 的 kernel 编程语言，构建在 Triton 之上，保留 SPMD 模型并暴露底层抽象。

Linear Layouts：OpenAI 发明的 layout 代数，把“硬件资源↔tensor 元素”的映射数学形式化，支持可证明正确的 layout 转换。

TensorInfo：Jalapeño 编程模型中显式记录 tensor layout 与物理放置的抽象。

persistent kernel / gigakernel：常驻设备端循环执行的 kernel 形态，减少反复 launch 与返回主机的开销。是执行形态，不等于可抢占。

MoE（Mixture of Experts）：每个 token 只路由到少数专家，总参数远大于激活参数。总参数决定容量需求，激活参数决定带宽需求。

TP / EP / PP：Tensor / Expert / Pipeline Parallel。TP 通信在关键路径上且频繁，EP 是 all-to-all，PP 是流水级间点对点。

A.4. 网络与拓扑

scale-up / scale-out：scale-up 指紧耦合、高带宽、供单个模型实例内部并行使用的域；scale-out 指跨实例的松耦合扩展。

Clos：多级无阻塞交换拓扑，现代 leaf-spine 的理论基础。

half-flattened：本文语境下指柜内 local 域被压平成单层零上行全互联，而跨柜 global 域仍是两级 Clos。

rail：多轨拓扑中的一条独立平面。每颗加速器在每个 rail 上各有一条链路。

rail-only：只有 rail 平面、不设跨 rail 的 spine 层的拓扑；跨 rail 流量需经本地高带宽域中继。

Tomahawk 6（TH6）：Broadcom 交换 ASIC，102.4 Tb/s，可配置为 128 个 800G 端口。

passive optical switch / OCS（Optical Circuit Switch）：在光域直接建立静态或慢速可重构连接的交换设备，无光电转换，无功耗与主动故障源，但不做逐包交换。

copper backplane（铜背板）：机柜内以无源铜缆或印制背板直连的高密度电气互联。

NVLink：NVIDIA 的专有 scale-up 互联，提供硬件级 load/store 内存语义。

UALink：开放的加速器 scale-up 互联规范，AMD Helios 采用，lane 速率 200 Gbps。

ATL（AI Transport Layer）：微软 Maia 200 使用的 scale-up 协议，每 chip 2.8 TB/s 双向。

ICI（Inter-Chip Interconnect）：Google TPU 的芯片间互联，v7 Ironwood 为 1,200 GB/s 双向。

PAM4：四电平脉冲幅度调制。每个符号携带 2 bit，因此 212.5 GBd 的信号可承载约 200 Gb/s 有效数据。

CPO（co-packaged optics，共封装光学）：把光引擎与交换 ASIC 封装在一起，替代可插拔光模块以降低互联功耗。Broadcom 的 TH6 “Davisson” 是其一例。

Oberon：NVIDIA 的机架级铜缆背板设计代号，本文中作为 Jalapeño 铜背板的类比对象。

radix：交换芯片的端口数。决定单层网络能接的节点上限。

A.5. 模型与基准

GSM8k：小学数学应用题基准，本文中用于验证提速没有牺牲模型正确率。

chilisim：OpenAI 的 Jalapeño 模拟器，精度在实测硬件的 5% 以内。

Teacup：OpenAI 内部推理服务引擎。

Katsu / Vindaloo / Chana：分别是 CPU host tray、Jalapeño ASIC tray、scale-up switch tray 的代号。

附录 B · 参考来源

B.1. 官方（OpenAI）

OpenAI Jalapeño, Hot Chips 2026 讲稿（Richard Ho, Ravi Narayanaswami, Chris Leary），36 页 PDF，2026-08-25。本文中全部规格数字、评测倍数、Pareto 口径、NON GOALS、拓扑图、Spatial 架构页、AI-PPA 数字均以此为准。
OpenAI 官方博客：OpenAI and Broadcom unveil LLM-optimized inference chip（2026-06-24 首次公布）。
OpenAI 官方博客：Jalapeño's first results show industry-leading speed and efficiency in AI inference（InferenceX 数据点、balanced and fungible、KV kept local）。

B.2. 第三方分析

SemiAnalysis, OpenAI Jalapeño: Better Than Nvidia Blackwell，2026-08-25，19 页。本文中制程（N3P / N3E）、I/O chiplet lane 分配、差分对数量、机柜代号与 elevation、local/global 带宽拆解、rail 结构图、A0/B0、TCO 对比、Cerebras 对比算式、PD 分离论证均出自此文。
SemiAnalysis, AgentX - InferenceXv3: Does CUDA Moat Hold up in Agentic Inferencing?（长上下文多轮基准的方法论与局限）。
SemiAnalysis, Vera Rubin NVL72 vs GB200 NVL72? Inference TCO & Architecture Analysis。注意：Vera Rubin NVL72 相对 GB200 NVL72 的 5.4× perf/MW 是 SemiAnalysis 自己的建模结果，不是 NVIDIA 的口径（见下方第 17 项）。

B.3. 分类法与背景文献

Sze, Chen, Yang, Emer, Efficient Processing of Deep Neural Networks: A Tutorial and Survey（Temporal / Spatial 定义与 WS/OS/IS/RS/NLR dataflow 分类）。
Chen et al., Eyeriss: A Spatial Architecture for Energy-Efficient Dataflow for CNNs（ISCA 2016）。
Horowitz, Computing's Energy Problem（ISSCC 2014 Plenary，数据搬运与控制开销的能耗量级）。
NVIDIA, Hopper Architecture In-Depth 与 Hopper Tuning Guide（Thread Block Cluster、DSMEM、TMA）。
DistServe / Splitwise / Mooncake（PD 分离的 goodput 论证与工程实现）。本轮未重新核验原文。

B.4. 媒体二手报道

ServeTheHome, OpenAI Jalapeno Custom AI ASIC at Hot Chips 2026。
The Register, OpenAI's upcoming Jalapeño chip looks like it'll be an inference beast（2026-08-25）。
Wccftech, OpenAI's First-Gen Jalapeno ASIC（OoO 标量核、weight-stationary 阵列、机架规格的二手整理）。
Forbes（Jon Markman / Luis Romero 两篇）：somewhat incomplete and unfair、A0 stepping、短上下文单轮的批评；TDP 归一方法与功耗受限分析。
llmrumors, OpenAI Jalapeño Results: What the Chip Means for NVIDIA（澄清“1.9× 是 per-watt 而非绝对吞吐”的常见误读）。

相关文章