Feature Request: mmproj GPU processing while offloading weights

[katakombi]

Prerequisites

• I am running the latest code. Mention the version if possible as well.
• I carefully followed the README.md.
• I searched using keywords relevant to my issue to make sure that I am creating a new issue that is not already open (or closed).
• I reviewed the Discussions, and have a new and useful enhancement to share.

Feature Description

I would like to request an option to use GPU-accelerated vision processing without keeping the complete multimodal projector permanently resident in VRAM.

Currently there are essentially two choices:

--mmproj-offload: fast GPU image encoding, but the projector permanently consumes a significant amount of VRAM.

--no-mmproj-offload: saves the VRAM, but image encoding runs on the CPU and can be considerably slower.

What I would like is a third option: keep the VRAM available for the LLM / KV cache most of the time, while still performing image encoding on the GPU.

There already seem to be several approaches demonstrating that this is possible:

ggml-org#20246

#140

https://github.com/valujin/beellama-kvarn

I also encountered a similar low-VRAM GPU vision approach while testing HyperQwen / vLLM.

Motivation

Currently, loading mmproj typically consumes around 1 GB of VRAM.

On VRAM-constrained GPUs, this is quite significant, especially when running large models with long context windows. That VRAM could otherwise be used for additional context, larger KV cache, draft models, or other features.

CPU-based image processing is an alternative, but in my experience it creates substantial overhead and is much slower.

For this reason, I currently often disable mmproj completely for Qwen and Gemma models: keeping it on the GPU costs too much VRAM, while processing images on the CPU is too expensive.

A low-memory GPU implementation would provide a useful middle ground:

• fast GPU-based image processing

• very low additional VRAM usage

• more VRAM available for context and KV cache

• no need to choose between fast vision processing and large context sizes

For users running modern multimodal models on GPUs with limited VRAM, this could make a substantial difference.

Possible Implementation

HyperQwen may provide a useful reference implementation. Its vLLM-based implementation seems to use a sliding-window approach for image processing, allowing the processing to remain GPU-accelerated while using only a very small amount of VRAM.

The related llama.cpp discussion also appears to cover approaches in this direction:

ggml-org#20246

I assume that a fully model-independent implementation may not be straightforward, since projector architectures differ between model families.

Still, even an implementation initially targeting a few common architectures such as Qwen and Gemma could already be very useful, and might provide a basis for a more generic solution later.

[katakombi]

Some unverified AI-analysis in addition:

There is already some promising experimental data:

• The beellama-kvarn fork implements --mmproj-host-weights, keeping projector weights in pinned host memory while the computation remains on the GPU.

• With Qwen3.8-27B this reportedly freed about 886 MiB of VRAM while making image encoding only 5–16% slower. LLM throughput remained unaffected.

• A separate llama.cpp experiment (--mmproj-vram-swap) temporarily loads the projector into otherwise unused GPU compute buffers. In the reported Qwen3.8 test, image processing improved from roughly 22 seconds on CPU to around 3.6 seconds, without permanently reserving the projector VRAM.

---

c) Possible Implementation

There appear to be several possible implementation strategies.

One already exists in the beellama-kvarn fork:

--mmproj-host-weights

The projector weights remain in pinned host memory while the arithmetic is still executed on the GPU. The author reports saving approximately 886 MiB of VRAM for the Qwen3.8 projector with only a 5–16% image-encoding performance penalty.

Another approach is discussed here:

ggml-org#20246

A prototype implementation temporarily releases GPU compute/scheduler buffers, loads the projector into that memory for image encoding, and releases it again afterwards. This avoids permanently allocating VRAM for the projector.

HyperQwen / vLLM also appears to use a low-memory GPU vision path, although its implementation may be architecture-specific.

I assume a completely model-independent solution may not be trivial, especially since projector architectures and sizes differ considerably.

Still, even exposing one of the already demonstrated approaches in BeeLlama — particularly the pinned-host-weight implementation — would already solve the main problem for models such as Qwen and Gemma.

[Anbeeld]

Ye, it's on the list. #140 already contains implementation basis.