你想在家用电脑上跑一个大模型，显卡却装不下它，就像小厨房放不下整套厨具：以前只能把不少工作留给CPU慢慢做；现在，llama.cpp尝试只把眼下要用的那几件工具搬到GPU，并把可能再次用到的暂时留下。这项面向MoE模型的GPU专家缓存，已经在2026年10月7日合并进 llama.cpp 主分支。它值得关注，不是因为已经证明了某个固定加速幅度，而是因为它瞄准了本地运行超大模型时一个很实际的瓶颈：显存不够，但又不想放弃GPU。
模型很大，每次却只用一小部分
llama.cpp是广泛使用的本地模型推理项目，重点是在个人电脑和多种硬件上运行模型，也常承接量化模型及本地服务工具链。
这次处理的是MoE——“混合专家”模型。它内部有许多专门的子网络，称为“专家”，但每次生成内容时只会启用其中一部分。因此，模型的总参数可以很大，单步真正参与计算的部分却相对有限。
麻烦在于，所有专家的权重仍要有地方存放。显存是GPU直接使用的高速内存，速度快但容量有限；主内存由CPU管理，通常更大，可是把数据送到GPU需要额外时间。模型装不进显存时，专家只能留在主内存，推理过程便可能反复等待搬运。
不搬整座仓库，只留常用专家
这项实现源自tetherto/qvac-fabric-llm.cpp。它给留在主内存里的MoE专家增加一层GPU缓存：模型需要某个专家时，把它送进GPU计算；近期或可能再次用到的专家则暂留显存，目标是减少重复传输。
可以把它理解成书桌和书架。书架容量大，但每次起身拿书都要花时间；桌面很小，却触手可及。专家缓存不试图把整排书搬上桌，而是利用有限桌面保留刚用过、可能还会用的几本。
供稿中的社区测试显示，这套缓存可以在Windows上的AMD ROCm/HIP环境构建并运行。测试机器采用Radeon AI PRO R9700 32 GB、Ryzen 7 8700F和32 GB主内存。不过，这一结果来自单名评论者；对方还披露使用AI助手执行benchmark并起草评论，虽然称已对照日志核验，仍不能把它当成跨硬件验证。
真正关键的是“猜中多少次”
缓存并不天然等于加速。它只有在再次需要某位专家时仍能从GPU里找到，才省下搬运时间。这就是“命中”；如果没有找到，就要从主内存重新传输。
评论区有人提醒，当显存预算很低时——举例约为全部专家大小的5%——命中率可能偏低。此时逐层经PCIe传输被选中的专家，再交给GPU计算，甚至可能慢于直接让CPU计算该层全部专家。这里的5%只是与具体硬件有关的经验示例，不是经过验证的通用门槛。
讨论者还提出，只让部分层参与缓存，可能把有限显存集中到更容易命中的地方，从而改善收益。但这仍是建议和推测，材料没有给出外部基准来验证。
为什么值得关注
llama.cpp里的专家缓存经历过一场持续数月的社区接力。此前一些方案因为范围过大或维护成本难以评审而关闭；讨论也逐渐从“要不要缓存”，转向怎样把实现缩小到主仓库愿意维护。这次合并的意义，首先是让这条思路进入主线，而非停留在个人分支。
社区早先也有反例：一位开发者在低配机器上发现，缓存越大反而越慢，操作系统的页面缓存甚至快了2.5倍。原因之一是模型的专家路由接近均匀，没有足够稳定的“热门专家”。这恰好说明，专家缓存不是免费午餐；模型怎样选择专家、硬件怎样传输数据，都会改变结果。
局限与未知
- 全部实现与效果信息都来自同一个GitHub PR及相关社区讨论，缺少独立复现。
- 供稿没有完整、可交叉验证的benchmark，不能据此给出普适的加速幅度、命中率或显存节省比例。
- 低显存预算下是否值得开启缓存，以及限制参与层数能否稳定提速，仍取决于模型、路由规律和硬件。