你可以把显存想成厨房台面：离厨师最近，取东西最快，但地方有限。系统内存则像旁边的储物柜，容量更大，拿取却更慢。运行超大模型时，过去常见的麻烦是：即使有些参数暂时不用，也得先占住宝贵的“台面”。一位 Reddit 用户展示的新方案，正试图把部分参数移进“储物柜”，需要时再取。
这里涉及 MoE——“专家混合”模型。它内部有多组擅长不同任务的参数，也就是“专家”；每次计算通常只调用其中一部分。问题在于，没被调用的专家往往仍会常驻显存。所谓专家卸载，就是把暂时不用的专家权重放进系统 RAM，只让活跃计算留在 GPU。这样有望降低显存门槛，代价则可能是 GPU 与 RAM 之间搬运数据带来的等待。
需要先说明：目前全部信息都来自 Reddit 用户 sloptimizer 的一篇帖子。帖子使用的是 tcclaviger/vllm 镜像，现有材料不足以确认这项能力已经进入 vLLM 官方稳定版本，也没有独立复现或性能测试。
它到底做了什么？
vLLM 是一个用于大语言模型推理和服务的开源引擎。帖子中的启动命令加入了 --enable-expert-offload，用于开启专家卸载；同时设置 --expert-offload-mem 160，为这项功能指定内存配置。参数值是 160，但帖子摘录没有明确交代单位，因此不能把它写成经官方确认的 160 GB 实际占用。
发帖者称，自己借此在四张 R9700 GPU 上运行了原版 DeepSeek-V4-Flash-Vision-Exp。整套程序通过 Podman 容器启动——容器就是把程序、依赖和运行环境一起封装起来，方便在相对隔离的环境中部署。命令使用的也是 tcclaviger 提供的镜像，而非现有材料能够确认的官方镜像。
这套配置还启用了四路 tensor parallel，即让四张 GPU 分担同一次模型计算；最大上下文长度被设为 256000 tokens。token 是模型处理文字时使用的基本单位，并不简单等同于汉字或单词。需要注意，这只是命令中的配置值，不能证明如此长的上下文已经实际跑通。
此外，命令采用 FP8 KV cache。KV cache 可以理解为模型生成文字时保存的“计算草稿”，避免反复重算；FP8 则用较低精度保存这份草稿，以减少内存压力。配置还打开了 prefix caching、chunked prefill 和 dspark speculative decoding，分别对应复用相同开头的计算结果、分块处理输入，以及用推测方式尝试加快生成。不过帖子没有给出这些功能各自带来的收益。
为什么值得关注？
真正有意思的不是一条很长的启动命令，而是它改变了本地运行 MoE 模型时的资源分配方式：不再要求全部专家都挤进高速但昂贵的显存，而是让显存和容量更大的系统内存分层协作。
如果这种实现稳定可用，前沿 MoE 模型对单机显存容量的要求可能明显下降。对本地用户来说，这意味着原本装不下的模型，或许可以用更多 RAM 换取运行机会。不过，“能装下”和“跑得实用”是两回事。内存搬运可能拖慢推理，最终体验还取决于带宽、调度和实际工作负载。
局限与未知
- 目前只有一篇 Reddit 帖子，无法确认功能是否已进入 vLLM 官方稳定版本。
- 命令只能证明作者声明了这些配置，不能证明服务成功启动、256000-token 上下文可用，或模型输出正确。
- 帖子没有披露速度、吞吐量、显存与 RAM 实际占用，也没有对照测试。现阶段更适合把它视为一条值得跟进的社区实践，而不是已经完成验证的性能突破。