llama.cpp Adds MoE Expert GPU Cache: A Speed Boost for VRAM-Limited Users

llama.cpp adds a GPU cache for MoE expert weights to speed up inference for VRAM-limited users.
llama.cpp PR #29887 introduces a key optimization for VRAM-constrained users: a GPU-side cache for MoE model expert weights stored in system RAM. Large MoE models like DeepSeek and Mixtral exceed consumer GPU VRAM limits, forcing CPU offload over slow PCIe — a major bottleneck. This optimization exploits expert activation locality to cache frequently used weights in VRAM, reducing PCIe transfers and boosting inference speed. The feature is still in PR stage, with real-world gains varying by hardware.
A Key Optimization for the "GPU Poor"
llama.cpp recently received a noteworthy Pull Request (#29887), submitted by contributor am17an, with the core goal of providing significant inference acceleration for MoE (Mixture of Experts) models that cannot fully fit into VRAM. The PR sparked discussion in the Reddit community, with the author even half-jokingly asking: "Are you GPU Poor? Come share your speedup results."

For users running local large language models on consumer-grade GPUs, VRAM has always been the hardest bottleneck. This is especially true for the MoE architecture models that have become popular in recent years (such as Mixtral, Qwen MoE, DeepSeekAd, etc.). While their activated parameter count is relatively manageable, the total parameter scale is massive — often too large to fully load into limited VRAM all at once. This is precisely the scenario this change aims to address.
Building a GPU Cache for Expert Weights in Host Memory
The PR title — "add a GPU cache for MoE experts kept in host memory" — makes the technical approach clear: establish a caching layer on the GPU side for MoE expert weights stored in host memory (i.e., system RAM).
The Unique Nature of MoE Inference
MoE models operate differently from traditional dense models. During each forward inference pass, the router only activates a small subset of experts for computation — not all of them. This means that at any given moment, only a fraction of the total expert weights are actually needed.
The conventional approach is to offload some layers or weights to system memory, then shuttle data back and forth between CPU and GPU over the PCIe bus during inference. Since PCIe bandwidth is far lower than VRAM bandwidth, this frequent data transfer becomes a significant performance bottleneck.
The core idea behind the MoE (Mixture of Experts) architecture is to replace the feed-forward network (FFN) layers with multiple parallel "expert" sub-networks, where a lightweight router (Router/Gating Network) dynamically selects the Top-K experts to participate in each inference pass. Take DeepSeek-V3 as an example: it has 256 experts but only activates 8 of them at a time, meaning the actually activated parameters represent only a small fraction of the total. This design dramatically reduces per-inference computation while preserving the model's overall capacity — but at the cost of an enormous total parameter count. DeepSeek-V3 has 685B total parameters, and even after Q4 quantization, the model size still exceeds 400GB, far beyond the VRAM capacity of any consumer GPU. This "computationally sparse, storage-dense" characteristic makes MoE models especially dependent on efficient weight scheduling strategies in memory-constrained environments.
The Value of a Caching Approach
Maintaining a GPU-side cache of expert weights can exploit the locality characteristic of expert activation in MoE inference — certain experts may be called repeatedly across consecutive inference steps. When a cache hit occurs, there's no need to transfer data from host memory over PCIe again, reducing transfer overhead and improving overall throughput. For hybrid deployment scenarios where some weights reside permanently in system memory, the gains from this optimization could be quite substantial.
Expert activation locality is not merely an assumption — it is an empirically supported phenomenon. Research shows that when processing semantically similar content or in continuous conversation, models tend to repeatedly activate the same set of experts, mirroring the principle of temporal locality that underpins CPU cache design. GPU cache implementations typically use replacement strategies similar to LRU (Least Recently Used): a portion of VRAM is allocated as an expert weight buffer, prioritizing retention of recently and frequently accessed expert weights. PCIe 4.0 x16 has a theoretical bandwidth of roughly 32 GB/s, while modern GPU memory bandwidth can reach hundreds of GB/s or even exceed 1 TB/s — a difference of one to two orders of magnitude. This is precisely why every percentage point improvement in cache hit rate translates into meaningful performance gains.
Who Benefits?
The target users for this change are very clearly defined — the author's so-called "GPU Poor" crowd:
- Individual users running large MoE models on a single consumer GPU (e.g., 8GB, 12GB, or 16GB VRAM);
- Deployment scenarios where model size exceeds VRAM capacity, requiring reliance on CPU offload;
- Developers and enthusiasts pursuing local deployment on a limited hardware budget.
For users who can fit an entire model into VRAM, the significance of this optimization is relatively limited — the bottleneck simply isn't data transfer. But for the vast majority of users relying on hybrid memory deployment, the expert cache could deliver a direct improvement in generation speed.
Community Testing and Open-Source Collaboration in Action
Notably, the author actively invited community members to submit their own real-world speedup data when publishing the PR. This is a typical collaboration pattern for active open-source projects like llama.cpp: features are implemented by contributors, while performance validation across real hardware is left to the large community testing across a wide variety of configurations.
Since the acceleration effect for MoE models is highly dependent on the specific model architecture, number of experts, VRAM size, and PCIe bandwidth, actual gains will vary across users. Therefore, before this feature is officially merged into the main branch, diverse community testing feedback is crucial for evaluating its generalizability and stability.
llama.cpp is an open-source project initiated by Georgi Gerganov, implementing large language model inference in pure C/C++. It first gained widespread recognition for running LLaMA models on a MacBook. Its core design goals are maximizing cross-platform compatibility and resource efficiency, with support for CPU, CUDA, Metal, Vulkan, and other backends, along with built-in multi-level quantization support in the GGUF format. Because of its extremely low barrier to entry, llama.cpp has built a large and active community of users spanning hardware from Raspberry Pis to high-end workstations. This diversity of users allows community testing to cover hardware combinations that developers would struggle to reproduce independently, making feature validation like this PR — which relies on real hardware feedback — genuinely feasible.
Summary
llama.cpp's MoE expert GPU cache change targets a long-standing pain point in local LLM inference: performance loss caused by insufficient VRAM. By caching expert weights that reside in host memory on the GPU side, it has the potential to help hardware-constrained users run MoE models that previously "wouldn't run" at much faster speeds.
It's worth noting that this change is still in the Pull Request stage, and the specific speedup magnitude and stability remain to be further verified by the community in real-world environments. For users focused on local deployment and inference efficiency, this is a development worth continuing to follow.
Related articles

Random Pruning of the DPO Computation Graph: 1.4x Training Speedup and Lower Peak Memory
DPO training too slow and memory-hungry? This paper proposes a random pruning framework for the DPO computation graph, sampling independently across position, sequence, and branch dimensions; branch pruning achieves a 1.426x step-time speedup and cuts training time by about 30%, with in-depth attribution of memory and time gains.

Why Does JEPA Underperform MLM in Longitudinal EHR Representation Learning?
New study compares JEPA and MLM for longitudinal EHR representation learning on MIMIC-IV: three JEPA variants train stably without collapse but underperform MLM; target size, not heterogeneity, drives prediction error.

Transfer Learning + Visible Light Communication: A New Approach to Energy-Efficient Indoor Positioning
A study proposes a transfer learning-based visible light communication indoor positioning method, achieving 47% accuracy improvement on the BOSCH factory dataset, 67.5% model efficiency under high noise, and introducing the ME composite metric for energy-efficient positioning in energy-constrained industrial IoT scenarios.