[Bug] Qwen-3.5 on B300 (sm_103) crashes in flash-attn-4 cute kernel — assertion at flash_fwd_sm100.py:162 (fix exists in Dao-AILab/flash-attention#2572; sglang needs to bump flash-attn-4)

[functionstackx]

Human

TLDR: in v0.5.12 on b300 (sm103), hitting

assert self.arch >= Arch.sm_100 and self.arch <= Arch.sm_110f, "Only SM 10.x and 11.x are supported"
AssertionError: Only SM 10.x and 11.x are supported

do to this line in flash-attn where sm103 doesnt fit within these 2 conditions assert self.arch >= Arch.sm_100 and self.arch <= Arch.sm_110f. there exists an patch for it in here Dao-AILab/flash-attention#2572

AI Slop below

Summary

On NVIDIA B300 (Blackwell Ultra, sm_103), lmsysorg/sglang:v0.5.12-cu130 fails to serve any Qwen-3.5-VL recipe (Qwen/Qwen3.5-397B-A17B) because the bundled flash-attn-4 cute kernel's architecture check in flash_attn/cute/flash_fwd_sm100.py:162 rejects sm_103. All TP ranks crash on the first warmup forward pass through the vision encoder; warmup eventually times out (600s) and the server is killed.

The root-cause fix already exists upstream, in Dao-AILab/flash-attention#2572 by @ocss884 — sglang's pinned flash-attn-4>=4.0.0b9 needs to be bumped to whatever Tri Dao tags after that PR merges.

Environment

sglang image	lmsysorg/sglang:v0.5.12-cu130
Hardware	NVIDIA B300 (Blackwell Ultra, sm_103 — compute capability 10.3), 4× / 8× GPU per node
Model	Qwen/Qwen3.5-397B-A17B (Qwen-3.5-VL — vision encoder is the failing path)
Tensor parallelism	TP=4 and TP=8 (identical failure on both)
Spec decoding	Both off and EAGLE-MTP variants hit the same assertion (the vision encoder runs regardless of MTP)
flash-attn version	flash-attn-4>=4.0.0b9 per pyproject.toml
Known-good image	lmsysorg/sglang:v0.5.11-cu130 (does not bundle the buggy assertion)

Note: sm_120 is consumer Blackwell (RTX 50 series / GB20x dies), not B300. B300 is sm_103. Don't propagate the wrong arch ID.

Exception

[TP0..3] Scheduler hit an exception: Traceback (most recent call last):
  File "/sgl-workspace/sglang/python/sglang/srt/managers/scheduler.py", line 4041, in run_scheduler_process
  ...
  File "/sgl-workspace/sglang/python/sglang/srt/models/qwen3_vl.py", line 1210, in get_image_feature
    return self.visual(pixel_values, grid_thw=image_grid_thw)
  ...
  File "/sgl-workspace/sglang/python/sglang/srt/models/qwen3_vl.py", line 838, in forward
    x = blk(
  File "/sgl-workspace/sglang/python/sglang/srt/models/qwen3_vl.py", line 231, in forward
    attn = self.attn(
  File "/sgl-workspace/sglang/python/sglang/srt/layers/attention/vision.py", line 1173, in forward
    output = self.qkv_backend.forward(
  File "/sgl-workspace/sglang/python/sglang/srt/layers/attention/vision.py", line 491, in forward
    output = flash_attn_varlen_func(
  File "/sgl-workspace/sglang/python/sglang/jit_kernel/flash_attention.py", line 273, in flash_attn_varlen_func
    return fa4_flash_attn_varlen_func(
  File "/sgl-workspace/sglang/python/sglang/jit_kernel/flash_attention_v4.py", line 65, in flash_attn_varlen_func
    result = _flash_attn_varlen_func(
  File "/usr/local/lib/python3.12/dist-packages/flash_attn/cute/interface.py", line 2217, in flash_attn_varlen_func
    return FlashAttnVarlenFunc.apply(
  File "/usr/local/lib/python3.12/dist-packages/flash_attn/cute/interface.py", line 2039, in forward
    out, lse = _flash_attn_fwd(
  File "/usr/local/lib/python3.12/dist-packages/flash_attn/cute/interface.py", line 882, in _flash_attn_fwd
    fa_fwd = flash_fwd_obj_cls(
  File "/usr/local/lib/python3.12/dist-packages/flash_attn/cute/flash_fwd_sm100.py", line 162, in __init__
    assert self.arch >= Arch.sm_100 and self.arch <= Arch.sm_110f, "Only SM 10.x and 11.x are supported"
AssertionError: Only SM 10.x and 11.x are supported

Why a nominally in-range arch trips the assertion

The check is self.arch >= Arch.sm_100 and self.arch <= Arch.sm_110f. B300 is sm_103, which is numerically inside [sm_100, sm_110f], so naively the assertion should pass.

Dao-AILab/flash-attention#2572 explains why it doesn't (quoting):

When using B300 (sm103) with non-cu13 cutedsl, current assertion introduced in 463623e will narrow the effective supported range as the arch class in cutedsl will do:

• For non-cu13 cutedsl: map Arch.sm_110 and Arch.sm_101 to SM101
• For cu13 cutedsl: map Arch.sm_101 and Arch.sm_110 to SM110

As a result when using non-cu13 cutedsl, the current the effective range check will be sm100 <= ... <= sm101 which unintentionally excludes SM103.

So the comparison operators on the enum don't behave like raw integers — depending on the bundled cutedsl, sm_110f resolves to a value that's less than sm_103, collapsing the range.

The fix in PR #2572 is a one-line change:

-        assert self.arch >= Arch.sm_100 and self.arch <= Arch.sm_110f, "Only SM 10.x and 11.x are supported"
+        assert self.arch.is_family_of(Arch.sm_100f) or self.arch.is_family_of(Arch.sm_110f), \
+            "Only SM 10.x and 11.x are supported"

is_family_of() correctly matches the SM 10.x / 11.x family regardless of cutedsl version, so sm_103 / sm_103a (and sm_100, sm_100f, sm_101, sm_110, sm_110f) all pass.

What sglang needs to do

python/pyproject.toml pins flash-attn-4>=4.0.0b9. Once @tridao reviews & merges Dao-AILab/flash-attention#2572 and tags a new flash-attn-4 release, the sglang Dockerfiles (and pyproject) should bump that floor to the fixed release so B300 stops crashing on Qwen-3.5-VL (and any other vision-encoder path that flows through flash_attn_v4).

Workarounds (until the bump lands)

Workaround	Notes
Pin recipe to lmsysorg/sglang:v0.5.11-cu130	✅ works — v0.5.11 didn't bundle the broken assertion
Disable flash-attn-4 in the vision encoder path	Not investigated; might be possible via --mm-attention-backend if a non-FA4 backend is available for Qwen-3.5-VL
Run on B100/B200 (sm_100) instead of B300	Not affected because the int comparison luckily holds for sm_100 itself

Sources

• Failing CI run (every TP-0/1/2/3 traceback identical): https://github.com/SemiAnalysisAI/InferenceX/actions/runs/25980018232
• Reproducer recipe (script): https://github.com/SemiAnalysisAI/InferenceX/blob/main/benchmarks/single_node/qwen3.5_bf16_b300.sh
• Master config: qwen3.5-bf16-b300-sglang / qwen3.5-bf16-b300-sglang-mtp in https://github.com/SemiAnalysisAI/InferenceX/blob/main/.github/configs/nvidia-master.yaml
• Tracking PR (image bump that exposed the regression): Update qwen3.5-bf16-b300-sglang and -mtp SGLang image to v0.5.12-cu130 SemiAnalysisAI/InferenceX#1422
• Sibling B300 regression in the same family (trtllm GEMM dispatcher selects sm100f kernel for sm_103): [Bug] GLM-5-NVFP4 + EAGLE on B300 (sm_103): trtllm_batched_gemm_runner.cu:276 dispatches sm100f kernel — crashes at bs=128 draft graph capture (v0.5.12-cu130; v0.5.11 works) #25563
• Upstream flash-attention fix: Dao-AILab/flash-attention#2572

Happy to attach a full server.log artifact if useful.

[mmangkad]

I don't think the FA PR is technically needed here, even upstream. If SM103 is hitting this assertion, that basically means we are on the non-cu13 CuTeDSL aliasing path. SGLang already defaults to CUDA 13, so I think the CuTeDSL dependency should match that now by using nvidia-cutlass-dsl[cu13].

The confusing bit is from the CuTeDSL 4.5 change. The Arch enum now aliases sm_101* and sm_110* differently depending on CUDA version. On the non-cu13 path, sm_110f can effectively behave like sm_101f, so the FA4 check:

self.arch >= Arch.sm_100 and self.arch <= Arch.sm_110f

can accidentally reject sm_103. So the fix is just to install the [cu13] extra for nvidia-cutlass-dsl. FI does the same thing for its own cu13 extra. We should add [cu13] to nvidia-cutlass-dsl dependency for the same reason.

[functionstackx]

AI GEnerated /loop Workaround confirmed working — full B300 sweep landed green

Just merged SemiAnalysisAI/InferenceX#1422 (qwen3.5-bf16-b300-sglang v0.5.11-cu130 → v0.5.12-cu130 with --mm-attention-backend triton_attn added to qwen3.5_bf16_b300{,_mtp}.sh). All 58+ matrix jobs across {off, mtp} × {tp=4/ep=1, tp=8/ep=1} × {1k1k, 8k1k} × conc-4..256 ran cleanly on B300 — no flash-attn assertion, no vision-encoder crash, sweep latency comparable to the pre-bump baseline.

So the short-term escape hatch is solid: keep --attention-backend trtllm_mha for the text decoder, swap only the vision-encoder path to triton_attn via --mm-attention-backend.

That said, would still really appreciate the long-term fix — pinning nvidia-cutlass-dsl[cu13] in sglang's deps per @mmangkad's comment (or upstream Dao-AILab/flash-attention#2572 landing) is what we actually want, since triton_attn on the VL path costs us some prefill throughput vs. the cute kernel and is a maintenance burden to remember on every B300 Qwen-3.5-VL recipe.

Same workaround has also been applied to the sibling B300 PRs (#1451 qwen3.5-fp8, #1475 qwen3.5-fp4) — they're currently in their sweep cycles and we'll merge as they land green.

Leaving this issue open until the upstream durable fix ships. Happy to test a pre-release sglang image if you want a B300 environment to validate against.

[trevor-m]

Thanks @mmangkad for the PR, I just left a review