预训练大模型和微调大模型常见问题，怎么做和怎么选

很多人一说「训练模型」就想到买卡、凑语料，结果花完钱才发现自己真正需要的只是一次小规模微调。这篇不铺概念，直接按「你到底卡在哪一步」来分：先判断该不该碰预训练，再判断微调是不是最优解，最后给数据、算力、验收三张可落地的清单。

很多人一说「训练模型」就想到买卡、凑语料，结果钱花完了才发现，自己真正需要的只是一次小规模微调。这篇不铺概念，按「你到底卡在哪一步」来分：先判断该不该碰预训练，再判断微调是不是最优解，最后给数据、算力、验收三张能直接照着做的清单。

读之前先记住一个前提：预训练和微调不是先进与落后的关系，而是两种成本结构完全不同的手段。选错的代价不在训练那几天，而在后面几个月的推理账单和一直追不上的效果。下面每一节都配了判断标准和不适用的场景，照着对号入座就行。

先把两个词的范围划清楚

预训练是从随机初始化开始，用海量通用语料学语言与世界的规律，产出的是底座，不是成品；微调是在已有权重上继续训练，用相对少量的领域数据改行为习惯，产出的是针对某类任务的版本。两者最直观的区别是：前者决定模型「会不会说话」，后者决定「说话方式对不对」。

最常见的误判，是把「让模型懂我的业务」直接等同于「要预训练一个自己的模型」。实际上大多数业务诉求落在输出格式、分类口径、语气风格上，这些恰恰是微调的主场。先问自己一句：我要改的是语言能力本身，还是表达习惯？答案基本就定了。

• 改的是「模型压根不认识这门语言或这个模态」——才轮到预训练
• 改的是「模型懂，但答得不符合我们的规范和格式」——微调
• 改的是「模型不知道最新的事实」——优先检索增强，不是训练
• 改的是「偶尔答得不够好，想整体提升」——先做数据清洗和提示词，别急着训练

什么情况下才轮到预训练

判断标准只有一条硬杠：现有开源或商用底座在你的核心语言、核心模态上明显不达标，并且这个缺口无法靠补充数据、调整提示或后处理补齐。达不到这条，预训练几乎一定是亏的。语种通用、任务常见的团队，直接排除这个选项。

另外要有稳定可持续的语料来源和清洗能力。预训练不是一次性采购，语料断供、清洗标准摇摆的项目基本会烂尾。动手前先到 /models 看有没有同语种、同模态的开源权重可以作为起点，能省掉绝大部分成本。

1. 确认缺口真实存在用现有底座在目标语言或模态上跑一批真实请求，把答不了的样本收集起来。如果失败样本集中在格式和口径，说明不是底座能力问题。
2. 确认缺口无法靠数据补齐把失败样本加入微调集或检索库再测一轮，效果明显回升就停下，不要往预训练走。
3. 确认语料可持续列出未来半年到一年的语料来源、更新频率、授权状态，任何一项拿不出来就先搁置。
4. 找可复用的起点到 /models 核对同语种同模态的已有权重，能继续预训练就不要从零开始。

微调不是万能的：先排除三条更便宜的路

在排训练预算之前，先把这三条更便宜的路走一遍。走完还在，再谈微调。顺序别反，反了就是拿训练成本去解决本该用工程手段解决的问题。

特别提醒一条：千万别用微调去塞事实。模型会把事实记歪，而且难以纠错——你没法像改检索库那样精确地删掉一条错误记忆。幻觉问题指望微调解决，通常只是把幻觉换了个方向。

数据这一关：常见问题和核对清单

微调的数据量看任务复杂度，不看模型大小。格式统一的分类任务往往比想象中需要的少，而开放式生成任务对样本多样性的要求高得多。别照搬别人说的「至少要多少条」，那是别人的任务，不是你的。

最容易被忽略的是验证集。必须留出与训练集不重叠的验证集，同一来源切分是效果虚高的头号原因——同一份文档切出来的问答对，训练和验证各放一半，指标当然好看。预训练语料则要提前确认授权与来源合规，到 /safety 核对当时的合规口径。

• 训练集与验证集按来源切分，不是随机打散同一批样本
• 去重：重复样本会让模型过度记住某几句话
• 检查模板化问答，千篇一律的句式学不到真实分布
• 标注规范先写下来再标，边标边改口径等于白标
• 留一小批「刁钻样本」单独存放，专门用来测边界
• 预训练语料逐批记录来源与授权状态，便于后续追溯

算力怎么估，别一上来就问「要几张卡」

「要几张卡」这个问题本身就没法回答，因为缺了四个量：参数规模、精度、批大小、序列长度。四个量对齐了才有估算的意义，然后到 /models/deploy 套当时的测算口径，比在群里问人靠谱。

微调优先用参数高效方法，全参微调的显存和卡数往往差一个量级。预训练的成本按 token 量乘以每 token 算力来估，算力单价与租金口径到 /compute/training 核对当时的数字——这类数字变动快，本文不写死，以页面为准。

1. 先定四个量参数规模、训练精度、批大小、序列长度写在一张纸上，缺一项就不要开始问价。
2. 选训练方式能参数高效就不全参，先算显存占用再决定卡型，别反过来。
3. 跑小规模实验只想验证可行性时，先租短期卡跑通全流程，确认数据管线和评测都正常。
4. 按最终规模复算实验跑通后再按目标规模复算一次，把推理侧成本一起算进去。

不适用的情况也说清楚：如果这一轮只是为了验证「微调有没有用」，那就不要按最终规模一次性下单，短租加小样本足够给出结论。

怎么判断这一轮训练值不值

固定一套评测集，训练前后跑同一套题，别只看 loss 曲线。loss 降了但业务题答歪，是最常见的假成功。同时要看两件事：目标能力有没有涨，通用能力有没有明显回退——微调过度会让模型变窄，原本会的现在不会了。

• 训练前后用同一套固定评测题，题目不许临时更换
• 分能力维度看结果，不要只报一个总分
• 单独测通用能力回退，回退明显就减训练强度
• 上线前抽样真实请求人工复核，benchmark 涨了线上答歪的情况很常见
• 权重版本、推理配置都要能一键切回，回退方案先于上线准备好

验收不只是「这次训练好不好」，还包括「下次还要不要训」。把每轮的评测结果、数据版本、配置记录下来，下次出问题才有得对比。

一张对照表落地选择

把前面的判断压成一张表，逐行对号入座。注意这是起点判断，不是终局结论——真正动手前，每一项都建议用一小批真实请求验证一次。

补充一句：表格里的判断会随底座能力变化而失效。半年前需要预训练才能解决的语种问题，现在可能已有现成权重。动手前到 /models 和 /rankings 看一眼当时的资料，别拿旧结论做新决策。

几个反复被踩的坑

最后一个部分不讲方法，讲坑。这些坑的共同点是：当时看着都挺合理，事后复盘才发现代价不小。提前知道能省一轮试错。

• 把评测集当训练数据用，指标好看但线上无感
• 忽略推理侧成本：微调后模型变大，服务账单跟着涨
• 以为微调能解决幻觉，结果只是把幻觉换了个方向
• 预训练项目没有明确的停手标准，一路加到预算烧完
• 只看训练总成本，不看迭代成本——数据一变就要重来一轮
• 把别人的样本量直接当成自己的下限，忽略了任务复杂度差异

其中推理成本这条最容易被低估。训练是一次性支出，推理是长期账单，模型变大之后每次请求的开销都会跟着涨。做决策时把两笔账放一起算，很多方案会自己分出高下。

预训练决定模型的下限，微调决定它在你业务里的上限；先确认下限够用，再谈上限。