[milesial]

Nemotron 3.5 Lightning NVFP4 runs its shared-expert projections as ModelOpt W4A16_NVFP4: 4-bit NVFP4 weights with BF16 activations. The performance model already asks for these GEMMs in the w4a16_nvfp4 mode. Before this PR, the vLLM GEMM collector did not measure that mode. Strict SILICON queries for Lightning failed with "GEMM perf data missing for quant 'w4a16_nvfp4'". After this PR, the collector measures the mode through vLLM's own ModelOpt dispatcher. The PR also adds measured rows for B200 and GB200. On these two GPUs, the Lightning shared-expert GEMM lookups at vLLM 0.30.0 now return measured data.

What changed

• collector/vllm/collect_gemm.py: a new w4a16_nvfp4 lane. It builds the layer with ModelOptMixedPrecisionConfig, as a Lightning MIXED_PRECISION checkpoint does, so vLLM selects the kernel. kernel_source records the kernel that vLLM ran. If vLLM builds a layer that quantizes activations, the run fails.
• Synthetic weights use the checkpoint layout that the ModelOpt loader fills. On SM100 and newer GPUs, vLLM's scaled_fp4_quant makes them. On older GPUs, vLLM's PyTorch reference quantizer makes them, because scaled_fp4_quant needs an SM100 kernel.
• collector/cases/models/NemotronHForCausalLM_cases.yaml: the six Lightning shared-expert (n, k) sites for TP1, TP4 and TP8.
• collector/cases/capabilities.yaml: w4a16_nvfp4: 80 (BF16 activations).
• collector/kernel_source_backends.yaml and collector/op_backend_facts.yaml: entries for the new kernel labels and data slices.
• vLLM 0.30.0 is admitted for the GEMM collector, because it is the current vLLM query version.
• Synthetic GEMM inputs and weights use a fixed seed.

Evidence

Each cell ran the unchanged collect.py entry point with 444 exact case filters (6 sites x 74 token counts). Each cell kept 444 cases and recorded 0 failures. All rows have the collector commit 9d81c45, collector hash sha256:3e50fb87, and case plan hash sha256:0da6da79.

System	vLLM	Image (architecture digest)	Kernel that vLLM selected	In this PR
b200_sxm	0.24.0	f9de5cd9	MarlinNvFp4LinearKernel	No (see limits)
gb200	0.24.0	32445b36	MarlinNvFp4LinearKernel	No (see limits)
b200_sxm	0.30.0	5f5e5352	FlashInferCuteDslNvFp4W4A16LinearKernel	Yes, merged into the shipped table
gb200	0.30.0	4864d466	FlashInferCuteDslNvFp4W4A16LinearKernel	Yes, merged into the shipped table
b200_sxm	0.31.0	a4a4c043	FlashInferCuteDslNvFp4W4A16LinearKernel	Yes, new w4a16_nvfp4-only table
gb200	0.31.0	3f7dd5b7	FlashInferCuteDslNvFp4W4A16LinearKernel	No (see limits)

• In every cell, the kernel received BF16 input, and the layer kept no activation scale.
• The two merged 0.30.0 tables went from 148962 to 149406 rows. Every shipped row and every earlier collection event is unchanged. collect.py appended one event. The text columns are now stored as large_string, and their values are unchanged.
• Strict SILICON queries (shared layer off) of the two TP1 keys at the eight token counts that the gate uses return the stored rows exactly: 16 of 16 on b200_sxm 0.30.0, gb200 0.30.0 and b200_sxm 0.31.0.
• check_collector_data.py and backend_facts.py --check pass.
• A short validation on an H100 (SM90) checked the weight preparation for GPUs older than SM100, on vLLM 0.24.0 and 0.30.0. The reference quantizer made a uint8 weight of shape (n, k/2) and float8 scales of shape (n, k/16). vLLM selected MarlinNvFp4LinearKernel at both versions, and both cases ran with 0 failures. These rows are evidence only and are not in this PR.

Prediction Regression Gate, run locally on vLLM 0.30.0 for b200_sxm, b300_sxm, gb200, gb300 and rtx_pro_6000_server, with #617's corrected candidate plus this PR:

• The 45 blocking rows stay blocking. On b200_sxm and gb200, the first failure moves from the dense GEMM to the MoE w4a16_nvfp4 lookup (TP1, EP8). On the other three systems, the GEMM lookup still fails.
• No other gate row changes.

Known limits

• vLLM 0.24.0 rows are measured but not in this PR. The 0.24.0 GEMM tables have a legacy provenance sidecar, and the collector refuses to add a fresh collection to a legacy sidecar.
• GB200 vLLM 0.31.0 rows are measured but not in this PR. The shipped table stores text as large_string, and the collector merge replaces such a table instead of adding to it. A separate fix is needed first.
• B300, GB300 and RTX PRO 6000 have the same Lightning gap on vLLM 0.30.0. This PR does not collect them.
• After feat: price checkpoint precision per layer for Nemotron-H, Qwen3.5 and Gemma 4, and collect vLLM NVFP4 MoE #617 keeps Lightning experts on w4a16_nvfp4, the MoE lookups also need measured W4A16 MoE rows. This PR does not add them.
• The tests for the pre-SM100 weight preparation need torch. The default development environment does not install torch, so CI skips them.
• The evidence policy flags many collector families, because the model case YAML is shared by every collector. Only the GEMM case plans change: +444 cases (+126 for vLLM XPU).

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}