大模型训练和推理的区别

很多人第一次接触算力预算时会卡住：同样是跑一张卡，为什么训练要排队几周、推理却要按每秒多少钱算；同一块显卡训练时显存爆掉，推理时却能塞下更大的模型。这篇不堆公式，只把两个阶段的目标、吃资源的部位、花钱的方式摆在一起对照，再给一份「你现在到底在做哪件事」的判断清单和排查顺序。想拿具体数字，按文里给的站内路径去核对当时的行情即可。

刚接触算力预算的人常会卡在同一个地方：明明都是跑同一张卡，为什么训练要排队等上几周、按整段卡时结算，推理却是按每秒或每百万 token 来报价；更奇怪的是，同一个模型训练时显存爆掉，换成推理居然能塞进去，甚至还能再开几路并发。这不是错觉，也不是服务商在乱报价，而是训练和推理本来就是两件性质不同的活。

这篇不堆公式，只把两个阶段的目标、吃资源的部位、花钱的方式摆在一起对照，再给一份「你现在到底在做哪件事」的判断清单和排查顺序。具体单价、各家卡的报价、模型规模对应的显存数字，文中一律不给死数，需要的时候按文里标注的站内路径去核对当时的行情即可。

先分清目标：一个在改参数，一个在用参数

训练和推理最根本的差别，是模型本身会不会因为你这一次运行而改变。训练跑完一轮，权重是被改写过的，模型比之前更接近目标；推理跑完一次，权重纹丝不动，只是把输入映射成了输出。这一个字的差别，决定了后面所有资源、成本、优化方向的走向。

• 训练的目标是让权重变好：前向算完还要反向传播、算梯度、更新参数，每一轮都在改模型本身
• 推理的目标是让权重干活：只做前向计算，参数冻结不动，输入什么就吐什么
• 所以训练关心收敛没收敛、泛化好不好，推理关心延迟、吞吐、稳定性和单次成本
• 衡量口径也不同：训练看损失曲线和验证集表现，推理看首字延迟、每秒输出和错误率

算力花在哪：训练是长时间满载，推理是持续轻载

训练一般是要连续跑很久的一段活，中途掉卡、断点、节点故障都直接影响进度，所以对集群稳定性和卡间通信带宽要求很高，宁可慢一点也要稳。推理则是长期在线的活，单次请求算得很快，但一天可能来几万次，真正的压力不在算得慢，而在并发上来之后排不排队、顶不顶得住。

一个实用的判断方法：如果你每天打开监控看的是「跑完没有、本轮损失多少」，那你做的是训练；如果你看的是「每秒能出多少字、五个人同时用会不会卡」，那你做的是推理。搞错这一步，后面配卡、选实例、算预算全部会歪。

成本结构不一样：一笔是重投入，一笔是细水长流

训练的钱集中在前期，是一次性的重投入：卡时、集群规模、数据准备、反复试错的轮次，钱花出去换的是一次「训练完成」的结果。推理的钱则摊在每一次调用和每一天的在线时长上，单次看上去很便宜，量堆起来总额往往超出预期。两笔账的算法逻辑完全不同。

训练账

总卡时乘以租赁单价，再乘一个失败重跑系数，系数按你集群稳定性和任务难度估

推理账

日请求量乘以单次平均 token 数乘以单价，再叠加常驻实例的空闲成本

隐藏项

训练的存储、数据搬运、重跑损耗；推理的峰值扩容、冷启动、缓存占用的显存

具体单价和换算方式不要凭记忆背，各家卡的租赁价、各家 API 的每 token 报价一直在动。训练侧的成本测算口径可以到 /compute/training-cost 核对，推理侧的按 token 折算和对比到 /tools/model-cost-calculator 按当时的数字算一遍，比自己拍脑袋准得多。

显存吃法不同：训练吃的是状态，推理吃的是缓存和权重

很多人第一次发现「同一个模型推理能跑、训练就爆显存」，就是没搞清显存里装的东西根本不是一回事。训练时显存里同时装着权重、梯度、优化器状态和一大堆中间激活值，几样加起来往往比权重本身大出好几倍；推理时显存主要装权重和 KV 缓存，权重是死的，缓存则是随上下文长度和并发数往上膨胀。

• 训练侧：权重、梯度、优化器状态、激活值四份同时占，缺一份就跑不动
• 推理侧：权重加上 KV 缓存，上下文越长、并发越高，缓存部分越吃显存
• 所以一张卡能推理的模型，未必能拿来训练；反过来也不成立
• 量化能显著省推理的显存，但对训练帮助有限，别指望用低精度把训练塞进小卡

要不要量化、量化到哪一档、上下文最长放到多少，别凭感觉降档，按 /models/deploy 里的测算口径先算一遍目标显存，再决定实例规格。降档降过头，推理质量掉下来是看不出来的，只会在业务侧表现为回答变差。

对照表：你现在手上这件事属于哪一阶段

分不清训练还是推理，通常是因为任务本身就处在一个中间地带。下面这张对照表按「你在做的事情」来分，不按名词分，对着找一行基本就能定位。定位错了，后面配卡、选框架、算预算全都是无效功。

第三行是最容易花冤枉钱的场景：很多人以为「跑自己的数据」就是训练，于是按训练规模买了一堆卡，结果日常只是在做前向推理，卡的利用率长期很低。第四行则是另一个极端，把微调当纯推理省钱，最后练出来的效果对不上，返工重来反而更贵。

配资源时的检查顺序：先定阶段，再算规模

1. 第一步，定阶段训练、微调还是纯推理，先明确一件事。这一步错了后面全错，别跳过。
2. 第二步，定模型规模和精度原始权重多大、要不要量化、上下文要放到多长，按 /compute/sizing 过一遍，得出显存底线。
3. 第三步，定并发或轮次推理看同时在线人数和平均上下文长度；训练看 batch 大小和总步数，两边估算方式不通用。
4. 第四步，留余量再下单推理留出峰值缓存和扩容空间，训练留出重跑和中断的容错空间，不要按理论最小值买。

这个顺序的关键在于不能反：先买卡再想跑什么，是最常见的浪费，也是后面所有成本失控的源头。如果实在拿不准自己的负载属于哪一类，可以先用 /tools/speed-test 之类的小规模压测跑一遍，看真实的延迟和资源占用落在哪个区间，再回来定规格。

优化方向不同：别拿推理的招去救训练

两个阶段的优化目标压根不一样，用错了地方通常只能省下零头，真正的大头还留在原地。推理优化关心的是单次延迟和并发承载，训练优化关心的是吞吐、稳定性和重跑次数。把推理那套手段套到训练上，多半是白费功夫。

判断要不要优化，看两件事：现在的成本里，卡时/实例费占大头还是周边占大头；现在的瓶颈是算得慢还是排队长。两个都指向同一个方向时再动手，否则优化半天，账单结构一点没变。

新手最容易踩的四个坑

这四个坑几乎是入门从业者按顺序踩过去的，提前知道能省不少返工。它们的共同点是：都是把训练和推理的某一边特征，错误地套到了另一边身上。

• 把推理当训练配卡：按训练峰值买卡，日常利用率很低，钱白花
• 把训练当推理省钱：想用低精度省显存去练模型，练出来的效果对不上
• 只算卡钱不算周边：存储、带宽、电费、故障重跑，训练侧占比不小
• 以为同一套环境两边通用：框架、镜像、并行方式差别不小，迁移成本要提前算进去

排查顺序建议从上往下走：先确认阶段有没有搞错，再看显存和精度假设成不成立，最后才去抠单价和优化。顺序反了，容易在单价上抠半天，回头发现是整个阶段定位错了。想横向比一比各家算力和中转站的实时情况，可以到 /price-watch 看追踪记录，再到 /rankings 看当前的整体排序，不过这些都只作参考，最终还是要落回自己的任务类型上判断。