最近 OpenAI 首款自研芯片 Jalapeño 的性能首秀引起了不少关注。外界讨论最集中的数据是在 DeepSeek R1 模型上Jalapeño 的每瓦 AI 吞吐量约为 GB300 的 1.7 倍。单看“每瓦吞吐量”这个表述很容易被理解成“芯片跑得更快”但它其实更像一个成本指标同样消耗一瓦电能能多生成多少 token。对靠 token 计费、对电费和散热敏感的推理服务来说这可能是比单纯 TOPS 更有参考意义的数字。这篇内容不打算替芯片厂做宣传而是把这条消息拆开来看每瓦吞吐量到底怎么定义为什么自研推理芯片容易在能效上超过通用 GPU团队评估这类数据时需要注意什么以及在自己的推理服务里如何用开源工具复现类似测量。1. 每瓦 AI 吞吐量先搞清楚“1.7 倍”是在比什么1.1 公式从 tokens 到 joules每瓦 AI 吞吐量的本质是“单位能量产生的有效 token 数”。先看两个基本量吞吐量Throughput推理服务在单位时间内完成的输出 token 数单位通常是 tokens/s。功耗Power芯片、板卡或整机在实际运行时的平均功耗单位是 W。于是每瓦吞吐量 吞吐量 / 平均功耗 (tokens/s) / W tokens / J最后一步可以解释一下1 W 等于 1 J/s所以(tokens/s) / W tokens/(s * J/s) tokens/J。也就是说“每瓦每秒生成多少个 token”和“每焦耳能量生成多少个 token”是同一个指标。它把性能和时间维度的功耗压缩成一个可以直接衡量推理成本的值。举例来说如果某块板卡跑一个 7B 量化模型稳定输出 50 tokens/s平均功耗 300 W那么它的每瓦吞吐量是50 / 300 0.167 tokens/J如果另一块板卡能输出 80 tokens/s但功耗是 600 W那么每瓦吞吐量只有 0.133 tokens/J。绝对吞吐量更高但按能量算却更低。在机房容量、电费和碳排受限的场景里后者可能并不是更好的选择。这个公式看起来简单真正的难点在口径。1.2 为什么推理场景比训练场景更看重每瓦吞吐量大模型训练时集群规模大作业可以长时间并行GPU 利用率高绝对算力和通信带宽通常比功耗更重要。但 LLM 推理服务是持续在线、按需响应的请求进来才计算空闲时也有显存占用和基础功耗而且大部分 token 是逐个生成的访存带宽和调度开销往往比纯算力更能决定吞吐。在推理场景里单次请求生成几百上千个 token 是常态。推理模型比如 DeepSeek R1 还会在给出最终答案前产生大量思考内容输出 token 数量会明显多于普通对话模型。当输出 token 变多芯片上的矩阵乘单元、显存带宽、KV cache 访问都会持续吃资源。此时每瓦吞吐量直接反映了“在固定电费预算下能支撑多少并发用户”是推理平台选型时容易和“峰值算力”脱钩的指标。1.3 三种容易混淆的指标峰值算力、实际吞吐量、每瓦吞吐量很多芯片材料的标题喜欢用 TOPS、TFLOPS 来描述算力但这并不是推理能力的直接证明。把三个指标放在一起看会更清楚。指标常见单位看什么局限理论峰值算力TOPS、TFLOPS芯片纸面上的运算能力无法直接换算成 token 数实际吞吐量tokens/s在给定负载下服务的输出能力没有考虑功耗和部署密度每瓦吞吐量tokens/J 或 tokens/s/W单位能量能完成多少 token高度依赖模型、batch、量化方式一个芯片理论算力高不代表跑 DeepSeek R1 时吞吐高。深层原因是LLM 推理受内存带宽、cache 命中率、算子调度、并发队列等多方面制约。峰值算力只是理论天花板实际能发挥多少要看模型结构和推理引擎能不能把它喂满。1.4 比较口径不一致数据就会失真如果只看到“Jalapeño 是 GB300 的 1.7 倍”这样一个数字不能直接得出“Jalapeño 在所有场景都更节能”的结论。比较每瓦吞吐量时至少要声明以下口径模型是哪一个大版本DeepSeek R1 的原始 671B MoE还是蒸馏后的 7B、16B 模型。输入 prompt 长度、输出 max_tokens、是否流式返回。并发数和 batch 大小是单条顺序请求还是大批量并发。推理框架和版本比如 vLLM、SGLang、TensorRT-LLM。数据类型和量化方式比如 BF16、FP8、INT8、INT4。功耗边界是裸芯片、板卡、整机还是包含机房制冷。这些条件稍微变动数值可能差出两到三倍。因此更合理的读取方式是这条新闻只说明在某个给定模型和一定负载下Jalapeño 的能效表现优于 GB300具体优势能否迁移到自己的场景需要测量验证。注意官方数据的“1.7 倍”是一个特定测量结果不是对所有负载的承诺。若要将它用于选型需要拿到完整测试方法而不是直接相信倍数。2. 为什么自研芯片更容易在能效上得分2.1 GPU 的通用性支出正是推理 ASIC 想省掉的部分GPU 是典型通用并行计算设备。它既要为游戏图形设计几何与光栅化管线也要支持通用计算、大模型训练、科学计算、视频编解码。为了通用性GPU 内部有大量可编程调度器、多级缓存、指令分发逻辑需要为不同形状的算子分配资源。这些逻辑本身消耗晶体管和功耗而推理模型真正高频的运算集中在几个固定模式上矩阵乘、激活函数、归一化、attention、KV cache 读写。推理 ASIC 的思路是把通用性砍掉把晶体管面积和功耗预算集中在已知的核心运算上。一个典型架构会围绕大规模矩阵乘单元、片上 SRAM、高带宽存储控制器设计让数据尽量在片上流动。少了一层通用调度逻辑单位功耗能完成的 token 数自然可能更高。需要说明的是这里的“自研芯片”指 OpenAI 的第一款 ASIC 推理芯片公开细节仍然有限。业界已知的 TPU、Groq LPU、Cerebras 晶圆级引擎都是走类似“用硬件匹配模型结构”的路线只是各自的存储和调度策略不同。2.2 推理芯片如何在设计上逼近物理上限要理解 ASIC 为什么省电可以从三个关键开销来看。第一指令开销。GPU 需要把计算任务拆成 kernel由驱动和调度器分发到 SM固定功能 ASIC 可以在制造时就把数据流和微码固化省掉大量指令发射和同步操作。第二数据搬运。LLM 推理中权重读取往往比计算更费电。芯片每次从头显存读权重都要付一比特功耗。推理芯片会尽量扩大片上 SRAM把权重、KV cache、中间结果放在离计算单元近的地方减少 HBM 访问。第三调度确定性。GPU 上不同 kernel 会被动态调度占用率变化会导致功耗波动。ASIC 可以在硬件层面按照固定流水线处理 token功耗曲线更平稳平均功耗更容易控制。这些设计能不能让“DeepSeek R1 的每瓦吞吐量达到 GB300 的 1.7 倍”从工程上看是可能的前提是芯片和模型结构匹配度足够高。DeepSeek R1 是 MoE 模型推理时需要根据路由把请求分配到多个 expert涉及大量权重选择和动态加载。如果 ASIC 在 MoE 路由、多 expert 并行、KV cache 管理上做了专门优化能效优势会更明显如果只是通用矩阵乘加速那 1.7 倍并不容易做到。2.3 能效优势是有代价的软件栈与灵活性专用芯片的能效通常以灵活性为代价。一个模型结构升级、一个算子变化、一种新的量化方法出现通用 GPU 可以通过升级 CUDA 代码、TensorRT 插件、PyTorch 算子来适配ASIC 则需要 SDK、编译器、算子库同步更新。最极端的情况是模型结构变化超出芯片数据流设计后续只能靠低效拆分来支持。这也是芯片厂商都在花大力气做编译器和运行时生态的原因。OpenAI 自研芯片如果只服务自己的模型和推理服务不需要支持所有用户的所有算子软件栈压力会小很多。工程团队如果考虑在使用自研芯片的云服务上部署需要提前确认支持的模型、精度、上下文长度和采样参数范围。2.4 从已知推理芯片的设计思路看 Jalapeño 可能做了什么