Skip to content

[Perf][DSv4.1] Pin the low-latency MXFP8 GEMM tactics at TP8 and without autotuning - #64147

Open
Schnitzel wants to merge 3 commits into
vllm-project:mainfrom
Schnitzel:dsv41-tp8-ll-gemm-tactics
Open

Schnitzel wants to merge 3 commits into
vllm-project:mainfrom
Schnitzel:dsv41-tp8-ll-gemm-tactics

Conversation

@Schnitzel

@Schnitzel Schnitzel commented Oct 27, 2026 •

Copy link
Copy Markdown

Overview

Pin the specialized decode's low-latency MXFP8 GEMM tactics for TP8 too, and use the pins without autotuning. Stacked on #64146 and #64144 (their commits are included; please review only the last commit).

Claims

  • The pins are keyed by (N, K, TP), and the TP8 shapes are added.
  • The pinned tactic now goes first in FlashInfer's tactic list for good. So the untuned runner (enable_flashinfer_autotune: false) and the publishing wo_b GEMM use it too, instead of FlashInfer's generic first tactic.
  • TP8 over two GB300 trays, DSpark, autotuning off: one request's decode step 3,926 → 3,834 µs (+2.4 % tok/s).

Validation

  • test_kernels.py::test_low_latency_mxfp8_mm and the new test_pinned_tactics_by_tensor_parallel_size pass on GB300 (vLLM nightly 5d35ce39, FlashInfer 0.7.2.post1).
  • A TP8 serve with this stack starts and answers correctly.
  • Step time: 5–8 requests per variant, same trays, with our deployment's patch set (c50aca1 + [Perf][DSv4.1] DSpark draft on the specialized decode #61869 + these PRs). Tetris single request: 1,500 ± 36 → 1,543 ± 79 tok/s.

Details

  • Without autotuning, FlashInfer's runner takes the first tactic in the list: one CTA per 128 output columns. At TP8 that is 14 CTAs for fused_wqa_wkv (N=1792) and 32 for wq_b (N=4096).
  • Autotuning across two trays is slow, because of the cross-rank tuning sync. And split-K tactics tuned in isolation are slower inside the decode step's PDL chain, which is why the pins exist in the first place.
  • fused_wqa_wkv is replicated, so at TP8 it has the same shape as at TP4. It pins split-K 2 there instead of 4. wq_b and wo_b halve.
  • If FlashInfer does not list a pinned tactic, the order is unchanged and it falls back to tuning or its default as before.
  • [Perf][DSv4.1] Extend the latency_specialized decode on NVIDIA #63921 re-keys the TP4 pins per row bucket. Whichever lands second will merge the two tables.

Pull Request Checklist
  • I used vLLM's /pr-checklist skill. (Mandatory for agents, optional for humans).

  • AI assistance was used during the creation of this PR.

  • Design Fit: Minimizes impact on core components, reuses existing functionality, and justifies added complexity.

  • Testing and Validation: Validates the change and ensures any added tests are meaningful and reliable, with CI coverage or documented CI resource constraints and validation performed outside CI.

  • Code Quality and Style: Keeps code and comments clear and concise, and updates relevant documentation and examples.

  • Pull Request Contents: Includes a brief summary and relevant links, supports claims with evidence, explains root causes and implementation trade-offs, and follows the contributing guide.

🤖 Generated with Claude Code

Schnitzel and others added 3 commits October 27, 2026 21:33
The Lamport all-reduce + mHC kernel published each rank's contribution with
multimem stores, so it needed an NVLink multicast mapping of its mailbox and
the specialized decode refused to start without one. An NVLink partition has
a fixed number of multicast groups shared by every engine in it, so engines
that start later run out of them.

When the symmetric-memory rendezvous maps no multicast object (on any rank),
the publish kernels and the publishing wo_b GEMM now store into every rank's
mailbox through a table of their base addresses. Multicast stays the default
where it is available; VLLM_DSV41_MHC_UNICAST=1 forces the unicast path.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Michael Schmid <mschmid@mirantis.com>
Allow tensor parallel size 8 for the DeepSeek-V4.1 specialized decode and its
fused all-reduce + mHC: two GB300 trays of an NVL72 NVLink domain.

At TP8 each rank holds a 288-column slice of the routed experts' 2304-wide
intermediate, padded to 384 by the TRT-LLM-gen weight conversion. The routed
expert GEMMs now take the slice from the weights' padded width (576/640 at
TP4, 288/384 at TP8): GEMM1 uses ceil(2 * slice / 128) m tiles (5 at TP8, whose
last 32 H columns come from zero weights) and zeroes the remaining 64 padding
columns from where the tiles end.

The routed-expert test compares against FlashInfer's TRT-LLM-gen MoE at both
slices.

Signed-off-by: Michael Schmid <mschmid@mirantis.com>
…out autotuning

The specialized decode pins one tactic per attention projection for 5-8 rows,
because split-K tactics tuned in isolation are slower inside the decode step's
PDL chain. The pins covered the TP4 shapes only and applied only while
FlashInfer autotuned. Without autotuning (for instance at TP8 across two trays,
where the cross-rank tuning sync is slow) the runner falls back to FlashInfer's
generic first tactic, one CTA per 128 output columns: 14 CTAs for
fused_wqa_wkv (N=1792) and 32 for wq_b at TP8 (N=4096).

- Key the pins by (N, K, TP) and add TP8 (fused_wqa_wkv is replicated, so it
  shares its shape with TP4 but pins split-K 2 there; wq_b and wo_b halve).
- Put the pinned tactic first in FlashInfer's tactic list for good, so the
  untuned runner and the publishing wo_b GEMM use it too.

On DeepSeek-V4.1-Flash, TP8 over two GB300 trays with DSpark and autotuning
off, one request's decode step went from 3,926 to 3,834 us (+2.4 % tok/s;
same trays, 5-8 requests per variant).

Signed-off-by: Michael Schmid <mschmid@mirantis.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.

@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. Reviewers with write access and configured trusted contributors can comment /ci run for upstream CI or /amd-ci run for AMD CI only whenever CI signals are needed.

Once the PR is approved or has the ready label, the PR author can also use the corresponding /ci run, /ci retry, and /ci cancel commands, or their /amd-ci variants. New commits do not start upstream CI automatically.

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.

🚀

@mergify mergify Bot added deepseek Related to DeepSeek models DSv4.1 Related to DeepSeek-V4.1 models agents Related to information for agents labels Oct 27, 2026
@mergify

mergify Bot commented Oct 28, 2026

Copy link
Copy Markdown
Contributor

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @Schnitzel.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

@mergify mergify Bot added the needs-rebase label Oct 28, 2026

This branch has not been deployed

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

Labels

agents Related to information for agents deepseek Related to DeepSeek models DSv4.1 Related to DeepSeek-V4.1 models needs-rebase

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant