本地部署大模型后如何训练

本地模型能出字了，下一步要不要动权重，很多人卡在这。直接上微调脚本，常见结果是把模型练傻、显存爆掉、或者训完发现效果还不如改提示词。这篇按顺序给一套判断标准和动作清单：先确认是否真需要训练，再准备数据和环境，最后怎么验收、什么情况下该掉头放弃。

本地模型能正常出字了，下一步要不要动权重，很多人就卡在这。直接上微调脚本，常见下场有三种：把模型练傻、显存爆掉、折腾半天发现效果还不如改提示词。这篇不讲原理，按顺序给一套判断标准和动作清单——先确认是否真需要训，再准备数据、配环境、跑起来，最后怎么验收、什么情况下该掉头。

整条链路比推理长一截，训完还得合并权重、重新部署、做对照测试。所以别把训练当成「想让它更强」的默认选项，它只是一类特定问题的解法。

先回答：你这种情况到底要不要训

知识类缺口

缺新事实、缺冷门资料，优先上检索增强，把资料喂进上下文，不改权重

格式与风格类需求

固定输出结构反复出错、口吻不稳定、领域术语老是理解偏，这类才是训练的靶子

改提示词能解决

先试几版提示词和少量示例，能过就别训

几十条数据

样本太少，训了容易过拟合，先攒数据或者退回提示词方案

• 要训的典型信号：同一类输出格式反复出错，加提示词也压不住；领域术语理解系统性偏差；需要在固定风格上稳定复现
• 不该训的情况：只是缺最新事实、只是泛泛希望它更聪明、手上只有几十条样本
• 成本先摆桌面：训练要额外占卡、要留出验证集、训完要合并权重再部署，链路更长也更费时间
• 拿不准的时候，先去 /stacks/fine-tuning 看现成的微调服务与工具目录，判断是自建还是外包更划算

一句话分界：缺知识走检索，缺行为走训练。如果两样都缺，先补检索，因为那部分改完立刻能验证，训练则要等一整个流程跑完才知道行不行。

数据准备：决定成败的一步

规模上，垂直领域任务通常千条量级起步才有明显变化，但别只盯总量——按任务难度和类目覆盖度看更靠谱。具体口径可以到 /compute/finetune 对照当时站内整理的说明和示例。

环境与跑通：从能跑到跑对

1. 算显存按模型规模、精度、批大小估一遍占用，本地卡不够就上低秩适应或量化训练；到 /models/deploy 用测算工具对一遍自己的配置
2. 冒烟测试先跑单步，确认不报错、损失能下降、日志能落盘，再放开完整轮次
3. 记录关键项学习率、批大小、轮数、随机种子写在同一个文件里，方便回溯和复现
4. 盯曲线训练损失降、验证损失反弹就是过拟合信号，该停就停；显存吃满先按 /vram-optimization-guide 排查再考虑加卡

新手最容易跳过冒烟测试，直接开完整训练，跑几小时才发现配置写错。单步验证花不了几分钟，能省掉一整晚。另外学习率这类参数别一次调太多项，改一个记一个，不然出问题都不知道是谁导致的。

训练完怎么验收与上线

• 合并导出：低秩适应的产物要跟基座权重合并才能当普通模型加载，合并后的格式要跟你的推理框架对得上
• 验证集跑一遍：用留出的那批数据，对比训练前后的输出
• 人工看真题：挑业务里最难的十几条实际请求，肉眼过一遍
• 同题对照：拿训练前的基座跑同样的题，两边放一起比，差别不明显就别上线

只看损失数值不算通过，损失好看但实际输出变差的情况很常见。判断标准是：目标场景稳定变好，同时通用能力没有明显退化。两个条件缺一个，就先别替换线上版本。

不适用的情形也说清楚：如果训完通用能力明显掉、或者只在一个很小的场景上变好，那这次训练就不值当，保留基座版本切回来即可。下次再试，先把数据和评测口径改明白再动手。