Jalapeño 跑分炸场，GPU 推理路线开始分裂？

本文作者：郑佳美

2026-08-28 15:27

导语：Token 成本成为大模型硬件竞争的新坐标。

Token 成本成为大模型硬件竞争的新坐标。

作者丨郑佳美

编辑丨岑峰

今天，OpenAI 的自研推理芯片 Jalapeño，终于从规格表走到了跑分台。

这次公开的数据很接地气：Token 吞吐、生成延迟、单位功耗下能跑多少推理。因为大模型上线以后，芯片面对的早就不只是一次训练任务。ChatGPT 要一直回消息，Reasoning 模型要持续生成长链路内容，Agent 还会一轮接一轮调用模型。算力再高，Token 吐得慢、延迟压不下来、功耗又高，数据中心照样难受。

成绩一出来，Reddit 很快就把 Jalapeño 和 NVIDIA Rubin 摆到了一起。有人认为它已经进入 Rubin 的效率区间，也有人认为测试条件、软件优化和整个平台形态没有对齐，现在还没法直接分高下。争论暂时停在这里，没有统一答案。

更巧的是，Jalapeño 并不是孤例。NVIDIA 正在把 Groq 3 LPU 拉进推理系统，专门处理 Token 生成；Google 也把 TPU 8 拆成偏训练和偏推理的两条路线。几家公司几乎在同一时间开始重新拆芯片的工作，背后那套硬件逻辑难道真的已经变了吗？

Jalapeño 在看 Token 怎么跑

OpenAI 公布的数据里，Jalapeño 在 GPT-OSS 120B、DeepSeek R1 670B 和 Kimi K2.5 1T 上，峰值吞吐位置每瓦完成的 AI 工作提高约 1.5～1.9 倍，端到端延迟降低约 1.7～3.6 倍；在交互速度要求较高的区间，性能提升达到约 2.1～4.1 倍。芯片额定功耗是 700W，这批负载中的持续功耗没有超过 550W。雷峰网

这些数字为什么围绕 Token 展开，需要先看一次大模型推理内部发生了什么。

输入 Prompt 时，模型进入 Prefill。假设一次输入 8K Token，这些 Token 可以大规模并行计算，模型权重从 HBM 取出来之后，会被很多 Token 重复使用。此时矩阵比较大，计算密度高，矩阵计算单元很容易忙起来。

开始生成答案后，模型进入 Decode。它需要一个 Token 接一个 Token 往外生成，新 Token 又依赖前面的状态。并行度下降了，模型权重却依然要读，Attention 还要不断访问此前保存下来的 KV Cache。

所以两段推理看起来使用相同的 Transformer，芯片看到的负载却差别很大：Prefill 更容易受到计算能力限制，Decode 更容易卡在内存带宽和数据移动上。OpenAI 在 Jalapeño 的架构说明里也明确把两者做了这一区分。雷峰网(公众号：雷峰网)

用 Roofline 模型可以把这个问题看得更清楚。芯片能发挥多少性能，大致取决于两个上限：可达性能 ≈ min（峰值计算能力，内存带宽 × 算术强度）算术强度说的是，搬运一份数据以后，能拿它做多少计算。

训练和 Prefill 的矩阵足够大，一次读取权重能够服务大量 Token，所以算术强度很高。低 Batch Decode 里，情况会反过来。假设 Dense 模型有 P 个参数，每个参数平均占 b Byte，生成一个 Token 涉及约 2P FLOPs 量级的矩阵运算，而读取一遍权重需要约 P × b Byte，只考虑权重部分，算术强度粗略只有：2 / b FLOPs/Byte。

参数量 P 在这个比例里直接被约掉了。换句话说，模型从几百亿参数变成几千亿参数，Decode 依然要面对同一类问题：计算阵列可以做得很强，但 HBM 如果没有及时把权重送过来，新增计算单元就会等数据。

Jalapeño 因此没有只在矩阵乘上堆资源。OpenAI 强调的是让模型状态和 KV Cache 显式放在合适的位置，尽量保持数据局部性，再通过芯片内部的计算、内存和网络协同完成不同推理阶段。它还刻意维持一种相对均衡的架构，让同一种加速器既能处理 Prefill，也能处理 Decode，而不需要提前把机器固定分成两套资源池。

这也解释了 Reddit 上为什么很难靠一个数字结束 Jalapeño 和 Rubin 的争论。

一部分讨论引用 SemiAnalysis 的比较，认为 Jalapeño 在部分单位成本 Token 指标上已经进入 Rubin 的区间，而且 Jalapeño 这批结果没有依赖 speculative decoding。

另一部分讨论则认为，当前公开测试主要是相对规则的负载，Rubin 的软件优化方式不同，Jalapeño 还处在生产资格验证和规模部署之前，更复杂的 Agent 型长上下文负载也缺少足够公开数据。

还有人直接把 NVIDIA 的比较对象扩大到了 Rubin GPU 加 Groq 3 LPX，而不再只看 Rubin GPU。

现有讨论可以搬出来看，但还不足以给两套系统下一个简单排名。

最合适做推理芯片的时代

专用推理硬件其实早就存在，变化在于大模型的运行方式。

训练一轮模型虽然昂贵，但它毕竟是一段集中发生的计算过程。模型上线之后，ChatGPT、Claude、代码助手以及各种 Agent 会持续运行，每次聊天、代码生成、搜索和工具调用背后，服务器还在不断生成 Token。

推理因此从训练之后的配套工作，变成了长期占用电力、服务器和机房容量的负载。

Agent 又把这个问题放大了一次。普通聊天里，几十毫秒的差异可能只体现为文字快一点出现。Agent 的任务经常是串行的：模型先判断一步，调用工具，拿到结果后继续判断，再进入下一步。单次推理增加的延迟，会一路传到后面的步骤。

此时 GPU 有一个经典矛盾。想把 GPU 用得更满，可以增加 Batch。模型权重从 HBM 读一次，同时给几十个请求使用，权重复用率提高，矩阵也更大，总 Token 吞吐自然会上升。

但在线请求不能无限等着凑 Batch。Batch 越小，单用户响应越快，权重复用率却会下降；Batch 越大，整台机器的吞吐更漂亮，单用户的 Token 延迟又可能上升。

OpenAI、NVIDIA 和 Google 现在展示性能时越来越喜欢画 Tokens/s/user 与 Tokens/s/watt 之间的 Pareto 曲线，背后就是这组交换关系。

长上下文还增加了另一笔成本：KV Cache。

Transformer 在生成新 Token 时，会把此前 Attention 的 Key 和 Value 保存起来，避免每次重新计算全部历史。上下文越来越长，KV Cache 也跟着增长。Agent 又会不断积累系统 Prompt、工具返回、网页、代码和历史步骤，这些状态可能跟着一个 Session 存在很久。

于是调度器不能只看“哪颗芯片现在空闲”，还得考虑“这个请求的数据现在在哪”。如果 Prefill 在一组机器完成，Decode 被迁到另一组机器，KV Cache 也可能跟着跨网络移动。对于长上下文模型，这次搬运本身就会消耗带宽和时间。

到了这里，推理芯片的价值已经不只来自减少几次计算。它开始围绕一整条数据路径做优化：权重从哪里来、KV Cache 留在哪里、一次 Token 生成需要访问几次 HBM、数据需不需要跨芯片，以及计算单元有多少时间处在等待状态。

而 NVIDIA 选择的办法，比 Jalapeño 更激进一些——它直接把推理内部拆开了。

GPU 不再包下整段推理

Hot Chips 2026 上，NVIDIA 展示了 Groq 3 LPU 在 Vera Rubin 系统里的位置。

逻辑非常清楚：GPU 很适合 Prefill，大矩阵、高并行、较高的权重复用率正好发挥 GPU 的能力；到了低延迟 Decode，NVIDIA 开始让 Groq 3 LPU 接手大量工作。ServeTheHome 在现场报道中直接把 LPU 的作用概括为填补 Vera Rubin 在低延迟 Decode 区域的短板。

Groq 的芯片设计也几乎围绕这件事展开。一套 LPX 机架有 256 颗 LPU，加起来只有 128 GB SRAM，容量和 GPU 机架里的 HBM 没法放在一个尺度上比较，但聚合 SRAM 带宽可以达到 40 PB/s。

这个设计看重的就是“近”。HBM 能装很多模型状态，却离计算单元更远；SRAM 很贵、容量难做大，但数据就在芯片内部，能够提供极高带宽和很低的访问延迟。

Decode 每一步做的计算有限，又频繁取数据，把数据放得更靠近 ALU，收益会非常直接地反映在下一个 Token 的等待时间上。

Groq 还进一步减少了动态硬件控制。LPU 是确定性执行架构，指令调度主要由软件提前完成。每颗芯片同时充当处理器和路由器，编译器会一起安排计算资源和网络资源，甚至省掉了传统硬件流控和虚拟通道这类机制。

代价也很明显：这种架构没有 GPU 那么通用，片上 SRAM 又装不下完整的大模型状态。所以 NVIDIA 没有让 Groq 3 独立运行整个模型，而是做了一套更复杂的异构系统。

Prefill 在 GPU 上进行，大部分 Decode 放到 LPU；Decode 里的 Attention 又可以回到 GPU。GPU 和 LPU 分别维护自己的 KV Cache，两边主要交换 draft Tokens，同时通过 micro-batch 把计算和通信重叠起来。由于 LPU 是同步域，而 GPU 和外部 KV Cache 属于异步系统，NVIDIA 甚至加入 FPGA 作为两边的异步桥接。

这套结构很能说明 AI 芯片分工已经走到了什么程度。它拆的已经不只是“训练芯片”和“推理芯片”，连一次 Decode 里面的不同部分也可以放到不同架构执行。

不过 NVIDIA 展示的数据也给出了这条路线的边界：当业务只追求总体吞吐，并且能够接受较高延迟时，Rubin GPU 依然很有效率；随着对单用户 Token 速度要求提高，LPX 才逐渐发挥优势，而使用更多 LPU 之后，总体吞吐效率也会下降。

所以 Groq 3 的出现并不意味着 GPU 被推理淘汰了。它说明另一件事：同一颗 GPU 很难同时占住高吞吐和极低延迟两端，让两种硬件分别跑自己更擅长的区间，系统反而更容易把性能曲线拉开。

Google 则把这道切口放在了更上层。

训练和推理，用两套芯片配方

Google 在 TPU 8 这一代同时做了 TPU 8t 和 TPU 8i，t 面向训练，i 面向推理。这种分法背后的逻辑，直接写在芯片的内存配置上。

Hot Chips 现场展示中，TPU 8t 使用 6 组 HBM，TPU 8i 反而用了 8 组。Google 给出的解释是，推理每单位计算需要更多 HBM，同时还需要更高比例的 SRAM，因此 8i 把更多资源给了 SRAM、内存容量和带宽。

这个差异很值得琢磨。如果 AI 芯片只是在比矩阵算力，推理版没有理由把这么多芯片面积和封装资源花在内存上。TPU 8i 这样设计，说明 Google 看到的瓶颈已经移到了数据供应。

训练时，大 Batch 能够把权重读取成本摊到很多 Token 上；Decode 中每次生成的 Token 很少，权重和 KV Cache 却仍然频繁访问。于是每单位 FLOPS 需要配多少 HBM 带宽，两类任务的答案并不一样。

Google 甚至把这种差异做到了网络拓扑。过去 TPU 常用的 3D Torus 更适合训练，强调的是大规模集群里的整体吞吐。TPU 8i 支持 BoardFly，网络路径更短：BoardFly 的路径上限为 7 hops，3D Torus 则达到 16 hops。

对训练来说，几次额外网络跳转之后通常还有很大一块矩阵计算，通信时间可以被摊薄。Decode 每一步的计算窗口短，几跳网络延迟更容易直接落进 Token 间隔里。

MoE 又让这个问题变得更明显。MoE 可以让一个 Token 只激活一部分 Expert，从计算量上看很划算，但 Router 会把 Token 发往不同 Expert。一旦这些 Expert 分布在不同芯片上，计算减少的同时，All-to-All 通信会增加。

因此 TPU 8i 还加入了 Collective Acceleration Engine，把部分 collective 操作放在靠近网络接口的 I/O Die 上处理。数据无需先搬进 Compute Die，再经过 HBM 完成操作，可以直接省掉一部分芯片内部数据移动。

训练版 TPU 8t 的资源分配则明显朝另一边倾斜。训练需要大量 FLOPS，也需要巨大的 Scale-Up 域去同步参数和梯度。TPU 8t 的 Superpod 可以扩展到 9600 颗芯片，拥有约 2 PB 共享 HBM 和 121 EFLOPS FP4 聚合计算能力，Google 还为它引入 Virgo 网络，把更大范围的训练连接做成专门体系。