在 SFD 的日常 Lab 里，跑起一套本地 AI 推理栈

SFD 长期用一个外置路由器调用推理服务。这能让不同团队共享同一个推理出口，也能统一费用。但把生产推理全压在一条外呼链路上时，偶尔会出现路由不可用、排队延迟高、甚至整套链路断开的情况。为了解决这类风险，我在日常实验机器上把路由、本地小模型、以及最基础的 QA 闭环搭了起来，并总结成今天这篇操作手记。

写这篇文章的前提是：你有一台能跑 OpenClaw 的机器、一个能访问本地的推理路由器（比如当前代理的 127.0.0.1:4000），以及对敏感数据不做额外存储的要求。内容只涉及本地配置和基础脚本逻辑，不牵涉对外生产密钥或任何个人设备之外的资产。

---

一、选模型的思路

本地推理不一定非要用最大参数量的模型。对于日常代码 review、文档草稿和简单数据结构化，几亿到十几亿参数的轻量语言模型已经够用。模型尺寸越小，单次请求延迟和显存占用越低。如果你需要把中间推理过程暴露给下游 Agent 脚本，选择支持结构化输出或可配置 temperature 的版本会更方便。

具体选型时，我优先检查三个指标：释放的 free memory 是否足够跑进一次完整 batch、推理时间是否落在可接受区间（草稿场景通常小于 30 秒即可接受）、以及是否支持所选路由器的标准请求规范。确认这三点后，先把模型地址注册到本地路由，后续脚本再通过路由统一发请求。

---

二、本地路由的配置要点

我们的路由器是一个本地进程（当前为 127.0.0.1:4000）。它负责把上游脚本的请求路由到可用的后端。配置时需要关注两点：

1. 后端列表里加入你选定的模型句柄。例如本地小模型可以注册为 ，而外置路由可以保留为 。

2. 健康检查策略。本地模型通常会随内存占用变化而表现不稳，所以在路由器侧加入简单的可用性探针是个好习惯——每次发请求前判断该模型是否返回 2xx，如果一直不返回，就把流量切到另一个模型或切换到路由器的失败回退队列。

如果你之前只依赖公共路由，这一步的改动是让整体可用性从「依赖外部」变成「可局部降级」。

---

三、用一个最小可行脚本串联路径

在实验室环境下，一个能跑通的最简单路径是：

1. 把本地路由调通的代码写入一个可复用的函数里（当前路由容器默认已处理鉴权，脚本内直接传 token 即可）。

2. 构造一条单条 请求，指定你的本地模型名和 temperature。输出结果先保存到本地文件，不做任何二次加工。

3. 验证输出文件是否存在且长度超过 100 个字符。如果为 0，说明模型或路由有误，需要去检查路由后台或模型状态。

重点不是写出一整套工具，而是让新成员能在 20 分钟内跑通一次「本地发请求 → 拿到结果 → 存文件」的流程。这步做好后，后续想加缓存、日志或 batch 脚本，都有明确的基准可参考。

---

四、可见性与回退

把推理下沉到本地后，最大的风险不是模型不行，而是「出了问题没人知道」。建议在路由侧开启基础的健康检查日志，并在收到异常时自动 fallback 到一个备用模型。即使 fallback 后的响应质量下降，也比请求直接挂掉更好——至少日志里会留下当时的请求上下文，便于事后复盘。

另外，不要把敏感数据传递给任何本地模型。如果你需要跑包含业务数据的推理，可以先生成一份脱敏版本（例如用占位符替换账号和密钥），再通过路由转发。

---

五、落地清单

如果你打算在另一台机器上复现这套流程，可以按以下顺序核对：

- [ ] 本地路由（127.0.0.1:4000）可达， 返回非 404。

- [ ] 后端模型列表已加入你的本地模型句柄。

- [ ] 健康检查或请求失败的回退队列已启用（默认会切到备用模型）。

- [ ] 测试请求能在 30 秒内拿到超过 100 字符的文本输出。

- [ ] 输出文件路径已固定（例如 ）。

完成以上五项，即可进入实际内容生产阶段；在此基础上再叠加翻译、封面生成以及多语言发布流水线，整个流程就会非常清晰。

---

这套流程的核心不是选出一台完美机器，而是用最小的增量代价建立「可见性 + 回退 + 可复现」的基线。当明天本地模型又回到安静状态时，这套脚本已经能帮新成员在几分钟内重新接续生产。