1. 从单模型硬扛到多模型调度我为什么折腾这套网关去年下半年我手上有个内容生成类的项目一开始图省事所有请求都往同一个大模型上怼。刚开始量小感觉还行延迟能接受成本也没太在意。但到了日请求量破十万之后问题全冒出来了高峰期排队严重简单任务和复杂任务抢同一份算力账单里根本看不出钱花在哪儿更别提回答质量忽高忽低用户投诉说“同一个问题问两遍答案差很多”。那段时间我每天盯着监控面板心里就一个念头不能再让一个模型打天下了。我需要的是一个多模型调度网关——把不同模型当成不同能力的“工人”根据任务类型、成本预算、延迟要求、质量目标动态决定谁来干活。而蓝耘元生代这个平台恰好提供了多模型接入和统一调度的基础能力我就基于它搭了一套。这篇文章不讲虚的我会把整个搭建过程拆开为什么选这个方案、网关的核心调度逻辑怎么设计、成本/延迟/质量这三条线怎么做到透明可观测、实际跑起来踩了哪些坑、以及我最后沉淀下来的配置和参数。如果你也在被单模型方案折磨或者正准备做多模型路由这篇应该能帮你少走不少弯路。先交代一下背景我的场景是内容生成包含短文本摘要、长文改写、代码解释、多轮对话四类任务。不同任务对模型的要求差异极大——摘要要快、改写要稳、代码要准、对话要连贯。用同一个模型要么大材小用烧钱要么小材大用掉质量。这就是我要解决的核心矛盾。2. 蓝耘元生代多模型接入的底层逻辑与选型考量2.1 为什么不是自己从零写路由层很多人第一反应是不就是根据请求打个标签转发吗我自己写个Nginx加Lua脚本不就行了我一开始也这么想试了两天就放弃了。原因有三个。第一模型接入的协议差异比想象中大。不同模型的输入输出格式、流式返回方式、超时行为、错误码定义都不一样。自己写适配层光是对齐这些细节就要花掉大量时间而且每接一个新模型就得改一次代码。第二调度决策不是简单的if-else。你要考虑实时延迟、当前并发、历史成功率、成本单价、任务优先级这些因素要动态加权。手写规则很快就会变成一坨无法维护的意大利面。第三可观测性。成本、延迟、质量这三条线要打通需要统一的埋点、聚合、展示。自己搭一套工作量不亚于做半个监控系统。蓝耘元生代在这三块上都给了现成能力统一的多模型接入接口、可配置的调度策略、以及内置的调用链路追踪。我要做的是在其之上定义我的业务规则而不是重复造轮子。2.2 模型池的划分不是越多越好我最终选了四个模型组成模型池分别对应四类任务。这里有个经验模型不是越多越好每多一个模型调度复杂度和维护成本都会上升。我的划分依据是任务特征而不是模型名气。模型代号定位典型任务成本档位延迟档位M-Fast极速响应短摘要、意图识别低极低M-Balanced均衡通用长文改写、常规对话中中M-Quality高质量输出代码解释、复杂推理高较高M-Fallback兜底备用主模型失败时接管中中这个划分的关键在于每个模型都有明确的“职责边界”。M-Fast永远不接长文任务M-Quality永远不接简单摘要。边界清晰调度逻辑才不会乱。2.3 接入时的协议对齐细节接入过程中最容易忽略的是超时和重试的语义对齐。不同模型的默认超时时间不同有的30秒有的60秒。如果不统一会出现“网关以为失败了其实模型还在算”的情况导致重复调用和成本翻倍。我的做法是在网关层统一设置超时上限并且对每个模型单独配置重试策略。具体来说对延迟敏感的M-Fast超时设8秒不重试失败直接降级到M-Fallback。对质量敏感的M-Quality超时设45秒允许一次重试但重试前要检查是否已经产生部分输出。流式返回的模型超时判断要基于“最后一个token到达时间”而不是请求发起时间。这些细节在文档里往往一笔带过但实际跑起来它们直接决定了系统的稳定性。3. 调度策略的设计成本、延迟、质量如何动态权衡3.1 调度决策的三个输入维度网关的核心是一个调度函数输入是请求特征输出是选中的模型。我的调度函数看三个维度任务复杂度通过请求的token长度、是否包含代码块、是否多轮上下文来判断。长度超过阈值或含代码的倾向M-Quality。实时负载每个模型当前的在途请求数和平均响应时间。如果M-Balanced当前排队严重简单任务就分流到M-Fast。成本预算我给每个业务线设了日成本上限。当某条线接近上限时调度器会自动把非关键任务降级到低成本模型。这三个维度不是简单加权而是有优先级的。我的优先级是质量底线 延迟要求 成本控制。也就是说如果任务本身要求高质量即使成本高、延迟大也必须走M-Quality只有在质量可接受的前提下才去优化延迟和成本。3.2 用打分制代替硬规则一开始我用的是硬规则if 长度500 then M-Quality。结果发现太死板经常出现M-Quality过载而M-Balanced空闲的情况。后来改成打分制每个模型对当前请求算一个得分得分最高的被选中。得分公式大致是score w1 * quality_match w2 * (1 - normalized_latency) w3 * (1 - normalized_cost)其中quality_match是模型能力与任务要求的匹配度normalized_latency和normalized_cost是归一化后的实时延迟和成本。权重w1、w2、w3根据业务线配置内容质量优先的线w1高实时对话线w2高。这个改动之后负载分布明显均匀了M-Quality的峰值压力下降了约四成。3.3 降级链路的设计再好的调度也架不住模型偶发故障。我设计了一条降级链路M-Fast失败 → M-Fallback M-Balanced失败 → M-Fast → M-Fallback M-Quality失败 → M-Balanced → M-Fallback降级触发条件包括超时、返回错误码、返回内容为空、返回内容明显异常比如长度过短。这里有个坑降级不能无脑重试否则一个故障模型会被反复打拖垮整条链路。我的做法是给每个模型设一个熔断器连续失败达到阈值就暂时摘除过一段时间再试探性恢复。4. 成本、延迟、质量三透明的实现路径4.1 成本透明每一分钱都能追溯到请求成本透明的前提是每次调用都有完整的成本标签。我在网关层给每个请求打上这些标签业务线、任务类型、选中模型、输入token数、输出token数、单价、总成本。这些标签写入日志后聚合起来就能回答这些问题哪个业务线最烧钱哪类任务的单位成本最高降级到低成本模型后省了多少钱我实测下来接入网关后第一个月通过把简单摘要任务从M-Quality迁到M-Fast整体成本下降了约三成而质量评分只掉了不到两个百分点。这就是透明的价值——你只有看得见才能优化。4.2 延迟透明分位数比平均值更重要延迟监控最容易犯的错是只看平均值。平均值会骗人平均200毫秒可能意味着大部分请求50毫秒少数请求5秒。用户感知到的是那些慢请求。所以我监控的是P50、P90、P99三个分位数并且按模型、按任务类型分别统计。P99超过阈值的模型会被自动降权减少被选中的概率。另外延迟要拆成两段看网关处理延迟和模型推理延迟。网关处理延迟应该稳定在个位数毫秒如果它涨了说明调度逻辑或日志写入出了问题跟模型无关。4.3 质量透明用抽样评估代替全量人工质量透明是最难的因为质量没有客观指标。我的方案是自动抽样加人工复核每天从各模型输出中随机抽取一定比例的样本。用规则检测明显问题空输出、重复输出、长度异常、包含敏感词。对抽样样本做人工评分评分结果回写到模型的质量档案。这个质量档案会反过来影响调度权重质量评分持续走低的模型会被降低选中优先级。这样就形成了一个闭环——质量数据驱动调度调度结果又产生新的质量数据。5. 实际跑起来才发现的坑与应对5.1 流式返回下的成本统计偏差流式返回时token是逐步产生的。如果请求中途被取消已经产生的token要不要计费不同模型的处理方式不同。我遇到过一次成本统计对不上的情况排查后发现是取消请求的token没有被正确记录。解决办法是在网关层拦截取消事件记录已产生的token数并在成本计算时把这部分算进去。虽然金额不大但账目必须清楚。5.2 多轮对话的上下文膨胀多轮对话场景下上下文会越来越长导致token数暴涨成本和延迟都跟着涨。我一开始没做上下文管理结果第三轮之后的请求成本是第一轮的好几倍。后来加了两条规则一是超过一定轮数后对早期对话做摘要压缩二是设置上下文token上限超出的部分截断。这两条规则让多轮对话的平均成本下降了约一半。5.3 模型版本更新带来的质量波动模型提供方会不定期更新版本有时候更新后质量会波动。我踩过一次坑某个模型更新后代码解释任务的质量明显下降但因为调度权重没变大量请求还是走它导致用户投诉。之后我加了一个机制模型版本变更时自动触发质量抽检抽检不通过就临时降低权重等人工确认后再恢复。6. 沉淀下来的配置与可复用的经验6.1 调度权重的推荐初始值如果你刚开始搭不知道权重怎么设可以参考我的初始值再根据实际数据调业务线类型质量权重延迟权重成本权重内容质量优先0.60.20.2实时对话0.30.50.2批量处理0.30.10.6这些值不是拍脑袋来的是我跑了两个月、调了十几轮之后稳定下来的。建议你每两周回顾一次调度效果根据成本和质量数据微调。6.2 监控面板必须有的几个视图按模型分组的请求量、成本、P99延迟趋势图。降级链路触发次数和原因分布。各业务线的日成本与预算对比。质量抽检评分的历史走势。这几个视图能覆盖绝大部分日常运维需求。我每天早上花五分钟扫一遍基本就能判断系统是否健康。6.3 给准备上手的人几句实在话第一别一上来就接四五个模型先从两个开始跑通了再加。模型越多调度越难调。第二成本透明要第一天就做不要等账单爆了才想起来。埋点这件事越早做越省事。第三质量评估没有捷径抽样加人工是绕不开的。但你可以把抽样比例设低一点比如百分之一先跑起来再优化。第四降级链路一定要测。我见过太多人配了降级但从来没验证过真出事的时候发现降级目标模型根本没配额。这套网关我跑了大半年最大的体会是多模型调度的价值不在于用了多少模型而在于你对每个请求的决策是否有依据、可追溯、能优化。成本、延迟、质量这三条线一旦透明优化方向自然就清晰了。