生产 6：成本调优
谁该读这一篇？ 既要 SLO 又要省钱的业务方 / 运维。 前置阅读：
04-slo.md、04-optimizations/03-quantization.md。 耗时： 30 分钟 学完能： 1. 算 GPU 单位成本：$/M tokens； 2. 列出影响成本的 6 个杠杆； 3. 在 SLO 约束下选最经济的配置； 4. 评估 spot / 包年 / 按量的取舍； 5. 写一份月度账单分析模板。
1. 单位成本：$/M tokens
最有用的成本指标：每生成 100 万 token 花多少钱。
举例：
- 4× H100 节点，按量 \$32/hr。
- 单副本（TP=4）throughput = 3000 token/s = 10.8M token/hr。
- 副本数 = 1：cost = \$32 / 10.8M = \$2.96 / M token。
对照 OpenAI / Anthropic 公开价格：
| 服务 | $/M output token (粗略 2026) |
|---|---|
| 自建 SGLang 70B FP8 (H100) | 0.5 - 3 |
| GPT-4o | 10-20 |
| Claude Sonnet 4.x | 15 |
| Gemini Flash | 0.3-1 |
自建优势：模型自主、数据私有；劣势：复杂度高。
2. 影响成本的 6 个杠杆
2.1 模型规格
70B vs 7B：模型大 10×，throughput 慢 ~10×，单 token 成本约等。 但 70B 输出质量好，需要 token 数少 → 端到端成本可能更低。
衡量：**$/任务**，不光是 $/token。
2.2 量化
FP8 比 BF16 throughput 1.5-1.8×，单 token 成本降 35-45%。 精度损失 < 1%（业务 eval 验证后）。
2.3 Batch size
KV pool 装得越多，并发越高，单卡 token/s 越高。
但代价：TTFT 上升（请求等队列）。
SLO 允许时尽量提 --max-running-requests。
2.4 Cache 命中率
每命中 1 token = 省 1 token 的 prefill flops。
高 cache 业务能把单 token 成本降 30-50%。
02-core-concepts/03-cache-aware-scheduling.md 的核心收益。
2.5 副本利用率
平均利用 50% vs 90%：成本差 1.8×。 对策：错峰调度、多业务共用、KEDA 自动缩容。
2.6 投机解码
接受率高时再省 1.5-2×。
不适合时是负优化（04-optimizations/02-speculative-decoding.md §11）。
3. Spot vs 按量 vs 包年
| 模式 | 折扣 | 风险 |
|---|---|---|
| 按量 | 0 (baseline) | 0 |
| Spot / Preemptible | 50-70% off | 随时被回收 |
| 1 年承诺 | 30-40% off | 需求估准 |
| 3 年承诺 | 50-60% off | 大额绑定 |
策略：
- 基线流量用包年（稳定）。
- 峰值溢出用按量（弹性）。
- Spot 跑离线 batch 任务（embedding / 评测 / 微调）。
不建议把在线推理放 Spot：被回收时 abort 会引起雪崩。
4. 输入 / 输出 token 比例对成本影响
LLM 推理两个阶段的成本不同：
- Prefill：每 token 算力大但一次性。
- Decode：每 token 算力小但要 N 次。
单 token 成本 ≈ α × prefill_cost + β × decode_cost
如果 prompt:output = 4:1（chat 典型），decode 占主导。 如果 prompt:output = 50:1（总结、RAG），prefill 占主导。
P/D 分离对长 prompt 业务能省成本（05-distributed/04-disaggregated.md）。
5. 跨业务摊薄
Chat / RAG / Agent / Embedding 共用副本：
单业务高峰错开 → 副本总数 << 各业务独立总和
代价：
- 隔离差。
- 一个业务突增影响其他。
需要：
- 优先级调度。
- 配额限制。
- 监控按业务标签（
08-multi-tenant.md）。
6. 月度账单拆解模板
# SGLang Cost Report - 2026-05
## 总览
- 总 token: 1.2 B output token
- 总成本: $4,820
- 单位: $4.02 / M tokens
## 拆分
| 业务 | Token | Cost | $/M | 备注 |
| --- | --- | --- | --- | --- |
| Chat | 800 M | $2,700 | $3.38 | cache hit 65% |
| RAG | 250 M | $1,200 | $4.80 | 长 prompt |
| Agent | 130 M | $670 | $5.15 | 多步 |
| Embedding | 20 M | $250 | $12.5 | bs 太小 |
## 资源
- 副本数: 6 平均 (peak 10)
- GPU: 4× H100 / 副本 = 24 H100·hr/hr * 24 * 31 = 17856 H100·hr
- GPU cost: $4,464 (按量 + 包年混合)
- Network / storage / misc: $356
## 利用率
- Peak: 95% 周一 14:00
- Off-peak: 30% 周日凌晨
## 优化建议
- Embedding 业务用更大 batch 或合并到主副本，省 $200/月
- Agent 业务接受率低，关 spec decoding 试一试
- 周末缩容到 4 副本，省 $400/月
7. 成本仪表盘
Grafana 加：
- $/M token 时序（按业务）
- 副本利用率（avg / peak）
- 闲置成本（副本数 × 闲置时间 × 单价）
- 各业务 token 占比
8. 常见省钱反模式
| 反模式 | 后果 |
|---|---|
| 拼命降 max_running_requests | TTFT 好看但容量浪费 |
| 用 INT4 不验业务 eval | 输出质量降，业务返工 |
| Spot 跑在线 | 雪崩风险 |
| 关 cache 让数据"公平" | 单 token 成本翻倍 |
| 业务每个独立部署 | 利用率低，账单倍增 |
9. 选型决策：买 vs 自建
| 因素 | 选商用 API | 选自建 |
|---|---|---|
| 流量 < 1B token/月 | ✓ | |
| 流量 > 10B token/月 | ✓ | |
| 数据合规要求 | ✓ | |
| 团队没 LLM 运维 | ✓ | |
| 需要私有模型 / 微调 | ✓ | |
| 业务变化快、不稳定 | ✓ |
自建临界点常在 5-10B token/月。
10. 小结
- 成本指标：$/M tokens（不是 $/hr）。
- 6 个杠杆：模型规格、量化、batch、cache、利用率、spec decoding。
- 部署模式 mix：包年 + 按量 + spot。
- 输入输出比例决定 P/D 分离收益。
- 月度报告拆业务，定向优化。
11. 自检
- 我的业务 prompt:output = 8:1，开 P/D 分离能省多少？
答案
8:1 表示 prefill 算力占主导（8 × prefill_flops vs 1 × decode_flops × N_layers，前者通常 5-10× 后者）。 合一模式下：prefill 抢算力让 decode 抖动，长尾 p99 TPOT 涨；为达 SLO 副本要超配 30-50%。 P/D 分离后：prefill 节点专攻算力（每 FP8 GPU 4k-8k token/s prefill），decode 节点专攻带宽；按 8:1 比例配 Prefill:Decode = 1:4。 省成本：(a) 各自精确配比，超配率从 30% 降到 10%；(b) prefill 节点可用更便宜 GPU（不需大 HBM）；(c) decode 节点 max_running_requests 更高（无 prefill 抢算力）。 实测总成本能降 20-30%；但**部署复杂度翻倍**，要权衡。短期内业务量不大时不开。- FP8 vs BF16 业务 eval 不变，单 token 成本能降多少？
答案
FP8 在 H100 上 throughput 1.5-1.8× BF16（FP8 Tensor Core 算力是 BF16 的 2×，受 attention / memory bandwidth 摊薄实际 1.5-1.8×）。 `$/M tokens = GPU rate / throughput`，throughput 1.5× → 成本 **降 33%**；throughput 1.8× → 成本 **降 44%**。 加 FP8 KV cache 后 KV 容量翻倍，max_running_requests 可加倍 → 再降 20-30% 成本。 总叠加：FP8 W8A8 + FP8 KV 比 BF16 单 token 成本降 **40-55%**。 前提：业务 eval 验证精度损失 < 1%（H100 + LMM 通常都满足）；A100 上 W8A16 收益小一些（约 20-30%）。- 利用率从 40% 提到 70%，成本变化？
答案
利用率 = 实际算力 / 物理算力。提升利用率意味着相同副本数扛更多流量。 `成本 ∝ 副本数 ∝ 1 / 利用率`。 40% → 70% → **副本数降 43%**，成本同比例降。 月账单 $10k → $5.7k，省 $4.3k/月。 提升手段：(a) 错峰调度（白天 chat、夜间总结 batch）；(b) 多业务摊薄（chat + embedding 共用）；(c) HPA 缩容 off-peak；(d) Spot/Preemptible 跑非关键流量。 注意：利用率 > 85% 时 p99 长尾恶化；通常 65-75% 是 sweet spot。- Spot 跑在线推理为什么危险？
答案
Spot / Preemptible 实例**云厂商可以 2-5 分钟通知后强制回收**。 后果： (1) **in-flight 请求被 abort**：长输出请求（如 2 分钟的 RAG）被切断，客户端看到 5xx。 (2) **CUDA Graph 重建**：替代 Pod 上线又要 5 分钟启动 + capture；流量在这期间被剩余副本扛，可能触发雪崩。 (3) **副本数突变**：Spot 实例集群可能短时间内多个被回收，剩余副本压力剧增。 (4) **PDB 失效**：PDB 防的是主动 drain，回收是云层面动作，PDB 管不到。 适合 Spot：(a) 离线 batch（embedding / 评测）；(b) Mock / 测试环境；(c) 训练 fine-tune。 不适合：任何带 SLO 的在线推理。- 月账单 embedding $/M 偏高，可能原因？
答案
embedding 任务的特点是**单次 forward，无 decode**，throughput 应该极高（chat 的 5-10×）。如果 $/M 反而高： (1) **batch size 太小**：客户端一次只传 1-5 条文本，没填满 GPU。embedding 应大 batch（128-256）。 (2) **模型选大了**：用 7B Llama 做 embedding，远不如 335M BGE-large 高效。 (3) **副本和 chat 混用**：chat 调度策略不适合 embedding（cache-aware 没用），HPA 按 chat 指标扩缩，embedding 用了多余的副本。 (4) **冷启动比例高**：embedding 副本被 KEDA 缩到 0 太狠，每次起新副本都收 cold start 成本。 (5) **量化没开**：embedding 模型 FP16 跑，没开 INT8。 解决：embedding 独立小副本组 + 大 batch + 小模型 + 不缩到 0。12. 下一步
07-router.md— 跨业务路由。08-multi-tenant.md— 多租户隔离。09-versioning.md— 模型版本切换。
参考：Anthropic / OpenAI 公开价格表；GPU 公有云价目表。