在算力中心立项或扩容前，最致命的错误往往不是“买贵了”，而是“算错了”——低估了训练集群规模导致项目延期，或高估了推理显存需求导致预算浪费。本节给出一线工程团队实际采用的速算方法，帮助你在方案设计阶段快速锁定 GPU 数量、显存容量和网络带宽的合理区间。
一、训练算力测算：从理论 FLOPs 到物理 GPU 数量
1.1 理论计算量：6N 法则
对于 Decoder-only 的 Transformer（当前主流 LLM 的架构选型，详见 3.7 节），单次前向传播（Forward）的理论浮点运算量约为 2 × 参数量 × Token 数。反向传播（Backward）约为前向的 2 倍。因此，完成一轮完整预训练的理论总计算量为：
\[
\text{Total FLOPs} \approx 6 \times N \times D
\]
其中：
- N：模型参数量（如 7B = 7 × 10⁹）
- D：训练 Token 总量（如 Llama 2 70B 用了约 2T Token）
- 系数 6 的来源：前向 2× + 反向 4×
示例：训练一个 13B 模型，使用 1T（1 × 10¹²）Token，理论 FLOPs ≈ 6 × 13×10⁹ × 1×10¹² = 7.8 × 10²²。
1.2 从理论到物理：引入 MFU
GPU 标称算力（如 A100 FP16 Tensor Core 的 312 TFLOPS）是实验室峰值。实际训练中，由于数据加载、通信、GPU 空闲、激活重计算等开销，模型浮点运算利用率（Model FLOPs Utilization, MFU） 通常在 35%–55% 之间。顶尖工程优化（FlashAttention、融合算子、最优并行策略）可逼近 60%。
因此，所需 GPU·小时数估算为：
\[
\text{GPU·Hours} = \frac{6 \times N \times D}{\text{GPU峰值算力} \times 3600 \times \text{MFU}}
\]
示例：用 A100（312 TFLOPS）以 45% MFU 训练上述 13B/1T 模型：
- 每秒单卡有效算力 = 312 × 10¹² × 0.45 ≈ 1.4 × 10¹⁴ FLOPS
- 总需 GPU·秒 = 7.8 × 10²² / 1.4 × 10¹⁴ ≈ 5.6 × 10⁸ 秒 ≈ 15.6 万 GPU·小时
- 若使用 128 张 A100，约需 51 天
工程提示：SFT/RLHF 阶段数据量小（通常百万到千万级 Token），但同样需要完整加载基座模型。虽然总 FLOPs 远低于预训练，但由于 batch size 小、序列长度分布不均，MFU 往往比预训练低 10–20 个百分点，不要直接按 Token 比例简单折算。
二、训练显存测算：参数、梯度、优化器与激活
训练阶段的显存占用是压垮单卡的最大瓶颈。以混合精度训练（FP16/BF16 参数 + FP32 优化器状态，详见 4.5 节）为例，显存可分为四大块：
| 显存项 | 计算公式 | 备注 |
|--------|---------|------|
| 模型参数 | \( 2 \times N \) 字节 | FP16/BF16 存储 |
| 梯度 | \( 2 \times N \) 字节 | 同参数精度 |
| 优化器状态 | \( 12 \times N \) 字节 | AdamW：FP32 主参数 (4) + 一阶动量 (4) + 二阶动量 (4) |
| 激活值 | 与配置强相关 | 序列长度、Batch Size、层数、隐藏维度；可用 Gradient Checkpointing 大幅降低 |
2.1 单卡显存速算（无 ZeRO 优化）
\[
\text{显存}_{\text{单卡}} \approx 16 \times N + \text{激活显存}
\]
即每 1B 参数约需 16 GB 纯参数/梯度/优化器显存，加上激活值。
- 7B 模型：约 112 GB + 激活 → 无法在单张 A100（80GB）上训练
- 13B 模型：约 208 GB + 激活 → 需要至少 4 张 A100（配合 ZeRO-3 / 张量并行）
2.2 ZeRO 优化后的显存分摊（第 9.5 节）
DeepSpeed ZeRO 通过切分优化器状态/梯度/参数，可将单卡显存压到接近：
| ZeRO 阶段 | 单卡显存估算 | 适用场景 |
|-----------|-------------|----------|
| ZeRO-1 | \( 4N + 12N/P + \text{激活} \) | 数据并行，P 为卡数；只切优化器状态 |
| ZeRO-2 | \( 2N + 14N/P + \text{激活} \) | 再切梯度 |
| ZeRO-3 | \( 16N/P + \text{激活} \) | 参数、梯度、状态全切；配合 Offload 可进一步压到 CPU/NVMe |
示例：用 ZeRO-3 在 8×A100 80GB 上训练 13B 模型：
- 参数切分后每卡参数/梯度/状态 ≈ 26 GB
- 激活值（序列 4096，Batch Size 1/GPU，Gradient Checkpointing）≈ 10–15 GB
- 总占用约 40 GB/卡，安全落在 80 GB 以内。
三、训练通信带宽测算：别让网络成为天花板
分布式训练中，卡间通信往往比计算更先成为瓶颈。
3.1 数据并行（DP）通信量
每轮迭代，各卡需 All-Reduce 同步梯度。通信总量约为：
\[
\text{通信量/卡} \approx \frac{2 \times \text{模型大小} \times (P-1)}{P} \approx 2 \times \text{模型大小}
\]
即每步每张卡要收发约 2 × 模型大小 的数据（如 13B 模型 FP16 权重对应约 26 GB 梯度聚合通信）。
3.2 所需带宽速算
若你希望通信耗时不超过计算耗时的某个比例（通常目标 <10%），则：
\[
\text{所需卡间带宽} > \frac{\text{通信量}}{\text{计算时间} \times \text{容忍比例}}
\]
经验法则：
- 对于千卡级集群训练百亿级以上模型，NVLink + InfiniBand NDR（400Gb/s） 是标配；
- 若只用 PCIe 或低速网络，数据并行基本不可行，必须转向张量/流水线并行以减少通信频次，但这会牺牲 MFU。
四、推理算力测算：Prefill 与 Decode 是两个世界
推理与训练的需求差异极大（第 16.2 节）。训练追求单次吞吐，推理则追求低延迟 + 高并发。推理过程分为两个阶段：
4.1 Prefill（首次填充 / 输入处理）
接收用户完整 Prompt，计算并生成第一个输出 Token。这是一次性开销，计算密集度类似训练的前向传播：
\[
\text{Prefill FLOPs} \approx 2 \times N \times \text{Input Tokens}
\]
4.2 Decode（自回归生成）
生成第一个 Token 后，每个后续 Token 都需要将新生成的 Token 拼回输入，重新过一遍模型。这导致：
\[
\text{Decode FLOPs per Token} \approx 2 \times N
\]
关键瓶颈转移：Decode 阶段 batch size 小、计算量低，但每个 Token 都要读取全部模型参数。此时限制因素往往不是 GPU 算力（Tensor Core），而是 显存带宽（Memory Bandwidth）——能否快速把权重从 HBM 搬进计算单元。
示例：A100 80GB 的显存带宽约 2 TB/s。读取 13B FP16 权重（26 GB）约需 13 ms。若生成 100 个 Token，仅权重读取就耗时 1.3 秒，还不算 KV Cache 和计算。这解释了为什么推理优化中量化（INT4/INT8，第 22.2 节）和 KV Cache 管理（PagedAttention，第 17.3 节）如此重要——它们直接减少显存搬运量。
五、推理显存测算：权重、KV Cache 与开销
推理显存占用是部署成本的核心：
\[
\text{总显存} = \text{模型权重} + \text{KV Cache} + \text{激活/临时缓存} + \text{系统开销}
\]
5.1 模型权重
| 精度 | 字节/参数 | 7B 模型 | 70B 模型 |
|------|----------|---------|----------|
| FP16/BF16 | 2 | 14 GB | 140 GB |
| INT8 | 1 | 7 GB | 70 GB |
| INT4/GPTQ/AWQ | ~0.5 | ~3.5 GB | ~35 GB |
5.2 KV Cache（第 16.5 节、第 22.3 节）
Transformer 每层的 Key 和 Value 矩阵需要在生成过程中缓存，避免重复计算。KV Cache 显存公式：
\[
\text{KV Cache} = 2 \times L \times h \times s \times b \times \text{Precision}
\]
其中：
- L：Transformer 层数
- h：注意力头维度（或总隐藏维度，取决于实现）
- s：当前序列长度（已生成长度）
- b：Batch Size（并发请求数）
- 2：Key + Value 两份
更直观的工程近似：每个 Token 每层的 KV Cache 约占 \( 2 \times 2 \times \text{隐藏维度} \) 字节（FP16）。以 Llama 2 7B 为例（隐藏维度 4096，32 层）：
- 每 Token KV Cache ≈ 2 × 2 × 4096 × 32 = 0.5 MB
- 若 Batch Size=16，序列长度 4096，则 KV Cache = 0.5 MB × 4096 × 16 ≈ 32 GB
这已经远超 7B 模型 FP16 权重本身的 14 GB。长上下文 + 高并发 = KV Cache 爆炸，是推理集群设计中最容易低估的部分。
六、推理吞吐量与并发测算
6.1 单用户延迟估算（Decode 阶段）
\[
\text{Time per Token} \approx \frac{\text{模型权重读取量} + \text{KV Cache 读取量}}{\text{显存带宽}} + \frac{2 \times N}{\text{算力峰值} \times \text{利用率}}
\]
对于小 batch 推理，第一项（显存带宽）通常占主导。
6.2 系统总吞吐
若使用 Continuous Batching（如 vLLM，第 23.1 节），系统吞吐不以单请求衡量，而以总生成 Token 数/秒衡量。此时需保证：
\[
\text{总显存} > \text{权重} + \sum_{\text{所有进行中的请求}} (\text{KV Cache})
\]
当显存满时，新请求必须排队。因此推理节点的并发上限往往由显存容量决定，而非算力。
七、一张实用的速算对照表
| 场景 | 核心公式/经验值 | 决策用途 |
|------|----------------|----------|
| 训练总 FLOPs | \( 6 \times N \times D \) | 估算总 GPU·小时成本 |
| 训练单卡显存（无 ZeRO） | \( 16N \) 字节 | 判断是否需要分布式 |
| 训练单卡显存（ZeRO-3） | \( 16N/P \) + 激活 | 快速选卡数和并行策略 |
| 推理单 Token FLOPs | \( 2N \) | 对比不同模型的 Decode 算力需求 |
| 推理权重显存 | \( N \times \text{精度字节数} \) | 决定单卡能否装下模型 |
| KV Cache / Token | 约 \( 4 \times L \times h \) 字节（FP16） | 评估长上下文服务的显存爆炸风险 |
| 带宽瓶颈检验 | 通信量 ÷ 实际带宽 << 计算时间 | 判断是否需升级 IB/NVLink |
八、小结与衔接
算力需求测算不是纸上谈兵，而是算力中心选型的第一道算术题：
- 训练侧：先用
6ND锁定总算力，再用16N检验单卡显存，最后用通信量校验网络是否会成为 MFU 杀手。 - 推理侧：区分 Prefill 与 Decode，警惕 KV Cache 对显存的吞噬，理解“量化省下的不仅是磁盘空间，更是显存带宽压力”。
测算完成后，这些数字将直接决定 18.2 节的算力中心定位——你究竟是建设一个训练型集群（追求极致算力密度与卡间互联）、一个推理型集群（追求显存容量与单卡并发），还是二者兼有的混合集群。在 19 章的硬件架构设计中，这些量化结果将转化为具体的 GPU 型号、显存规格和网络拓扑选型。