📚 课程目录第3章 AI算力需求分析

3. AI算力需求分析：深度学习训练/推理的算力需求、模型规模与算力关系

3.1 算力需求的三层解构：从模型到芯片

要理解AI算力需求，不能只盯着GPU的峰值算力（FLOPS），而应从模型算法层 → 计算图算子层 → 硬件执行层三层递进拆解。深度学习训练的本质是前向传播（Forward）计算损失 + 反向传播（Backward）计算梯度，而推理则只保留前向传播。每一层网络的计算量由张量形状（Tensor Shape）和算子类型（卷积、矩阵乘、归一化等）共同决定。

以最核心的矩阵乘法（GEMM）为例，全连接层或注意力机制中的QKV变换，其计算量公式为：

单层前向计算量 = 2 × M × N × K （MAC操作计为2次浮点运算）
其中：
  M = Batch_size × 序列长度（或空间位置数）
  N = 输出特征维度
  K = 输入特征维度（含通道数）
反向传播计算量 ≈ 前向的 2 倍（需分别计算权重梯度和输入梯度）

因此，一次完整的训练迭代（前向+反向）总浮点运算量约为 6 × 模型参数量 × 训练Token数（对于Transformer类模型）。这个“6倍法则”是估算训练算力需求的黄金公式。

核心公式：训练总算力需求（FLOPs）≈ 6 × N（参数量） × D（训练数据Token数）。推理单次请求算力需求 ≈ 2 × N（参数量） × 输出Token数（忽略KV Cache命中部分）。

3.2 模型规模与算力的量化关系：Scaling Law 实战

OpenAI 在2020年提出的 Scaling Laws 揭示了模型性能与算力、参数量、数据量之间的幂律关系。核心结论是：在计算预算固定时，模型参数量与训练Token数应按比例增长。后续 DeepMind 的 Chinchilla 法则进一步修正：最优情况下，参数量 N 与训练 Token 数 D 应满足 D ≈ 20N，即一个70B参数的模型，需要约1.4万亿Token的训练数据才能达到计算最优。

这一法则直接决定了算力规划：

参数量翻倍 → 单次迭代计算量翻倍，但若同时保持数据量按比例增长，总计算量变为原来的 4倍（2×2）。
训练效率（MFU）：实际GPU利用率通常只有 35%～55%（受通信开销、数据加载、算子效率影响）。规划算力时必须除以MFU。
显存容量约束：训练时需同时存储参数、梯度、优化器状态（Adam需2份动量）、激活值。混合精度训练下，每参数字节数 ≈ 2（参数FP16）+ 2（梯度FP16）+ 8（优化器FP32状态）+ 激活值开销，通常按每参数 20～40字节 估算。

案例：训练一个 70B 参数的稠密模型，数据量 1.4T Token，使用 H100（FP8 算力约 4000 TFLOPS，BF16 约 2000 TFLOPS）：

总算力 = 6 × 70×10⁹ × 1.4×10¹² = 5.88×10²³ FLOPs

所需 H100·小时 = 5.88×10²³ / (2000×10¹² × 3600 × 0.45 MFU) ≈ 181,481 GPU·小时

若使用 1000 张 H100，需约 181 小时（约 7.5 天）。

3.3 推理算力：比训练更复杂的工程挑战

推理阶段的算力需求与训练有本质区别。训练是离线批量处理，而推理是在线实时服务，受延迟（TTFT，首Token时间）和吞吐量（Tokens/s）双重约束。推理算力需求由以下公式决定：

推理集群总算力需求 = 单请求算力 × 并发请求数 × 平均输出长度
单请求算力 ≈ 2 × N（每输出一个Token）
并发请求数 = 目标QPS × 平均服务时间（含排队等待）

显存需求 = 模型权重 + KV Cache
KV Cache 大小 = 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 精度字节 × 并发数

以 Llama-3-70B 为例，若部署在 A100（80GB）上：

配置项	数值	说明
模型权重（FP16）	140 GB	需 2 张 A100 或量化至 FP8（70GB）
KV Cache（单请求，4K上下文）	约 1.2 GB	80层 × 8头 × 128维 × 2 × 4096 × 2字节
单卡最大并发	约 30 请求	受显存容量限制，而非算力
单Token延迟	约 15 ms	受访存带宽限制（A100 2TB/s）

推理集群的规划核心是“访存带宽”而非“峰值算力”。因为每个Token的权重读取量是固定的（2×N字节），而计算量也是固定的（2×N FLOPs），两者的比值称为算术强度（Arithmetic Intensity），恒等于1 FLOP/Byte。这远低于GPU的平衡点（A100约 200 FLOP/Byte），因此推理是典型的访存密集型任务。

3.4 常见误区与复盘：算力规划的“坑”

误区一：只看峰值算力，忽略MFU。 很多团队按GPU标称算力直接计算训练时间，结果实际耗时是理论值的2～3倍。原因在于：数据加载瓶颈、通信同步开销、算子融合不足、梯度检查点导致的重计算。规划时必须预留 30%～50%的算力冗余。

误区二：推理集群按训练集群的思路配置。 训练需要高算力GPU（如H100），但推理可能更依赖大显存和带宽。例如，使用 A10（24GB，带宽600GB/s）做低并发推理可能比H100更经济。应根据目标延迟和QPS反推所需GPU型号和数量，而不是盲目堆旗舰卡。

误区三：忽略KV Cache的显存爆炸。 长上下文场景下，KV Cache随序列长度线性增长，且随并发数倍增。一个支持 128K 上下文、并发 1000 请求的 70B 模型，KV Cache 可能占用 超过 10TB 显存，远超模型权重本身。必须采用 PagedAttention、KV Cache 量化或 MoE 架构来缓解。

复盘建议：在项目启动前，先完成“算力需求四步估算”：

① 确定模型架构（稠密/MoE）和参数量 N；

② 确定训练数据量 D（遵循 Chinchilla 法则或按业务需求）；

③ 计算总算力 FLOPs，除以 GPU 单卡算力 × 目标 MFU，得到 GPU·小时；

④ 根据时间窗口（如 30 天）反推 GPU 数量，并额外增加 20% 用于实验调参和故障恢复。

推理侧则需单独评估：目标 QPS、平均输入/输出长度、延迟SLA，再结合 KV Cache 显存模型确定部署方案。

算力需求分析不是一次性的静态计算，而是随模型迭代、数据增长、业务峰值动态调整的持续过程。建议建立算力监控仪表盘，实时跟踪 MFU、显存利用率、KV Cache 命中率等关键指标，让每一分算力投入都清晰可量化。