一、起因
刚开始接触大模型的时候，我和很多人一样，认准一个最强的用到底。那会儿在 KULAAI（dl.kulaai.cn） 上把能试的模型都试了一圈，GPT-5.5 的推理能力确实惊艳，但很快发现一个问题：再强的模型也不是万能的。
用户问“今天天气怎么样”，也要走一遍 GPT-5.5，等 1.5 秒返回，感觉像用大炮打蚊子。代码补全这种高频操作，每次调云端模型，延迟累积起来用户受不了。月底拉账单，简单任务吃掉了一半的配额，真正需要深度推理的场景反而配额不够用。
后来想明白了：不是一个模型不够强，是我太懒了，让一个模型干了所有事。
Q：一个模型不行吗，为什么非要搞多模型调度？
A：省钱、提速、保稳，三个好处
二、我现在的调度方案
任务类型走哪个模型为什么
简单分类、关键词提取轻量小模型成本几乎为零，速度还快
图片识别、语音转文字多模态模型专门的事交给专门的工具
复杂推理、代码分析GPT-5.5深度思考它最拿手
高频实时对话本地小模型延迟不到 100 毫秒
多文档交叉分析GPT-5.5长文本理解能力最强
这套方案跑了半年，综合成本降了四成多，响应速度反而上去了。最大的感受是：GPT-5.5 不是用来包揽一切的，是用来啃最难那块骨头的。
三、路由怎么判断该叫谁
刚开始我的路由规则写得很死——看到代码问题就走 GPT-5.5，看到闲聊就走小模型。后来发现这样太粗糙，用户问“这段代码为什么报错”，表面是代码问题，其实是 Bug 分析，需要深度推理。
后来改成了动态评分机制：先让一个轻量分类器判断任务复杂度，简单任务直接挡在外面走廉价模型，复杂任务才进 GPT-5.5。路由不是“分给谁”，是“配给谁”——把最合适的模型配给最合适的任务。
还有一个保底开关： 日配额消耗到八成的时候，非核心场景自动降级，保证核心业务永远不被配额卡住。这个开关上线第一天就拦了一次预算超支——月底结算的时候财务终于没有找我聊天了。
四、多模型混用的坑
路由逻辑做成单点。 我的第一版路由服务挂了，全公司所有模型调用一起瘫。后来加了降级开关——路由挂了直接切 GPT-5.5 兜底，虽然成本高了点但业务不断。
模型之间的上下文不通用。 从 GPT-5.5 切到其他模型时，对话格式不一样，信息丢失导致下游回答质量断崖下降。这个问题花了我整整两天处理适配层。
账单不按模型拆。 第一个月只知道总消费，不知道哪个模型最吃钱。后来给每个模型加了独立计数，才发现简单分类任务吃掉了 30% 的配额——优化掉之后省了一大笔。
评分系统用固定权重。 刚开始给每个模型打了个分就写死了。结果模型版本一更新，原来的评分全过时。现在改成动态收集各模型的成功率和延迟数据，路由权重自动调整。
五、半年下来的感受
多模型调度这件事，做之前觉得是“技术选型”，做之后发现是“资源统筹”。
GPT-5.5 很强，但它不应该去干那些“看一眼就知道答案”的活。把这些简单任务分给小模型之后，GPT-5.5 的配额全用在了刀刃上——复杂推理、长文档分析、代码架构设计——这些才是它真正拉开差距的地方。
一个好的调度系统，不是让最强的模型干所有事，是让每个模型只干自己最擅长的事。
这也是为什么我后来不再纠结“哪个模型最好”这种问题了。与其找一个全能选手，不如搭一个好调度，让合适的模型在合适的时刻上场。省下来的不只是钱，还有用户的等待时间，还有我自己排查故障的精力。
这些经验是半年踩坑攒下来的，希望能帮到你。
