“8000P园区一个月烧掉千万级电费”很适合做标题，却不是一张能复核的账。
8000P是算力口径，PUE衡量的是数据中心总能耗与IT设备能耗的关系。两者之间还隔着设备平均功耗、实际负载、运行时长和综合电价。少一个，都算不出月账单。
如果这里的P指某种精度下的峰值算力，还要继续追问：是哪种精度，是理论峰值还是持续可用算力？同样标成8000P，硬件组合和利用率不同，用电量不会自动相同。
PUE差0.15，金额不能靠猜
园区电费可以用一条基础公式估算：
园区月电费 = IT设备平均功耗 × PUE × 当月运行时长 × 综合电价
在IT负载相同的前提下，PUE从1.15升到1.3，新增电费为：
IT设备平均功耗 ×（1.3－1.15）× 运行时长 × 综合电价
这0.15当然会进入账单，但究竟对应多少支出，必须代入园区的实测功耗和电价。直接写成“每月多付数百万散热税”，缺了最关键的计算条件。
看到PUE 1.1时也要多问一句：这是设计值、某个时段的瞬时值，还是长期运行的平均值？三种口径不能混用。
液冷同样不是免检章。冷板液冷、浸没式液冷能否省钱，要同时核算建设投入、维护成本、设备稳定性和长期PUE，不能只凭技术名称下结论。
先看每瓦产出，再看芯片名
不论租用H100、910B，还是部署昇腾910C，只看标称TFLOPS都不够。真正应该写进采购、租赁和验收表格的，是目标模型在指定精度下的实测结果：吞吐、平均功耗、利用率、延迟和稳定性。
换句话说，厂商需要知道的不是一张卡“有多快”，而是它在实际业务里每消耗一瓦电，能稳定交付多少有效Token。
昇腾910C的适配也是如此。算子兼容只是第一步，显存碎片、内存搬运、批处理策略和CANN参数都会影响设备利用率。调优是否真的降低了单位Token成本，只能通过同一模型、同一负载下的前后压测确认，不能先写一个节省比例。
训练花一笔，推理每天续账
训练通常有明确的开始和结束，推理成本则会随着服务调用持续发生。模型一旦长期在线，每次请求里多出来的等待、空转和无效计算，都会不断累积。
但成本结构没有一个适用于所有公司的统一比例。“推理已占AI总支出的80%以上”缺少可核验的统一口径，也不能直接套在训练型团队、API服务和端侧产品上。
更值得盯的是具体环节。KV Cache压缩能否降低长上下文开销，Semantic Routing能否把请求可靠地分配给合适的模型，FP8或INT4量化能否在维持质量和延迟要求的同时减少资源占用，都要逐项测试。
FP8不是所有业务的固定底线，INT4也不是天然的“黄金平衡点”。如果量化带来输出质量下降、重试增加或延迟波动，省下的计算资源可能又会在别处花掉。
把能效比落到有效Token
比单独比较PUE更接近业务的指标，是每度电交付了多少有效Token：
业务能效 = 成功交付的有效Token数 ÷ 园区用电量
这里的“有效”不能只按模型生成量统计。未满足质量要求的回答、失败请求和内部重试，都不应被当成对外产出。否则Token数字很好看，成本仍然没有算清。
如果要进一步讨论毛利，还要把硬件租赁或折旧、网络、存储和运维成本放进来。电费是重要支出，但不能单独决定模型服务是否赚钱。
一张能用的园区月报，至少应回答这些问题：
- 8000P采用什么精度口径，是理论峰值还是持续可用算力；
- IT设备的平均功耗、负载和利用率是多少；
- PUE是设计值、瞬时值还是长期平均值；
- 同期交付了多少有效Token，延迟和成功率如何；
- KV Cache、语义路由、FP8或INT4调优前后，测试条件是否一致；
- 电费之外，硬件、网络、存储和运维支出是多少。
即便两家公司都使用Llama 4及其衍生版本，也部署了相近规模的硬件，最终成本仍要落到调度、缓存、量化、利用率和基础设施上。
8000P只是容量标签。能效比要回答的是一个朴素问题：同样一笔电费，谁交付的有效Token更多。所谓绿色AI，也不该只展示一个PUE数字，而应把这笔账完整地摊开。
