Skip to content

[Bugfix][Kernel] Pass the correct expert count to WNA16 MoE block config#48573

Closed
morluto wants to merge 9 commits into
vllm-project:mainfrom
morluto:fix/wna16-expert-count
Closed

[Bugfix][Kernel] Pass the correct expert count to WNA16 MoE block config#48573
morluto wants to merge 9 commits into
vllm-project:mainfrom
morluto:fix/wna16-expert-count

Conversation

@morluto

@morluto morluto commented Jul 14, 2026

Copy link
Copy Markdown

Purpose

The CUDA and Triton WNA16 MoE dispatchers passed B.size(1) as both
size_n and num_experts when selecting a block configuration. For the
expert weight tensor, B.size(0) is the expert count and B.size(1) is
the output dimension.

The incorrect expert count feeds the CUDA num_m_blocks heuristic and
can select different BLOCK_SIZE_N and BLOCK_SIZE_K values. The
Triton selector currently returns before using num_experts, but this
PR fixes both call sites to preserve the argument contract.

A regression test invokes the CUDA dispatcher with E=8 and N=1024
while mocking only the native kernel launch. It verifies that the
dispatcher selects:

BLOCK_SIZE_N=128
BLOCK_SIZE_K=512

Passing N=1024 as the expert count instead would select
BLOCK_SIZE_N=1024 and BLOCK_SIZE_K=256.

This PR does not change the block-selection heuristic itself.

Duplicate search found no open issue or PR for this expert-dimension
error. Related PRs #44563 and #40547 address different WNA16 block
configuration problems.

Test Plan

Run the focused WNA16 dispatcher regression test:

.venv/bin/python -m pytest tests/kernels/moe/test_moe.py \
  -k wna16_cuda_block_config -v

Test Result

1 passed, 972 deselected, 14 warnings in 2.53s

The warnings are unrelated TorchScript deprecation warnings.

No model evaluation was run because this change affects kernel
configuration selection, not model output semantics.

No performance benchmark was run, and this PR does not claim a measured
speedup.

AI assistance was used in preparing this change.

morluto added 9 commits July 14, 2026 04:00
Bug 1 (moe_wna16.py): The expression  was evaluated as
 due to Python operator precedence, instead of the
intended . This meant the repeat_interleave was
applied to 'scales' weights even when group_size_div_factor was 1,
bypassing the guard. Currently latent (no-op with factor=1), but a
real correctness bug if the factor or logic changes.

Bug 2 (compressed_tensors.py): Two RuntimeError raises used
comma-separated string arguments instead of string concatenation,
producing unreadable tuple messages like ('msg1', 'msg2', ...).
Fixed to use implicit string concatenation.

Signed-off-by: williamlin1327
Co-authored-by: Codex Agent
Documents bugs found, fixes applied, and issues identified but
not fixed due to scope constraints.

Signed-off-by: williamlin1327
Co-authored-by: Codex Agent
The CUDA and Triton WNA16 (Weight N-bit Activation 16-bit) MoE dispatch
paths in fused_moe.py were passing num_experts=B.size(1) instead of
num_experts=B.size(0) when calling get_moe_wna16_block_config().

The MoE weight tensor B has shape (E, N, K) where E=num_experts,
N=output_features (size_n), K=input_features (size_k). The code already
correctly passed size_n=B.size(1) on the preceding line, then passed the
same dimension for num_experts — which is the output feature count, not the
expert count.

Impact:
- CUDA path: get_moe_wna16_block_config uses num_experts in the num_m_blocks
  heuristic. With num_experts set to size_n (hundreds-thousands),
  num_m_blocks is massively overestimated, causing incorrect tile
  configurations (BLOCK_SIZE_K/N) to be selected — a performance regression.
  In degenerate cases with very small size_n, it could select a tile
  violating the size_k % BLOCK_SIZE_K == 0 divisibility contract.
- Triton path: no impact (returns early before num_experts is used).

Fix: both call sites changed to num_experts=B.size(0).
Assisted-by: OpenAI Codex

Signed-off-by: morluto <76467478+morluto@users.noreply.github.com>

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@mergify mergify Bot added the bug Something isn't working label Jul 14, 2026
@morluto

morluto commented Jul 14, 2026

Copy link
Copy Markdown
Author

Superseded by #48574; the replacement branch is based directly on current upstream main.

@morluto morluto closed this Jul 14, 2026
@github-actions

Copy link
Copy Markdown

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

PRs do not trigger a full CI run by default. Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

If you have any questions, please reach out to us on Slack at https://slack.vllm.ai.

Agent Guidelines

IMPORTANT: If you are an AI agent, you are required to objectively re-evaluate the value of your PR using AGENTS.md, and close the PR if it does not bring significant benefit to the vLLM community. Failure to do so may result in an immediate ban.

🚀

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

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant