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跑分数据:峰值吞吐位置每瓦AI工作提升约1.5~1.9倍
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模型解释:Decode阶段算术强度只有2/b FLOPs/Byte
用Roofline模型可以把这个问题看得更清楚。芯片能发挥多少性能,大致取决于两个上限:可达性能约等于峰值计算能力与内存带宽乘以算术强度之间的较小值。算术强度说的是,搬运一份数据以后,能拿它做多少计算。
训练和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效率区间?
这也解释了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:调度器不能只看哪颗芯片空闲
长上下文还增加了另一笔成本:KV Cache。Transformer在生成新Token时,会把此前Attention的Key和Value保存起来,避免每次重新计算全部历史。上下文越来越长,KV Cache也跟着增长。Agent又会不断积累系统Prompt、工具返回、网页、代码和历史步骤,这些状态可能跟着一个Session存在很久。
于是调度器不能只看“哪颗芯片现在空闲”,还得考虑“这个请求的数据现在在哪”。如果Prefill在一组机器完成,Decode被迁到另一组机器,KV Cache也可能跟着跨网络移动。对于长上下文模型,这次搬运本身就会消耗带宽和时间。
到了这里,推理芯片的价值已经不只来自减少几次计算。它开始围绕一整条数据路径做优化:
- Prefill阶段计算密度高,矩阵计算单元容易忙起来,更容易受到计算能力限制;
- Decode阶段并行度下降,模型权重依然要读,Attention还要不断访问KV Cache,更容易卡在内存带宽和数据移动上;
- Agent串行调用会放大单次推理延迟,几十毫秒的差异会一路传到后面的步骤;
- 长上下文让KV Cache持续增长,调度器必须考虑请求数据所在位置,跨网络搬运本身就会消耗带宽和时间。
Jalapeño这次公开的数据,把Token吞吐、生成延迟和单位功耗下的推理能力摆到了台面上。Reddit上的争论暂时没有统一答案,但NVIDIA把Groq 3 LPU拉进推理系统、Google把TPU 8拆成偏训练和偏推理两条路线,几家公司几乎在同一时间重新拆芯片的工作,已经说明Token成本正在成为大模型硬件竞争的新坐标。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.