我给自己写了一个 mini OpenRouter基于蓝耘 MaaS 的多模型路由网关实战一、为什么需要自己的网关前几篇我把蓝耘 MaaS 的 API 已经摸熟了——45 个模型、OpenAI 兼容协议、统一 Key 调用。但真要在生产环境用起来会很快撞上几个工程问题该用哪个模型蓝耘有 25 个对话模型qwen3.6-flash 便宜但能力一般glm-5.3 强但贵。让每个业务开发自己挑结果肯定是全部用最贵的。模型挂了怎么办虽然蓝耘 SLA 不错但任何单一模型都有限流、抖动、临时不可用的可能。直接调裸 API一旦失败业务就 500。成本到底花在哪月底账单总消耗 100 万 token但哪个业务线、哪个模型、哪个用户花的算不清。业界的标准答案是AI Gateway——OpenRouter、Portkey、One-API 这类产品干的就是这事。但它们要么走 SaaS 订阅多一层 vendor lock-in、要么需要自己部署 K8s小团队玩不起。我的方案蓝耘本身已经是统一上游我只需要在它前面再加一层薄薄的智能路由 容错 计费。用 Python 标准库写了 200 行跑通全部功能。二、架构设计整个网关只有 4 个核心模块全部跑在调用方进程内无独立部署模块职责实现Router按规则选模型一组 lambda 规则从上到下匹配Failover失败自动切换每个模型配一条备胎链RateLimiter控制并发asyncio.Semaphore(5)MeteringToken 级成本核算按模型定价表精确到分对外只暴露一个方法gw.call(prompt)业务方完全不用关心下面是哪个模型在干活。三、核心代码精华版完整代码 200 行这里只贴最关键的三段模型注册表 路由规则“配置即代码”MODEL_REGISTRY{qwen3.6-flash:{price_in:0.001,price_out:0.005,tier:cheap},deepseek-v4-flash:{price_in:0.001,price_out:0.002,tier:mid},glm-5.3:{price_in:0.005,price_out:0.020,tier:premium},}ROUTING_RULES[(lambdap:len(p)100,glm-5.3),# 长 prompt(lambdap:代码inpordebuginp.lower(),deepseek-v4-flash),# 代码类(lambdap:len(p)50,qwen3.6-flash),# 短问答]FALLBACK_CHAIN{qwen3.6-flash:[deepseek-v4-flash,glm-5.3],deepseek-v4-flash:[qwen3.6-flash,glm-5.3],glm-5.3:[deepseek-v4-flash,qwen3.6-flash],}带容错的主调用入口asyncdefcall(self,prompt:str,request_id:str)-CallRecord:primaryself.route(prompt)models_to_try[primary]FALLBACK_CHAIN.get(primary,[])foridx,modelinenumerate(models_to_try):recordawaitself._try_call(model,prompt,request_id,fallback_frommodels_to_try[idx-1]ifidx0elseNone)ifrecord.ok:ifidx0:self.stats.failovers1returnrecordreturnrecord# 全部失败并发安全的 HTTP 调用asyncio urllibasyncdef_try_call(self,model,prompt,rid,fallback_fromNone):asyncwithself.sem:# 信号量限流最多 5 并发t0time.time()loopasyncio.get_event_loop()dawaitloop.run_in_executor(None,self._http_post,body)# urllib 是同步的扔进 executor 不阻塞事件循环...注意几个工程细节run_in_executor把同步的 urllib 包装成异步避免引入 httpx/aiohttp 依赖asyncio.Semaphore控制并发上限防止打爆上游每次调用记录CallRecorddataclass便于后续审计/计费四、实测场景场景 1路由策略——三种 prompt 各走各的模型我设计了三种典型业务 prompt让网关自动选择模型实测结果Prompt字符数路由到耗时成本“你好”2qwen3.6-flash9.59s¥0.001600“帮我 debug…”20deepseek-v4-flash8.88s¥0.000696撰写 5000 字报告…×3177glm-5.312.95s¥0.010571最便宜的 qwen3.6-flash 一次只要 0.16 分钱最贵的 glm-5.3 一次 1 分钱——价格差 6.6 倍。如果业务不区分场景全用 glm-5.3一天 1 万次调用就是 ¥105而合理路由后只要 ¥30 左右省 70%。场景 2故障转移——主模型挂了自动切备胎最考验网关能力的场景。我故意调一个不存在的模型not-exist-model-xyz看输出✗ 第 1 次尝试 [not-exist-model-xyz] HTTP 404 ✓ 第 2 次尝试 [qwen3.6-flash] 成功 6.74s ¥0.001771第一次 404 立刻返回不到 100ms 就触发了备胎切换业务方收到的是成功响应完全无感知网关记录了这次 failoverfailovers: 1后续可以告警这种容错对生产环境至关重要——故障转移不是模型挂了更常见的是限流、超时、单条请求触发了上游 bug。蓝耘返回的错误码很规范HTTP 404、HTTP 402、HTTP 429等让容错逻辑可以写得非常干净。场景 3并发压测——10 个并发打满光看单次延迟没意义得看并发承载。发了 10 个并发请求用信号量限制最多 5 个同时在飞实测数据指标数值成功率10/10100%总耗时25.19s平均延迟12.10sP5012.32sP9514.87s最大延迟14.87sQPS0.40总成本¥0.043793几个观察零失败——蓝耘在 5 并发下完全稳定P95 - P50 只差 2.5 秒——延迟分布很平没有长尾QPS 0.4 不算高——这是推理型大模型的常态对比 GPT-4 同级10 次调用成本不到 5 分钱——便宜到可以忽略如果要更高 QPS可以开大Semaphore或者在网关上做请求队列 批量提交。场景 4综合业务模拟 成本分析最后模拟一天的真实流量覆盖 8 种业务场景客服、代码助手、内容创作、闲聊、Review、文档总结、快速问答、故障演示终端报表一目了然总调用: 8 总成本: ¥0.069227 故障转移: 1 次 模型 调用数 平均延迟 累计成本 -------------------------------------------------------------------------- qwen3.6-flash 5 10.92s ¥0.055959 deepseek-v4-flash 2 8.64s ¥0.001311 glm-5.3 1 13.17s ¥0.011957成本占比可视化qwen3.6-flash 80.8% ██████████████████████████ glm-5.3 17.3% █████ deepseek-v4-flash 1.9%这就是 Metering 模块的价值——一眼看出 80% 的成本花在 qwen3.6-flash 上因为它被调用最多glm-5.3 虽然贵但只被路由了一次所以总成本可控。如果想再优化下一步可以给每个业务线打 tag按业务线统计成本做预算熔断——某个业务当天超 ¥10 自动降级到便宜模型把 records 落库到 SQLite/PG用 Grafana 画实时大盘五、关键工程经验这次实测下来对蓝耘 MaaS 的平台能力有几个直接判断优点OpenAI 协议兼容度极高——我的网关代码可以无缝切到 OpenAI/DeepSeek 官方只需要换 base_url key模型间切换无差异——qwen/deepseek/glm 三个模型用同一份代码调message 结构、usage 字段完全一致错误码规范——404模型不存在、402余额不足、429限流让容错逻辑能精确编程Token 计量精准——每个响应都带usage.prompt_tokens/completion_tokens分账零误差45 个模型统一入口——意味着我的 FALLBACK_CHAIN 可以写得很激进反正备胎有的是踩过的坑不同模型延迟差异大qwen3.6-flash 平均 10sdeepseek-v4-flash 8sglm-5.3 13s——路由策略也得考虑延迟不能只看价格max_tokens不能给太小推理型模型 reasoning 也占 quota给 200 会返回空 content上一篇踩过stream failover 组合复杂流式响应一旦开始输出就没法切备胎了所以生产环境建议先 streamfalse 失败再 failoverstreamtrue 不重试Token 单位是元/千 token 不是 “元/百万”算成本时千万别搞错数量级六、这套网关的价值把这次实验放到生产语境下算笔账假设一个中型 AI 应用日调用量50,000 次如果全用最贵的 glm-5.350,000 × ¥0.012 ¥600/天 ¥18,000/月用 mini-gateway 智能路由80% 走便宜的 qwen 15% 走 deepseek 5% 走 glm40,000 × ¥0.0016 7,500 × ¥0.0007 2,500 × ¥0.012 ¥64 ¥5.25 ¥30 ¥99/天 ¥2,970/月每月省 ¥15,000省 83%而这套网关代码只有 200 行跑在业务进程内零额外基础设施成本。总结回到最初的问题中小团队如何低成本用上多模型我的答案是分两步选一个统一 MaaS 上游——蓝耘这种一个 Key 调 45 个模型的平台刚好填补这个空白省掉逐一对接 DeepSeek/通义/Kimi 的工程成本在前面加一层薄网关——用 200 行 Python 解决路由、容错、计费这三个工程问题比引入 OpenRouter/One-API 这种重型方案轻得多大模型时代的工程竞争力不在于你调了哪个模型而在于你能不能用最低的边际成本把模型的能力稳定地交付给业务。这次用蓝耘 MaaS 200 行 Python 搭出来的 mini-gateway是我目前看到的最小可行方案。
我给自己写了一个 mini OpenRouter基于蓝耘 MaaS 的多模型路由网关实战一、为什么需要自己的网关前几篇我把蓝耘 MaaS 的 API 已经摸熟了——45 个模型、OpenAI 兼容协议、统一 Key 调用。但真要在生产环境用起来会很快撞上几个工程问题该用哪个模型蓝耘有 25 个对话模型qwen3.6-flash 便宜但能力一般glm-5.3 强但贵。让每个业务开发自己挑结果肯定是全部用最贵的。模型挂了怎么办虽然蓝耘 SLA 不错但任何单一模型都有限流、抖动、临时不可用的可能。直接调裸 API一旦失败业务就 500。成本到底花在哪月底账单总消耗 100 万 token但哪个业务线、哪个模型、哪个用户花的算不清。业界的标准答案是AI Gateway——OpenRouter、Portkey、One-API 这类产品干的就是这事。但它们要么走 SaaS 订阅多一层 vendor lock-in、要么需要自己部署 K8s小团队玩不起。我的方案蓝耘本身已经是统一上游我只需要在它前面再加一层薄薄的智能路由 容错 计费。用 Python 标准库写了 200 行跑通全部功能。二、架构设计整个网关只有 4 个核心模块全部跑在调用方进程内无独立部署模块职责实现Router按规则选模型一组 lambda 规则从上到下匹配Failover失败自动切换每个模型配一条备胎链RateLimiter控制并发asyncio.Semaphore(5)MeteringToken 级成本核算按模型定价表精确到分对外只暴露一个方法gw.call(prompt)业务方完全不用关心下面是哪个模型在干活。三、核心代码精华版完整代码 200 行这里只贴最关键的三段模型注册表 路由规则“配置即代码”MODEL_REGISTRY{qwen3.6-flash:{price_in:0.001,price_out:0.005,tier:cheap},deepseek-v4-flash:{price_in:0.001,price_out:0.002,tier:mid},glm-5.3:{price_in:0.005,price_out:0.020,tier:premium},}ROUTING_RULES[(lambdap:len(p)100,glm-5.3),# 长 prompt(lambdap:代码inpordebuginp.lower(),deepseek-v4-flash),# 代码类(lambdap:len(p)50,qwen3.6-flash),# 短问答]FALLBACK_CHAIN{qwen3.6-flash:[deepseek-v4-flash,glm-5.3],deepseek-v4-flash:[qwen3.6-flash,glm-5.3],glm-5.3:[deepseek-v4-flash,qwen3.6-flash],}带容错的主调用入口asyncdefcall(self,prompt:str,request_id:str)-CallRecord:primaryself.route(prompt)models_to_try[primary]FALLBACK_CHAIN.get(primary,[])foridx,modelinenumerate(models_to_try):recordawaitself._try_call(model,prompt,request_id,fallback_frommodels_to_try[idx-1]ifidx0elseNone)ifrecord.ok:ifidx0:self.stats.failovers1returnrecordreturnrecord# 全部失败并发安全的 HTTP 调用asyncio urllibasyncdef_try_call(self,model,prompt,rid,fallback_fromNone):asyncwithself.sem:# 信号量限流最多 5 并发t0time.time()loopasyncio.get_event_loop()dawaitloop.run_in_executor(None,self._http_post,body)# urllib 是同步的扔进 executor 不阻塞事件循环...注意几个工程细节run_in_executor把同步的 urllib 包装成异步避免引入 httpx/aiohttp 依赖asyncio.Semaphore控制并发上限防止打爆上游每次调用记录CallRecorddataclass便于后续审计/计费四、实测场景场景 1路由策略——三种 prompt 各走各的模型我设计了三种典型业务 prompt让网关自动选择模型实测结果Prompt字符数路由到耗时成本“你好”2qwen3.6-flash9.59s¥0.001600“帮我 debug…”20deepseek-v4-flash8.88s¥0.000696撰写 5000 字报告…×3177glm-5.312.95s¥0.010571最便宜的 qwen3.6-flash 一次只要 0.16 分钱最贵的 glm-5.3 一次 1 分钱——价格差 6.6 倍。如果业务不区分场景全用 glm-5.3一天 1 万次调用就是 ¥105而合理路由后只要 ¥30 左右省 70%。场景 2故障转移——主模型挂了自动切备胎最考验网关能力的场景。我故意调一个不存在的模型not-exist-model-xyz看输出✗ 第 1 次尝试 [not-exist-model-xyz] HTTP 404 ✓ 第 2 次尝试 [qwen3.6-flash] 成功 6.74s ¥0.001771第一次 404 立刻返回不到 100ms 就触发了备胎切换业务方收到的是成功响应完全无感知网关记录了这次 failoverfailovers: 1后续可以告警这种容错对生产环境至关重要——故障转移不是模型挂了更常见的是限流、超时、单条请求触发了上游 bug。蓝耘返回的错误码很规范HTTP 404、HTTP 402、HTTP 429等让容错逻辑可以写得非常干净。场景 3并发压测——10 个并发打满光看单次延迟没意义得看并发承载。发了 10 个并发请求用信号量限制最多 5 个同时在飞实测数据指标数值成功率10/10100%总耗时25.19s平均延迟12.10sP5012.32sP9514.87s最大延迟14.87sQPS0.40总成本¥0.043793几个观察零失败——蓝耘在 5 并发下完全稳定P95 - P50 只差 2.5 秒——延迟分布很平没有长尾QPS 0.4 不算高——这是推理型大模型的常态对比 GPT-4 同级10 次调用成本不到 5 分钱——便宜到可以忽略如果要更高 QPS可以开大Semaphore或者在网关上做请求队列 批量提交。场景 4综合业务模拟 成本分析最后模拟一天的真实流量覆盖 8 种业务场景客服、代码助手、内容创作、闲聊、Review、文档总结、快速问答、故障演示终端报表一目了然总调用: 8 总成本: ¥0.069227 故障转移: 1 次 模型 调用数 平均延迟 累计成本 -------------------------------------------------------------------------- qwen3.6-flash 5 10.92s ¥0.055959 deepseek-v4-flash 2 8.64s ¥0.001311 glm-5.3 1 13.17s ¥0.011957成本占比可视化qwen3.6-flash 80.8% ██████████████████████████ glm-5.3 17.3% █████ deepseek-v4-flash 1.9%这就是 Metering 模块的价值——一眼看出 80% 的成本花在 qwen3.6-flash 上因为它被调用最多glm-5.3 虽然贵但只被路由了一次所以总成本可控。如果想再优化下一步可以给每个业务线打 tag按业务线统计成本做预算熔断——某个业务当天超 ¥10 自动降级到便宜模型把 records 落库到 SQLite/PG用 Grafana 画实时大盘五、关键工程经验这次实测下来对蓝耘 MaaS 的平台能力有几个直接判断优点OpenAI 协议兼容度极高——我的网关代码可以无缝切到 OpenAI/DeepSeek 官方只需要换 base_url key模型间切换无差异——qwen/deepseek/glm 三个模型用同一份代码调message 结构、usage 字段完全一致错误码规范——404模型不存在、402余额不足、429限流让容错逻辑能精确编程Token 计量精准——每个响应都带usage.prompt_tokens/completion_tokens分账零误差45 个模型统一入口——意味着我的 FALLBACK_CHAIN 可以写得很激进反正备胎有的是踩过的坑不同模型延迟差异大qwen3.6-flash 平均 10sdeepseek-v4-flash 8sglm-5.3 13s——路由策略也得考虑延迟不能只看价格max_tokens不能给太小推理型模型 reasoning 也占 quota给 200 会返回空 content上一篇踩过stream failover 组合复杂流式响应一旦开始输出就没法切备胎了所以生产环境建议先 streamfalse 失败再 failoverstreamtrue 不重试Token 单位是元/千 token 不是 “元/百万”算成本时千万别搞错数量级六、这套网关的价值把这次实验放到生产语境下算笔账假设一个中型 AI 应用日调用量50,000 次如果全用最贵的 glm-5.350,000 × ¥0.012 ¥600/天 ¥18,000/月用 mini-gateway 智能路由80% 走便宜的 qwen 15% 走 deepseek 5% 走 glm40,000 × ¥0.0016 7,500 × ¥0.0007 2,500 × ¥0.012 ¥64 ¥5.25 ¥30 ¥99/天 ¥2,970/月每月省 ¥15,000省 83%而这套网关代码只有 200 行跑在业务进程内零额外基础设施成本。总结回到最初的问题中小团队如何低成本用上多模型我的答案是分两步选一个统一 MaaS 上游——蓝耘这种一个 Key 调 45 个模型的平台刚好填补这个空白省掉逐一对接 DeepSeek/通义/Kimi 的工程成本在前面加一层薄网关——用 200 行 Python 解决路由、容错、计费这三个工程问题比引入 OpenRouter/One-API 这种重型方案轻得多大模型时代的工程竞争力不在于你调了哪个模型而在于你能不能用最低的边际成本把模型的能力稳定地交付给业务。这次用蓝耘 MaaS 200 行 Python 搭出来的 mini-gateway是我目前看到的最小可行方案。
