第 13 章：成本/时长粗估（¥）与 TCO

开篇段落

本章的目标不是提供一份精确到分的财务报告，而是为 AI Scientist 建立一个可复用、可推理的成本估算框架。在大型语言模型的研发竞赛中，计算资源如同燃料，而精确估算燃料消耗的能力，是区分业余爱好者和专业团队的核心技能之一。理解训练一个 LLM 的资源消耗，不仅关乎项目规划和预算申请，更直接影响技术路线选择（如模型规模、数据量）、资源获取策略（云 vs. 自建、按需 vs. 竞价）乃至研究方向的可行性判断。本章将深入剖析从零预训练一个 1T token 规模 LLM 所涉及的全部主要成本构成，并提供一个基于我们假设硬件（64x H100 80GB）的高度可定制化的估算表格。学完本章，你将能够：

1. 精通计算量估算：从模型参数和训练数据量，精确推算理论计算量（FLOPs），并理解其构成。
2. 洞悉性能瓶颈：掌握 MFU（模型浮点利用率）和 tokens/s 两个核心指标，理解它们如何将理论计算量转化为实际训练时长，并知道影响它们的关键因素。
3. 全面理解 TCO：不仅能计算 GPU 和电力成本，还能系统性地分析云计算（OpEx）与自建机房（CapEx + OpEx）在总拥有成本（TCO）上的复杂权衡。
4. 规避估算陷阱：利用提供的估算模板和“常见陷阱”清单，为你的项目进行稳健的“信封背面计算”，并向管理层清晰地阐述资源需求的依据。

文字论述

训练 LLM 的成本结构可以被视为一个金字塔。塔基是理论计算量，中间是硬件效率和时长，塔尖是最终的财务成本。我们将逐层向上解析。

1. 塔基：理计算量（FLOPs）的精确估算

一切估算的起点，是确定完成训练任务需要多少次浮点运算。对于 Decoder-only 的 Transformer 模型，业界公认的黄金法则是：

$$ \text{FLOPs}_{\text{train}} \approx 6 \cdot N_{\text{params}} \cdot T_{\text{tokens}} $$

这个公式简洁而强大，但理解其背后的构成至关重要：

• $N_{\text{params}}$: 模型的非嵌入参数量。为什么是非嵌入？因为词嵌入矩阵的计算量与词表大小 V 和序列长度 L 相关，而不是总参数量 N。对于大型模型（N > 1B, V ~ 50k），绝大部分参数和计算量集中在 Transformer Block 的 nn.Linear 层中，因此这个简化是成立的。
• $T_{\text{tokens}}$: 训练语料库的总 token 数量，是我们的目标工作量。
• 系数 6 的由来:
  • 前向传播 (Forward Pass): 对于每个 token，其通过模型时经历的矩阵乘法（nn.Linear）计算量总和约等于 $2 \cdot N_{\text{params}}$ FLOPs。(一个 A @ B 的矩阵乘法，A 是 m*k，B 是 k*n，需要 2*m*k*n FLOPs。Transformer 中线性层的权重总和构成了 $N_{\text{params}}$)。
  • 反向传播 (Backward Pass): 根据链式法则，计算梯度所需的计算量大约是前向传播的 2 倍，即 $4 \cdot N_{\text{params}}$ FLOPs。
  • 两者相加：$2 \cdot N_{\text{params}} + 4 \cdot N_{\text{params}} = 6 \cdot N_{\text{params}}$ FLOPs per token。

公式忽略了什么？ 该公式主要捕获了 nn.Linear 层的计算量，而忽略了如 Self-Attention 中的矩阵乘法（Query-Key-Value）、LayerNorm/RMSNorm、激活函数和 Softmax 等。然而，对于 LLaMA 这类数十亿参数的模型，线性层的计算量占比超过 99%，因此这个公式的误差极小，完全适用于宏观估算。

2. 中坚：从理论到现实（MFU 与 Tokens/Second）

拥有了理论计算量 FLOPs，我们如何将其转化为墙上时间（Wall Clock Time）？这需要引入硬件效率度量。

$$ \text{Time (seconds)} = \frac{\text{FLOPs}_{\text{train}}}{\text{Effective Cluster Performance (FLOPs/s)}} $$

其中，Effective Cluster Performance = (#GPUs) * HFLOPs_per_GPU * MFU。

• $\text{#GPUs}$: GPU 数量，本教程中为 64。
• $\text{HFLOPs}_{\text{per_GPU}}$: 单块 GPU 的理论峰值性能。H100 80GB SXM 在 BF16/FP16 Tensor Core 上的理论峰值约为 2000 TFLOPs（$2 \times 10^{15}$ FLOPs/s）。注意：这是稀疏化（Sparsity）关闭时的性能，实际训练中我们通常使用这个数值。
• MFU (Model FLOPs Utilization): 模型浮点利用率，这是连接理论与现实的桥梁。它衡量了你的训练任务在多大程度上压榨出了硬件的理论性能。MFU 永远小于 100%，其限制因素包括：
  • 内存带宽墙: GPU 核心计算速度远超于从 HBM（高带宽内存）中存取数据的速度。对于 FlashAttention 这类访存密集型算子，性能瓶颈在内存而非计算。
  • 通信销: 在分布式训练中，梯度同步（All-Reduce）需要通过 NVLink/NVSwitch 和 InfiniBand 进行大量数据交换。网络带宽和拓扑结构直接影响通信效率，这部分时间 GPU 核心可能在等待。
  • 软件开销: CUDA kernel launch 的延迟、Python 解释器的开销、数据加载 pipeline 的不畅，都会让 GPU 产生微小的空闲，累积起来影响巨大。
  • 并行策略的“气泡” (Bubble): 流水线并行（Pipeline Parallelism）中，不同阶段之间不可避免地存在等待时间，即“气泡”，降低了总体利用率。

Rule-of-thumb for MFU on H100 Clusters:

• 低于 30%: 可能存在严重的瓶颈，如数据加载缓慢、通信效率低下或实现代码有待优化。
• 30% - 50%: 一个健康且经过良好优化的区间。使用 FlashAttention v2、fused kernels 和优化的通信库（NCCL）是达到这个区间的关键。
• 高于 50%: 极为出色，通常只在超大模型、超长序列或特定优化下才能达到。

实践中的核心指标：Tokens per Second

对于算法工程师而言，MFU 略显抽象。我们更关心一个直接可观测的指标：吞吐量。

$$ \text{Time (seconds)} = \frac{T_{\text{tokens}}}{\text{Tokens}_{\text{per_second_total}}} $$

这个指标非常直观：用总任务量除以每秒完成的任务量。我们可以进一步将 MFU 和 tokens/s 关联起来：

$$ \text{Achieved TFLOPs/GPU} = \frac{6 \cdot N_{\text{params}} \cdot \text{Tokens}_{\text{per_second_per_GPU}}}{10^{12}} $$ $$ \text{MFU} = \frac{\text{Achieved TFLOPs/GPU}}{\text{Peak TFLOPs/GPU}} $$

影响 tokens/s 的因素：

• 模型大小：模型越大，计算越密集，tokens/s 越低。
• 序列长度：序列越长，Attention 计算量呈平方级增长，但由于计算强度增加，MFU 通常会提高，而 tokens/s 会下降。
• 并行策略：Tensor Parallelism 会引入额外的通信开销，可能降低 tokens/s。
• 软件栈：是否使用 FlashAttention v2、fused RMSNorm/SwiGLU 等，对 tokens/s 有决定性影响。

3. 塔尖：财务成本分析 (TCO)

现在我们可以将时间换算成金钱。成本模型主要分为两种：

A. 云计算 (OpEx - 运营支出模型)

云计算的模式是“即用即付”，财务模型简单直接。

$$ ¥_{\text{gpu_cloud}} = (\text{Total GPU Hours}) \cdot (¥/\text{GPU} \cdot \text{h}) $$

• Total GPU Hours = (#GPUs) * Time(hours)
• ¥/GPU·h: 云厂商单价。这并非一个固定值：
  • 按需实例 (On-Demand): 价格最高，灵活性最好。国内 H100 价格约 ¥20 - ¥30 / GPU·h。
  • 预留实例 (Reserved): 长期（1-3年）承诺使用，可获得显著折扣（40%-60% off）。
  • 竞价/抢占式实例 (Spot/Preemptible): 价格最低，可能是按需的 1-3 折。但实例可能随时被云厂商收回，需要极强的断点续训和容错机制。对于长达数月的预训练务，完全依赖竞价实例风险极高。

云的隐形成本:

• 数据存储: 1T token 的数据集（约 2TB）和大量的模型检查点（一个 13B 模型的完整检查点可达 200-300GB）会产生持续的存储费用。
• 网络流量: 尤其是数据传出（Egress）云的费用非常昂贵。训练过程中的跨区数据同步或日志传输也可能产生费用。
• 高附加值服务: 日志、监控、容器管理等平台服务也可能收费。

B. 自建机房 (CapEx + OpEx 模型)

自建机房需要巨大的前期资本投入（Capital Expenditure），并伴随着持续的运营支出（Operating Expenditure）。

TCO (总拥有成本) 公式: $$ \text{TCO}_{\text{on-prem}} = \text{CapEx}_{\text{amortized}} + \text{OpEx} $$

• CapEx (资本支出):

  • 计算服务器: 8x H100 SXM 服务器（如 DGX H100）是核心，价格在 ¥2,500,000 - ¥3,500,000。64 卡集群需要 8 台。
  • 网络设备: 高速 InfiniBand/RoCE 交换机（如 NVIDIA Quantum-2），是保证集群扩展效率的关键，成本可达服务器总成本的 15%-25%。
  • 存储系统: 高性能并行文件系统（如 CPFS），满足海量数据和检查点的读写需求。
  • 数据中心基础设施: 机柜、PDU、冷却系统。

  摊销 (Amortization): CapEx 通常按 3-5 年进行摊销。例如，一台 ¥320 万的服务器按 3 年摊销，每小时的硬件成本约为 3,200,000 / (3 * 365 * 24) ≈ ¥122/小时，即 ¥15.25 / GPU·h。

• OpEx (运营支出):

  • 电力成本: 这是最大的运营支出项，计算公式如下： $$ ¥_{\text{power}} = (\text{#GPUs} \cdot \text{Power}_{\text{per_GPU}}) \cdot \text{PUE} \cdot \text{Time (hours)} \cdot (¥/\text{kWh}) $$

    • $\text{Power}_{\text{per_GPU}}$: H100 SXM 满载功耗约 700W，我们按 0.7 kW 估算。
    • PUE: 现代化绿色数据中心 PUE 可达 1.2，传统数据中心可能高达 1.8。这意味着每 1kW 用于计算的电，就有 0.8kW 用于制冷等。
    • ¥/kWh: 中国工业用电价格区间为 ¥0.8 - ¥1.2。
      • 数据中心托管费: 如果是租赁机位，会产生机柜空间和带宽费用。
      • 运维人力: 需要专业的 SRE/DevOps 团队来维护集群的稳定运行，这是巨大的隐性成本。
      • 软硬件维保: 服务器和交换机的维保合同。

对比：云 vs. 自建 | 特性 | 云计算 (Cloud) | 自建机房 (On-Premise) |

4. 高级估算模板：综合实战演练

下表在一个更详细的框架下，对 1T token 训练任务进行估算。

核心假设:

• 训练数据量 $T_{\text{tokens}}$ = 1T ($10^{12}$)
• 硬件 = 64 × H100 80GB SXM
• MFU 假设 = 40% (这是一个经过良好优化的目标)
• H100 理论峰值 = 2000 TFLOPs (BF16)
• 云成本: ¥25/GPU·h (按需), ¥10/GPU·h (长期合约/混合竞价)
• 自建成本: ¥15/GPU·h (3年摊销), PUE=1.4, 电价=¥1.0/kWh
• R&D 开销系数: 1.2x (计入 20% 的调试、实验和失败重试成本)

| 指标/成本项 | 3B (N=3e9) | 7B (N=7e9) | 13B (N=13e9) | 公式 / 说明 |

这个更详细的表格揭示了：

• MFU 是关键：如果你的 MFU 只有 20%，所有的时间和成本都会翻倍。
• 规模的非线性成本：从 7B 到 13B，参数量增加不到 2 倍，但成本和时间也几乎翻倍，这给模型选型带来了巨大的经济压力。
• 云与自建的抉择：对于一次性的 13B 模型训练，自建的前期投入远超云成本。但如果计划每年进行 3-4 次这样的训练，自建的 TCO 优势将迅速显现。

本章小结

本章我们构建了一个从理论到实践，再到财务的 LLM 训练成本估算全流程。

1. 估算起点是理论计算量：
   • 黄金公式：$\text{FLOPs}_{\text{train}} \approx 6 \cdot N_{\text{params}} \cdot T_{\text{tokens}}$ 是所有估算的基石。
2. 效率是连接现实的桥梁：
   • MFU 是衡量集群计算效率的根本指标，受限于内存、网络和软件栈。在 H100 上，30%-50% 是一个健康的优化目标。
   • Tokens/second 是算法工程师最应关注的实测指标，它直接决定了训练时长。
3. 成本模型决定资源策略：
   • 云提供极高的灵活性和低启动成本，但长期单位成本高昂，适合敏捷研发和需求不确定的场景。
   • 自建需要巨大的资本投入和专业运维，但能实现最低的长期单位成本，适合拥有明确、持续大规模训练需求的核心团队。
4. 估算必须考虑冗余：
   • 永远不要只计算理想情况下的“一趟过”成本。引入 R&D 开销系数（如 1.2x - 1.5x）来覆盖调试、实验和失败重试，会让你的预算更加切合实际。

常见陷阱与错误 (Gotchas)

1. MFU 理想化谬误：直接用硬件理论峰值 TFLOPs 进行计算，是新手最常犯的错误。这会导致对训练时长的预估极度乐观（通常是实际时间的 1/3 到 1/2），造成项目延期和预算超支。永远要基于一个保守而现实的 MFU（如 30%）开始估算。
2. 忽略 R&D 开销系数：成功的训练背后是无数次失败的尝试。将总成本乘以一个 1.2x 到 1.5x 的系数，用以覆盖调参、解决 bug、硬件故障重启等不可避免的开销。一个“跑通”的配置，背后可能消耗了数倍于单次成功运行的资源。
3. 检查点 I/O 梦魇：对于 13B+ 模型，一个包含优化器状态的完整检查点大小可达数百 GB。在 64 个节点上同时将其写入共享存储（如 CPFS），可能造成严重的 I/O 瓶颈，使训练暂停数分钟甚至更久。这会显著降低有效 tokens/s，延长总体时间。估算时需要考虑或实测检查点保存的开销。
4. 竞价实例的惑陷阱：云的竞价实例价格极具诱惑力，但其“随时被抢占”的特性对于长周期训练是致命的。频繁的抢占不仅会丢失最近一次 checkpoint 到抢占时刻之间的训练进度，还可能因为集群状态不一致导致恢复失败。除非有极其鲁棒的自动化容错和恢复系统，否则应谨慎使用。
5. 自建成本的“冰山之下”：在计算自建成本时，只考虑服务器硬件的摊销是严重低估。电力、制冷、数据中心托管、高速网络、专业运维团队的薪资，这些 OpEx 才是冰山下的主体。一个完整的 TCO 分析必须包含所有这些要素。
6. 上下文长度的诅咒：从 4k 上下文切换到 8k，虽然理论 FLOPs 不变，但由于 Attention 矩阵变大，对 HBM 带宽和计算模式的压力剧增，通常会导致 tokens/s 显著下降（可能下降 20%-40%）。在估算时，必须使用与目标上下文长度匹配的吞吐量数据。