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

这周掘金上两篇高赞帖，讲的是两件不同的事。一篇讲怎么在 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 缓存读 $0.0028 / 百万 token——这个数字 来自他所用的聚合平台 OpenCode Go（原帖里是从一位朋友的账单读出来的），不是 DeepSeek 官方价目页上的价。这个区分很重要，下面会说明为什么。

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

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

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

这里要说清楚两件事。

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

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

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

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

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

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

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

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

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

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

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

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

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

那张你可以自己填的表

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

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

拿去直接用：

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

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

哪一部分值得交给系统

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

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

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

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

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

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

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

收尾

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

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

延伸阅读：本地跑 Qwen 3.8 等于 Opus 4.6？这个等号有五个前提 （本地云端分流那条规则的技术前提）、你的 LLM 账单里有多少是看不见的 （为什么账单事后也对不出来）。