凭什么跑个大模型，就非得要几千块的显卡、几十GB的显存？

项目地址：https://github.com/TencentYoutuResearch/Palm-Infra

一、为什么这个项目值得你停下来读？

如果你在本地部署过大模型，你一定被一个现实折磨过：模型太大，显存放不下。

70B的模型需要40GB+显存，122B的MoE模型更是望而却步。整个社区的主流方案是——要么花大价钱买显卡，要么忍受2-3 token/s的龟速offload。说白了，在端侧跑大模型，长期以来是一场"显存不够、速度来凑"的工程妥协。

mollm——Palm-Infra旗下的移动端LLM推理引擎——给出了一个颠覆性的思路：

不要再用"显存够大"来定义"能跑什么模型"。我们可以用SSD-offload + 智能预取的方式，让一台48GB的Mac，跑起122B的MoE模型。

这不是又一个在llama.cpp上小修小补的工作——它从根上重新设计了MoE模型的推理内存架构，并把它落地到了Apple Silicon和ARM CPU的真实场景里，拿到了实打实的吞吐提升。

二、核心思想：从"硬塞显存"到"SSD智能换页"

2.1 传统方案在做什么？

传统的本地推理方案，要么把模型整个塞进内存/显存，要么用最朴素的offload——需要哪层加载哪层，没有任何预测性。对于MoE（混合专家）模型来说，问题更严重：每次推理只会激活少数几个"专家"，但传统方案会把所有专家的权重都加载到内存里，浪费大量带宽。

2.2 mollm的做法：共享缓存 + 跨层预取

mollm的核心操作完全不同。它的设计围绕两个关键机制展开：

共享全局RAM池：不再为每一层分配固定的显存配额，而是用一个全局的RAM池统一管理所有专家的缓存。Least-Stale淘汰策略会优先保护当前层和未来层可能用到的专家权重。

下一层路由器预测 + 异步预取：在推理当前层时，mollm会提前预测下一层MoE层会路由到哪些专家，然后用异步pread线程提前从SSD中读取这些专家的权重。

2.3 一句话总结区别

三、实战成绩单：122B模型在48GB Mac上跑出13.54 token/s

理论再漂亮，最终要看实测。

mollm在**Qwen3.5-122B-A10B MoE模型（W4量化）**上的表现，堪称端侧推理的"降维打击"：

解码速度提升24%，缓存命中率从74.5%跃升至89.3%。预取策略虽然多消耗了约6GB的SSD读取带宽，但成功将I/O延迟隐藏在了计算背后，交互式解码体验质的飞跃。

更令人震撼的是对比基线：llama.cpp的CPU方案根本无法在48GB内存中跑起这个122B模型。mollm不仅跑起来了，还跑出了可用速度。

3.1 与其他模型的全面对比

mollm在各类模型上的表现同样亮眼：

FP16精度下：

• Qwen3.5-0.8B：mollm预填757 t/s vs llama.cpp 665 t/s，解码124 t/s vs 98 t/s
• Youtu-LLM-2B：mollm预填335 t/s vs 258 t/s，解码51 t/s vs 47 t/s

W4量化下：

• Qwen3.5-0.8B：mollm解码259 t/s vs llama.cpp 191 t/s——快了36%
• Youtu-LLM-2B：mollm解码116 t/s vs 97 t/s

MoE模型下优势更加明显：

• Qwen3.6-35B-A3B：mollm预填1.19倍、解码1.49倍于llama.cpp
• Qwen3-30B-A3B：mollm预填1.30倍、解码1.05倍于llama.cpp

mollm的解码速度已经全面领先，而预填速度仍是下一步优化的重点。

四、技术实现：开箱即用的完整工具链

这个项目不仅设计扎实，代码也完整开源、结构清晰、开箱即用。

4.1 环境要求

• macOS/Apple Silicon 或 ARM Linux
• CMake + Ninja
• Python 3 + numpy + safetensors

4.2 快速上手

# 克隆仓库gitclone https://github.com/TencentYoutuResearch/Palm-Infra.gitcdPalm-Infra# 编译cmake-GNinja-Bbuild_i8mm-DCMAKE_BUILD_TYPE=Release cmake--buildbuild_i8mm-j# 转换模型（以Qwen3.5-4B为例）python3 models/converter.py /path/to/Qwen3.5-4B qwen35_4b_w4g128.mollm w4g128# 交互式对话./build_i8mm/mollm_chat--packageqwen35_4b_w4g128.mollm--threads4# 性能压测./build_i8mm/mollm_bench--packageqwen35_4b_w4g128.mollm\--prompt-tokens256--max-new-tokens64--warmup3--threads4

4.3 仓库结构一览

Palm-Infra/ ├── mollm/ │ ├── kernels/ # ARM内核：matmul、attention、MoE、norm、rope │ ├── graph/ # 图格式、执行器、mmap加载、BufferPool │ ├── engine/ # LLMEngine、分词器、对话生命周期 │ ├── models/ # Python转换器和图构建器 │ ├── examples/ # mollm_chat、mollm_server、mollm_bench │ └── tests/ # 单元测试、压力测试、端到端测试 └── ...

4.4 量化方案选择

4.5 本地HTTP服务

mollm还内置了OpenAI兼容的HTTP服务器：

./build_i8mm/mollm_server--packageqwen35_4b_w4g128.mollm\--host127.0.0.1--port8080--threads4

支持GET /v1/models和POST /v1/chat/completions，包括SSE流式输出。

五、mollm的深远意义：它打开了哪几扇门？

5.1 让"平民设备"跑起"顶级模型"

在本地部署大模型，长期以来是"显存决定论"——你有多少显存，就能跑多大模型。mollm用SSD-offload + 智能预取证明了：只要算法够聪明，48GB内存也能跑122B模型。这在NVIDIA侧需要专业卡才做得到。

5.2 为MoE模型端侧部署扫清障碍

MoE模型的理论优势是"推理时只激活部分专家"，但传统方案因为无法有效管理专家权重的加载，导致这个优势在端侧根本无法发挥。mollm的跨层预测 + 异步预取第一次让MoE的"稀疏激活"优势在端侧真正兑现。

5.3 ARM CPU推理的性能标杆

长期以来，ARM CPU上的LLM推理被llama.cpp统治。mollm用一系列精心优化的AArch64 GEMV内核、静态可复用的解码工作区、直接W4G128打包布局，在解码速度上全面超越了llama.cpp。这为ARM生态的端侧AI树立了新的性能标杆。

5.4 工程透明度的典范

mollm不仅提供了性能数据，还提供了Chrome Trace / Perfetto时间线分析工具，让开发者可以直观地检查prefill/decode、每层MoE路由和专家计算、缓存请求和SSD I/O合并情况。这种"透明工程"的态度，值得每一个基础设施项目学习。

六、谁应该关注这个项目？

七、总结：不追热点，只解决真问题

在如今大模型军备竞赛、动辄"千卡训练、百G显存"的喧嚣中，Palm-Infra/mollm是一股清流。它：

• 不追热点：没有去卷新的模型架构，而是扎进了"端侧推理基础设施"这个被忽视的工程问题。
• 工程扎实：从内核优化到缓存策略、从SSD预取到性能分析工具，一整套完整的端侧推理方案。
• 实战硬核：122B MoE模型在48GB Mac上跑出13.54 token/s，不是纸上谈兵。
• 诚实透明：性能数据、分析工具、代码结构全部开源，科研与工程态度令人敬佩。

如果你正在做端侧AI部署、MoE模型推理优化、ARM CPU推理引擎，或者单纯对**“如何在普通设备上跑超大模型”**感兴趣，这个仓库绝对值得你star、精读、复现。

项目地址：https://github.com/TencentYoutuResearch/Palm-Infra

许可证：Apache License 2.0（完全开源，欢迎复现与二次开发）

mollm — 让大模型走下"显卡神坛"，跑进每一台ARM设备。