Gemma-4 MoE: `EnsureGemma4Fp8NativeOnDevice` has no arm-existence guard, so #1126 would still throw on the DEFAULT expert arm

[localai-bot]

EnsureGemma4Fp8ExpertOnDevice now refuses the device upload before it happens where vt::MatmulBTAlphaBeta has no arm (#1205, landed by #1200): src/vllm/model_executor/models/gemma4_moe.cpp:571, inside :548-608. Its FP8-native twin, EnsureGemma4Fp8NativeOnDevice (:611), carries the same shape and has no such guard.

The twin is the DEFAULT arm, not an opt-in. VT_GEMMA4_FP8_NATIVE is read at :969-974 and returns true when the variable is unset, so on a per-expert FP8 Gemma-4 checkpoint the expert loop takes EnsureGemma4Fp8NativeOnDevice at :1359 and :1484 before it ever reaches the BF16 arm the guard covers.

What it would wake. A true from the twin routes into ExpertGeGLUFp8Native (:95-130), which needs three ops that only ROCm implements:

• vt::ExpertGeGLUFp8TopKM1 (:105) — returns false off ROCm, so this one degrades rather than throws.
• vt::DequantFp8ChannelBf16 (:117, :119) — refuses: src/vt/fused_ops.cpp:194.
• vt::MatmulBTAlphaBeta (:128) — refuses: src/vt/fused_ops.cpp:152.

So the T>1 path throws at the first DequantFp8ChannelBf16, and the T==1 path falls through the fused kernel and throws there too. As with #1205 the throw lands outside the upload's own try/catch, so it leaves the decode step instead of degrading to the host fallback.

Latent for exactly the same reason and for exactly as long. The twin's MakeRoom also needs vt::Backend::DeviceMemoryInfo, which only ROCm overrides (src/vt/rocm/rocm_backend.hip:338-345), so nothing admits today. #1126 step 1 is the change that adds CudaBackend::DeviceMemoryInfo, and it wakes this arm before it wakes the guarded one.

Why it was not fixed in the same flow. The BF16 arm's guard keys on one predicate, vt::HasMatmulBTAlphaBeta, which is the same condition its dispatch uses. The twin depends on three different ops, so an honest guard needs a predicate per op rather than a reused one, and keying it on HasMatmulBTAlphaBeta alone would be a guard that names the wrong arm. That is a distinct change with its own gate, and #1200 was already scoped to the BF16 chain #1205 traces. Recording it here keeps the default arm from being discovered by whoever lands #1126.

Owned by ENG-EXPERT-STREAM and listed under ## Owed in expert-streaming.md.