硬件与折旧
卡与服务器的支出按年摊入，型号选择决定单位算力的成本。为什么不能只看单价：高配卡在低负载下单位产出更贵。做法是按业务的实际批量与并发选型；边界是业务增长快时，低配方案会很快需要扩容，折旧周期要一起算。
电力与制冷
高密度机柜的供电与散热成本随负载上升，PUE 高的机房会放大这部分支出。怎么做：把电费按业务线分摊，识别高耗低产的任务；边界是降频省电会影响延迟，不能单方面为省电牺牲服务承诺，需与业务确认。
网络与许可
多机训练需要高速互联，虚拟化与调度平台可能有许可费用。为什么容易漏：这部分常混在基础设施预算里。做法是单独列项并按项目归集；边界是许可模式与卡数、节点数相关，扩容前要重新核算，不能沿用旧口径。
运维与平台
监控、调度、镜像与备件都需要投入，规模小时单位成本更高。怎么做：优先用成熟开源组件，把自研限制在差异点；边界是平台能力不足会让利用率优化无法落地，不能为省人力砍掉调度与可观测能力。
闲置与碎片
为峰值预留、为隔离保留、开发环境常开，都会形成隐性浪费。为什么排第一：这部分不产生业务价值且可回收。做法是按周出闲置清单并设回收时限；边界是回收要留缓冲，避免误删正在调试的环境。
适用与不适用
适合谁
- 算力账单持续增长、需要解释构成的负责人
- 要为下一轮采购做取舍的财务与运维团队
- 多项目共用算力、需要建立配额规则的平台部门
不适合谁
- 算力规模很小、优化收益有限的团队
- 不愿意盘点闲置、只接受采购结论的组织
典型场景
某企业的算力账单连续增长但业务量平稳。财务与运维联合盘点后发现，开发测试环境长期占用整卡、两个已下线项目仍保留配额、部分任务因显存碎片无法调度。清理闲置配额、为开发环境设时限、调整切分规格后，新增采购计划被推迟，账单结构也变得可解释。
可执行步骤
- 按业务线归集硬件、电力、网络与平台四类支出，附口径说明与假设记录留档
- 统计各环境的实际占用与闲置时长，形成闲置清单、占比数据表与责任人名单
- 清理已下线项目的配额与长期常开的实例和镜像，并留记录备查与审批
- 调整切分规格以减少显存碎片，并实测任务可调度性、吞吐变化与拐点位置
- 按利用率设置扩容与回收触发线，纳入月度评审议程与责任人名单和记录机制
常见坑
- 只比较卡的单价比，忽略电力、许可与运维，总成本被明显低估，预算一再超支，采购被迫中断，业务进度受影响。
- 开发测试环境无限期占用整卡，测试需求挤占生产容量，业务高峰只能排队，却没人负责清理。
- 为隔离保留了大量余量却从不复核，余量逐渐变成固定浪费，也没人敢动，年年重复采购，成本就此固化下来。
- 没有闲置清单与回收时限，浪费长期无人认领，整改时找不到入口，只能继续追加采购预算。
自检与验收清单
- 成本是否已经按业务线归集，是否注明了关键假设与统计口径
- 各环境的实际占用与闲置时长是否统计，是否留有占比数据表
- 已下线项目的配额、常开实例与镜像是否都已清理并留记录备查
- 切分规格与显存碎片的情况是否复核过，是否做过实测验证与调优
- 扩容与回收是否设置了利用率触发线，是否纳入月度评审议程与责任人
常见问题
为什么先清闲置再扩容？
闲置回收不需要新增投入，见效也快，能先把账算清。若闲置大量存在却直接扩容，等于在浪费之上再加成本。建议先出一份闲置与碎片清单，设回收时限，再评估真实缺口。
电力成本要算多细？
至少要按业务线分摊电费与制冷，识别高耗低产的任务。不必精确到每台设备，但要能回答哪类任务最耗电、是否值得。PUE 高的机房尤其要看，它会把同样的负载放大成更高支出。
开发测试环境怎么管？
设时限与审批是常见做法：按项目周期分配，到期自动回收，延期要说明理由。也可以改用共享池或切分实例，避免长期独占整卡。关键是有清单与责任人，否则占用会一直延续下去。