1. 从单模型硬扛到多模型调度我为什么要折腾这套网关去年下半年开始我手里同时跑着好几个AI应用一个面向内部知识库的问答助手、一个给运营团队用的文案生成工具、还有一个做结构化信息抽取的小服务。最开始图省事所有请求都往同一个大模型上怼——反正接口统一、代码简单一个API Key走天下。结果跑了不到两个月问题全冒出来了。最直接的感受就是成本失控。文案生成这种对创意要求高的任务用大模型确实值但信息抽取这种活儿本质上就是把这段话里的字段抠出来用同一个模型纯属杀鸡用牛刀。月底一看账单抽取类请求占了将近四成调用量但贡献的业务价值可能连一成都不到。这种感觉就像你打车去楼下便利店买瓶水车费比水贵十倍。然后是延迟问题。有些场景用户对响应速度极其敏感比如内部问答助手用户问一句上季度的报销政策是什么等三秒和等八秒的体验完全是两回事。但有些任务比如批量生成周报摘要跑个十几秒用户根本无所谓。把所有请求塞进同一个模型等于让所有任务都承受同一个延迟水平快的不够快慢的也没必要那么慢。还有一个容易被忽略的点质量波动。同一个模型在不同类型的任务上表现差异很大。有的模型写代码强有的模型中文理解细腻有的模型在结构化输出上特别稳。你用一个模型去打所有场景总有一些场景的效果让你想摔键盘。所以我决定动手搭一套多模型调度网关。核心目标就三个词成本透明、延迟透明、质量透明。让每个请求走它该走的模型该省的地方省该花的地方花该快的地方快。这套东西我用蓝耘元生代平台做底座下面把整个设计思路、实操过程和踩过的坑完整拆一遍。2. 整体架构设计调度网关到底该怎么分层2.1 为什么不做简单的if-else路由一开始我想得很简单写个函数判断一下请求类型然后if-else分发到不同模型不就行了真动手才发现事情没那么简单。第一模型列表是动态的。今天这个模型便宜明天可能涨价今天这个模型响应快明天可能因为负载高变慢。你硬编码在代码里的路由规则过两周就过时了。第二判断维度不是单一的。你不能只看任务类型这一个维度。同样是文案生成紧急的走快模型不紧急的走便宜模型同样是信息抽取字段多的走强模型字段少的走轻模型。这是一个多维度决策问题。第三你需要数据反馈。哪个模型在哪个任务上表现好不能靠拍脑袋得有实际调用数据支撑。没有数据反馈的调度系统本质上还是拍脑袋。所以我的架构分成了四层接入层、决策层、执行层、观测层。接入层负责统一收口所有请求决策层负责根据规则和数据选择模型执行层负责实际调用和容错观测层负责记录每次调用的成本、延迟和质量指标。2.2 四层架构的职责划分接入层的核心任务是统一协议。不管上层应用用什么格式传参到了网关这里都归一化成统一的请求对象。这样做的好处是后面换模型、加模型上层应用完全无感知。我定义了一个标准的请求结构包含任务类型、优先级、输入内容、期望输出格式、预算上限等字段。决策层是整个网关的大脑。它维护一张模型能力表记录每个模型在不同任务类型上的历史表现、平均延迟、单位成本。当一个请求进来时决策层根据任务类型、优先级、预算约束等条件从候选模型列表中选出一个最优解。这里我用的是规则评分的混合策略纯规则太死板纯评分又不好控制边界。执行层负责实际调用。它要处理的事情包括超时控制、重试策略、降级方案、并发限流。比如你选了模型A但模型A突然超时了执行层要能自动降级到模型B而不是直接把错误抛给用户。观测层是我最看重的部分。每次调用都会记录请求ID、任务类型、选中模型、实际延迟、token消耗、成本估算、输出质量评分如果有反馈的话。这些数据反过来喂给决策层形成闭环。2.3 蓝耘元生代在架构中的角色蓝耘元生代在这套架构里承担的是模型供给和统一调用的角色。它提供了多模型的统一接口我不需要自己去维护每个模型的SDK和鉴权逻辑。同时它的计费数据比较清晰方便我在观测层做成本核算。具体来说我在元生代上配置了多个模型端点每个端点对应不同的模型。网关的执行层通过统一接口调用这些端点决策层根据端点返回的历史数据做选择。这样整个系统对上层是透明的对下层是灵活的。3. 核心细节拆解路由策略、成本核算与质量评估3.1 路由策略怎么定才不拍脑袋路由策略是整套系统的核心。我试过几种方案最后落到了一个三层决策模型上。第一层是硬规则。有些请求有明确的约束条件比如必须支持JSON输出、必须支持中文、单次调用成本不能超过X。这些条件直接过滤掉不满足的模型不需要参与后续评分。硬规则的好处是边界清晰不会出现评分算出来选了个不支持的模型这种尴尬。第二层是加权评分。对通过硬规则筛选的模型按照多个维度打分历史质量分、平均延迟、单位成本、当前负载。每个维度的权重可以根据业务需求调整。比如面向C端的问答场景延迟权重调高面向内部的批量处理场景成本权重调高。第三层是兜底策略。如果所有模型都不可用比如全部超时走一个预设的兜底模型保证服务不中断。兜底模型不追求最优只追求可用。这里有个经验权重不要设太多维度。我一开始搞了七八个维度结果调参调到怀疑人生。后来精简到四个核心维度效果反而更稳定。维度太多每个维度的数据噪声会叠加最终评分反而不可靠。3.2 成本核算每一分钱都要算清楚成本核算是这套系统的价值锚点。如果算不清楚成本调度就失去了意义。我的做法是按请求粒度记录成本。每次调用返回后从响应中提取token消耗量乘以该模型的单位价格得到这次调用的估算成本。这个成本会写入观测层的数据库同时累加到当天的总成本里。这里有个细节不同模型的计费方式不一样。有的按输入输出分别计价有的统一计价有的还有阶梯价格。我在配置里为每个模型维护了一个计费函数输入是token量输出是成本。这样不管计费方式怎么变只要改配置就行不用动代码。另外我设置了一个日预算告警线。当天累计成本超过预算的80%时触发告警超过100%时自动把非紧急请求路由到更便宜的模型。这个机制救过我一次——有天晚上跑批量任务忘了设上限结果告警及时触发避免了一次账单惊吓。3.3 质量评估没有反馈就没有优化质量评估是最难的部分因为质量本身很难量化。我的方案是分层评估。对于结构化输出任务比如信息抽取、分类质量很容易判断输出是否符合预期格式、字段是否完整、值是否正确。这类任务可以做到自动化评估每次调用后直接打分。对于生成类任务比如文案、摘要质量评估就复杂了。我的做法是抽样人工评估自动指标辅助。自动指标包括输出长度、重复率、关键词覆盖率等这些指标不能完全代表质量但能筛出明显有问题的输出。人工评估则是每周抽一批样本由业务方打分分数回写到模型能力表里。这里踩过一个坑不要用单一指标做决策。我曾经只看输出长度来判断文案质量结果发现模型学会了凑字数输出越来越长但质量越来越差。后来改成多指标综合才把这个偏差纠正过来。4. 实操过程从零搭建调度网关的完整步骤4.1 环境准备与模型端点配置第一步是在蓝耘元生代上把需要的模型端点配好。我选了四个模型作为初始候选池一个强推理模型代号M1、一个均衡模型M2、一个轻量快速模型M3、一个超低成本模型M4。这四个模型覆盖了从高质量高成本到低质量低成本的完整光谱。配置的时候要注意每个端点都要单独测试连通性和基础能力。我写了一个简单的测试脚本对每个端点发三类请求纯文本生成、JSON结构化输出、长文本摘要。记录每个端点的响应时间、输出格式正确率、基础质量分。这些初始数据作为模型能力表的冷启动数据。# 模型端点配置示例伪代码实际配置在平台侧完成 model_endpoints { M1: {endpoint: xxx, cost_per_1k_tokens: 0.12, max_tokens: 8192}, M2: {endpoint: xxx, cost_per_1k_tokens: 0.06, max_tokens: 4096}, M3: {endpoint: xxx, cost_per_1k_tokens: 0.02, max_tokens: 2048}, M4: {endpoint: xxx, cost_per_1k_tokens: 0.005, max_tokens: 1024}, }注意单位成本一定要用实际测试数据校准不要直接抄官方文档。我实测发现某些模型的实际token消耗比预期高20%左右因为系统提示词和格式指令也计入token。4.2 请求归一化与任务分类接入层的核心工作是把各种格式的请求归一化。我定义了一个标准请求对象class GatewayRequest: task_type: str # 任务类型qa / copywriting / extraction / summary priority: str # 优先级high / normal / low input_text: str # 输入内容 expected_format: str # 期望输出格式text / json / markdown budget_limit: float # 单次调用预算上限可选 timeout_ms: int # 超时时间可选任务分类我用了两种方式结合显式声明隐式推断。上层应用如果能明确声明任务类型直接使用如果不能网关根据输入内容和期望格式做推断。推断逻辑很简单期望JSON输出且输入是长文本大概率是抽取任务输入是短问题大概率是问答任务。这里有个实操心得任务类型不要设太多。我一开始设了十几种任务类型结果每种类型的样本量都不够统计数据没有意义。后来收敛到四类核心任务每类的数据量足够支撑决策效果反而更好。4.3 决策引擎的实现细节决策引擎的核心是一个评分函数。对每个候选模型计算综合得分score w_quality * quality_score w_latency * (1 - normalized_latency) w_cost * (1 - normalized_cost) w_load * (1 - current_load)其中权重根据任务类型和优先级动态调整。比如高优先级的问答任务延迟权重设为0.5成本权重降到0.1低优先级的批量抽取任务成本权重设为0.5延迟权重降到0.1。def calculate_score(model, task_type, priority): weights get_weights(task_type, priority) quality model.history_quality.get(task_type, 0.5) latency normalize(model.avg_latency_ms, 500, 10000) cost normalize(model.cost_per_1k, 0.005, 0.15) load model.current_load return (weights[quality] * quality weights[latency] * (1 - latency) weights[cost] * (1 - cost) weights[load] * (1 - load))提示normalize函数的作用是把不同量纲的指标映射到0-1区间。延迟用500ms到10000ms作为边界成本用0.005到0.15作为边界。这些边界值要根据实际模型池的情况调整不是固定值。4.4 执行层的容错与降级执行层要处理的核心问题是选中的模型调用失败了怎么办。我的策略是三级容错第一级同一模型重试一次针对网络抖动等瞬时故障第二级降级到评分次高的模型第三级降级到兜底模型。每一级都有超时控制避免请求卡死。def execute_with_fallback(request, ranked_models): for i, model in enumerate(ranked_models): try: result call_model(model, request, timeoutrequest.timeout_ms) if validate_output(result, request.expected_format): return result, model except TimeoutError: continue except Exception as e: log_error(model, e) continue # 所有模型都失败走兜底 return call_fallback_model(request), fallback这里有个关键细节降级时要记录原因。是超时、格式错误还是服务不可用不同原因对应的优化方向不一样。超时多说明延迟评估不准格式错误多说明模型能力评估有偏差。这些数据回写到观测层驱动决策层优化。4.5 观测层的数据采集与看板观测层我用了最简单的方案结构化日志定时聚合。每次调用写一条JSON日志包含所有关键字段。然后用定时任务每小时聚合一次生成模型维度的统计报表。{ request_id: req_20240115_001, timestamp: 2024-01-15T10:30:00Z, task_type: extraction, priority: normal, selected_model: M3, actual_latency_ms: 1200, input_tokens: 850, output_tokens: 120, estimated_cost: 0.0194, output_valid: true, fallback_used: false }看板我一开始想搞得很花哨后来发现三个核心指标就够了每个模型的日均调用量、平均延迟、单位成本。再加一个成本分布饼图看钱主要花在哪些任务上。这三个指标能回答80%的问题。5. 常见问题与排查技巧实录5.1 模型评分震荡怎么办问题现象某个模型的评分忽高忽低导致路由决策不稳定同一个任务今天走M2明天走M3。排查思路先看数据量。如果某个模型在某个任务类型上的样本量少于50条评分波动大是正常的因为统计噪声太大。再看时间窗口。如果用的是最近1小时的数据而模型调用量本身就不大那评分基本就是随机数。解决方法我用了滑动窗口指数平滑。评分不是用瞬时值而是用最近N次调用的加权平均越近的调用权重越高。同时设置最小样本量阈值低于阈值的任务类型不参与评分决策走默认路由。5.2 成本估算和实际账单对不上问题现象观测层算出来的日成本是50块实际账单是65块差了30%。排查思路逐项核对。第一检查是否有未记录的调用比如测试请求、健康检查第二检查token计算方式是否和平台一致有的平台把系统提示词计入有的不计第三检查是否有阶梯计价或最低消费。解决方法我在观测层加了一个对账模块每天拉取平台的实际账单数据和估算数据做对比。差异超过10%就触发排查。后来发现主要差异来源是系统提示词的token没算进去修正后差异降到了3%以内。5.3 某个模型突然变慢导致大量超时问题现象某天下午开始大量请求超时用户投诉激增。排查思路先看是单个模型的问题还是全局问题。如果是单个模型看它的延迟曲线是不是突然飙升。如果是全局问题看是不是网关本身的瓶颈。解决方法短期方案是自动熔断。当某个模型的超时率超过阈值比如20%时自动把它从候选池里摘除15分钟后再放回来试探。长期方案是多端点冗余同一个模型配两个端点一个主用一个备用。5.4 输出格式校验太严格导致误判问题现象模型明明输出了正确的JSON但校验不通过导致不必要的降级重试。排查思路检查校验逻辑。常见问题包括模型在JSON外面包了markdown代码块标记、字段顺序和预期不一致、多了或少了一个可选字段。解决方法校验逻辑要宽松但有底线。我的做法是先尝试直接解析失败则尝试提取代码块内容再解析再失败则尝试修复常见格式问题比如补全缺失的引号。只有所有尝试都失败才判定为格式错误。这样误判率从15%降到了2%以下。5.5 常见问题速查表问题类型典型现象优先排查方向快速解决手段评分震荡路由决策不稳定样本量、时间窗口滑动窗口最小样本阈值成本偏差估算与账单不符token计算、未记录调用对账模块差异告警模型变慢大量超时单模型延迟曲线自动熔断端点冗余格式误判无谓降级重试校验逻辑严格度宽松校验格式修复预算超支日成本突增批量任务、非紧急请求预算告警自动降级6. 运行三个月后的真实数据与个人体会6.1 成本、延迟、质量的实际变化跑了三个月数据比预想的好。成本方面整体下降了约45%。主要贡献来自两个方面一是把大量简单任务从强模型迁移到了轻量模型二是低优先级任务自动走了更便宜的通道。延迟方面高优先级请求的平均响应时间从3.2秒降到了1.8秒因为决策层会把它们优先路由到快模型。质量方面结构化输出任务的格式正确率从82%提升到了96%因为决策层会把格式要求高的任务路由到擅长结构化输出的模型上。当然也有代价。系统的复杂度上去了维护成本增加了。你需要定期校准模型能力表、调整权重参数、检查对账差异。如果调用量很小比如每天几百次这套系统的投入产出比可能不划算。但一旦调用量上到每天几千次以上收益就非常明显了。6.2 几个让我印象深刻的踩坑经历第一个坑是过度优化。我一开始想把路由做到极致每个请求都算一遍最优解。结果决策层本身成了瓶颈增加了200ms的额外延迟。后来改成缓存决策结果相同任务类型优先级的请求复用同一个路由决策5分钟内有效。延迟降下来了效果几乎没损失。第二个坑是忽视冷启动。新加一个模型时没有历史数据评分默认给0.5结果它既不会被优先选中也不会被完全排除处于一个尴尬的中间态。后来我加了一个探索机制新模型前100次调用强制分配5%的流量快速积累初始数据。第三个坑是日志太多。全量记录每次调用的完整输入输出导致存储成本飙升。后来改成只记录元数据抽样记录内容存储成本降了80%排查问题时也够用。6.3 这套系统适合什么场景如果你符合以下条件这套多模型调度网关值得一试调用量达到一定规模每天至少几千次、任务类型有差异不是所有请求都干同一件事、对成本或延迟有明确诉求不是能用就行。如果只是个人玩玩或者调用量很小直接用单个模型更省心。后续我打算在这几个方向继续优化一是引入更细粒度的质量反馈让业务方可以直接在界面上给输出打分数据自动回写二是做跨天的成本预测根据历史数据预估明天的成本提前调整策略三是把决策逻辑配置化让非技术人员也能调整路由规则不用改代码。这套东西说到底就是一个思路别让一个模型干所有事也别让调度逻辑拍脑袋。数据驱动、持续迭代成本、延迟、质量这三个指标自然会往好的方向走。