企业官网建设流程全解析

上个月，我把手头那台跑着本地大模型的机器，从“下载即固定”改成了“用完能进步”的模式。整个改造思路来自一个叫 YoungAi 的社区实验项目——它重新定义了本地 AI 的更新方式：推理服务继续干推理的老本行，旁边挂一个后训练 Sidecar，专门负责收集数据、触发微调、评估效果、发布新版本。这个方案特别适合不想把数据送出去、又觉得手动微调太繁琐的开发者。

如果你只是拿本地大模型做个聊天玩具，可能还没什么感觉。但一旦你把它接入工作流、让它长期服务固定的一群用户，模型不更新的问题就会非常扎眼：你的使用习惯、知识库、交互反馈其实都沉淀在本地，数据不断积累，模型却一直停在原地。YoungAi 做的事情，恰恰是把“训练”从“推理”里剥离出来，让模型像软件一样每天自动迭代。这篇文章我会把它的设计思路、核心组件、参数选择、踩坑过程完整拆一遍，希望能给你自己搭建本地 AI 系统提供一条可复制的路径。

1. 为什么本地大模型需要“持续进化”

1.1 一次性部署的尴尬局面

很多团队在启动本地 AI 项目时都走同一条路：从网上下载一个性能不错的基础模型，配好环境，跑起来，然后就不动了。前两周效果确实可以，但越往后越能明显感觉到不对劲。用户开始反复纠正同一个问题，模型给出的回答风格和团队预期越来越偏，知识库新增的内容它完全不知道。这其实不是模型能力不行，而是它没有“变”的能力。

云端模型靠服务商持续迭代，底层模型几个月就换一版，用户侧基本无感。本地部署则完全相反，模型文件就是一锤子买卖。你想获得同样的能力提升，只能重新下载新模型、重新跑一遍评测、重新处理兼容性。这个成本不低，尤其是显存要求变化、量化格式差异、依赖版本冲突，一次升级往往要折腾大半天。更现实的问题是，很多行业场景下数据不能出本地，云端模型再好也不能用，可本地模型又停滞不前，两边都很别扭。

1.2 持续进化要解决的三件事

YoungAi 这个方案把“持续进化”拆成了三个具体问题：数据回流、训练管道、版本交付。数据回流解决的是“模型靠什么学”，训练管道解决的是“模型怎么学”，版本交付解决的是“新模型怎么上线而不出乱子”，三者缺一不可。

先说数据回流。运行中的本地 AI 服务会沉淀大量交互记录、用户纠正、操作结果、知识库更新日志，这些天然就是训练数据。问题是它们又乱又杂，必须经过清洗、去重、隐私过滤才能进训练集。然后是训练管道。微调不是拍脑袋执行一条命令就行，需要针对本地硬件选合适的参数高效微调方案，控制显存占用，设置触发条件。最后是版本交付。新模型不能直接覆盖旧文件，必须有评测、有灰度、有回滚能力。把这三件事用自动化串起来，才能真正做到“睡一觉起来模型自己变强了”。

1.3 为什么选择 Sidecar 而不是“一体式改造”

刚看到 YoungAi 的思路时，我也想过：既然要改，为什么不直接在推理服务里加训练逻辑，做成一体式架构？后来越想越不对。推理服务是线上核心路径，任何改动都会引入稳定性风险，训练任务动不动占满显存，一旦出错整条链路都跟着遭殃。

Sidecar 模式相当于在主体之外单独挂一个辅助进程：推理服务照常跑自己那一摊，Sidecar 在旁边悄悄收数据、干训练、出结果，两者通过本机通信协作。这里的类比是飞机发动机维修——坏了一个发动机，不需要拆整个机身，挂载点在旁边，单独摘下来修就行。把模型训练做成“可插拔”的伴生服务，最大的好处是职责分离：推理进程只负责处理请求，训练进程只负责让模型进化。哪个出了问题，都能独立重启、升级、回滚，不用互相拖累。

2. Sidecar 架构：核心设计思路与关键技术选型

2.1 进程边界与通信机制

YoungAi 的部署单元很清晰：一个主进程负责模型推理和 API 服务，一个 Sidecar 进程负责后训练。两个进程不共享内存，只通过本机 HTTP 接口或 Unix Socket 通信。Sidecar 从推理服务拿什么数据呢？主要是三块：对话日志、用户点赞/点踩反馈、知识库变更事件。推理服务也会定期上报一个“忙碌指数”，告诉 Sidecar 当前显存占用和请求负载，Sidecar 根据这个状态决定要不要启动训练。

通信协议越简单越好。我建议不要搞太重的事件总线和分布式队列，一个本机端口、一组 JSON 格式的消息体、一个心跳信号就够了。Sidecar 每 30 秒向主进程报一次状态，主进程把新产生的交互数据推送到一个本地文件夹或者 SQLite 表里，Sidecar 定速轮询。这样即使 Sidecar 挂了，数据也都在主进程侧留存，不会丢。等 Sidecar 重启，续跑未完成的任务就行。

2.2 数据采集与过滤链路

数据质量直接决定后训练效果，这是我踩坑最深的地方。一开始我想省事，把所有对话日志直接扔给训练脚本，结果模型学了一堆网络用语和重复废话，反而变笨了。后来老老实实搭了过滤链路：先过规则过滤，把纯闲聊、无实际内容、超长无意义重复的样本剔除；再做相似去重，防止某条高频错误回答反复出现在训练集里；最后加一个“困惑度过滤”，用当前模型跑一遍候选样本，对那些模型已经回答得非常好的样本可以降权，重点把模型没答对、用户又给了负面反馈的样本留下。

隐私保护在这个环节同样重要。虽然数据不出本地，但识别信息、敏感字段依然要做脱敏。我会在抽取阶段就把用户名、手机号、邮箱等实体替换成匿名占位符，保证后面训练流程接触到的只是干净文本。这个处理不复杂，但必须在管线入口就做，不能拖到训练脚本里再处理，否则很容易漏。

2.3 训练触发与资源调度

Sidecar 不能像定时炸弹一样随便引爆训练任务，触发策略要足够保守。YoungAi 支持的触发条件很朴素，但非常有效：新样本数量达到阈值（我这边设置的 200 条）、负面反馈数量异常升高、用户手动提交训练请求。满足任意一个，Sidecar 就开始准备训练。

资源调度才是真正决定这套方案能不能落地的关键。本机 GPU 通常同时跑着推理服务，训练直接抢显存的话，用户请求会瞬间超时。我的做法是设置“空闲窗口”：Sidecar 每隔 5 分钟检查一次推理进程上报的忙碌指数，低于某条水位线再启动训练，否则进入退避等待。训练过程中如果推理负载突然升高，训练任务就自动暂停并保存断点，把显存让出来。这个“可抢占”机制很重要，不然用户体感很容易被后台任务拖垮。

3. 后训练管道：把 LoRA 微调做成自动任务

3.1 基座模型和 LoRA 适配器分层

年轻项目 YoungAi 的后训练核心思路是“基座不动、适配器动”。每次训练不碰原始模型权重，而是训练一个轻量级的 LoRA 适配器，再和基座模型合并或者动态加载。这样做的好处非常直接：基座模型永远是干净版本，出了问题随时可以卸掉适配器回退；适配器文件通常只有几十到一两百 MB，保存多个历史版本的成本很低。

LoRA 的关键参数有四个：秩、缩放系数、丢弃率和目标模块。我常用的组合是秩 16、缩放系数 32、丢弃率 0.05，目标模块覆盖注意力层的 q、k、v、o 投影和 MLP 层的 up、down 投影。秩越高表达能力越强，但显存和过拟合风险也随之增加。以端侧数据量（几千条以内）来说，秩 16 已经够用，贸然上到 64 反而容易记住噪声。缩放系数一般与秩保持 2 倍左右的关系，太大会让微调后的行为偏离基座过远。

3.2 训练样本格式与超参选择

训练数据格式不能乱编。我参考社区里相对通用的“指令-输入-输出”三段式结构，统一转成同一种 JSON 格式。每条样本长这样：

{ "instruction": "根据用户反馈修正回答风格", "input": "用户说：这个回答太啰嗦了，直接给结论", "output": "理解，以后先给结论再展开。" }

不需要做特别花哨的模板，但字段必须稳定。训练的时候我一般选 3 个 epoch，学习率 2e-4，最大长度 2048，批量大小 1，梯度累积 8 步。为什么这么保守？因为本地后训练数据量不大，学习率稍微调高一点就会把模型原来的能力冲掉，批量大小受显存限制又没法开大，梯度累积可以变相模拟大批次，让更新方向更稳。

3.3 评测门控与模型切换

没有评测门控的自动更新就是在玩火。YoungAi 的做法是维护一个固定评测集，里面有几百条覆盖核心场景的问答样本，每次训练完新适配器，先跑一遍评测，再和上一版本对比各项指标，只有胜负关系达到阈值才允许发布。

模型切换本身也要讲究原子性。我的发布目录结构是这样的：versions/v1/、versions/v2/、versions/v3/，每个版本目录里有完整模型文件和评测报告，当前版本用一个软链接指向最新目录。发布新版本时先生成新目录，更新软链接，再让推理服务重新加载。这个方案的优点是旧版本永远不会被覆盖，只要软链接改一下，秒级回滚。

3.4 为什么后训练必须带“回滚思维”

很多人做模型微调只关心训练完效果好不好，完全不考虑失败怎么收场。本地 AI 持续进化这种事，失败率其实很高，模型学歪、数据污染、评测集覆盖不全，任何一步出问题都会导致线上服务降级。回滚思维要前置到架构设计阶段，而不是等出事了再去翻备份。

我的习惯是每个版本留下三类东西：适配器文件、合并后完整模型文件、评测报告。适配器文件用于快速调试，合并后完整模型文件用于实际部署，评测报告用于事后分析。这三样东西都有了，回滚就是改一个软链接的事。我还会在推理服务里加一个“最近三个版本自动保留”的清理策略，磁盘紧张时优先删除更老的版本。

4. 实操记录：从零搭建一套持续进化本地 AI

4.1 最小运行环境与部署拓扑

如果你也想复刻这套链路，最小环境只需要一台带独立显卡的 Linux 机器，显存建议最少 24GB。我这边实际使用的配置是 GPU 24GB，系统内存 32GB，存储预留 200GB。这个配置不算高，主要是为了同时容纳基座模型、新旧版本模型和训练缓存。

部署拓扑上，我会把所有文件按三个目录隔离：runtime/放推理服务代码和运行配置，data/放交互日志、清洗后数据集，versions/放模型版本。三者不能混在一起，否则后面做数据清理和版本管理都会很痛苦。推理服务和 Sidecar 都用系统守护进程管理，崩溃后自动拉起，Sidecar 的任务状态单独存一份 JSON 文件，重启后能续跑未完成训练任务。

4.2 推理服务的改造点

很多人以为搞持续进化得把推理服务重写一遍，其实不用。YoungAi 的做法是在现有推理服务上改两个点：一是模型加载层支持指定版本目录，二是暴露一个简单的状态接口。状态接口返回当前加载版本、GPU 利用率和请求排队数，Sidecar 全靠这几个数字做资源调度。

模型切换我建议“先切后验”：Sidecar 发布新版本后，先让推理服务加载新版本但不立即对外服务，跑一遍冒烟测试，确认没问题再切流量。如果冒烟测试失败，就自动回滚到上一个软链接。这比直接在服务中新老切换要稳得多，尤其是一次更新多个模型文件时，能避免加载到一半的脏状态。

4.3 一次完整训练发布长什么样

完整的自动流程我拆成八个步骤，每一步都落在具体文件或状态上，方便排查。

第一步，Sidecar 扫描新增日志，发现有效新样本超过 200 条，进入训练准备。第二步，清洗管道跑完，把候选样本写到data/training/目录，同时生成一份抽样报告。第三步，随机抽样 10 条人工快速检查，确认没有明显质量问题。第四步，Sidecar 判断当前推理服务空闲，启动 QLoRA 训练任务，训练过程每 100 步记录一次损失值。第五步，训练完成后保存新适配器到versions/v2/adapter/。第六步，加载评测集，新适配器和上一版本逐一对比输出，记录胜率。第七步，胜率超过预设阈值则合并模型、更新软链接，触发推理服务重新加载；否则自动丢弃新版本，保留旧版本继续服务。第八步，训练任务结束，Sidecar 回填一条任务日志，记录样本量、损失、评测结果和最终版本号。

这八步里，第四步和第七步最容易出问题。第四步要处理训练中途被推理负载打断的情况，第七步要处理评测集不够全面导致的误判。我的建议是训练任务一定要支持断点续跑，评测集则要定期混入新的、真实发生过的纠错样本，防止评测集自己也“过时”。

4.4 显存空间不够怎么办

24GB 显存同时跑推理和训练的压力非常大。推理时模型占掉 8GB，QLoRA 训练峰值大约 14GB，缓存和临时数据再占几 GB，极限能压到 22GB 左右。但这是理想情况，如果推理服务负载突然拉起，很容易爆显存。

我做的资源调度策略是：Sidecar 只在检测到 GPU 利用率连续 15 分钟低于 30% 时启动训练。训练启动时显存预留也做保守估计，把目标模块的梯度计算量压到最低，开启梯度检查点，禁用一切不必要的缓存。如果训练过程中推理负载回升，就立刻保存断点并退出，把显存全部释放出来。这个机制磨合好之后，用户几乎感受不到后台训练的存在。

5. 常见问题与排查技巧实录

5.1 显存不足与训练中断

这可能是你们第一个遇到的问题。现象很直接：Sidecar 刚启动训练，推理服务就开始报显存不足错误，或者训练进程直接 OOM 被杀。排查时先看是不是同一个 GPU 上两个进程同时占用，再确认训练配置里是否开启了 4bit 量化。我建议第一次运行时把批量大小设为 1，梯度累积逐步往上加，先让训练能跑通，再优化吞吐。

还有一个隐蔽问题：PyTorch 这类计算库默认会缓存显存，进程退出后显存不一定立刻释放。遇到这种情况，等几秒再启动训练，或者在训练脚本里加显存清理函数。不要频繁启动训练任务，优先级排在更后面的是进程间共享数据的格式冲突。

5.2 数据污染和模型学歪

数据污染是持续进化最容易翻车的点。我一个朋友把用户吐槽“你真是笨死了”也当成正样本收进训练集，下个版本模型回答问题前先来一句“我是不是笨死了”，全组人血压拉满。所以过滤规则宁可严，不能松：纯情绪化文本、超短文本、含有侮辱性词汇的文本，一律不进训练集。

做判断时我会同时看两个指标：一是训练集里标注质量抽检比例，二是新模型在旧评测集上是否出现明显下降。要想提前挡掉污染样本，最实用的是困惑度过滤，用当前基座模型跑一遍候选样本，那些概率异常高的短句很可能只是高频噪声，而不是值得学习的样本。

5.3 灾难性遗忘怎么缓解

持续进化最大的坑不是模型不变强，而是变强一个旧任务，弱化三个旧任务。这在大模型微调里太常见了。原因是新数据和旧数据分布不一样，训练时梯度和旧能力互相冲突。YoungAi 缓解这个问题的办法很朴素：每个训练批次里混合一部分通用评测样本，比如按 70% 新样本、30% 旧样本的比例混合，让模型在学新东西的同时保留旧能力。

实操时我会把之前的某个稳定版本当成“锚点”模型，每次评测都做三方对比：当前版本、上一版本、锚点版本。如果当前版本比锚点版本下降超过阈值，即使新任务评测得分很高，我也不会发布。机器学习的经验就是把“变好”和“不退化”当成两个独立指标分开盯，缺一不可。

5.4 Sidecar 自身故障与自愈

Sidecar 毕竟是额外的进程，多了一个就容易多一类故障。它挂掉的时候推理服务本身还正常工作，所以也常被忽略，直到一两个月后才发现模型根本没更新。解决办法是给 Sidecar 加“任务状态持久化 + 心跳上报”，每次训练任务启动就写一条状态记录，崩溃重启后根据状态决定是续跑还是放弃重来。

系统守护进程的自动重启我已经习惯性用上了，但还不够，还需要在推理服务的状态页面里暴露一个字段显示“最近一次训练完成时间”。没有这个字段，Sidecar 静默挂掉多久你都无法察觉。我现在每周看一次这个时间戳，比看训练日志高效得多。

6. 实测效果与后续扩展方向

6.1 实测下来值不值

坚持跑了两个月之后，我的实际感受是：这套系统最大的收益不是分数提升多少，而是把模型迭代从“周级别”变成了“天级别”。以前我想调一次模型，先导出数据、清洗、写脚本、训练、评测、手动部署，一套流程下来大半天没了。现在只需要把清洗规则维护好，其余全部自动化。评测集上大概稳定提升了两到三成的错误减少率，这个数字不夸张也不惊艳，但胜在持续。

而且“模型会变”这件事本身会改变你和 AI 的交互方式。以前我对本地模型的回答不满意只能忍着，现在会直接点踩，因为我知道下个版本它大概率会修正。反馈回路一旦建立，系统的天花板就不再是模型原始能力，而是你和团队的迭代效率。

6.2 后续值得尝试的两个方向

第一个方向是把 Sidecar 从“单模型后处理”扩展成“多模型路由”。现在本地部署一个模型服务已经不够，不同任务各有所长，Sidecar 完全可以为不同请求选不同模型，同一个后台训练任务同时微调多个轻量适配器。这个方向比单纯堆一个大模型要灵活得多。

第二个方向是引入反馈强化环节。当前数据回流用的是隐式规则：点踩、纠错、超时等都算负反馈。但这些信号太粗糙，下一步可以在 Sidecar 里集成一个自动奖励模型，对生成结果打分后再决定是否进入训练集，相当于把“该学什么”这个判断也交给模型完成。YoungAi 后续版本已经在探索这个路径，我准备等它稳定后直接升级。

6.3 我最想强调的几个建议

如果让我重新搭一遍，我会先花两天时间把数据清洗和评测集做好，而不是先去调模型训练参数。很多人在这套系统上栽跟头，本质不是训练代码写错，而是数据太脏导致模型越学越差，最后不得不把整个版本目录清空重来。第二点建议是训练任务开始之前，永远先确认能回滚，才去碰新版本。第三点建议是不要贪心，触发阈值设高一点，宁可一周只更新一次，也不要每天更新一次却次次学歪。持续进化的核心不是频率，而是稳定。