1. 从单模型硬扛到多模型调度我为什么要折腾这套网关去年下半年开始我手上同时跑着好几个AI应用一个面向内部知识库的问答助手、一个给运营团队用的文案生成工具、还有一个做结构化信息抽取的小服务。最开始图省事所有请求都往同一个大模型上怼——反正接口调通了能出结果就行。结果跑了不到两个月问题全冒出来了账单涨得比预期快了三倍高峰期延迟飙到十几秒偶尔模型服务抖动一下整个业务链路直接卡死。最要命的是我根本说不清楚钱花在哪了、哪个请求慢、输出质量到底稳不稳。痛定思痛我决定搭一套多模型调度网关。核心目标就三个词成本透明、延迟透明、质量透明。说白了就是让每一个请求在出去之前网关能根据预设策略决定这个活儿该派给谁回来之后能记录花了多少钱、用了多久、结果靠不靠谱。这套东西我最终基于蓝耘元生代平台落地了跑了两周多效果比我预期好所以把整个设计思路和实操过程整理出来。这篇文章适合谁看如果你也在用多个模型服务、被成本和延迟搞得头疼或者你正准备从一个模型打天下往多模型架构迁移那这篇内容应该能帮你少踩几个坑。我会从整体设计、核心细节、实操落地到问题排查一层层拆开讲尽量做到你看完就能照着搭一套自己的版本。先说清楚一个前提多模型调度网关不是银弹它解决的是路由决策和可观测性两个问题不解决模型本身的能力上限。你得先接受一个现实——没有任何一个模型在所有场景下都是最优的所以才需要调度。这个认知转变是整个项目能推进下去的心理基础。2. 整体架构设计网关到底该管什么、不该管什么2.1 核心需求拆解与边界划定动手之前我先花了两天时间做需求梳理这一步很多人会跳过但我觉得恰恰是最关键的。我列了一张表把网关该做的事和不该做的事分清楚职责归属具体内容理由网关该管请求路由、模型选择、成本核算、延迟统计、质量打分、降级重试这些是跨模型通用的横切逻辑网关该管统一鉴权、限流、日志埋点集中管理比散落在各业务里强网关不该管具体业务Prompt构造业务逻辑应该留在业务层网关不该管模型微调、训练那是另一套体系的事网关不该管复杂的结果后处理交给业务侧网关保持轻量这个边界划清楚之后架构就清晰了。网关本质上是一个智能代理层夹在业务代码和模型服务之间对外暴露统一接口对内做决策和统计。2.2 为什么选蓝耘元生代作为底座选平台这件事我对比过几个方案。自建的话光是模型接入、密钥管理、并发控制就够写一大堆胶水代码维护成本太高。用蓝耘元生代主要是看中几点一是它支持多模型统一接入省去了我自己封装各家SDK的功夫二是它的调用链路本身有比较完整的日志和计量能力我的网关可以直接复用这些数据做成本核算三是它的接口风格统一我做路由层的时候不用为每个模型写一套适配逻辑。这里要强调一个设计原则网关要尽量薄。我见过一些团队把网关做成了大杂烩什么逻辑都往里塞最后变成一个谁都不敢改的单点。我的做法是网关只做决策和转发所有重逻辑都下沉到独立的策略配置和统计模块里网关本身保持无状态方便水平扩展。2.3 三透明的实现思路三透明听起来抽象落到实现上其实是三套并行的数据采集和展示机制成本透明每次调用记录token消耗量乘以对应模型的单价累加到请求维度和业务维度。关键是单价要可配置因为模型价格会变。延迟透明记录首token延迟TTFT和总耗时两个指标。前者影响用户感知后者影响吞吐。两个都要看只看一个会误判。质量透明这个最难。我的做法是引入一个轻量级的质量打分器对输出做规则校验比如格式是否符合、是否包含敏感词、长度是否合理再结合用户反馈做加权。提示质量透明不要追求一步到位。我一开始想搞个复杂的质量评估模型后来发现投入产出比太低先用规则校验跑起来后面再迭代。3. 核心细节解析路由策略、成本核算与质量打分怎么落地3.1 路由策略的设计与参数选择路由是整个网关的大脑。我设计了三层路由逻辑从粗到细依次过滤第一层是能力过滤。每个模型在配置里标注自己的能力标签比如支持长上下文支持函数调用支持多模态。请求进来先看它需要什么能力把不满足的模型直接排除。这一步能砍掉大部分不合适的候选。第二层是成本与延迟权衡。剩下的候选模型我按一个加权公式打分score w1 * (1 / normalized_cost) w2 * (1 / normalized_latency) w3 * quality_score其中w1、w2、w3是权重可以根据业务场景调整。比如面向C端的实时对话w2延迟权重调高面向批处理的任务w1成本权重调高。normalized_cost和normalized_latency是归一化后的值避免量纲差异导致某个指标主导。第三层是动态降级。如果首选模型连续失败或延迟超过阈值自动切到备选。这里我用了一个滑动窗口统计窗口内失败率超过20%就触发降级恢复则用更保守的阈值比如失败率降到5%以下才切回避免在临界点反复横跳。3.2 成本核算的精度控制成本核算最容易出的问题是算不准。原因通常有两个一是token计数和平台计费口径不一致二是缓存命中没考虑进去。我的做法是以平台返回的用量数据为准本地只做累加和展示。每次调用后从响应里提取prompt_tokens和completion_tokens乘以配置的单价。单价我单独维护一张表按模型和计费类型输入/输出区分。这样即使平台调价我改配置就行不用动代码。关于缓存如果你的网关支持结果缓存一定要在成本核算里区分缓存命中和实际调用。缓存命中的请求成本记为零但延迟要单独统计否则会拉低整体延迟均值造成误判。3.3 质量打分的规则设计质量打分我用了四个维度每个维度0到1分最后加权求和格式合规如果请求指定了输出格式比如JSON校验是否能解析。能解析得1分不能得0分。长度合理输出长度在预期区间内得1分过短或过长按比例扣分。内容完整检查是否包含关键字段或关键词缺失则扣分。异常检测检测是否有重复、乱码、明显无意义内容有则大幅扣分。这套规则不完美但胜在可解释、可调整、零额外成本。跑了一段时间后我发现质量分低于0.6的请求人工抽查确实大部分有问题说明这套简单规则是有区分度的。注意质量打分器本身也会消耗计算资源如果你的QPS很高建议异步执行不要阻塞主链路。4. 实操过程从零搭建网关的完整步骤4.1 环境准备与基础配置我用的技术栈是Python FastAPI选它主要是因为异步支持好、开发速度快。数据库用PostgreSQL存配置和统计数据Redis做缓存和限流。第一步是配置模型清单。我在数据库里建了一张models表字段包括模型标识、能力标签、输入单价、输出单价、优先级、最大并发数。这张表是网关路由的数据基础所有决策都从这里读。# 模型配置示例结构 { model_id: model_a, capabilities: [long_context, function_call], input_price: 0.0008, # 每千token单价 output_price: 0.0024, priority: 1, max_concurrency: 50 }第二步是配置路由权重。我把权重也做成可配置的按业务场景分了几套预设实时对话场景、批处理场景、高精度场景。业务方调用时指定场景名网关自动加载对应权重。4.2 请求处理主链路实现主链路的流程我拆成了六个阶段每个阶段都有明确的输入输出接收请求校验鉴权、解析业务标识和场景标识。能力过滤根据请求需求筛选候选模型。打分排序按加权公式计算每个候选的得分排序。调用执行从最高分开始尝试失败则降级到下一个。结果记录记录成本、延迟、质量分写入统计表。返回响应统一格式返回给业务方。这里有个细节值得说降级重试要有次数上限。我设的是最多尝试3个模型超过就返回错误。不设上限的话一个请求可能把所有模型都试一遍延迟爆炸。async def route_and_call(request): candidates filter_by_capability(request) ranked rank_by_score(candidates, request.scene) for model in ranked[:3]: try: result await call_model(model, request) record_metrics(model, result) return result except ModelError: continue raise AllModelsFailed()4.3 统计数据的采集与展示统计数据我分了两张表一张是请求明细表记录每个请求的模型、成本、延迟、质量分一张是聚合表按小时和按业务维度预聚合方便快速查询。展示层我用了一个简单的看板核心就三个图成本趋势图、延迟分布图、质量分趋势图。别看简单这三个图能覆盖80%的日常决策需求。比如成本突然涨了看趋势图定位到是哪个业务、哪个模型延迟高了看分布图判断是整体慢还是长尾慢。提示聚合表一定要做预聚合不要每次查询都去扫明细表。我一开始偷懒直接查明细数据量上来后查询慢得没法用。4.4 灰度上线与效果验证网关这种东西不能一次性全量切。我的做法是先切10%的流量跑三天对比网关路由和原来的固定模型方案在成本、延迟、质量上的差异。确认没有明显劣化后逐步提到50%、100%。灰度期间我重点关注两个指标一是降级率如果降级率超过5%说明路由策略有问题二是质量分分布如果低分请求比例明显上升说明路由把请求派给了不合适的模型。实测下来全量切换后成本降了约35%P95延迟降了约40%质量分基本持平。这个结果我觉得是合理的——成本降是因为把简单请求派给了便宜模型延迟降是因为做了负载分散质量持平说明路由策略没有牺牲效果。5. 常见问题与排查技巧实录5.1 路由决策不符合预期怎么办这是最常见的问题。表现是明明某个请求应该走便宜模型结果走了贵的。排查思路是把决策过程打日志。我在路由函数里加了debug日志记录每个候选模型的得分和最终选择理由。一看日志就清楚了通常是权重配置不对或者能力标签标错了。还有一种情况是缓存导致的决策滞后。模型配置改了但网关缓存没刷新还在用旧配置。解决办法是配置变更时主动清缓存或者给缓存设一个较短的过期时间。5.2 成本统计和平台账单对不上对不上的原因通常有三类我整理成了速查表现象可能原因解决办法统计值偏低缓存命中未计入检查缓存逻辑命中也记录统计值偏高重试请求重复计费重试时标记只计一次两者差异小但持续单价配置过期定期同步平台最新单价差异突然变大平台计费口径调整核对平台文档更新核算逻辑我的经验是允许1%到3%的误差因为token计数本身可能有细微差异。但如果超过5%一定要查。5.3 延迟统计的陷阱延迟统计最容易踩的坑是把排队时间算进去了。如果你的网关有限流或排队机制用户感知的延迟是排队执行但模型执行延迟只是执行。这两个要分开统计否则你会误以为模型慢其实是排队慢。另一个坑是平均值掩盖长尾。我一开始只看平均延迟觉得挺好后来看P99才发现有大量请求延迟很高。所以延迟一定要看分位数P50、P95、P99都要看。5.4 质量打分的误判处理规则打分难免误判。我遇到过一个典型情况某个模型输出用了不同的JSON字段命名风格格式校验直接判0分但实际上内容是对的。解决办法是让格式校验更宽容比如支持字段名的大小写不敏感匹配或者允许多种等价格式。还有一个经验是质量分不要直接用于自动决策至少初期不要。我一开始想用质量分自动把低分模型踢出候选后来发现误判会导致好模型被误伤。现在的做法是质量分只做展示和告警人工确认后再调整配置。5.5 高并发下的稳定性问题并发一高问题就多。我遇到过的包括连接池耗尽、Redis超时、统计写入成为瓶颈。对应的处理是连接池按模型单独配置并留足余量Redis操作全部加超时和降级统计写入改成异步队列不阻塞主链路。注意统计写入异步化之后要处理进程崩溃导致统计数据丢失的问题。我的做法是本地先落盘再异步同步到数据库保证至少不丢。6. 一些踩坑之后的经验总结搭这套网关前后花了大概三周其中一半时间在调试和修bug。回头看有几个经验我觉得挺值钱的。第一配置和代码要分离。路由权重、模型单价、能力标签这些全部做成配置改的时候不用发版。我一开始把权重写死在代码里调一次改一次代码效率极低。第二先跑通再优化。我一开始想设计一个完美的路由算法结果卡了两天没进展。后来改成先用最简单的规则跑起来再逐步迭代反而顺利多了。第三可观测性比算法重要。网关的核心价值不是路由多智能而是让每个决策都可追溯、可解释。没有好的日志和统计再聪明的算法也是黑盒。第四降级策略要保守。宁可少降级也不要频繁横跳。频繁切换模型会导致输出风格不稳定用户体验反而更差。这套网关现在还在持续迭代下一步我打算把质量打分做得更细一些引入一些轻量的语义相似度校验。不过那是后话了当前这套版本已经能解决我80%的问题。如果你也在做类似的事情建议先从成本透明做起因为那个最容易量化也最容易看到收益。
