将大型稀疏专家混合（MoE）模型部署到生产环境，与密集模型相比，带来了独特的架构难题。专业批处理和模型压缩等技术能解决计算效率问题。然而，MoE的基本结构，凭借其独特的路由层和众多专家模型，需要特定的部署模式来有效管理资源分配、网络通信和整体推理 (inference)延迟。选择合适的模式很大程度上取决于预期的流量模式、延迟要求、成本限制以及训练好的 MoE 模型的具体特点。
专家模型同地部署
专家模型同地部署模式可能是分布式训练设置最直接的扩展。在这种方式下，分配给特定推理 (inference)工作器（或工作器组）的专家模型，驻留在相同的物理计算节点上。当推理请求到达时，路由层确定目标专家模型，令牌数据由该工作器本地或其紧密连接组内（例如，通过 GPU 的 NVLink）可用的专家模型进行处理。
在这种专家模型同地部署模式下，路由层和一部分专家模型驻留在同一个工作节点上，从而最大程度地减少了专家模型计算的网络延迟。
优点：
- 较低的网络延迟： 路由层与专家模型之间的通信主要发生在节点内部或通过高速互连进行，与分布式专家模型相比，最大程度地减少了网络开销。
- 基础设施简化： 通常与为分布式训练和推理设计的框架（例如 DeepSpeed Inference、FasterTransformer）匹配良好，可能简化部署设置。它采用训练期间建立的张量并行和专家并行等思想。
缺点：
- 资源粒度： 扩展与工作节点绑定。如果只有少数专家模型需要明显更多的计算资源，您可能需要扩展整个工作节点，这可能导致资源利用效率低下。
- 静态专家分配： 专家模型通常静态分配给工作器，如果流量模式导致驻留在不同节点上的专家模型之间负载不平衡，这可能不是最佳选择。
专用专家服务
另一种模式是将专家模型从主模型执行中解耦，并将其部署为独立的微服务或专用服务实例。主推理 (inference)服务处理非 MoE 层和路由逻辑。当需要专家模型计算时，路由层通过网络向相应的专用专家服务发送请求（包含相关令牌）。
在这种专用专家服务模式下，专家模型作为独立服务部署，并通过主推理服务中的路由层进行网络调用访问。
优点：
- 独立扩展： 专家模型或专家模型组可以根据其具体负载独立扩展，从而实现更细粒度且可能更具成本效益的资源分配。对于使用频率较低的专家模型，您可以使用不同的硬件（例如，较小的实例、CPU）。
- 故障隔离： 与同地部署模型相比，一个专家服务内部的问题不太可能影响整个推理过程。
缺点：
- 增加网络延迟： 主要缺点是路由层和专家服务之间的网络通信会增加延迟。这对于对延迟敏感的应用程序可能很明显。需要高吞吐量 (throughput)、低延迟的网络。
- 基础设施复杂性： 管理多个独立的服务（主模型 + 众多专家服务）会增加部署和操作的复杂性。需要对专家服务进行服务发现和负载均衡。
混合与分层方法
更高级的模式结合了同地部署和专用服务的特点。例如：
- 分层专家模型： 经常访问的（“热”）专家模型可以与路由层同地部署以实现低延迟，而访问频率较低的（“冷”）专家模型则部署为专用服务，以优化成本。
- 区域专家模型： 如果专家模型专长于区域特定数据或语言，则可以将其部署在地理上更接近相关用户的位置，并通过由中央路由层指导的专用服务进行管理。
这些混合模型旨在平衡延迟、成本和可扩展性之间的权衡，但会在路由逻辑和基础设施管理中引入进一步的复杂性。最佳选择取决于对专家模型使用模式和应用要求的详细分析。
部署平台考量
无论选择何种模式，使用模型服务平台都很重要。像 NVIDIA Triton Inference Server、TorchServe 或 TensorFlow Serving 这样的工具，可能通过自定义后端或适配器进行扩展，可以提供基本功能：
- 动态批处理： 聚合请求以提高硬件利用率，这对于路由层和专家模型都重要。平台通常需要定制以处理 MoE 特定的批处理，因为批处理中的令牌可能针对不同的专家模型。
- 请求管理： 处理排队、优先级和并发。
- 监控和日志： 提供性能指标、专家模型利用率和潜在瓶颈的可视性。
- 协议支持： 支持 gRPC 或 HTTP/REST 等标准通信协议，这在专用专家服务中尤为相关。
在使用这些平台服务 MoE 时，请确保它们能高效处理将令牌路由到可能分布式的专家模型并聚合结果中固有的分散-收集通信模式。这可能涉及自定义 C++ 或 Python 后端，或使用服务器内为集成或业务逻辑脚本设计的功能。
选择合适的模式
选择过程涉及分析几个因素：
- 延迟敏感性： 实时应用程序倾向于同地部署或分层方法，以最大程度地减少网络跳数。
- 专家模型负载分布： 高度倾斜的专家模型使用模式可能受益于专用专家服务的细粒度扩展。均匀的使用模式可能非常适合同地部署。
- 成本预算： 专用服务可以通过为每个专家模型选择合适大小的实例来节省成本，但会产生网络费用。同地部署可能需要更大、更昂贵的实例，但能简化网络。
- 操作复杂性： 同地部署通常在初始阶段更易于管理，而专用服务需要更复杂的编排和网络管理。
- 现有基础设施： 使用现有 Kubernetes 集群、服务网格或特定服务平台会影响可行性。
最终，部署大型稀疏模型通常涉及迭代改进。从更简单的模式（例如，如果使用支持性框架，则采用同地部署）开始，然后根据生产监控数据和性能分析进行改进，是一种常见的策略。能够跟踪令牌流、专家模型利用率和网络延迟的分析工具，对于优化这些复杂的部署必不可少。
