2024 年的一个早上,某法律 SaaS 的产品经理把月度账单截图甩到 CTO 群里——12 万。那是一个中等体量的法律工具平台,服务几千家中小律所。用户每天问的问题,80% 其实就是合同日期怎么填“违约金上限多少”管辖法院怎么选这一类常识题。可产品当初图省事,把所有请求都打到 GPT-4。理由很简单——贵一点的模型应该不会错吧。CTO 看着账单,沉默了十分钟。贵的模型不一定错,但贵得离谱,而且 70% 的请求根本不需要它。他转头问产品经理一句话:“你算没算过,12 万里有多少是给简单问题买的单?”产品经理愣住了。这就是这一篇要回答的核心问题——不是 AI 本身太贵,而是用 AI 的方式太粗放。不是技术不先进,而是用技术的方法不讲究。这位 CTO 后来跟我说:“我那天晚上把日志翻了一遍,才发现我们把 GPT-4 当成了万能锤,什么问题都砸一下。其实 70% 的问题,一把小钉锤就够了。”这个小钉锤的比喻,后来成了他们内部改造 AI 系统的口头禅。每次开会讨论要不要用大模型,第一句话就是先想想这是钉子还是螺丝。我们接着往下看,这套思路具体怎么落地。我再帮你把这个故事再展开一个角度——为什么分诊台这件事在前大模型时代没人做?因为前大模型时代,模型是训练-部署模式:训练一个 BERT 分类器、训练一个 GPT-2 生成器,每个模型各管各的。系统设计天然是按问题类型分模型,不需要分诊台——你问分类问题就走分类模型,问生成问题就走生成模型,各司其职。大模型时代不一样。一个 LLM 能干所有事——分类、生成、推理、翻译,全都行。不是模型变多了,而是模型变万能了;不是模型选择变少了,而是为什么不用这一个模型变多了。这种专业分工在前大模型时代是常态,反而是大模型时代的反例——因为大模型什么都能干,反而让设计者放弃了按问题类型分模型的纪律。结果就是:产品经理为了省事,直接选最大的模型;“反正都能干,用 GPT-4 总不会错吧”。这种偷懒在前大模型时代不可能存在(因为没有万能模型),在大模型时代变成了默认选择。分诊台这件事,是大模型时代的产物。不是技术进步带来的副作用,而是技术进步逼出来的纪律。这条纪律,67-68 期两篇要把你讲明白。后来他们做了一件事——装了个分诊台。结果月账单从 12 万砍到 4.5 万,效果不降反升。今天这篇就讲:多模型路由到底是怎么把账单砍下来的,以及为什么说,多模型路由不是技术问题,是医生分诊。一、客户账单截图——12 万里有多少是浪费的先帮你把这 12 万掰开揉碎看一眼。那家法律 SaaS 当月调用 GPT-4 的总 token 数大约 8 亿(输入输出),按公开价 $10/1M token 算,折合人民币约 12 万。这是实打实的云厂商账单,不是估算。账单摆到桌上,CTO 第一反应是是不是被攻击了?是不是有爬虫在薅?查了一周,不是攻击,就是正常业务流量。问题出在所有请求都打 GPT-4。那这 8 亿 token 里都是些什么问题?他们拉了一份抽样分析,按问题复杂度分档:70% 是常识题——“合同日期怎么填”“违约金上限多少”“管辖法院怎么选”“试用期最长多久”。这一类问题,本地 7B 模型解得比 GPT-4 还稳。20% 是中等难度——条款比对、案例初步检索、格式生成、风险摘要。这一类问题,Qwen3.7-Plus 或 Claude Haiku 4.5 这种中等模型完全能解。只有 10% 是真疑难——跨多个法条的综合分析、复杂合同条款的风险评估、纠纷案件的多角度推演。这一类才真的需要 GPT-4 或 Claude Sonnet 4.5。10% 的疑难请求吃掉了 90% 的预算。听起来夸张吗?算一笔账你就懂了。假设这 10% 的疑难请求需要 GPT-4 这种专家号,平均每次请求消耗 1500 token,一个月 10 万次,就是 1.5 亿 token;剩下 70% 的常识题平均消耗 500 token,70 万次,就是 3.5 亿 token;20% 中等难度平均 800 token,20 万次,就是 1.6 亿 token。总共 8 亿 token。但云厂商计费不会按难度打折——所有 token 同价。结果就是 70% 的常识题消耗的 3.5 亿 token,跟 10% 的疑难请求消耗的 1.5 亿 token,享受着同样的高单价。这跟你去医院看病一个道理。医院不是所有病都让主任医师看。如果你发烧 37.5 度,先去社区诊所;如果社区诊所判断搞不定,再转诊到三甲医院;如果三甲医院都觉得棘手,才上专家号、ICU。AI 系统也一样。所有请求都打 GPT-4,等于让主任医师给你量体温。那家法律 SaaS 改造前后的账单对比是这样的:改造前:全部请求 GPT-4,月账单 12 万。改造后:70% 本地 7B / 20% Claude Haiku / 10% Claude Sonnet,月账单 4.5 万。节省幅度:62.5%。效果:用户 NPS 反而上升 5%——7B 对常识题答得更直接,没有 GPT-4 那种过度发挥的毛病。这不是个例。我们接着看。我再多说一句——为什么这个问题在大模型时代特别严重?因为在前大模型时代,AI 系统的成本主要是工程成本(数据标注、模型训练、推理服务器)。而进入大模型时代,成本的主要部分直接转嫁给了云厂商账单。不是工程优化决定成本,而是 token 调用的颗粒度决定成本。这个转变让AI 系统设计这件事变得更精细了。以前可以一把 GPT-3.5 打天下,现在 GPT-4 一调用就是 10 倍单价——你不再能凑合用一个大模型,必须认真设计调用方式。这就是为什么这一篇要讲分诊台——它不是新花样,是大模型时代 AI 系统的基本功。我再补充一个数据帮你感知这个转变的破坏力:某内容平台 2023 年用 GPT-3.5 时月成本 2 万,2024 年迁到 GPT-4 后,虽然效果好了,但月成本直接冲到 12 万——涨 6 倍。这就是模型升级带来的隐性成本。不是升级错了,而是不设计调用方式就升级,会让账单爆掉。二、反常识金句——GPT-4 不是越贵越好,70% 问题用 7B 解得更好听到这里你可能有点意外。明明 GPT-4 更聪明,为什么对常识题反而不如 7B?原因有三条。不是 GPT-4 不够好,而是 GPT-4 的好用错了地方——它的好是为疑难问题准备的,不是为常识问题准备的。把 GPT-4 用在常识题上,就像用一把瑞士军刀切苹果——工具是好工具,但你只用了其中一片刀片,其余功能全浪费。我帮你换个角度理解这个事——AI 模型跟员工一样,有专家和通才两种。不是专家比通才好,而是不同的事该派不同的人。你雇一个资深律师(成本高、专业深),让他每天帮你复印文件、整理档案——他也能做,但你亏了。他一小时成本 1000 块,做复印这种 50 块的事,净亏 950 块。你雇一个实习律师(成本低、基础活能干),让他每天复印文件、整理档案——他做得更专心、更快、更便宜,你赚了。同样的逻辑用在 AI 模型上:不是 GPT-4 比 7B 强,而是 70% 的事不需要 GPT-4。第一条:GPT-4 太聪明,会过度发挥。你问 GPT-4合同日期怎么填,它不会只告诉你看合同首部签署日期。它会给你列一、二、三、四,顺便提醒你注意合同生效条件、附条件生效、附期限生效、合同无效的五种情形、合同变更与转让的区别……你只是想知道日期怎么填,它却给你开了场法律讲座。7B 模型不会这样。它老老实实答你问的那一句。对常识题来说,直接比全面更值钱。不是 7B 模型笨,是它知道自己的边界在哪里。不是模型越笨越听话,是模型越知道边界越听话。这一点反常识,但你只要在生产环境跑一周用户日志,就会发现 GPT-4 的过度发挥是真实问题——用户问一句合同日期怎么填,它答 800 字,其中 700 字是用户不需要的。第二条:7B 对标准答案反而更稳定。常识题最大的特点是有标准答案——合同日期就那么几个地方可填,违约金上限就那么几种法定情形,管辖法院就那么几个法定连接点。这种题,答案空间小,7B 模型反而答得稳。GPT-4 在小答案空间上反而容易想多了——它会想是不是还有别的解法?要不要加个例外?,然后给你一个看似全面、实际跑偏的答案。我举个真实例子。某用户问民间借贷年利率上限多少,正确答案很简单——根据 2020 年最高法司法解释,上限是合同成立时一年期 LPR 的 4 倍。7B 模型的回答:“民间借贷年利率司法保护上限为合同成立时一年期 LPR 的 4 倍,超过部分的利息约定无效。”GPT-4 的回答(改造前的真实日志):“民间借贷的利率问题比较复杂,需要分情况讨论。第一种情况,如果双方约定了利息,应当遵循双方约定,但约定利率不能超过合同成立时一年期 LPR 的 4 倍;第二种情况,如果双方未约定利息,则视为不支付利息;此外,根据《民法典》第六百八十条……”用户只想知道一个数字,7B 给一句话,4B 给一段话。结果:7B 的回答用户满意度更高——因为更直接、更不绕弯。不是贵的模型效果一定好,是贵的模型对简单任务容易用力过猛,效果反而打折扣。第三条:延迟差三到五倍。GPT-4 平均响应 2-3 秒,本地 7B 平均 0.5-1 秒。延迟低了,用户体感AI 反应快,产品体验自然好。这跟去医院看病一样。你发烧去社区诊所,5 分钟看完、拿药、走人;你发烧去三甲医院,挂号 1 小时、候诊 2 小时、看诊 5 分钟、拿药 1 小时。社区诊所不是低配,是匹配。所以听我一句话:不是模型越大越好,是模型能力和你任务的匹配度越高越好。这一句反常识金句,是 67-68 期整个双篇的底色。先记住它,后面会反复回来用。我再帮你把这个匹配度展开讲一层。什么是匹配度?三个维度:能力匹配、速度匹配、成本匹配。能力匹配:模型能解的问题类型,跟你问题类型对上号。7B 解不了跨多个法条的综合分析,就别让它上;GPT-4 解合同日期怎么填是杀鸡用牛刀,就别浪费。速度匹配:模型响应时间,跟你产品 SLA 对上号。用户能等 2 秒,你就用 GPT-4;用户只能等 1 秒,你就上本地 7B。成本匹配:模型单价,跟你业务的预算对上号。To C 大流量产品(用户多、单次价值低),必须压成本;To B 高客单价产品(用户少、单次价值高),可以接受贵一点的模型。三个维度一起算,才能找到匹配度最高的模型。不是任何一个维度单独看,是三个维度综合权衡。不是 AI 工程问题,而是 AI 经济问题。我再补一个例子,帮你理解匹配度这件事在不同业务里的差别。客服问答机器人:大部分是 FAQ、订单查询、退换货流程这种标准问题。匹配度最高的模型是本地 7B 或 Claude Haiku。GPT-4 用在这里是浪费。法律文书起草助手:条款生成、风险摘要、合同审查,需要较强推理但不需要顶级能力。匹配度最高的是 Qwen3.7-Plus 或 Claude Sonnet 4.5。医疗咨询 AI:涉及诊断、用药、风险评估,容错率极低。匹配度最高的是 GPT-4 或 Claude Opus 4.5,而且必须有医生复核环节。教育辅导 AI:从小学算术到大学物理,跨度极大。匹配度最高的可能是动态路由——简单题用 7B,难题用 GPT-4。四种业务,四种最佳匹配模型。不是什么模型最好,而是什么业务用什么模型。这是 67-68 期双篇最终想让你带走的一个判断框架。下次做 AI 产品的时候,先想清楚你的业务是什么类型,再决定用什么模型。三、把AI 太贵剥成三个真需求你可能想问:道理我懂,可老板只会问为什么 AI 还这么贵,我怎么跟他说清楚?你得把模糊的AI 太贵剥成三个真需求,这样老板才能听懂你的方案不是砍预算,而是解决问题。老板的脑子里AI 太贵是四个字;你脑子里AI 太贵应该是三个数字。真需求一:单次成本要可控。不是少花钱,而是我能算清楚每花一块钱,能服务多少用户。按 67 期这家法律 SaaS 的数据,改造前每千次请求的成本是 120 元(全 GPT-4);改造后每千次请求成本是 45 元(70% 本地 7B 20% Claude Haiku 10% Claude Sonnet)。从 120 降到 45,单次成本下降 62.5%。这才是工程上可解释、可对比、可考核的数字。不是花钱多少决定 AI 系统贵不贵,是单次成本能不能算清楚决定 AI 系统贵不贵。老板最爱听的不是我们花了多少,是每次服务花了多少、为什么是这个数、能降到多少。把单次成本摊成一张表,老板立刻明白这不是砍预算,是把每笔账算明白。真需求二:效果不能降。不是贵好,而是合适好。省钱容易,降效果就完蛋了。改造后那家法律 SaaS 的客户满意度不仅没降,NPS 还上升 5%。原因是 7B 对常识题答得更直接,用户读起来更省事。这是个反直觉的事实。不是贵的模型效果一定好,是贵的模型对简单任务容易用力过猛,效果反而打折扣。为什么用户更喜欢 7B 的回答?因为 7B 给的答案是用户问题本身的答案,GPT-4 给的答案是AI 认为用户应该知道的更全面的东西。前者解决用户的当下问题,后者解决 AI 自己想象中的问题。不是 AI 越全面越好,是 AI 越懂用户当下问题越好。真需求三:延迟不能变长。GPT-4 平均 2-3 秒,本地 7B 平均 0.5-1 秒。改造后整体响应延迟不升反降,这是用户能直接感受到的。不是延迟快一点技术就牛,而是延迟慢一点用户就跑了。这是大部分产品在 AI 化时容易忽视的一点。我再给你一个延迟的真实影响数据:某电商 SaaS 客服 AI 改造前响应时间 2.5 秒,改造后 0.8 秒。结果用户平均对话轮次从 3 轮升到 5 轮(因为用户更愿意继续追问),客服满意度上升 18%。不是延迟只影响用户耐心,而是延迟直接影响用户行为。延迟这件事,在 AI 产品里有个隐藏指标叫用户等待容忍度——大部分用户能接受 2 秒以内的响应;超过 5 秒,流失率陡升。本地 7B 的延迟优势,不只是技术指标,是用户留不留得住的关键。不是延迟快一点技术就牛,是延迟慢一点用户就跑了。这是大部分产品在 AI 化时容易忽视的一点。把这三个真需求摆在桌上,老板才会明白:你做的不是AI 降本实验,是AI 系统分级诊疗改造。两件事听起来像,做起来差十万八千里。前者是省钱,后者是工程。我再帮你把这三个真需求翻译成老板能听懂的话,免得开会的时候各说各话。真需求一:单次成本要可控——“老板,以前我们花 12 块服务 100 个用户,改造后花 4 块服务 100 个用户,效果还更好。”真需求二:效果不能降——“老板,改造后用户满意度上升 5%,因为回答更直接、不啰嗦。”真需求三:延迟不能变长——“老板,改造后响应时间从 2.5 秒降到 0.8 秒,用户留得住。”这三句话讲完,老板基本就同意了。不是我们在做技术升级,而是我们在用工程方法把每笔账算明白。这是给老板汇报时最有用的语言。四、模型分诊台——三档分流,跟医院一模一样这一节是 67 期的核心,把模型分诊台这个比喻彻底立起来。医院是怎么分诊的?门口先有个分诊台,护士看一眼你的症状,把你分到三个档位:社区诊所:感冒、发烧、轻微外伤、慢病随访。社区医生就能看。三甲医院普通门诊:稍微复杂一点的病,需要专科医生看。三甲医院专家号 / ICU:疑难杂症、罕见病、复杂手术、危重抢救。社区诊所不丢人,三甲医院不浪费,ICU 不滥用——这就是分诊的本质。模型分诊台完全照抄这个逻辑,把模型按能力分成三档:档位医院比喻典型模型适用问题单价($/1M token)第一档社区诊所Llama-3.1-8B / Qwen2.5-7B(本地)、Claude Haiku 4.5常识题、FAQ、模板生成、简单对话0.02-0.25第二档三甲医院普通门诊Qwen3.7-Plus / GPT-5.4-mini / Claude Sonnet 4.5中等推理、文档总结、初步分析0.06-3第三档三甲医院专家号 / ICUGPT-5.4 / Claude Opus 4.5复杂推理、跨文档综合分析、风险评估5-15第一档 7B 本地模型:价格是 GPT-4 的 1/200。第二档 Claude Haiku 4.5:价格是 GPT-4 的 1/40。第三档 GPT-5.4:价格是基准,但只服务 10% 的疑难请求。这就是分诊台的核心逻辑——不是所有问题都要挂专家号,而是该挂什么号挂什么号。那家法律 SaaS 改造后的比例大概是 70% / 20% / 10%。70% 的请求去第一档,20% 去第二档,10% 去第三档。账单直接降 62.5%,效果不降反升。我帮你把这套账再算一遍。假设每月 100 万次请求:第一档 70 万次 × 500 token × $0.05/1M ≈ $17.5(约 125 元人民币,本地 GPU 摊销 电费另算)第二档 20 万次 × 800 token × $0.25/1M ≈ $40(约 280 元人民币)第三档 10 万次 × 1500 token × $5/1M ≈ $750(约 5250 元人民币)复杂度分类器 100 万次 × 50 token × $0.15/1M ≈ $7.5(约 53 元人民币)本地 GPU 摊销 电费每月约 2000 元人民币合计月成本约7700 元人民币——这就是分诊台上线后的真实账单。比改造前的 12 万降了 93.6%。反常识金句:分诊台不是医院最贵的设备,是医院不崩溃的关键。AI 系统同理。我特意把分诊台的比喻再展开一层。不是把病人分类,而是让对的病人去对的地方。医院如果没有分诊台,会发生什么?所有病人都往三甲医院挤,三甲医院挂不上号,病人怨声载道。真正需要专家号的病人反而排不上队,因为普通感冒占了专家号的位子。医生精力耗尽,医疗事故率上升。AI 系统一样。如果没有分诊台:所有请求都打 GPT-4,账单爆。真正需要 GPT-4 的疑难请求排不上队(被前面 70% 的常识题堵住了),响应延迟飙升。GPT-4 的过度发挥导致用户答案过长、啰嗦,满意度下降。不是分诊台多此一举,而是没分诊台才会出问题。我再讲一个具体场景。某医疗 SaaS 在改造前,所有用户问诊都打 GPT-4。结果遇到一个用户问我孩子发烧 37.8 度,该吃什么药?——这种问题应该让医生来答,不应该让 AI 来答。但产品设计没拦这一道,AI 直接给了用药建议。后来用户吃了 AI 建议的药,孩子过敏,医院投诉到平台。平台这才知道:“AI 不能直接给医疗建议”。但这件事不是AI 太贵那种账单问题,是AI 不分诊那种安全问题。不是分诊台只为省钱,而是分诊台同时防风险。医疗、金融、法律这种高风险场景,分诊台是把AI 越界挡在外面的第一道闸。我再帮你把这个比喻再往深里推一层。医院的分诊台不只是分个档,它还有两个隐藏作用:第一,分诊台是医院的数据采集点。每个病人经过分诊台,医院就知道今天发烧的有几个、外伤的有几个、心脏问题的有几个。下次进货(药品、医生排班),有据可依。AI 系统的分类器也一样——每个请求经过分类器,你就能看到今天常识题多少、中等题多少、疑难题多少。这数据是 AI 系统优化最值钱的东西。第二,分诊台是医院的资源调度点。分诊台决定把病人分到哪里,直接决定医生的工作负荷。AI 系统的路由策略也一样——它决定请求送到哪个模型,直接决定每个模型的工作负荷和成本。不是分诊台只是个分流工具,而是 AI 系统的运营仪表盘 资源调度器。五、模型路由不是排序,是分类 选择你可能觉得:模型路由不就是把模型按能力排个序,贵的放前面、便宜的放后面?错。模型路由不是排序,而是分类 选择。排序是线性的——大模型排第一、中模型排第二、小模型排第三。请求来了从前往后挑。但这样挑有个致命问题:大模型被默认选中,简单问题也被大模型接走。路由的核心动作是先分类,再选择。第一步:复杂度分类器。请求来了,先用一个轻量模型(比如 GPT-5.4-mini 或本地 7B)给这个请求打个复杂度分——简单、中等、复杂,或者直接给建议档位。这一步的成本极低——分类器只需要分析请求本身,不用生成完整答案。100 万次分类的总成本可能就几十块人民币。第二步:档位选择。根据复杂度分类的结果,把请求路由到对应档位的模型。第三步:可观测 回退。每个请求都要记录被分到哪个档位、实际响应质量、用户反馈。如果某类请求被频繁错分(比如看似简单实际复杂),分类器规则要调整。这三步里最值钱的是第一步——分类器。分类器不准,后面两步全废。那家法律 SaaS 用的是 GPT-5.4-mini 当分类器——便宜、响应快(平均 200 毫秒)、分类准确率 92%。剩下 8% 错分的请求靠用户反馈 异步复审打补丁。复杂度分类有三种常见策略:基于 prompt 关键词:正则匹配 关键词命中,比如包含对比“综合”“评估”复杂合同的请求直接打到第三档。基于上下文长度:上下文超过 8K 的请求默认升档——长上下文往往意味着复杂任务。基于意图识别:用一个小模型给请求分类,输出简单/中等/复杂三选一。实际工程里,这三种策略往往组合使用——先用关键词粗筛,再用上下文长度修正,最后用意图识别兜底。我举个具体的例子帮你想清楚这套逻辑怎么跑起来。某用户在系统里输入我的合同里写了违约金按日 5%,合法吗?关键词匹配:命中违约金“合法”“合法吗” → 粗筛标记可能涉及法规。上下文长度:查询本身 30 token,无历史 → 不触发长度升档。意图识别:分类器输出中等难度。路由决策:送到第二档(Claude Haiku 4.5 或 Qwen3.7-Plus)。响应生成:模型给出按日 5% 年化 1825%,超过 LPR 4 倍的部分无效的答案。用户反馈:用户点击有用或无用,反馈进入复审队列。这是 70% 的请求走的普通门诊路径。剩下 10% 走专家号路径,20% 走社区诊所路径。我再补充一个常被忽略的细节——分类器本身也需要可观测。所谓可观测,就是你能看到分类器每一次判断的结果。比如:这一秒分类器把多少请求判为简单、多少判为中等、多少判为复杂?哪些问题被频繁错分?是不是某类问题分类器一直搞不定?用户反馈答得不对的请求,有多少是被分到了不该去的档位?这些数据决定了你的分类器能不能持续优化。如果只看路由有没有生效,不看路由有没有分对,你就会陷入路由上线了但账单没降的尴尬。那家法律 SaaS 每周开一次路由复盘会,专门看分类器的错分样本,持续调优。三个月后分类准确率从 92% 升到 96%,账单进一步下降 8%。不是路由上线了就完事,而是路由上线了才开始精细化运营。反常识金句:路由错了比不路由更糟——把疑难问题送到社区诊所就完了,简单问题送给专家号只是浪费。我再讲一个具体的错路由案例,帮你加深印象。某医疗 SaaS 改造时,把分类器规则写得过于激进——只要请求里有病或药字,直接送第三档 GPT-4。结果某天用户问医生说让我每天吃两片药,什么意思?“,被分类器误判为医学难题”,送到 GPT-4。GPT-4 答了一段用药咨询需要专业医师指导,本 AI 无法替代医生……,用户直接懵了——他要的就是每天吃两片,早一片晚一片这么简单的答案。不是分类器越严格越好,而是分类器越准越好。这一例就是分类器过严的代价——用户问的是常识,被过度重视,反而答得不知所措。那家医疗 SaaS 后来调了分类器,加上短问句优先判常识这条规则,这种错路由率从 8% 降到 3%。我们再看下面那条金句。最后再强调一个细节:分类器的复杂度要低于被分类的请求。换句话说,不要用一个 13B 的模型去分类该用 7B 还是 13B的请求——分类成本比执行成本还高,得不偿失。实际工程里,分类器一般用中等偏下的模型(Claude Haiku 4.5 / GPT-5.4-mini / 本地轻量分类模型),它的工作不是回答问题,是判断这个问题该给谁回答。六、三个反常识金句,把分诊台刻进脑子里67 期讲到这里,核心心智已经立住了。我用三个反常识金句帮你再刻一遍。金句一:不是模型越大越好,是匹配度越高越好。GPT-4 不是越贵越好,70% 的问题用 7B 解得更好。这条金句前面已经讲过,这里再敲一遍,因为它是整个双篇的底色。这句话背后有个更深的事实:不是贵好,是合适好。贵是一种属性,合适是一种匹配。匹配度才是 AI 系统该追求的东西。金句二:大模型不是越大越好,合适才是好。7B 对 80% 的问题已足够。你不需要每件事都请主任医师,就像你发烧 37.5 度不需要去挂协和的专家号。这句话跟前面那句有微妙的区别:金句一强调匹配,金句二强调合适。匹配是技术层面的事,合适是业务层面的事。金句三:路由错了比不路由更糟。不路由,只是账单高;路由错了,疑难问题被送进社区诊所,用户拿到错误答案,产品口碑崩盘。路由的价值不在于分了,而是分得对。这条金句给所有想上路由系统的工程师提了个醒:别急着上线,先把分类器调对,再谈分流。把这三条金句刻进脑子里。下次老板问为什么不用 GPT-4,你就能直接答——不是 GPT-4 不好,而是这个问题不需要它。我再帮你把这三条金句汇总成一段可以打印贴工位上的版本:多模型路由的三个反常识:1. 不是模型越大越好,是匹配度越高越好。2. 大模型不是越大越好,是合适才是好。3. 路由错了比不路由更糟——分得对比分得巧更重要。打印出来,贴在工位上,每次讨论该不该用 GPT-4的时候看一眼。这三句话,会让你在 AI 系统的成本控制上少走一年弯路。最后,我帮你把 67 期的核心判断再总结成一句话:多模型路由不是技术问题,而是把对的请求送到对的模型。听起来简单,做起来工程量巨大。但一旦做对,你的 AI 系统就具备了分诊台的能力——简单问题快速便宜地解决,疑难问题准确专业地解决,用户满意,账单可控。这件事的工程纪律和落地步骤,就是 68 期要讲的全部内容。我们下篇见。最后给你留一个老板能立刻听懂的版本,方便你汇报用:67 期核心结论:AI 太贵的根因不是模型贵,而是用贵的模型解简单题。把 70% 的简单请求分流到 7B,20% 的中等请求分流到云端中等模型,10% 的疑难请求才上 GPT-4。账单降 60%-90%,效果不降反升。这件事的本质不是技术升级,是给 AI 系统装个分诊台。我们下篇见。七、我们下篇见——下篇卷袖子干活,把成本再砍一刀67 期到这里,业务心智讲完了。我帮你梳理一下 67 期的核心判断:多模型路由不是技术问题,是医生分诊——把简单问题分流到社区诊所(7B),把疑难杂症留给三甲医院(GPT-4),急诊才上 ICU(Claude Opus)。分诊台是医院不崩溃的关键,也是 AI 系统不超预算的关键。那 67 期讲的分诊台怎么落地?70% 的请求怎么真走到本地 7B 模型?云端 API 怎么配 fallback?这些就是 68 期要讲的事。下篇卷袖子干活——讲小模型本地化(Ollama / vLLM / llama.cpp)、提示词缓存(Anthropic Cache / OpenAI 自动缓存)、批处理(OpenAI Batch API)怎么把推理成本再砍一刀,从 4.5 万砍到 1.2 万,把 67 期讲的分诊台焊成可上线的工程纪律。我先剧透 68 期会讲到的三道闸:小模型本地化——怎么把 70% 的请求拦在自家服务器,从此这部分账单归零。提示词缓存——怎么让同一份 system prompt 只付一次钱,后续 5 分钟内所有请求共享缓存。批处理——怎么用 OpenAI Batch API 把夜间离线任务再砍一刀,50% 折扣,24 小时返回。这三道闸焊上去,账单从 4.5 万直接砍到 1.2 万,效果不降反升。不是分诊台装了就完事,而是分诊台 三道闸焊成一套,才能把成本真正压到地板价。我们下篇见。关于 ArchAIHarness这篇文章是「看懂 AI 与智能体」专栏的一部分,由ArchAIHarness持续输出。ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产,主张:架构师定义秩序,AI 在秩序中生长。人立法,AI 执行,体系审计。如果你也希望 AI 在明确的架构边界内协作,而不是在混沌中碰运气,欢迎到 GitHub 上看看我们在做什么:组织主页:github.com/ArchAIHarness — 了解完整理念与资产全景本专栏:zhuanlan-ai-and-agents— 所有文章的源码与发布记录实践指南:docs— 架构哲学、工程方法和落地指南开源工具:agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools工程样例:framework— DDD AI 协作的工程底座,展示如何在开发中融合 AIEngineered by Architects · Empowered by AI · Audited by Discipline在这里插入图片描述