实测蓝耘元生代:从三模型对比到会自动降级的LLM智能路由平台

接入一个大模型并不难,真正困难的是:当项目同时面对代码、推理、知识问答和内容写作等不同任务时,应该选择哪个模型?如果模型质量相近,响应速度和Token消耗又该如何取舍?更现实的问题是,当首选模型超时、返回空内容或出现异常时,系统能否自动切换到其他可用模型,而不是直接把错误交给用户?围绕这些问题,我基于蓝耘元生代MaaS搭建了一个可在本机运行的多模型评测与智能路由平台maas-router-lab.项目使用统一接口并发调用deepseek-v4-flash、qwen3.7-plus和minimax-m3,再由独立的qwen3.7-max裁判模型,从正确性、完整性、相关性和清晰度四个维度进行评分.同时,系统会记录每次调用的延迟、Token、运行状态和评分结果,并结合历史数据完成可解释的模型选择与失败自动降级.本文不是简单修改 API 地址的接入示例,而是一次包含项目创建、蓝耘模型接入、前后端开发、PostgreSQL 数据存储、三模型对比、LLM 自动评测、Benchmark 排行榜和智能路由的完整实测.整个过程中共完成首轮 24 次候选模型调用,并真实遇到了慢响应、无效内容、隐藏推理标签和首选模型调用失败等问题.接下来,我将说明这个项目如何从零搭建,以及这些问题最终是怎样被发现和解决的.

一、为什么不再把所有任务都交给一个模型

接入大模型很容易,真正上线却会马上遇到三个问题：哪个模型更适合代码、知识或写作?质量相近时,延迟和Token消耗怎么取舍?首选模型偶发超时或返回异常时,业务是否只能一起失败?

我因此做了一个可在本机运行的maas-router-lab：同一道题并发调用三个候选模型,再用一个独立模型按固定量表评分,把回答、延迟、Token 和得分写进 PostgreSQL;有了历史数据后,路由器按任务类别计算综合分,选择模型并在失败时自动降级.

这不是只改base_url的"接入演示".完整链路包括前后端、数据库、8 题 Benchmark、结构化裁判、可解释路由、失败兜底和可视化页面.模型入口使用蓝耘元生代 MaaS.蓝耘模型广场提供统一入口和多家模型的调用名称,本次实测所用模型均从控制台核对后选取.

最终选型如下：

这里的"独立"只表示调用角色和模型名不同,不代表评分绝对客观.LLM-as-a-Judge 仍可能有偏好,所以页面始终展示四项原始分、理由和样本数,不把总分包装成普遍能力排名.

图 1：项目首屏同时展示三个候选模型、独立裁判模型和 55/25/20 路由权重,下方可直接进入模型对比、智能路由与排行榜.

首屏不是装饰性大屏,而是把项目的关键约束先交代清楚：候选模型数量为3,裁判模型只有1个,路由依据是质量、延迟和 Token.首次打开时结果区显示"尚无对比记录",只有真正提交问题后才渲染模型回答与评分,避免用预置数据伪装实测结果.

二、蓝耘在项目中到底承担什么角色

蓝耘负责的是"统一模型入口",本地项目负责"比较、评测、路由和展示".这条边界很重要：MaaS 不替我决定业务评分标准,本地代码也不重复建设模型推理服务.蓝耘公开页面说明其接口采用OpenAI兼容方式,并聚合多家主流模型.

实际请求时,三个候选模型只改变model,鉴权头、消息结构和响应解析保持一致：

POST https://maas-api.lanyun.net/v1/chat/completions Authorization: Bearer <仅存在于后端进程的 API Key> Content-Type: application/json

图 2：蓝耘元生代模型广场,实测前先核对准确调用名而不是凭印象填写.

这比在代码里分别维护三套厂商地址和错误格式更省事,但"统一协议"并不等于"行为完全一致".实测中,有的模型响应很快,有的会长时间等待,还有模型把<think>推理标签混进正文.统一入口解决连接问题,兼容性和业务兜底仍要由应用层完成.

API Key 的处理采用最小暴露原则：临时 Key 备注为maas-router-lab,没有写入.env、源码、前端、数据库、日志或文章;启动后端时通过静默输入注入当前进程.公开的/api/health只返回api_key_configured: true/false,永远不返回 Key 内容.

图 3：控制台只展示平台已脱敏的 Key、使用状态和项目备注.

三、架构与一次请求的完整流向

技术栈是FastAPI + HTTPX + SQLAlchemy AsyncIO + PostgreSQL + Vue3 + Element Plus + ECharts.蓝耘兼容 OpenAI 消息协议;项目选择在 HTTPX 层封装调用,是为了把连接超时、429、鉴权失败、余额不足、模型名错误和无效响应映射成稳定的本地错误码,并精确记录每次端到端延迟.

数据表不保存 Key,只保存五类可审计信息：题目与类别、模型调用名、成功或失败状态、延迟与 Token、裁判四项分和理由.前端既能看总榜,也能切换到coding、reasoning、knowledge、writing,避免把完全不同的任务混成一个总分.

四、在PyCharm中从零跑起来

本机环境是 macOS、Python 3.9.6、PostgreSQL 16 和 Node.js.先创建虚拟环境并升级 pip：

图 4：PyCharm 项目树包含 FastAPI 后端、23 项测试、实测证据、Vue3 组件和图片目录;开发时应阅读.py、.ts与.vue源文件,生成的.js文件不是核心展示对象.

cdbackend python3-mvenv .venv .venv/bin/python-mpipinstall--upgradepip .venv/bin/python-mpipinstall-e'.[test]'

再用 Docker Compose 启动数据库.实测库和测试库必须分开,后文会解释原因：

cd..dockercompose up-dpostgresdockercomposeexecpostgres createdb-Urouter_lab router_lab_testdockercomposeps

图 5：Docker Compose 启动 PostgreSQL 后,容器状态为healthy,本机仅通过127.0.0.1:54329映射数据库端口.

真实配置只进入当前 PyCharm 终端进程：

cdbackendexportDATABASE_URL='postgresql+asyncpg://router_lab:router_lab_local@127.0.0.1:54329/router_lab'exportLANYUN_BASE_URL='https://maas-api.lanyun.net/v1'exportLANYUN_CANDIDATE_MODELS='deepseek-v4-flash,qwen3.7-plus,minimax-m3'exportLANYUN_JUDGE_MODEL='qwen3.7-max'exportLANYUN_TIMEOUT_SECONDS='45'exportLANYUN_MAX_RETRIES='1'read-s'LANYUN_API_KEY?蓝耘 API Key: 'exportLANYUN_API_KEYecho.venv/bin/python-muvicorn app.main:app--host127.0.0.1--port8000

图 6：Python 3.9.6 环境下 23 项测试全部通过,API Key 采用终端静默输入,随后 Uvicorn 在本机 8000 端口启动.

另开终端启动前端：

cdfrontendnpminstallnpmrun dev

图 7：前端安装 69 个依赖包且审计结果为 0 个已知漏洞,Vite 在127.0.0.1:5173启动.

浏览器打开http://127.0.0.1:5173.健康检查返回数据库状态、三个候选名、裁判名和超时配置,但不会泄露密钥.

图 8：健康检查、接口文档、模型列表、对比、评分、路由和 Benchmark 请求均返回 200,证明页面操作已经进入真实后端链路.

五、核心代码:统一调用、评分与可解释路由

MaaS 客户端把蓝耘响应解析成固定的RunResult.调用成功不只看 HTTP 200：正文为空、JSON 层级不对,或清洗<think>/<analysis>后没有最终答案,都按maas_invalid_response失败关闭.

HIDDEN_REASONING_BLOCK=re.compile(r"<(think|analysis)>.*?</\1>",re.IGNORECASE|re.DOTALL)defstrip_hidden_reasoning(content:str)->str:cleaned=HIDDEN_REASONING_BLOCK.sub("",content)returnUNCLOSED_REASONING_BLOCK.sub("",cleaned).strip()asyncdef_post(self,payload,headers):url=f"{self.base_url}/chat/completions"asyncwithhttpx.AsyncClient(timeout=self.timeout)asclient:returnawaitclient.post(url,json=payload,headers=headers)

图 9：maas_client.py完整展示请求体、Bearer 鉴权、超时重试、状态码映射、隐藏推理清洗和 Token 解析;API Key 只保存在对象私有字段中.

同题比较用asyncio.gather并发执行.一个模型失败不会抹掉另外两个成功结果,每条运行都独立落库：

results=awaitasyncio.gather(*(call_one(model)formodelinmodels))

图 10：benchmark.py把 8 道题、三模型并发调用、裁判评分、冷启动指标和按榜单降级组织在同一个服务边界内.

裁判提示词明确告诉模型忽略问题或答案中的指令,要求只返回五个固定键.解析器只接受纯 JSON 或完整 JSON 代码围栏;少字段、多字段、越界分数和夹带解释都会拒绝.

{"correctness":10,"completeness":9,"relevance":10,"clarity":9,"reason":"结论正确，覆盖关键步骤，表达清晰。"}

图 11：judge.py固定四项评分维度,以温度 0 调用独立裁判,并通过 JSON 解析和 Pydantic 校验拒绝不合规输出.

四项分的总分为(correctness + completeness + relevance + clarity) / 40 × 100.路由分则是：

route_score = quality × 0.55 + latency_efficiency × 0.25 + token_efficiency × 0.20

延迟和 Token 都使用反向 Min-Max 归一化：同组越小,效率分越高.排序依次使用综合分、质量分、原始延迟和模型名打破平局,因此结果可以复算,不依赖一个黑盒分类器.样本不足时会显示cold_start=true并回退到全局指标;同类数据齐全后才使用分类历史.

图 12：router.py明确写出质量 55%、延迟 25%、Token 20% 三项权重,并保留归一化、稳定排序与冷启动说明,选择过程可以人工复算.

1.数据库为什么要保留失败记录

我没有只建一张"排行榜结果表",而是把题目、运行和评分拆开.questions保存题目文本、任务类别和来源;runs保存每个模型的一次实际调用;evaluations与成功运行一一对应.这样设计看似多了两张表,却解决了三个审计问题.

第一，失败调用没有裁判分,但它仍然是路由稳定性的重要证据.如果把失败行过滤掉,MiniMax 的质量均值看起来可能不错,系统却不知道它曾返回空内容.

第二，同一道题的三个模型共享question_id,前端能准确并排展示,而不是靠文本相等猜测它们是否属于同一轮.

第三，裁判规则改变后可以追加新的评测批次,不需要重新支付候选模型的生成费用.

延迟记录在模型请求外层,用单调时钟计算,包含网络和平台排队时间,更接近用户实际等待;Token 直接取兼容响应的usage.如果平台没有返回Token,字段保持null,不根据字符串长度伪造.错误信息也经过本地映射：鉴权、余额、限流、超时、模型不可用和响应异常使用不同错误码,但不会把上游响应中的 Key、请求头或账户信息写进日志.

API 只保留七个业务入口，前端没有直连蓝耘：

这个边界还有安全收益：浏览器开发者工具里只能看到本地 API,请求蓝耘所需的 Bearer Key 从未下发到 Vue.即使前端代码和构建产物全部公开,也无法从中恢复凭证.

2.Benchmark为什么不用一堆随手问题

测试集故意保持小而可解释,每类只有两题.coding覆盖可变默认参数和 LRU 数据结构,既测语言细节也测系统设计;reasoning覆盖9球称重和可用性分钟数,答案可以手工验算;knowledge选择 ACID 与 Kubernetes 请求链路,要求概念之间有清楚边界;writing要求维护通知和 API 空状态文案,检查约束遵循而不只是文采.

每道题还带一组reference_points,例如 LRU 题要求出现哈希表、双向链表、容量淘汰和并发边界.裁判看得到这些要点,候选模型看不到,因此候选回答不会为了迎合评分表机械复述.参考点不是标准答案全文,它只降低"裁判凭感觉打分"的自由度.

执行顺序也经过取舍：同一道题的三个候选并发,三条裁判请求同样并发;不同题目按顺序处理.完全串行会让一次评测等待太久,24个请求全部同时发出又容易触发限流,并且难以在预算接近上限时中止.当前策略让峰值并发保持在3,数据库仍按题目形成清晰批次.

为了避免一次短暂 429 直接丢失样本,客户端只对限流、连接错误和部分服务端错误执行有限指数退避;鉴权失败、余额不足、模型名错误不重试,因为重复请求无法修复配置问题.实测阶段把单次超时设为 45 秒、重试次数设为 1,既给长回答留出空间,也不允许一个模型把整轮拖上几分钟.

3.如何看待裁判给出的100分

9 球问题三家模型都答对"两次",裁判也都给了100分.这里的100只说明答案覆盖了这道题的参考点,并在正确、完整、相关、清晰四个维度没有明显缺陷.它不代表模型数学能力达到满分,更不能跨题目与公开 Benchmark 的百分制直接比较.

为减少明显偏差,项目做了四层约束：裁判模型不出现在候选列表;温度固定为0;输出必须通过 Pydantic 的整数范围和字段白名单;原始四项分、理由、模型名和样本数全部保留.对于业务高风险题目,还应增加人工抽查、盲化模型名、交换回答顺序，并用第二个裁判检查一致性.

路由阶段使用分类均值而不是某一道题的最高分,也不把失败当成零分混进质量均值.失败率应该成为独立的可靠性指标;当前版本通过运行状态和自动降级实际利用了失败信息,下一版则应把近 24 小时成功率直接加入公式.这样可以避免一个质量很高但近期持续异常的模型仍被频繁选为首选.

六、真实结果:24次候选调用,不把失败藏起来

Benchmark 包含 8 道题,每类 2 道：Python 可变默认参数与 LRU、9 球称重与可用性计算、ACID 与 Kubernetes、维护通知与空状态文案.三个模型共执行 24 次候选调用,再由qwen3.7-max评每条成功回答.

结果是 23 次成功、1 次失败、23 条结构化评分.失败来自minimax-m3的空状态文案题：蓝耘返回内容缺失或格式异常,系统记录maas_invalid_response，没有用空字符串冒充成功.

这组数据只代表首轮固定题集、提示词、平台路由状态和采样参数.它能帮助这个项目做下一次选择,不能推出"某模型永远更强".为了确认页面不是只对内置题生效,我后来又在 PyCharm 中分别提交知识、编程、推理和写作四个简单问题.以下属于追加的复现,数据会继续写入同一个 PostgreSQL,因此不与上表的首轮 24 次证据混为一谈.

知识类问题要求解释 Kubernetes 中 Deployment、Service、Ingress 的职责与外部请求链路.qwen3.7-plus获得 100 分但等待 26.11 秒；deepseek-v4-flash为 97.5 分、7.79 秒;minimax-m3因请求链路不完整得到 75 分.这个样本很直观地说明,质量、速度与篇幅往往不能只看一个维度.

图 13：知识类实测中三个模型均成功返回,但独立裁判根据职责边界和请求链路完整度给出不同分数.

编程类问题是"找出列表中出现次数最多的元素,并在并列时返回最小值".三个模型都使用计数结构完成要求,裁判均给出 100 分;延迟分别为 7.64 秒、20.45 秒和 5.15 秒.答案质量相同时,延迟和 Token 就成为更有区分度的路由依据.

图 14：编程类实测同时展示完整代码、时间复杂度、端到端延迟、Token 用量和四项裁判评分.

推理类问题只做5 - 2 + 1的苹果数量计算.三家都得到正确答案 4 和 100 分,但输出长度从 221 Token 到 611 Token、等待时间从 3.02 秒到 9.93 秒不等.简单题尤其适合观察模型是否用过多篇幅解释显然结论.

图 15：三个模型都答对简单推理题,页面仍保留延迟和 Token 差异,而不是只显示相同的满分.

写作类问题限制在 100 字以内,并必须突出“智能问答”和“个性化学习”.三条回答都满足硬约束并得到 100 分,但deepseek-v4-flash只使用 114 Token、约 2.79 秒完成,qwen3.7-plus则使用 1302 Token、约 21.58 秒.可见最终短文相近时,生成过程的消耗仍可能差很多.

图 16：写作类实测把字数约束、两个必含卖点、最终文案与裁判理由放在同一屏中,便于核对约束遵循情况.

追加问题和再次运行评测后,页面中的排行榜会实时重新聚合全部成功记录,因此截图中的样本数已经增长到 16、17 和 15,不再等于首轮表格的 8、8 和 7.累计榜单中deepseek-v4-flash的质量均值为 96.41、延迟中位数约 6.20 秒;这个变化证明榜单来自数据库实时计算,而不是写死的演示数字.为了保证可复核性，首轮 24 条明细仍单独保存在evidence/run-details.json.

图 17：累计排行榜公开质量均值、延迟中位数、平均 Token 和有效样本数;追加测试后指标与样本数会随数据库记录更新.

本次调用过程没有触发余额不足错误,控制台余额也未出现 0.01 元精度下的可见变化.但计费明细可能延迟,因此我不把它写成“零成本”.

七、最有价值的不是满分,而是真实故障

1.模型广场可见,不等于当前链路适合批量评测

最初计划使用kimi-k3.它在模型广场可见,但两次独立短探针都超过20秒,原并发请求也长时间未完成.继续强行使用会让 8 题 Benchmark 被单个慢响应拖住,因此换成约 1.24 秒返回最小探针的minimax-m3,同时把glm-5留作可用备选.

这个过程说明模型选择不能只看名称和介绍.先做低成本探针,再运行完整题集;为外部调用设置超时、有限重试和部分成功保存,才是可重复的工程流程.

2.首选模型可能在下一次调用立即失败

代码类历史数据让minimax-m3获得 89.86 的最高路由分,deepseek-v4-flash为 83.27.但第一次路由调用中,首选返回无效内容.程序直接把失败交给用户,这与“智能路由”的目标不符.

修复后,系统按已排序候选逐个尝试：首选失败就调用第二名;全部失败才返回最后一个诊断结果.首轮受控验证约 9.80 秒、838 Token,完整摘要保存在证据 JSON 中.后来在 PyCharm 再次运行同一个代码任务时,页面仍明确显示“首选minimax-m3调用失败,已按榜单顺序降级到deepseek-v4-flash”,这次约 13.17 秒、553 Token 获得可用答案.两次耗时不同属于真实网络与模型服务波动,但降级决策一致.

图 18：首选minimax-m3得分最高却返回异常,系统自动调用第二名deepseek-v4-flash;首选分数、降级原因和最终代码答案全部可见.

3. HTTP200里也可能没有可展示的最终答案

一次minimax-m3调用返回了完整<think>…</think>推理块,却没有最终正文.如果只检查状态码,前端会把内部推理过程展示给用户.统一客户端现在先清除完整或未闭合的think/analysis标签;清洗后为空就判为无效响应,并进入自动降级.这个规则有两条回归测试：保留标签后的最终答案,以及拒绝只有推理块的响应.

4.测试库和实测库必须物理隔离

早期conftest.py在没有指定TEST_DATABASE_URL时回退到实测库.Repository 测试会执行drop_all(),结果把刚跑完的榜单清掉.真实调用结果仍在本次进程的证据对象中,最终原样恢复到 PostgreSQL;随后默认测试库改为router_lab_test，README 增加一次性建库命令.

这比"测试通过"本身更值得记录：测试代码也是会改数据的代码,不能因为环境在本机就降低隔离标准.

八、为什么选择蓝耘,而不是把几家API手工拼起来

这次蓝耘承担了三个实际作用：一个 Key 和一个接口连接多家模型;模型广场提供可核对的调用名;控制台保留 Key 与用量管理入口.项目因此可以把精力集中在评测和路由,而不是为每家厂商复制鉴权、请求结构和基础接入代码.

我不会据这一次小样本断言蓝耘在所有维度都优于其他平台.更准确的结论是：它与"多模型评测 + 路由"这个项目高度匹配,统一协议显著缩短了接入路径;同时，超时、空内容、思考标签、计费延迟等现实问题依旧存在,应用层必须可观测、可降级.

九、测试、边界与下一步

最终本机验证结果：后端23 passed；前端vue-tsc类型检查通过;Vite 生产构建通过.构建产物中 JavaScript 单包约 747 KB,Vite 给出超过 500 KB 的非阻塞警告.当前是本地展示项目,下一步应按路由懒加载 ECharts 和页面模块,而不是为了消除警告盲目拆依赖.

项目目前仍有四个明确边界：题集只有 8 道,不能代表所有业务;裁判只有一个模型,适合加入人工复核或双裁判一致性;路由权重是人为设定的 55/25/20,生产环境应按 SLA 和成本调整;当前按单机顺序运行题目,大规模评测应引入任务队列、并发上限和预算熔断.

这套结果也给出了一个比"选出冠军"更实用的判断方式：模型榜单不是静态采购表,而是当前业务流量的运行画像.题目类型、提示词长度、输出约束和网络状态变化后,排名都可能变化.因此,线上路由不应永久固化某个模型,而应定期滚动评测,并把最近成功率、超时率和成本作为独立指标.历史数据需要保留题集版本与时间窗口,避免把半年前的低延迟成绩继续用于今天的选择.

部署到团队环境时,还应把 API Key 迁入密钥管理服务,只允许后端工作负载读取;数据库账号按读写职责拆分;前端接口加鉴权、限流和请求大小上限.评测题如果来自真实用户,还要先脱敏再入库,并规定原始回答的保存期限.本文为了展示路由闭环保留了完整回答,但生产系统应按最小化原则决定是否长期存储.

如果要把它继续做成生产服务,我会优先增加：价格表与真实人民币成本、按错误类型设置不同退避策略、模型健康度滑动窗口、路由前的预算上限、评测数据版本号,以及一条"首选和降级模型都失败"的告警链路.

十、参考资料

1: 蓝耘元生代：模型广场

2: 蓝耘元生代：企业级大模型统一网关与调度平台

敬请期待下一篇文章内容

人与人之间最大的差距,很多时候不是能力的差距,而是注意力分配方式的差距.每个人每天都拥有24小时,但大多数人会把时间平均分散在各种事情上:工作、娱乐、社交、情绪消耗以及短期满足,他们在不断消耗时间,却很少让时间产生复利.而真正想改变命运的人,会主动选择一个长期方向,把自己的时间、精力、学习、实践和资源持续投入其中.当一个人能够几年甚至十几年持续聚焦在同一个领域,他积累的不只是知识,而是一套独特的认知体系、经验优势和资源网络.世界上的高手,往往不是因为他们拥有更多时间,而是因为他们让有限的时间产生了无限的积累.真正的竞争,本质上不是谁更忙,而是谁能够把自己的注意力长期集中在一个有价值的方向上,让时间从消耗品变成资产.