67 期那家法律 SaaS 把月账单从 12 万砍到 4.5 万的故事,讲完了。但那不是终点。CTO 复盘的时候,发现一个更扎心的事实:70% 的问题其实 7B 模型都能解。他在本地搭了个测试环境,拿 Qwen2.5-7B 一跑,效果跟云端中等模型几乎打平。于是他们做了 68 期这一篇要讲的事——再降一次。把 Llama-3.1-8B 跑在 vLLM 上做主力本地模型,加上 Anthropic Prompt Caching 把重复的 system prompt 缓存命中,加上 OpenAI Batch API 把夜间离线任务再砍一刀,最后账单从 4.5 万降到1.2 万。这一篇就讲清楚:多模型路由不是按大小排序,而是把对的病送到对的医院,五道闸焊死,效果不降,账单砍到 1/10。一、反差开场——从 12 万到 1.2 万的二次降本先把账本翻给你看。那家法律 SaaS 的三次降本路径是这样的:第 0 阶段(原始):全部请求打 GPT-4,月账单 12 万。第 1 阶段(67 期讲的分诊台):LiteLLM 路由 三档分流,月账单 4.5 万。节省 62.5%。第 2 阶段(68 期讲的工程纪律):本地 7B 主力 Prompt Caching Batch API,月账单 1.2 万。再省 73%。从 12 万到 1.2 万,账单砍到 1/10。这不是营销话术,是真账。后面第八节我会把这套账本摆给你看,每一行都拆得清清楚楚。关键不是用便宜模型,关键是把对的病送到对的医院。70% 的问题,本地 7B 解得比 GPT-4 还稳、还快、还便宜;20% 用云端中等模型;10% 才上专家号。分诊台不是装了就完事,分诊台后面还要有五道闸——复杂度分类器、模型路由、小模型本地化、提示词缓存、降级 fallback。这五道闸焊死,才能把分诊变成可上线的工程纪律。这一篇就讲这五道闸。我再帮你把二次降本这件事的内在逻辑展开——为什么分诊台装完还不够,还要再降一次?因为分诊台解决的是路由问题——请求送到对的模型。但分诊台没解决成本结构问题——就算送对了模型,云端中等模型还是贵(每月 4.5 万)。不是分诊台没效果,而是分诊台之后还有成本优化的空间。降本的第二次空间来自三件事:空间一:本地化——把云端中等模型的请求,进一步切到本地 7B。云端 0.25 美元/1M token → 本地 0.05 美元/1M token,价差 5 倍。空间二:缓存——同一份 system prompt 知识库,5 分钟内所有请求共享。Cache Read -90%,输入 token 直接砍掉九成。空间三:批处理——离线任务用 Batch API,50% 折扣,24 小时返回。这三件事的共同特征是不动业务逻辑、不动模型选型,只在工程层面把账单压下来。这才是 68 期的核心——不是更聪明地用 AI,而是更精细地用 AI。我再帮你展开 CTO 复盘时看到的那个扎心事实——他怎么就断定 70% 的问题 7B 能解?他做了三件事:第一件,跑了一周的对照实验。同一批用户请求,50% 打 GPT-4、50% 打本地 7B,让用户盲评(用户不知道哪个是哪个)。结果用户对 7B 的满意度比对 GPT-4 高 5%——因为 7B 答得更直接。第二件,拉了一份问题类型分布。把 100 万次请求分类,发现 70% 是信息查询 模板生成这种固定答案的问题,7B 完全能解;20% 是条款比对 文档总结这种中等推理,需要中等模型;只有 10% 是跨法条综合分析这种疑难。第三件,算了一笔账。如果把 70% 切到本地,本地 GPU 摊销 电费每月 2000 块(对比云端这部分原本花 8 万)。光这一刀就砍掉 7.8 万。不是省钱需要小模型,而是业务问题本身只需要小模型。这件事想清楚,后面的工程动作就是顺水推舟。二、第一道闸:复杂度分类器——别让大模型给简单问题量体温复杂度分类器是路由系统的鼻子。请求来了,它先闻一闻——这问题简单、中等、还是复杂?然后决定送到哪个档位。三种常见分类策略:策略一:基于 prompt 关键词的正则匹配。这是最便宜的方案,几乎零成本。提前维护一份关键词清单:简单问题关键词:“日期”“怎么填”“格式”“模板”“标准”“默认”——命中关键词直接送第一档。复杂问题关键词:“对比”“综合”“跨多份合同”“风险评估”“疑难”“特殊情形”——命中关键词直接送第三档。正则匹配的局限是容易被绕过——用户换个说法,关键词就不命中了。所以实际工程里,它只能当粗筛。策略二:基于上下文长度。上下文超过 8K 的请求默认升档——长上下文往往意味着复杂任务,用户塞了很多背景资料进来。这一招简单粗暴但很有效——7B 模型在 8K 上下文里跑得稳,再长就开始丢三落四。策略三:基于意图识别的小模型分类。用一个轻量模型(GPT-5.4-mini 或本地 7B 的 fast 版本)给请求打标签。输入用户的 query,输出简单/中等/复杂三选一。那家法律 SaaS 用的是 GPT-5.4-mini 当分类器——平均响应 200 毫秒,单次分类成本约 0.0003 元(每 1M token 0.15 美元)。100 万次分类,总成本不到 30 元。三种策略组合用——关键词粗筛 上下文长度修正 意图识别兜底。复杂度分类器是整个路由系统的命门。分类器不准,后面四道闸全废。我再讲一个真实案例帮你加深印象。某电商客服 SaaS 改造时,只用了关键词匹配(策略一)。结果某用户问我的快递能不能送货上门?“,被关键词快递”“上门命中,粗筛标记可能涉及物流”。再被意图识别判为中等,送到 Claude Sonnet 4.5。Claude Sonnet 答了一段 800 字的物流政策详解,用户只想知道能不能。最后用户给了差评:“AI 答非所问。”不是分类器不重要,而是分类器一错,后面所有响应都是错的起点。这件事在工程上必须严肃对待。我再帮你深入一层——分类器的准有两个维度:精确率(Precision)和召回率(Recall)。精确率:分类器判为复杂的请求里,真的是复杂的比例。召回率:所有真正的复杂请求里,被分类器挑出来的比例。理想情况下两个都要 95%,但实际工程里,大多数分类器精确率高、召回率低——它们擅长把明显简单的请求挑出去,但看似简单其实复杂的请求容易漏。为什么召回率低?因为看似简单是个非常主观的判断。用户问民间借贷利息多少,看起来简单(常识题),但如果用户的具体场景是超过 LPR 4 倍的部分是否一律无效——这就是疑难。不是分类器做不到 100%,而是看似简单本身就是个伪命题。所以工程上不追求分类器完美,而是追求错分率可监控、可降级。这就是 68 期第六节要讲的降级 Fallback——给分类器的错分一个兜底。我再补充一个分类器选型的经验——用什么样的模型当分类器,直接决定整套路由的成本。如果分类器本身太贵,等于用一个贵模型帮一堆便宜模型分类,反而把成本结构搞乱了。常见分类器选型:本地轻量模型(如 Qwen2.5-7B Q4 量化):成本 0,但需要自部署。Claude Haiku 4.5:便宜 ($0.25/1M token),响应快 (1-2 秒),分类质量高。GPT-5.4-mini:便宜 ($0.25/1M token),响应快 (200 毫秒),分类质量极高。那家法律 SaaS 选的是 GPT-5.4-mini——100 万次分类总成本 30 元,等于免费。不是分类器不能上贵的,而是分类器本身要够便宜,否则路由系统的成本结构不成立。分类器选型的经验值:分类器成本应该占整套路由系统总成本的 1% 以内。超过 5%,说明分类器太贵,该换了。三、第二道闸:模型路由策略——成本、质量、延迟的三角权衡分类器给出简单/中等/复杂的标签后,模型路由策略就要做决策了:送到哪个具体的模型?三种权衡维度:成本优先:能省就省,简单问题打死不送云端。质量优先:效果好为先,成本次之。延迟优先:响应快为先,用户体感第一。大部分生产环境是成本 延迟组合优先,质量兜底。具体策略:第一档(简单):Llama-3.1-8B 本地 / Qwen2.5-7B 本地 / Claude Haiku 4.5。响应 1 秒,成本 0.05 元/千次。第二档(中等):Qwen3.7-Plus / GPT-5.4-mini。响应 1-2 秒,成本 0.2-0.5 元/千次。第三档(复杂):GPT-5.4 / Claude Sonnet 4.5 / Claude Opus 4.5。响应 2-5 秒,成本 5-15 元/千次。反常识金句:不是路由策略越复杂越好,而是越准越好。那家法律 SaaS 一开始想做动态路由——根据用户反馈自动调整路由权重。结果三个月下来,效果还不如固定三档分流。动态路由听着性感,实际工程里很难调——用户反馈有滞后、模型版本会更新、季节性流量波动大。最后他们退回最简单的分类器 固定三档,效果反而最稳。不是动态路由不好,而是固定三档更适合生产环境。这是工程上的看起来 low,实际 best。我再帮你展开为什么动态路由在生产环境难调——三个原因:反馈滞后:用户点击满意/不满意是异步的,可能 1 分钟也可能 1 天。路由系统要根据这个反馈调权重,但反馈数据本身就是过时的。模型版本漂移:OpenAI / Anthropic 每个月都在更新模型,模型能力曲线在变。但路由权重是按上一版本调的,新版本可能答得更好但被路由跳过。季节性流量:促销季流量翻倍,日常流量平稳。同样一个分类器,在促销季可能错分率升高,因为请求类型分布变了。这三个原因叠加,动态路由就成了看似聪明但难以稳定的设计。那家法律 SaaS 最后选了固定三档 分类器可观测——分类器每周调一次,路由权重不变。不是不优化,而是优化要选对节奏。我再补充一个工程上的路由权重经验:简单档:本地 7B:80% 的请求走这里。基础事实查询、FAQ、模板生成。中等档:云端 7B-中模型:15% 的请求走这里。需要点推理但不需要顶级能力。复杂档:云端大模型:5% 的请求走这里。跨文档综合、风险评估、疑难杂症。这三个数字不是固定的,但80/15/5 是大多数 SaaS 业务的经验值。不是任意分档,而是按业务问题分布分档。如果你跑下来发现是 50/30/20,说明你的业务疑难请求偏多,可能要考虑升级到 13B 本地模型;如果你跑下来发现是 95/4/1,说明你的业务主要是 FAQ,可以考虑去掉第三档、专心优化前两档。不是分档越精细越好,而是分档匹配业务才最优。四、第三道闸:小模型本地化——把 70% 的请求拦在自家服务器这一道闸是 68 期的工程核心。本地化部署小模型,听起来高大上,其实有三件现成的工具可以直接用。4.1 Ollama——开发自测的瑞士军刀Ollama 是个人开发者最爱的本地模型工具。一行命令拉模型:ollama pull qwen2.5:7b一行命令起 REST API:ollama serve就完事了。Mac、Linux、Windows 都支持,自带 web 管理界面。优势:零配置,5 分钟跑起来。劣势:生产并发能力弱,单机 10 并发就吃力。适用场景:开发自测、内部工具、PoC 验证。那家法律 SaaS 的开发团队每人都跑 Ollama,本地测试不需要花云端 API 的钱。4.2 vLLM——生产环境的 24 倍吞吐提升vLLM 是中型 SaaS 的首选。核心卖点是PagedAttention 显存调度 连续批处理——这两项技术把 GPU 利用率从 20% 提到 70%,吞吐是 Ollama 的 24 倍(Hugging Face 2024 公开数据)。python-mvllm.entrypoints.openai.api_server\--modelmeta-llama/Llama-3.1-8B-Instruct\--max-num-seqs256\--gpu-memory-utilization0.9一行命令起 OpenAI 兼容 API,老代码不用改。优势:吞吐高、兼容 OpenAI 接口、易扩展。劣势:需要懂 GPU 调度、需要 A100/H100 这种中高端显卡。适用场景:中型 SaaS 月调用 100 万 token 以上的生产环境。4.3 llama.cpp——家用 NAS 的极简方案llama.cpp 是边缘部署的极简方案。支持 GGUF 量化格式,7B 模型可以塞进 6GB 显存,甚至纯 CPU 跑(M2 Mac mini 都能跑)。./llama-server-mLlama-3.1-8B-Instruct-Q4_K_M.gguf\--port8080\--host0.0.0.0优势:极低显存、纯 CPU 可跑、模型文件小(7B Q4 量化约 4.7GB)。劣势:无内置 web 服务、并发弱、需要自己包一层 API。适用场景:Mac mini / 家用 NAS / 边缘盒子 / 内部知识库问答。4.4 三件套怎么选开发自测:Ollama。零配置,5 分钟跑起来。中型生产:vLLM。吞吐是 Ollama 的 24 倍。家用 NAS / 边缘:llama.cpp GGUF 量化模型。混合架构:vLLM 跑主流量 Ollama 跑开发自测 llama.cpp 跑边缘兜底。那家法律 SaaS 最后用的是vLLM 跑主力 7B Ollama 跑开发测试。月账单主力流量这块基本归零——本地 GPU 摊销每月 2000 块,电费几百块,比起云端 4.5 万,直接砍到 1/20。反常识金句:不是本地模型省钱省出来的,而是分级诊疗分流出来的——把对的请求送到本地,本地才能发挥零边际成本的优势。我再展开为什么本地模型有零边际成本——这是经济学概念,不是营销话术。云端 API:边际成本 0。每多一个 token 调用,云厂商都按单价收费。无论你调用 100 万还是 1 亿,边际成本都是正数。本地 GPU:边际成本 ≈ 0(在 GPU 没跑满的前提下)。你买了一张 A100,不管跑 1 万次还是 100 万次,电费差异很小。一旦把 GPU 利用率从 20% 提到 70%,多跑的请求几乎不增加成本。这就是为什么本地化能把账单砍到 1/20——不是本地模型便宜,而是本地模型把成本结构从按量变成了按容量。按量:你用多少付多少,边际成本恒定。按容量:你买了多少容量,在这个容量内随便用,边际成本递减。前者适合流量波动大的业务,后者适合流量稳定的业务。SaaS 业务大多流量稳定,所以本地化很划算。不是本地化一定省钱,而是稳定流量业务本地化才省钱。五、第四道闸:提示词缓存——同一份 system prompt 只付一次钱68 期最容易被忽略的一道闸:Prompt Caching。什么是 Prompt Caching?长上下文场景下,system prompt 知识库摘要 历史对话经常超过 1 万 token。这些重复内容如果每次请求都重新计费,账单会爆。Prompt Caching 的思路是:同一份内容,5 分钟内的所有请求共享缓存——写一次的钱,被后续所有请求摊销。5.1 Anthropic Prompt CachingAnthropic 2024 年 9 月发布的官方缓存机制:Cache Write:首次写入,价格是输入 token 的25%(略贵一点,因为要存到 CDN)。Cache Read:命中缓存后读取,价格是输入 token 的-90%(便宜 10 倍)。举个例子:某法律 SaaS 的 system prompt 法条库摘要合计 8000 token。不开缓存:每请求按 8000 token 计输入费,1 万次请求 8000 万 token。开缓存:首次写入 25%(多付 2000 token 的钱),后续 9999 次按 90% 折扣读取 72000 token × 9999 ≈ 7.2 亿 token 当量。节省:超过 95%。Anthropic 官方建议:命中率低于 30% 不要上(浪费工程时间)。5.2 OpenAI 自动缓存OpenAI 2024 年 10 月也跟进了类似机制:超过 1024 token 的 prompt 自动缓存。命中后输入 token 价格 -50%。不需要手动加字段,服务端自动处理。OpenAI 自动缓存的命中率比 Anthropic 低一点(因为是自动判定),但用起来简单。5.3 自建 GPTCache如果模型服务商不提供缓存,或者你要在本地模型上实现类似效果,可以自建GPTCache(开源库)。GPTCache 的思路:把请求和回答的语义向量存到本地向量数据库(如 ChromaDB),新请求来了先做相似度检索,命中相似问题就直接返回缓存答案。反常识金句:不是提示词缓存越存越省,而是命中率高于 30% 才省。命中率低就是给云厂商捐款。那家法律 SaaS 的命中率经过一周调优后稳定在85%——因为他们的 system prompt 法条库基本是固定的,变的是用户问题。我再帮你展开为什么命中率 30% 是分水岭——这是个工程经验值,不是官方数字。命中率 30%:缓存几乎没用上,缓存写一次的钱 偶尔命中的折扣,反而比不开缓存更贵。这种情况直接关掉缓存。命中率 30-70%:能省一点,但工程复杂度上来了(要维护缓存失效、调 TTL)。适合有专门工程师的小团队。命中率 70%:省得明显,工程复杂度也值得承受。适合所有上规模的 SaaS。不是上了缓存就一定省,而是命中率达标才省。这件事在工程上必须先估算,再决定要不要上。我再帮你讲一个具体案例——某电商 SaaS 用了 OpenAI 自动缓存,结果账单没降反升。他们一开始不知道 OpenAI 自动缓存的命中条件是超过 1024 token。他们的 system prompt 只有 500 token,根本触发不了缓存。结果每月账单多了 5%——自动缓存本身不收费,但请求结构改变导致某些 prompt 触发了缓存边界,反而让一些简单 prompt 被强制走了长 prompt 路径。这件事是个反例,提醒我们:不是云厂商提供缓存就一定省钱,而是要看自己的 prompt 长度和请求模式。那家电商 SaaS 后来把 system prompt 扩到 1500 token(增加法务免责声明 公司介绍),立刻触发了 OpenAI 自动缓存,命中率 70%,账单下降 15%。不是缓存没用,而是要先看自己的请求模式匹不匹配。这件事在工程上是常识,但很多团队第一次上缓存都忘了这一步。我再补充一个工程经验——Prompt Caching 最适合长 system prompt 短用户问题的场景。长 system prompt:占大头(几千 token),且每次都一样。短用户问题:每次不同,但相对短(几十到几百 token)。这种场景的命中率天然高,因为 system prompt 是不变的,缓存命中后每次只算用户问题那部分。反例是短 system prompt 长用户问题——用户上传一份 1 万字合同让你审查,system prompt 只有 500 token。这种场景的命中率天然低,因为每次上传的合同都不一样,缓存几乎没机会命中。不是所有场景都适合缓存,而是长 prompt 短 query才最适合。我再补充一个 Prompt Caching 的工程套路——主动构造缓存场景。有时候你的请求模式本来不适合缓存,但你可以主动调整让它适合:把法务免责声明放在 system prompt 开头——加 200 token,系统 prompt 变成 700 token,触发 OpenAI 自动缓存。把公司介绍、产品 FAQ 放在 system prompt——加 500 token,大部分用户问题都会复用这些内容。用 LangChain 之类的框架封装 system prompt——把常用片段提到一个共享的 system prompt 里,所有请求都带上。这些主动构造缓存的技巧,能把命中率从 30% 拉到 70% 以上。不是缓存命中率只能靠运气,而是命中率可以通过 prompt 工程主动优化。六、第五道闸:降级 Fallback——社区诊所搞不定,转诊三甲医院最后一道闸是降级机制。什么是降级 Fallback?本地 7B 模型搞不定的请求,自动 fallback 到云端大模型。比如:本地 7B 在 3 秒内没返回(timeout) → 自动切到云端。本地 7B 输出的置信度低于阈值(可以用 logprobs 估算) → 自动切到云端。本地 7B 拒绝回答(“这个问题我不确定”) → 自动切到云端。降级的关键不是切,是**“切得无感”**——用户不应该感觉到刚才那个请求被打回了两个地方重做。工程上一般这样实现:本地优先:请求先打本地 7B,带 timeout(比如 3 秒)。降级触发:timeout 或置信度低 → 自动重试云端 API。日志埋点:每一次降级都记录为什么降级、降级到哪个模型、用户最终有没有接受答案。定期复盘:每周看一次降级率,降级率超过 20% 说明本地模型选得太小,该升级到 13B 或 14B。那家法律 SaaS 改造后的降级率稳定在8%——意味着 92% 的请求本地 7B 都能直接搞定,剩下 8% 才走云端。反常识金句:降级不是失败,而是兜底。社区诊所搞不定不丢人,该转诊就转诊。AI 系统也一样。我再补充一个细节——降级也要分档。降级不是本地不行就一步到位打 GPT-4,而是按级别递进:第一级降级:本地 7B → 云端 7B(如 Claude Haiku 4.5)。成本 5 倍,但效果接近。第二级降级:云端 7B → 云端中模型(如 Claude Sonnet 4.5)。成本 10 倍,效果更好。第三级降级:云端中模型 → 云端大模型(如 GPT-5.4)。成本 50 倍,疑难杂症。这三档降级让成本可控和效果兜底兼顾。不是降级一次到位,而是降级要分档。我再补充一个降级的反直觉事实——降级率不是越低越好。如果降级率一直低于 3%,说明你的本地模型选得太保守(可能用了 1.5B 而不是 7B)。看起来本地能搞定,其实用户拿到的答案质量不高,只是凑合能用。健康的降级率是 5%-15%——本地能搞定 85-95%,剩下 10-15% 该转诊就转诊。这才是分级诊疗的最佳平衡点。不是降级率越低越好,而是降级率反映本地模型的边界感。这个指标是路由系统健康度的核心信号,比任何技术指标都更说明问题。我再补充一个降级的陷阱——降级不能silent。所谓silent 降级,就是降级发生了,但用户不知道,日志也没记。这种降级会让产品出现莫名其妙答错的情况,排查极其困难。降级必须是loud——每次降级都要:日志埋点:记下为什么降级、降级到哪个模型、用户最终有没有接受答案。监控告警:降级率超过 20% 自动告警,提示可能本地模型选得太小。用户感知:有些降级可以告知用户(如为保证回答质量,正在调用更强的模型),有些不必告知(如本地超时切云端),看具体场景。不是降级一次成功就行,而是降级必须可观测、可监控、可调整。这是工程上的纪律,不是可选项。七、五层模型选型决策树——什么场景用什么模型把前面四道闸串起来,变成一张可决策的决策树。第一层:任务分类数据查询 / 简单生成 / FAQ →第一档(本地 7B)文档总结 / 模板生成 / 中等推理 →第二档(云端中等)复杂推理 / 跨文档综合 / 风险评估 →第三档(云端大模型)第二层:QPS 预估QPS 10 → 本地 Ollama 就够。QPS 10-100 → 本地 vLLM。QPS 100 → 本地 vLLM 云端 API 混合。第三层:延迟要求必须 1 秒 → 本地 7B 优先。可接受 2-3 秒 → 云端中等。可接受 5 秒 → 云端大模型。第四层:合规要求数据不能出网 → 本地 Ollama / vLLM / llama.cpp。数据可上云但要脱敏 → 云端 PII 脱敏中间件。数据可上云 → 云端大模型。第五层:成本预算月预算 1 万 → 全本地。月预算 1-10 万 → 本地主力 云端兜底。月预算 10 万 → 混合架构 动态路由。把五层串起来,就是一张什么场景用什么模型的决策树。我再帮你画一张更直观的图:┌─────────────────┐ │ 你的 AI 请求 │ └────────┬────────┘ │ ┌────────▼────────┐ │ 第一层:任务类型 │ └────────┬────────┘ │ ┌────────────────┼────────────────┐ ▼ ▼ ▼ 简单 FAQ 中等推理 复杂推理 (本地 7B) (云端中模型) (云端大模型) │ │ │ └──────┬─────────┴────────┬───────┘ ▼ ▼ QPS 100 QPS 100 (本地 Ollama) (vLLM 云端) │ │ └──────┬───────────┘ ▼ ┌──────────┐ │ 上线运行 │ └──────────┘每一层都是一个过滤点,把适合的请求留下,不适合的剥出去。不是一上来就拍脑袋选模型,而是五层过滤后自然落到最佳模型。我再帮你把五层决策树翻译成工程师上手 Checklist:任务类型确定了吗?是 FAQ / 中等推理 / 复杂推理?明确这一步,后续四层才有方向。QPS 预估算了吗?月调用 100 万次 vs 1 万次,选型完全不一样。延迟 SLA清楚吗?To C 产品用户等不了 5 秒,To B 内部工具可以等。合规要求明确了吗?金融/医疗/政企 数据不能出网,这一条最硬。成本预算卡好了吗?预算决定你能上多贵的模型,不要倒过来。五层 Checklist 全过了,选型自然浮出水面。不是凭感觉选模型,而是用五层 Checklist 选模型。我特意把合规要求放在第四层而不是第五层,因为合规是硬约束——满足不了,其他四层全废。某金融 SaaS 改造时,本来想上 GPT-4 当主力。结果合规审计说金融数据不能出网,一刀切下来,只能上本地 vLLM。最后他们的方案是本地 vLLM 7B 本地 vLLM 13B 双机部署,月度成本 8000 块,效果反而比云端 GPT-4 更稳定(因为数据不出网,合规好过关)。不是预算决定选型,而是合规决定选型,预算决定规模。这是金融/医疗/政企场景的常识。我再补充一个工程纪律的总结——五层决策树不是为了花最少的钱,而是为了在合规、能力、成本之间找到平衡。任何 AI 系统的设计,本质都是在回答三个问题:能不能用?合规、数据安全、伦理边界。好不好用?能力匹配、速度匹配、效果稳定。用得起吗?单次成本、月度预算、长期可持续。三个问题都有答案,系统就能上线;任何一个没答案,系统就不能上。不是技术决定 AI 系统,而是合规 能力 成本三方制衡决定 AI 系统。这是 68 期五层决策树背后更深一层的逻辑。八、真实成本对比表——同一业务 6 种部署方案的月度账单这一节把账本摆给你看。某法律 SaaS 月调用 100 万次,平均 800 token/次,业务总 token 量 8 亿/月。来看 6 种部署方案的成本:方案部署架构月成本(人民币)节省幅度效果A: 全 GPT-4100% GPT-4 云端12 万0%基准B: 三档分流(67 期)70% 本地 7B 20% Claude Haiku 10% Claude Sonnet4.5 万62.5%NPS 5%C: 本地主力 Prompt Caching(68 期)80% 本地 vLLM 7B 15% 云端中等 5% 云端大模型 全部开缓存2.0 万83%NPS 3%D: 本地主力 Batch API(68 期加强)80% 本地 vLLM 10% Cloud Batch 10% 云端中等1.2 万90%NPS 2%E: 全本地 量化100% 本地 vLLM 7B INT4 量化0.5 万96%NPS -8%(部分复杂请求答不准)F: 全 Claude Opus 4.5100% Claude Opus 4.5 云端36 万-200%效果最好但成本翻 3 倍关键观察:方案 D(本地主力 Batch API)是性价比拐点——账单砍到 1/10,效果几乎不降。方案 E(全本地)看着省钱,但8% 的复杂请求答错,这 8% 用户投诉率会爆。方案 F(全 Claude Opus)效果最好,但成本翻 3 倍,中小 SaaS 根本扛不住。那家法律 SaaS 最后选的是方案 D——本地主力 Batch API Prompt Caching 的组合拳。反常识金句:不是成本越低越好,而是性价比拐点最优。我再展开为什么方案 D 是性价比拐点——它满足了三个条件:成本下降足够大:从 12 万到 1.2 万,降 90%,符合砍到 1/10的目标。效果几乎不降:NPS 只下降 3%,在用户感知范围内(5% 以内用户基本无感)。工程复杂度可控:vLLM LiteLLM Anthropic Cache Batch API,都是现成工具,不需要自研。三个条件同时满足的方案,在工程上就是最佳性价比拐点。不是最便宜,也不是最好,而是综合最优。我再帮你做一张性价比拐点的对比图,更直观:成本(万/月) 36 ┤ ● 方案 F (全 Opus) │ 12 ┤● 方案 A (全 GPT-4) ← 起点 │ 4.5 ┤ ● 方案 B (67 期分诊台) │ 2.0 ┤ ● 方案 C ( Prompt Cache) │ 1.2 ┤ ● 方案 D ( Batch API) ← 拐点 │ 0.5 ┤ ● 方案 E (全本地) │ 0 └───────────────────────────────────── 效果差 ←────────────→ 效果好拐点就在方案 D——成本降了 90%,效果几乎不降。再往方案 E 走,成本还能省,但效果开始崩。不是越往右越好,而是拐点是最优。这是工程上的知止——知道在哪里停下来。九、金句收束——多模型路由是把对的病送到对的医院68 期到这里,五道闸讲完了。我帮你梳理一下 68 期的核心判断:多模型路由不是按大小排序,而是把对的病送到对的医院。第一道闸(复杂度分类器):把请求分成简单、中等、复杂三档。第二道闸(模型路由策略):三档对应三档模型,固定分类最稳定。第三道闸(小模型本地化):vLLM Ollama llama.cpp 三件套,本地 7B 拦下 70%-80% 的请求。第四道闸(提示词缓存):命中率 30% 才上,Anthropic 缓存命中读 -90%、OpenAI 自动缓存 -50%。第五道闸(降级 Fallback):本地搞不定自动转诊云端,8% 降级率是正常水位。五道闸焊死,账单从 12 万砍到 1.2 万,效果不降反升。这就是 68 期要讲的全部。我再帮你做一个60 秒回顾,把五道闸压缩成你能记住的版本:第 1 道:复杂度分类器——把请求分简单/中等/复杂三档。关键词粗筛 上下文长度修正 意图识别兜底。第 2 道:模型路由策略——三档对应三档模型,固定分类最稳定。成本 延迟优先,质量兜底。第 3 道:小模型本地化——vLLM Ollama llama.cpp 三件套,本地 7B 拦下 70-80% 请求,边际成本趋近于零。第 4 道:提示词缓存——长 prompt 短 query 命中率最高,Anthropic Cache 命中读 -90%,OpenAI 自动缓存 -50%。第 5 道:降级 Fallback——分档降级(loud 降级 日志埋点 监控告警),8% 降级率是正常水位。把这五道闸背下来,你的 AI 系统就有了分诊台 五道闸的完整工程纪律。不是五道闸缺一不可,而是五道闸组合起来才有奇效。我再帮你做最后一段工程价值复盘,把 67-68 双篇连起来看:67 期讲的分诊台是 业务心智——把对的请求送到对的模型。68 期讲的五道闸是 工程纪律——把分诊台焊成可上线的系统。心智不落地,只是 PPT;工程不回到心智,只是堆代码。不是心智比工程重要,也不是工程比心智重要,而是心智 工程焊在一起,才能真正把成本压到地板价。那家法律 SaaS 的 CTO 后来跟我说了一句话,我特别认同:“我们做完这件事之后才明白,多模型路由不是技术问题,而是把对的病送到对的医院——这句话是 67 期说的。但 68 期做的事是把这家’医院’建成,让它真的能接诊、真的能转诊、真的能不超预算。”心智和工程,缺一不可。我再帮你列一份68 期行动清单,让读者看完就能上手:[ ] 跑一周对照实验:同一批请求 50% 打 GPT-4、50% 打本地 7B,盲评用户满意度。[ ] 拉一份问题类型分布:看你的业务里常识题 / 中等题 / 疑难题各占多少。[ ] 选一个本地模型起点:Ollama 装 Qwen2.5-7B,跑通本地推理。[ ] 装一个 LiteLLM:做最简单的一档路由(全部本地 vs 全部云端)。[ ] 开 Anthropic Cache:把 system prompt 提到 1024 token 以上,触发缓存。[ ] 跑三档路由:简单/中等/复杂 三档分流,降级率监控。[ ] 每周复盘一次:看分类器错分样本,持续优化。[ ] 季度评估账单:看是不是真的省了,效果是不是真的稳。这八步走完,你就有了完整的分诊台 五道闸。从 12 万到 1.2 万,不是神话,是工程纪律的必然结果。最后,我把 68 期全文的核心判断压成一句话,刻在脑子里:多模型路由不是技术问题,而是把对的病送到对的医院。67 期告诉你为什么要这么做,68 期告诉你怎么做。两篇一起读,就是一套完整的AI 系统降本方法论:先装分诊台(业务心智),再焊五道闸(工程纪律),账单从 12 万砍到 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