Skip to content

fix(cambricon): stop index autotune from killing the process on untileable expand_shape - #5510

Open
tengqm wants to merge 1 commit into
flagos-ai:masterfrom
tengqm:fix/cambricon-index-expand-shape
Open

fix(cambricon): stop index autotune from killing the process on untileable expand_shape#5510
tengqm wants to merge 1 commit into
flagos-ai:masterfrom
tengqm:fix/cambricon-index-expand-shape

Conversation

@tengqm

@tengqm tengqm commented Aug 15, 2026

Copy link
Copy Markdown
Contributor

Problem

E2E on cambricon MLU590 (vLLM 0.20.2 + flag_gems 5.3.4, inductor-wrapped context), the index op autotune kills the whole process instead of skipping a bad config:

RuntimeError: PassManager::run failed
'tensor.expand_shape' op expected dimension 0 of collapsed type to be static value of 4

Root cause: the MLU backend's AutoTileForTritonPass raises a plain RuntimeError on the tensor.expand_shape generated for the BLOCK_SIZE0=4 x BLOCK_SIZE1=4096 config (collapse [1, 4, 4096]). RuntimeError is outside triton's autotuner catch list (OutOfResources, CompileTimeAssertionFailure, PTXASError — all TritonError subclasses), so the exception escapes the tuner, propagates through libentry, and kills the caller (vLLM EngineCore dead).

Standalone (non-wrapped) the config compiles fine; the failure only manifests in inductor-wrapped contexts where shapes are dynamic. Reproducer: index on a (15, 4096) bf16 tensor under inductor wrap, BLOCK_SIZE0=4, BLOCK_SIZE1=4096, num_stages=2.

Fix (two-part, E2E-verified)

  1. libentry.py bench(): any RuntimeError from _bench is treated as a non-candidate (inf) so tuning survives backend compiler failures on any config. This is the general robustness fix — the failure mode is 'backend raises non-TritonError on an untileable config'.
  2. _cambricon/tune_configs.yaml index block: drop BLOCK_SIZE1=4096. With the default num_stages=2, a 4096-wide tile always exceeds NRAM (standalone-tested: OutOfResources, can never win), and BLOCK_SIZE0=4 x 4096 is the exact config that trips the compiler bug.

Verified on MLU590: with the previous blacklist removed, the request that used to crash now returns correct output, the engine stays alive across repeated requests, and no errors appear in the log.

Note

The underlying AutoTileForTritonPass expand_shape failure is a vendor (cambricon triton-MLU) compiler bug; this change makes flag_gems resilient to it. If the vendor fixes it, BLOCK_SIZE1=4096 can be re-added.

closes: #5509

This PR was written in part with the assistance of generative AI.

…eable expand_shape

The MLU backend's AutoTileForTritonPass raises a plain RuntimeError ('PassManager::run failed') on the tensor.expand_shape generated for BLOCK_SIZE0=4 x BLOCK_SIZE1=4096. Since RuntimeError is outside triton's autotuner catch list (OutOfResources / CompileTimeAssertionFailure / PTXASError), the exception propagated out of the tuner and crashed the whole process (EngineCore dead in vLLM).

Two-part fix, E2E-verified on MLU590 with flag_gems 5.3.4 + vLLM 0.20.2:

1) libentry bench(): any RuntimeError from _bench is treated as a non-candidate (inf) so tuning survives backend compiler failures on any config.

2) _cambricon index tune config: drop BLOCK_SIZE1=4096. With default num_stages=2 a 4096-wide tile exceeds NRAM (always OutOfResources) and BLOCK_SIZE0=4 x 4096 is the exact config that trips the compiler bug.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The index operator fails on Cambricon under certain condition

1 participant