MoE模型推理挑战 - 现有主流MoE推理框架扩展性差，要求使用大规模同步通信组部署模型，一次性占用大量GPU资源，导致弹性资源伸缩困难，资源供给无法按用户流量精细调整，造成浪费[2] - 传统MoE推理容错性低，采用全局紧耦合架构，各GPU间通过All-to-All等大规模集体通信协同工作，任意节点故障可能导致整个服务集群重启，缺乏容错能力[3] - 负载不均问题突出，MoE专家调用动态稀疏，激活分布随工作负载波动，固定专家映射和资源分配策略难以适应，导致部分GPU过载而其他闲置，资源利用低下[4] EaaS架构创新 - 提出专家即服务架构，将每个专家拆分为独立无状态服务模块，专家不维护会话状态，仅根据请求计算输出，使模型由许多可独立扩展服务组成，支持精细扩展，初始部署可小至16块GPU起步，支持一次增减一块GPU匹配负载需求[7] - 实现Attention层与专家层解耦，二者通过高效通信机制衔接，减少全局同步点，Attention端可异步等待专家结果并处理下一批次计算，提升流水线利用率，且Attention和专家可独立扩展[10] - 研发高性能异步通信库IBGDA，基于InfiniBand GPUDirect Async技术，实现GPU直连网络通信，完全绕过CPU参与，支持单边RDMA操作和灵活缓冲管理，突破NCCL等通信库需整组同步的限制，结合CUDA graph实现CPU-free数据传输[14] - 引入动态负载均衡策略，当监测到某个专家请求频率过高时可动态增添实例分摊流量，对冷门专家减少实例以节省资源[14] 系统性能优势 - 在扩展能力实验中，随GPU节点从32增加到64，EaaS总吞吐量几乎按比例提升，支持任意数量GPU部署组合，打破传统架构对GPU数量整除比要求，实验显示可实现同等性能下最高约37.5%的GPU资源节省[18] - 容错性卓越，模拟故障场景中随机失效GPU节点时，EaaS几乎不中断完成请求处理，吞吐量仅略微下降不到2%，而传统方案任一节点故障都会使整个组停止服务[20] - 实现高吞吐与低延迟兼顾，端到端推理吞吐量与现有最优系统相当，响应延迟稳定，每个token平均生成延迟维持在较低水平，在吞吐-延迟权衡上达到优秀平衡[22] - EaaS通信库通过IBGDA高效通信模式与CPU-free结构支持的CUDA graph带来kernel launch开销overlap，最多将延迟降低49.6%[24] 应用前景 - EaaS细粒度资源调配能力使云服务商可根据实时负载弹性调整MoE模型算力分配，以更低成本提供稳定可靠推理服务，非常契合云计算环境下的多租户和持续交付需求[25] - 服务化架构具有良好的可运营和可演化特性，模块化专家服务便于独立升级维护，通信调度组件可逐步优化迭代，使系统能随模型规模和应用需求变化不断演进[25]