[Bug]: Dense Qwen3.8-27B NVFP4 fails to start on Hopper with default settings (no Marlin default for dense Qwen3.5 classes) #20969

System Info

1x H200 (SM90), x86_64, nvcr.io/nvidia/tensorrt-llm/release:1.4.0rc1.dev202610201007, PyTorch backend, TP 1.
Checkpoint RadixArk/Qwen3.8-27B-NVFP4 (revision 319f741c). Source lines below are from main b7d6e624d1.

Who can help?

Information

• The official example scripts
• My own modified scripts

Tasks

• An officially supported task in the examples folder (such as GLUE/SQuAD, ...)
• My own task or dataset (give details below)

Reproduction

cat > cfg.yaml <<'EOF'
kv_cache_config:
  free_gpu_memory_fraction: 0.80
  host_cache_size: 0  # works around a separate host-memory startup failure on the test host
EOF
trtllm-serve serve RadixArk/Qwen3.8-27B-NVFP4 --backend pytorch --tp_size 1 \
  --max_batch_size 32 --max_num_tokens 8192 --max_seq_len 4096 --config cfg.yaml

Expected behavior

The server starts and runs the NVFP4 linear layers with Marlin, as the Qwen3.5 MoE classes already do by default on SM89-99 (added in #17293).

actual behavior

Weights load, then startup fails in the memory-profiling warmup:

RuntimeError: [TensorRT LLM Error][CutlassFp4GemmRunner][GEMM Dispatch] Arch unsupported for CUTLASS FP4 GEMM

Adding nvfp4_gemm_config: {allowed_backends: [marlin]} to cfg.yaml fixes it: the server starts, and GSM8K on the first 100 test questions scores 0.92 (5-shot chat, thinking off, greedy, scored by a small client script).

additional notes

_get_qwen35_moe_model_defaults (tensorrt_llm/_torch/models/modeling_qwen3_5.py:64-83) selects Marlin on SM89-99 for NVFP4 / MIXED_PRECISION checkpoints, but only the MoE classes call it. The dense Qwen3_5ForCausalLM (:703-717) and _Qwen3_5VLModel.get_model_defaults (:747-755, used by Qwen3_5VLModel, which this checkpoint resolves to) return only the Qwen3-Next defaults, so allowed_backends keeps the global default, which has no marlin.

Suggestion: give the dense classes the same linear default, without the MoE backend.

nvidia/Qwen3.8-27B-NVFP4 (MIXED_PRECISION) and Inferact/Qwen3.8-27B-NVFP4 (NVFP4) have the same architecture, so they should get the same defaults; only their config files were checked, they were not run.

Related: #12591 (open) proposes an early error that names marlin; it does not change the default. A separate bug in the Marlin MoE path (SiLU applied to the up projection) is in #20965.

Before submitting a new issue...

• Make sure you already searched for relevant issues, and checked the documentation and examples for answers to
  frequently asked questions.