谈到芯片能效，很多人第一反应是看峰值算力除以功耗，数字越大越好。这个算法在训练场景下有一定参考价值，但到了推理场景就容易失真。推理的输出是逐词元生成的，延迟、批量大小、序列长度和缓存命中情况都会影响最终的能效表现。只看峰值算力，等于默认芯片永远跑在满载状态，而真实的推理服务大部分时间都在等待、调度和传输数据，峰值算力根本跑不满。每瓦词元数这个指标的意义，正在于把分母从理论功耗换成真实功耗，把分子从理论算力换成真实产出。

算这笔账的第一步，是把分子定义清楚。词元数应该统计实际生成的有效词元，而不是包含填充位和重复计算在内的名义词元。批量推理里，填充位会让名义词元数虚高，如果按名义值计算，能效会被系统性高估。同样，投机解码或者缓存复用带来的加速，也应该按实际产出来算，而不是按模型前向次数折算。把分子定义为单位时间内真正交付给用户的词元数，指标才具备跨方案对比的意义。测试时还要注明批量大小和序列长度，因为同一个芯片在不同批量下的能效表现可能相差很大。

分母的界定同样关键。芯片本身的功耗只是整机功耗的一部分，显存、互连、供电转换和散热系统都要耗电。如果只算芯片功耗，能效数字会很好看，但对机房运营没有指导意义。更合理的做法，是分层记录功耗，芯片级功耗用于架构对比，整机功耗用于单机选型，机架级功耗用于容量规划。每一层都要注明测量方法和采样窗口，瞬时功耗和一段时间内的平均功耗不能混用。尤其要注意空闲功耗，推理服务存在明显的波峰波谷，空闲时的功耗占比越高，低负载下的能效就越难看。

测量方法决定了这笔账可不可信。常见的误区，是在短时间内跑满负载测一个峰值，然后直接外推为日常能效。真实服务是波动的，正确做法是采集一段覆盖波峰和波谷的完整业务周期，记录总词元产出和总耗电量，再用两者相除得到周期平均能效。压测时还要控制变量，固定模型、量化精度、批量策略和序列分布，否则换一个变量，能效数字就会跟着变。建议每次测试都输出完整的测试条件清单，包括模型规模、精度、批量大小、输入输出长度分布和并发水平，让别人能够复现。

除了计算本身，能效账还要考虑延迟约束。把批量拉得很大通常能提高每瓦词元数，因为算力利用率上去了，但首词元延迟和词元间延迟也会上升。用户体验有上限的场景，不能为了能效牺牲延迟。正确的做法，是在满足延迟目标的前提下谈能效，先划定延迟红线，再在这个红线内寻找能效最优的批量和调度策略。这样得到的能效数字，才是业务真正能用上的数字，而不是实验室里的极限值。

最后，能效对比要避免跨场景直接比较。端侧芯片和数据中心芯片的功耗量级不同，优化目标也不同，前者更看重待机和峰值功耗，后者更看重单位机架的吞吐和散热成本。同一块芯片在不同模型和不同精度下的能效排名也可能翻转，因此选型时应该用自己的业务模型和业务流量来实测，而不是照搬厂商宣传页上的数字。把每瓦词元数当成一套测量方法，而不是一个孤立的数字，这笔账才算得明白。