[NVFP4 MoE/Deepseek V4] Marlin: wire SwiGLU clamp + allow it for clamped models on non-Blackwell

[mikekg]

Purpose

Address #45859.

NVFP4 MoE models that declare a SwiGLU clamp (config.swiglu_limit, e.g. DeepSeek-V4) cannot be served on any non-Blackwell GPU (SM80/SM89/SM90). select_nvfp4_moe_backend() raises:

NotImplementedError: No NvFp4 MoE backend supports the deployment configuration.

When swiglu_limit is set, the selector restricts candidates to NVFP4_BACKENDS_WITH_CLAMP, which previously contained only FLASHINFER_TRTLLM (Blackwell/SM100-only). On SM80/89/90 that leaves no candidate. The Marlin NVFP4 MoE backend runs on those architectures and its kernel already applies the SwiGLU clamp (swiglu_limit_func), but it was excluded from the clamp-capable set and was never handed the clamp value.

This PR wires the clamp through to Marlin and allows it for clamped models on non-Blackwell:

1. nvfp4_w4a16_moe_quant_config() accepts gemm1_clamp_limit and forwards it to FusedMoEQuantConfig.make().
2. The MARLIN branch of make_nvfp4_moe_quant_config() passes gemm1_clamp_limit=swiglu_limit.
3. MARLIN is added to NVFP4_BACKENDS_WITH_CLAMP.

All three are required together. Without (1)+(2) the clamp would arrive as None and Marlin would silently skip it, producing unclamped (numerically incorrect) output — so adding MARLIN to the set alone would be unsafe. With all three, MarlinExperts receives gemm1_clamp_limit and the kernel applies swiglu_limit_func (identical math to SiluAndMulWithClamp), reproducing the intended clamped SwiGLU. Unclamped models (swiglu_limit is None) are unaffected — the filter is skipped and Marlin is selected as before.

Test Plan

• Serve an NVFP4 MoE checkpoint that sets config.swiglu_limit (DeepSeek-V4-Flash) on a non-Blackwell GPU (SM90 / H100) at TP=4 and TP=8.
• Confirm the model now selects the Marlin NVFP4 MoE backend instead of raising NotImplementedError: No NvFp4 MoE backend ....
• Issue a /v1/chat/completions request and verify a correct response.

Sample H100 invocation:

  vllm serve nvidia/DeepSeek-V4-Flash-NVFP4 \
    --tokenizer nvidia/DeepSeek-V4-Flash-NVFP4 \
    --served-model-name dsv4flash-nvfp4-sanity \
    --tensor-parallel-size 4 \
    --kv-cache-dtype fp8 \
    --trust-remote-code \
    --max-model-len 16384 \
    --max-num-batched-tokens 2560 \
    --max-num-seqs 1 \
    --gpu-memory-utilization 0.85 \
    --port 8652 \
    --tokenizer-mode deepseek_v4 \
    --reasoning-parser deepseek_v4 \
    --dtype auto

Test Result

• Before: serving the clamped NVFP4 MoE model on non-Blackwell fails at load with No NvFp4 MoE backend supports the deployment configuration.
• After: the model loads and serves on H100 (SM90) at TP=4 and TP=8; /v1/chat/completions returns 200 OK with a correct answer (e.g. "What is the capital of Japan?" → "Tokyo").

---

This change is self-contained (only fused_moe/config.py and fused_moe/oracle/nvfp4.py). Serving DeepSeek-V4 end-to-end additionally requires, separately from this MoE-backend fix: sharing tied weights for quantized embeddings or model that use tied embeddings, and an fp8 KV-cache path for the model's MLA attention. (Available on Hopper but not Ampere today)

[mikekg]

Thanks @mgoin @pavanimajety — addressed:

• Dropped the unit test entirely (per @mgoin). The PR is now just the 4-line
  wiring — gemm1_clamp_limit plumbing in config.py and adding MARLIN to
  NVFP4_BACKENDS_WITH_CLAMP in oracle/nvfp4.py. That also moots the nvfp4_utils
  note (@pavanimajety) since there's no quantizer in the diff anymore.
• Removed the explanatory comment in oracle/nvfp4.py.
• Rebased on main.

For the record, I validated the clamp wiring out-of-tree rather than as a
committed test: the Marlin clamp path (fused_marlin_moe(..., clamp_limit=L) →
in-kernel swiglu_limit_func, identical math to SiluAndMulWithClamp(L, alpha=1,
beta=0), matching DeepSeek-V4-Flash Expert.forward) was cross-checked at dsv4
operating points (k=4096, n=2048, topk=6; clamp ∈ {5,7,10,15}; weight_scale_2
∈ {2⁻¹³…2⁻⁹}) against a torch SiluAndMulWithClamp reference and the
FlashInfer TRT-LLM NVFP4 kernel — Marlin matched the torch reference to rel-L2
≈ 0.003–0.007 on A100/H100/B200, and ≈ 0.004 vs real dsv4 expert weights from
the checkpoint. The e2e H100 serving result is in the description.

[pavanimajety]

thanks, lgtm now.

[mgoin]

Thanks, great