# 手动在四个模型之间切换？这套规则有三个失效点

> 掘金两篇高赞帖：一篇在 DeepSeek V4 Flash、GLM-5.2、Qwen3.8 Max、GPT 5.6 Luna 之间用 /models 手动切，一篇讲本地云端怎么分工。这套规则是有效的，但有三个失效点——其中一个已经发生：规则依赖的那个缓存读价格，在同一个入口上已经变成峰谷两个价。附一张五列的规则表，写完就能看出哪几条该交给系统。

- Published: 2026年8月23日
- Author: Leo Kaka, Engineering
- Tags: routing, cost, coding-agents
- Canonical: https://pirouter.ai/zh/blog/you-are-already-routing

---
这周掘金上两篇高赞帖，讲的是两件不同的事。一篇讲怎么在 DeepSeek V4 Flash、GLM-5.2、
Qwen3.8 Max、GPT 5.6 Luna 之间用 `/models` 切来切去，一篇讲本地跑 Qwen3.8-27B 和云端
怎么分工。**两位作者都没用「路由」这个词，但两个人做的都是路由——按任务特征选后端，
按成本约束定默认，按失败情况兜底。** 区别只是这套逻辑跑在人脑子里，不跑在代码里。

我不打算说手动做这件事有什么问题。这套规则是有效的，两位作者也都写得很清楚。我想说的是
另一件事：**规则会过期，而人脑不会报警。** 其中一条规则已经过期了，就在这两篇帖子发出来
之后没几天。

## 先把规则老实写下来

第一位作者的做法，是订阅入口下的多模型切换。执行 `/models` 看可用模型并切换，
`/connect` 接供应商。规则大致是三条：

- **默认用 DeepSeek V4 Flash**，理由是缓存读便宜，频繁使用最划算；
- **Qwen3.8 Max 留给复杂规划和疑难问题**——它虽然也在 $10 套餐里，但每月折算额度只有
  $15，作者原话是「不建议一直作为默认模型使用」；
- 套餐层面还有速率约束：每 5 小时 $12、每周 $30、每月 $60。

先澄清一个容易读错的地方：**上面这些美元数是按美元折算的配额刻度，不是账单。**
账单是固定的 $10/月。这个区分下面会反复用到——配额是一堵墙，撞上了不是多付钱，是**停下**。

第二位作者做的是另一维度的分流：本地和云端。他**自测**的是 M5 Max 128GB + Ollama
4bit，约 25 tok/s；另外**引了社区数据**（M4 Max、开投机解码 MTP 的 M5 Max、RTX 5090），
区间到 90–120 tok/s——都是 4bit，与 FP16 不可比，而且社区数上下浮动两倍是常态，
自测与转述这两层不该混着读。结论是日常编程、agent 任务、中文写作和基础编程「完全没问题」，
可以长时间跑不心疼 token。

但这位作者的结论才是这篇文章里最重要的一句：

> 说实话，Qwen3.8-27B 现在还替代不了我的生产主力，真正做项目，我还是会打开云端。

复杂长推理云端更稳，速度和云端 API「完全比不了」，多轮 agent 上下文涨起来之后回读延迟
累积。**这是一个诚实的分流结论，不是一个失败报告。** 本地不是替代，是分流——而分流边界
就是路由决策。

把两位的做法合成一张表，是这样：

| 维度 | 规则 | 判据 |
|---|---|---|
| 按任务复杂度 | 简单/高频 → V4 Flash；复杂规划 → Qwen3.8 Max | 单价 × 频次 |
| 按额度 | Max 不做默认 | 月额度 $15 用完就没了 |
| 按部署位置 | 日常编程/写作 → 本地；长推理/生产项目 → 云端 | 稳定性与速度 |
| 按速率窗口 | 5h/周/月三层限额内排布 | $12 / $30 / $60 |

这张表是真的能用的。四条规则覆盖了任务、成本、部署、限额四个维度，比大多数团队写在
文档里的「模型选型规范」都具体。

问题不在规则本身，在它依赖的东西。下面三节分别是三个失效点：**前提数字过期**、
**额度耗尽后没有下一步**、**失效是无声的**。

![三个失效点的成因与实证：前提数字过期、额度耗尽后无降级路径、失效无声](/blog/images/you-are-already-routing-failure-points.png "图 1 — 三个失效点的共同结构：失效时刻与你需要规则的时刻高度重合。图中价格为 [OpenCode Go](https://opencode.ai/docs/zen/) 平台价，与 [DeepSeek 官方价目页](https://api-docs.deepseek.com/quick_start/pricing) 是两套计价体系。")

## 第一个失效点：规则依赖的价格，已经不是当初那个了

第一位作者的默认模型规则，理由是 V4 Flash 缓存读 **$0.0028 / 百万 token**——这个数字
来自他所用的聚合平台 OpenCode Go（原帖里是从一位朋友的账单读出来的），不是 DeepSeek
官方价目页上的价。这个区分很重要，下面会说明为什么。

同一个位置，OpenCode Go 现在列的是**谷时 $0.007 / 峰时 $0.014**。

变的不只是数值，是**结构**：原来一个位置一个价，现在一个位置两个价。这个结构来自
DeepSeek 8 月 16 日 16:00 UTC 起实行的峰谷定价，平台跟进了它（这次调价背后的条款背景，
[另一篇](/zh/blog/price-notice-is-a-contract-clause)里有）。峰时段换算成北京时间是
**09:00–12:00 与 14:00–18:00**——上班时间。

所以那条规则现在有两个问题，第二个比第一个严重得多。第一，基准数变了。第二，
**同一个模型在一天中不同时刻是两个价，而规则里只有一个价。** 「V4 Flash 当默认因为
缓存读便宜」这句话在谷时依然成立，在你实际写代码的那八小时里，成立程度打了对折。

这里要说清楚两件事。

一，**这不是作者写错了**。他写的时候那个数就是对的，来源也交代得清清楚楚。

二，也是更值得注意的一点：**这个数字所在的计价体系，和你去 DeepSeek 官网看到的不是同一个。**
同一个模型名，经由不同的聚合平台或订阅入口，单价、缓存口径、额度扣减方式都可能不同。
所以「去官网查一下现在多少钱」这个动作，对一条经由平台生效的规则来说是**查错了地方**——
你要查的是那条规则实际跑在哪个入口上。

这两点合起来才是完整的失效模式：**失效的不是判断，是判断的前提；而前提在哪儿、
谁在维护它，规则本身通常没写。** 手动规则的本质缺陷就在这里——它把一个会变的外部变量，
固化成了脑子里的一个常量，还顺手丢掉了这个常量的出处。

## 第二个失效点：额度用完之后，规则里没写「然后呢」

「Qwen3.8 Max 留给复杂规划」是一条好规则，直到那 $15 的配额刻度走完。

规则表里没有这一行。真实情况下这一行会由你在当时临时决定，而临时决定的时刻恰好是最不适合
做决定的时刻——你正在解一个疑难问题，额度耗尽的提示弹出来，你要么降级到一个能力不匹配的
模型继续，要么停下来重新规划预算。两个选择都不是你冷静时会做的那个。

同样的问题在速率窗口上更隐蔽：$12/5h 那一层，触发的时候往往是你手头工作最密集的那五小时。
而峰谷定价让这堵墙提前到来——同一笔请求在上班时段扣掉的配额是谷时的两倍，
**额度上限没变，消耗速率翻倍了**。这是第一个失效点和第二个失效点咬合的地方。

**规则的完整形态应该包含降级路径**：主选项不可用时,次选项是什么，什么条件下降级，
降级后哪些任务应该干脆推迟而不是硬做。这三个问题手动做也能做，但你得**事先**写下来——
写在脑子里的规则通常只有主路径，没有降级路径。

## 第三个失效点：失效是无声的

前两个至少还有个明确时刻——价格公告日、额度耗尽提示。第三个没有。

供应商侧的降级、限流、模型静默替换、上游波动，这些都不会给你发通知。手动规则的执行者是你，
而**你只在结果变差之后才知道规则失效了**，中间隔着若干次质量不明的输出。

第二位作者其实碰到了这类问题的一个温和版本：多轮 agent 上下文涨起来之后回读延迟累积。
这是可感知的——慢是能感觉到的。但「同样的 prompt 今天返回质量差了一点」不可感知，
尤其在你同时在四个模型之间切换、每个模型的基线手感本来就不同的时候。

这也是我不建议把「手动」当成落后的原因。手动的问题不在于人不够聪明，在于**人没有采样**。
一个能报警的规则，前提是有东西在持续测量；脑子里的规则没有测量层，所以它只能事后归因。

## 那张你可以自己填的表

在讨论要不要自动化之前，先做一件成本为零的事：**把你的规则写下来。**

不是写给别人看的文档，是给你自己的一张表。四列：

| 列 | 填什么 | 为什么这列重要 |
|---|---|---|
| 触发条件 | 什么样的任务/时段/状态走这条 | 说不清触发条件的规则，等于没有规则 |
| 目标模型 | 具体到版本 | 「用便宜的那个」在四个模型之间不构成指令 |
| 前提数字 | 这条规则依赖的价格/额度/速度，**注明是从哪个入口读到的** | 官网价与平台价不是一回事，不写来源就没法复核 |
| 上次复核 | 你最后一次核对上一列是哪天 | 没有这一列，过期是不可见的 |
| 降级路径 | 主选项不可用时怎么办 | 这一列通常是空的，而空着的代价在最忙的时候兑现 |

拿去直接用：

```markdown
| 触发条件 | 目标模型 | 前提数字 | 上次复核 | 降级路径 |
|---|---|---|---|---|
|  |  |  （来源：） |  |  |
|  |  |  （来源：） |  |  |
```

写完你大概率会发现两件事：第四列的日期普遍偏旧，第五列大面积空白。这两个发现比表本身
更有价值——它们精确地指出了哪几条规则该交给系统，因为**「持续复核外部数字」和
「在失败时自动走备选」正是人做得最差、机器做得最好的两件事**，而「判断这个任务复杂不复杂」
恰恰相反。

## 哪一部分值得交给系统

按上面那张表分类，规则分成两半，分界线只有一条：**这件事需不需要在你没看着的时候
持续发生。**

**该留给你的**：任务复杂度判断、质量偏好、什么活儿值得花贵模型。这些依赖你对项目的理解，
没有任何系统比你更清楚这次重构是不是「疑难问题」。

**该交出去的**：价格快照的复核、时段感知的选路、额度耗尽时的降级、上游异常时的切换。
这四件事的共同点是它们都需要**持续测量**，而且失效时需要**立刻**响应——正好是手动规则
的三个失效点。

如果你打算把这几件事交出去——无论是自建还是买——下面四个问题值得逐个问清楚。
它们对应的正好是上面三个失效点，而且**不针对任何一家**，包括我们：

- 价格快照更新之后，**历史的成本估算会不会被追溯改写**？（改写了，你就对不上上个月的账）
- 峰谷、阶梯这类定价，是**建模成一个独立的价格维度**，还是取了平均？（取平均 = 峰谷这件事在系统里不存在）
- 额度耗尽时的降级路径是**配置项还是硬编码**？（硬编码意味着降级去哪儿不由你定）
- 上游降级或静默替换，系统**多久能发现**？发现之后的默认动作是什么？（这条对应第三个失效点，也是最难答的一条）

能痛快回答这四条的方案，多半真的在做持续测量；答不上来的，卖给你的可能只是一个更漂亮的
手动切换界面。

规则写下来这件事本身就值得做——**你手动执行的这套逻辑，系统化之后长的就是它现在的样子**，
只是多了一个会报警的测量层。

## 收尾

两位作者都在做正确的事，而且做得比大多数人细。我唯一想补的是：他们规则里的数字带着
隐式的时间戳，而其中一个已经过期了。

如果这篇文章只留下一句，那就是：**把你规则里的每个数字后面加上你上次核对它的日期。**
这一个动作,就能让上面三个失效点里的第一个变成可见的。

延伸阅读：[本地跑 Qwen 3.8 等于 Opus 4.6？这个等号有五个前提](/zh/blog/local-qwen-equals-opus-preconditions)
（本地云端分流那条规则的技术前提）、[你的 LLM 账单里有多少是看不见的](/zh/blog/invisible-llm-bill)
（为什么账单事后也对不出来）。

---

## Sources

### opencode.ai

- [OpenCode Go](https://opencode.ai/docs/zen/)

### api-docs.deepseek.com

- [DeepSeek 官方价目页](https://api-docs.deepseek.com/quick_start/pricing)