让模型自己当路由器｜模型池调度的接入实战

模型路由正在从"网关里的一组 if-else"进化成"一个会分派任务的模型"。一家专攻该方向的实验室公布了新旗舰：一个不依赖任何单一专有前沿模型的调度器，把任务在固定的开源与专用模型池之间分派，还能递归调用自己。

一、一种新的产品形态：路由器即模型

我注意到这份技术报告里的几个关键设定。该模型是家族中的高性能档，核心机制是用一个语言模型给任务选执行者：池子里是固定的开源模型与专用模型，路由器按任务特征分派，复杂任务还能递归调用自身实例做拆解。设计目标放在复杂多步推理、自主研究与全栈软件开发的答案质量上；能力面覆盖可配置的推理努力档位、函数调用、结构化输出、图像与 PDF 输入、内置搜索。

这套设定的价值不在单项分数，而在姿态：路由智能被产品化成模型能力，而不是散落在业务代码里的调度脚本。对依赖中转聚合接入的团队，这几乎是对着自家架构图喊话——网关侧的路由规则，正在获得一个"模型形态"的竞争对手与合作者。

二、路由器模型与规则路由的差异

维度	规则路由（网关 if-else）	路由器模型
判定逻辑	人工维护的关键词、任务标记	模型理解任务后动态判断
维护成本	规则库随业务膨胀，需要人守	池子清单换模型即换配置
递归拆解	需要自建编排代码	模型原生递归调用自身
可解释性	规则即文档，判定透明	需要输出分派理由才可审计
失败模式	规则漏判走默认档	误路由更隐蔽，需评测兜底

两条路线不是替代关系。规则路由胜在确定与便宜，适合黑白分明的场景（批处理走低价档、生产审批走旗舰档）；路由器模型胜在弹性与细粒度，适合"任务难度事先分不清"的长尾流量。成熟架构通常是两层并存：粗粒度用规则，细粒度交给路由器。

三、原理速览：三层调度结构

text

业务请求
    |
    v
第一层：规则路由（确定性）
    |      硬规则：批处理、审批流、合规要求 → 直接定档
    v
第二层：路由器模型（弹性）
    |      读取任务 → 选择池内执行者 / 决定递归拆解
    |      输出：执行者 + 分派理由 + 推理努力档位
    v
第三层：模型池执行（固定清单）
    |      开源档 / 专用档 / 旗舰档，按清单调用
    v
聚合回传：结果 + 实际执行者标记 + token 用量归因

第三层的"固定清单"值得强调：路由器模型范式的前提是池子稳定可控。池子里放什么、每个成员的能力边界与价格，都要清单化管理——路由的智能在第二层，责任在第三层的清单治理。

四、什么时候值得搭自己的模型池路由

判断标准是任务难度的方差。如果业务流量里九成任务难度均匀，规则路由加一个默认档就够；如果方差大——同一时段混着三行代码的摘要与跨服务重构——固定档位必然两头吃亏（要么贵任务跑不动，要么便宜任务烧旗舰）。方差大的流量才是路由器的用武之地。

还有两个加分条件：任务可以延迟几秒（路由判断本身是成本），以及有回归集能验证误路由率（没有评测的路由器是黑箱赌博）。三个条件凑不齐，先用第 178 期的任务分级标记过渡，条件成熟再上模型路由。

五、接入教程：带预算护栏的轻量路由前置层

下面这段 Python 示例以 4sapi 提供的 OpenAI 兼容接口为例，实现一个轻量路由前置层：先用小模型做分派判断（输出执行者与理由），再调池内模型，递归深度与预算硬编码封顶。4sapi 的多模型聚合让池内切换只改模型名。

python

import json
import openai

client = openai.OpenAI(base_url="https://4sapi.com/v1", api_key="sk-xxx")

ROUTER_MODEL = "lite-model"            # 路由判断用轻量档
POOL = {
    "light":  "lite-model",            # 摘要、格式化
    "mid":    "mid-tier-model",        # 常规执行
    "heavy":  "flagship-model",        # 深度推理
}
MAX_RECURSION = 2                      # 递归拆解硬上限
SUBTASK_BUDGET = 4000                  # 单次分派的判断成本上限（token）


def route_once(task: str, depth: int) -> dict:
    resp = client.chat.completions.create(
        model=ROUTER_MODEL, temperature=0,
        messages=[{"role": "user", "content":
                   f"为以下任务选择执行档位（light/mid/heavy），"
                   f"若需拆解输出 recursive=true 并给出子任务。\n"
                   f"递归深度 {depth}/{MAX_RECURSION}。\n"
                   f"任务：{task}\n"
                   f"仅输出 JSON：{{tier, reason, recursive, subtasks}}"}],
    )
    return json.loads(resp.choices[0].message.content)


def dispatch(task: str, depth: int = 0) -> dict:
    verdict = route_once(task, depth)
    if verdict.get("recursive") and depth < MAX_RECURSION:
        # 递归拆解：子任务各自走一遍分派，深度与预算双封顶
        results = [dispatch(s, depth + 1) for s in verdict["subtasks"]]
        return {"task": task, "routed_by": "recursion",
                "sub_results": results, "reason": verdict["reason"]}
    model = POOL[verdict["tier"]]
    resp = client.chat.completions.create(
        model=model, temperature=0,
        messages=[{"role": "user", "content": task}],
    )
    if resp.usage.total_tokens > SUBTASK_BUDGET:
        log_overrun(task, verdict, resp.usage)   # 超预算单独归因
    return {"task": task, "tier": verdict["tier"], "model": model,
            "answer": resp.choices[0].message.content,
            "reason": verdict["reason"], "usage": resp.usage.model_dump()}

三处实现要点。第一，路由判断用轻量档，分派成本控制在执行成本的零头，SUBTASK_BUDGET 兜住判断环节自身的膨胀。第二，MAX_RECURSION 是递归的硬闸门——递归调用是这类范式最迷人的能力，也是最容易指数爆炸的能力，深度上限加预算上限双保险缺一不可。第三，reason 字段强制路由器输出分派理由，逐条落库：误路由的事后归因、规则库的迭代依据，全靠这份理由日志。

六、成本对比：三种调度形态的账

以难度方差大的日流量一万次请求为例（示例口径，实际以牌价与账单为准）：

形态	调用结构	日成本（估算）	长尾任务质量
全旗舰	无路由	最高	最好，但大部分任务在浪费
固定中档	无路由	最低	两头受损：难的做不动，简单的也没省多少
轻量路由 + 模型池	判断一次 + 分档执行	约为全旗舰的一半	难易各自归位，质量接近全旗舰

第三行多出的判断成本（轻量档一次调用）摊进总量几乎不可见，换来的档位命中率是三种形态里性价比最高的。前提仍是第 184 期的老话：命中率要用自己的回归集验证，路由器说"这题 light 够了"不等于真的够了。

七、成本与风险提示

第一条风险是误路由的隐蔽性。规则路由漏判会走默认档（可观测），路由器误判会自信地选错档（难观测）。对策是双层验证：抽样人工复核分派理由 + 失败任务回流检查当时的档位决策，误路由率进监控面板。

第二条风险是递归失控。拆解出的子任务再拆解，两三层就是几十次调用。深度硬上限之外，还要给"一次业务请求的总调用预算"设天花板，触碰即降级为单次执行。

第三条风险是池子漂移。池内成员的版本更新会改变能力边界，路由器的历史经验随之过期。池子清单带版本号，成员升级后触发一轮回归，必要时刷新路由判断的提示词。

红线：路由器的一切判断只落在自家模型池的白名单成员上，不动态接入来历不明的端点；递归调用遵守与单次调用相同的合规边界，不因拆解而绕过任何审批。

八、模型池路由自查清单

难度方差已测量：流量里长尾任务占比够高，路由判断有存在价值。
回归集已就位：误路由率可测量，分派理由可抽查。
递归双重封顶：深度上限 + 单请求总预算，触碰即降级。
理由日志已落库：每次分派带 reason，误路由可归因到决策环节。
池子清单带版本：成员模型升级触发回归，路由提示词随之校准。
判断成本已封顶：路由自身用轻量档，判断 token 有预算上限。

九、与中转聚合层的分工

把路由器模型放到接入架构的全图里看，分工是清晰的：中转聚合层（如 https://4sapi.com 一类）负责协议统一、密钥管理、多供应商可用性与牌价归因——它回答"请求从哪走"；模型路由器负责任务到档位的智能分派——它回答"这活该谁干"。两层叠起来，业务代码面对的仍是单一 OpenAI 兼容端点，换池内成员、换上游供应商都不动业务代码。路由智能越强，聚合层的价值越大，两层是共生而不是竞争。

十、总结

这一期想沉淀的结论是：路由正在从网关规则进化为模型能力，固定模型池加会分派的调度器，把"任务该谁干"变成了模型自己回答的问题。接入方的落地路径是渐进的：先用规则路由管住确定性场景，用回归集量出难度方差，再让轻量路由前置层接管长尾，递归与预算双封顶、理由日志全落库。我在 4sapi 的接入统计里见过的账单曲线，最陡的那几根下降都来自路由粒度的变细——从全旗舰到分档，从人工规则到模型分派。对递归封顶或误路由治理有不同做法，欢迎在评论区聊聊。