多模型协作方案实战：从LLM调度到MoE落地的踩坑复盘

显示全部楼层

兄弟们，最近在搞一个多模型协作的POC，忍不住来唠唠。🚀

先说场景：想用一个大模型做调度+路由器，搭配几个专用小模型（比如代码补全、RAG检索、图像描述）来降本增效。理想很丰满，现实是调度延迟和上下文一致性直接翻车。

**核心问题：**
1. 路由策略：是让LLM自己选模型，还是搞个简单的启发式规则（如关键词匹配+负载均衡）？实测LLM调度的准确率能到85%，但每次多花300ms延迟，小请求直接劝退。
2. 状态管理：多模型间怎么共享上下文？用共享KV Cache？还是让主模型打summary传给子模型？目前踩坑发现，summary丢细节，Cache显存炸裂，得按场景权衡。
3. 部署架构：微服务+gRPC流式调用比较稳，但服务发现和熔断必须做好，否则一个模型挂掉，整条链崩。推荐用K8s+Envoy，但代价是运维复杂度指数级上升。

**当前方案：**
- 大模型当“路由器”，只处理高置信度请求，低置信度走规则兜底。🛡️
- 子模型全部量化+异步批处理，压到单卡8B以下，不然成本扛不住。
- 上下文用Redis+短期窗口存，超时自动清，避免泄露。

最后抛个问题：你们在实际生产里，是更倾向“大模型统帅中小模型”的星型架构，还是“模型间平等对话”的网格架构？有哪些坑是文档里写不出来的？来聊聊。🔥