本地部署的大模型怎么训练

本地模型能跑起来之后，很多人会卡在下一步：想让它懂自己的业务、按自己的格式说话，到底该改什么。是继续训练、还是只做微调、还是干脆别动权重？这篇按「定目标—挑方法—算资源—验效果」的顺序走一遍，每一步都给出可对照的判断标准和该去站内哪个页面核对的数字。

先分清你要的是「补知识」还是「改行为」

动手训练之前先问自己一句：我是想让模型「知道得更多」，还是想让模型「做事方式变一变」。这两个目标看着近，技术路线差得很远。选错方向，通常不是效果差一点，而是白烧几小时甚至几天机器，最后发现根本没解决原来的问题。

先说「补知识」。如果你的诉求只是让模型读到新文档、新条例、新流程，那优先考虑检索增强：把资料切成块存进向量库，提问时先检索再拼进上下文。这条路不改权重，资料更新只要重新切一遍入库，第二天就能生效。反过来，用微调往里灌知识，等于让模型把原文背下来，既背不全，也没法保证时效。

改成「用知识库兜底」的检查点

• 资料是否经常变？常变就别往权重里塞
• 答案是否需要能追溯到原文出处？需要就走检索
• 问题是否总围绕同一批文档？是的话检索增强基本够用
• 模型原本的语言能力和推理能力是否已经够用？够用就别重训

再说「改行为」。固定输出格式、固定语气、学会一套内部术语、按固定流程拆解任务，这类需求跟知识无关，跟「条件反射」有关，这才是微调擅长的范围。判断方法很土但有效：把同一个问题问十遍，你要的不是答案不同，而是形态一致，那多半属于改行为。

还有一种常见情况：只是想让某类任务答得更好，手上却没有几百条以上干净样本。这时候别急着上微调，先去调提示词。样本太少，模型会记住你那几十条的表面特征，换个问法就崩，也就是过拟合。提示词改到天花板再考虑微调，顺序别倒过来。

不适用的情况也说清楚：如果你的目标既是补知识又要改行为，比如让模型按公司口径回答新政策，那往往是检索加微调两条腿走，单靠一条都别扭。另外，样本量足够、格式要求又很死板时，硬扛提示词会越来越脆，这时候微调反而更省事。

继续训练、全参微调、LoRA 三条路的取舍

先把三条路的定位说清楚：继续训练是喂大量领域语料让模型改语感，全参微调是在目标任务上把所有权重都动一遍，LoRA 这类适配器微调只训练一小撮附加权重。三者不是谁替代谁，而是数据量、硬件、任务稳定度三个条件先卡住你，再选路。

判断顺序建议从硬件倒推：先看手里是单卡还是多卡，再看任务是不是长期固定，最后看有没有成规模的领域语料。单卡本地机器直接看第三行，不要被继续训练的效果描述带跑，那部分投入通常不是个人机器能兜住的。

• 数据量：几百到几千条指令数据，走适配器微调就够；要到百万级领域文本，才谈得上继续训练。
• 显存：全参微调的显存需求会随模型规模成倍上涨，先按自己要跑的模型量一遍峰值再决定。
• 任务稳定度：任务半年不变，全参或继续训练回本更慢但上限高；任务经常换，适配器微调切换成本低得多。
• 运维成本：多套适配器意味着多份权重和切换逻辑，评估一下自己愿不愿意维护这套东西。
• 迭代频率：如果每周都要重训一次，优先选训练快、单次成本低的那条路。

1. 先圈定任务和数据把要做的事写成一句话，同时把可用语料按条数量和干净程度过一遍。语料不够规模就别往继续训练上想。
2. 量一遍显存和机器按自己要跑的模型规模估算峰值显存，单卡跑不动全参就先把这条路划掉，别先训再发现 OOM。
3. 按任务跨度选路线任务单一长期用，考虑全参微调；任务多且会变，优先适配器微调并规划好多套适配器的管理方式。
4. 再决定自己跑还是外挂先到 /stacks/fine-tuning 看一圈服务商和工具覆盖，如果站内已有现成方案能覆盖你的任务，就不必花时间搭本地训练链路。

最后补一句适用边界：如果任务是通用对话、语料只有几十条，三条路都不值得，先把提示词和数据整理做好；如果是强合规、数据不能出内网的场景，外挂方案直接排除，只能在本地方案里选，这时候优先看适配器微调，再看整机条件是否够全参。

按显存和数据量倒推能不能做

做不做得了，先别问「我的卡够不够训大模型」，而是反过来算：手里这张卡实际能空出多少显存，再拿去对照模型规模。很多人卡在这一步是因为直接看显卡标称显存，而系统、桌面、其他进程、CUDA 上下文都会吃掉一块，实际可用往往比标称少一截。先跑一次空闲状态下的显存占用，记下这个数，后面所有测算都以它为准。

1. 量出可用显存关掉占显存的进程，用 nvidia-smi 看当前已用，再用标称值减去已用，得到真正能拿来做训练的上限；训练脚本启动后再看一次峰值，两次差值就是模型和优化器实际吃掉的部分。
2. 对一遍推理占用拿同规模模型去站内部署测算页核对推理阶段的占用，路径是 /models/deploy。注意那是推理的数，微调要在这之上再留优化器状态、梯度和激活的余量，别把推理占用当成训练预算。
3. 按顺序降参数显存不够时先降序列长度和 batch size，再考虑把 LoRA 秩往下调，最后才动量化基座；每降一档都重跑一次，确认不 OOM 再继续。

数据量没有统一门槛，别信「必须几千条」这类说法。分类、抽取、格式规整这类任务，几百到上千条常常就能看到效果；开放性生成任务要的会更多，但更关键的是标注一致性——同一类输入被打成互相矛盾的标签，再多条数也是噪声。量不够的时候，先把已有数据的一致性过一遍，比盲目加量划算。

• batch size、序列长度、梯度累积是一组联动参数，要一起调，不能只改一个
• 从小的 batch 和较短的序列起步，稳定后再往上加，一上来拉满很容易 OOM 或训练不稳
• 梯度累积可以在显存不变的前提下模拟更大的 batch，但会拉长单步时间
• 量化基座能训，但效果和稳定性得用你自己的数据实测，别默认和全精度一样
• 判断能不能做，用「跑通一轮 + 抽样看输出」两个条件，而不是只看启动成功

能不能训，不是看卡大不大，是看可用显存减去推理占用之后还剩多少，以及你的任务到底需要多少条一致的数据。

跑起来之后怎么判断该收手还是该重来

训练脚本跑起来容易，难的是跑起来之后怎么下判断。先把一句话记住：训练损失曲线只是给你看「模型背得怎么样」，真正决定要不要收手的是那批从没进过训练集、也没参与调参的验证样本。如果训练损失一路往下掉，验证指标卡住甚至反弹，基本就是过拟合信号，继续跑只是让它更会背题，不是更会做题。

验证集之外，还要固定一组真实任务问题做人工对照。同一批问题，新旧模型各跑一遍，逐条比。这一步不追求统计显著性，追求的是「你关心的那个坏情况有没有出现」。别只看整体感觉，要拆成可数的东西，不然两版回答看着都还行，你根本分不清哪一版更该上线。

对照结果不达标时，回退排查有顺序，别第一反应就换更大的模型。模型规模通常是最后一个变量，而且换它代价最大、归因最难。前四步都没动过就换模型，等于把前面所有变量一起搅乱，下次出问题你还是不知道是谁的锅。

1. 第一步：查数据质量抽十几条训练样本逐条读，看标注是否有前后矛盾、答案是否本身就是错的、格式是否统一。发现脏数据先清再谈其他。
2. 第二步：查样本数量看目标行为在训练集里出现多少次。只出现几次的行为，模型学不稳是正常的，不是模型不聪明。补齐数量后重跑再对照。
3. 第三步：查学习率验证指标剧烈震荡或不升反降，先怀疑学习率偏大。调小重跑，观察验证指标是否变平稳，而不是盯着训练损失。
4. 第四步：查方法选择前面三步都排除后，再想是不是该换训练方式或加数据增强。此时换模型规模才有意义，因为其他变量已经相对干净。
5. 上线前：合并与导出按 /stacks/fine-tuning 的工具目录逐项对照，把适配器与原权重合并、导出成可部署格式，再在目标环境里跑一次那批固定问题，确认合并后行为与训练时一致。

什么情况下这套顺序不适用？如果你只想要一个非常窄的行为、训练样本又极干净且数量充足，那可能一步就过，回退链用不上；反过来，如果验证集本身就有标注错误，那所有指标都不可信，先修验证集再谈收手还是重来。另外，合并导出这步在部分工具链里是可选的，什么时候必须合、什么时候可以运行时加载，同样以 /stacks/fine-tuning 里的工具说明为准。