我将 Gemma 4 部署在我的家庭实验室人工智能网关之后。这仅仅是个开始。

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

大多数模型实验都始于一个笔记本、一个基准测试脚本，或是一次快速的 API 调用。

而这次实验始于一个面向生产环境的问题：

我能否通过实际运行的本地人工智能网关，替换掉当前服务于默认路径的整个模型家族？

这不是一个侧面演示。不是一次性的 curl 命令。也不是“看，它能运行”那种浅尝辄止的测试。

我指的是真实的路由：那些代理程序、后台任务、应用界面、基准测试框架以及我自己开发的工具已经在调用的网关。

这就是我用 Gemma 4 开始的实验。

本文是这一故事的开端，而非最终结论。我是在平台仍处于试用窗口期时撰写此文的。后续跟进内容将会更加有趣：哪些部分保持了稳定，哪些部分在真实负载下崩溃，哪些部分被回滚，以及在经过一两周的实际使用后，我会保留哪些部分。

目前，这是具体的设置情况：我改变了什么，为什么改变，以及哪些部分立即失败了。

替换前的平台状况

我的本地人工智能技术栈围绕着一个我称为“Forge”（熔炉）的网关构建。

Forge 为调用者提供一个类似 OpenAI 的 API 接口，并处理其背后繁杂的部分：

• 哪种模型应该回答此类请求
• 哪台机器正在托管该模型
• 模型处于热启动、冷启动、已弃用还是按需加载状态
• 请求类型是对话、视觉、嵌入、转录、代码生成、信息提取还是其他类型
• 后端是否可用，或者是否应跳过

背后的机器是消费级硬件，而非数据中心设备：

在此次实验之前，默认的本地文本路径主要由 Qwen（通义千问）家族模型承担。这并非偶然。Qwen 已成为操作基线，因为它对于平台而言足够可预测，而不仅仅是在孤立测试中表现令人印象深刻。

我也测试过其他模型。例如，Devstral2 足够有趣，值得正式接入并进行基准测试。较小的 240 亿参数变体在代码场景中具有竞争力，但并未成为默认路径。1230 亿参数的模型对于我所需的角色来说太慢了。这种区别很重要：

一个模型可能很优秀，但并不一定适合作为平台的默认模型。

这就是 Gemma 4 必须跨越的门槛。

为何进行原位替换

我本可以将 Gemma 4 作为另一个可选模型添加进去，然后就此作罢。

那样做会更安全。但那样我也学不到太多东西。

相反，我将其视为一次真正的迁移。在试用窗口期内，Gemma 4 接管了真实调用者已经使用的标准角色。

旧的 Qwen 路由并未被删除。它们被标记为已弃用，并计划了回滚窗口。