54.1 为什么容量规划是 FDE 的必备能力

在 FDE（前沿部署工程师）的真实交付现场，最常被客户追问的两个问题是："这套 AI 系统到底要花多少钱？"和"峰值来了扛不扛得住？"这两个问题本质上是同一个问题——容量规划与成本建模。

算力贵是行业级事实。一张 NVIDIA H100（80GB）的按小时云单价在 2024–2025 年间长期维持在 2.5–4.0 美元/卡·小时区间，A100（80GB）约 1.5–2.5 美元/卡·小时。一个典型的 8 卡 H100 节点跑满一天就是 480–770 美元，一个月（按 720 小时）就是 1.4 万–2.3 万美元。客户听到这个数字后，第二句话几乎一定是："能不能少用点卡？"或者"能不能告诉我什么时候该扩、什么时候该缩？"

这就是 FDE 必须掌握容量规划的根本原因：

• 预算可控：客户决策层需要在立项前看到 TCO（Total Cost of Ownership，总拥有成本）区间，否则项目根本拿不到预算审批。
• SLA 可达：客户业务方会承诺 P95 延迟、可用率、吞吐量指标，FDE 必须把业务指标翻译成 GPU 数量，否则上线即违约。
• 可辩护：当 CFO（首席财务官）质问"为什么是 16 张卡而不是 8 张"时，FDE 必须能拿出测算公式和数据来源，而不是凭感觉。

一句话原则：FDE 的容量规划不是"拍脑袋估个数"，而是"业务负载 → token 流量 → GPU 数量 → 美元成本"的可追溯推导链。

值得强调的是，传统 Web 系统的容量规划以 QPS（Queries Per Second）为核心指标，而 LLM 系统必须以 token/秒 为核心。原因很简单：同一个"请求"，输入 200 token、输出 50 token 的成本，和输入 8000 token、输出 2000 token 的成本相差几十倍。如果按请求计数来规划，必然系统性低估算力需求。

54.2 容量估算：从业务流量到 GPU 数量

54.2.1 四步推导法

容量估算遵循一条清晰的推导链：

1. 业务流量 → 日均请求量、峰值 QPS、平均会话轮次
2. token 流量 → 平均输入/输出 token 数、峰值 token/秒
3. 单卡吞吐 → 目标模型在目标硬件上的 token/秒（实测）
4. GPU 数量 → 峰值 token/秒 ÷ 单卡吞吐 ÷ 利用率余量

54.2.2 核心估算公式

公式 54.1（峰值 token 吞吐）峰值输出 token/秒 = 峰值 QPS × 平均输出 token 数 ÷ 平均解码并行度调整系数

更稳妥的工程化写法： 峰值 token/秒（输出）= 峰值并发请求数 × 单请求输出 token/秒峰值 token/秒（输入）= 峰值 QPS × 平均输入 token 数（prefill 瞬时压力）

公式 54.2（GPU 数量）所需 GPU 数 = 峰值 token/秒 ÷（单卡 token/秒 × 利用率）× 冗余系数 其中：利用率通常取 0.7–0.8（留出调度、KV cache 抖动空间）；冗余系数取 1.2–1.5（应对突发流量与单点故障）。

54.2.3 单卡吞吐的实测参考值

单卡 token/秒不能从厂商 PPT 抄，必须用目标模型 + 目标硬件 + 目标推理引擎（vLLM / TensorRT-LLM / SGLang）实测。下面给出 2024–2025 年公开基准的区间参考，仅供初估，落地必须自测：

模型	硬件	推理引擎	输出吞吐（token/秒/卡）	备注
Llama-3 8B FP16	A100 80GB	vLLM 连续批处理	2500–3500	高并发场景
Llama-3 8B FP16	H100 80GB	vLLM 连续批处理	4000–5500	较 A100 提升 50–60%
Llama-3 70B FP16	A100 80GB ×8（张量并行）	vLLM	800–1400（每卡均摊）	需 8 卡才能装下权重
Llama-3 70B FP16	H100 80GB ×8	vLLM	1500–2200（每卡均摊）	MoE 模型 H100 提升更明显
Mixtral 8×7B FP16	H100 80GB	vLLM	1800–2800	arXiv 实测：1 rps 时 $15.25/M token，25 rps 时骤降

数据来源：arXiv 2606.11690（并发感知成本方法论）、Anyscale 连续批处理基准、NVIDIA Developer Blog（LLM Benchmarking Fundamentals）。

54.2.4 一个完整测算示例

场景：某金融客户客服助手，Llama-3 70B FP16，部署在 H100 80GB。

• 日均请求量：50 万次会话，平均 3 轮对话
• 单轮平均：输入 1200 token，输出 350 token
• 峰值 QPS：业务高峰 80 QPS（早 9–10 点开盘时段）
• 峰值并发：80 × 平均响应时长（约 7 秒）≈ 560 并发

测算：

1. 峰值输出 token/秒 = 560 并发 × 单请求输出 50 token/秒 ≈ 28000 token/秒
2. 单卡 H100 吞吐（70B、高并发）≈ 1800 token/秒
3. 所需 GPU 数 = 28000 ÷ (1800 × 0.75) × 1.3 ≈ 27 张 → 向上取 32 张（4 个 8 卡节点）

结论：4 个 8 卡 H100 节点，月度推理算力成本约 4 × 8 × 720 × 3.0 ≈ 6.9 万美元/月。这个数字必须在立项前摆到客户决策层桌上。

54.3 推理成本模型

54.3.1 token 成本的核心公式

公式 54.3（每百万 token 成本）成本/百万 token =（GPU 小时单价 × 10⁶）÷（单卡 token/秒 × 3600 × GPU 利用率 × 张量并行度）

以 H100 3.0 美元/小时、单卡 1800 token/秒、利用率 0.75 为例：

成本/百万 token =（3.0 × 10⁶）÷（1800 × 3600 × 0.75）≈ 0.62 美元/百万输出 token

对比 OpenAI GPT-4o（2025 年公开定价约 2.50 美元/百万输入、10 美元/百万输出），自建 70B 模型在输出侧便宜约 16 倍——但前提是 GPU 利用率真的能撑到 0.75。这就是下一节的胜负手。

54.3.2 GPU 利用率：成本模型的胜负手

未优化的推理服务，GPU 利用率往往只有 20–40%（Spheron、YottaLabs 公开数据）。这意味着同样一张卡，优化前后的有效吞吐差 2–4 倍，对应成本差也是 2–4 倍。

利用率低的根因有三类，对应的解法也不同：

低利用率根因	现象	解法
静态批处理	请求到齐才批，GPU 空等	连续批处理（continuous batching）
内存碎片	KV cache 装不下，频繁 OOM	PagedAttention（vLLM）
prefill/decode 混跑	prefill 算力密集，decode 访存密集，互相阻塞	chunked prefill / 分离式推理

Anyscale 的公开基准显示，vLLM 的连续批处理 + PagedAttention 相比朴素批处理可获得最高 23 倍吞吐提升，同时降低 p50 延迟。这是单一最大杠杆。

54.3.3 批处理增益曲线

并发度对每 token 成本的影响是幂律衰减。arXiv 2606.11690 给出的 Mixtral 8×7B 在 H100 上的实测：

并发（rps）	每百万 token 成本	相对 1 rps
1	15.25 美元	1.0×
5	4.80 美元	0.31×
10	2.40 美元	0.16×
25	0.90 美元	0.06×

从 1 rps 到 25 rps，每 token 成本下降约 17 倍。这意味着：低流量场景下自建推理的单 token 成本可能比调 API 还贵。FDE 必须诚实告诉客户：如果日均请求量只有几千次，直接调 API 几乎一定更划算。

54.4 训练与微调成本

54.4.1 三类成本拆解

训练/微调成本不是单一数字，而是三类成本叠加：

1. 算力成本：GPU 小时 × 单价
2. 数据成本：标注、清洗、人工审核
3. 人力成本：ML 工程师、数据工程师、领域专家

54.4.2 微调算力成本实测区间

以 Llama-3 70B 为例（io.net、Anyscale、Introl 公开数据汇总）：

方法	硬件需求	单次成本	适用场景
LoRA / QLoRA	1–2 张 H100 或 RTX 4090	15–30 美元/次	任务适配、风格对齐
7B 模型 LoRA	单消费级 GPU	<10 美元/次	快速实验
全参数微调 70B	8× H100 80GB，1 天	200–300 美元/次	领域深度注入
全参数微调 70B（大规模）	16× A100 80GB	1000+ 美元/次	生产级定制

关键结论：LoRA/QLoRA 通常能以 0.1% 的成本达到全参数微调 95–99% 的效果（Michiel Horstman、Exxact 公开评测）。在客户预算敏感时，FDE 应优先推荐 LoRA 路线，把全参数微调留作"效果不达标时的兜底"。

54.4.3 数据成本：被严重低估的一项

数据成本是 FDE 报价中最容易遗漏的项。一个典型的垂直领域微调项目，数据成本往往占总成本的 40–60%：

• 专家标注：医疗、法律、金融领域，单条高质量样本 5–30 元人民币
• 多轮校验：每条样本通常需要 2–3 轮交叉审核
• 数据清洗：去重、去毒、格式统一，约占标注成本的 20–30%

测算公式：数据成本 = 样本数 × 单条标注单价 ×（1 + 校验轮次系数）×（1 + 清洗系数）

示例：1 万条金融问答样本，单价 15 元，校验系数 0.3，清洗系数 0.25：

10000 × 15 × 1.3 × 1.25 ≈ 24.4 万元

这个数字必须在方案中显式列出，否则客户会以为"微调就是跑个脚本"。

54.5 RAG 系统成本

RAG（检索增强生成）的成本结构由四个组件叠加：

组件	成本驱动	典型计价
向量数据库	存储量 + 查询 QPS	Pinecone 按维度+副本；自建 Milvus 按 CPU+内存+SSD
嵌入模型	文档数 × 平均长度 + 查询数	每百万 token 0.02–0.13 美元（text-embedding-3 量级）
检索	查询 QPS × 召回数	向量库 + 重排序模型
生成	召回上下文长度 × 生成长度	见 54.3

RAG 的隐性成本在于上下文膨胀：召回 5 段、每段 500 token，意味着每次生成都要多消耗 2500 输入 token。如果日均 50 万查询，仅上下文部分就是 12.5 亿 token/日的额外输入压力。FDE 在做 RAG 方案时，必须把"召回数 × 平均段长"作为一个独立成本项测算，而不是只算生成模型。

优化杠杆：召回段数从 5 降到 3（配合重排序）、段长从 500 压到 300、嵌入模型用开源 BGE-M3 自建——三项叠加通常能把 RAG 生成成本降 40–60%。

54.6 Agent 系统成本

Agent 是 LLM 成本结构中最难预测的一类，因为它放大了所有不确定性：

• 多轮放大：一个任务平均 5–15 轮 LLM 调用，每轮都消耗 token
• 多模型组合：规划用大模型（如 Claude/GPT-4 量级）、执行用小模型（7B–14B）、嵌入用专用模型
• 工具调用：每次工具调用的输入输出都进入下一轮上下文，token 累积增长
• 失败重试：工具失败、规划错误导致的重试，成本翻倍

54.6.1 Agent 成本测算公式

公式 54.4（单任务 Agent 成本）单任务成本 = 平均轮次 × Σ（每轮输入 token × 输入单价 + 输出 token × 输出单价）×（1 + 重试率）

实测经验值：一个中等复杂度的企业 Agent 任务（如"查订单 → 改地址 → 发通知"），平均 8 轮、每轮输入 2000 token、输出 400 token，使用 GPT-4o 量级模型：

8 × (2000 × 2.5/10⁶ + 400 × 10/10⁶) × 1.2 ≈ 0.058 美元/任务

看起来便宜，但放到日均 10 万任务的规模上就是 5800 美元/天，约 17 万美元/月。Agent 的成本爆炸是指数级的，FDE 必须在 PoC 阶段就建立 token 消耗的实时看板。

54.6.2 Agent 成本优化策略

• 模型分级路由：简单判断用 7B，复杂规划才调大模型，可降本 50–70%
• 上下文压缩：用摘要模型压缩历史轮次，避免线性增长
• 工具结果裁剪：工具返回的原始 JSON 只保留必要字段
• 缓存工具结果：相同工具调用直接命中缓存

54.7 存储、网络与运维成本

算力成本之外的三项隐性成本，常被 FDE 低估：

• 存储成本：模型权重（70B FP16 约 140GB）、KV cache（高并发时数十 GB/卡）、训练数据集（TB 级）、日志与审计数据。云上对象存储约 0.023 美元/GB/月，但高频访问会叠加请求费与出口费。
• 网络成本：跨可用区流量、跨区域复制、出口带宽。云厂商出口流量 0.08–0.12 美元/GB，大规模推理集群的跨节点通信（张量并行）会显著推高网络成本。
• 运维成本：监控（Prometheus + Grafana）、日志（ELK）、告警、值班工程师人力。这部分约占总算力成本的 15–25%。

经验值：自建集群的 TCO 中，硬件只占 50–60%，剩下 40–50% 是电力、机房、网络、人力。FDE 在比较"自建 vs API"时必须算全口径，不能只比 GPU 单价。

54.8 总拥有成本（TCO）建模

54.8.1 TCO 五层模型

FDE 给客户的 TCO 报告应包含以下五层，缺一不可：

层级	内容	占比经验值
L1 算力	推理 + 训练 GPU	40–55%
L2 存储/网络	向量库、对象存储、出口流量	10–15%
L3 数据	标注、清洗、采购	15–25%（项目初期更高）
L4 人力	ML 工程师、运维、领域专家	15–25%
L5 软件/许可	商业模型 API、向量库企业版、MLOps 平台	5–10%

54.8.2 自建 vs API 的决策矩阵

维度	调 API	自建
初期投入	极低（按量付费）	高（集群采购/租赁）
单 token 成本（高流量）	高	低（量大后反超）
单 token 成本（低流量）	低	高（利用率低）
数据合规	依赖供应商承诺	完全自主
定制能力	受限	完全可控
运维负担	几乎为零	高

拐点经验：当日均 token 消耗超过约 5–10 亿 token/日（输出 token 计），自建通常开始比 API 便宜。低于这个量级，调 API 几乎一定更经济。FDE 不要为了"显得专业"而强行推荐自建。

54.9 成本优化杠杆全景

54.9.1 六大杠杆排序（按性价比）

杠杆	成本降幅	质量影响	实施难度
1. 连续批处理（continuous batching）	5–23× 吞吐	几乎无	低（换推理引擎即可）
2. 权重量化（INT8/INT4）	50–75% 显存	95–99% 精度	中（需校准）
3. KV cache 量化（INT4）	44–68% cache 显存	极小（带校准）	中
4. 语义缓存（GPTCache）	命中部分免算	无	中（需评估命中率）
5. 模型分级路由	50–70%	任务相关，需评测	高（需路由策略）
6. 弹性扩缩容	20–40%	无	高（需流量预测）

54.9.2 杠杆详解

量化：FP16 → INT8 显存减半、成本降约 50%、精度保留 95–99%；FP16 → INT4 显存降 75%、精度保留 90–95%。INT4 KV cache 相比 INT8 再省 44%、相比 FP16 省 68%（OpenVINO、LMDeploy 实测）。量化是性价比最高的单一杠杆。

语义缓存：对重复或语义相近的查询直接返回缓存结果，完全省掉推理。命中率取决于业务——客服 FAQ 类场景可达 30–50%，开放问答场景通常 <10%。FDE 必须先实测命中率再决定是否上线。

模型分级路由：用一个轻量分类器（甚至规则）判断请求难度，简单请求走 7B，复杂请求走 70B。实测可降本 50–70%，但需要严格的 A/B 评测保证质量不退化。

弹性扩缩容：基于流量预测自动扩缩 GPU 节点。日间流量是夜间的 5–10 倍的场景下，弹性可省 30–50% 成本。难点在于冷启动慢（模型加载需 1–5 分钟），需配合预热策略。

54.10 给客户做容量与成本方案的模板

FDE 交付一份可被客户决策层认可的容量成本方案，建议包含以下七个部分：

1. 业务负载画像：日均/峰值 QPS、平均 token、会话轮次、季节性波动
2. 模型与硬件选型：目标模型、量化方案、推理引擎、硬件规格
3. 容量推导：用公式 54.1、54.2 完整推导 GPU 数量，附实测单卡吞吐数据来源
4. 成本拆解表：按 54.8.1 的五层模型分项列出，标注假设与单价来源
5. 优化路径：列出拟采用的优化杠杆及预期收益（量化表格）
6. 风险与边界：峰值余量、单点故障、扩容冷启动时间、数据增长曲线
7. 决策建议：自建 vs API 的拐点分析、分阶段扩容路线图

FDE 红线：方案里每一个数字都必须能追溯到来源（公开基准、自测数据、云厂商定价页），不能出现"经验上大概"这类不可辩护的表述。

54.11 反模式与陷阱

FDE 在做容量规划时最常踩的坑：

• 低估峰值：只看日均 QPS，忽视早晚高峰的 5–10 倍峰值。正确做法是按 P99 流量规划，留 1.2–1.5 倍冗余。
• 忽视 prefill 压力：只算输出 token 吞吐，不算输入 token 的瞬时 prefill 算力压力。长输入请求会瞬间打满 GPU，导致 TTFT（Time To First Token）飙升。
• 按请求数而非 token 数规划：这是最经典的错误，会导致系统性低估 3–10 倍。
• 忽视利用率：假设 GPU 跑满 100%，实际只有 20–40%。必须用真实利用率测算。
• 漏算隐性成本：只报 GPU 单价，不报网络、存储、人力、数据成本，导致客户预算被击穿。
• 盲目推荐自建：低流量场景下自建比 API 贵几倍，却因为"显得专业"而推荐，损害客户信任。
• 忽视冷启动：弹性扩容时模型加载需数分钟，峰值来了扩不出来，直接 SLA 违约。
• 量化不做评测：直接上 INT4 不测精度，质量退化后才回滚，浪费一周工期。

本专题小结

AI 系统的容量规划与成本建模，本质上是把"业务流量"翻译成"美元"的工程化推导。核心要点：

1. 以 token/秒为基本单位，而非 QPS；这是与传统 Web 容量规划最大的区别。
2. 利用率是成本胜负手，连续批处理 + PagedAttention 是单一最大杠杆（最高 23 倍吞吐）。
3. 并发度决定单 token 成本，低流量场景自建比 API 更贵，FDE 要敢于建议客户调 API。
4. TCO 必须五层全口径：算力、存储网络、数据、人力、软件许可，漏任何一层都会让报价失真。
5. 量化是性价比最高的优化，INT8 保留 95–99% 精度、降本 50%，应作为默认选项。
6. 每个数字都要可追溯，FDE 的专业度体现在公式与数据来源，而不是"经验估算"。
7. Agent 与 RAG 是成本放大器，必须在 PoC 阶段就建立 token 消耗实时看板，防止指数级失控。

容量规划不是一次性工作，而是一个随业务增长、模型迭代、硬件演进而持续更新的动态模型。FDE 的价值，在于把这个模型建得足够扎实，让客户在任何时刻都能回答"再加一个业务线要花多少钱"。

本专题来源

本专题数据与公式综合自以下公开来源：

• arXiv 2606.11690《A Concurrency-Aware Methodology for LLM Infrastructure Cost》（H100 上 Mixtral 8×7B 的并发-成本实测，1→25 rps 成本降约 17 倍）
• arXiv 2511.17593《A Performance Study of vLLM and HuggingFace TGI》（vLLM vs TGI 吞吐、延迟、利用率对比）
• NVIDIA Developer Blog《LLM Inference Benchmarking: Fundamental Concepts》（TPS、TTFT 基准定义）
• Anyscale《Achieve 23x LLM Inference Throughput with Continuous Batching》（连续批处理 23 倍吞吐提升基准）
• Anyscale《Fine-Tuning LLMs: LoRA or Full-Parameter — An In-Depth Analysis with Llama-2》
• io.net《LLM Fine-Tuning Budget Guide》（LoRA/QLoRA/全参数微调成本区间：7B LoRA <10 美元、70B QLoRA 15–30 美元、70B 全参数 200–300 美元）
• Introl《Fine-Tuning Infrastructure: LoRA, QLoRA, and PEFT at Scale (2025)》
• OpenVINO / LMDeploy 文档（INT4 KV cache 量化：较 INT8 省 44%、较 FP16 省 68%）
• Morphllm《LLM Inference Optimization: Cut Cost & Latency at Every Layer》（FP16→INT8 降本 50% 保留 95–99% 精度；FP16→INT4 降本 75% 保留 90–95% 精度）
• Spheron、YottaLabs 公开分析（未优化推理 GPU 利用率仅 20–40%）
• GMI Cloud《Compare GPU Cloud Pricing for LLM Inference Workloads》（每 token 成本公式：GPU 小时单价 / 3600 / token/秒）
• Databricks《LLM Inference Performance Engineering: Best Practices》
• Run.ai《Serving Large Language Models: Benchmarking Study》（vLLM vs TensorRT-LLM 在不同 QPS 与 batch 下的吞吐曲线）

落地提示：以上单卡吞吐与成本数字为公开基准区间，实际项目必须用目标模型 + 目标硬件 + 目标推理引擎自测校准。云厂商 GPU 单价随区域、租期（按量/包月/预留）、供需波动较大，报价时以云厂商定价页实时数据为准。