成本核算与容量规划
一句话定义
把推理服务折算成钱只需要三个量：单卡吞吐（由压测得出）、实际利用率、GPU 时租——每百万 token 成本 = 租金 ÷（吞吐 × 3600 × 利用率）× 10⁶；容量规划则用 Little's Law 把峰值流量换算成副本数。
为什么重要
"自建还是买 API""上不上量化""加不加副本"的答案全在这一页的两个公式里：成本模型把工程优化翻译成 CFO 的语言，容量模型把业务增长翻译成采购单。没有这两个模型，推理优化就只是技术爱好。
前置知识
核心概念
- 成本链条：硬件时租 → 单副本吞吐（SLO 约束下）→ 利用率（真实负载不会打满）→ 每百万 token 成本。链条中利用率是最大折扣项：峰值冗余、流量波动、维护窗口，生产系统长期利用率常在 30–60%。
- SLO 约束的吞吐：容量数字必须来自"满足 TPOT/TTOT SLO 的最大并发"下的实测吞吐（kp-002 的 goodput），理论峰值只用于可行性初筛。
- 容量规划：Little's Law（kp-023）换算并发 → 副本数 = 峰值并发/单副本安全并发 × 冗余（1.3 常用）。
- 三个成本场景：API 采购（直接按 token 单价）、自建专属（固定租金+利用率折扣）、端侧（一次性硬件，边际成本趋零）——选型本质是流量规模与隐私约束的函数。
原理与机制
成本模型的原理是把异质资源（算力、带宽、显存）统一折算成"每小时租金"，再除以"实际产出的有效 token"：吞吐由 SLO 约束下的压测得出，利用率由负载曲线的峰谷比决定，两者相乘才是真实产出。容量一侧用 Little's Law 把 QPS 与请求时长合成并发数——因为 LLM 的资源占用挂在并发（KV 与批位置）而非裸 QPS 上，这是它与传统 API 容量规划最大的不同。
公式与模型
可复现例：A100 时租 $1.8，7B W4A16 压测得 SLO 内吞吐 2500 tok/s，利用率 50%：每小时产出 2500×3600×0.5 = 4.5M token，成本 = 1.8/4.5 ≈ $0.40 / 百万 token。把吞吐翻 2 倍或利用率提 20 个百分点，成本各降约一半——这就是前 20 个知识点的"商业价值换算"。
容量：峰值 30 QPS、平均请求 6s → 180 并发；单副本安全并发 48 → 180/48×1.3 ≈ 4.9 → 5 副本，再乘 $0.40/百万 得到月度预算。
图示
租金(固定) ─┐
压测吞吐 ───┼─► 成本/1M token ─► 与 API 单价对比 → 自建/采购决策
利用率(折扣) ┘
峰值QPS×时长 ─► 峰值并发 ─► ÷单副本并发 ─► 副本数(×1.3) ─► 采购/扩容实例或案例
决策案例：月均 12B token 的产品。API 报价 $0.5/百万 → $6000/月；自建按上例 $0.40/百万、但需 5 副本常驻（利用率按 50% 计）≈ $6500/月且要负担运维——量级相当时自建不省钱，除非流量再增 3 倍（利用率升至 80%+）或有数据合规硬约束。这个演算解释了为什么"自建省成本"常是错觉。
常见误区
- "用理论峰值吞吐算成本"：未计利用率折扣，实际成本常被低估 2–3 倍。
- "利用率越高越好"：逼近 100% 意味着无冗余，排队尖刺会击穿 SLO；成本模型里要留余量。
- "容量按平均流量规划"：按峰值（或峰值时段分时扩缩，kp-023）规划，否则晚高峰雪崩。
- 忽视隐性成本：网关、存储、可观测性与值班人力通常占总成本 15–30%。
伦理与可持续性
推理是能耗密集型负载：能耗 = 功率 × 时间，吞吐优化即降碳——同一模型用 W4 量化 + 连续批处理服务同等流量，能耗可降一半以上。选型时应把"单位 token 能耗"与成本并列披露，避免用更大模型盲目堆体验。
自测题
- 时租 $2、SLO 吞吐 1800 tok/s、利用率 60%，求每百万 token 成本。
要点：2/(1800×3600×0.6)×10⁶ ≈ $0.514。
- 为什么容量规划用并发数而不是 QPS？
要点：LLM 请求时长差异巨大（输出长度决定），Little's Law 的并发=QPS×时长才是调度资源真正的量。
- 自建何时才比 API 划算？
要点：流量大到利用率足够高（一般 70%+）、或有合规/定制硬需求时。
与其他知识点的关系
吞吐数字来自 kp-002/kp-022 的压测；副本换算即 kp-023；量化与压缩决策（kp-009/kp-012）由本页回算 ROI；误区汇总见 kp-029。
延伸阅读
本节不适用——成本模型为工程实践归纳，公式与本库各知识点的数字闭环即可复核。