更新:将稠密模型转换为混合专家模型

Reddit r/LocalLLaMA 模型

摘要

作者更新了将稠密模型转换为混合专家(MoE)模型的项目,发布了 Qwen2.5-1.5B-MoE-A0.9B 及 0.5B/1.5B 的 GGUF 版本。结果显示 GPU 和 CPU 推理速度明显提升(约 32-41%),但困惑度上升约 40%,作者称其为小模型上的概念验证。

这是我上一篇帖子的更新,上一篇帖子可以在这里找到:https://www.reddit.com/r/LocalLLaMA/s/n7sgRZZc4z 自上次发帖以来,我一直在继续完善转换流程,同时也在转换新的模型。我最新的模型是 Qwen2.5-1.5B-MoE-A0.9B。我还发布了 0.5B 和 1.5B 模型的 GGUF 版本,分别可以在这里找到:bayliner1980/Qwen2.5-0.5B-MoE-A0.3B-GGUF 和 bayliner1980/Qwen2.5-1.5B-MoE-A0.9B-GGUF。评估 - 稠密模型 MoE WikiText-2 测试集困惑度(1024 token 窗口)10.41 14.63(+41%)C4 验证集困惑度(64 × 1024 token)15.76 22.88(+45%)零样本任务,平均 acc_norm 0.565 0.462 任务 稠密模型 MoE HellaSwag 0.592 0.510 ARC-Easy 0.723 0.572 ARC-Challenge 0.452 0.311 WinoGrande 0.646 0.588 OpenBookQA 0.410 0.328 困惑度高了约 40%,基准测试中 ARC 的成绩下降最明显。llama-bench,两者均使用 Q4_K_M,RTX 4060 8 GB / Ryzen 5 7500F - 稠密模型 MoE 变化 GPU,文本生成 token/秒 191 253 +32% CPU,文本生成 token/秒 54.9 77.5 +41% 这是首次转换后的模型在 GPU 上也明显快于稠密模型。0.5B 模型在 GPU 上仅提升了 6%。坦诚说明局限 在这个规模下,模型质量大致处于 Qwen2.5-0.5B 的水平,而后者的速度还更快。因此,这次发布更多是概念验证。这种方法应该能在更大的模型上带来更多收益,因为这些模型的 MLP 占总计算量的比例更高。GGUF 文件比稠密模型的更大(Q4_K_M 下为 1.1 GB,而稠密模型为 0.9 GB),因为 llama.cpp 的 MoE 架构需要一个不共享权重的输出头。支持 如果你觉得我的工作有意思,可以考虑在 Ko-fi 上支持我。
查看原文

相似文章

将稠密模型转换为混合专家模型

Reddit r/LocalLLaMA

一位独立开发者在 RTX 4060 (8GB) 上尝试将稠密模型直接转换为稀疏 MoE 模型(Qwen2.5-0.5B 和 SmolLM2-360M,32 专家 top-8),无需从头预训练,并分享了计算量节省与性能损失的评测结果。

面向 16GB GPU 与 Qwen 3.6 35B MoE 代码模型的穷人版推理引擎

Reddit r/LocalLLaMA

作者将 llama.cpp 的 server 分支为 AgrillaMoE,针对 Qwen3.6-35B-A3B MoE 模型在 16GB 显存 GPU 上优化,配合 2-bit 量化可达约 57-60 tok/s,并支持 OpenAI/Anthropic API 兼容接口;其 MoE 扩展补丁在运行时增加每 token 激活专家数(20 vs 8),无需重训即可在 GPQA-Diamond 上提升约 2.5 分。

一个 80B MoE 模型(Qwen3-Next,48 GB GGUF)在 Chrome 标签页中回答问题:使用 llama.cpp 的 WebGPU 后端,专家从磁盘按需分页加载

Reddit r/LocalLLaMA

作者将上周的 MoE 专家按需从磁盘流式加载的方案接入 llama.cpp 的 WebGPU 后端,使 80B MoE 模型(Qwen3-Next,48GB GGUF)也能在 Chrome 标签页中运行,无需为每个模型手写引擎。该方案新增了 ggml-webgpu 的缓冲类型、slot 映射的 MUL_MAT_ID 着色器和驻留逻辑,实测在 M4 Pro MacBook 上以 2.9 tok/s 解码 80B 模型,较小模型可达 22 tok/s。