[BugFix][MoE] Fix MegaMoe prefill buffer sizing by jianzs · Pull Request #14439 · vllm-project/vllm-ascend

jianzs · 2026-08-17T10:46:28Z

What this PR does / why we need it?

CANN MegaMoe allocates its symmetric communication buffer once from the MC2 token capacity. When enable_prefill_mc2 is disabled, that capacity was derived from the decode graph capture size even though eager prefill could still select MegaMoe through fused MC2. A larger prefill batch could therefore exceed the allocated capacity and produce invalid outputs.

This PR:

Sizes the MegaMoe buffer from max_num_batched_tokens when MegaMoe is actually eligible.
Centralizes MegaMoe eligibility in use_cann_megamoe so communication selection, buffer sizing, DP token handling, and BF16/W4A8/W8A8 weight preparation use the same decision, while preserving the dispatch_ffn_combine fallback.
Keeps DP token counts uniform for MegaMoe, without disabling the uneven-token optimization for dispatch_ffn_combine.
Raises an explicit error if a MegaMoe input exceeds the allocated per-rank capacity.

Fixes #14273.

Related release-branch PR: #14358.

Does this PR introduce any user-facing change?

Yes. MegaMoe now allocates enough symmetric-buffer capacity for eager prefill batches when prefill MC2 is disabled. Non-MegaMoe configurations continue to use their existing communication path, and an invalid capacity is reported explicitly instead of producing incorrect output.

How was this patch tested?

git diff --check
python3 -m py_compile vllm_ascend/ascend_forward_context.py vllm_ascend/ops/fused_moe/moe_comm_method.py vllm_ascend/ops/fused_moe/routed_experts.py vllm_ascend/quantization/methods/w4a8.py vllm_ascend/quantization/methods/w8a8_dynamic.py vllm_ascend/utils.py
ruff check vllm_ascend/ascend_forward_context.py vllm_ascend/ops/fused_moe/moe_comm_method.py vllm_ascend/ops/fused_moe/routed_experts.py vllm_ascend/quantization/methods/w4a8.py vllm_ascend/quantization/methods/w8a8_dynamic.py vllm_ascend/utils.py
The underlying buffer-sizing fix was validated end-to-end with DeepSeek V4 W8A8 inference on Ascend A3 using eager prefill, fused MC2 enabled, and prefill MC2 disabled. A prefill batch larger than the decode graph capture capacity completed without non-finite output and produced the expected response. This final main-branch adaptation was verified with the static checks above and was not rerun end-to-end.

No unit test was added because the failure depends on CANN MegaMoe symmetric-buffer allocation and collective execution across an NPU communication group.

vLLM main: vllm-project/vllm@ba07e4a

gemini-code-assist · 2026-08-17T10:46:38Z

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a bug in CANN MegaMoe buffer sizing where prefill batches could exceed allocated capacity when 'enable_prefill_mc2' was disabled. By centralizing the eligibility logic and ensuring the buffer is sized based on actual batched token limits, the changes ensure stability for eager prefill scenarios. The update also includes defensive programming to catch and report capacity violations explicitly.

Highlights

MegaMoe Buffer Sizing: Corrected the MegaMoe buffer allocation to use 'max_num_batched_tokens' when eligible, preventing capacity overflows during eager prefill.
Centralized Eligibility Logic: Introduced 'use_cann_megamoe' to unify MegaMoe eligibility checks across communication, buffer sizing, and weight preparation.
Error Handling: Added an explicit validation check to raise an error if MegaMoe input tokens exceed the allocated per-rank capacity.

New Features

🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

github-actions · 2026-08-17T10:47:40Z

👋 Hi! Thank you for contributing to the vLLM Ascend project. The following points will speed up your PR merge:‌‌

A PR should do only one thing, smaller PRs enable faster reviews.
Every PR should include unit tests and end-to-end tests ‌to ensure it works and is not broken by other future PRs.
Write the commit message by fulfilling the PR description to help reviewer and future developers understand.

If CI fails, you can run linting and testing checks locally according Contributing and Testing.

Tip

💡 Consider Linking a Related Issue or RFC

Your PR title contains the [BugFix] tag, indicating a bug fix or new feature.

Linking a related issue or RFC in the PR description is strongly encouraged — it gives reviewers helpful context and speeds up the review. You can use any of these keywords:

Fixes #<issue_number>
Closes #<issue_number>
Resolves #<issue_number>
Refs #<rfc_or_issue_number> (for RFCs)

🙏 Thanks for helping us keep the project well-organized!

gemini-code-assist

Code Review

Suggested PR Title:

[Ops][Feature] Refactor CANN MegaMoe activation and add token limit validation

Suggested PR Summary:

### What this PR does / why we need it?
This PR refactors the CANN MegaMoe activation logic by introducing a centralized `use_cann_megamoe` helper function across various modules, replacing direct checks on `_MEGA_MOE_SUPPORTED`. It also adds a safety check in `_apply_cann_mega_moe` to raise a `ValueError` if the number of tokens per rank exceeds the allocated symmetric buffer capacity.

### Does this PR introduce _any_ user-facing change?
No, this is an internal refactoring and validation improvement.

### How was this patch tested?
CI/CD tests.

Feedback Summary:
One review comment was kept which suggests using getattr to safely access max_num_tokens_per_rank on self.token_dispatcher to prevent potential AttributeErrors in mock or testing environments.

gemini-code-assist · 2026-08-17T10:48:05Z

+        num_tokens = fused_experts_input.hidden_states.shape[0]
+        num_max_tokens = self.token_dispatcher.max_num_tokens_per_rank
+        if num_tokens > num_max_tokens:
+            raise ValueError(
+                f"MegaMoe received {num_tokens} tokens per rank, but its symmetric buffer "
+                f"was allocated for at most {num_max_tokens}. Increase max_num_batched_tokens "
+                "or disable fused MC2."
+            )


Using direct attribute access self.token_dispatcher.max_num_tokens_per_rank can raise an AttributeError if the attribute is not set or initialized on the dispatcher (e.g., in certain testing or mock environments). To be robust and consistent with how this attribute is accessed elsewhere in this file (such as using getattr with a default value in _init_mega_moe_symm_buffer), it is safer to use getattr here as well.

Suggested change

num_tokens = fused_experts_input.hidden_states.shape[0]

num_max_tokens = self.token_dispatcher.max_num_tokens_per_rank

if num_tokens > num_max_tokens:

raise ValueError(

f"MegaMoe received {num_tokens} tokens per rank, but its symmetric buffer "

f"was allocated for at most {num_max_tokens}. Increase max_num_batched_tokens "

"or disable fused MC2."

)

num_tokens = fused_experts_input.hidden_states.shape[0]

num_max_tokens = getattr(self.token_dispatcher, "max_num_tokens_per_rank", None)

if num_max_tokens is not None and num_tokens > num_max_tokens:

raise ValueError(

f"MegaMoe received {num_tokens} tokens per rank, but its symmetric buffer "

f"was allocated for at most {num_max_tokens}. Increase max_num_batched_tokens "

"or disable fused MC2."

)

github-actions · 2026-08-21T03:44:36Z

This pull request has conflicts, please resolve those before we can evaluate the pull request.

czydyy · 2026-08-28T12:52:24Z

/rerun

[Bot]: rerun completed.

Rerun (failed jobs only):

E2E

github-actions · 2026-08-29T01:46:47Z

This pull request has conflicts, please resolve those before we can evaluate the pull request.

czydyy · 2026-08-30T06:30:59Z

/rerun

[Bot]: rerun completed.

Rerun (failed jobs only):

E2E

czydyy · 2026-08-30T08:38:01Z

/rerun
[Bot]: rerun completed.

Rerun (failed jobs only):

E2E

github-actions · 2026-08-31T01:21:15Z

This pull request has conflicts, please resolve those before we can evaluate the pull request.

coder-fny · 2026-08-31T12:45:01Z

+    @patch("vllm_ascend.quantization.methods.w4a8.get_current_vllm_config", new=lambda: None)
+    @patch("vllm_ascend.quantization.methods.w4a8.use_cann_megamoe", new=lambda _: False)
+    @patch("vllm_ascend.quantization.methods.w4a8.get_ascend_config")
+    @patch("vllm_ascend.quantization.methods.w4a8.maybe_trans_nz")


it should be w4a8.w4a8 rather than w4a8

github-actions · 2026-09-01T06:43:10Z

This pull request has conflicts, please resolve those before we can evaluate the pull request.

MegaMoe allocates a symmetric communication buffer once from the MC2 token capacity. When enable_prefill_mc2 is disabled, that capacity was derived from the decode graph capture size even though fused MC2 can still select MegaMoe for eager prefill. Larger prefill batches could exceed the configured buffer and produce invalid outputs. Size capacity from max_num_batched_tokens whenever A3 MegaMoe is actually eligible, while retaining existing graph sizing for dispatch_ffn_combine and other MC2 paths. Centralize that eligibility in use_cann_megamoe so communication selection, buffer sizing, DP token uniformity, and BF16/W4A8/W8A8 weight preparation cannot disagree. Reject inputs exceeding the allocated MegaMoe buffer while preserving the uneven-token optimization for dispatch_ffn_combine. Signed-off-by: Zheng Shoujian <zheng.shoujian@outlook.com>

Mock the centralized MegaMoe selector together with current config evaluation in weight-loading tests. Extend forward-context stubs with use_mega_moe so the existing non-MegaMoe assertions remain isolated from the new shared state. Signed-off-by: Zheng Shoujian <zheng.shoujian@outlook.com>

Signed-off-by: Zheng Shoujian <zheng.shoujian@outlook.com>

…are profiles (#15478) ## What - add the final MoE/compilation/sampling hardware capabilities and a `MoECommPolicy` - migrate MoE communication selection, graph fusion gates, routing, shared experts, token dispatch, SwiGLU-OAI MX quant, and top-k/top-p sampling away from direct device identity checks - preserve the latest upstream Situ, hierarchical communication, SFA, DSV4, sampler, and CANN MegaMoe paths - model the new A3-only CANN MegaMoe consumer with `HardwareCapability.CANN_MEGAMOE` and update the exact capability matrix ## Why Shared business logic should consume hardware capabilities and implementation policies instead of branching on Ascend device identities. This keeps hardware detection/profile registration as the single identity boundary and makes the final consumers explicit. This is a refactor only; there is no user-visible behavior change. ## Series Device HAL / Hardware Profile refactor 7/N. Depends on merged #15407 (`d4ebe8a0e0fdf56135507259f90f80a45f736cab`) and is rebased onto current `main` (`30f54b5c341f015bcc124022e62156d3e5ef5919`). This base includes the GLM5.3 documentation-link fix from #15508 and the MegaMoe prefill update from #14439. ## Testing - `ruff check` on all 14 changed Python files - `ruff format --check` on all 14 changed Python files - `python3 -m compileall -q` on all 14 changed Python files - `git diff --check upstream/main..HEAD` - production-code scan for newly introduced direct device-identity branches - E2E run https://github.com/vllm-project/vllm-ascend/actions/runs/33579196584: 23 successful jobs, 4 skipped, zero failures; CPU, all selected NPU jobs, 310P, upstream, pre-commit, DCO, Read the Docs, and `ci-gate` succeeded The local static checks above passed. The development server does not provide the complete pytest/mypy/vLLM environment, so targeted unit tests and Python 3.10/3.11/3.12 mypy comparison are covered by the successful CI run and are not claimed as local results. --------- Signed-off-by: frost_mourne <2906339855@qq.com>

### What this PR does / why we need it? CANN MegaMoe allocates its symmetric communication buffer once from the MC2 token capacity. When `enable_prefill_mc2` is disabled, that capacity was derived from the decode graph capture size even though eager prefill could still select MegaMoe through fused MC2. A larger prefill batch could therefore exceed the allocated capacity and produce invalid outputs. This PR: - Sizes the MegaMoe buffer from `max_num_batched_tokens` when MegaMoe is actually eligible. - Centralizes MegaMoe eligibility in `use_cann_megamoe` so communication selection, buffer sizing, DP token handling, and BF16/W4A8/W8A8 weight preparation use the same decision, while preserving the `dispatch_ffn_combine` fallback. - Keeps DP token counts uniform for MegaMoe, without disabling the uneven-token optimization for `dispatch_ffn_combine`. - Raises an explicit error if a MegaMoe input exceeds the allocated per-rank capacity. Fixes vllm-project#14273. Related release-branch PR: vllm-project#14358. ### Does this PR introduce _any_ user-facing change? Yes. MegaMoe now allocates enough symmetric-buffer capacity for eager prefill batches when prefill MC2 is disabled. Non-MegaMoe configurations continue to use their existing communication path, and an invalid capacity is reported explicitly instead of producing incorrect output. ### How was this patch tested? - `git diff --check` - `python3 -m py_compile vllm_ascend/ascend_forward_context.py vllm_ascend/ops/fused_moe/moe_comm_method.py vllm_ascend/ops/fused_moe/routed_experts.py vllm_ascend/quantization/methods/w4a8.py vllm_ascend/quantization/methods/w8a8_dynamic.py vllm_ascend/utils.py` - `ruff check vllm_ascend/ascend_forward_context.py vllm_ascend/ops/fused_moe/moe_comm_method.py vllm_ascend/ops/fused_moe/routed_experts.py vllm_ascend/quantization/methods/w4a8.py vllm_ascend/quantization/methods/w8a8_dynamic.py vllm_ascend/utils.py` - The underlying buffer-sizing fix was validated end-to-end with DeepSeek V4 W8A8 inference on Ascend A3 using eager prefill, fused MC2 enabled, and prefill MC2 disabled. A prefill batch larger than the decode graph capture capacity completed without non-finite output and produced the expected response. This final main-branch adaptation was verified with the static checks above and was not rerun end-to-end. No unit test was added because the failure depends on CANN MegaMoe symmetric-buffer allocation and collective execution across an NPU communication group. - vLLM main: vllm-project/vllm@ba07e4a --------- Signed-off-by: Zheng Shoujian <zheng.shoujian@outlook.com>

…are profiles (vllm-project#15478) ## What - add the final MoE/compilation/sampling hardware capabilities and a `MoECommPolicy` - migrate MoE communication selection, graph fusion gates, routing, shared experts, token dispatch, SwiGLU-OAI MX quant, and top-k/top-p sampling away from direct device identity checks - preserve the latest upstream Situ, hierarchical communication, SFA, DSV4, sampler, and CANN MegaMoe paths - model the new A3-only CANN MegaMoe consumer with `HardwareCapability.CANN_MEGAMOE` and update the exact capability matrix ## Why Shared business logic should consume hardware capabilities and implementation policies instead of branching on Ascend device identities. This keeps hardware detection/profile registration as the single identity boundary and makes the final consumers explicit. This is a refactor only; there is no user-visible behavior change. ## Series Device HAL / Hardware Profile refactor 7/N. Depends on merged vllm-project#15407 (`d4ebe8a0e0fdf56135507259f90f80a45f736cab`) and is rebased onto current `main` (`30f54b5c341f015bcc124022e62156d3e5ef5919`). This base includes the GLM5.3 documentation-link fix from vllm-project#15508 and the MegaMoe prefill update from vllm-project#14439. ## Testing - `ruff check` on all 14 changed Python files - `ruff format --check` on all 14 changed Python files - `python3 -m compileall -q` on all 14 changed Python files - `git diff --check upstream/main..HEAD` - production-code scan for newly introduced direct device-identity branches - E2E run https://github.com/vllm-project/vllm-ascend/actions/runs/33579196584: 23 successful jobs, 4 skipped, zero failures; CPU, all selected NPU jobs, 310P, upstream, pre-commit, DCO, Read the Docs, and `ci-gate` succeeded The local static checks above passed. The development server does not provide the complete pytest/mypy/vLLM environment, so targeted unit tests and Python 3.10/3.11/3.12 mypy comparison are covered by the successful CI run and are not claimed as local results. --------- Signed-off-by: frost_mourne <2906339855@qq.com>

### What this PR does / why we need it? CANN MegaMoe allocates its symmetric communication buffer once from the MC2 token capacity. When `enable_prefill_mc2` is disabled, that capacity was derived from the decode graph capture size even though eager prefill could still select MegaMoe through fused MC2. A larger prefill batch could therefore exceed the allocated capacity and produce invalid outputs. This PR: - Sizes the MegaMoe buffer from `max_num_batched_tokens` when MegaMoe is actually eligible. - Centralizes MegaMoe eligibility in `use_cann_megamoe` so communication selection, buffer sizing, DP token handling, and BF16/W4A8/W8A8 weight preparation use the same decision, while preserving the `dispatch_ffn_combine` fallback. - Keeps DP token counts uniform for MegaMoe, without disabling the uneven-token optimization for `dispatch_ffn_combine`. - Raises an explicit error if a MegaMoe input exceeds the allocated per-rank capacity. Fixes vllm-project#14273. Related release-branch PR: vllm-project#14358. ### Does this PR introduce _any_ user-facing change? Yes. MegaMoe now allocates enough symmetric-buffer capacity for eager prefill batches when prefill MC2 is disabled. Non-MegaMoe configurations continue to use their existing communication path, and an invalid capacity is reported explicitly instead of producing incorrect output. ### How was this patch tested? - `git diff --check` - `python3 -m py_compile vllm_ascend/ascend_forward_context.py vllm_ascend/ops/fused_moe/moe_comm_method.py vllm_ascend/ops/fused_moe/routed_experts.py vllm_ascend/quantization/methods/w4a8.py vllm_ascend/quantization/methods/w8a8_dynamic.py vllm_ascend/utils.py` - `ruff check vllm_ascend/ascend_forward_context.py vllm_ascend/ops/fused_moe/moe_comm_method.py vllm_ascend/ops/fused_moe/routed_experts.py vllm_ascend/quantization/methods/w4a8.py vllm_ascend/quantization/methods/w8a8_dynamic.py vllm_ascend/utils.py` - The underlying buffer-sizing fix was validated end-to-end with DeepSeek V4 W8A8 inference on Ascend A3 using eager prefill, fused MC2 enabled, and prefill MC2 disabled. A prefill batch larger than the decode graph capture capacity completed without non-finite output and produced the expected response. This final main-branch adaptation was verified with the static checks above and was not rerun end-to-end. No unit test was added because the failure depends on CANN MegaMoe symmetric-buffer allocation and collective execution across an NPU communication group. - vLLM main: vllm-project/vllm@ba07e4a --------- Signed-off-by: Zheng Shoujian <zheng.shoujian@outlook.com>

…are profiles (vllm-project#15478) ## What - add the final MoE/compilation/sampling hardware capabilities and a `MoECommPolicy` - migrate MoE communication selection, graph fusion gates, routing, shared experts, token dispatch, SwiGLU-OAI MX quant, and top-k/top-p sampling away from direct device identity checks - preserve the latest upstream Situ, hierarchical communication, SFA, DSV4, sampler, and CANN MegaMoe paths - model the new A3-only CANN MegaMoe consumer with `HardwareCapability.CANN_MEGAMOE` and update the exact capability matrix ## Why Shared business logic should consume hardware capabilities and implementation policies instead of branching on Ascend device identities. This keeps hardware detection/profile registration as the single identity boundary and makes the final consumers explicit. This is a refactor only; there is no user-visible behavior change. ## Series Device HAL / Hardware Profile refactor 7/N. Depends on merged vllm-project#15407 (`d4ebe8a0e0fdf56135507259f90f80a45f736cab`) and is rebased onto current `main` (`30f54b5c341f015bcc124022e62156d3e5ef5919`). This base includes the GLM5.3 documentation-link fix from vllm-project#15508 and the MegaMoe prefill update from vllm-project#14439. ## Testing - `ruff check` on all 14 changed Python files - `ruff format --check` on all 14 changed Python files - `python3 -m compileall -q` on all 14 changed Python files - `git diff --check upstream/main..HEAD` - production-code scan for newly introduced direct device-identity branches - E2E run https://github.com/vllm-project/vllm-ascend/actions/runs/33579196584: 23 successful jobs, 4 skipped, zero failures; CPU, all selected NPU jobs, 310P, upstream, pre-commit, DCO, Read the Docs, and `ci-gate` succeeded The local static checks above passed. The development server does not provide the complete pytest/mypy/vLLM environment, so targeted unit tests and Python 3.10/3.11/3.12 mypy comparison are covered by the successful CI run and are not claimed as local results. --------- Signed-off-by: frost_mourne <2906339855@qq.com>

jianzs requested review from realliujiaxu and zzzzwwjj as code owners August 17, 2026 10:46

github-actions Bot added module:ops module:core module:quantization labels Aug 17, 2026

gemini-code-assist Bot reviewed Aug 17, 2026

View reviewed changes

jianzs added the ready label Aug 17, 2026

jianzs force-pushed the fix/megamoe-prefill-buffer-capacity-main branch 2 times, most recently from d81fd73 to 42279c5 Compare August 18, 2026 09:11

jianzs requested a review from kunpengW-code as a code owner August 18, 2026 09:11

This was referenced Aug 18, 2026

[Bug]: DeepSeek V4 PD output corruption with CANN 9.1.0 (works with CANN 9.0.1) #14273

Closed

[v0.25.1rc][BugFix][MoE] Fix MegaMoe prefill buffer sizing #14519

Closed

[v0.25.1rc][BugFix][MoE] Keep fused MC2 on legacy dispatch path #14530

Closed

jianzs mentioned this pull request Aug 20, 2026

[v0.26.0rc][BugFix][MoE] Fix MegaMoe prefill buffer sizing #14358

Merged

jianzs force-pushed the fix/megamoe-prefill-buffer-capacity-main branch from f77f1ea to 588a676 Compare August 20, 2026 04:10

github-actions Bot added the module:tests label Aug 20, 2026

wangxiyuan removed the ready label Aug 20, 2026

github-actions Bot added the merge-conflicts label Aug 21, 2026

jianzs force-pushed the fix/megamoe-prefill-buffer-capacity-main branch from 588a676 to 2b2e768 Compare August 22, 2026 04:01

github-actions Bot removed the merge-conflicts label Aug 22, 2026

kunpengW-code added the ready-precise run selected e2e test for pr label Aug 26, 2026

github-actions Bot added the merge-conflicts label Aug 29, 2026

jianzs force-pushed the fix/megamoe-prefill-buffer-capacity-main branch from b641690 to 54b0f4d Compare August 29, 2026 04:24

github-actions Bot removed the merge-conflicts label Aug 29, 2026

github-actions Bot added the merge-conflicts label Aug 31, 2026

jianzs force-pushed the fix/megamoe-prefill-buffer-capacity-main branch from 54b0f4d to a68edb1 Compare August 31, 2026 11:40

github-actions Bot removed the merge-conflicts label Aug 31, 2026

coder-fny reviewed Aug 31, 2026

View reviewed changes

weijinqian0 previously approved these changes Sep 1, 2026

View reviewed changes

github-actions Bot added the merge-conflicts label Sep 1, 2026

weijinqian0 enabled auto-merge (squash) September 1, 2026 08:07

jianzs added 5 commits September 1, 2026 10:54

lint code

a90a199

Signed-off-by: Zheng Shoujian <zheng.shoujian@outlook.com>

fix ci

8ea0d55

Signed-off-by: Zheng Shoujian <zheng.shoujian@outlook.com>

fix ci

e72d2c3

Signed-off-by: Zheng Shoujian <zheng.shoujian@outlook.com>

jianzs dismissed weijinqian0’s stale review via e72d2c3 September 1, 2026 10:54

jianzs force-pushed the fix/megamoe-prefill-buffer-capacity-main branch from 800f92a to e72d2c3 Compare September 1, 2026 10:54

github-actions Bot removed the merge-conflicts label Sep 1, 2026

Merge branch 'main' into fix/megamoe-prefill-buffer-capacity-main

e5663ba

zzzzwwjj approved these changes Sep 1, 2026

View reviewed changes

Merge branch 'main' into fix/megamoe-prefill-buffer-capacity-main

2d68181

weijinqian0 merged commit 30f54b5 into vllm-project:main Sep 1, 2026
30 checks passed

Tflowers-0129 mentioned this pull request Sep 2, 2026

[Refactor][Device][7/N] Migrate MoE compilation and sampling to hardware profiles #15478

Merged

Navigation Menu

[BugFix][MoE] Fix MegaMoe prefill buffer sizing - #14439

[BugFix][MoE] Fix MegaMoe prefill buffer sizing#14439
weijinqian0 merged 7 commits into
vllm-project:mainfrom
jianzs:fix/megamoe-prefill-buffer-capacity-main

jianzs commented Aug 17, 2026 •

edited by github-actions Bot

Loading

Uh oh!

gemini-code-assist Bot commented Aug 17, 2026

Uh oh!

github-actions Bot commented Aug 17, 2026

💡 Consider Linking a Related Issue or RFC

Uh oh!

gemini-code-assist Bot left a comment

Uh oh!

gemini-code-assist Bot Aug 17, 2026

Uh oh!

github-actions Bot commented Aug 21, 2026

Uh oh!

czydyy commented Aug 28, 2026 •

edited by vllm-ascend-ci

Loading

Uh oh!

github-actions Bot commented Aug 29, 2026

Uh oh!

czydyy commented Aug 30, 2026 •

edited by vllm-ascend-ci

Loading

Uh oh!

czydyy commented Aug 30, 2026 •

edited by vllm-ascend-ci

Loading

Uh oh!

github-actions Bot commented Aug 31, 2026

Uh oh!

coder-fny Aug 31, 2026

Uh oh!

github-actions Bot commented Sep 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Conversation

jianzs commented Aug 17, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this PR does / why we need it?

Does this PR introduce any user-facing change?

How was this patch tested?

Uh oh!

gemini-code-assist Bot commented Aug 17, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

github-actions Bot commented Aug 17, 2026

💡 Consider Linking a Related Issue or RFC

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist Bot Aug 17, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Aug 21, 2026

Uh oh!

czydyy commented Aug 28, 2026 • edited by vllm-ascend-ci Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Aug 29, 2026

Uh oh!

czydyy commented Aug 30, 2026 • edited by vllm-ascend-ci Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

czydyy commented Aug 30, 2026 • edited by vllm-ascend-ci Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Aug 31, 2026

Uh oh!

coder-fny Aug 31, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Sep 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

jianzs commented Aug 17, 2026 •

edited by github-actions Bot

Loading

czydyy commented Aug 28, 2026 •

edited by vllm-ascend-ci

Loading

czydyy commented Aug 30, 2026 •

edited by vllm-ascend-ci

Loading

czydyy commented Aug 30, 2026 •

edited by vllm-ascend-ci

Loading