大模型实战:微调、优化与私有化部署

团队常卡在同一处：模型能跑起来，但微调完不敢上线，上线后又慢又贵，想搬进内网更不知道从哪下手。这篇不堆概念，按「先定目标—再算资源—再选档位—再合并部署—最后验证回退」的顺序，把每一步的判断标准和动作列清楚，具体数字到站内对应页面核对。

很多团队卡在同一处：模型能跑起来，微调完却不敢上线；勉强上线了，又慢又贵；想搬进内网，更不知道从哪下手。问题往往不在技术本身，而在顺序——先定目标、再算资源、再选档位、再合并部署、最后才是验证与回退。这篇不堆概念，按这条链路把每一步的判断标准和动作列清楚，具体数字到站内对应页面核对。

读之前先明确一件事：微调、优化、私有化部署不是三件并列的事，而是有先后的流水线。目标没定清就去找数据，数据没自检就去调参，调完不合并不验证就直接替换线上模型，任何一步跳过去，后面都得返工。下面按七个环节展开，最后一页执行清单可以直接拿去当项目看板。

先定目标：这三种活到底该做哪一种

动手前先把需求归到三类之一：补知识、改风格与格式、改能力边界。补知识指模型不知道的内部事实、产品文档、时效信息，这类靠检索更合适；改风格与格式指输出要固定成某种口吻、某种结构，提示词或轻微微调就能解决；改能力边界指模型本身做不好某类任务，比如特定领域推理、固定格式抽取，这才需要真微调。归类错了，投入基本白费。

升级顺序建议固定成「先提示词 → 再检索 → 再微调」。提示词改两三轮没有明显提升，再上检索；检索把知识问题解决了但任务通过率仍上不去，才考虑微调。每一级都要设退出信号，比如改提示词连续几版都达不到约定门槛，就说明不是提示词的问题；检索接入后失败案例集中在推理而非事实，就说明该走微调。站内已有专门讨论这三者分界的文章，这里只讲动作，不重复那些结论。

数据这一关：够不够、干不干净、格式对不对

先按任务类型看数据形态。分类和抽取类任务，重点是标注口径一致，同一个边界情况不能两个标注者给出两种标签；风格对齐类任务，重点是样本多样，别让模型只学会一种句子结构；指令跟随类任务，重点是覆盖边界与拒答，光喂正例会让模型该拒绝时也硬答。数据量和效果不是线性关系，先拿小样本试跑，看曲线走势再决定要不要扩。

• 去重：完全重复和近似重复都要清，尤其是模板生成留下的伪多样样本
• 去模板化残留：把占位符、系统提示、批处理标记删干净
• 去矛盾标注：同一个输入出现两个相反标签的样本，要么统一要么丢弃
• 统一字段与截断长度：训练和推理时的字段名、截断策略要对齐
• 留出验证集：从同一分布里切，别拿训练样本回测

什么情况下不该微调：样本量极少、标注者标准不统一、任务本身靠检索就能解决。这三种情况下硬训，通常表现为验证集好看、线上崩得快。判断办法是先做一次小样本试跑，如果同一批数据换个人标注后结果波动很大，说明问题在数据一致性，不在模型。

资源测算：显存档位并发先算明白再动手

估算要按项拆开：参数量乘以权重精度，加上优化器状态、激活值、缓存。训练和推理的口径不同，别混用一套数。训练时优化器状态往往比权重本身还占地方，推理时则是缓存随上下文长度线性增长。量化档位在质量、显存、吞吐之间做取舍，具体档位对照去站内的显存估算与部署测算页看当时的数字，别凭记忆估。

权重占用

参数量乘以每参数字节数，精度越低占用越小，但质量可能下降

优化器状态

训练时每个可训练参数附带的额外状态，参数高效微调能显著压小这块

激活与缓存

随批大小和上下文长度增长，是峰值显存的主要来源之一

峰值余量

并发不是显存除一下就算出来，要按最大上下文和瞬时峰值留余量

并发估算最容易翻车的地方，是拿平均上下文去算。真实请求里总有几条特别长的，峰值显存由最长那几条决定。稳妥做法是按目标并发乘以最大上下文跑一次压测，到站内测算页把当次配置填进去核对，再决定要不要降批大小或换量化档位。

微调方式与训练配置：怎么选、怎么不训崩

参数高效微调够用的场景：任务是风格对齐、格式固定、领域术语适配，数据量中等，且基座模型本身已经具备相关能力。必须全参微调的场景：任务需要模型学到新的推理模式，或者参数高效方案在验证集上怎么调都上不去。判断分界不看参数量，看的是「基座差多远」和「允许改多少」。

1. 小学习率试跑先跑很少的步数，观察 loss 走势；如果一开始就震荡，先降学习率而不是加步数
2. 看曲线决定步数验证损失开始回升就是过拟合信号，早停点设在那里，别硬跑满
3. 查灾难性遗忘每轮抽几条通用问题测一下，通用能力明显退化就要调低强度或混入通用数据
4. 留存检查点按固定间隔保存，日志记清步数、损失、数据版本，后面回退全靠这些

权重合并与打包：从训练产物到可部署模型

适配器权重和原模型合并有固定顺序：先确认基座版本一致，再执行合并脚本，合并后做一次一致性抽检——同一批输入分别跑合并前和合并后的模型，输出应当基本一致。抽检不过就别往下走，多半是基座对不上或者合并脚本参数写错。

版本管理的要求很具体：把基座版本、数据版本、合并脚本三者绑成一条记录。只记模型名，过两周没人说得清这个权重是怎么来的。合并后的模型存成什么格式、什么精度，取决于后面用哪个推理框架，所以顺序是先定推理框架，再决定打包方式。当前可用的工具链和训练服务到站内微调服务目录与训练页核对。

私有化部署与性能优化：跑起来之后怎么跑得快

推理框架按场景分：单机试用看重上手快，多人并发看重调度和显存利用率，批量离线看重吞吐而不是延迟。三类需求对应的取舍不一样，别拿单机试用的配置直接上生产。提速动作按性价比排序：先调批处理与并发参数，再做量化，最后才考虑换硬件。顺序反了，钱花了效果未必好。

• 显存占满：先看最大上下文和批大小，再考虑量化或换更小模型
• 首 token 慢：多半是预填充阶段计算量大，调批处理策略或看前缀缓存是否生效
• 输出慢：逐 token 生成受解码策略影响，检查采样参数和批内调度
• 并发上不去：先确认是不是峰值显存卡住，而非算力不足

内网部署还有一关：许可证与商用边界。模型权重、推理框架、训练工具可能各有各的授权条款，别等上线才发现不能用。这一步没有捷径，逐项核对授权文件，把结论记进项目文档。部署环境的实测表现，可以用站内工具目录里的测速工具跑一遍，看当时的延迟与吞吐数字。

上线前验证与回退清单

验收要三组一起跑：通用能力回归、目标任务集、对抗与边界输入。通用能力回归防止为了目标任务把模型练废；目标任务集是主指标；对抗与边界输入看模型该拒绝时是否拒绝。通过线怎么定？不是看跑分，而是看任务通过率有没有达到事先约定的门槛，这个门槛在开工前就写进项目文档。

1. 准备验收集三组集合分开存放，目标任务集从验证分布里切，不得混入训练样本
2. 跑基线对比把基座模型和微调后模型跑同一组输入，记录通过率差异
3. 写回退方案旧版本镜像保留、切换开关就位、数据与日志可回溯到具体版本
4. 设放弃条件任务通过率不升、通用能力明显退化、维护成本超过收益，三者占其一就停

一页执行清单：从开工到上线

把上面七个环节压成一页清单，开工前、训练中、上线前、上线后各盯几件事。这份清单可以直接当项目看板用，每一项都有明确的完成标志，没打勾就不进入下一阶段。具体阈值和数字到站内对应页面核对，别抄别人项目里的数。

• 开工前：目标归类完成、数据自检通过、算力测算跑过一遍
• 训练中：小样本试跑有结论、检查点按间隔留存、日志可复盘到具体步数
• 上线前：合并抽检通过、三组验收集跑完、回退开关就位
• 上线后：盯延迟与失败率、按周期复评是否还需要继续微调
• 长期：把本次的基座、数据、脚本版本记录归档，下次微调有对照