企业官网建设流程全解析

如果你手里有一台显存还不错的机器，又折腾过本地大模型，大概率会遇到一个有点泄气的场景：刚部署的时候热情高涨，每天拿业务文档去测它；一个月之后，你还是问它同样的问题，它还是给你同样不够准的答案。你教过它的事情只在当次对话里有效，你更新过的资料库它感知不到，团队内部新出现的缩写词它经常瞎猜。这种“模型像被冻住”的感觉，就是本地 AI 最大的痛点。

我们团队后来做了一套代号 YoungAi 的改造方案，核心就两件事：用 Sidecar 把训练能力挂在推理进程旁边，再把后训练流程接到日常使用数据上，让大模型在本地持续进化。这篇文章把我完整的设计思路和踩坑记录写出来，适合手上有一台本地服务器、想把模型越用越顺手的朋友参考。

1. 重新理解本地 AI：为什么“静态部署”不够？

1.1 本地大模型的三大尴尬

本地部署大模型和云端调用最大的区别是什么？很多人第一反应是“数据不出域”“响应快”“不按 token 计费”，这些都对，但真正用过一段时间之后你会发现，本地模型还有一个隐藏的天花板：它的能力是固定的。

第一层尴尬是知识固化。云端模型隔几个月就换一代，知识是新的，本地模型一旦下载，参数就冻结了。你公司内部新出的产品手册、新定义的业务术语，它一概不知道，只能靠系统提示词往上下文里塞。提示词越塞越长，响应变慢，还经常漏看。

第二层尴尬是行为不可控。同一个问题，十个用户问会得到十种措辞风格，有的啰嗦，有的太简略。你希望模型按团队的口径回答，比如“先结论，再给依据，最后补充注意事项”，纯靠咒语式提示词很难稳定生效。

第三层尴尬是缺少反馈回路。云端产品可以靠海量用户反馈后训练更新，本地模型用完之后什么痕迹都不留。用户点没点赞、问题有没有被答对、哪个方向经常问错，对模型本身没有任何影响。

所以我们当时达成的共识是：本地模型如果只做“部署”，那它就是一件消耗品；只有把它接上“使用—回流—训练—更新”的循环，它才有长期价值。这也是 YoungAi 项目的出发点。

1.2 “持续进化”到底在进化什么

很多人一听“让模型持续进化”，第一反应是让它在线学习用户的每句话。这个理解是错的，也很危险。不要指望模型像人一样聊着天就变聪明，那既不稳定也不可控。YoungAi 里说的“持续进化”，本质上是三个受控的循环。

第一个是数据循环。推理过程产生的日志、用户反馈、纠错记录，经过脱敏、清洗、筛选之后，沉淀成可供训练的数据集。关键是“受控”，不是所有对话都进训练集，而是按规则和人工确认来决定哪些样本值得留存。

第二个是参数循环。数据积累到一定量，触发布局在 Sidecar 里的训练任务，用后训练方式在底座模型上做参数更新。更新的是低秩适配器或对齐层，不是把整个模型重训一遍。

第三个是评估替换循环。新模型训练完成后并不直接生效，而是先在一个固定评估集上跑分，通过之后才完成版本切换；如果指标降了，自动回滚到旧版本。

这三个循环合在一起，模型才会“越用越懂你”，而不是“越用越奇怪”。也更符合标题里说的“重新思考本地 AI”——本地 AI 的竞争优势本来就不该是参数规模，而是它能围绕你的数据持续生长。

2. Sidecar 架构：把“训”从“用”里彻底剥离

2.1 为什么不能塞进同一个进程

第一次设计 YoungAi 的时候，有人提过一个更简单的想法：模型推理服务不是常驻的吗？那就在同一个进程里加个定时训练模块，数据攒够了直接开训。这个方案听起来省事，实际跑起来就是灾难。

推理任务要求低延迟，训练任务要求高吞吐，两者挤在同一份显存和 CPU 资源里，结果就是推理响应变慢，训练损失震荡，谁也不讨好。更麻烦的是，训练代码一旦报错，比如 OOM 或者死锁，直接就把推理服务带崩了，线上业务全挂。

打个比方，推理是餐馆的炒菜窗口，需要稳定出菜；训练是后厨改造，要重新铺管道、换灶台。你非要把施工队请到炒菜窗口边上干活，菜也没法炒，工也没法施。Sidecar 的基本原则就是：给主服务旁边配一个辅助进程，共享一部分基础设施，但生命周期、资源、失败边界完全隔离。

2.2 训练边车具体负责哪几件事

YoungAi 里的 Sidecar，准确说叫训练边车（Training Sidecar）。它不碰用户请求，也不直接干预推理，它只承担持续进化链路里最脏最累的四个活。

一是采集与脱敏。推理服务把每次对话的输入输出、模型版本、用户评分写入本地日志，边车负责拉取这些日志，做敏感信息脱敏和格式标准化。脱敏这步不能省，别把员工身份证号、手机号当成训练语料。

二是清洗与蓄积。边车会把日志按会话切分，过滤掉过短、重复、被中断、含攻击性内容的样本，然后落到本地数据集仓库。这个仓库就是一个普通目录，按日期和业务域分目录存放。

三是触发与调度。边车内部跑着一个规则引擎，当“新增有效样本数”“距上次训练时间”“评测分数下滑幅度”任一条件被满足时，它会提交一个训练任务。任务进入本地队列，由训练工作节点逐个消费。

四是发布与回滚。训练结束后，边车会生成一个新版本模型，在隔离环境里先跑一轮自动评测，通过后更新线上模型指向；评测不通过就保留旧版本，并记录失败原因。

2.3 部署姿态与通信方式

在 YoungAi 的实际部署里，推理主服务是一个常驻进程，训练边车是另一个独立进程，两者之间没有共享内存，只有三条通路：推理日志目录、数据集仓库目录、模型版本目录。通信则是轻量的本地 HTTP 或 Unix Socket，心跳探活，简单直接。

我建议你不要上来就上消息队列、任务编排那一套，会显得很专业，但维护成本会直接劝退你。本地环境的资源本来就有限，用一个带锁状态文件的队列足够了。下表是我们当时的模块分工：

这种隔离带来的直接收益是：哪怕训练任务把显存吃光导致进程崩溃，最多损失一次训练进度，推理服务毫发无伤。对团队来说，这也意味着可以在白天让边车静默采集，晚上夜深人静时再跑训练。

3. 后训练：本地模型“变聪明”的真正引擎

3.1 后训练到底在训什么

聊后训练之前，先厘清几个被混用的概念。预训练是让模型读海量文本学会语言；微调是拿一批有标注的问答或指令数据，让模型适应特定任务；后训练则是个更大的伞，包含指令微调、偏好对齐、人类反馈强化学习这些阶段。本地环境里，我们做的主要是其中两类：指令微调和偏好对齐。

为什么不能做全参数微调？一个 7B 参数的模型，全参数微调光是优化器状态就得占好几倍于模型权重的显存，单张消费级显卡基本不用想，哪怕勉强跑起来，也要面对灾难性遗忘——把你底座模型原本会的东西全冲淡了。

YoungAi 的做法是“小步快跑”：用参数高效微调方式，冻结底座模型，只训练注入的适配器，把一次训练的成本压到一次普通推理任务的水平。底座模型不动，换来的是一份可以随时丢弃、随时合并的增量适配器。这样后训练对本地环境来说才真正变得可负担。

3.2 LoRA/QLoRA 参数到底怎么定

参数高效微调的思路理解起来不复杂：在原始权重旁边加几条低秩的旁路，训练时只更新旁路参数，推理时把旁路合并回原权重，或者动态叠加增量。LoRA 就是其中的代表，QLoRA 则是在 LoRA 的基础上把底座模型先做 4-bit 量化，进一步压低显存占用。

参数怎么选，我直接给一份经过验证的起始值：

这里有个容易踩的坑：很多人觉得 rank 越大越好，但在本地这种千条级数据规模下，rank 拉到 64 的结果就是训练集上分数漂亮，验证集和实际业务一测，马上漏出过拟合的尾巴。我们后来统一规定，首轮尝试先取 rank=8，如果评估集有明显提升再往上加，加一次测一次，别贪。

3.3 DPO 偏好对齐：把用户满意度变成训练信号

微调解决的是“会答”，偏好对齐解决的是“答得让人满意”。YoungAi 早期只用微调，结果模型回答问题倒是规范了，但语气生硬得像个自动回复机器人。后来我们引入了 DPO 做偏好对齐，效果才真正打开。

DPO 的原理可以理解成：准备一批“偏好对”，同一个问题，配上一个人工标注的好回答和一个相对差的回答，通过比较两者概率差来让模型学会“偏向好回答”。这里的关键参数是 beta，它控制模型偏离原始参考答案的容忍度，太大会让模型学到很偏激的风格，太小又学不动。实测下来，beta 取 0.1~0.2 对大多数场景都是安全区间。

偏好数据从哪来？一是让业务方人工标注，二是从用户反馈中隐式挖掘。比如用户追问“你刚才说的不对”或者反复编辑同一个问题，这些都是天然的负反馈信号。我们会在边车采集阶段给每条样本打上偏好标签，训练阶段再按需组装成偏好对。

3.4 数据质量是后训练的生死线

这一点值得单独拿出来强调：后训练能不能成，八成取决于数据，两成取决于参数。我们第一次用业务日志训练时，偷懒没做充分清洗，结果模型学会了把“这个嘛……”“说实话啊”这些口头禅当成标准风格，在回答里高频出现，气得业务方差点把这个项目毙了。

那之后边车的清洗模块加了好几条规则：长度小于 15 个字符的样本直接丢弃；单轮输入输出重复率超过 80% 的视为“复读机会话”丢弃；含网址、手机号、邮箱等实体的对话必须脱敏后使用；连续 20 条以上同一用户的问题只抽样保留 5 条，防止个别用户把模型带偏。

数据质量还有一层容易被忽略：训练集和评估集不能重叠。如果评估集里的题正好在训练集里出现过，哪怕模型是死记硬背的，跑分也会虚高，上线必翻车。我们后来把当日新增样本切两段，80% 进训练集，20% 进评估缓冲池，每周清空一次，从机制上杜绝作弊。

4. YoungAi 实操落地：架构、代码与资源规划

4.1 完整流程：从推理日志到新模型上线

YoungAi 的链路看起来环节多，实际上每一步都尽量做得朴素，方便排查问题。完整流程我拆成七步：

1. 用户在推理服务提问，服务记录请求日志、输出内容、用户评分到本地文件。
2. 训练边车巡检日志目录，按会话粒度切分数据，执行脱敏和规则清洗。
3. 清洗后的有效样本写入数据集仓库，按业务域和时间归档。
4. 边车统计新增样本量，当超过阈值（比如单周 1500 条）且距上次训练超过 48 小时，提交训练任务。
5. 训练工作节点消费任务，用 QLoRA 或 DPO 跑一轮增量训练，得到新适配器。
6. 训练完成，边车把适配器合并到最新底座模型，生成 vNext 版本目录。
7. 自动评估器载入 vNext，在固定评估集上打分；高于当前版本约定的分数则切换版本指向，否则保留旧版本并告警。

版本切换这块有个小技巧。我们不是直接把旧模型文件删掉，而是保留最近三个版本目录，线上服务读一个“当前版本”配置文件。切换时只需改配置里的版本号再重新加载模型。一旦新版本有问题，把配置改回去就能回滚，全程不用动训练产物。

4.2 关键代码示例：QLoRA 配置与边车触发逻辑

下面给一份 YoungAi 里 QLoRA 训练任务的核心配置，字段含义按实际项目简化过：

# 任务示例：qlora_customer_v7 task: name: "qlora_customer_v7" base_model: "local_models/llama3_7b_base" adapter_output: "adapters/customer_v7" data: train_path: "data/clean/customer_2024/" eval_path: "data/clean/customer_eval/" quantization: type: "nf4" double_quant: true lora: r: 8 alpha: 16 dropout: 0.05 training: epochs: 3 per_device_batch_size: 2 gradient_accumulation_steps: 4 learning_rate: 2e-4 warmup_ratio: 0.06

需要注意的细节是gradient_accumulation_steps。本地显存小的时候，per_device_batch_size 往往只能设为 1 或 2，但直接拉到 2 会显得步子迈得太大。累积步数 4 意味着每 4 个小批次才更新一次权重，等效批次大小为 8，比硬调大 batch 稳得多。

训练边车触发任务的逻辑，用伪代码表达会更清楚：

# 训练边车的触发逻辑（结构示意） def try_trigger_training(job_queue): stats = data_stats() if stats.new_samples < NEW_SAMPLE_THRESHOLD: return if hours_since_last_job() < MIN_INTERVAL_HOURS: return if not eval_score_declining(): return job_queue.submit( task="qlora_customer", data_snapshot=snapshot_new_samples(), config_path="configs/customer_v7.yaml" )

这三个条件缺一不可：数据量够、时间间隔够、评测有下滑趋势，三者同时满足才触发训练，避免模型不停地自我折腾。

4.3 资源预算参考：显存、时间与成本

预算问题直接决定落地方式。我们测试环境是一张消费级 24GB 显存显卡，底座模型是 7B 量化版。跑 QLoRA 微调时，显存占用稳定在 8~10GB，加载训练集的同时还能保留部分推理负载，训练 1500 到 3000 条样本、3 个 epoch 的耗时大约在 40 到 90 分钟之间。这个成本对“每周更新一次”的使用频率来说，完全可接受。

如果把底座换成 13B 量化模型，显存需求大约翻倍，单次训练时间会拉到 3 到 5 个小时。本地单卡机建议还是锚定 7B 档位，性价比最高。训练时如果想尽量减少在线推理影响，有两个手段：一是把训练任务调度到凌晨低峰期，二是在训练进程上用显存上限限制，把可分配显存压到比离线可用值低一点，宁可慢一点也不要和推理服务抢资源。

内存方面，训练边车本身很轻，主要内存消耗在数据清洗和评估阶段。建议机器至少有 32GB 内存，数据集仓库用 SSD 存放。整套跑下来，YoungAi 的额外硬件成本几乎为零，真正贵的反而是人工维护数据和标注偏好对的时间。

5. 常见问题与排错实录

5.1 量化模型微调不收敛

第一个典型问题出现在 QLoRA 训练刚跑起来的时候，训练损失前几个 step 不但不降，反而小幅上升，再往后直接震荡甚至报错。排查到最后，问题出在底层库版本不匹配上：量化加载方式和训练适配器这两个模块来自不同的版本组合，在梯度回传时出现了数值类型不匹配。

解决方法是把整条代码链路固定成已知兼容的版本组合，同时先跑一个 200 条样本的小烟雾测试，确认训练循环能顺利走完，再放开跑完整数据。这个烟雾测试的步骤相当于机场安检，多花十分钟，省掉半夜看日志的时间。另一个细节是学习率不能按全量微调的习惯设到 2e-5 这种小值，LoRA 适配器是新生参数，学习率低了半天不动，一般直接从 2e-4 起步再调。

5.2 训练任务拖垮在线推理

有一次我们把批量数据和训练流程都准备好了，兴奋地启动了第一次全量训练，结果 10 分钟后同事反馈线上对话响应慢了两倍。查了下资源，训练任务几乎吃满了显存，推理服务的一部分算子被挤到 CPU 上执行了。

后来我们上了两个硬性约束。第一，训练进程启动时设置显存上限，只允许使用当前剩余显存的 70%，剩下的留给推理服务抖动；第二，训练任务里把per_device_batch_size固定为 1，梯度累积步数加到 8，牺牲一点速度，保证推理延迟平稳。实测之后，除了模型切换那一下所有请求会短暂排队，其他时段基本无感。

5.3 模型越训越“蠢”的灾难性遗忘

训练了大概三周之后，业务指标还在涨，但团队里有人发现模型开始“变笨”：一些本来答得很好的通用常识题开始偷懒，甚至用业务口吻回答简单数学问题，明显是被业务语料带偏了。这就是典型的灾难性遗忘，后训练只盯着单一领域数据，把底座模型原有的通用能力冲淡了。

解决办法是调整训练样本配比，把通用指令数据混入训练集，占比大概 20%~30%。这些通用数据不需要额外收集，从公开指令集里抽一小部分缓存到本地即可。同时评估集设计必须双轨制：20 条业务专属评测题加 10 条通用能力抽样题，每次训练完成两轨都看，任何一轨掉分就不发布。有了这套机制之后，YoungAi 的迭代才真正称得上“进化”，而不是“偏科式更新”。

还有一个被反复问到的细节：如果新版本评估分数和旧版本持平，要不要切换？我们现在的规矩是，持平也切。因为持续进化的价值不只是分数提高，还在于模型手里的数据永远是最新的，等到哪天业务口径变化，新版本因为见过新数据，天然就有优势。

最后再聊一点实际的体会。我们把 YoungAi 这套东西跑通之后，最大的收获不是模型分刷得多高，而是彻底改变了对本地模型的看法——它不该是个一次性固化的部署物，更像一个能持续吸收团队经验的新成员。这个思路带给我们最大的正反馈，是团队开始愿意在生产环境里认真使用本地模型。如果你也想做类似的事，我的建议是从最小闭环开始，先只接一个业务域的数据，手工确认每一次训练触发，宁可慢一点，也别让模型在失控的路上越走越远。