Helldez/BigMoeOnEdge

项目介绍

BigMoeOnEdge 解决的是「模型比内存大」的问题：MoE 模型每个 token 只激活少量专家，引擎因此把每个 token 都需要的权重和最常用的专家留在内存里，其余专家按需从闪存读取。项目声称输出与整模型驻留内存时一致，并基于 llama.cpp 的公开 API 实现，现有 GGUF 量化、tokenizer 和对话模板无需改动即可使用。主要面向手机、笔记本和消费级显卡，同一套代码也能跑在数据中心卡上。交付形态包括桌面应用、Android/iOS 应用以及 CLI 和服务端程序，--auto 规划器会测量硬件并自动决定缓存大小、线程数和设备分工（工作原理）。

快速使用

先准备一个 MoE 格式的 GGUF 模型，再从最新发布版安装命令行工具：

curl -fsSL https://github.com/Helldez/BigMoeOnEdge/releases/latest/download/install.sh | sh

Windows 上改用 PowerShell：

irm https://github.com/Helldez/BigMoeOnEdge/releases/latest/download/install.ps1 | iex

让规划器自行选参数并跑第一个提示词：

bmoe-cli -m model.gguf --auto -p "Explain MoE routing."

bmoe-cli -m model.gguf --plan 只打印规划结果、不生成内容。若要让其他工具调用模型，启动服务端，它同时在 8765 端口提供网页界面；各平台应用可从最新发布版获取：

bmoe-server -m model.gguf -c 32768

服务端兼容 OpenAI 和 Anthropic API，OpenAI SDK 客户端可指向 http://127.0.0.1:8765/v1。上下文长度设置和编程 Agent 接入方式见服务端 API 文档。

使用约束

• 只对流式读取 MoE 模型有效；哪些张量属于专家从 GGUF 文件读取，非 MoE 模型或识别不出专家的模型可能用不上这套机制（哪些模型可流式）。
• 速度强依赖存储和内存。README 的表格给出 12 GB 手机上 Qwen3.6-35B-A3B 约 5-6 tok/s、16 GB Apple 芯片笔记本约 18-24 tok/s，这些是特定机器的测量值，不是通用保证。
• 各平台安装成本不同：macOS 构建尚未公证，iOS 需要从 Xcode 自行构建且标注为实验性，Linux 窗口依赖 WebKitGTK 4.1（平台支持）。
• 编程 Agent 需要较大上下文，README 称 opencode 用 32768 足够、Claude Code 需要 65536（上下文尺寸）。
• 许可证为 Apache-2.0，捆绑的 llama.cpp 等第三方组件按各自条款分发（THIRD_PARTY_LICENSES）。

HotRepo 点评

在 2026-11-14 的 C++ 日榜上，该项目以当日新增 17 Star 排到第 7，说明一个 llama.cpp 之上的内存流式前端在当天 C++ 条目中处于前列。README 最有辨识度的不是某一项技巧，而是覆盖面：同一套流式引擎覆盖 Android、iOS、macOS、Windows 和 Linux，后端包括 CPU、Metal、CUDA、HIP、Vulkan、OpenCL 和 Hexagon，并配有自动规划器。这个范围值得持续观察，但速度数据是特定内存和存储配置下的第一方测量，应视为单机观测值，而不是任意硬件上的预期表现。