2026年5月1日，vLLM 项目仓库出现了一条值得关注的新 Issue，提出为 MoE（Mixture of Experts）架构模型增加 Expert 动态预取功能。这并非一个简单的功能请求，而是触及了当前大模型推理引擎在显存利用率上的核心痛点。
背景：MoE 的显存困境
MoE 模型通过稀疏激活机制，在参数量上可以远超同级别 dense 模型——典型如 DeepSeek V3、Qwen3 MoE、Gemma 4 等，都是千亿参数级别的 MoE 架构。然而 MoE 的显存占用存在一个结构性矛盾：Expert 数量庞大但每次只激活少数，导致显存中大部分 Expert 处于”热备”状态，无法释放。
vLLM 目前在服务 MoE 模型时，Expert 通常全部常驻 GPU 显存。以一个 8 个 Expert 的 MoE 层为例，假设每个 Expert 占用 2GB，即使一次只用到 2 个，剩余 6 个 Expert 仍然占用着 12GB 显存。这对于多实例部署和长上下文场景来说是巨大的浪费。
提案核心：–moe-gpu-prefetch
Issue #41447 提议在 vLLM 中引入 --moe-gpu-prefetch <num> 参数，允许用户控制预取的 Expert 数量。其设计思路是：
- 参数意义：
num指定除了当前激活 Expert 外，额外预加载到 GPU 的 Expert 数量 - 显存换速度：适度预取可以减少从 CPU/NUMA 远端内存拉取 Expert 的延迟
- 动态调节：用户可根据显存预算灵活配置，找到最优的 prefetch 数量
# 示例：仅预取 2 个额外 Expert（当前激活2个 + 预取2个 = 4个在GPU）
vllm serve deepseek-ai/DeepSeek-V3 --moe-gpu-prefetch 2实现分析：现有代码基础
vLLM 近期已经在 MoE 方面做了大量优化工作：
- v0.20.0 完成了 DeepSeek V4 的初始支持
- FlashInfer FP8 async TP fusion 已合入，优化了 MoE 的计算融合
- Gemma4 MoE GELU kernel 在 TRT-LLM NvFP4 上的支持
当前 MoE 的 GPU 调度逻辑位于 vllm/moe/ 目录，Expert 的加载由 MoEGPTKernel 或 FlashInferMoEKernel 处理。提案的实现需要在调度层面增加 prefetch 队列，结合模型层数的 Expert 总数动态分配 GPU/Host 内存。
价值与局限
价值：
- 多实例场景下可显著提升 GPU 利用率
- 对 DeepSeek V3、Qwen3.5 MoE 等国产模型有直接收益
- 与已有的 KV Offload、UMA 显存优化形成互补
局限：
- 预取本身有延迟开销，
num设置过大会抵消收益 - 对单 Expert 模型（无 MoE）无效果
- 需要与应用场景（长/短推理）配合调优
延伸：国产 GPU 的特殊挑战
值得注意的是，国内 Ascend NPU 等硬件对 MoE 的支持仍在完善中。DeepSeek V3 近期合入了华为 Ascend NPU 支持模式，但在 Expert 调度层面与 NVIDIA GPU 存在架构差异。--moe-gpu-prefetch 若要支持国产硬件，需要针对 NPU 的内存层次重新设计预取策略。
总结
vLLM 的 MoE Expert 预取提案代表了推理引擎从”粗放显存管理”向”精细化控制”的演进方向。随着 MoE 模型逐渐成为主流（DeepSeek V4、Qwen3 MoE 乃至即将发布的 Llama 4 MoE），显存效率将成为各家推理框架竞争的关键战场。这一提案值得关注和跟进。
评论区