把聊天切到 gemini flash，成本降了 4 倍
模型路由优化的技术概念插画
v0.0.5 把媒体支持做完之后，Mio 能看图、听语音、发表情了，一个 AI 伴侣该有的功能基本都齐了。但有个问题我一直拖着没碰：太慢了。
Mio 聊天背后的主力一直是 Gemini 3 Pro Preview，开着 thinking 的话，首 token 要等 8 到 10 秒。8 秒是什么概念，你发一句「今天过得怎么样」，然后就对着打字指示器干等，等个七八秒才开始出字。对话类产品等这么久，聊天那种沉浸感基本就没了，或者说你会开始怀疑它是不是卡死了。开发期间一直忍着，反正在赶功能。功能做完之后再看，这个延迟就是最扎眼的问题。
先跑一轮对比测试
没有拍脑袋直接换，我先做了一轮正经的对比：Gemini 3.1 Pro vs Gemini 3 Flash，专门针对情感伴侣这个场景去测。结果大概是这样：
| 指标 | 3.1 Pro | 3 Flash |
|---|---|---|
| 输入成本 | ~4 倍贵 | 基准 |
| 输出成本 | ~4 倍贵 | 基准 |
| 输出速度 | 90.8 t/s | 214 t/s |
| 首 token 延迟 (thinking) | 8-10s | 1-2s |
| 首 token 延迟 (minimal thinking) | N/A | 1-2 秒 |
成本差 4 倍，这个当然重要。不过真正让我拍板的是延迟这项：1-2 秒对 8-10 秒，这个差距用户是直接感受得到的。
剩下的问题是质量。伴侣 AI 这个产品，情感细腻度就是产品本身，Flash 要是立不住人设，省再多钱也没用。查下来社区的共识出奇地一致：Flash 基本可以当 2.5 Pro 的平级替代来用。极端情感细腻度上差距大概 1-2%，专业作者能分出来，大多数用户分不出来；叙事主动性和角色一致性上 Flash 反而更强。
还有一个挺反直觉的发现：thinking 模式会把创意写作的质量往下拉。好几个开发者都反馈过，Gemini 开推理之后，情感和创意的输出反而会变差。推荐配置是 thinkingLevel: minimal，正好把首 token 压到 1-2 秒。这么算下来切 Flash 基本没什么代价，速度和成本都是赚的，质量也不掉，等于没什么可犹豫的。
反直觉的反转：开推理模式反而让创意和情感写作变差，用 minimal thinking 反而更好。
按任务类型路由
想清楚之后方案就很直接了。不是所有任务都一样重：日常聊天要的是快，人格提取这种要的是深，那就按任务类型路由。
按任务类型把请求分流：90% 日常聊天走便宜快的 Flash，10% 高价值任务走贵而深的 Pro。
聊天（90% 的 API 调用）：Gemini 3 Flash + thinkingLevel: minimal
- 首 token 1-2 秒
- 214 tokens/秒的吞吐
- 每百万 token 成本大概是 Pro 的四分之一
- 日常对话里情感细腻度完全够用
高价值任务（10% 的 API 调用）：Gemini 3.1 Pro + thinkingLevel: low
- 从引导对话里提取人格特征
- 记忆摘要、情感模式分析
- 这类任务算一次就缓存结果，调用频率低，用贵一点的模型也无所谓，反正不常调
这么拆完，90% 的流量成本降了 4 倍；10% 的高价值任务因为从 3 Pro 换到了 3.1 Pro，质量反而是升的。
视觉 prompt 重写了一版
v0.0.5 加了图片上传，AI 能看了，但描述特别泛。你发一张游戏截图，它回你「我看到一个彩色的游戏画面」。这种回复没什么用，你跟朋友说在打游戏，朋友会问「什么游戏？」，没人会说「我看到一个彩色的画面」。
v0.0.6 把视觉 prompt 重写了，要求它说具体的：叫出游戏名字、认出品牌和 logo、描述地点的时候带上具体信息。视觉的 thinking 级别也从 minimal 提到了 low，多一点延迟，换明显更好的理解。改完的效果，大概就是从「我看到一个游戏」变成「你在玩原神？新地图怎么样？」。
中文语音转写修了两个地方
语音转写一直有 bug：用户发一段普通话语音，转写结果里会冒出英文单词，或者口语的表达直接被漏掉。这次修了两个地方：
- OpenAI 转写器加了显式的
language: 'zh'参数。不加的话，模型会逐段自动检测语言，碰到中英混着说或者背景有噪音就容易判错。 - Gemini 备用 prompt 加强了对口语、网络用语和中文专有名词的处理。OpenAI 转写置信度不够的时候走这条备用路径，现在俚语和特定名词都能正确处理了。
改动本身很小，不过语音是用户跟 Mio 最亲密的交互方式，转写老出错的话对体验伤得挺重，所以这两个修复的优先级其实不低。
顺手清掉 80 行重复代码
还有个代码质量的事从 v0.0.5 就搁在那：POST /chat 和 POST /chat/stream 两个 handler，媒体解析和 context 构建的逻辑几乎一模一样，或者说就是复制粘贴过去的，大概 80 行。这次提取了两个共享函数：
resolveMedia()— 按 mediaId 拿待处理的上传、做校验、返回处理好的媒体prepareChatContext()— 把历史记录、人设和媒体拼成对话 context
两个 handler 现在调的是同一套函数，80 行重复没了。这个问题 v0.0.5 的 audit 就标过 MEDIUM，这次正好修掉。
Google 不想让 Gemini 当情感伴侣
调研的时候还发现一个值得单独说的信号：Google 明确表过态，不希望 Gemini 被用在情感伴侣 AI 上。他们团队负责人公开说过，Gemini 的定位是「超级工具，不是情感伴侣」。具体的风险有三个：
- 外部安全过滤器是独立运作的，就算设了
BLOCK_NONE，也可能在回复中途把内容删掉 - Google 封禁过用 API 做角色扮演相关场景的开发者
- 未来的模型版本可能进一步限制情感和创意输出
这个信号不影响 v0.0.6 的决策，Flash 今天依然是最优选。但架构上得留后手：Mio 要做到足够的 model-agnostic，哪天真被限制了，能在不重写应用的前提下把 provider 换掉。刚搭好的模型路由层正好就是干这个的，等于顺手把后路也铺了。
这一版改了什么
v0.0.6 是几个小时内的六个 commit：
| 变更 | 影响 |
|---|---|
| 聊天模型：3 Pro → 3 Flash (minimal thinking) | 成本降 4 倍，首 token 1-2 秒 |
| 高价值任务：3 Pro → 3.1 Pro (low thinking) | 关键处的情感细腻度更好 |
| 视觉提示词 + thinking 级别 | 具体识别替代泛泛描述 |
| 中文语音转写 | 准确的普通话语音识别 |
| DRY 重构 | 消灭 80 行重复代码 |
| 部署文档 | 修正 Artifact Registry 命令 |
改动量都不大，六个 commit 都是小改，但体验上的提升挺明显的。
这个系列的第零篇做过一次取证分析，拆的是上一个伴侣框架早期为什么烧钱烧到不可持续。那次的教训就是成本要先搞清楚，不能等烧完了再回头算账。v0.0.6 把同样的纪律用在了模型选择上：先跑延迟基准、算成本、比质量，再看看社区的经验，别凭「Pro 听起来比 Flash 高级」这种印象拍。调研说 Flash + minimal thinking 是对的选择，部署完也验证了。
现在发消息，一两秒就开始出字了，聊起来舒服很多。至于 Google 那个态度，先记着，反正路由层已经搭好了，真到那天再说。
