企业官网建设流程全解析

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 平台的总吞吐为 T1，700W 平台总吞吐为 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%。
• 互连与 IO（PCIe、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 和母线槽可能就不需要动了。
• 冗余：N+1 冗余的备电系统功率也能做得更小，机房的整体 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 的出现，至少让我对这个方向多了不少信心。