蓝耘 MaaS：我把推理层重构成多模型路由，本以为能省 70%，实测只省了 9%——但学到了更值钱的三件事

蓝耘 MaaS我把推理层重构成多模型路由本以为能省 70%实测只省了 9%——但学到了更值钱的三件事上周一早上 8:47监控告警响了。我们的 AI 聊天服务 P99 延迟从 3 秒飙到 12 秒同时月度推理账单比预期高了3.2 倍。排查一圈后发现我们把所有流量——不管是「把用户反馈归类为 bug 还是建议」这种一句话任务还是「写一个 LRU Cache」这种代码生成——全灌给了同一个旗舰模型。它贵、它慢、它在简单任务上疯狂烧 reasoning token 收着看不见的「思考税」。于是我们决定重构在蓝耘 MaaS 的统一网关之上加一层多模型路由中间件按任务类型把流量分发给不同模型。我以为这能立刻砍掉 70% 成本。结果跑完基准测试成本只降了8.7%延迟反而涨了39%。但在这个过程中我学到了三件比省钱更值钱的事。第一幕病根不在代码在「单一模型信仰」那个周一的告警我们团队做的是一个内部 AI 助手类似客服 知识库问答接入的是蓝耘 MaaS 的 OpenAI 兼容接口https://maas-api.lanyun.net/v1。上线初期为了省事所有请求都走同一个模型——当时选的是deepseek-v4-pro旗舰版。理由很简单「旗舰模型最强一个模型打天下不用维护路由逻辑。」这个决策在日调用量 1000 次时没问题。但当量涨到日均 5 万次、且任务类型越来越杂分类、摘要、代码生成、长文档分析时问题爆发了问题表现根因账单爆炸月费是预期的 3.2x简单任务也在付「思考税」P99 延迟飙升3s → 12s旗舰模型排队 长生成阻塞短请求偶发 500高峰期错误率 2–3%单点故障无 fallback用 usage 字段做「CT 扫描」我之前写过一篇关于流式输出和 Token 陷阱的文章[《别只打印 content》](3-别只打印 content蓝耘元生代 MaaS 流式输出、思维链与 Token 陷阱实战.md)里面提到usage.completion_tokens_details.reasoning_tokens这个字段。当时只是当知识点记下来这次终于派上用场了。我在生产日志里加了一行每次 API 返回后把reasoning_tokens和completion_tokens的比例打出来。结果触目惊心taskclassify R/C0.93 # 归类一句话93% token 在想 tasksummarize R/C0.74 # 两句话摘要74% 在想 taskcode R/C0.79 # 写代码确实要想想但也太多了一个「归类 bug 还是建议」的任务模型花了 93% 的 completion token 在内部推理只有 7% 真正输出了内容。这就是「思考税」——你为它付了钱但它对你毫无价值。第二幕设计路由中间件架构核心思路很简单客户端请求 → API 网关 → Router(按 task_type 选模型) │ ┌─────────┼─────────┐ ▼ ▼ ▼ flash(快有思考) V3.2(便宜零税) kimi(均衡) │ │ │ ┌─────┴─────┐ │ ┌────┴────┐ ▼ ▼ ▼ ▼ ▼ 成本护栏 Fallback PromptCache 可观测四个横切关注点贯穿整个路由层成本护栏 / SLA单请求 max_tokens 上限 月度预算熔断故障转移 Fallback主模型失败自动切备模型Prompt Cache长 system prompt 统一前缀命中缓存打两折可观测 usage每条请求落 reasoning/cached tokens供成本看板核心代码可直接复制运行#!/usr/bin/env python3多模型路由中间件 · 生产级骨架importjson,os,timefromdataclassesimportdataclass,asdictfromopenaiimportOpenAI BASEhttps://maas-api.lanyun.net/v1# 路由表task_type - (主模型, 备模型)ROUTES{classify:(deepseek-v4-flash,/maas/deepseek-ai/DeepSeek-V3.2),summarize:(/maas/deepseek-ai/DeepSeek-V3.2,kimi-k2.5),code:(/maas/deepseek-ai/DeepSeek-V3.2,deepseek-v4-flash),reason:(deepseek-v4-flash,/maas/deepseek-ai/DeepSeek-V3.2),longctx:(/maas/deepseek-ai/DeepSeek-V3.2,kimi-k2.5),}dataclassclassCall:task:str;model:str;fallback:bool;ok:boolsec:float;completion:int;reasoning:int;cost:float;note:strdefask(client,model,text,max_tokens400):t0time.time()try:rclient.chat.completions.create(modelmodel,messages[{role:user,content:text}],max_tokensmax_tokens,temperature0.3,streamFalse,)exceptExceptionase:returnNone,time.time()-t0,str(e)[:60]ur.usage compgetattr(u,completion_tokens,0)or0ctdgetattr(u,completion_tokens_details,None)rtgetattr(ctd,reasoning_tokens,None)or0# 示例单价 ¥/M以控制台为准pin,pout(2,8)# deepseek-v4-flash 口径cost(getattr(u,prompt_tokens,0)*pincomp*pout)/1_000_000.0returnr.choices[0].message.contentor,time.time()-t0,None,comp,rt,costdefroute_one(client,task,text):primary,backupROUTES[task]content,sec,err,comp,rt,costask(client,primary,text)ifcontentisnotNone:returnCall(task,primary,False,True,round(sec,3),comp,rt,round(cost,5))# 故障转移content,sec2,err2,comp,rt,costask(client,backup,text)ifcontentisnotNone:returnCall(task,backup,True,True,round(sec2,3),comp,rt,round(cost,5),notef{primary}failed -{backup})returnCall(task,primary,False,False,round(sec(sec2or0),3),0,0,0.0,notefboth failed:{err}|{err2})defmain():clientOpenAI(api_keyos.getenv(LANYUN_API_KEY),base_urlBASE)tasks[(classify,这条反馈归类为 bug/建议/咨询/闲聊只回类别导出按钮点了没反应控制台报错 500。),(summarize,用两句话总结团队决定 Q3 上线多模型路由。),(code,写 Python LRU cache带注释。),(reason,为什么 P99 延迟比平均值更能代表 Agent 体验),(longctx,指出规范中最影响稳定性的三条(接口必须有超时。*30)),]calls[route_one(client,t,txt)fort,txtintasks]ok[cforcincallsifc.ok]print(f成功{len(ok)}/{len(calls)}| f总成本 ¥{sum(c.costforcinok):.5f}| fFallback{sum(1forcinokifc.fallback)}次)withopen(router_log.json,w)asf:json.dump([asdict(c)forcincalls],f,ensure_asciiFalse,indent2)if__name____main__:main()完整可运行版本含--force基线对比模式在 demo/maas_router.py。第三幕实跑数据——诚实的结果终端原始输出图maas_router.py实跑——上半部分是多模型路由结果下半部分是--force deepseek-v4-flash单模型基线对比。注意 code 任务走 V3.2 拖到 15 秒。数据拆解我把同 5 个任务跑了两次方式classifysummarizecodereasonlongctx合计均延路由(routed)flash ¥0.00057V3.2 ¥0.00035V3.2 ¥0.00323flash ¥0.00325V3.2 ¥0.00328¥0.010687.79s单模型(naive)flash ¥0.00042flash ¥0.00090flash ¥0.00324flash ¥0.00325flash ¥0.00391¥0.011725.59s差值¥0.00015-¥0.00055-¥0.00001-¥0.00063-8.7%39.3%三张图看清真相图每个任务的「单模型 vs 路由」成本对比¥/千次。红色全走 flashnaive绿色按类型路由routed。Y 轴标注了各任务在 flash 上的隐藏思考税占比。诚实结论summarize 和 longctx 在路由下更便宜V3.2 零思考税分别便宜 61% 和 16%classify 反而更贵了flash 本身就快V3.2 不适合超短任务code 和 reason 持平两个模型在这类任务上消耗差不多总体只省了 8.7%但平均延迟暴涨 39%V3.2 在长生成上太慢这不是失败。这是真实。第四幕比省钱更值钱的三件事如果我只看成本数字这次重构是「亏本生意」——省了不到一毛钱用户还觉得变慢了。但在复盘会上我总结了三个远比账单数字重要的收获1. 成本不是单变量路由是「成本 × 延迟 × 质量」的多目标优化之前我们认为「便宜模型 好」。但 V3.2 虽然单价低、零思考税在长文本生成上拖到 10–15 秒。对于对延迟敏感的场景实时聊天、联机补全慢 10 秒等于不可用。正确的做法不是「全部路由到最便宜的模型」而是建立一个多维度的模型画像表维度deepseek-v4-flashDeepSeek-V3.2kimi-k2.5qwen3.6-flash单价(¥/M out)88124思考税中(50–95%)0%0%极高(95%)短任务延迟快(~2s)快(~2s)最快(~2s)快(~0.6s)长生成延迟中等(~6–8s)慢(10–15s)中等中等(~5s)适用场景推理/分析摘要/分类/长文分类/摘要❌简单任务慎用有了这张表路由策略变成了场景匹配而不是「谁最便宜」# 改进后的路由加入延迟感知SMART_ROUTES{classify:(kimi-k2.5,DeepSeek-V3.2),# 最快 零税summarize:(DeepSeek-V3.2,kimi-k2.5),# 零税 够快code:(deepseek-v4-flash,kimi-k2.5),# 不要用 V3.2太慢reason:(deepseek-v4-flash,DeepSeek-V3.2),# 需要适度推理longctx:(kimi-k2.5,DeepSeek-V3.2),# 比 V3.2 快得多}教训永远不要只优化单一指标。在生产环境中成本、延迟、质量是一个三角 trade-off路由的本质是在这个三角里找到你的最优解。2. 思考税是隐形的——你必须主动测量才能看见在我们加上reasoning_tokens监控之前没有人知道「归类一条反馈」这种任务居然有 93% 的 token 在「空转」。因为它不报错它返回的内容看起来正常它只是悄悄地让你的账单膨胀 10 倍测量方法已验证可用# 每次 API 调用后立即采集usageresponse.usage compusage.completion_tokens ctdusage.completion_tokens_detailsor{}tax_ratio(ctd.get(reasoning_tokens,0)or0)/max(comp,1)iftax_ratio0.7:alert(f高思考税警告: task{task}tax{tax_ratio:.0%}model{model})把这个埋进你的 Prometheus / Grafana 看板按task_type × model聚合。一周后你会看到一张 heatmap告诉你哪些组合在烧冤枉钱。3. 真正的护城河不是「选对模型」而是「系统能扛住模型挂掉」在这次重构过程中我们还做了一个实验故意把主模型名写成错的测试 fallback 是否生效。# 把 primary 写成一个不存在的模型ROUTES[classify](nonexistent-model-xxx,deepseek-v4-flash)# 结果第一次调用 404 → 自动 fallback 到 flash → 用户无感在生产环境中模型抽风是常态上游更新导致临时 500我们在蓝耘上遇到过deepseek-v4-pro连续 500限流 429高峰期模型下架 404旧模型名失效没有 fallback 的系统每一次上游抖动都是一次线上事故。有 fallback 的系统上游抖动只是一条静默日志。另外Prompt Cache 也是护城河的一部分。虽然我们在上一篇文章中发现蓝耘 MaaS 大部分模型的缓存命中率是 0%详见 《思考税》文章 的缓存深坑章节但minimax-m3 是唯一命中的cached128。这说明缓存能力因模型而异路由中间件可以在选择模型时把「是否支持缓存」作为一个因子。蓝耘在这条链路上的角色坦白说这次重构能做成很大程度上依赖蓝耘 MaaS 的几个特性特性对路由中间件的价值统一网关 (/v1)一个 Base URL 接入所有模型族DeepSeek/Qwen/GLM/Kimi/MiniMax切换模型只需改字符串不改 SDKOpenAI 兼容直接用openaiPython SDK零适配成本Anthropic 端点(/anthropic)还能让 Claude Code 直连usage 字段透传reasoning_tokens、cached_tokens完整透传让成本归因成为可能模型广场同一个 key 能调几十个模型不需要逐个申请/配置可靠性我们在重构期间连续跑了上百次调用未遇到网关级 5xx个别模型 500 是上游问题被 fallback 兜住了特别是统一网关 OpenAI 兼容这两点让我们能在不改动任何业务代码的前提下只在中间件层加了一个 Router 就完成了重构。如果是自建多模型服务光是统一不同厂商的 API 格式就要花两周。结尾给同行者的三条建议如果你也在考虑做多模型路由或者正在为推理账单发愁这是我踩坑后的三条建议先测量再优化。不要凭感觉选模型。跑一遍maas_profiler.py代码在这里拿到每个模型在你真实任务上的reasoning_tax和density用数据说话。不要只看成本。建立「成本 × 延迟 × 质量」三维画像表。便宜的模型可能慢到你无法接受。Fallback 不是可选项。从第一天起就设计好降级路径。模型会挂、会限流、会下架——这不是如果而是什么时候。最后一句实话路由中间件不会立刻帮你省 70%。它会帮你建立一个健康的、可观测的、有弹性的推理层。这才是长期来看真正值钱的东西。