目录

1. 资源估算概述
2. GPU 计算资源
3. 内存与显存
4. 存储资源
5. 网络带宽
6. 资源规划方法
7. 实践建议与最佳实践

摘要

训练一个 7B 模型（1T token）需要约 42 EFLOPs 计算量，128 张 H100 按 40% MFU 估算约 10 天，未分片 BF16 加 AdamW 的核心显存约 112GB。推理侧 INT4 7B 参数仅占 3.5GB，叠加 8 路 8K 上下文的 KV Cache 后单卡 80GB 可支撑约 40 路并发。本文给出训练与推理两套算力、显存、存储与带宽公式，覆盖 NVLink 900GB/s、InfiniBand 400Gbps、数据加载带宽 5MB/s 量级等关键数值，以及容量规划、弹性伸缩与验证方法。

1. 资源估算概述

资源估算回答三个问题：训练任务要多少 GPU 和多少天、推理服务要多少卡才满足并发与延迟、配套的存储与带宽是否构成瓶颈。估算结果直接决定采购预算、云厂商实例选型与交付排期，因此不能停留在"按经验拍一个数"的阶段。本节顺序覆盖估算目标与验收口径、误差来源，以及公式法、基准法与经验外推三种方法及其组合方式。

1.1 估算目标

估算目标分为硬约束与软约束两类。硬约束一旦违反就导致方案不可行，例如训练天数超过交付排期、单机显存放不下模型核心状态、月度推理预算超过财务审批线；软约束只影响体验或成本优化空间，例如 P99 延迟、批处理吞吐。实践中以 7B 模型、1T token 为例，硬约束通常写成"训练不超过 14 天、单 Token 成本不超过 0.0006 美元"，软约束写成"并发 500 时 P99 TTFT 低于 1.5 秒"。

目标必须可度量、可验收，不能写"尽量快"。可度量的口径包括：每 GPU 每秒处理的 token 数（训练与推理通用）、每万 token 的电费与租费、单次全参训练的总 GPU 小时数、推理侧的 TTFT（首 token 延迟）与 ITL（逐 token 间隔）。验收时用同一套指标做基准测试，公式估算是 0 版本，基准测试结果作为 1 版本，两者偏差小于 25% 才视为估算有效。

把目标录入结构化的对象而不是散文，才能在调整参数后自动重算达标状态。下面的代码用 dataclass 定义目标并逐一校验，硬约束不达标直接标记失败。

# 来源：自实现 / estimation_goals.pyfromdataclassesimportdataclass@dataclassclassGoal:name:str# 目标名称metric:str# 指标名target:float# 目标值unit:str# 单位hard:bool=True# 是否硬约束lower_better:bool=True# 是否越小越好defcheck_feasible(goals,achieved):# 每个目标对比实际值，返回是否达标与约束类型results={}forgingoals:value=achieved[g.metric]ok=(value<=g.target)ifg.lower_betterelse(value>=g.target)results[g.name]=(ok,g.hard,value)returnresultsif__name__=="__main__":goals=[Goal("训练时长","天数",14.0,"天"),Goal("单 Token 成本","成本",0.0006,"美元"),Goal("推理吞吐","吞吐",4000.0,"token/s",hard=False,lower_better=False),]achieved={"天数":9.6,"成本":0.0005,"吞吐":5200.0}forname,(ok,hard,value)incheck_feasible(goals,achieved).items():status="达标"ifokelse"未达标"print(f"{name}:{value}{status},{'硬约束'ifhardelse'软约束'}")

1.2 估算挑战

第一类挑战来自硬件标称值与应用层利用率之间的落差。A100 SXM4 的 BF16 稠密峰值是 312 TFLOPS，H100 SXM5 是 989 TFLOPS，但真实训练任务的 MFU（模型浮点利用率）通常在 0.30 到 0.50 之间。MFU 损失来自通信等待、显存带宽受限的算子、负载不均衡与 kernel 启动开销，把 312 TFLOPS 直接当有效算力计算，训练时长会被低估 2 到 3 倍。

第二类挑战是显存峰值的不确定性。显存占用随序列长度、微批大小、激活重计算开关、碎片化程度波动。同一模型在序列 4096、微批 1 时激活可能只占 2GB，序列拉到 8192、微批 8 时激活可膨胀到 20GB 以上；分配器的碎片又额外吃 5% 到 10%。估算时若不区分这些档位，很容易在训练中途触发 OOM。

第三类挑战是负载的时间分布。推理服务的峰值并发往往是均值的三到五倍，训练任务也会因检查点写盘、数据重打乱出现吞吐低谷。估算必须给出区间而不是单点值，并预留余量。对 MFU 做敏感性分析是最廉价的做法，它把"取哪个 MFU"的影响显式暴露出来。

显存峰值还要叠加分配器碎片与通信缓冲。PyTorch 缓存分配器按块预留显存，长时间训练后碎片占比可达 5% 到 10%；NCCL 在每步通信时额外申请缓冲区，8 卡训练时缓冲区可达数百 MB。估算应在核心状态与激活之外再加 10% 的碎片与缓冲系数。

负载的时间分布同样要量化。推理集群的 P99 并发通常是均值的 3 到 5 倍，训练任务在检查点写盘（每 4 小时一次）与数据重打乱期间吞吐下降 20% 到 40%。规划输出必须带上下界，例如 7B 预训练 9.6 天，区间 8 到 12 天，再乘 1.2 到 1.3 的排期系数。

三类挑战相互叠加时误差会放大。MFU 被高估 25% 与碎片系数被忽略，二者合计让训练天数偏差超过 40%，推理卡数偏差超过 50%。因此估算必须显式输出灵敏度区间，而不是单一数字；区间口径记录在假设清单里，复核时逐项核对。

估算的时间粒度也要明确。天数按有效训练小时计，去掉检查点写盘、数据重打乱与故障恢复的停摆；7B 任务若每天停摆 1 小时用于写盘与重启，9.6 天的理论值实际要排到 10.2 天。这个系数写进排期公式，避免把理论天数当交付天数。

硬件标称值本身的差异也要纳入。同一型号 GPU 的峰值算力在 SXM 与 PCIe 版本之间不同，H100 SXM5 989 TFLOPS、H100 PCIe 756 TFLOPS；显存带宽同样有差，H100 SXM5 约 3.35TB/s、PCIe 约 2TB/s。规划时按实际板卡规格取值，不能只写型号。

推理估算的误差来源与训练不同。推理吞吐受批处理策略、KV Cache 管理与量化格式影响，同一模型在 vLLM 与原生实现之间吞吐可差 2 到 3 倍；规划按目标框架版本实测的吞吐为基准，而不是按模型理论值。

估算偏差的容忍度要分级。容量型指标（显存、带宽）偏差容忍 10% 到 15%，超了直接不可行；成本型指标（GPU 小时、天数）容忍 25% 到 30%，超了影响预算但可协商；延迟型指标（TTFT、ITL）按 SLA 单独管，不并入估算容差。

假设清单是挑战管理的关键。每个假设一行：MFU、峰值因子、量化精度、检查点频率、数据副本数；评审时逐项确认，变更时记录变更原因。清单越完整，估算复现性越高，偏差归因越容易。

# 来源：自实现 / mfu_sensitivity.pydeftraining_days(flops_total,gpu_tflops,n_gpus,mfu):# 总计算量除以有效算力，得到秒数再转天数flops_per_second=n_gpus*gpu_tflops*1e12*mfu seconds=flops_total/flops_per_secondreturnseconds/86400.0defschedule_range(days,low_factor=0.85,high_factor=1.25,margin=1.2):# 按敏感性系数给出区间，再乘排期余量lo,hi=days*low_factor,days*high_factorreturn{"区间":(round(lo,1),round(hi,1)),"排期建议":round(hi*margin,1)}if__name__=="__main__":flops_total=42e21# 7B 模型在 1T token 上的总 FLOPsgpu_tflops=989.0# H100 SXM5 BF16 稠密峰值formfuin(0.25,0.30,0.40,0.50):days=training_days(flops_total,gpu_tflops,128,mfu)print(f"MFU{mfu:.2f}-> 128 卡约{days:.1f}天")r=schedule_range(training_days(flops_total,gpu_tflops,128,0.40))print(f"MFU 0.40 区间{r['区间']}天, 排期建议{r['排期建议']}天")

1.3 估算方法

公式法自上而下，核心是训练计算量 C=6ND（N 为参数量，D 为 token 数），再除以 GPU 数量、单卡峰值算力与 MFU 得到天数。它对大模型预训练最可靠，因为主流 transformer 结构都符合 6 倍系数；缺陷是它不感知算子效率差异，对推理场景（前向只算约 2ND）需要单独处理。

基准法自下而上，拿同规模或同架构的公开 benchmark 与自测结果外推。MLPerf Training 给出 GPT-3、BERT 等模型的标准化训练时长，Hugging Face 的 model-memory-usage 工具给出显存占用；缺陷是硬件型号、框架版本与数据分布不同，外推误差可能达到 30%。经验外推法用历史任务的实际 MFU 与吞吐做回归，最贴近本团队环境，但需要积累数据。

三种方法应组合使用：公式法给出理论下限，基准法给出可参考量级，经验外推给出校正系数。最终输出一个区间，例如"7B 预训练 10 天，区间 8 到 12 天"，再用 20% 到 30% 的余量折算成排期。下面的代码把三个来源的估计值合并为中位数与上下限。

估算的不确定性管理：输入参数（请求量、序列长度、并发）各自有波动范围，用敏感性分析确定对结果影响最大的参数。估算结果附带置信区间与参数假设清单，评审时先核对假设再采纳结论。假设不成立的场景重新估算，避免把过期估算当作当前依据。估算文档记录参数来源与更新时间，支持追溯与复核。

估算方法的校验：估算完成后用实际运行数据回测，偏差超过阈值时修正公式或参数。回测记录按项目归档，估算精度随时间与经验积累提升。新场景的估算参考同类历史项目，避免每次从零开始。估算结果的呈现面向不同角色：管理层看区间与余量，工程师看参数与公式，财务看成本折算，三份视图共用同一份底层数据。

估算的迭代节奏：每次项目启动前做一次正式估算，项目过程中根据实际消耗滚动修正。估算修正记录在项目文档中，支持事后复盘"估算偏差来自哪里"。季度汇总所有项目的估算偏差分布，系统性偏差通过调整默认参数修正。估算流程的成熟度评估：从"凭经验拍脑袋"到"公式加基准加外推"再到"全流程自动化估算"，逐级提升可复现性与精度。成熟度提升的收益用估算偏差率衡量，偏差率从 30% 降到 10% 说明估算体系趋于可靠。

估算与决策的衔接：估算结果直接支撑采购、预算与排期决策，估算结论的采纳记录与决策依据一并归档。估算区间而非单点的呈现方式，让决策者明确不确定性边界，避免把估算当承诺。估算结论的版本管理：参数与公式变更生成新版本，旧版本结论标注失效，防止过期估算被误用。估算的参与方：容量工程师负责公式与参数，业务方提供需求输入，财务折算成本，三方共同确认估算结论。

估算的常见陷阱：只算 GPU 不算配套资源、用峰值代替均值、忽略维护窗口与故障预留。三类陷阱都会导致估算偏乐观，实际消耗超支。规避方法：配套资源（存储、网络、人力）单列估算，容量按 P95 负载规划，预留 20% 到 30% 的维护与故障缓冲。陷阱清单写进估算模板，评审时逐项核对。

# 来源：自实现 / estimator_combine.pyimportstatisticsdefformula_estimate():# 自上而下：C=6ND 除以有效算力return{"天数":9.6}defbenchmark_estimate():# 自下而上：同规模基准任务外推，附带波动return{"天数":8.2,"波动":1.1}defcombine(estimates):# 取中位数与 min/max 构成区间，并计算含余量的排期值days=[e["天数"]foreinestimates]median=statistics.median(days)return{"中位数":median,"区间下限":min(days),"区间上限":max(days),"排期建议":median*1.25,}if__name__=="__main__":est=combine([formula_estimate(),benchmark_estimate(),{"天数":10.5}])fork,vinest.items():print(f"{k}:{v:.1f}天")

2. GPU 计算资源

GPU 数量决定训练与推理的核心成本。训练侧先算总计算量，再除以单卡峰值算力与 MFU；推理侧先算单卡吞吐与每请求算力需求，再按峰值并发折算。两者的数量级相差悬殊：7B 预训练要上百张卡跑若干天，同模型推理只需几张卡就能服务数百并发。本节分别给出训练与推理的公式，并按场景给出选型决策路径。