Skip to content

Fix Gemma4-E4B compute graph#1855

Merged
ikawrakow merged 1 commit into
mainfrom
ik/fix_gemma_e4b
May 21, 2026
Merged

Fix Gemma4-E4B compute graph#1855
ikawrakow merged 1 commit into
mainfrom
ik/fix_gemma_e4b

Conversation

@ikawrakow

Copy link
Copy Markdown
Owner

The issue was that the per layer token embedding tensor was loaded into the output context, so onto a GPU when present. But if this tensor was quantized with a type that does not have CUDA support for ggml_get_rows on CUDA (i.e., all quants except Q4_0, Q4_1, Q5_0, Q5_1, Q8_0), this required a copy of the per layer embedding tensor to the CPU, computing ggml_get_rows there, and copying back the result to the GPU. As the per layer embedding tensor is giant (2.8 billion elements!), this totally kills performance.

There is PR #1830, which adds CUDA support for ggml_get_rows for some k-quants. But this does not solve the actual root cause of the per layer embedding tensor being loaded into the wrong context.

With this PR CUDA performance for Gemma4-E4B is recovered to expected levels independently of the quantization type of the per layer embedding tensor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant