MSM：用多小模型协作替代单一LLM的开放标准

MSM提出了一种全新的AI系统架构思路——通过6层专用小模型流水线协同工作，在成本、延迟和准确性上全面超越传统大语言模型方案。

当前，构建商业AI系统的默认选择是调用GPT-4、Claude等大型语言模型。这种方案虽然简单，但存在明显痛点：每次调用成本高昂、响应延迟通常在2-5秒、对垂直领域的理解准确率有限、私有化部署需要昂贵的基础设施。

更重要的是，大语言模型是一个"黑盒"——你无法知道它是如何得出答案的，也难以针对特定环节进行优化。当业务需求变化时，往往需要重新训练或更换整个模型。

MSM（Multi Small Models）提出了一种截然不同的思路：与其依赖一个"什么都会但什么都不精"的大模型，不如让多个小型专用模型各司其职，通过流水线协作完成任务。

这就像一家餐厅不是让主厨一个人包办所有工作，而是有专门的采购、切配、烹饪、摆盘团队——每个环节都由专家负责，整体效率反而更高。

MSM将AI系统划分为六个明确的处理层，每层都有清晰的职责边界：

第一层：翻译层（Translation）

负责将用户输入的任何语言转换为标准英文，同时提取上下文标注。这一层让系统天然支持多语言，无需为每种语言单独训练模型。推荐模型如NLLB-200 600M，这是一个经过优化的神经机器翻译模型。

第二层：分类层（Classification）

识别用户意图、领域和紧急程度。例如区分"我要订餐"和"我要退款"属于不同的业务意图。这一层使用mDeBERTa-v3等轻量级分类模型，读取翻译层提供的上下文标注来做出判断。

第三层：编排层（Orchestration）

根据分类结果规划工作流步骤，决定需要调用哪些工具或API。比如订餐场景可能需要获取位置、搜索餐厅、确认订单等多个步骤。推荐使用Qwen 2.5 3B这类小型指令模型。

第四层：执行层（Execution）

实际调用工具、处理错误、获取外部数据。这一层与外部系统对接，如地图API、支付接口、库存系统等。使用Functionary Small v3等支持工具调用的模型。

第五层：生成层（Generation）

将执行结果组织成自然语言回复。这是用户最终看到的输出，需要流畅、准确、符合语境。可以使用最小的Qwen 2.5 0.5B模型完成。

第六层：验证层（Validation）

对最终输出进行质量、合规性和安全性检查，确保内容符合业务规范。使用MiniCheck和DeBERTa-v3等验证模型。

指标	传统LLM方案	MSM方案
单次调用成本	高	降低10-20倍
响应延迟	2-5秒	低于1秒
领域准确率	约80%（通用）	95%+（专用）
语言支持	英语优先	通过翻译层支持任意语言
私有化部署	不现实	单GPU即可运行
审计追踪	黑盒	每层可追踪
训练成本	数百万美元	数千美元

整个MSM流水线总参数量约6.75B，可以在单张GPU上运行，每次调用成本仅为几分钱。

MSM的最大优势在于其模块化架构。每个层都是一个独立的模型，通过标准化的接口协议进行通信。这意味着：

• 独立升级：当更好的翻译模型出现时，只需替换翻译层，其他层完全不受影响
• 领域定制：不同业务场景可以为特定层配置专用模型，如医疗场景使用医学术语优化的分类模型
• 快速迭代：新功能的添加不需要重新训练整个系统

每个部署都通过一个YAML格式的Manifest文件声明配置，清晰记录每层使用的模型版本、微调状态和数据集来源。

MSM的设计是领域无关的，同一个六层流水线可以服务于各种垂直场景：

餐饮电商：处理订单、追踪配送、取消订单等全流程 医疗分诊：症状评估、分诊路由、患者沟通 体育预订：场地预约、课程安排、会员管理

每个领域只需创建一个新的Manifest配置文件，定义该场景下各层使用的专用模型即可。

MSM提供了完整的TypeScript实现，开发者可以通过简单的API注册和组合各层：

const pipeline = new Pipeline();
pipeline.register(new TranslationLayer());
pipeline.register(new ClassificationLayer());
// ... 注册其他层
const trace = await pipeline.run({ raw: "用户输入", modality: "text" });

框架内置了CLI工具支持演示运行、Manifest验证和完整追踪输出，方便开发和调试。