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

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

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

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

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

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现在展示性能时越来越喜欢画Token s/s/user与Token s/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更激进一些——它直接把推理内部拆开了。

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网络，把更大范围的训练连接做成专门体系。

Google在现场还提到了一个很实际的芯片设计问题：dark silicon。

芯片面积和功耗预算有限。如果同一颗芯片同时塞入训练需要的大量矩阵计算资源，又塞进推理需要的更多SRAM、HBM和低延迟网络，在某一种workload运行时，总会有一部分电路长期闲置。

既然两种任务已经需要不同的资源比例，直接做两颗芯片反而更干净。

把三条路线放在一起，差异其实很清楚。

OpenAI做Jalapeño，把芯片专用化到LLM推理这一层，但保留Prefill和Decode在同构硬件上的灵活调度；NVIDIA往下继续拆，让GPU和Groq LPU分担一次推理里的不同阶段；Google往上切，把训练和推理直接做成两颗TPU。

这几条路线背后并没有神秘的新计算原理，改变的是资源比例。训练希望把更多晶体管投入矩阵计算和大规模互联，因为高Batch能把数据搬运成本摊开；低延迟推理需要更高的HBM带宽、更大的SRAM、更好的KV Cache局部性和更短的网络路径，因为很多时间花在等待数据上。

当两类负载需要的“芯片配方”越拉越开，用一颗通用芯片同时照顾它们，效率损失自然会越来越明显。

这也是为什么这轮硬件竞争里的核心数字正在变化。FLOPS依然重要，但旁边开始出现Token s/s/user、TBT、TTFT、Tokens/kW、HBM带宽以及网络延迟。

它们描述的其实是同一件事：算力已经放在那里了，系统能不能持续把数据喂进去，并把生成的Token尽快送出来。

OpenAI、NVIDIA和Google现在选择的分界线还不一样，后面真正会继续变化的，很可能也是这条线应该画在哪里。

训练和推理可以拆，Prefill和Decode可以拆，Decode内部的Attention与其他计算也可以继续拆。拆得越细，单项效率越容易提高，但资源调度、KV Cache搬运和跨硬件通信也会变得更复杂。

因此下一阶段AI芯片竞争的难题，或许已经不只是造出一颗更强的芯片。

更难的是决定： 哪些任务值得专门做一颗芯片，哪些任务继续放在同一套硬件里，整套系统的Token成本才更低。

参考链接：https://openai.com/index/jalapeno-first-results/

上车，带你看遍全球AI顶会精华

或点击 「 阅读原文 」 关注专区。