很多人把大模型跑在本地觉得“能离线推理、不传数据出去”就算成功了。但我一直觉得这还不够如果模型部署之后就不再更新那它只是一个会说话的静态词典。模型的价值在于它能不能跟上你的知识变化、术语变化和使用习惯。为了折腾这个问题我给自己维护的这套本地模型迭代流水线起了个代号叫 YoungAi核心思路就两条用 Sidecar 把推理服务和训练流水线拆开用后训练让模型能持续吸收新知识。这篇文章把我这段时间的完整实验记录整理出来包括架构取舍、数据闭环、训练参数和踩坑修复给已经在本地部署过模型、想让模型越用越聪明的朋友一条可以直接照搬的路径。1. 为什么本地模型也需要“持续进化”而不只是一次性微调1.1 本地部署的真正优势不是“跑得动”而是“留得住”聊本地部署的时候大家关心最多的永远是显存、速度、模型尺寸仿佛只要能把模型塞进显卡就是胜利。但这些讨论忽略了一个更本质的问题本地和云端最大的区别到底是什么我的答案是本地部署让数据不需要离开你的硬盘这比推理速度值钱得多。企业内部的知识库、个人的笔记和偏好、行业里的黑话和术语这些数据在合规和隐私的限制下根本不适合传到云端 API。你想让模型真正理解这些内容就必须在本地给模型“补课”。并不是模型本身不够聪明而是它还不知道你所在领域的上下文。比如一个模型可以写出漂亮的财务分析但如果没见过你们公司的报销流程和项目代号它就很难回答员工的具体提问。问题是大多数人补课的方式是“一次性微调”整理一批语料训完部署然后忘掉。这种做法的问题在于知识是变化的。你上个月整理的内部流程文档这个月就改版了用户反复问的问题可能集中在你完全没预料到的方向。如果训练是一条只做一次的死流程模型就会在部署的那一刻开始变得过时。换句话说部署到本地这个动作本身只是起点。模型能不能持续跟上环境的变化才是本地 AI 真正要解决的难题。我给这个难题的答案是把“训练”从一次性行为变成一条自动运转的基础设施。这也是 YoungAi 这个项目存在的理由。1.2 “一次性微调”为什么撑不起持续变化的需求举个实际例子你就明白了。假设你维护一个面向内部员工的问答机器人模型刚上线时效果不错但三个月后业务系统升级旧文档全部作废模型还在按旧逻辑回答。这时候你想更新它常规做法是重新整理语料、重新微调、重新部署。这个流程要几个小时甚至几天期间模型一直处于“错误状态”。更麻烦的是如果你三个月才更新一次中间积累的大量真实交互反馈——用户觉得哪些回答有用、哪些回答被打回重写——就全部浪费了。这些反馈其实是训练数据里最值钱的部分因为它们反映的是真实需求而不是你脑补出来的需求。你辛辛苦苦手写一百条标准问答可能都不如用户真实问过的五十个问题更贴合业务。所以要支持“持续进化”第一步不是选什么模型而是改掉“一次训练定终身”的心态。你的目标应该是让每一次有价值的交互都能以较低的成本沉淀回模型里。这个沉淀过程如果靠人肉跑脚本肯定坚持不下来你很快就会被重复劳动耗尽耐心。于是就有了自动化架构的需求。这就是后面要说的 Sidecar 和后训练流水线。2. 用 Sidecar 把“推理服务”和“训练流水线”拆开的设计逻辑2.1 Sidecar 模式从云原生搬到本地模型到底拆了什么Sidecar 这个词来自云原生里的“边车”模式主容器旁边挂一个辅助容器帮主容器完成日志收集、监控上报、网络代理这些旁路任务主容器自己保持干净。我把这个思路搬到本地 AI 场景基于一个很朴素的担心推理进程和训练任务混在一起会互相伤害。推理服务要求稳定、低延迟、随时在线训练任务则相反它吃满显存、间歇性运行、运行过程中的失败和抖动都很正常。如果这两件事放在同一个进程里训练一跑推理就卡训练崩了推理也跟着死。这就像让同一个厨师既站在前台招呼客人又跑去后厨颠勺两头都做不好。所以我让架构上分成两个角色一个主服务负责模型推理只处理 generate 和对话补全一个 Sidecar 进程负责训练流水线监听数据、清洗样本、启动后训练、评估模型、发布新权重。Sidecar 挂了不影响主服务继续回答问题主服务升级也不影响 Sidecar 里正在跑的训练。这个拆分带来的另一个好处是升级路径清晰。推理主服务更新时不需要把整个训练流水线一起重跑训练逻辑调整时也不需要重启常驻的推理服务。两个进程各自迭代故障域完全隔离这对于个人维护的项目来说省掉了大量“改一处崩全局”的痛苦。2.2 一条数据从进来到变成权重的完整路径YoungAi 的数据流我可以用一张文字图说清楚它不算复杂但每一步都有自己的角色推理主服务每次处理用户请求会把交互日志写到本地数据目录Sidecar 进程定时或按事件监听这个目录读取新产生的交互日志Sidecar 对日志做清洗去重剔除坏样本组装成标准训练格式当有效样本累积到设定阈值Sidecar 启动一轮后训练任务先用低秩适配训练产出增量权重任务完成后进入离线评估用预留的评测集打分通过门禁的版本被发布到模型仓库未通过的自动丢弃Sidecar 通知推理主服务重新加载新权重新请求开始使用新版本。这条链路里最容易被忽略的是最后一步推理主服务要支持热重载。很多本地推理引擎默认启动时一次性加载权重不会自己去看磁盘上的新文件。所以我会在主服务里留一个 reload 端点Sidecar 在发布新版本后主动调用它。如果 reload 失败主服务继续用旧权重用户无感知。部署上我建议把两个服务分别跑成独立进程用 systemd 或者容器编排管理。它们共享两个目录日志交换目录和模型权重目录。这样设计之后Sidecar 即使整晚训练推理服务的延迟也一点不受影响。对于大多数自托管场景这个方案比在一个框架里硬塞所有功能要可靠得多。2.3 为什么本地场景不需要引入消息中间件一开始我习惯性地想在上游加一个消息队列把交互日志推过去。后来发现在单人或者小团队维护的本地场景这套东西纯粹是给自己添负担。本地数据量不大直接用文件目录加轮询就能满足需求引入队列还得多维护一个组件数据链路长了反而更难排查。设计原则也要跟着场景走单机本地场景的 Sidecar 要的是简单和稳定不是分布式扩展。只要日志目录写入和模型仓库发布这两个环节做好原子性保护整条流水线已经足够可靠。这也算是我在设计过程中做过的一个减法减掉了一堆不必要的外部依赖。3. 后训练不是一句口号LoRA、增量预训练与偏好对齐怎么落地3.1 为什么选 LoRA / QLoRA 而不是全参微调想让模型持续吸收新知识第一个要解决的问题是本地显存扛不住全参微调。一个 7B 量级的模型全参微调需要保存优化器状态和完整梯度通常要 8 张以上大显存显卡才舒服个人开发者手里通常只有一两张显卡这条路根本走不通。LoRA 的思路很直接不修改原来的大权重矩阵而是在权重旁边挂两个小矩阵用它们的乘积来模拟权重的变化。模型推理时原始权重 W 和低秩增量 BA 一起参与计算训练时只更新 B 和 A 这两个小矩阵。由于矩阵的秩 r 压得比隐藏维度小一个数量级可训练参数往往只有全模型的 0.1%~1%显存和训练时间都能降一个量级。QLoRA 再把底座参数量化到 4bit进一步压缩基座模型占用的显存。这样在 24GB 显存的单卡上训 7B 模型是可行的。实测跑一轮一两千条样本的指令微调普通消费级显卡也能在几小时内完成。全参微调每一步都要动整个模型本地进化这件事根本做不起来低秩适配才让“隔几天训一次”变得现实。为什么不把 adapter 合并回一个大模型文件合并之后推理时少一步低秩计算速度略快部署也更简单不合并则可以在同一个基座上挂多个能力适配器按场景切换。我自己的选择是发布到对外服务用的版本会合并成一个完整权重但训练产出的 adapter 文件也会存档。这样既有部署便利又保留了多个能力包。3.2 三条训练支路分别在什么时候用后训练不是一个筐什么都能装。YoungAi 里我主要走三条支路按目标选用。第一条是监督微调 SFT。它的作用是让模型学会“怎么回答”适合整理出高质量的问答对把回答格式、语气、内部规范灌进模型。数据格式通常是 system / user / assistant 三段式对话样本。比如你希望模型在回答前先说明“根据最新文档”或者让它在不确定时直接说“我不确定”这些规范都能通过 SFT 灌进去。第二条是增量预训练。它针对的是“模型不知道的新知识”——专业术语、最新文档、内部产品介绍。做法是把领域语料喂给模型让它继续学习文本里的知识分布。注意增量预训练不是为了学会对话格式而是为了扩充词汇和知识所以语料要尽量贴近真实业务文本而不是问答对。第三条是偏好对齐比如用 DPO 这类不需要单独训练奖励模型的方法。它的输入是“好回答/差回答”这样的成对样本。用户对某条回答点了赞但没有手动修改可以当成 chosen被用户明确改写或吐槽的可以作为 rejected。DPO 的训练目标是提高模型输出好答案的概率更适合利用交互反馈这类信号。三种手段的适用场景我用一个对比表归纳训练方式解决什么问题典型数据训练成本SFT对话风格、回答结构、指令遵循手工整理的问答对低增量预训练注入新的领域知识与术语最新文档、知识库文本中DPO对齐用户偏好减少糟糕回答成对的好/差回答样本低训练超参上我建议以小步快跑为主学习率 1e-4 到 5e-5训练 1 到 3 个 epoch上下文长度根据实际数据设 2048 或 4096。单轮样本控制在 500 到 2000 条之间比攒一堆数据一口气训练更可控。工具链用常见开源大模型训练栈就行不需要自己造轮子。3.3 一份可以被直接复用的训练数据样例给一个实用的数据格式方便直接上手{instruction: 用一句话解释什么是增量预训练。, output: 增量预训练是在已有模型基础上继续学习新领域文本以扩充知识和术语覆盖。, category: concept}实际训练时很多训练框架更习惯 chat template 格式把 system、user、assistant 的轮次组织好。我的经验是多轮对话必须带上下文不要只给最后一轮否则模型在真实使用中会忘记历史会话。你可以在每条样本里把前两三轮对话作为前缀保留。4. “进化”的闭环从交互日志到新模型权重的完整流水线4.1 训练数据从哪里来把交互反馈当成矿脉持续进化的前提是持续有新数据。YoungAi 采集数据主要有几个来源用户与模型的真实对话日志用户对回答点赞、点踩、改写后的最终答案知识库和帮助文档的更新内容人工整理的高质量问题。但原始日志不能直接拿来训练。一个最典型的坑是用户对某条回答不满意改写了一版更好的答案这个改写后的版本应该作为训练样本但如果采集逻辑没做对齐把用户抱怨的话也当成了 assistant 回复模型就会学到非常奇怪的东西。所以清洗是必须的。我用的清洗流程包含四步格式过滤把过短、乱码、纯 URL 的样本扔掉精确和模糊去重避免大量重复样本让模型反复背同一句话噪声检测剔除与业务无关的闲聊质量打分用一些启发式规则加模型打分给每条样本一个质量分低于阈值的不用。一句话总结处理原则训练数据的价值密度比数量重要得多100 条干净的高质量样本胜过 1000 条噪声数据。这条原则我是在踩了几个坑之后才真正认同的后面会专门说那个“复读机”事故。4.2 评估门禁和版本回滚不能让模型越进化越退化持续进化最怕什么怕模型学完新数据旧能力崩了更怕训练集太偏练完之后模型看起来 loss 很低实际业务反而更差。所以我给流水线加了一道评估门禁。做法是每周从真实交互中留出约 300 条新样本单独保存不进训练集。每次训练完Sidecar 先在这套评估集上跑一遍和当前线上版本对比。指标可以看正确率、回答长度、拒答率、和参考答案的语义相似度也可以混入几个固定的人工检查点。只有综合分不低于当前版本新版本才允许发布否则自动回滚保留旧权重。对应的模型仓库我按版本目录管理models/ base_7b/ train_v010/ merged/ lora/ manifest.json train_v011/ merged/ lora/ manifest.json current - train_v011current 是一个符号链接指向当前线上版本。Sidecar 发布新版本时不会直接覆盖正在使用的文件目录而是先写一个新目录全部写完、校验通过后再切换符号链接并触发主服务 reload。这样即使 reload 前主服务还在读取也不会有半份权重文件的问题。热重载之后我还会让主服务跑一次固定的健康检查请求比如问几个固定 prompt对比输出签名。输出预期的版本号的才认为发布成功。这一步虽然简单但能避免“训练成功但加载的其实还是旧文件”这种乌龙。5. 实测中踩过的坑灾难性遗忘、样本污染、热切换失灵5.1 灾难性遗忘比想象中来得快我第一次尝试持续进化时喂了大约 2000 条内部问答结果模型对新领域问题答得像模像样但日常闲聊和通用知识明显变笨了甚至偶尔回答格式都变形。复盘下来原因很清晰训练样本太偏全是新领域数据学习率给得偏高训练轮数也偏多。解法是给训练集加入 10%~20% 的历史通用样本做“重放”学习率降到 5e-5 左右epoch 不超过 3。另外不要试图一轮吃成胖子把一次大训练拆成多次小训练每次只针对最近累积的几百条有效样本反而更稳。这个调整之后灾难性遗忘基本被控制住了。注意重放样本不是随便找一些通用 QA 就行最好是从过去几轮训练数据里均匀抽样这样能覆盖模型已经学会的旧知识防止新的权重覆盖旧能力。5.2 样本污染模型学会“复读机”的教训有段时间我的模型出现一种很迷惑的行为同一个问题问两次第一次回答还行第二次开始复读第一次的答案。查了很久才发现训练数据里有大量重复问题而且有些样本把“用户改写后的最终答案”错误地拼进 assistant 轮次导致模型把“重复”当成了规律。这个坑给我的教训是训练数据必须做会话轮次对齐和去重。去重不能只看完全相同的字符串还要用相似度计算把语义重复的样本也去掉。清洗脚本里我会给每条样本计算一个内容哈希再用 embedding 距离做近重复检测超过相似度阈值的直接丢弃。更重要的是一句提醒不要迷信“数据越多越好”。如果自动化流水线把用户产生的坏回答也当成正确答案采集进来模型会稳定地学会那些坏回答。数据来源的质量信号比清洗算法本身更能决定训练效果。我现在宁可把采集门槛调高一点只吸收有明确正向反馈的样本。5.3 热切换不生效与权重文件竞争有个问题我调试了一整个下午训练完成新版权重也发布了推理服务 reload 成功但回答内容没有任何变化。后来发现是推理进程把模型权重映射到内存后不会去重新读取磁盘的符号链接目标我修改的是链接指向的目标进程却还在用旧的缓存文件。解决办法是发布新版本时使用全新的目录名并且在 reload 接口里显式指定新的模型路径不依赖符号链接原地更新reload 完成后必须跑一轮健康检查。另一种常见问题是训练还在往模型目录里写权重推理进程就已经开始加载导致读到一半的文件。所以写入过程要先写临时目录全部写完再做原子切换这是必须养成的习惯。5.4 训练和推理争抢 GPU本地场景往往只有一块 GPU。训练任务一旦跑起来推理服务立刻变慢经常 OOM。我的解决办法是给训练任务加了一个简单的调度策略只在推理服务低峰时段启动训练比如深夜如果训练过程中推理服务检测到显存吃紧也可以主动暂停训练任务等空闲时再恢复。这个机制不需要很复杂一个锁文件加一个定时检查就够用了。整条流水线跑顺之后我最大的体会是不要把持续进化想成一次两次微调它本质上是把训练变成和推理一样平常的基础设施。YoungAi 到现在已经自动迭代了好几轮每次只进步一点点但累计起来的变化非常可观。如果再给我一次机会我会更早地引入评估门禁——自动训练的每一步都值得被检验。最后再分享一个实用建议在你开始做全自动闭环之前先把数据采集、训练、发布、回滚这四个环节手工跑通一遍。确认每一步都有重启能力和人工介入手段再把它们自动化串联。任何自动进化系统都要留一个紧急停止开关这可能是整个设计里最重要的一句话。