FDE W8D2 学习手册 · 容量规划与成本估算
W8 Day2 · B 级（工程核心）· 5h · 学完能给出"私有部署 vs API"的可信成本测算，并讲清容量与副本数怎么定
本日定位：Day1 把模型跑成了服务，Day2 算"这笔账划不划算、要几张卡"。候选人有 Java + 大数据背景，冲刺架构/负责人岗——老板最关心"上 LLM 一年花多少、值不值"。本日是面试里"成本和容量"题的标准答案来源。
学完能回答：① 私有部署成本怎么估算（GPU 时租 + 显存 + 副本数）；② API vs 私有部署的选型权衡（成本 / 延迟 / 数据合规）。
使用方法：先理解两种计费模式 → 掌握显存/KV 估算（呼应 Day1）→ 重点背成本公式与选型话术 → 做自测 → 配合《FDE-W8D2-评测题.md》。标注（左下★重要 / 右下📌待查）用于圈出自己易混的成本项。
一、两类成本模式：API 按 token vs 私有按 GPU 时租
1.1 本质区别
| 维度 | API（SaaS，如公有云大模型） | 私有部署（自购/租用 GPU） |
|---|
| 计费单位 | 每千 token（输入/输出分别计价） | GPU 时租 + 电费 + 运维人力 |
| 边际成本 | 随调用量线性增长 | 固定（卡在跑就计费，闲置也计费） |
| 数据 | 出域（需评估合规） | 不出域 |
| 弹性 | 极高，按需扩 | 受限于自有/租用卡数 |
| 适合 | 调用量波动大、早期验证 | 量大、稳定、强合规 |
架构师的核心判断：当月调用量足够大时，私有部署的"固定成本被摊薄"，单位 token 成本会低于 API；量小则 API 更省。这叫"成本交叉点"，是选型第一性原则。
两种模式：API 按 token 计费、边际成本随量线性涨；私有按 GPU 时租（固定）计费、闲置也花钱。量大且稳定时私有更省（固定成本被摊薄），量小波动大时 API 更省——这是选型第一性原则。
① 私有部署不是"免费"——卡空跑也计费，所以低利用率是最大浪费。② 别只比单价，API 的输入/输出 token 单价不同，长输出场景 API 成本会飙升。③ "私有一定更便宜"是误区，必须在自己的量纲下算交叉点。
二、API 模型成本结构
2.1 计费要素
- 输入 token 单价：通常低于输出（如输入 ¥0.5/千、输出 ¥1.5/千，示意）。
- 输出 token 单价：更高（生成更贵）。
- 缓存命中折扣：相同前缀（如 system prompt）命中缓存可打折（如 5 折）。
- 批量/异步折扣：离线批量调用常有折扣。
单次调用成本 = 输入token/1000 × 输入单价 + 输出token/1000 × 输出单价（缓存命中部分再乘折扣）
2.2 长上下文陷阱
RAG 每次把长文档塞进 prompt，输入 token 随文档长度线性增长，API 成本会随知识库变大而失控。这正是"私有部署 + 长上下文"可能更省的拐点之一。
对特药理赔 Agent，prompt 里常含长条款/病历，API 模式输入 token 巨大。架构师要算清"长上下文下 API 成本曲线"，才能说服老板上私有化或上缓存。
API 成本 = 输入×输入价 + 输出×输出价，且缓存命中、批量有折扣。RAG 长上下文会让输入 token 暴增、成本失控——这是推动私有化或缓存优化的重要依据。
① 很多估算漏算"system prompt + 长文档"这类每请求都发的输入 token，导致成本严重低估。② 缓存折扣有前提（前缀一致），动态拼接的 prompt 命中率低。③ 输出 token 单价高，要控 max_tokens 避免冗长回答烧钱。
三、私有部署成本结构
3.1 成本构成
| 项 | 说明 |
|---|
| GPU 时租 / 折旧 | 云租卡（元/小时）或自购折旧（元/月） |
| 电费 | 8 卡机约 2-4 kW，按当地电价 |
| 存储/网络 | 模型权重、向量库、带宽 |
| 运维人力 | 部署、监控、升级、排障 |
| 闲置损耗 | 低利用率时卡空跑的固定浪费 |
私有月成本 ≈ (卡数 × 时租 × 720h) + 电费 + 运维 + 存储网络
3.2 单位 token 成本推导
单请求成本 ≈ 私有月成本 ÷ 月总请求数；或 ≈ (单次GPU·秒成本) ÷ 单请求吞吐(token/s)
私有部署的"省钱"来自高利用率把固定成本摊薄。如果一天只跑几小时，单位成本远高于 API。架构师要算"利用率≥X% 才划算"，这是和老板对话的硬指标。
私有成本 = GPU 时租(或折旧) + 电费 + 运维 + 存储网络，卡空跑也计费。单位 token 成本 = 月成本 ÷ 月总 token。利用率越高越省；低利用率反而比 API 贵。
① 自购卡的"折旧"常被忽略，它和云租卡一样是真实成本。② 电费在 8 卡机上一月也不小，不能漏。③ 运维人力在负责人岗评估里必须计入，否则 TCO 失真。
四、GPU 显存估算（呼应 Day1）
4.1 显存 = 权重 + KV Cache + 激活 + 碎片
显存 ≈ 权重(fp16≈2B/参, int4≈0.5B/参) + KV Cache + 激活开销 + 框架碎片
4.2 常见模型显存（fp16）
| 模型 | 参数量 | fp16 权重 | int4 权重 |
|---|
| Qwen2.5-7B | 7B | ~14 GB | ~3.5 GB |
| Qwen2.5-14B | 14B | ~28 GB | ~7 GB |
| Qwen2.5-32B / DeepSeek-Lite | 32B | ~64 GB | ~16 GB |
| DeepSeek-V2/V3（MoE） | 总参大/激活小 | 按激活参估算显存 | — |
呼应 W8D1：vLLM 的 PagedAttention 提升的是 KV Cache 利用率（碎片部分），不改变权重本身显存。所以"装不装得下"先看权重，并发多少看 KV。
容量规划第一步就是"这张卡装不装得下"。架构师开口就能报出 7B/14B/32B 在各量化的显存，这是可信度的基石。MoE 模型要按激活参数算，不能按总参。
显存 = 权重 + KV + 激活 + 碎片。fp16 权重约 2B/参，int4 约 0.5B/参：7B≈14G、32B≈64G(fp16)/16G(int4)。装不装得下看权重，能扛多少并发看 KV。MoE 按激活参数算。
① 权重显存是下限，KV Cache 会随并发/长度叠加，别只算权重就说"能跑"。② MoE（DeepSeek）总参巨大但激活参小，显存远小于"总参×2B"的朴素估算。③ 碎片和激活需留余量（gpu-memory-utilization 不建议设 1.0）。
五、KV Cache 估算（呼应 Day1）
5.1 单请求 KV 显存
单请求KV ≈ 2 × num_layers × hidden_dim × seq_len × bytes_per_elem
例：某 7B 模型（32 层、4096 隐维、fp16=2B）在 seq_len=8192 时：KV ≈ 2×32×4096×8192×2 ≈ 4.3 GB/请求。可见长序列下 KV 比权重还夸张。
5.2 KV 与并发的关系
最大并发 ≈ (可用KV显存) ÷ (单请求KV峰值)
这正是 Day1 说的"长度↑ → 单卡并发↓"。容量规划的杠杆就在这里：降 max_model_len、量化、prefix caching 都能释放 KV 给更多并发。
KV Cache 是"并发的硬天花板"。架构师给老板承诺并发数时，必须能反推出"需要几张卡、每张卡留多少 KV"。这是 Day1 指标与 Day2 成本之间的桥梁。
单请求 KV ≈ 2×层数×隐维×序列长×字节。长序列下 KV 可能比权重还大，所以 max_model_len 直接决定单卡并发上限（最大并发≈可用KV÷单请求KV）。降长度/量化/前缀缓存都能提并发。
① 把 KV 估算漏掉，并发预算会虚高数倍。② prefix caching 能复用相同系统提示的 KV，显著降低重复开销——但 prompt 动态拼接会破坏复用。③ 估算用峰值 seq_len，否则高峰 OOM。
六、并发、队列与模型副本数
6.1 副本数推导
副本数 N ≈ 目标峰值QPS ÷ 单实例可承载QPS（在SLA内）
6.2 队列与降级
- 队列：超出 --max-num-seqs 的请求排队，TTFT 升高（Day1 指标）。
- 横向扩容：加副本 + 负载均衡（网关轮询/一致性哈希）。
- 降级：超阈值转小模型 / 返回缓存 / 转人工。
副本数不是越多越好——每张卡都是真金白银。架构师要算"SLA 下的副本下限"，并用自动伸缩（按 GPU 利用率）平衡成本与体验。负责人岗还要考虑多租户隔离（每租户独立副本 or 共享+配额）。
副本数 ≈ 峰值QPS ÷ 单实例QPS(满足SLA)。超并发的请求会排队（TTFT 升），对策是加副本+负载均衡，或降级到小模型/缓存/人工。副本数是成本与体验的旋钮。
① 副本数按"峰值"算会浪费，按"均值"算会崩——要按 SLA 容忍的排队概率选分位数。② 多副本要前面有网关做路由，否则请求扎堆单实例。③ 自动伸缩有冷启动延迟，突发流量要留缓冲副本。
七、Token 成本计算（单次 / 日 / 月）
7.1 三步算清
# 假设：理赔 Agent 日均 2 万次调用，平均每次 输入1500 + 输出400 token
# API 模式（输入¥1/百万token，输出¥3/百万token，示意）
api_per_call = 1500/1e6*1 + 400/1e6*3 = 0.0015 + 0.0012 = ¥0.0027
api_month = 0.0027 * 20000 * 30 ≈ ¥1620
# 私有模式：1×A100(¥10/h) 跑满
priv_month = 10 * 720 + 电费(¥300) + 运维(¥2000) ≈ ¥11,300
# 但私有承载全部量，单位成本随量摊薄
7.2 交叉点思维
上例中 API 在小量时便宜，但当调用量翻 10 倍（月 60 万次），API 月成本 ≈ ¥1.6 万 > 私有 ¥1.13 万——出现交叉点。量越大私有越香。该交叉点就是选型决策点。
给老板汇报永远带"交叉点"：低于 X 调用量用 API，高于则用私有。这是把技术选型翻译成商业语言的硬能力，面试官极看重。
Token 成本按"单次→日→月"逐级算。关键是交叉点：量小 API 省，量大私有省（固定成本摊薄）。汇报时给出"月调用超 X 万次就转私有"的决策线，比单纯比单价有力。
① 别用"平均调用"算交叉点，要用"目标期末量"。② 私有成本里的运维/电费在量增大时几乎不增，这是它后段更省的原因。③ 混合架构（热链路私有 + 长尾 API）往往总体最优，别二选一。
八、成本优化方案：缓存 / 批处理 / 小模型降级
8.1 三类手段
| 手段 | 怎么做 | 省什么 |
|---|
| 缓存 | 相同问答/前缀 KV 缓存；结果级缓存（相似问题命中） | 重复请求不进模型，省 token 与算力 |
| 批处理 | 离线任务合并批量、用 batch API 拿折扣 | 单价折扣 + 算力效率 |
| 小模型降级 | 分类/抽取用 7B，复杂推理才上 32B | 大幅降单请求算力成本 |
8.2 组合策略
- 能缓存的缓存（高频条款问答、固定模板）。
- 能批的批（夜间批量生成报告）。
- 能用小模型的用小模型（意图识别、字段抽取）。
- 实在要大模型才上调用的那部分。
对医疗保险场景，"分层用模"是降本主力：90% 的简单理赔问答用 7B 小模型，只有复杂特药审核才调 32B。成本可降一个数量级，体验几乎无感。
成本优化三板斧：缓存（相同/相似请求不进模型）、批处理（离线合并拿折扣）、小模型降级（简单任务 7B、复杂才 32B）。组合用，医疗场景分层用模可降本一个数量级。
① 结果级缓存要防"语义相同但答案过时"（如条款更新后缓存未失效）——需 TTL 或失效策略。② 小模型降级要有"升级触发条件"，否则简单任务误判漏审。③ 批处理只适合非实时，别把在线请求也攒批导致延迟爆。
九、API vs 私有部署：选型权衡
9.1 决策矩阵
| 关注点 | API 胜 | 私有胜 |
|---|
| 成本（大量稳定） | — | ✅ 摊薄后更低 |
| 成本（小量波动） | ✅ 零固定成本 | — |
| 数据合规 | — | ✅ 不出域 |
| 上线速度 | ✅ 即开即用 | — |
| 定制（量化/微调） | — | ✅ 全可控 |
| 弹性峰值 | ✅ 无限扩 | 受卡数限 |
9.2 混合架构（最推荐）
热链路/合规敏感用私有，长尾/突发峰值用 API 兜底；或核心模型私有 + embedding/小任务用 API。
成熟方案几乎都是混合：私有保合规与稳态成本，API 保弹性与冷启动。架构师要能画出"哪部分走私有、哪部分走 API"的边界，并说明切换条件。
选型不是二选一：量小/波动大/要快上线用 API；量大稳定/强合规/要定制用私有。最优往往是混合——稳态私有保成本与合规，峰值 API 兜底弹性。
① 强合规行业（医疗/保险/金融）数据不出域常是硬要求，此时"API 更省"要让位于合规。② 别为"显得先进"硬上私有，低利用率会亏钱。③ 混合架构要定义清晰的流量分配与降级策略，否则两难。
十、容量规划方法：SLA → 并发 → 副本
10.1 四步法
- 定 SLA：如 P99 TTFT ≤ 2s、P99 端到端 ≤ 8s、可用率 99.9%。
- 测单实例上限：用 Day1 benchmark_serving 在目标卡/量化下测出满足 SLA 的并发与吞吐。
- 算副本：副本 N = 峰值QPS ÷ 单实例QPS（留 20-30% 缓冲）。
- 算成本：N × 单卡时租 × 720h + 其他。
容量规划 = SLA → 单实例容量(实测) → 副本数(留缓冲) → 月成本
容量规划的本质是"用实测数字反推资源"。负责人岗要能把一份规划文档拍在桌上：SLA、实测数据、副本数、月成本、扩容触发条件，全链条闭环。
容量规划四步：定 SLA → 实测单实例容量（Day1 压测）→ 副本数=峰值QPS÷单实例QPS(留缓冲) → 算月成本。核心是"用实测数字反推资源"，不是拍脑袋。
① 单实例容量必须用真实 benchmark 测，不能套别人数字（卡型/量化/长度不同天差地别）。② 缓冲留太少，突发就崩；留太多烧钱。③ 容量规划要含"扩容触发条件"和"降级预案"，否则只是静态估算。
十一、真实案例：特药理赔 Agent 成本测算
11.1 假设与口径
| 项 | 值 |
|---|
| 日均调用 | 5 万次（月 150 万） |
| 平均 token | 输入 1800 + 输出 500 |
| API 单价（示意） | 输入 ¥1/百万、输出 ¥3/百万 |
| 私有硬件 | 2×A100 80G（¥20/h）跑 Qwen-32B-int4 |
11.2 测算
API月 ≈ (1800/1e6×1 + 500/1e6×3) × 150万 ≈ ¥4950
私有月 ≈ 20×720×2(双卡) + 电费¥600 + 运维¥3000 ≈ ¥31,800
→ 本量纲下 API 更省；若调用量 ×8（月1200万）则 API≈¥3.96万 > 私有≈¥3.18万，交叉点出现
诚实标注：上述为示意单价与估算，真实决策需以合同价、实测吞吐、真实调用分布为准。医疗合规若要求不出域，则私有优先级上调，交叉点右移也可接受。
这个案例展示"把业务量纲代入公式"的方法。面试时能现场套一个案例并说出交叉点，远比背概念得分高。关键是口径透明、假设明示。
案例套路：先列量纲（调用量、token、单价/硬件），再分别算 API 与私有月成本，找交叉点。本例量小 API 省，量×8 后私有反超。医疗合规要求不出域时，私有优先级还应上调。
① 案例数字务必标注"示意/估算"，不可当实测结论。② 真实交叉点受合同折扣、缓存命中率影响很大，要 sensitivity 分析。③ 合规硬约束会改写纯成本结论，要显式说明。
十二、学习资源（官方文档，中文非 OpenAI）
建议：先用手册 s4/s5 的公式在纸上手算一组 7B/32B 显存与 KV，再套 s11 案例模板做一次自己业务的成本测算，最后看 B站视频补全直觉。
十三、面试达标线①：私有部署成本怎么估算
| 步骤 | 动作 | 要点 |
|---|
| 1 装得下吗 | 权重显存（fp16/int4）+ KV + 激活 | 呼应 Day1，MoE 按激活参 |
| 2 并发多少 | 最大并发 ≈ 可用KV ÷ 单请求KV峰值 | 长度/量化/前缀缓存影响 |
| 3 副本几张 | 副本 N = 峰值QPS ÷ 单实例QPS(SLA内) | 留 20-30% 缓冲 |
| 4 月成本 | 卡数×时租×720 + 电费 + 运维 + 存储 | 闲置也计费，算 TCO |
一句话达标：能从"这张卡装不装得下（权重+KV）→ 单卡扛多少并发 → 要几张副本满足 SLA → 月成本多少"完整推一遍，并点出闲置浪费和 MoE 按激活参估算。
十四、面试达标线②：API vs 私有选型权衡
选型第一性原则：量大稳定且合规→私有（固定成本摊薄+不出域）；量小波动大→API（零固定成本+弹性）
最优常是混合：稳态私有保成本/合规，峰值 API 兜底
决策线 = 成本交叉点（月调用超 X 万次转私有），需结合合规硬约束上调优先级
- 成本维度：交叉点之前 API 省，之后私有省。
- 延迟维度：私有内网延迟低、稳定；API 受公网与限流影响。
- 合规维度：医疗/保险数据不出域常是硬要求，私有优先。
- 弹性维度：突发峰值 API 无限扩，私有受卡数限，故混合最优。
十五、W8D2 自测清单
- 能说清 API（按 token）与私有（按 GPU 时租）两类模式的成本本质差异。
- 能写出 API 单次成本公式，并点出长上下文导致输入 token 暴增的陷阱。
- 能列出私有部署成本结构（时租/电费/运维/存储/闲置），说明卡空跑也计费。
- 能估算 7B/14B/32B 在 fp16 与 int4 下的权重显存，并说明 MoE 按激活参算。
- 能写出单请求 KV Cache 公式，并解释它如何决定单卡并发上限。
- 能推导副本数 N ≈ 峰值QPS ÷ 单实例QPS（留缓冲）。
- 能按"单次→日→月"算出 API 与私有成本，并解释交叉点。
- 能讲出成本优化三板斧（缓存/批处理/小模型降级）及各自风险。
- 能在决策矩阵中比较 API 与私有的成本/延迟/合规/弹性优劣。
- 能描述"混合架构"为何最优，并画出私有/API 的流量边界。
- 能复述容量规划四步法（SLA→实测单实例→副本→成本）。
- 能结合特药理赔案例做成本测算，并诚实标注"示意/估算"。
十六、高频面试题速记卡
Q：API 和私有部署，到底哪个便宜？
看量。量小波动大→API（零固定成本）；量大稳定→私有（固定成本摊薄）。决策点是"成本交叉点"，且医疗合规常让私有优先。
Q：私有部署成本怎么估算？
卡数×时租×720h + 电费 + 运维 + 存储网络；卡空跑也计费，要算 TCO 而非只看卡租。
Q：为什么 RAG 用 API 可能很贵？
每次把长文档塞进 prompt，输入 token 随知识库线性增长，输入成本失控——这常是推动私有化/缓存的拐点。
Q：单卡能扛多少并发？
最大并发 ≈ 可用 KV 显存 ÷ 单请求 KV 峰值；降低 max_model_len、量化、开 prefix caching 都能提并发。
Q：副本数怎么定？
副本 N ≈ 峰值 QPS ÷ 单实例 QPS（在 SLA 内），并留 20-30% 缓冲防突发。
Q：成本优化三板斧？
缓存（相同/相似请求不进模型）、批处理（离线合并拿折扣）、小模型降级（简单 7B、复杂 32B）。
Q：为什么推荐混合架构？
稳态/合规走私有保成本与不出域，突发峰值走 API 兜底弹性；两难变双赢。
Q：容量规划四步？
定 SLA → 实测单实例容量（Day1 压测）→ 副本数（留缓冲）→ 月成本，核心是用实测反推资源。
Q：DeepSeek 这种 MoE 显存怎么估？
按激活参数量估（远小于总参），不能简单用"总参×2B"；否则会严重高估显存需求。
Q：缓存有什么坑？
结果缓存要防"语义相同但答案过时"（条款更新），需 TTL/失效策略；prompt 动态拼接会降低前缀缓存命中。
FDE W8D2 学习手册 · 容量规划与成本估算（面试级）· 配合《FDE-W8D2-评测题.md》自测
📌 待查★ 重要