很多人第一次接触大模型，会把「训练」和「推理」混着说：看到租卡报价就问训练多少钱，看到按量计费又以为在训练。结果和同事对不上话，选型、算预算、谈部署全都歪。这篇不堆公式，只把两个阶段的目标、开销来源、硬件偏好和常见误判拆开讲，最后给一张能直接对照的清单和提问顺序，让你在读报价页和部署文档时知道自己在看哪一步。
很多人第一次接触大模型，会把「训练」和「推理」混着说：看到租卡报价就问训练多少钱，看到按量计费又以为在训练。结果和同事对不上话，选型、算预算、谈部署全都歪。这篇不堆公式，只把两个阶段的目标、开销来源、硬件偏好和常见误判拆开讲，最后给一张能直接对照的清单和提问顺序，让你在读报价页和部署文档时知道自己在看哪一步。
先记住一句话：训练是让模型“学”，推理是让模型“用”。学的时候要改模型内部的参数，用的时候参数已经固定，只是拿你的输入去算一个输出。这两个动作在时间尺度、资源消耗和花钱方式上完全是两码事。下面的内容假设你刚入门，没有数学背景也能看懂。
先把两个词摆正：一次「学」和一次「用」
训练的过程，是拿一大堆文本（或其他数据）反复喂给模型，模型每次猜一个结果，然后根据猜错的程度去调整自己内部的数字（参数）。这个过程重复很多轮，最终产出一个权重文件——你可以把它理解成模型的“大脑”。推理则是拿着这个已经固定下来的权重文件，接收你输入的 prompt，算出一个回答。它不再改变权重，只是做计算。
- 训练：目标是从数据里学出参数，产出可复用的权重文件；通常以天或周为单位，一次性重投入。
- 推理：目标是拿已有权重处理你的输入，产出一段回答；每次调用都发生，按次或按量计费。
- 判断你在看哪一步：凡是谈数据集、学习率、epoch、收敛的，都是训练；凡是谈输入输出、延迟、并发、token 的，都是推理。
- 同一个模型，训练和推理用的代码框架、硬件配置、成本结构都不一样，不能直接换算。
各自内部发生了什么：一个在改参数，一个不改参数
训练时，模型对每个输入先做一次前向计算得到预测，然后拿预测和正确答案比，算出误差，再通过反向传播算出每个参数应该往哪个方向调，最后用优化器更新参数。这三个环节都要占用显存。推理只有前向计算，算完就输出结果，不需要存梯度，也不需要优化器状态。所以同一个模型，训练需要的显存远大于推理，具体倍数取决于你用的优化方法、精度和并行策略。
另一个容易踩的坑是量化。推理时可以把权重从高精度压成低精度（比如 8 位或 4 位），模型变小、跑得更快，精度损失通常可接受。训练对数值精度敏感得多，大部分情况下不能用同样的低精度去训。这两件事的取舍标准不一样，别拿推理省显存的经验去套训练。
| 对比项 | 训练 | 推理 |
|---|---|---|
| 是否改参数 | 改，每步都更新 | 不改，权重固定 |
| 显存里存什么 | 权重、梯度、优化器状态、激活值 | 权重、KV 缓存、少量激活 |
| 典型时间尺度 | 小时到周 | 毫秒到秒 |
| 能否用量化 | 通常不能直接用低精度 | 可以，常见 8 位或 4 位 |
| 失败代价 | 高，可能白跑几天 | 低，重试一次请求即可 |
算力与钱花在哪：一笔是一次性投入，一笔是持续流水
训练的成本集中在把模型跑完的那段时间。它受并行策略、卡间通信效率、带宽影响很大，同样的卡数可能因为通信瓶颈差出几倍时间。推理的成本则按请求量线性增长：你调用越多，花得越多。而且推理的响应时间直接和并发数、显存占用相关，不是简单加卡就能解决。
所以问“跑一次多少钱”之前，先确认对方问的是训练还是推理。两者的账单没有可比性。如果你要算具体数字，去站内 /compute/training-cost 和 /compute/finetune 看当前的口径和示例，这里不写死任何金额。
- 训练账单是一次性投入，看的是总卡时和并行效率，不是单次调用价格。
- 推理账单是持续流水，看的是每百万 token 的单价和你的调用量。
- 小团队如果只是调 API 做应用，根本碰不到训练那一层的成本结构。
- 只有当你决定自己改权重（微调或从头训练）时，才需要认真研究训练成本。
硬件偏好不同：训练看互联，推理看显存与吞吐
训练更在意多卡之间的互联带宽和整机稳定性。单卡再强，如果卡间通信慢，整体速度也上不去。推理更在意单卡显存够不够放下权重和 KV 缓存，以及每张卡能同时跑多少并发。显存不够时，推理会直接报错或被迫降低并发，而训练可以通过切分模型来缓解，但通信开销会上升。
对于只想调接口做应用的团队，硬件选择基本是云厂商或中转站的事，你只需要关心接口的延迟和稳定性。只有当你决定自己部署推理服务时，才需要算显存和并发。显卡和加速卡的差别、租卡口径，可以对着站内 /compute/gpus 和 /compute/sizing 逐项核对。
| 场景 | 更该关注 | 可以忽略 |
|---|---|---|
| 调 API 做应用 | 接口延迟、并发限制、计费方式 | 训练卡型号、互联带宽 |
| 自己部署推理 | 显存容量、量化支持、吞吐量 | 训练并行策略、梯度检查点 |
| 微调已有模型 | 微调框架、数据量、显存要求 | 从头训练的收敛曲线 |
| 从头预训练 | 多卡互联、通信效率、训练稳定性 | 推理侧的 KV 缓存优化 |
混淆的四种典型症状，对照看看你中没中
下面这些场景很常见，看看你有没有类似的想法。如果有，说明训练和推理在你脑子里还是糊在一起的。
- 把推理的按 token 单价直接乘出训练预算，得出一个离谱的小数字；或者反过来用训练成本判断调用 API 划不划算。
- 以为“模型已经训练好了”就等于不用再花钱，忽略了部署推理本身的显存和运维开销。
- 看到显存不够就以为要加卡训练，其实只是推理并发开太高、KV 缓存吃满。
- 把微调当成训练的等价物，实际上微调的投入量级和从头训练差着好几个台阶。
这些误判会导致预算算错、选型走偏、跟同事沟通不在一个频道上。纠正的方法很简单：每次讨论前先明确“我们现在说的是训练还是推理”，然后再往下聊。
一张对照清单：下次讨论时按这个顺序问
不管你是在做技术选型、算预算还是和供应商沟通，按下面的顺序提问，基本不会跑偏。每一步都有明确的判断标准，达不到就退回上一步重新想。
- 先问目标是要改模型行为（训练或微调），还是只想让它回答你的问题（推理）？如果只是问答，直接跳到推理路径，不用考虑训练。
- 再问数据有没有标注语料、量级多大？没有数据就别往训练那条路走。微调至少需要几百到几千条高质量样本，从头训练需要的数据量更大。
- 再问预算形态一次性投入还是按量付费？一次性投入看租卡时价和训练时长，按量付费看每百万 token 单价。这两类预算对应不同的比价页面。
- 最后问回退训练失败或效果不达标时怎么退？推理侧则要问限流和降级方案。没有回退方案就贸然开始，风险很高。
- 查当前口径需要具体数字时，去 /compute 看算力总览，去 /official-api 看官方按量价格，去 /price-watch 看价格变动记录。不要在文章或聊天里记死数。
想深一层：去哪查术语、参数和真实数字
训练和推理涉及很多名词，遇到不认识的先查站内词典，别在群里猜。要看训练全流程的分阶段说明，可以参考站内 /training 和已有的训练流程类文章，本篇只做区分，不重复流程细节。算力规格、租用价格、并发估算这些数字随时会变，一律以站内对应页面当时的数字为准。
- 名词不认识：先查 /ai-dict/category/basics 和 /ai-dict/category/tech。
- 训练全流程：参考 /training 的分阶段说明，本篇不展开。
- 算力规格与租用：看 /compute/gpus 和 /compute/sizing，以当时的数字为准。
- 官方接口计费：看 /official-api 的按量价格页。
- 拿不准某说法是否过时：用 /news/daily 扫一眼近期动向再下结论。
最后提醒一点：训练和推理的界限在有些场景下会模糊，比如持续学习或在线学习，模型在推理过程中也会更新参数。但那属于进阶话题，对入门者来说，先把“学”和“用”分开就够用了。
下一步如果你正在选型或算预算，去站内算力总览页看看当前的租卡和 API 计费口径，对照本文的清单走一遍，基本能避免把训练和推理混为一谈。→常见问题
训练和推理可以同时进行吗？
可以，但通常不是同一件事。常见做法是训练侧持续迭代新权重，推理侧用稳定版本对外服务，两边资源分开算。如果硬把两者挤在一张卡上，训练会抢显存和算力，推理延迟会明显抖动，所以生产环境一般会隔离。
只想做个应用，需要懂训练吗？
多数情况下不用。直接调 API 或部署现成权重就够了，你只需要理解推理侧的输入输出、上下文和计费方式。只有当现成模型在你的垂直场景明显不达标、且你有标注数据时，才需要往微调方向考虑。
为什么同一个模型，训练和推理对显存的要求差那么多？
训练除了权重，还要保存梯度、优化器状态和中间激活值，反向传播时这些都得留在显存里；推理只做一次前向，算完即可释放。再加上推理常用量化压缩权重，所以两者对显存的需求不在一个量级。压缩方案看站内量化相关页面。
推理比训练便宜，是不是说明推理不重要？
恰好相反。训练是一次性的，推理是天天在跑的，长期累计开销往往更可观，而且直接决定用户体验。所以做预算时要分开看：训练看一次性投入，推理看单位请求成本和并发上限。
微调算训练还是推理？
算训练，但属于投入小得多的那一种。它复用已有权重、只更新一部分参数，数据和算力需求都远低于从头训练。判断标准很简单：只要过程里在改权重，就是训练侧的事，具体规模差异可对照站内训练与微调相关页面。
