deepseek-v3 本地微调训练

团队想把 DeepSeek-V3 调成自家领域的模型，通常卡在两件事上：一是不知道数据要整理成什么样，二是不确定要买或租多少卡。这篇不谈选型结论，只给一条可执行的准备路径——先定任务边界，再把数据做小做干净，然后按微调方式反推算力，最后拿小样本试跑验收。每一步都给了判断标准和不适用的情形，方便你在预算批下来之前先把方向固定住。

团队想把 DeepSeek-V3 调成自家领域的模型，通常卡在两件事上：一是不知道数据要整理成什么样，二是不确定要买或租多少卡。这篇不谈选型结论，只给一条可执行的准备路径——先定任务边界，再把数据做小做干净，然后按微调方式反推算力，最后拿小样本试跑验收。

整条路径的目标是让你在预算批下来、卡租出去之前把坑排掉。每一步都给了判断标准和不适用的情形，照着走一遍，最差也能得出「这活现在不该做」这个结论，而不是烧完算力才发现方向错了。

先定边界：这活到底该不该用微调

把需求拆成三类：改说话风格与输出格式、补领域知识、提升某类任务准确率。前两类优先考虑提示词与知识库方案，只有风格固化和高频重复任务才值得动权重。拆不清就先别往下走，因为后面所有准备工作都建立在任务类型上。

• 把判断标准写下来：如果换一批提示词或换个知识库，效果就能达标，就不要微调
• 微调的成本主要不在卡上，而在数据标注和后续每次换版的回归验证
• 不适用情形一：业务规则每周都在变，训出来的权重很快过期
• 不适用情形二：训练数据拿不到授权，先解决来源问题再谈训练
• 不适用情形三：团队没人能长期维护这条训练流水线

数据准备：格式、体量与清洗顺序

按「指令-输入-输出」整理成训练集和验证集两套。验证集的切分方式是准备阶段最容易出问题的地方：要按时间或来源切分，不要从同一批样本里随机抽，否则验证集和训练集高度相似，指标好看但上线就崩。

体量上先定一个最小可用集做可行性验证，再按效果缺口扩量。领域术语类的任务通常比通用对话任务需要更精简的样本，宁少而准。具体量级按任务类型对照，到站内指南中心的数据规模相关页面核对当时的说明。

1. 去重整句完全一致和高度相似的样本都要合并，同一意图保留少量代表性样本即可；去重前后数量差得离谱，通常说明采集口径有问题。
2. 去格式脏数据清掉乱码、多余换行、混入的网页导航文字；用脚本过一遍正则，再人工抽检一小批确认脚本没误删。
3. 去答案歧义答案与业务规则冲突、同一问题有两个互相矛盾的回复，这类样本必须删或统一口径，留着比没有更伤。
4. 写标注口径说明把「什么算合格答案」写成一页纸，多人标注前先对齐；没有这页纸，标注一定跑偏。

算力口径：分清楚训练与推理两笔账

微调占用的是训练侧资源，峰值显存取决于基座规模、微调方式和批大小三个变量，和推理侧按并发算的思路完全不同，不要拿推理的显存结论直接套到训练上，这是租卡前最常见的误判。

全参微调和参数高效微调两个量级差距很大，多数团队先走后者。显存不够时优先降批大小并开梯度累积，再考虑量化训练或换更小的基座。多卡不是简单除一下：先确认通信与并行方案是否支持你要用的微调方式，卡间带宽不够时加卡收益会掉得很快。

基座规模

决定权重本身占多少显存，是训练侧的第一个硬约束

微调方式

全参与参数高效两条路的资源量级不同，先选路再算卡

批大小

显存不够时第一个要动的旋钮，配合梯度累积稳住有效批大小

卡间带宽

多卡并行时的隐性瓶颈，带宽不足时加卡收益会明显下降

小样本试跑：用最小成本验证方向

先跑一个小规模试跑，只看趋势不看绝对效果：损失有没有稳定下降、验证集有没有同步变好、同样的配置复现是否稳定。三项都往好的方向走，才值得放大数据量和算力。

• 试跑通过再放大数据量和算力，别在趋势没看明白时一次性铺开
• 把「哪一版权重、哪一版数据、哪份评估脚本」记成一条记录，方便回退
• 试跑阶段就固定评估脚本，后面换版才有可比性
• 失败样例单独存一份，它们是下一轮数据的来源

验收与交付检查清单

固定一组真实业务问题做回归，每次换版都跑一遍，别只看训练指标。训练指标好、业务问题答不对，说明评估和真实场景脱节，这时候要改的是评估集而不是模型。

1. 跑回归测试用同一组真实业务问题对比新旧版本，记录每题的通过与否，不只看总分。
2. 确认许可边界提前确认基座模型的许可证对商用场景的边界，不清楚就到站内许可与合规相关页面核对。
3. 打包交付交付要连同数据版本、训练配置、评估脚本一起打包，只交出权重文件等于给后续埋雷。