colibri 在自有硬件上运行前沿 MoE 模型
本文目录
colibri#
小引擎,大模型。colibri 在你已有的机器上运行非常大的开放模型。拥有数千亿参数的混合专家(Mixture-of-Experts)模型在每个 token 上只使用自身的一小部分,因此 colibri 将那部分保留在 RAM 中,并在模型需要时从磁盘读取其余部分——也就是专家(experts)。纯 C 实现,每个模型系列一个文件,无需 GPU。
目前有十三个引擎在运行。其中十个用于语言模型:GLM-5.2/5.3(它也能运行 Mistral-Large-4)、GLM-5.3-Flash、Inkling、Kimi K3、DeepSeek V4 Flash、DeepSeek V4.1 Flash、MiMo-V2.6 Flash(及 Pro)、Qwen3.8-Flash-Next、Qwen3.6(它也能运行 Qwen3-Coder、稠密模型 Qwen3.8-27B、Flint、Muse Spark Open 和 LFM3-VL)以及 OLMoE。一个用于画图:Qwen-Image-2.1。两个用于回答决策:Laya 和 GLiNER2.5-Decide,第三个决策模型 Clef 运行在 Qwen3.6 引擎上。这些语言模型也可以直接读取已发布的 GGUF 文件,按原样读取(GGUF),在 CPU 上、通过 Vulkan 在任何 GPU 上、以及通过 CUDA 在 NVIDIA 显卡上运行。
哪一款适合我的机器
$ ./coli chat
colibri v2.1.0 · GLM-5.2 · 744B MoE · int4 · streaming CPU
✓ ready in 32s · resident 9.9 GB
› ciao!
◆ Ciao! Come posso aiutarti oggi?
colibri 免费且开源。如果它已经在你的机器上赢得了一席之地,一杯咖啡可以帮助支付下一个引擎和下一次加速的开发费用。
一步开始#
你至少需要一台有 8 GB RAM 的电脑(16 GB 或更多更好)、最小的模型需要 22 GB 可用磁盘空间,以及互联网连接。显卡可选。
Windows#
在此页面点击 Code,然后点击 Download ZIP,并解压。
双击解压文件夹中的 START-HERE.bat。如果缺少 Python,它会提供安装选项。
Linux(Ubuntu 和 Debian;其他发行版有相同软件包,但名称不同)#
sudo apt install git python3 build-essential
git clone https://github.com/JustVugg/colibri
cd colibri
./start-here.sh
macOS(使用 Homebrew)#
xcode-select --install
brew install libomp git python
git clone https://github.com/JustVugg/colibri
cd colibri
./start-here.sh
你回答一个问题——哪个模型——按 Enter 接受推荐。然后设置会:
- 检查你的机器:RAM、可用磁盘、CPU 和 GPU;
- 推荐一个合适的模型:始终驻留在 RAM 中的那部分模型,加上最低限度的专家缓存,必须能装入你的 RAM,并且下载文件必须能装入磁盘;
- 获取引擎:如果存在编译器,它会为你的机器构建引擎;否则下载预构建版本,该版本在 CPU 上运行,在 Linux 和 Windows 上也可在 Vulkan GPU 上运行。当这样做划算时,它会为你的 GPU 构建:在 Linux 上,如果安装了 CUDA 工具包,则为 NVIDIA 显卡使用 CUDA,否则使用 Vulkan。在独立显卡上它总是这样做;在共享 CPU RAM 的集成显卡上,只对在那里测得更快的模型(Qwen3.6、Qwen3-Coder 和 Qwen3.8-Flash-Next)这样做。如果缺少某个软件包,它会打印确切的安装命令并继续使用 CPU;之后再次运行设置,它会为 GPU 重新构建;
- 下载模型并支持进度和断点续传:随时停止,再次运行就会从停止的地方继续;
- 启动 colibri 并在浏览器中打开仪表板,同时打印其他应用可以使用的地址:
Starting colibri
Browser: http://127.0.0.1:8000/
OpenAI base URL: http://127.0.0.1:8000/v1
Anthropic base URL: http://127.0.0.1:8000
stop: press Ctrl+C here (or close this window)
下次,再次运行 START-HERE.bat 或 ./start-here.sh:colibri 会直接启动,无需下载和构建。c/coli status 显示已安装的内容以及是否运行,c/coli stop 停止它(Windows 上是 c\coli.cmd status 和 c\coli.cmd stop)。
选项放在 ./start-here.sh 或 START-HERE.bat 之后:
| 选项 | 作用 |
|---|---|
--list | 针对本机列出每个模型,以及某个模型不合适的原因 |
--model ID | 安装该模型(ID 见下表) |
--yes | 不再提问:采用推荐 |
--dir DIR | 将模型放在另一个磁盘(默认 ~/colibri-models) |
--backend vulkan、cuda 或 cpu | 自行选择引擎构建;--no-gpu 等同于 --backend cpu |
--model-dir DIR | 使用你已经下载的模型 |
--reconfigure | 选择另一个模型 |
每个步骤的详细说明:docs/quickstart.md。
如果出了问题#
| 你看到 | 该怎么做 |
|---|---|
| 下载过程中停止了 | 再次运行同一命令:它会从磁盘上已有的字节继续 |
to use the GPU through ..., first run: <command> | 运行该命令,然后再次运行设置:它会为 GPU 重新构建,不会重新下载 |
the ... build failed, for example Unsupported gpu architecture,当安装的 CUDA 工具包不再支持该显卡时 | 设置会先检查工具包与显卡是否匹配,并自行选择 Vulkan,同时说明原因;如果构建仍然失败,它会提供下一个选项(Vulkan,然后是 CPU)。./start-here.sh --backend vulkan 强制使用 Vulkan;--no-gpu 保持在 CPU 上 |
needs N GB free for the download | 使用 --dir 指向更大磁盘上的文件夹 |
在 WSL 上,模型文件夹位于 /mnt/c 下 | 保持在 Linux 磁盘上(默认 ~/colibri-models):/mnt/c 会慢很多倍 |
你更新了检出(git pull) | 再次运行 ./start-here.sh:当源码变化时它会重新构建引擎,然后启动 |
| 其他任何情况 | c/coli logs -n 50 显示后台启动的服务器的日志(前台启动的服务器会打印到自己的终端),c/coli logs --install 显示设置的日志;带上设置打印的最后几行开一个 issue |
让你的 AI 助手来设置#
如果你使用 AI 编程助手,它可以为你完成所有这些。请它:
按照 https://github.com/JustVugg/colibri 的 docs/AI_SETUP.md 在这台机器上设置 colibri
docs/AI_SETUP.md 将每一步都以带有机器可读结果的命令形式交给助手,并告诉它在下载模型或安装系统包之前先询问你。支持模型上下文协议(Model Context Protocol)的助手可以改用 colibri 的 MCP 服务器:coli mcp 提供检测硬件、推荐模型、安装、启动、停止和检查的工具(docs/MCP_SERVER.md)。
或者手动操作#
要自己选择每一步(预构建发布版或源码构建,下表任意模型,然后 coli chat、coli web 或 coli serve),请参阅手动安装,或查看针对每个平台逐步说明的快速开始指南。
colibri 是什么,以及为什么#
混合专家模型在磁盘上很大,但每 token 很小。GLM-5.2 有 744B 参数,每个 token 使用约 40B,其中只有约 11 GB 会从一个 token 到下一个 token 发生变化:路由专家(routed experts)。
因此,模型不必装入快速内存;它必须被放置。稠密部分(注意力、共享专家、嵌入)留在 RAM 中。路由专家留在磁盘上,当路由器需要时被读取,通过一个学习你的工作使用哪些专家的缓存。如果有 GPU,它保存最热门的专家和稠密层。权重放在哪里只改变答案产生的速度,不改变哪些权重或哪些路由器决策产生它。
为什么:在人们已经拥有的硬件上运行这种规模的模型,观察它们工作(仪表板显示每个专家被触发),并让引擎足够小,任何人都能测量它并让它更快。colibri 也是一个开放研究平台:一项优化只有通过可复现的端到端测量才能赢得一席之地,默认策略绝不会悄悄改变模型精度或路由器语义。更少的快速内存可能带来速度损失;它绝不能悄悄重新定义模型。工作原理部分有细节。
哪个模型适合我的机器#
设置会推荐能在你的机器上从 RAM 运行的最强模型,并在其下方列出从磁盘流式读取的更大模型。./start-here.sh --list 会针对你的机器显示全部模型。表格遵循设置自己的目录(c/setup_catalog.py);下载大小是 Hugging Face 为每个仓库列出的大小。
RAM 是两个数字:低于第一个数字,模型无法启动;从第二个数字起,模型按实测结果运行。
GPU 是设置可以为该引擎构建的 GPU(GPUs)。“也支持集成显卡”表示它也会使用集成 GPU(在这些引擎上测得速度更快);其他引擎只使用独立 GPU。
实测是在指定机器上测得的结果,聊天模型为解码速度。字母是表格下方列出的机器。空白表示尚无人测量。
小模型(从 RAM 运行)#
| 模型 | --model | 下载 | RAM | GPU | 实测 |
|---|---|---|---|---|---|
| Qwen3.6-35B-A3B:带思考和工具的聊天 | qwen36-35b | 23 GB | 10 / 20 GB | CUDA、Vulkan(也支持集成显卡) | CPU 上 6.0 tok/s,集成 GPU 上 Vulkan 9.9(A);CUDA 30.0(C) |
| Qwen3-Coder-30B-A3B:代码和工具调用,无思考 | qwen3-coder-30b | 19 GB | 8 / 18 GB | CUDA、Vulkan(也支持集成显卡) | 所有专家在 RAM 中时 8.5-9.6 tok/s,每层 32 个专家时 5.1(A,CPU) |
| Qwen-Image-2.1:文本转图片,非商业许可 | qwen-image-2.1 | 33 GB | 12 / 18 GB | Vulkan | 一张 768x512 图片用时 2 分 40 秒(8 核 Zen 4,CPU) |
大模型(专家从磁盘流式读取;磁盘决定速度:快速 NVMe 驱动器帮助最大)#
| 模型 | --model | 下载 | RAM | GPU | 实测 |
|---|---|---|---|---|---|
| DeepSeek V4 Flash REAP 150B:256 个专家中的 132 个 | deepseek-v4-flash-reap | 85 GB | 16 / 32 GB | CUDA、Vulkan | |
| DeepSeek V4 Flash (284B):工具 | deepseek-v4-flash | 167 GB | 16 / 32 GB | CUDA、Vulkan | 32 GB 时 0.93 tok/s(Ryzen 7 5800X),63 GB 时 1.24(Ryzen 9 5950X),仅 CPU;CUDA 下 1.5-1.6(RTX 5080,32 GB,两块 NVMe) |
| MiMo-V2.6 Flash (309B):视觉和工具 | mimo-v2.6-flash | 172 GB | 32 / 52 GB | Vulkan | 2.34-3.37 tok/s(A,CPU) |
| Qwen3.8-Flash-Next (125B + 51B n-gram):视觉和工具 | qwen38-flash-next | 186 GB | 24 / 32 GB | CUDA、Vulkan(也支持集成显卡) | 每层 32-96 个专家时 1.91-2.56 tok/s;可选 int4 专家时 3.99(A,CPU) |
| GLM-5.2 (744B):参考模型,带 MTP 头 | glm-5.2 | 429 GB | 16 / 24 GB | CUDA、Vulkan | 25 GB 笔记本上冷启动 0.05-0.1 tok/s;128 GB Ryzen AI Max+ 395 上 1.83;6x RTX 5090 上 9.0-9.2 |
| GLM-5.3 (744B):同一引擎,无 MTP 头 | glm-5.3 | 419 GB | 16 / 24 GB | CUDA、Vulkan | |
| Inkling (975B):int4 专家,bf16 稠密权重 | inkling | 514 GB | 下载时 120 / 128 GB;稠密转换后 25 GB | CUDA、Vulkan | 0.25 tok/s(Ryzen 9 7900,187 GB,RTX A6000) |
| MiMo-V2.6 Pro (1.02T):视觉和工具 | mimo-v2.6-pro | 564 GB | 54 / 64 GB | Vulkan | 0.66-0.79 tok/s(A,CPU) |
| Kimi K3 (2.8T):最大 | kimi-k3 | 1.56 TB | 32 / 64 GB | CUDA、Vulkan | 每 token 约 9.4 秒,专家读取速度 6.3 GB/s |
手动操作:下载后需要转换或准备步骤#
| 模型 | 下载,然后在磁盘上 | RAM | GPU | 实测 |
|---|---|---|---|---|
| OLMoE (7B):小型,用于学习工具 | 14 GB,转换为 int8 后 7 GB | 8 GB | Vulkan | 22-23 tok/s(A,CPU) |
| Qwen3.8-27B(稠密):文本和图像 | 56 GB,转换后 51 GB | int4 时 20 GB,int8 时 30 GB | Vulkan | int4 时 3.45 tok/s,int8 时 2.1(16 线程 CPU 服务器) |
| GLM-5.3-Flash (321B):视觉和工具 | 328 GB,逐分片转换为 195 GB | 25 GB | CUDA、Vulkan | 热启动每 token 约 20 秒,冷启动 44 秒(6 核,25 GB,普通磁盘) |
| DeepSeek V4.1 Flash (552B):视觉和工具,无需转换但需一次性准备 | 510 GB | 约 18 GB 加上专家缓存(每层 8 个时峰值 24.8 GB) | Vulkan | 0.21-0.24 tok/s(16 线程 CPU 服务器,持有 68% 的专家) |
从 GGUF 读取:按原样读取已发布文件#
./coli import 接收 GGUF 的第一个文件(其他部分放在它旁边),并在其旁边写入一个模型目录;把该目录传给 --model,就像任何其他模型一样(gguf.md)。不会再次转换或量化:块按文件中的原样运行,从 IQ1_S 到 Q8_0、F16、BF16 和 MXFP4。上面每个聊天模型的引擎也能读取 GGUF(架构);以下四个模型以 GGUF 形式提供:
| 模型 | GGUF | GPU | 实测 |
|---|---|---|---|
| Mistral-Large-4 (1T, 52B 激活):文本、图片、推理和工具 | unsloth,UD-IQ1_S 233 GB | CUDA、Vulkan | CUDA 下 1.34-1.36 tok/s,Vulkan 下 1.16-1.17(D) |
| Muse Spark Open (816B, 42B 激活):文本和工具,遵循 Meta 的许可协议 | unsloth,UD-IQ1_S 176 GB 到 UD-Q4_K_XL 505 GB | CUDA、Vulkan | Vulkan 下 1.55-1.58 tok/s,CUDA 下 1.34-1.40,CPU 上 0.83-0.89(D) |
| Flint (40B, 2.5B 激活):文本和工具,Apache 2.0 | unsloth,UD-IQ1_M 11.4 GB 到 BF16 79.6 GB | CUDA、Vulkan | UD-Q4_K_XL:CUDA 下 77.4 tok/s,Vulkan 下 77.7,CPU 上 15.8(D) |
| LFM3-VL-2B:文本、图片和工具,LFM 开放许可 | LiquidAI,QAD-Q4_0 到 BF16(或转换后的检查点) | CUDA、Vulkan | Q4_K_M:CUDA 下 235.1 tok/s,Vulkan 下 214.1,CPU 上 34.5(D) |
上表中较大的模型从它们的 GGUF 在同一台机器上运行:基准测试。
决策模型(它们回答 System One 问题,不聊天)#
| 模型 | 下载,然后在磁盘上 | RAM | GPU | 实测 |
|---|---|---|---|---|
| Laya(Convai Innovations),英语 | 0.85 GB | 1.7 GB | CPU、CUDA | 一个问题 219 ms,三个问题 882 ms(B);CUDA 下十二个 0.69 秒,CPU 上 11.4-13.0 秒(D) |
| GLiNER2.5-Decide(fastino),英语 | 1.95 GB | 1.9 GB | CPU、CUDA | 一个问题 294 ms,三个问题 897 ms(B,负载下);CUDA 下十二个 0.16-0.21 秒,CPU 上 2.0-2.6 秒(D) |
| Clef(Cloudflare):带决策头的 Qwen3.8-27B,它也能聊天 | 55 GB,转换后 52 GB | int4 时 19 GB 到 f16 时 55 GB | CPU | int8 下每请求 20.4 秒(A) |
机器:
A:Ryzen 7 PRO 8700GE 台式机(8 核,61-64 GB DDR5,NVMe,集成 Radeon 780M);
B:i7-1355U 笔记本电脑;
C:Threadripper 3945WX 机箱中的 RTX 3070 8 GB,稠密层和 DeltaNet 层在显卡上(逐行 int4 容器);
D:i5-13500,62 GB RAM,RTX PRO 4000 Blackwell SFF(24 GB)和两块 NVMe 驱动器组成 md 阵列:基准测试表格所用的机器。
每个数字都来自其在 docs/ 中的模型页面或基准测试表格,并带有确切的设置。
每个系列都有自己的页面:qwen36.md(Qwen3.6、Qwen3-Coder、Qwen3.8-27B、Flint、Muse Spark Open、LFM3-VL)、mistral-large4.md、gguf.md、qwen38.md、deepseek-v4.md、deepseek-v41.md、mimo.md、glm53-flash.md、inkling.md、kimi_k3.md、qwen-image.md、laya.md、gliner_decide.md、clef.md,以及快速开始中的 GLM-5.2。
与受支持架构相同的检查点,例如 Qwen3.6 引擎上的 KAT-Coder v2.5,可以原样运行。
GPU#
不需要 GPU#
每个引擎都能在 CPU 上运行,无需安装其他东西。GPU 是保存权重的更快位置,而不是必需条件:对于大模型,磁盘决定速度;对于小模型,RAM 决定速度。
Vulkan:任何 GPU#
每个 MoE 引擎都可以通过两种方式使用任何具有 Vulkan 1.2 驱动的 GPU(AMD、Intel、NVIDIA,集成或独立):
- 专家层(expert tier):GPU 内存中路由专家的缓存,启动时由过去对话使用的专家填充,并在聊天时自适应。GPU 计算它持有的专家,CPU 计算其余的;
- 稠密链(dense chain):将整个层记录为一次 GPU 提交,模型的运行状态从一个层到下一个层保留在 GPU 上。
在机器 A 的集成 Radeon 780M 上测量,每次运行前从页面缓存中丢弃模型文件,解码 100 个 token(vulkan.md):
| CPU | Vulkan,专家层 | Vulkan,专家层和稠密链 | |
|---|---|---|---|
| Qwen3.6-35B-A3B,解码 | 6.0 tok/s | 8.0 tok/s | 9.9 tok/s |
| Qwen3.6-35B-A3B,512 token 提示 | 35.7 s | 12.2 s | 9.5 s |
| Qwen3.8-Flash-Next(int4 专家),解码 | 3.5 tok/s | 3.8 tok/s | 3.2 tok/s |
| Qwen3.8-Flash-Next,512 token 提示 | 43.6 s | 38.7 s | 30.1 s |
| OLMoE,解码(热) | 23.1 tok/s | 12.8 tok/s | 17.3 tok/s |
集成 GPU 共享 CPU 的 RAM。它节省的是它所持有的专家的工作量和磁盘读取,因此对 Qwen3.6 这样的模型有利,而对于专家已经位于 RAM 中的小模型(如 OLMoE)可能会变差。这就是为什么设置只对 Qwen3.6、Qwen3-Coder 和 Qwen3.8-Flash-Next 在集成 GPU 上启用 Vulkan,以及为什么每个引擎自行决定是否在那里运行稠密链(Qwen3.6 是,Qwen3.8 否)。--backend vulkan 无论如何都会要求使用 Vulkan。
打开或关闭 GPU。coli setup --backend vulkan 为任何模型使用 GPU,而 coli setup --backend cpu(或 --no-gpu)将所有内容保持在 CPU 上。使用 Vulkan 构建的引擎只有在 coli chat、serve 或 web 的环境中设置 COLI_VULKAN=1 时才使用 GPU(设置在选择 Vulkan 时会设置它);没有它,引擎就在 CPU 上运行。开启 GPU 时,COLI_VK_CHAIN=0 保留专家层并在 CPU 上运行稠密层。在集成 GPU 上,两者都试试:在一台配备 Intel Iris Xe(Core i7-1355U)的笔记本上,Qwen3.6 在 CPU 上解码 2.1 tok/s,Vulkan 下 1.7 到 1.9,关闭稠密链后 2.1。
在独立 GPU 上,设置会为每个引擎构建 Vulkan(在引擎支持且安装了工具包时优先使用 CUDA),稠密层在显卡上。这就是设计针对的情况。在 RTX PRO 4000(24 GB,机器 D)上,Qwen3.6-35B-A3B 解码速度为 92.9 tok/s,读取提示为 2,076;OLMoE 为 299.4 和 6,867(见表格)。比显卡更大的模型会将显卡无法容纳的专家保留在 RAM 中的主机池中,每一步 CPU 计算这些专家,而显卡计算自己的专家,在同一帧中进行:Qwen3.8-Flash-Next IQ2_XS(68 GB)在那里解码 50.6 tok/s(vulkan.md)。一位用户在 Tesla V100 16 GB 上测得 Qwen3.6 为 17 到 19 tok/s(#1852)。欢迎提供你显卡上的数字。
不支持 Resizable BAR 的显卡现在可以工作了。这样的显卡(所有 Turing 卡、发布固件上的 Ampere 卡、关闭该选项的较旧 AMD 卡)只允许 CPU 直接写入其内存约 256 MB;colibri 现在自行通过暂存缓冲区复制权重。该路径通过强制使用它以及在三个设备上模拟小窗口进行了测试,在 780M 上没有可测量的开销;尚未在没有 Resizable BAR 的显卡上测量(vulkan.md)。
CI 在软件驱动上针对 CPU 的 token 检查每个引擎的 Vulkan 路径。GPU 以不同的顺序相加数字,并在 CPU 进行舍入的地方将一些激活保留为 f32,因此长答案可能会与 CPU 的结果相差一个词(vulkan.md)。
CUDA:NVIDIA 显卡#
在 Linux 上,如果安装了 CUDA 工具包,设置会为具有 CUDA 路径的引擎构建 CUDA:GLM-5.2/5.3 和 Mistral-Large-4、GLM-5.3-Flash、Inkling、Kimi K3、DeepSeek V4 Flash、DeepSeek V4.1 Flash、MiMo-V2.6、Qwen3.8-Flash-Next,以及 Qwen3.6 及其运行的模型;OLMoE 和决策引擎使用 make <engine> CUDA=1 构建。在 Windows 上,CUDA 引擎是一个单独的 DLL(windows.md),每个版本都会附带构建好的版本:colibri-<version>-windows-x86_64-cuda.zip 包含 coli_cuda.dll(计算能力 8.0 及以上的显卡)以及加载它的 colibri、qwen36 和 kimi_k3 引擎,还有 DeepSeek V4 自己的 CUDA DLL。将其解压到主归档之上,设置就会选择 CUDA。
Qwen3.6、Qwen3.8 和 OLMoE 的每一层都在显卡上:稠密层、注意力和显卡持有的路由专家作为一条链运行,显卡不持有的专家在 CPU 上运行。在 RTX PRO 4000 上,Qwen3.6-35B-A3B UD-Q4_K_M 解码 104.8 tok/s,读取提示 3,491;OLMoE 为 354.6 和 10,418(见表格)。
每个引擎都有显卡上的路由专家层(cu_tier.h),DeepSeek V4、V4.1、Kimi K3、GLM-5.3 和 MiMo 的稠密矩阵也在显卡上(cu_dense.h)。
GGUF 的块在显卡上(cuda_bd.cuh):所有 32 个权重或以上的 ggml 块类型,每一行都按文件中的原样;提示通过张量核心(tensor cores)处理(gguf.md)。
VRAM 专家层将最热门的专家保留在显卡上,根据测量的路由选择;未命中同时在 CPU 上计算。Qwen3.6 在两块 8 GB 显卡(RTX 3070 和 Quadro RTX 4000)上解码 11.3 tok/s,带有热历史(qwen36-cuda-tier.md);GLM-5.2 在六块 RTX 5090 上,所有专家常驻,9.0-9.2 tok/s(benchmarks.md);DeepSeek V4 Flash 在 RTX 5080 上,1.5-1.6 tok/s,3,324 token 提示用时 90 秒(deepseek-v4.md)。
Qwen3.6 的 DeltaNet 层在显卡上(Q36_DN_GPU=1,可选启用)。Qwen3.6 的 30 个 DeltaNet 层过去每个 token 都要在显卡和 CPU 之间复制数据四次;现在一个解码 token 在显卡上运行整个层,其循环状态保存在 VRAM 中。在稠密层位于 VRAM 的 RTX 3070 上:25.4 到 30.0 tok/s(qwen36-cuda-tier.md)。
较旧的显卡。如果 CUDA 工具包不再为你的显卡编译(例如 CUDA 13 和 V100,#1852),设置会在构建前发现,并通过 Vulkan 使用显卡,同时说明原因;CUDA 12.x 工具包可以恢复 CUDA 路径。DeepSeek V4 的 CUDA 层也可以为 Pascal 和 Turing 构建(CUDA_ARCH=portable-pre-ampere NO_TC=1)。
全部内容:docs/cuda.md。
Apple Silicon#
Metal 后端在多个引擎上为统一内存 GPU 执行专家数学运算(docs/metal.md)。发布版的 macOS 归档包含以此构建的 colibri、inkling 和 kimi_k3:COLI_METAL=1(Kimi K3 用 K3_METAL=1)可开启它,否则它们在 CPU 上运行。从源码构建时使用 METAL=1;一步式设置为 CPU 构建。
System One:带概率的决策#
人们向模型要求的大多数东西是一个选择,而不是一段话:哪个队列、哪个裁决、是或否。POST /v1/systemone 接收一个状态(文本或 JSON)和带类型的问题,并以每个允许选项的概率和置信度回答每个问题。不生成任何内容,因此答案不会超出你的列表,而“模型不确定”是一个你可以设置阈值的数字。
curl -s http://127.0.0.1:8000/v1/systemone -H 'Content-Type: application/json' -d '{
"state": "340 lines, 8 files, no tests. CI is green but nothing covers that path.",
"questions": {
"review": {"type": "choice", "instructions": "What should the reviewer do?",
"criteria": {"merge": null, "request changes": null, "close": null}},
"risky": {"type": "noul", "instructions": "Is this change risky?"}}}'
一个 choice 会返回所选标签、每个标签的概率,以及从 0(平坦)到 1(确定)的置信度;一个 noul 返回“是”的概率;一个 score 返回预期水平。
谁回答:
- colibri 运行的任何聊天模型,通过评分:它读取每个选项的概率,而不是写答案。关于一份文档的许多问题只读取文档一次:在 Qwen3.6 上,关于一份文档的四个问题在同一台 CPU 机器上比生成相同答案快 5.7 倍。
- 三个决策模型,原生地,在一次前向传递中完成,并带有作者拟合的校准:Laya(Convai Innovations)、GLiNER2.5-Decide(fastino)和 Clef(Cloudflare;它也能聊天)。它们的大小和速度见决策模型表。
从 Jev 切换。请求和回复是 TypeSafe 的 Jev API 的请求和回复,因此 Jev 客户端只需更改其基础 URL 即可切换到 colibri,无需其他更改:TYPESAFE_BASE_URL=http://127.0.0.1:8000(它已经发送的密钥会被在没有 COLI_API_KEY 的情况下启动的服务器接受)。两个官方 SDK 未经修改,已针对 coli serve 进行测试。
同样的模式也在终端中(coli chat 中的 /decide merge | request changes | close)和仪表板的 System One 页面上。完整的请求和回复、评分规则以及它在哪些地方没有帮助:docs/systemone.md。
仪表板#
coli web 打开它,一步式设置也会打开:聊天、System One 页面、大脑(Brain)和性能分析(Profiling)页面,支持浅色或深色主题。
聊天 UI#
coli ui 在运行中的 coli serve 旁边打开新聊天:推理在自己的块中,为带视觉塔的模型显示图片,支持网络搜索、专家图、实时监视器,以及已经指向 colibri 打开的编程智能体。支持七种语言。见 ui/README.md。
LFM3-VL-2B 在 i5-13500 的 CPU 上,32 tok/s。
LFM3-VL-2B 写作时的监视器:31.6 tok/s,提示读取耗时 0.1 秒,占用 2.1 GB RAM。
OLMoE 在聊天旁边打开专家图:每个块中的每个专家对应一个单元格,当前步骤被选中时显示白色,在此答案中使用过时显示琥珀色。
System One:给模型一份文档,以及它只能选择的答案。这里 Qwen3.6-35B 在 RTX PRO 4000 上读取一个破坏缓存大小限制的拉取请求:request changes 为 81%,熵 0.56(不确定),读取 98 个 token,生成 0 个。
性能分析页面显示每一轮在何处花费时间,逐阶段展示,并以最近 30 轮作为趋势。
从其他应用使用#
coli serve(设置会为你启动)是一个带有多个 API 的服务器:
- 兼容 OpenAI:
/v1/chat/completions、/v1/completions和/v1/models,支持流式传输、JSON 回复、停止序列和 logprobs;
- 兼容 Anthropic:
/v1/messages,因此 Claude Code 和 Anthropic SDK 可以针对它工作;
- 除 Inkling 和 OLMoE 外的每个聊天引擎都支持工具调用,各自使用其模型的原生格式(见各引擎表格);
- 图片输入:GLM-5.3-Flash、DeepSeek V4.1 Flash、MiMo-V2.6、Qwen3.8-Flash-Next、Qwen3.8-27B、LFM3-VL 和 Mistral-Large-4(从 GGUF 读取,旁边有 mmproj 文件):可以是
coli chat消息中的路径、coli web或coli ui中的附件,或一个image_url部分;
- 每个聊天引擎都支持文档输入:
coli chat中的/file PATH(或coli chat --file PATH)会将文本文件或 PDF 的文本随下一条消息发送。只有以这种方式命名的文件才会被读取,消息内的路径绝不会被读取;它必须是具有文本后缀或.pdf的常规文件,大小不超过 64 MiB,字符数不超过 200 万。PDF 在单独的进程中解析,带有时间和内存限制,使用 pdftotext(poppler)或 pypdf;
- 图片输出:在
POST /v1/images/generations上使用 Qwen-Image-2.1,并可在终端中由coli chat绘制(qwen-image.md);
- 决策:
POST /v1/systemone(见上);
- 每个文本引擎支持多个并发对话:
coli serve --kv-slots N最多保留 16 个,每个都有自己的缓存,并一起解码它们的下一个 token(api.md)。
编程 CLI 和编辑器像连接任何 OpenAI 兼容提供商一样连接:基础 URL 为 http://127.0.0.1:8000/v1,模型 ID 由 coli status 打印,任意非空密钥(docs/api.md)。
工作原理#
每个 token 的每一层都走同样的五个步骤:路由(route)、合并(union)、放置(place)、重叠(overlap)、学习(learn)。设计目标是放置只决定速度:无论专家是从 VRAM、RAM 还是磁盘回答,路由器的决策和权重的精度都相同。
权重的 JIT。编译器 JIT 从不编译整个程序:它观察运行的内容并编译热路径。colibri 对权重做出同样的押注。测量的路由热度决定哪些专家获得 VRAM、RAM 或磁盘:每层 LRU 缓存,加上从你自己的对话中学到的固定热门集合(.coli_usage,每轮更新)。colibri 使用得越多就越快。它之所以有效,是因为路由具有可测量的结构(专家图谱)。
绝不等磁盘两次。一个专家的三个矩阵在一次 pread 中读取;一个加载器池在常驻专家计算时读取缺失的专家;一批位置每个专家只读取一次;一个路由器前瞻线程可以预取下一层(GLM-5.2 的路由在一层之前有 71.6% 的可预测性)。DIRECT=1(O_DIRECT)在快速 NVMe 驱动器上通常是大赢,在其他驱动器上则中性或更差:请在你的驱动器上测量(tuning.md)。
不止一个 SSD。COLI_MODEL_MIRROR=/second/glm52_i4 ./coli chat --model /fast/glm52_i4 从第二块驱动器上的副本读取。独立控制器上的两块 NVMe 驱动器测得解码 +37.5%;较小驱动器上的部分镜像也可以(multidisk.md)。
从笔记本到机架。在 25 GB 的笔记本上,每个专家都从磁盘流式读取,缓慢但正确;在大型主机上,每个专家都常驻(CUDA_EXPERT_GB=auto PIN_GB=all),磁盘退出解码过程。COLI_NUMA=1 将常驻权重分散到多插槽主机的内存控制器上,本地集群模式可以在其他机器上运行路由专家(cluster.md)。
忠实的模型。每个引擎都在 CI 中针对其模型的参考实现在一个小型固定装置上进行检查。GLM-5.2 的 MLA 注意力保留压缩的 KV 状态(每 token 576 个浮点数,而不是 32,768 个,小 57 倍),该状态在重启后仍然存在,因此对话重新打开时无需再次读取提示。
值得保留的推测。GLM-5.2 的 int8 MTP 头在划算时每次前向起草 2.2-2.8 个 token;Qwen3.8-Flash-Next 的 MTP 头默认开启,在输出相同的情况下增加 16-20%,提示查找在代码编辑上增加 6-7%。Qwen3.6 的头(Q36_MTP=1)在 CUDA 上将解码从 99.7-104.5 提升到 115.8-120.1 tok/s,在 Vulkan 上从 83.2-83.8 提升到 99.9-109.3(RTX PRO 4000)。DeepSeek V4.1 的 DSpark 头按其置信度指示的深度起草,一个门控会跳过无法划算的草稿。在起草成本高于节省的地方(DeepSeek V4),它保持关闭(speculative.md、tuning.md)。
引擎是每个模型系列一个 C 文件(GLM-5.2 为 c/colibri.c),位于共享头文件之上,没有 BLAS,运行时没有 Python:Python 只运行设置、启动器、转换器和 API 网关。
基准测试#
相同的引擎和相同的 int4 容器:硬件只改变专家所在的位置。GLM-5.2 解码,来自完整表格:
- 6x RTX 5090,所有专家常驻:5.8-6.8 tok/s,选择性 NUMA 交错时 9.0-9.2(实验日志);
- 128 GB,仅 CPU(Ryzen AI Max+ 395):热启动 1.83 tok/s(#200);
- 单台 RTX 5070 Ti 笔记本级机器:1.07 tok/s(#273);
- 这个项目起步时的 25 GB 笔记本:冷启动 0.05-0.1 tok/s,诚实的下限。
一台机器上的三种后端#
一台 i5-13500,62 GB RAM 和 RTX PRO 4000 Blackwell SFF(24 GB,70 W),每个模型由 coli serve 提供服务:先是一个新的 450 token 提示,然后是一个 128 token 的流式答案,包括请求的 HTTP;取两次运行中较好的一次,单位 tok/s。
| GGUF | CUDA 提示 | CUDA 解码 | Vulkan 提示 | Vulkan 解码 | CPU 提示 | CPU 解码 |
|---|---|---|---|---|---|---|
| Qwen3.6-35B-A3B UD-Q4_K_M | 3,491 | 104.8 | 2,076 | 92.9 | 122.6 | 13.9 |
| LFM3-VL-2B Q4_K_M | 12,317 | 235.1 | 8,174 | 214.1 | 286.5 | 34.5 |
| OLMoE-1B-7B-0125-Instruct Q4_K_M | 10,418 | 354.6 | 6,867 | 299.4 | 279.9 | 47.4 |
| LFM3-VL-2B F16 | 11,524 | 103.4 | 7,767 | 99.3 | 49.7 | 6.4 |
| Qwen3.8-Flash-Next IQ2_XS(68 GB:显卡无法容纳的专家留在 RAM 中) | 217.1 | 51.4 | 214.3 | 50.6 | 38.3 | 9.3 |
同一台机器上的大模型#
再次是机器 D,每个模型通过 coli serve 从其发布的 GGUF 运行:显卡和 RAM 都无法容纳的部分来自两块 NVMe 驱动器。每秒 token 数,来自各模型页面:
| GGUF | 大小 | 后端 | 提示 | 解码 |
|---|---|---|---|---|
| Inkling-Small UD-IQ2_XXS | 77 GB | Vulkan | 15.1-33.1 | 10.92-11.53(vulkan.md) |
| MiMo-V2.6-Flash Q2_K_S | 106 GB | Vulkan | 8.2 | 7.8(gguf.md) |
| DeepSeek V4 Flash 0731 UD-IQ2_XXS | 85 GB | Vulkan | 19.7-20.4 | 6.18-6.25(vulkan.md) |
| DeepSeek V4.1 Flash UD-IQ1_S | Vulkan | 3,403 token 上 31.8 | 5.01-5.29(deepseek-v41.md) | |
| GLM-5.3-Flash UD-IQ2_XXS | 95 GB | Vulkan | 9.3 | 2.92-3.40(vulkan.md) |
| Muse Spark Open UD-IQ1_S | 176 GB | Vulkan | 5.0-5.3 | 1.55-1.58(qwen36.md) |
| Mistral-Large-4 UD-IQ1_S | 233 GB | CUDA | 240 token 用时 66-82 s | 1.34-1.36(mistral-large4.md) |
| GLM-5.2 UD-IQ1_S | 202 GB | Vulkan | 0.633-0.658(gguf.md) | |
| Kimi K3 UD-IQ1_S | 594 GB | Vulkan | 31 token 用时 46.5 s | 0.349(gguf.md) |
长上下文和智能体#
以 64k 的速度处理 256k 上下文。在机器 D 的 CUDA 链上运行 Qwen3.8-Flash-Next IQ2_XS,上下文为 262,144 个 token:提示 15.6 -> 149 tok/s,解码 9.6 -> 45.7(RAM 计划,一个提示段,K/V 在显卡上以 float16 存储;在 65,536 时读取 188,解码 48.4)(qwen38.md)。
智能体的一轮只读取新内容。两轮之间的短请求(智能体询问对话标题)会暂停对话,而不是取其状态,在每个引擎上都是如此(COLI_PARK)。Hermes Agent 在 Qwen3.8-Flash-Next 上的第二轮,14,810 个 token:86 秒 -> 4.9 秒(qwen38.md)。
float16 中的 KV 缓存:GLM-5.3 在 131,072 个 token 时占用 11.9 GB 而不是 23.9 GB(CHANGELOG)。
质量是测量出来的,而非假定的:int4 容器的成本和量化消融在 benchmarks.md 中。要添加你的机器,请遵循基准测试协议并附上数字开一个 issue。
手动安装#
- 程序。从 Releases 获取适用于你平台的归档(Linux x86_64、macOS、Windows;无需编译器,启动器和 API 只需要 Python 3)并解压,然后运行
python3 coli info。Linux 和 Windows 引擎内置 Vulkan,旁边有它们的shaders/;macOS 引擎内置 Metal;Windows 上的 NVIDIA 显卡需要添加 CUDA 归档。或者使用 gcc(或 clang)和 OpenMP 从源码构建:
git clone https://github.com/JustVugg/colibri && cd colibri/c
./setup.sh # 检查 gcc/OpenMP,构建,自测
make qwen36 VK=1 # 单个引擎,这里使用 Vulkan(CUDA=1 为 CUDA)
- 一个模型。上表中的任何下载:设置的 ID 映射到 Hugging Face 仓库,每个模型页面都有下载和转换命令。对于 GLM-5.2,使用带 int8 MTP 头的分组缩放(gs64)容器
mastouri/GLM-5.2-colibri-int4-g64-with-int8-mtp(429 GB),或使用Justvugg/GLM-5.3-colibri-int4-g64获取 GLM-5.3(419 GB,无 MTP 头)。不要使用较旧的逐行 int4 镜像:它们在质量上测得差约 9 个点,并导致了 #455 的循环回答。./coli convert --model /nvme/glm52_i4从 FP8 发布版逐分片构建相同的容器,始终无需其 756 GB 同时存在于磁盘上。如何检查 MTP 头及其他内容:quickstart.md。你已经拥有的 GGUF 无需转换:./coli import它的第一个文件(见上)。
- 运行它。在源码检出的
c/中,或从解压的发布版运行。启动器读取模型的config.json并选择引擎及其聊天模板,因此每个模型的命令都相同:
./coli chat --model /nvme/qwen36 # 在终端中聊天
./coli web --model /nvme/qwen36 # API + 仪表板,打开浏览器
./coli serve --model /nvme/qwen36 # API + 仪表板,不打开浏览器
./coli plan --model /nvme/qwen36 # 模型将住在哪里:VRAM、RAM、磁盘
./coli doctor --model /nvme/qwen36 # 只读检查:一切准备好了吗?
./coli tune --model /nvme/qwen36 # 测量并保存这台机器最快且安全的设置
./coli import /nvme/Flint-UD-Q4_K_XL.gguf # 一个 GGUF:在它旁边写入 Flint-UD-Q4_K_XL.colibri
./coli ui # 聊天 UI,位于运行中的 coli serve 旁边
在 Windows 上,发布归档附带 coli.cmd(coli.cmd chat --model D:\qwen36);从源码检出使用 py -3 c\coli。.exe 文件是引擎,不是启动器。所有选项和变量:SETTINGS.md、ENVIRONMENT.md。
研究,以及如何帮助#
colibri 希望前沿模型减少对稀缺硬件的依赖,并降低运行成本。这意味着改变权重的存储和移动方式,决定什么放在 VRAM、RAM 或存储中,重叠 CPU 和 GPU 工作,并测试新的解码方式。没有什么是因其惯例而被保留,也没有什么是因微基准测试看起来快而被采纳:决定性的结果是在真实机器上的端到端推理,并同时测量质量和速度。开放问题:
| 假设 | 目前的证据 | 仍需的实验 |
|---|---|---|
| 路由历史可以比普通 LRU 更好地放置专家 | 学习到的固定项改善了重复工作负载,但可能对某个提示过拟合 | 在编程、聊天、多语言和长上下文工作负载上进行留出的跨会话 A/B 测试 |
| 多个 SSD 可以将独立带宽转化为解码速度 | 两块独立的 NVMe 驱动器测得解码 +37.5%;较慢的第三块驱动器在加权条带化后为中性(测量) | 在不同驱动器速度、控制器布局和缓存状态下复现 |
| 硬件感知规划器可以自动接近每台机器的最佳配置 | 今天已检测 RAM/VRAM 预算和多种后端,设置会选择构建 | 在笔记本、工作站、NUMA 主机和多 GPU 系统上,将生成的计划与受控参数扫描进行比较 |
| 无损或质量有界的表示可以减少足够的权重移动,从而产生影响 | 存在格式和量化消融,带有正确性/质量门控 | 同时复现质量、移动字节数、延迟和每有效 token 成本,而不仅仅是压缩率 |
| 路由感知的推测可以在接近完全常驻之前就划算 | MTP 和语法草稿有效,但 MTP 也在约 85% 专家命中率附近测得 32% 的损失 | 在接受率、专家命中率、批处理并集和草稿深度上绘制盈亏平衡面 |
| CPU/GPU 重叠可以隐藏传输和同步,而不仅仅是移动瓶颈 | 存在 CUDA、Metal 和 Vulkan 的收益,但快速 CPU、集成 GPU 和低常驻率可能将其抵消 | 在 PCIe、统一内存和完全常驻机器上进行逐阶段分析和单变量 A/B 测试,并为 Vulkan 层和链测试比已测量的一块(RTX PRO 4000)更多的独立显卡 |
想帮忙?选择一行,并把负面结果也发布出来。记录硬件、commit、模型、确切命令、提示、缓存状态、吞吐量、首 token 时间、专家命中率、读取字节数和质量检查;改变一个变量,重复,并附上原始日志。从 CONTRIBUTING.md 和基准测试协议开始,然后开一个 issue。一个控制良好的失败在这里比一个无法解释的快速数字更有价值。
文档#
| 主题 | 文档 |
|---|---|
| 一步式设置和手动安装,每个平台 | quickstart.md |
| 通过 AI 助手设置,以及 MCP 服务器 | AI_SETUP.md、MCP_SERVER.md |
| API:OpenAI、Anthropic、工具、KV 槽、仪表板 | api.md |
| System One 和决策模型 | systemone.md、laya.md、gliner_decide.md、clef.md |
| GGUF 文件:架构、两种模式、每个引擎如何处理块 | gguf.md |
| Qwen3.6 引擎上的模型(Flint、Muse Spark Open、LFM3-VL)和 Mistral-Large-4 | qwen36.md、mistral-large4.md |
聊天 UI(coli ui) | ui/README.md |
| Vulkan:专家层、稠密链、不支持 Resizable BAR 的显卡 | vulkan.md |
| CUDA,以及 Qwen3.6 的 CUDA 层 | cuda.md、qwen36-cuda-tier.md |
| Apple Silicon、Windows | metal.md、windows.md |
| 调优、学习缓存、预取 | tuning.md |
| 推测解码:MTP 头、提示查找、门控 | speculative.md |
| 多个 SSD、多台机器 | multidisk.md、cluster.md |
| 基准测试及如何测量 | benchmarks.md、benchmarking.md |
| 所有选项和环境变量 | SETTINGS.md、ENVIRONMENT.md |
| 语法强制草稿,以及实验性嵌入 ABI | grammar-draft.md、segment-runtime.md、edge-runtime.md |
仓库布局#
start-here.sh, START-HERE.bat 一步式设置(Linux 和 macOS、Windows)
Makefile 根构建/检查入口
c/
├── colibri.c GLM-5.2/5.3、Mistral-Large-4(make glm)
├── glm53.c GLM-5.3-Flash(make glm53)
├── inkling.c Inkling(make inkling)
├── kimi_k3.c Kimi K3(make kimi_k3)
├── deepseek_v4.c DeepSeek V4 Flash(make deepseek-v4)
├── deepseek_v41.c DeepSeek V4.1 Flash(make deepseek_v41)
├── mimo.c MiMo-V2.6 Flash 和 Pro(make mimo)
├── qwen38.c Qwen3.8-Flash-Next(make qwen38)
├── qwen36.c Qwen3.6、Qwen3-Coder、Qwen3.8-27B、Flint、Muse Spark、
│ LFM3-VL、Clef(make qwen36)
├── olmoe.c OLMoE(make olmoe)
├── qwenimage.c Qwen-Image-2.1(make qwenimage)
├── laya.c Laya(make laya)
├── gliner_decide.c GLiNER2.5-Decide(make gliner_decide)
│
├── st.h, quant.h, idot.h safetensors 读取、容器解码器、整数内核
├── expert_ffn.h, expert_store.h 路由专家内核和流式专家缓存
├── tok.h, json.h, compat.h 分词器、JSON、Windows/macOS 兼容层
├── route_trace.h, kv_prefix.h 路由遥测(.coli_usage)、KV 前缀复用
├── gguf.h, park.h GGUF 读取器、在智能体轮次之间暂停的对话
├── decide_serve.h 决策引擎在 System One 中的部分
│
├── backend_cuda.*, cu_tier.h, cuda_chain.cu 可选 CUDA 层和链(CUDA=1)
├── backend_metal.* 可选 Metal 层(METAL=1)
├── backend_vulkan.*, vk_tier.c, vk_chain.c 可选 Vulkan 层和稠密链(VK=1)
│
├── coli 面向用户的 CLI
├── setup_*.py 一步式设置:硬件、目录、下载、流程
├── mcp_server.py MCP 服务器(coli mcp)
├── openai_server.py OpenAI 和 Anthropic 兼容 HTTP 网关
├── resource_plan.py coli plan 和 coli doctor 背后的 RAM/VRAM 规划器
├── tools/ 转换、固定装置和基准测试
└── tests/ 无依赖的 C 和 Python 测试
ui/ 聊天 UI(coli ui)
web/ 仪表板(纯 API 客户端)
desktop/ 围绕仪表板的 Tauri 桌面外壳
docker/ 容器镜像
docs/ 参考文档、实验、媒体
site/ 网站
每个模型系列一个 .c,位于共享的单个头文件之上。一个引擎拥有其架构,仅此而已;两个引擎都需要的东西放在它们都包含的头文件中,因此一个修复可以同时到达所有引擎。从仓库根目录,make、make check 和 make clean 委托给引擎 Makefile。
支持该项目#
colibri 最初是一个人在 12 核笔记本、25 GB RAM 上的项目;今天它的数字来自真实机器组成的社区。如果它对你有所帮助:
- 给仓库加星并分享;
- 用你硬件上的基准数字开 issue:数据点对这个项目的推动比什么都大;
- 加入 Discord 社区讨论实验、硬件结果和研究方向;
- 通过 GitHub issue 联系以赞助开发或捐赠硬件。
为什么叫 "colibrì"#
蜂鸟只有几克重,能原地悬停,每天造访一千朵花。这个引擎让一个 7440 亿参数的庞然大物靠蜂鸟的口粮活着:25 GB RAM、十二个 CPU 核心,以及大量的磁盘耐心。
致谢#
colibri 是一个引擎;它运行的头脑是一份礼物。感谢那些公开释放权重的团队:Z.ai(GLM)、Moonshot AI(Kimi)、Alibaba Qwen、DeepSeek、Xiaomi(MiMo)、Thinking Machines(Inkling)、Allen AI(OLMoE)、Convai Innovations(Laya)、fastino(GLiNER2.5-Decide)和 Cloudflare(Clef);感谢发布转换容器的人们;感谢每一位做基准测试、二分定位、复现图谱运行或发送补丁的贡献者。本仓库中的第三方代码及其许可证:THIRD_PARTY_NOTICES.md。
该项目的专家放置、压缩和路由实验也建立在以下开放研究和系统工作的思想和证据之上:
- REAP 和 EASY-EP,用于输出感知和领域特定的专家重要性。
- SERE,用于基于相似性的专家重路由;ReMoE,用于缓存局部性感知的路由器微调。
- MC-SMoE,用于路由引导的专家合并和压缩。
- MoBE 和 D²-MoE,用于共享专家基础和低秩专家增量。
- HybriMoE,用于混合 CPU/GPU 专家调度;ScMoE,用于重叠专家通信与计算;OD-MoE,用于分布式按需专家加载。
- vLLM、llama.cpp 和 kTransformers,用于使比较可复现的开放推理系统和专家卸载工作。
该引擎也建立在具体的工程工作之上,而不仅仅是想法。以下每一项今天都在代码树中被使用或重新实现:
- safetensors:每个引擎读取的容器(
c/st.h),包括其 fp8 和 I64 数据类型。 - tiktoken:
c/tok.h精确地重新实现了其byte_pair_encode,合并拼接后具有最低词表 ID 的相邻对,因此源自 tiktoken 的词表不需要合并列表。 - llama.cpp:
c/grammar.h中的 GBNF 语法子集遵循其语法及其栈集合 PDA,Metal 路径借鉴了其newBufferWithBytesNoCopy的常驻技巧。 - vLLM:引擎逐位置匹配的输出语义的参考(例如最终归一化相对于 LM 头的位置)。
- transformers:预言机:CI 针对它逐 token 复现一个随机初始化模型。
- DietGPU:实验性压缩专家层(
COLI_ANS)背后的 GPU ANS 编解码器。 - rocWMMA:HIP 后端将 CUDA 的
nvcuda::wmmafragment/mma_sync API 映射到它上面(c/backend_gpu_compat.h),这使得一个.cu源文件可以为两个厂商编译。
许可证#
Apache 2.0,Copyright 2026 Vincenzo Fornaro。见 LICENSE 和 NOTICE。每个模型保留其作者赋予的许可证(GLM-5.2 权重由 Z.ai 以 MIT 发布;Qwen-Image-2.1 仅限非商业使用)。