七类成本四类常被漏
为什么分开归集：硬件折旧、机房电力与制冷、存储与网络、软件与模型许可、集成人力、运维与备件、冗余容量。前四项在报价单上看得见，后三项散落在各部门预算里，汇总时才发现总量超出预期，此时已难调整。
利用率是成本的分母
按峰值采购必然带来闲置，这是私有化单位成本高的主因。怎么降：把可延迟的批处理排到低谷、把多部门需求汇进共享池、对稳定场景做量化或蒸馏，每一步都用评测集确认质量没有掉出可接受范围。
集成人力不是一次性
上线后仍有提示词维护、权限调整、评测回归与故障处理，通常按人天持续发生。为什么要单列：把它当成项目一次性支出，第二年就会出现系统还在、没人管的状态，最后被判定为失败项目，且难以追责。
优化顺序别倒过来
先清闲置与重复采购，再提利用率，然后换更小的模型或更低的精度，最后才谈硬件降配。为什么讲顺序：倒过来常见后果是：先降配，业务跑不动，又加回来，中间白折腾一轮，团队信任也被消耗。
适用与不适用
适合谁
- 已有私有化环境、想压单位成本的企业
- 多业务线共用算力、存在重复采购的集团
- 愿意投入评测以换取资源效率的团队
不适合谁
- 用量尚未稳定、还在验证场景的团队
- 把成本优化理解为单纯换更便宜的硬件
典型场景
一家零售集团的 IT 部门把三个业务线的推理需求汇总，发现各自按峰值采购、平均利用率不足一半。团队改成共享池加错峰批处理，把夜间报表任务移到低谷，季度复盘时用同一套评测集确认回答质量未下降。
可执行步骤
- 按七类成本逐项归集，标注责任部门与年度金额区间，形成一张可核对的总表
- 统计各业务线的峰值与均值，算出真实利用率与闲置率，作为优化起点
- 把可延迟任务挑出来，改成排队与错峰调度，先从低风险批次试起并留对比记录
- 对量化与蒸馏方案跑评测集，确认质量边界与降级表现后再逐步推广
- 每季度做一次成本复盘，决定扩容、回收还是继续观察一个周期
常见坑
- 只算采购价，漏掉电力制冷、备件与运维人力，三年总账远高于立项估算，预算中途被砍。
- 为省成本直接换小模型，跳过回归验证，关键场景准确率下滑，返工费用超过省下的部分。
- 各部门各自采购，闲置与重复并存，等到汇总才发现总量翻倍，此时已过预算年度无法调整。
自检与验收清单
- 七类成本都有归口部门与可核对的年度金额
- 峰值与均值分别统计，闲置率与利用率一并写进复盘材料
- 可延迟任务已识别，调度与配额策略同步调整
- 量化方案跑过回归测试，质量边界形成书面结论方可上线
- 季度复盘有明确结论，并写明下一步动作与责任人
常见问题
优化利用率会不会影响响应速度
会，取决于调度策略。把在线请求与批处理放在同一队列，低峰期没事，高峰期就互相挤占。做法是给在线请求设优先级与保底配额，批处理只用剩余容量，并持续监控分位延迟。
自建一定比租用便宜吗
不一定。自建成本随利用率摊薄，用量稳定且高时才显现优势；用量波动大或仍在增长期，租用与按量更划算。比较时要把人力与闲置都折进去，只看单价容易得出反向结论。
旧设备能不能继续用
可以用于非关键场景或作为备份，但要评估驱动与框架兼容性、能耗与故障率。把旧卡放进生产主链路，常见结果是故障频发且无备件，最后拖累整体可用性，维护成本反而更高。