MoE4All——20MB 的本地推理引擎：显存/内存/SSD 三级协同，让游戏显卡跑起超显存大模型

本地跑大模型这件事，卡人的从来不是模型，是显存。

你手里那张 16GB 的游戏显卡，跑个 7B、14B 的稠密模型还算体面；一旦想碰 Qwen3.8-Flash-Next 这类千亿级的 MoE 模型，模型文件动辄一百多 GB，显存直接爆表。于是要么加钱上 24GB、48GB 的卡，要么老老实实把数据传上云。

今天五哥要给大家介绍的 MoE4All，走的是第三条路：让显存装不下的专家权重，按需从内存和 SSD 里「流」进来，而计算始终交给 GPU。它不是又一个「把模型切成几块丢进内存跑」的土办法，而是一套 Vulkan 优先、Rust 编写的完整推理引擎——顺带把视觉、Embedding、语音转录和语音合成也塞进来了。

一句话概括：一个约 20MB 的轻量本地推理引擎，显存、内存、SSD 三级协同，让消费级显卡跑起远超显存容量的 MoE 大模型；AMD、NVIDIA、Intel 通吃，Windows / Linux 开箱即用，自带 OpenAI 兼容 API，Claude Code、Cursor、DSH 都能直接接上。

📌 先看成绩单

比起那些两个月冲到几万星的爆款，MoE4All 目前还处在「三百多星」的成长期，属于典型的小而硬的技术项目。它没有靠话题出圈，靠的是一件事：别人让 AMD 用户去装 ROCm，它直接给你一个解压就能跑的包。

这一点很重要。你在 Linux 上装过 ROCm 就知道那是什么体验——内核版本对不上、驱动装完掉显示器、PyTorch 的 wheel 还要挑 CUDA / HIP 版本。MoE4All 的做法是：不用装 ROCm、不用装 PyTorch、不用装 CUDA 工具链，只需要显卡驱动正常，配置 Vulkan 后端直接跑。对 AMD 用户来说，这几乎是「终于有人管我们了」。

🖥️ 它到底解决了什么问题：显存有限，模型不必

要理解 MoE4All，得先说清楚 MoE 模型的特点。

MoE（Mixture-of-Experts，混合专家）模型的参数量看着吓人，但每生成一个 token，只有一小部分专家会被激活。比如 Qwen3.8-Flash-Next 这类模型，主参数上百 B，实际每步只用到几个 B。也就是说：大部分权重在那一刻是「闲着的」。

传统推理框架的逻辑是：全部权重必须躺在显存里，否则没法算。模型 180GB、显存 16GB？直接没戏。

MoE4All 的调度思路则是分三档：

• 🧠 常驻显存（VRAM）——固定权重、控制资源，以及当前最热门的专家，留在显存里；
• 💾 按需从内存（RAM）取——大部分专家全集住在系统内存，命中不高的专家从这里热交换进显存；
• 💽 冷数据沉到 SSD——内存都不够装的超大模型，把不常用的部分放到固态盘，真正用得到才读上来。

关键在于两个细节：

第一，计算仍然在 GPU 上完成。它不是把整层计算挪到 CPU 上跑（那样速度会崩），而是只把「权重搬运」交给 CPU / 磁盘，算力还是吃显卡。

第二，谁来搬专家，是动态决定的。在支持 GPU 驻留的 Decode 路径里，GPU 自己维护专家驻留和 LRU 淘汰策略——能自己 DMA 拿到的专家，GPU 直接搬；拿不到才通知 CPU 上传。Prefill（处理长输入）阶段则把分块、专家加载与计算重叠起来，尽量让「等数据」的时间和「算」的时间叠在一起。

换句话说：你不是在用一张更大的显卡，而是在用一张被「喂得很聪明」的显卡。

所以性能不只看模型总大小，而是取决于一组实实在在的硬件指标：激活参数量、量化格式、显存命中率、上下文长度，以及 PCIe 带宽、内存频率、SSD 随机读速度。这也是为什么同一个模型，换台机器速度能差一倍——MoE4All 官方文档没有把话说圆，反而把这些变量摆到了明面上。

📊 实测数据：RX 7900 XTX 跑 35B，154.6 tok/s

官网给出的参考配置是 RX 7900 XTX 24GB + Ryzen 5 5600X + 64GB DDR4 + Windows 11，使用「自动激进」资源配置、Q8 K/V，关闭 MTP 与 CPU miss。这个配置很「玩家」——不是什么 H100 服务器，就是一套两万块以内的家用主机。

怎么读这张表：

• Prefill 三千 tok/s，意味着你贴一篇一万字的长文档进去，几秒钟就处理完，不用干等；
• Decode 154.6 tok/s 是单路生成速度，已经超过大多数人阅读的速度（约 5-10 字/秒），日常对话完全感觉不到「它在算」；
• x4 合计 248.3 tok/s，这是多路并发的总吞吐。对开多个 Agent 跑任务、或者自建一个团队内部 API 的场景，这个数字比单路速度更有意义；
• 上下文拉到 150K 后单路掉到 65 tok/s——这不是失效，而是正常现象：上下文越长，KV 越大，显存里能留给专家的空间越少，命中率下降，速度自然回落。这个降幅放在「24GB 显存跑 35B 模型」的前提下，是可以接受的。

官方还提供了一个很「老实」的设计：向导内置 Benchmark，快速测 6K、标准测 6K / 30K、完整测 6K / 30K / 150K，每路预热 512 token，正式生成 1,024 token，结果按前段 / 中段 / 后段分段展示。测完可以存本地报告，也可以自愿上传到社区排行榜，不需要注册账号。

这一点值得单独夸一句：很多项目宁可放一张好看的图，也不肯把测试条件写清楚。MoE4All 把「怎么测的」和「在什么配置下测的」全摊开了，还允许用户把结果传上去做横向对比——敢让人复现的项目，数据才可信。

⚡ 不只是跑 LLM：一个引擎，五种能力

这部分是很多人容易忽略的。MoE4All 不是一个「只跑语言模型」的壳子，它把本地 AI 常用的几块能力做成模块，共享同一套显存管理：

设计上有几个点挺讲究：

• 视觉权重按请求加载，用完可以卸载；Embedding 空闲后能释放。也就是说你不用为了看图再起一套长期占显存的引擎，图片处理完，显存还给你聊天用。
• 语音模块走独立 CPU 资源，完全不碰语言模型的显存池。转写一段一小时的会议录音时，你仍然可以正常聊天。
• Embedding、转录、合成都能单独启动，不加载大模型也能当 RAG 的向量服务、当语音工具用。

对折腾知识库的人来说，这一条价值不小：一个进程里同时把「生成 + 检索 + 语音」跑完，比装三套服务省心太多。

🤖 接上 Claude Code 和 Cursor：OpenAI 兼容 API

工程上最省事的一点：MoE4All 启动 API 服务后，直接暴露一个 OpenAI 兼容接口，默认地址是：

http://127.0.0.1:8080/v1

你只要把这个地址填进任何支持 OpenAI 协议的客户端，模型 ID 从 GET /v1/models 里挑一个就行。四个核心接口覆盖了全部能力：

这意味着：Claude Code、Cursor、Cline、Cherry Studio、Open WebUI、AnythingLLM 这些工具，基本都能直接接上，代码不用改一行，把 Base URL 换掉就行。局域网里想给全家人的设备用，在向导里把监听地址改成 0.0.0.0 再加个 API key 即可。

另外，如果你在 Anthropic 生态里混（比如用 Claude Code），社区有 Anthropic 协议转换的中间件可以叠一层——不过从「本地、可控」的角度，OpenAI 协议这条路更简单。

它还有官方收录的 DSH（DeepSeek Harness）接入插件，已经被 Awesome DSH Plugin、DSH.so、DSH Market 三个站点收录。装了插件之后，可以在 DSH 里直接管理引擎、下载和选择模型、看实时速度，插件内还能自动安装引擎（目前限 Windows），其他系统连接已有 API 服务。另外还有 MoE4All Agent——把模型、工具、插件组织成桌面工作台，带记忆、定时任务、手机远程访问，目前是独立的 Windows 版入口。这块是项目里比较新的部分，成熟度还要再观察。

🛠️ 三步跑起来，真的不用装环境

整个安装过程可以概括为「下载 → 解压 → 双击」。

第一步，下载对应系统的包。打开 最新发行版：

第二步，打开向导，选用途。向导里依次选择：用途（本机聊天 / API 服务 / Benchmark 测速）、模型、计算设备、资源策略。资源策略里有两个选项值得注意：

• 自动保守：适合后台还开着浏览器、微信、PR 渲染的场景，会给别的程序留出资源；
• 自动激进：能占多少占多少，优先性能。上面的实测数据就是在这个模式下跑出来的。

Windows 上的向导是原生窗口界面，配置、启动、看日志都在一个窗口里完成，不用和黑框框搏斗。

第三步，准备模型。向导里可以直接下载推荐模型，也能导入已有的 GGUF 文件。官方给了一张「药方表」：

引擎还实现了 Qwen、Llama、Gemma、Ling、DeepSeek 等家族的运行路径，不同家族的视觉、KV、MTP 能力各有差异，官方有一张能力矩阵表可以对照。这里提醒一句：并不是所有 GGUF 都能开满特性，动手前先查矩阵表，能少踩很多坑。

第四步（可选），API 调用。服务起来之后，一行 curl 就能验证：

curl http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "YOUR_MODEL_ID",
    "messages": [{"role": "user", "content": "介绍一下你能帮我做什么。"}],
    "stream": true
  }'

特别注意：Linux 和 macOS 没有 Windows 那样的一体化窗口，用命令行向导；Apple Silicon 的 Metal 版本还是实验性质，未做 Apple 公证，第一次运行前可能需要移除隔离标记：

xattr -dr com.apple.quarantine /path/to/MoE4All-macOS-arm64-vVERSION

⚠️ 劝退指南：什么情况下别用

吹完了，说点实在的。MoE4All 不是银弹，下面几种情况建议换个思路：

• 想要「量化后也要接近原精度」的旗舰效果——它的定位是「让跑得起优先于跑得极致」，配合 4-6bit 量化后在消费级硬件上确实能跑，但工业级高精度推理还是服务器框架的活儿。
• 机器内存太少——这套方案吃的就是「内存 + SSD」这条缓冲带。只有 16GB 内存却想跑 100B+ 的模型，命中率会低到怀疑人生，速度不如换个小模型。
• 你的盘是机械硬盘——SSD 是三级协同里的最后一档，机械盘随机读会直接把 Decode 拖成个位数。
• 多用户高并发生产环境——它的强项是「单机、多路」而不是「集群、大规模」。真要给几十个人同时服务，vLLM、SGLang 那类框架在调度与小批量吞吐上更成熟。
• 只想点一下就能用的普通用户——虽然向导是图形化的，但你仍然需要理解「模型、量化、上下文、资源策略」这几个概念。它面向的是愿意动手折腾的人。

🧭 和 llama.cpp、vLLM 比，位置在哪

说句公道话：MoE4All 的根基是 kryptic-sh/infr，它在上面加的是工程化和产品化——自动资源规划、图形向导、多平台打包、社区排行榜、完整文档体系。这类「把硬核内核做成能用产品」的工作，往往比写内核本身更枯燥，也更稀缺。

📖 五哥的话

本地方案这两年最大的变化，不是模型变强了，而是「跑得动」的门槛在往下掉。MoE4All 属于这一波里思路很正的那类：不去硬拼算力，而是承认硬件就这么多，然后想办法让「闲置的权重」不占着显存不走。

它目前的短板也很清楚：星数还不高、Mac 版还在实验、Agent 部分刚起步、中文文档虽然在补齐但深度页仍有英文。但如果你手里正好是一张 16GB 或 24GB 的 A 卡 / N 卡，一直想跑一个 30B 以上、能看图的模型，又懒得折腾 CUDA 那套环境——先下这 20MB 试试，是这个项目最划算的用法。

• 项目地址：github.com/Headmaster218/MoE4All
• 官网与性能演示：moe4all.com
• 文档中心：documentation/README.md
• 最新发行版：Releases

遇到问题报 Issue 的时候，记得把模型名称、运行配置、启动日志和复现步骤一起贴上——这项目对可复现的反馈响应挺快。