OpenAI Jalapeño 这个代号最近在圈子里传得很热。我第一眼看到“700W 打 1400W每千瓦吞吐高出 1.9 倍”这个结论时第一反应不是兴奋而是怀疑——这类能效数字在行业里见得太多了口径稍有不同结论就可能完全反转。但冷静下来重新算了一遍账这个数字并不是营销话术背后确实指向了推理基础设施里面一个长期被忽视的硬道理当算力规模大到一定程度决定你能部署多少模型、能以多低的价格提供服务的关键变量不是单卡峰值算力而是每千瓦功率能换来的有效吞吐。这篇文章我想把 Jalapeño 这个事件拆开聊透。先解释那个 1.9 倍到底意味着什么再说从 1400W 降到 700W 省掉的功耗去了哪里然后深入到“单位功耗吞吐为什么会涨”的底层机制最后聊一聊部署侧的真实影响和能效数据里最常见的陷阱。无论你是做推理服务、维护 GPU 集群还是单纯关心大模型成本走向这篇都应该能给你一些可以带进机房实操的判断依据。1. 先把这个“1.9倍”翻译成人话700W到底打出了什么成绩1.1 每千瓦吞吐的算式以及两个平台的真实差距先明确术语。所谓“每千瓦吞吐”标准定义就是在稳定运行状态下系统每消耗 1 千瓦功率单位时间内能完成多少个推理请求或者输出多少个 token。公式不复杂每千瓦吞吐 总吞吐量 / 系统总功耗如果拿 1400W 平台和 700W 平台对比设 1400W 平台的总吞吐为 T1700W 平台总吞吐为 T2那么“每千瓦吞吐高出 1.9 倍”用公式表达就是(T2 / 0.7) / (T1 / 1.4) 1.9化简后就是 T2 / T1 0.95。这个结果比“1.9 倍”本身更值得品味。意思是700W 平台在绝对吞吐上只需要做到 1400W 平台的 95%就已经能在单位功耗吞吐上反超 1.9 倍。换句话说这不是一个“低功耗小卡勉强够用”的对比而是“用一半的功耗做到几乎相同的总吞吐”。这才是真正硬核的地方。如果对标到具体场景假设 1400W 平台能稳定跑出每秒 10 万 token 的生成速度那么 700W 平台只需要每秒 9.5 万 token就能在能效比上实现翻倍式的领先。对于大规模推理集群来说这个差距直接决定了同样的电力容量下谁能塞进更多的有效算力。1.2 95%总吞吐这个数字为什么分量很重很多人看到“每千瓦吞吐高 1.9 倍”的第一反应是是不是因为 700W 平台本来就很弱基数低所以能效数字好看但如果按上面的公式反推我们发现 700W 平台的绝对吞吐其实非常接近 1400W 平台差距只有 5%。这就引出一个关键结论功耗减半并没有以牺牲吞吐为代价至少不是线性代价。如果只是简单地把芯片降频、砍半吞吐大概率会掉到 50% 甚至更低而每千瓦吞吐基本持平。Jalapeño 这类方案厉害的地方在于它通过架构和系统层面的重构把“功耗减半”的大部分损失都补了回来。从实际工程角度看这个 95% 特别微妙。它意味着在绝大多数情况下用户感知不到服务变慢但运营成本结构会发生质变。这也是未来推理服务竞争的一个分水岭当能耗成本占整体运营成本的比例越来越高谁能先把功耗压下来谁就能在不牺牲服务质量的前提下提供更有竞争力的价格。2. 从1400W到700W省掉的700W到底省在哪儿2.1 先把加速卡的功率账单拆开看要理解 700W 平台为什么能存在得先知道 1400W 平台的功耗都花在哪里。一颗现代 AI 加速芯片的功耗大致可以分为这么几块计算核心Cores真正做矩阵乘法、激活函数、注意力计算的部分占大头通常 50%~65%。片上存储与缓存SRAM/Cache数据在芯片内部搬移的功耗占比 10%~15%。芯片越大、缓存越多这部分越可观。片外存储接口HBM/DRAM访问 HBM 的功耗尤其在推理任务里权重和 KV cache 的反复读取是非常耗电的占比 10%~20%。互连与 IOPCIe、NVLink、光模块数据进出芯片的功耗占比 5%~10%。供电转换损耗从机房 400V 交流电到芯片核心电压中间经过多级转换每级都有损耗约 5%~10%。如果拿一张 1400W 的卡来算其中光存储访问和供电损耗加起来就可能超过 300W。700W 方案要想成立必须在这几个大项里面动刀。2.2 Jalapeño 砍掉的不是某一个部件而是整条功耗链从能效优化的常规路数来看700W 平台的功耗削减不会只靠压低芯片电压或降低时钟频率那样收益有限。更合理的推测是它做了一整套系统级减法存储子系统重新设计减少 HBM 容量或者改用更矮胖的存储层次让权重更长时间留在片上 SRAM减少去 HBM 搬数据的次数。HBM 的功耗跟访问频率成正比每减少一次搬运省下的功耗都是实打实的。供电系统精简1400W 的供电系统需要多相 VRM、大面积散热器和更粗的铜排这些都有功耗开销。如果芯片功耗目标降到 700W供电转换损耗可以近乎减半整套供电链路也能做得更短。散热功耗转移到系统层芯片功耗降下来后散热风扇、液冷循环泵的功耗也同步下降。这部分虽然不在芯片本身的数据表里但在机柜层面确实是实打实的电费。我的理解是Jalapeño 的本质不是“造了一颗更小的芯片”而是重新定义了一台推理节点的功率预算让每一瓦都花在计算而非维持系统运行上。这其实跟做数据中心的人常说的“power-proportional design”是同一个逻辑。2.3 冷却方式对整个功率预算的连锁影响这里有一个容易被忽视的联动效应。当单卡功耗从 1400W 降到 700W很多以前必须上液冷的场景就重新回到了风冷可覆盖的范围。风冷和液冷之间牵扯的不只是冷却方式还有整个机房的部署密度和维护复杂度。如果单卡 1400W一个标准 42U 机柜塞 4 台 4 卡服务器就已经接近 20kW这个功率密度基本得配液冷或者至少是冷通道密封加高风量风扇。而单卡 700W 时同样一个机柜容量能翻倍甚至更多而且空气冷却就能搞定。我见过不少团队在“1400W 高性能”和“液冷运维负担”之间纠结。Jalapeño 这种 700W 方案如果能在普通风冷环境下长期稳定运行它带来的收益不只是电费还有整个机房的基础设施简化和运维负担下降。这也是为什么我判断这个方向比单纯追求单卡峰值算力更有实际价值。3. 单位功率吞吐要涨1.9倍靠的不是“删减”而是“重构”3.1 计算侧让晶体管干更少的“无效功”功耗降一半吞吐只掉 5%根本原因在于 AI 推理任务里面有大量功耗并没有花在“有效计算”上而是花在等待和不必要的精度上。先看精度。很多推理负载在正式部署时都会用 FP8、INT8 甚至更低的精度。低精度运算最直接的好处是单位功耗能换来的计算次数大幅上升。如果 Jalapeño 在硬件层面把这个精度范围做到了极致比如把常见算子的默认精度压到 FP8再把部分算子直接硬化成低精度专用单元那么同样功耗预算下算力密度就会明显提升。再看稀疏化。Transformer 模型里真正被激活的神经元其实只占一小部分很多权重在推理时不动。传统硬件不管权重有没有用都会完整地做矩阵乘法大量功耗就消耗在这些无效计算上。支持稀疏化运算的芯片可以跳过零值或小权重块同样的功耗就能覆盖更多有效计算。这属于结构性的效率提升不是靠“压低频率省一点电”能比的。3.2 存储侧KV cache 和显存带宽的隐形收益推理任务和训练任务最大的不同在于推理有一个逐 token 生成的循环每一步都要读取完整的权重同时还要反复读写 KV cache。在这个过程里芯片算力往往是富余的真正的瓶颈反而是显存带宽和 KV cache 的容量。传统方案为了保证 KV cache 命中率会配置大量高带宽显存但这部分显存在短请求时是空闲的白付静态功耗。Jalapeño 如果在架构上把 KV cache 的管理做得更精细比如按请求的实际长度动态分配存储、引入更激进的缓存淘汰策略让同样容量的 HBM 装下更多并发请求那么单位时间完成的请求数就会涨。另一个关键点在“访存距离”。权重如果能尽量驻留在片上 SRAM就不用反复去 HBM 拉取省掉的功耗是双重的HBM 端少工作总线端少搬数据。这跟 CPU 场景里 L1/L2 缓存命中率提升节省功耗的逻辑完全一样只是大模型场景里数据的体量更大优化空间也大得多。3.3 调度侧连续批处理和 Prefill/Decode 分离的妙用如果说芯片架构是硬件底子那么运行时调度就是软件放大器。推理服务是典型的延迟敏感型任务空闲的芯片周期意味着白白消耗的功率。Jalapeño 能效提升的另一半我个人判断来自调度策略的进步。连续批处理Continuous Batching是目前推理引擎的标准操作一个请求生成完一个 token 后它的 GPU 时隙马上让给下一个请求而不是等整个 batch 都结束。这个机制能大幅提升芯片利用率直接拉高总吞吐。更进一步的是 Prefill/Decode 分离。Prefill 阶段处理用户输入的整段文本计算密集但不需要很低的延迟Decode 阶段逐个生成 token带宽密集且对延迟敏感。如果这两个阶段跑在不同的计算资源上就能避免“一个阶段空闲、另一个阶段排队”的互相拖累。分开之后芯片的有效工作时间变多了单位功耗的吞吐自然就上去了。这些调度优化虽然不直接改变芯片功耗但它们决定了同样功耗下能跑完多少请求。这也是为什么我坚持认为Jalapeño 的 1.9 倍能效优势一定包含软件层面的贡献而不只是硬件选型的结果。4. 部署视角能效高1.9倍机柜里能多塞多少算力4.1 从一个机柜的功率预算反推部署密度数据中心的机柜功率是有上限的。常见的风冷机柜功率上限在 10kW~20kW 之间液冷机柜可以做到 30kW~50kW但液冷不是所有机房都能上的。假设一个标准机柜的功率预算是 15kW如果单台推理节点功耗是 1.4kW对应一张 1400W 卡算上整机其他部件那这个机柜只能塞 10 台左右。但注意1400W 只是卡的功耗加上 CPU、内存、网络、风扇等其他部件整机功耗可能到 1.6kW~1.8kW实际能塞的节点数量还要打折。如果换成 700W 卡的方案整机功耗大概在 900W~1.1kW 区间同样 15kW 的机柜就能塞 13~16 台节点至少提高了 50% 的部署密度。哪怕单节点的绝对吞吐只达到原来的 95%机柜层面的总吞吐实际上反而上升了。这个账算下来事情就变了你不需要换机房、不需要加电力容量只是换了更节能的推理方案原来的机柜就能多跑 50% 以上的负载。在很多已经“电力容量锁死”的数据中心里这种靠提升能效来变相扩容的方案远比新建机房来得实际。4.2 散热、供配电和冗余设计的连锁变化把功耗降下来之后整个基础设施的设计约束都会跟着放松散热风冷可以覆盖更多场景不依赖液冷冷板机房改造成本大幅下降。供电PDU 的容量需求下降原来要升级的 UPS 和母线槽可能就不需要动了。冗余N1 冗余的备电系统功率也能做得更小机房的整体 CAPEX 都随之下降。这些变化在单机层面看不出来但在整个集群层面影响极大。尤其是那些已经运营了两三年、电力容量基本耗尽的数据中心要想扩容新算力要么等新机房交付要么就是靠这类高能效设备在现有功率余量里挤出来。4.3 TCO 模型电费、机柜、维护全都要重算最后算运维端的 TCO。假设一个 10MW 的推理集群全年负载平均功率在 70%电费按 0.6 元/度算一年电费大概 3700 万左右。如果方案从 1400W 换成 700W同等吞吐下功耗差不多减半一年光省下来的电费就近千万级别。这还不算因部署密度提升而省下的机柜租金以及散热系统维护成本下降带来的隐性收益。我做基础设施测算时一般会建一个粗略的四项模型电费、机柜租金、散热成本、维护成本。能效提升 1.9 倍对前两项的改善是立竿见影的散热和维护虽然幅度小一些但也在同一方向上叠加。整个集群的 TCO 优化幅度用“显著”来形容并不夸张。5. 能效数据里最常见的坑别被“每千瓦”骗了5.1 吞吐口径token/s、req/s、prefill/decode 完全是不同的世界任何能效对比之前先要确认“吞吐”到底指什么。在推理场景里至少有三种常见的吞吐口径输出 token 数/秒只看生成阶段的速度不包含输入处理代价。请求数/秒把输入和输出的整体耗时都算进去对短请求更有利。Prefill 吞吐和 Decode 吞吐分开计算两者对硬件资源的消耗模式完全不同。有些宣传数据喜欢用纯 Decode token 数来算每千瓦吞吐因为这个数字最容易做大。但真实生产环境里用户请求长短不一前处理、排队、上下文管理都会吃掉资源。如果只按一种口径的优势去对标另一种场景就容易得出过于乐观的结论。5.2 负载画像长输出和短对话的能量密度差距巨大能效数字还跟负载特征强相关。如果跑的是“多轮短对话”那么 Prefill 占的比例相对小Decode 阶段的带宽瓶颈更突出。如果跑的是“长文档总结”则 Prefill 阶段的计算量和内存占用会急剧上升。同样是 700W 和 1400W 两个平台对比在短对话场景下 700W 平台可能确实只需要 95% 的总吞吐就能持平但如果是长上下文场景两者的差距可能会被拉大或者缩小取决于硬件设计时更偏向哪类负载。所以评估一个能效方案时必须先拿自己的业务流量画像去测不能直接照搬别人的数字。5.3 空载、满载与散热功耗的分摊必须看整机数据芯片的功耗数据表是 100% 满载的理论值真实机房里没有一个卡永远跑在满载。空载时芯片功耗虽然低但整机里的 CPU、内存、网卡、风扇这些部件都在耗电散热系统也不是零功耗。这些“非计算功耗”如果占比大每千瓦吞吐就会被明显稀释。我曾经踩过这个坑某个 GPU 平台标的能效比很高但那是按“芯片满载 整机功耗恒定”的理想假设计算的。实际跑起来因为请求波动大芯片经常处于 40%~60% 负载区间整机的固定功耗占了总功耗的将近三分之一算下来每千瓦吞吐比宣传的差了一截。所以对比能效时我强烈建议看“整机级别、目标负载、目标延迟”三个维度下测得的数据而不是只看芯片数据表。Jalapeño 这种系统级方案如果只标芯片数据参考意义有限只有看到机柜端、服务端的实测才真正说明问题。6. 这件事对整个推理基础设施的启示能效正在成为新的军备竞赛6.1 自研 ASIC 与通用 GPU 的能效角力Jalapeño 的能效数字本质上是在向通用 GPU 阵营传递一个信号针对特定工作负载深度定制的硬件可以在能效上取得代差级优势。通用 GPU 要跑各种模型和框架算子覆盖广但必然有冗余自研推理芯片只需要服务自己的模型和推理栈可以做到极致的精确匹配。但这个优势要真正落地并不容易核心在于整个软件栈的配合能力。如果模型结构经常变、算子频繁更新硬件定制化程度越高适配成本也越高。所以这条路更适合有庞大固定负载、且能长期掌控模型演进的团队来走。对于大多数应用方直接买成熟通用算力仍然是更稳妥的选择但采购时确实应该把能效比放到更重要的位置。6.2 液冷、机架级优化和“以功率为第一约束”的设计思路过去设计推理集群大家习惯先定性能指标再算要多少卡、多少机柜最后发现电不够了。Jalapeño 这类方案提示我们更合理的设计思路可能是先确定一个机柜的功率上限然后反推在这个功率预算内能用什么样的设备组合出最大吞吐。这个思路如果推广开会让整个产业链都跟着调整。硬件厂商会更重视功耗感知的性能优化机房会更精细化地管理功率分配软件调度器也会把功耗作为调度目标而不是事后统计项。这些变化叠加起来整个行业对“算力”的定义都会慢慢从“峰值 FLOPs”转向“单位功率有效输出”。6.3 对 API 成本和模型部署策略的直接影响对普通开发者来说这些硬件层面的变化最终会反映到 API 价格和可用性上。推理成本里电费占比并不低如果新一代推理节点能以一半功耗提供接近同等的吞吐服务商就拥有了降价空间。这也会让一些原本因为推理成本过高而不太敢落地的场景比如长上下文助手、大规模端侧智能体重新变得现实起来。我个人判断接下来半年到一年会有更多团队沿着这个方向做文章有的在芯片侧优化功耗有的在调度侧提高利用率有的在模型侧降低推理所需算力。整个推理生态的竞争重心会从单纯的性能和价格逐渐转向一个更综合的指标体系而每千瓦吞吐大概率会成为其中最核心的一条。我自己做集群运营时有个习惯书架上一台新设备表上好看没用先插到机柜里空载跑一周、再带负载跑一周最终看电表读数和延迟分布。能效数字是方向标但真正能落地的方案还得过了机房里那些线缆、散热和突发流量这关才行。Jalapeño 的出现至少让我对这个方向多了不少信心。