大模型训练三阶段 预训练-微调-推理

很多人第一次接触大模型，会把「训练」当成一件事：以为模型是喂一堆资料就长出来的。真到要落地时才发现，预训练、微调、推理是三件成本量级完全不同的事，混着谈就容易高估自己要做的事、也容易低估预算。这篇按分工顺序拆开讲，给一套判断流程：你的需求落在哪一阶段，需要准备什么，哪些情况其实根本不用训练。具体价格与规格去站内对应页面核对当时的数字。

很多人第一次接触大模型，会把「训练」当成一件事：以为模型是喂一堆资料就长出来的。真到要落地时才发现，预训练、微调、推理是三件成本量级完全不同的事，混着谈就容易高估自己要做的事、也容易低估预算。这篇按分工顺序拆开讲，给一套判断流程：你的需求落在哪一阶段，需要准备什么，哪些情况其实根本不用训练。

下面每节都配了判断标准和可执行动作，不是纯概念。具体价格与规格去站内对应页面核对当时的数字，这里不写死任何数值。

先看全局：三个阶段各干什么活

把三个阶段想成一条流水线：预训练是造机器，微调是调机器，推理是开机器干活。预训练负责把海量语料压成基础能力，产出的是基座权重，决定模型的下限和知识面；微调在基座之上用少量领域数据调整行为，改的是说话方式、格式服从和任务适配；推理是把训好的权重拿来跑请求，只做前向计算，不改权重，是唯一能按次计费的一环。

• 判断口诀：想让模型「会新东西」多半靠检索或再训练，想让它「按你的方式说话」才是微调的活。
• 预训练产出的是基座权重，决定知识面和能力下限，但不会天然适配你的业务口吻。
• 微调改的是行为和格式，不会凭空补上你语料里没有的事实。
• 推理不改权重，只负责把已有能力兑现成响应，是唯一按次计费的一环。

预训练：门槛在哪，个人基本别碰

成本主要来自数据清洗、长时间占用大量加速卡、以及反复试错，量级远超一般人预期。产出一个能用的基座不是一次跑完，中间要过数据配比、稳定性、评测多道关，失败重来很常见。所以先想清楚：你是要造一个新基座，还是只想把某类业务问题答好。

判断标准与不适用场景

• 如果你的目标是「某类业务问题答得好」，从零预训练几乎肯定是绕远路，优先看检索和微调。
• 如果你的目标是「拥有一个别人没有的基座能力」，才需要认真评估预训练，且要有长期算力和团队准备。
• 什么情况下不适用：数据量、算力预算、评测体系任一项明显不足时，预训练都不该进入候选清单。
• 要看规模量级就去站内训练成本与算力总览页面对照当时的口径，别用别人的旧数字套自己。

微调：它到底改什么，什么时候值得做

微调最擅长的是稳定输出格式、固定口吻、把任务收敛到窄领域，不擅长灌入大量事实性知识。先问自己三件事：提示词能不能解决、检索能不能解决、只有都不行且样本够多再考虑微调。数据质量比数量重要，标注口径不一致会让模型学到矛盾行为，效果反而不如基座加好提示词。

1. 写清要改的行为把「希望模型怎么说话、输出什么格式」写成可检查的条目，而不是笼统说效果不好。
2. 先试提示词与检索用同一批真实问题跑提示词方案和检索方案，看是否已能满足，能就停在这一步。
3. 准备一致性样本确认要微调后，先统一标注口径，样本宁少而精，避免互相矛盾的教学信号。
4. 回归对照再上线微调后模型在其他通用任务上的表现可能下降，上线前要用原任务集做回归对照，确认没有明显退化。

推理：真正天天在花钱的那一环

推理只做前向计算，延迟和吞吐受显存带宽、量化档位、批大小影响，跟训练是两套优化思路。同一份权重，量化后显存占用下降但可能损失精度，选档位要结合任务对错误的容忍度。推理成本按 token 或时长结算，具体单价与计费口径到站内官方 API 价格页和比价页面看当下数字。

量化

把权重精度压低以省显存和加快推理，代价是可能损失精度，需按任务容忍度选档。

吞吐

单位时间能处理多少请求，和批大小、硬件配置相关，直接影响单位成本。

延迟

单次请求从发出到收到回复的时间，与吞吐往往需要权衡。

按次计费

推理是唯一按量或按时结算的环节，训练通常是前置一次性投入。

• 先测延迟再看吞吐：交互类场景延迟优先，批量离线任务吞吐优先，两者优化方向不同。
• 量化档位不是越低越好，错误容忍度低的场景宁可选保守档位。
• 什么时候不用想这一层：如果你只是偶尔手动问几句，用现成接口就行，不必自己搭推理服务。
• 要比较各家接口的计费口径，去站内价格追踪与比价页面核对当时的数字，别凭印象判断。

落到自己身上：三步判断该走哪条路

把前面三节收敛成一个可执行流程。第一步写清问题：是缺知识、缺格式服从，还是缺稳定响应，三类问题对应不同解法。第二步算账：把「提示词加检索」「微调」「从零训练」三条路的人力、数据、算力各估一遍再比。第三步小规模验证：先用几十到几百条真实样本试，效果不行就别急着放大投入。

1. 写清问题归类把需求归到缺知识、缺格式、缺稳定响应三类之一，归类不清就先做一轮需求梳理。
2. 三路并行估算对提示词加检索、微调、从零训练各自估人力、数据、算力，形成可对比的清单。
3. 小样本验证用真实样本跑一轮，记录通过率和失败模式，再决定是否放大。
4. 确认部署约束合规要求数据不出内网时，路线选择会被部署方式限制，得先把这条约束确定下来再选路。

注意不适用的场景：如果合规要求数据不出内网，能选的路线会大幅收窄，这时不是先比效果，而是先确定部署方式，再在允许的范围内做选择。具体能选哪些方案，到站内中转站导航与工具目录页面看当下的收录情况。

先把问题归类，再选阶段；大多数团队真正的答案停在推理和检索这一层，而不是训练。