做 AI 应用这几年我一直有个固执的念头与其拼命调整一个大模型去覆盖所有场景不如让几个开源模型各管一摊再通过统一的调度层把它们变成一支协同作战的舰队。K2 Horizon 这个项目就是在这个念头下折腾出来的产物。项目的核心是用 01.AI 开源的 K2 模型作为协调中枢搭配五个各有所长的开源模型组成一支六模型舰队任务进来先做意图判断再按类型路由给最合适的模型执行必要时串联多个模型完成复合能力。这套设计解决的问题很现实单模型方案要么贵要么慢更常见的是偏科——数学推理强的模型写代码一般代码模型看不懂图通用对话流畅的模型在复杂逻辑上一本正经地胡说八道。K2 Horizon 用路由分工兜底三层机制把这些问题拆开解决。整个过程从方案设计到跑通大概花了两周接着稳定运行了三个月中间踩了不少坑。这篇文章会把整体架构、六模型的分工逻辑、连接层的具体实现、部署调优和排障实录一次性写清楚适合正在做多模型服务、Agent 编排或者想在公司内部搭一套私有模型网关的工程师参考。1. 为什么是舰队而不是单模型1.1 单模型方案的三个硬伤先说结论如果你的业务只有一种固定任务比如只做客服问答那老实调一个大模型就够了搞多模型纯粹是给自己找事。但一旦任务类型开始分化单模型方案就会暴露出三个很明显的硬伤。第一个是算力和质量的矛盾。所有请求都走同一个大模型简单查询也消耗同样的推理资源高峰期排队问题立刻出现。可如果为了速度换小模型复杂任务的质量又接不住。更难受的是参数无法按任务区分——同一个温度系数写代码要的是确定性和严谨写营销文案要的是发散和创意一个模型很难两头兼顾。我最早用单个 72B 模型跑全量请求简单问答的首 token 延迟经常飙到 3 秒以上明显是杀鸡用牛刀。第二个是模态割裂。纯文本模型处理带图请求非常痛苦我最初的方案是先用 OCR 服务把图里的字抽出来再把文本塞给大模型。这套流程维护成本极高OCR 识别错一个字后面的推理就全错。图表、截图、票据这类结构化图片OCR 的还原度永远达不到需求。第三个是故障爆炸半径。单模型一旦出问题整个服务全部瘫痪没有任何回退余地。一次偶然的模型推理异常就可能导致线上大面积超时。这些问题叠加在一起让我最终决定换成多模型舰队架构。1.2 舰队模式的设计取舍多模型协同主要有三种模式路由分发、并联投票、串联流水线。我在 K2 Horizon 里以路由为主局部用投票和串联补强。路由分发的核心是一个调度层每次请求先进来判断任务类型后再转发给对应的模型这套方式对延迟和成本最友好并联投票是让多个模型对同一个问题各自输出再按多数或置信度取结果适合内容审核、事实校验这类不能出错的场景串联流水线则是把任务拆成多个阶段比如先 OCR 再推理先规划再执行。为什么不是全都上原因很直接并联投票的成本是成倍增长的每次请求都要调动两三个大模型托底场景可以接受日常请求根本吃不消。串联流水线则会显著放大延迟链路里任何一个环节慢了整个请求都被拖住。所以我最终确定的原则是90% 的流量走单模型路由关键判断走一次双模型交叉验证复杂任务最多串联两个模型。这里必须强调一点路由决定成败路由判错一次后面所有模型再强也没有意义。所以路由层我单独花了很多精力打磨这块放在第 3 章详细讲。2. 六模型分工与选型复盘2.1 选型标准不追最强只追最对六个模型不是随便凑的选型时我给自己定了四条硬标准。第一许可证必须商用友好首选 Apache 2.0 和 MIT一定要避开传染性强的协议不然上线前法务会让你把整个项目翻一遍。第二生态成熟度模型必须能被 vLLM 直接加载量化方案要齐全社区用户基数大出了问题能搜到答案。第三硬件适配团队实际能用的 GPU 就那几台模型再强塞不进去也是白搭。第四模型之间的能力要有区分度不能选六个同质化模型否则舰队就是摆设。基于这四条标准我最后定的六名成员是K2 做中枢协调和复杂推理Qwen2.5-72B 做通用对话DeepSeek-R1-Distill-Qwen-32B 做数学和深度推理Qwen2.5-Coder-32B 做代码相关任务MiniCPM-V-2.6 做视觉理解BGE-M3 做语义向量和路由判断。K2 是 01.AI 开源的新一代 MoE 模型激活参数只有 32B走 4bit 量化之后实际可以在 8×80G 单机跑起来作为舰队的大脑正合适。2.2 六模型角色分配表每个模型承担的角色和部署方式我整理了一张表方便对照。模型角色部署方式上下文核心职责K2 (01.AI)中枢协调/复杂推理vLLMTP8AWQ 4bit256K意图兜底分类、复杂推理、结果汇总Qwen2.5-72B-Instruct通用对话vLLMTP2128K日常问答、摘要、改写、情感分析DeepSeek-R1-Distill-Qwen-32B深度推理vLLMTP1128K数学题、逻辑推理、多步规划Qwen2.5-Coder-32B-Instruct代码生成vLLMTP1128K代码补全、解释、测试用例生成、重构MiniCPM-V-2.6视觉理解vLLMTP18K图像内容识别、图表理解、OCRBGE-M3语义向量/路由FlagEmbedding8K意图向量化、相似度计算、路由匹配这套组合覆盖了文本、代码、视觉、检索四类能力选型的一个重要心法是模型参数不是越大越好而是越匹配越好。代码任务用专门的代码模型比通用大模型又快又准数学推理用带思维链的蒸馏模型比直接问对话模型稳定得多。2.3 硬件规划与部署分布硬件方面我用的是一台 8 卡 80G 节点跑 K2一台 4 卡 80G 节点跑三个文本模型外加一张 4090 跑视觉模型和向量模型。4 卡节点上三个模型不能同时常驻否则显存会爆我做了冷热分离——Coder 和 DeepSeek 按流量时段拉起Qwen2.5-72B 常驻承接主要流量。4090 这张卡比较紧张MiniCPM-V-2.6 和 BGE-M3 共享根据请求特点设置进程优先级视觉请求多发时向量服务自动排队。显存分配的核心原则是给 K2 留足余量。K2 走 AWQ 4bit 量化后权重大约占用 500GB8 卡还剩约 140GB 给 KV cache 和激活值。实测最大上下文长度拉到 131072 时并发 8 个请求就开始吃紧所以我平时把 K2 的 max-model-len 限制在 65536既保住了长文档分析能力又留出了并发余量。3. 连接层设计让六个模型说同一种话3.1 路由层怎么判任务类型六个模型各说各话连接层要做的就是让它们听懂同一个指令。路由层我试过三种方案纯规则匹配、小模型分类、向量相似度匹配。纯规则匹配的问题是一戳就破用户换个说法规则就失效小模型分类准确率还行但需要维护训练数据和模型版本最后我选了 BGE-M3 做向量相似度匹配。具体流程是这样的BGE-M3 先把用户输入编码成向量然后和预置的七类意图模板向量算余弦相似度超过 0.78 的阈值就直接返回对应任务类型低于阈值则升级给 K2 做兜底分类。这套混合方案的好处是简单请求完全不用惊动 K2复杂请求又能得到模型的理解能力。我准备了大概 200 条意图模板覆盖聊天、推理、代码、视觉、摘要、安全、未知七类实测路由准确率在 94% 以上。之前踩过一个很深的坑阈值定得太低导致很多明显是闲聊的请求被路由到了 K2一个顶俩的成本瞬间把预算烧穿。后来我把阈值调高并且加了一条规则——如果用户请求长度小于 20 个字且没有明显代码或图片特征默认走通用对话模型这样既省成本又降低了误判概率。3.2 统一消息协议与上下文隔离模型之间要协作必须有一套统一的消息格式。我设计了一个 JSON 信封包含 request_id、task_type、payload、history、meta 和 fallback_ok 六个字段。request_id 全链路透传排查问题全靠它串日志task_type 是路由层给出的任务类型下游模型必须严格遵守history 按任务类型分别维护绝不让对话上下文和代码上下文混在一起。上下文隔离这块特别重要。最开始我把所有历史消息一股脑塞给下一个模型结果代码任务的上千行上下文把对话模型的窗口撑爆导致回答质量断崖式下降。后来改成按任务类型分桶存储会话Redis 里每个桶一个 keyTTL 24 小时自动过期转发时只带当前任务类型的上下文。这个改动让端到端成功率提升了将近 10 个百分点。超时和熔断机制也是连接层的重头戏。每个模型都有独立的超时配置K2 给 120 秒文本模型 60 秒视觉模型 30 秒。连续 5 次超时自动触发熔断后续请求直接跳过该模型走 fallback 链路熔断状态每 30 秒探测一次模型恢复后自动放量。3.3 核心编排代码示例路由和编排的核心逻辑并不复杂关键在于把降级路径设计好。下面是路由判定的简化代码# router.py 简化版 from dataclasses import dataclass dataclass class RouteResult: target: str confidence: float async def route_query(query: str, embedding_fn, intent_templates: dict) - RouteResult: query_vec await embedding_fn(query) best_target, best_score None, 0.0 for intent, template_vec in intent_templates.items(): score cosine_similarity(query_vec, template_vec) if score best_score: best_target, best_score intent, score # 相似度足够高直接路由 if best_score 0.78: return RouteResult(targetbest_target, confidencebest_score) # 相似度不够升级给 K2 兜底分类 return RouteResult(targetk2_fallback, confidencebest_score)请求进来之后编排层拿到路由结果再做分发。每个任务类型我都配了一条 fallback 链reasoning 任务DeepSeek-R1-32B 为主失败切 K2再失败切 Qwen2.5-72Bcode 任务Coder-32B 为主失败切 K2vision 任务MiniCPM-V-2.6 为主失败返回明确错误并建议用户上传更清晰的图片chat 任务Qwen2.5-72B 为主失败切 K2fallback 链最多跳一次绝不允许无限递归。这个设计是用一次线上事故换来的教训有一版代码没有限制跳转次数一个模型超时后连续触发了三个模型整个链路雪崩了十几秒。现在所有 fallback 都带深度计数超过一跳直接返回友好错误。3.4 输出格式化与参数控制六个模型输出风格千差万别有的喜欢在 JSON 外面包一层 markdown 代码块有的会在回答后面追加解释。我的处理方式是双保险提示词里明确要求只输出 JSON不要任何额外说明同时在代码层写了一个 extract_json 函数用正则把最外层的大括号内容抠出来再解析。凡是解析失败的走一次轻量修复——补全缺失的引号、去掉尾逗号再不行就重新请求一次。每个模型的采样参数也做了差异化配置代码和数学任务温度设为 0.1保证确定性通用对话用 0.7保持自然创意写作单独开一个 0.9 的通道。分类类任务温度必须设为 0否则同样的输入两次分类结果可能不一致下游体验会很差。这套参数矩阵放在配置文件里改参数不用动代码。4. 实操落地从部署到上线的完整记录4.1 部署顺序与验证清单六个模型的部署顺序很有讲究我的原则是先易后难先外围后核心。最先部署 BGE-M3它是路由层的基石没有它所有请求都进不了分发流程接着部署 MiniCPM-V-2.6视觉链路独立性强容易验证然后是三个文本模型最后才是 K2。每部署一个模型先跑一组 smoke test验证 vLLM 接口连通性、首 token 延迟、上下文长度和并发表现通过之后再接入路由层。K2 的 vLLM 启动命令我贴在这里注意 tensor-parallel-size 必须和 GPU 数量一致否则直接报错python -m vllm.entrypoints.openai.api_server \ --model /models/K2 \ --tensor-parallel-size 8 \ --quantization awq \ --max-model-len 65536 \ --gpu-memory-utilization 0.92 \ --served-model-name k2部署完成后我建了一份验证清单逐项打勾模型能正常加载、第一次推理不超 5 分钟、连续 10 次推理结果稳定、上下文截断位置正确、并发 5 个请求不报显存错误。这套清单后来成了团队其他项目上线模型的通用模板省了很多重复排查的时间。4.2 性能实测数据与调优稳定运行后我统计了一组端到端延迟数据覆盖六类主要任务作为容量规划的参考。任务类型路由模型平均首token延迟平均总耗时建议并发上限简单问答Qwen2.5-72B0.8s3.2s20数学推理DeepSeek-R1-32B1.5s9.8s10代码补全Coder-32B0.9s4.1s15图像识别MiniCPM-V-2.60.6s2.5s10复杂推理K22.1s18.6s8向量检索BGE-M330ms80ms200从数据能看出来K2 虽然最慢但也只承接了少量高价值请求。流量分布上大约 65% 的请求落在 Qwen/Coder/视觉模型上20% 落在 DeepSeek只有 15% 走 K2。这个比例是刻意控制的结果因为算力要优先保障高频低成本的路径让便宜的模型养着贵的中枢模型。调优过程中做的最有效的一件事是给每个模型单独配置了队列长度和排队超时。vLLM 默认的队列策略是公平调度但遇到突发流量时简单请求会被长推理请求堵在后面。我给每个模型设了独立的 max_queue_size并让编排层按任务优先级插队——视觉和简单问答优先代码和深度推理靠后。这个改动让 P95 延迟下降了约 30%。4.3 评测集与回归机制多模型系统的质量评估比单模型麻烦得多因为一个请求可能经过路由、模型、后处理三个环节问题出在哪一层需要能定位。我建了一个 200 条的评测集按任务类型分类每次改动路由逻辑或替换模型先跑一遍回归。评测维度有四项路由准确率、端到端成功率、超时率、fallback 使用率。最初端到端成功率只有 67%大量失败集中在输出解析和上下文截断上。加了解析兜底和上下文隔离之后成功率逐步爬到 93%。剩下的 7% 失败里一半是视觉模型的图片预检问题一半是 K2 在超长上下文下的偶发推理异常。评测集的作用不只是把关更是给优化提供数据支撑——没有评测你根本说不清改动到底是变好了还是变坏了。5. 常见问题与排查技巧实录5.1 六类高频问题速查表运营三个月我把遇到的高频问题整理成了一张速查表每种问题都对应着根因和解决办法。问题现象根因解决办法请求排队越来越慢某个模型负载过高上游重试叠加限流 按优先级插队 超时熔断模型输出 JSON 解析失败模型吐了 markdown 代码块或多余文本extract_json 正则兜底 提示词约束模型回答突然变差上下文混入了其他任务类型的历史按任务类型分桶隔离 定期清理会话简单请求误路由到 K2向量相似度阈值偏低调高阈值 短文本默认走通用模型视觉模型返回空结果图片格式或大小超出模型限制上游预检图片格式、尺寸、base64 合法性40G 节点 OOM多模型同时常驻导致显存碎片冷热分离按流量时段拉起和释放模型5.2 独家避坑心得先说熔断。熔断不是越灵敏越好太灵敏会导致模型一抖动就被摘除流量全挤到备用路径上反而把 K2 打挂。我的经验是熔断窗口设 30 秒连续 5 次失败才触发恢复探测间隔 10 秒给模型留足喘息空间。再说日志。多模型系统最怕排查问题时分不清是哪个环节出的错。我要求所有日志必须带 request_id从入口网关到路由层到模型响应全链路串联。没有 request_id 的排查就像没手电筒进隧道只能靠猜。这套链路日志上线后平均故障定位时间从半小时缩短到五分钟以内。最后说容量规划。很多多模型项目死在模型越加越多卡越买越贵上。我的体会是新模型上线前必须做容量评估预估 QPS、单请求平均 token 数、目标延迟然后反推需要几张卡、要不要量化、要不要做冷热分离。模型不是越多越好而是要让每一个模型都有清晰的流量定位承担它该承担的那部分成本。6. 这套系统的边界与后续扩展6.1 什么时候不适合上舰队多模型架构不是银弹有几种情况我明确不建议上。第一如果场景非常单一调用量也不大一个大模型加提示词工程完全够用强行上多模型只会增加维护负担第二如果团队连 GPU 资源都没有只能用 CPU 推理或全量走云厂商 API那多模型的路由收益会被网络延迟和费用吃掉第三如果业务对延迟要求极其严格比如必须在 500 毫秒内返回那路由层的开销是不可接受的更合适的是单模型加缓存。还有一个容易被忽略的边界团队维护能力。六个模型意味着六套依赖、六种日志格式、六份故障预案如果团队只有一两个人且没有完善的监控体系多模型会变成维护泥潭。K2 Horizon 能跑稳很大程度是因为前期在日志、监控、评测上做了足够多的投入。6.2 后续可以扩展的方向这套系统的下一步扩展我打算从三个方向入手。第一把历史路由结果收集起来离线微调一个小型分类模型替代当前的阈值路由方案减少对 K2 兜底分类的依赖第二做一个模型健康度面板把每个模型的延迟、成功率、队列长度、显存占用可视化设置阈值告警让异常在影响用户之前就被发现第三把模型注册做成插件化新模型上线只需要在配置中心加一条记录不用改编排代码。还有一个很值得做的方向是路由策略的自适应。现在的路由规则是静态的模型负载高的时候依然会把请求发过去。下一步可以做成动态路由根据每个模型的实时健康度和延迟动态调整流量分配比例比如 K2 排队超过 10 秒时自动把部分复杂推理降级给 Qwen2.5-72B 处理用略微下降的质量换取整体稳定性。最后分享一点个人体会。K2 Horizon 这个项目最值钱的地方不是把六个模型调通了而是逼着我把模型能力和服务架构两件事彻底分开思考。以前我总在纠结哪个模型最强现在更关注哪个模型最适合当前请求、出错了怎么兜底、成本怎么分摊。多模型架构听起来高大上本质上就是把人力的分工逻辑搬到了模型层——让擅长数学的去做数学擅长代码的去做代码擅长聊天的去聊天。如果你也想搭一套类似的系统我的建议是别一上来就搞六个先用两个模型把路由跑通一个强推理一个通用对话确认链路稳定了再加视觉、加代码、加向量一步步扩编。舰队不是在图纸上画出来的而是在一次次航行中修出来的。