大模型训练是”从数据中学出参数”，每 token 要做 6-8 次浮点运算且必须留梯度与优化器状态；推理是”用学好的参数生成 token”，每 token 只做 2 次浮点运算、显存里只剩权重与 KV 缓存。两个阶段在算力、显存、通信、延迟四条线上呈数量级差异，工程上常被概括为”训练是马拉松、推理是百米冲刺”。
一、先把”训练”和”推理”定义对齐
工程语境里，”训练（Training）”指让模型权重从零或从预训练 checkpoint 继续更新参数的过程，要跑完前向、反向、优化器三步；”推理（Inference）”指用已固定的权重在输入上做一次前向、吐出 token 的过程，没有反向也没有参数更新。把这两个概念混在一起谈资源，是规划 GPU 预算时常见的源头错误。
“微调（Fine-tuning）”夹在两者之间：仍要反向传播，但只更新 LoRA 之类的小参数或少量层，资源量级比全量训练小 1-2 个数量级，却又比纯推理多一份梯度的开销。谈”训练 vs 推理”的资源差异时，业界默认是”全量预训练”对照”线上推理”两端，微调单独看待。
二、算力消耗：一个差到 4-6 个数量级
算力差异是四个维度里最直观的。工程口径上，每个参数每 token 的浮点运算次数，训练是 6-8 次（前向 1 + 反向 2，再加优化器里若干矩阵乘），推理只有 2 次（仅前向的一次乘加）。再把”训练 token 数”与”推理 token 数”的差距叠上去，整段训练的累计 FLOPs 通常比单次推理高出 4-6 个数量级。
| 维度 | 训练 | 推理 |
|---|---|---|
| 每 token 浮点运算 | 6-8 次/参数 | 2 次/参数 |
| 累计数据量 | 万亿级 token | 一次请求数百到数千 token |
| 优化目标 | 吞吐（tokens/s）最大化 | 延迟（首 token / 单 token）最小化 |
| 典型耗时 | 数周至数月 | 毫秒到秒级 |
| 算力取向 | 训练侧计算密集，通信同样关键 | 推理侧单请求带宽敏感，编码端计算密集 |
落到具体硬件，千亿参数级别的训练需要千卡级 GPU 集群、NVLink/InfiniBand 互联，显存总和动辄 TB 级；同尺寸模型的推理在量化加持下，单卡或 8 卡服务器就能撑住高并发，这也是大模型能”飞入寻常百姓家”的硬件基础。
三、显存构成：训练是”权重+梯度+优化器+激活”的四件套
显存是规划预算时最容易踩坑的项。训练显存可以拆成五块：模型权重、梯度、优化器状态、激活值、KV 缓存；推理显存只剩三块：模型权重、激活值、KV 缓存。粗略公式如下。
| 显存组成 | 训练公式 | 推理公式 |
|---|---|---|
| 主体 | 权重 + 梯度 + 优化器 + 激活 | 权重 + 激活（量级远小于训练） |
| 7B FP16 经验值 | 训练仅模型状态约 112 GB | 推理约 14 GB 权重 + 2 GB KV |
| 70B FP16 经验值 | 多卡 + ZeRO/张量并行才能跑 | 130 GB+；INT4 量化后 35 GB+ |
| KV 缓存占比 | 训练期间较小 | 长上下文+高并发时成为主项 |
激活值是训练独有的大头：前向算完后，每一层的中间输出要一直留在显存里等反向传播用。工程上常用”激活重计算（activation checkpointing）”换空间——把若干层的激活丢掉，反向时再算一次，省下来的显存可达 30%-50%。推理时只需保留极少数张量，激活开销通常不到权重的 20%。
KV 缓存只在自回归解码时显著增长，按”并发数 × 序列长度”线性放大。短上下文时权重占大头，长上下文加高并发时 KV 反超权重，成为显存的真正瓶颈。
四、通信与硬件选型：训练卡互联，推理卡拼带宽
训练对节点间带宽的依赖是硬性的。千亿参数做一次 AllReduce，每秒要搬运的梯度数据可达 TB 量级，没有 NVLink、InfiniBand 或 RoCE 这类高速互联，训练会被通信拖垮。机内带宽从早期 400 Gbps 一路涨到最新一代多 Tbps 量级，正是被大模型训练”挤”出来的需求。
推理则把优化点放在单卡带宽上。自回归解码时每生成一个 token 都要把整层权重扫一遍，瓶颈是 HBM 带宽而不是峰值算力。Blackwell B200 这类新一代卡把 HBM 容量推到 144 GB 以上，正是为了在大模型 + 长上下文场景下减少切分、提升并发。
工程上，硬件选型有一条经验对照：
- 千亿参数预训练，优先 H100/H200/B200 这类数据中心级卡，配套 NVLink + InfiniBand；
- 70B-130B 推理，按并发量选 48 GB 工作站卡或 80-144 GB 数据中心卡；INT4 量化后单卡可起步；
- 7B-13B 推理与 LoRA/QLoRA 微调，24-32 GB 消费级 GPU 即可，量化后甚至能进 16 GB；
- CPU 与存储别拖后腿：CPU 负责数据预处理与动态批处理，PCIe 4/5 直连 ≥ ×16，避免 GPU”等数据”。
五、落地时的三个易错点
冷启动击穿：训练重启时激活缓存是空的，第一批大 batch 容易 OOM，工程上用渐进式 batch 预热。推理的”冷启动”则表现为 KV 缓存为空时首 token 延迟高，需要预热 prompt 或复用 prefix-KV。
精度选错：训练用 FP16/BF16 起步，FP32 仅在优化器主副本上保留；推理常用 INT8/INT4 量化，量化等级与业务对生成质量的下限直接挂钩，不能只看显存省了多少。
并发盲区：只盯着”权重能不能塞进卡”而忽略 KV 缓存，是推理扩容最常见的翻车点。算清楚”单请求 KV 大小 × 目标并发”再下单，是把推理服务从”能跑”推到”能扛”的关键。
六、把资源差异落到一行代码上
下面这段伪代码演示一个训练 step 与一次推理 forward 的差异：训练 step 比推理 forward 多走 backward 与 optimizer 两步，显存里也多出 grads 与 optimizer_state 两个对象。
# 训练 step
optimizer.zero_grad()
logits = model(input_ids, labels=input_ids) # 前向
loss = logits.loss
loss.backward() # 反向，占显存大头
optimizer.step() # 更新参数
# 推理 forward（自回归生成）
past_kv = None
next_token = None
for _ in range(max_new_tokens):
out = model(next_token, past_key_values=past_kv, use_cache=True)
past_kv = out.past_key_values # KV 缓存累积
next_token = sample(out.logits[:, -1])训练 loop 在 backward 后立即释放激活，optimizer 更新完就清梯度；推理则把 past_kv 一直带在身上，每生成一个 token 就多一份缓存。”训练/推理资源差异”在这两段代码里最直观。
常见问题（FAQ）
Q1：训练和推理可以共用同一台机器吗？
可以用，但要把 batch、显存上限、CPU 负载分开调度，否则训练 OOM 会把在线推理拖垮。
Q2：为什么推理要单独算 KV 缓存？
自回归生成每一步都要复用前面所有 token 的 K/V，不缓存就每次重算，时延会到秒级。
Q3：量化对训练和推理都有效吗？
INT8/INT4 主要加速推理与微调，训练一般只到 FP16/BF16，再低会破坏收敛。
