Skip to content

qwen4exp: sum the indexer heads by slices #28023

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ServeurpersoCom merged 2 commits into from
Sep 1, 2026
+11 −4
Merged

qwen4exp: sum the indexer heads by slices #28023

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ead00ae
qwen4exp: sum the indexer heads by slices
ServeurpersoCom Aug 30, 2026
e066e13
qwen4exp: drop the redundant cont on the indexer query
ServeurpersoCom Aug 31, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 11 additions & 4 deletions src/models/qwen4exp.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -576,12 +576,19 @@ ggml_tensor * llama_model_qwen4exp::graph::build_qsa_top_k(
// rectify each head dot product before the sum, as in the DeepSeek lightning indexer
// mul_mat matches ne[2], so the queries of stream s only meet the blocks of stream s
ggml_tensor * score = ggml_mul_mat(ctx0, pooled,
ggml_reshape_3d(ctx0, ggml_cont(ctx0, q), idx_dim, n_idx_h*n_tps, n_stream));
ggml_reshape_3d(ctx0, q, idx_dim, n_idx_h*n_tps, n_stream));
score = ggml_reshape_4d(ctx0, score, n_blocks, n_idx_h, n_tps, n_stream);
score = ggml_relu(ctx0, score);
score = ggml_cont(ctx0, ggml_permute(ctx0, score, 1, 0, 2, 3));
score = ggml_sum_rows(ctx0, score);
score = ggml_reshape_3d(ctx0, score, n_blocks, n_tps, n_stream);

// the heads sit side by side on ne[1] and there are only a few of them
ggml_tensor * summed = nullptr;
for (int64_t h = 0; h < n_idx_h; ++h) {
ggml_tensor * slice = ggml_view_3d(ctx0, score, n_blocks, n_tps, n_stream,
score->nb[2], score->nb[3], h*score->nb[1]);
summed = summed ? ggml_add(ctx0, summed, slice) : ggml_cont(ctx0, slice);
}
Comment on lines +583 to +589

@am17an am17an Aug 30, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of this thing, can we add an operation in the backends which are able to sum along as axis, similar to pytorch sum(axis=), it would be make a lot of permute->cont->sum_rows operations better supported. cc @ggerganov

@am17an am17an Aug 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not required for this PR though, just a suggestion

@ServeurpersoCom ServeurpersoCom Aug 30, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, I've added ggml ops before and I'd be happy to do this one as a follow up, with the tests and the backends. I'm getting the M5 shortly for Metal, and the CI should cover me for AMD.
It would clean up the permute -> cont -> sum_rows pattern in several models here. And reducing along ne1 with a large ne0 is the good shape on GPU anyway, so it should beat the transpose on top of removing the copy.

@ggerganov ggerganov Aug 30, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before adding an op, take a look if the graph is optimally constructed. Often cases, having to do such permute->cont->sum_rows means that earlier in the graph the data wasn't arranged properly. I'm not sure if this is the case here, but I would first look for that.

@ServeurpersoCom ServeurpersoCom Aug 30, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had a look: the layout is already fine, the matmul puts the heads on ne[1] with n_blocks as the fast axis so the slices are plain views, and what forces the reduction is the relu between the matmul and the sum.

I also tried dropping the redundant ggml_cont on q before the matmul, since rope already returns it contiguous. It works, but alternated A/B in both orders shows no measurable difference on prefill, the run to run drift is larger than the gap, so I left it out.

On the op: with only 4 heads a chain of adds does the job here, so it would mostly be for readability. The cases worth looking at are the models where the reduced axis is big enough that a chain of adds stops being reasonable, since that is where we are forced to transpose today.

@ggerganov ggerganov Aug 31, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also tried dropping the redundant ggml_cont on q before the matmul, since rope already returns it contiguous. It works, but alternated A/B in both orders shows no measurable difference on prefill, the run to run drift is larger than the gap, so I left it out.

It's better to remove the cont - it is a redundant op. Even if it is not measurable, there is no reason to have redundant nodes in the graph.

@ServeurpersoCom ServeurpersoCom Aug 31, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, same goes for this one also, since ggml_add allocates a contiguous result anyway:

-        summed = summed ? ggml_add(ctx0, summed, slice) : ggml_cont(ctx0, slice);
+        summed = summed ? ggml_add(ctx0, summed, slice) : slice;

Greedy output is unchanged. It only holds because n_idx_h is 4 here, so the loop always runs at least one add: with a single head summed would stay a view, and the paths downstream would be the ones materialising it.


score = summed;
cb(score, "indexer_score", il);

// one value per block, so it is cheaper to bias here than after the cells are expanded
Expand Down
Loading