deepseek本地部署 + 训练

很多人已经按教程把 DeepSeek 在本机或内网跑通了，一问「怎么接着训练」就卡住：不知道是继续预训练、做微调，还是干脆只做知识库；也不清楚自己的卡到底能训多大的模型。这篇不重复部署步骤，只把「部署完之后到真正训出一版能用的权重」之间那段路拆成可执行动作，并给出判断标准和什么时候该放弃本地训练。

环境准备：在能跑推理的基础上再补什么

很多人本地推理跑得挺顺，一上来就想直接开训，结果第一步就卡住。原因是推理和训练对环境的胃口不一样：推理只要权重能加载、显存放得下就行，训练还要额外装微调框架、盯紧 CUDA 和显卡驱动是否对得上。先把这条线捋清楚，后面才不会反复返工。

• 推理工具和微调框架是接力关系，不是二选一：前者负责跑，后者负责训，别指望一个工具全包
• 先跑通一个最小样例，再上真数据，样例过了才说明环境真的可用
• 确认模型存储路径，训练输出和原始权重往往不在同一个目录
• 确认权重格式，不同框架吃进去和吐出来的格式可能不一样
• 把显卡驱动版本和 CUDA 版本记下来，换了就重新对一遍

1. 第一步：确认推理已跑通先保证基础权重能被推理工具加载并出结果，这一步不通过就先别碰训练，说明基础环境还没稳
2. 第二步：装微调框架并对版本选一个微调框架装上，重点核对它要求的 CUDA 与你的显卡驱动是否匹配，对不上就调驱动或换框架版本
3. 第三步：跑最小样例用极小的一小份样本跑通一次完整训练流程，看它能不能正常开始、正常结束、正常产出文件
4. 第四步：确认路径与格式记下训练产物落在哪个目录、是什么格式，再回头确认合并时该拿哪一份权重去合

这里有个常见坑：训练输出目录和原始权重目录不在一起，训完想合并时满盘找权重。建议在动手前就把「原始权重在哪、训练产物在哪、合并读哪一份」三个路径写在一张纸上。具体的权重格式对照和目录约定，可以到站内模型资料库核对当时的说明，别凭记忆猜。

先算账再动手：显存和卡数怎么估

动手买卡之前，先把账算清楚。要回答的问题只有两个：显存够不够放模型和优化器，卡数够不够把训练时间压到你能接受的范围。这两件事经常被混在一起，其实得分开看——显存决定「能不能跑起来」，卡数决定「要等多久」。先按下面这张对照表把两件事拆开，再往下算数字。

全量微调

模型所有参数都参与更新，优化器还要为每个参数存状态，显存开销通常远大于模型本身。

参数高效微调

只训练一小部分新增或选定的参数，优化器状态大幅减少，本地起步一般优先看这类方式。

量化档位

把权重压到更低位宽存放，省显存，代价是精度和速度上的一些折中，档位不同结果差很多。

上下文长度

单条样本越长，激活值占用越大，长上下文会把显存需求往上顶一截。

1. 先定训练方式优先按 LoRA 这类只训小部分参数的路线来估，确认目标效果能接受再考虑全量微调；如果非要全量，显存预算要按数量级往上加。
2. 把四个输入量摆齐参数量、量化档位、上下文长度、批大小。这四个一变，结论全变，所以别只报一个参数量就问「几张卡够」。
3. 用站内工具对一遍到 /compute/sizing 按参数量、量化档位和上下文长度把口径对一遍，先看它给出的显存需求落在哪个区间。
4. 再估时长拿工具给的显存结论，反过来判断卡数够不够：显存刚好够但只有单卡时，训练时间会很可观，先想清楚你能接受多长的等待。
5. 留出余量再下单按估算值留一点余量，别贴着上限配；贴着上限跑，换数据、加长度或者放宽批大小都会立刻卡住。

• 只看显存不看时间，结果配出来的机器要跑很久，中途只能中断或者加卡。
• 只报参数量不报量化档位和上下文长度，估算结果没有参考价值。
• 把全量微调的显存需求套到 LoRA 上，会严重高估，白白多花钱。
• 单卡能跑通就以为多卡线性加速，实际受通信和数据读取拖累，提速没那么理想。
• 估完不复核，训到一半才发现显存不够或者时间超出预期，返工成本很高。

数据准备：比模型选择更容易翻车的一步

很多人把精力全花在挑模型和调参上，结果训完发现输出还是一股怪味：要么答非所问，要么格式忽好忽坏。追根究底，问题八成出在数据这一步。原始材料不先洗干净、不统一格式，模型学到的就是一堆互相打架的样式，最后反映到你的输出里就是不稳定。

统一格式

先定死一种样本结构，比如指令-回答或问答对，全库都照这个来

字段名

同一含义的列只用一个名字，别一半叫 question 一半叫 input

标点与换行

全角半角、句末符号、多空行都要清成一致，否则输出跟着乱

清洗优先级

先做格式统一再谈数量，格式乱的样本宁缺毋滥

格式这块最容易被忽略。你可以先随便抽几十条，人工看一遍，把不统一的地方记下来，再写脚本批量处理。判断标准很简单：把两条不同来源的样本并排放在一起，肉眼分不出处理痕迹，就算过关。做不到就继续改脚本，别急着开训。

1. 定模板先确定一种样本结构，例如指令-回答或字段抽取样本，把字段名和顺序写进一个小文档，后面所有处理都对照它
2. 批量转换用脚本把原始材料转成模板格式，统一标点、去多余空行、裁掉首尾空白，转换后随机抽几十条人工核对
3. 划分三份按大致比例切成训练、验证、测试三份，划分时打乱顺序再切，避免同一来源整段落进同一份
4. 封存测试集测试集单独存好，训练和调参期间不碰它，只在最后验收时打开看一次

还有一点：验证集和测试集别混用。验证集的作用是告诉你什么时候该停下训练，测试集只在最后看一次，用来判断这套东西能不能交付。如果拿同一批数据既调参又验收，你看到的分数就是自欺欺人。什么情况下不适用？当你的数据总量实在太小、连三份都切不出来时，可以先用交叉验证顶一下，但验收时仍要留出一批没参与过任何调整的样本。

训练执行：参数怎么设、什么时候停

训练参数没有一套放之四海皆准的数，只有一条主线：先让模型「动起来」，再观察它有没有往坏的方向走。学习率和训练轮次是两个最容易翻车的旋钮。学习率太大，模型会在几步之内把原有能力冲掉，表现出来就是回答变得前言不搭后语，或者只会重复；学习率太小，损失曲线几十步看不出变化，容易让人误以为代码写错了。稳妥做法是先跑一个很小的规模试跑，确认曲线有下降趋势，再放大到正式训练。

• 每轮结束都把验证集结果记下来，和训练损失并排看，不要只看一个数
• 验证损失出现回升就停，哪怕训练损失还在往下掉
• 保存检查点时按验证表现命名，不要只按轮次编号，方便回头挑
• 试跑阶段先把轮次设小，确认流程通了再拉长，不要一上来就设很大
• 日志里同时记录显存峰值和单步耗时，两项突变往往比损失更早暴露问题

1. 小步试跑用很小的一批数据和少量轮次先跑通，确认损失有下降趋势、显存没顶到上限。这一步只验证流程，不追求效果。
2. 放大参数把学习率在试跑值附近做小范围调整跑几组，选验证损失下降最稳的那一组，而不是下降最快的那一组。
3. 盯日志三件事看显存是否接近上限、单步耗时是否稳定、有没有梯度异常告警。任意一项出问题先停下排查，别硬着头皮往下训。
4. 按验证损失决定停点每轮记录验证表现，出现连续回升就停，回退到回升前的检查点作为交付版本。

训练完怎么接回本地服务

训练跑完不等于服务就换了脑子。微调产物多数是「补丁」性质：只存了训练时改动的那部分权重，推理工具读的是完整的模型结构，直接丢进去往往报结构不匹配，或者勉强加载了却一点变化没有。正确顺序是先合并，再转格式，最后对比验证。

1. 合并权重按你用的训练框架文档，把微调产物和训练时用的那份基座权重合并成一份完整的模型目录。验证方式是合并后目录里的文件数量和体积应接近原始基座，而不是只剩几个小文件。
2. 转换格式看看你本地推理工具认哪种格式，再用对应转换脚本转一次。别跳过这步，格式不对时工具可能不报错、直接静默用回旧权重。转换完用工具自己的加载日志确认读的是新目录。
3. 固定题对比准备一批同样的问题，分别问旧权重和新权重，人工看回答差异。重点看改动方向对不对，同时抽几道通用问题，确认模型没有整体变笨。
4. 留档可回退新权重单独放一个目录，旧版本原样保留，用配置或软链接切换。发现效果不对时能立刻切回去，不用重新训练。

• 合并和转换都做在副本上，原始基座权重不要动
• 固定题要提前写死、每次用同一批，否则前后对比没有意义
• 新权重目录命名带上训练批次或用途，别用「new」「test」这种名字
• 切换新旧版本尽量靠配置或软链接，别反复覆盖同一个目录
• 上线前多跑几轮日常问题，固定题看不出长尾场景的退化

验收与止损：怎么判断这一版值不值得留

这一节只解决一个问题：训完一版之后，怎么冷静判断它到底该留还是该扔。先说清一个前提，下面这套判断只适用于你对训练数据有掌控、且下游有固定调用方的情况；如果只是自己玩票、没有明确用场景，那验收线可以宽松很多，甚至不设。

验收不能只看「感觉变聪明了」，那多半是过拟合的错觉。稳妥做法是固定三类指标同时看，缺一类都会误判。三类指标各自看什么、怎么算，可以先看下面这张对照表，具体阈值和当前同类任务的基线，去站内模型资料库里核对当时的口径。

三项里最容易翻车的是通用能力。微调最常见的副作用就是「领域变强、别的全忘」，模型把参数都押到你的领域数据上，原本会答的题开始胡言乱语或答非所问。所以训练前一定要存一份基线回答，训完拿同一批问题再问，哪怕不做详细打分，肉眼扫一遍也能看出退化。

1. 训练前留基线把通用问题、格式样例、领域抽题各存一份，连同当时的回答一起归档，这是后面所有对比的参照物，没有它验收就是拍脑袋。
2. 训完先跑格式用解析脚本批量过一遍，格式合规率不达标就别往下看了，先回去改数据格式，而不是改超参。
3. 人工抽样判领域从领域题里抽一批，让不参与训练的人盲判对错，记录错误类型，是知识错还是格式错，两类问题的修法完全不同。
4. 回头测通用能力用基线那批问题重测，明显退步就说明代价太大，别急着继续调参。

如果三项都达标，那就留下、打标签归档；如果只是领域涨、通用崩，那就要算一笔账：模型变好的那部分，值不值它变差的那部分。多数时候不值，尤其是你的领域问题本来就能靠提示词或检索兜住的时候，退回原方案反而更省事、更好维护。判断这笔账划不划算，可以到站内指南中心看同类任务的经验口径，别自己硬扛。

• 先定验收线再开训，别训完才想及格线在哪
• 止损点写死：训到第几版还达不到验收线，就停，回到提示词或检索方案
• 连续两版指标没有实质变化，就说明调参到头了，继续只会烧时间
• 领域提升但通用明显退步的版本，默认不留，除非通用退化对你的场景真的无所谓
• 每一版的指标都单独记一行，别只留最后一版，否则回溯时等于白训

成本与合规别漏算

很多人算自建训练的账，第一反应就是「一张卡多少钱」。但真正烧钱的往往是卡以外的东西：电费、散热、机位租金、以及被训练任务长期占住、没法干别的活的那台机器。这几项加起来，三年下来可能比卡本身还贵。

算力总拥有成本（TCO）

把硬件、电、散热、机位、运维、折旧摊到几年里一起算，而不是只看采购价

机会成本

训练任务占住机器时，这台机器本来能跑推理或接别的活，少赚的那部分也算钱

单项对比陷阱

只比单卡价格，会忽略功耗和散热差异，长期账可能反过来

• 电费：按满载功率 × 每天训练小时 × 电价估，别看闲时功耗
• 散热与机位：家用环境要额外算空调和噪音处理，托管要算机位与带宽
• 机器占用：训练期间这台机器基本不能同时做别的事，要么排队要么加机器
• 折旧与故障：卡和电源、硬盘都有寿命，留一笔更换预算
• 运维时间：调环境、盯任务、处理掉卡，都是人力成本

数据合规：训练前先把授权范围翻出来

拿客户资料、内部文档、聊天记录去训练之前，先确认三件事：你是否有权把这些数据用于训练、里面是否混进了个人信息、训完的产物会不会间接带出这些内容。授权范围通常写在合同或用户协议里，不是「我能访问」就等于「我能拿来训」。什么情况下不适用：如果数据完全由你自己合成、且不含任何真实个人与第三方内容，这一层压力会小很多，但仍要留记录。

1. 列数据来源清单把准备喂进去的每类数据写下来：来源、归属方、获取方式。来源不明的先剔出去。
2. 核对授权条款翻合同或协议里关于「使用目的」「二次利用」「模型训练」的措辞，看是否明确允许；没写清楚的按不允许处理。
3. 标记个人信息筛查姓名、联系方式、身份标识等字段，能去标识化就去，去不掉就评估是否必须用。
4. 留存处理记录记下每批数据的授权依据和处理动作，将来对外提供服务时能拿出来说明。

许可证边界：权重能怎么用，读清楚再上线

不同开源权重的商用条件不一样：有的允许商用但要求保留声明，有的对月活或营收设门槛，有的明确限制某些用途。训完之后如果要对外提供服务，先回到权重自带的许可证条款逐条确认，别默认「开源就等于随便用」。拿不准时，优先选条款更宽松的权重，或把服务范围控制在许可允许的用途内。

什么情况下不该在本地训

本地训练听起来很爽，但很多团队真正需要的其实不是「把知识写进权重」，而是「让模型在回答时能看到这些知识」。这两件事的成本差一个量级。判断要不要训，先别问「能不能训」，先问三个问题：数据够不够多、需求稳不稳定、团队里有没有人能看懂训练日志。三条里只要有一条踩中，优先考虑检索或提示词方案。

• 只是想让模型多知道点事实，比如产品参数、内部流程、常见问题：更新检索库比重新训练便宜得多，改错了直接回滚某一条文档就行。
• 训练出来的模型很难「撤回」某一句话，检索库可以精确删掉某条，责任边界清楚。
• 如果你的算力是租的，先对比两条路的总耗时和总花费，而不是只看卡时单价。
• 团队里没人能判断过拟合、学习率、数据清洗质量时，训练更像是在赌，不是在做工程。

1. 先算两笔账把「租卡自训」和「官方接口 + 检索」两条路各自的总耗时列出来：数据清洗、训练、评测、上线、后续每次需求变更的重训时间。总花费也要算上人力，不只是卡钱。
2. 再验证检索能覆盖多少把最近一段时间的真实提问整理出来，直接跑一遍检索加提示词方案，看命中率和回答质量。如果大部分问题都能被文档覆盖，就没必要训。
3. 最后设一个触发条件只有当检索方案连续出现同一类失败、且这类失败靠加文档解决不了时，再考虑训练。触发条件提前写下来，避免拍脑袋决定。

当然，这不是说本地训练永远不该做。如果你的场景是固定任务、数据量大且质量可控、团队里有人能读懂训练曲线，那训练是合理的。具体到当前各家接口和算力的实际数字，别拿旧印象做决策，到站内的价格与模型资料库核对当时的情况，再按上面的步骤算自己的账。