Int4GroupwiseGemmPluginV2 fails silently when ENABLE_CUTE_DSL omits int4_fp16_gemm: "Failed to enqueue status -1" with no diagnostic

Component: Int4GroupwiseGemmPluginV2 / ENABLE_CUTE_DSL build configuration
Version: v0.10.1 (e8b2952), built from source
Platform: DGX B300 (SM103), CUDA 13.0, TensorRT 10.13.2 — but this is platform-independent
Impact: an INT4 model built with the default ENABLE_CUTE_DSL produces an engine that
builds, loads and then fails at the first token, with an error that points at the kernel
rather than at the build configuration.

Summary

ENABLE_CUTE_DSL defaults to fmha, which omits int4_fp16_gemm. An INT4 model built
that way compiles Int4GroupwiseGemmPluginV2 with CUTE_DSL_INT4_FP16_GEMM_ENABLED
undefined, so enqueue() returns -1 from its #else branch with no diagnostic.

Observed

[E] Error Code: 2: int4_groupwise_gemm_v2_4: Failed to enqueue status -1
[E] IExecutionContext::enqueueV3: Error Code 1: Myelin ([immediate.cpp:exec:156]
    Custom layer callback with tactic id '..._706246428453888_0' failed.
    In executeMyelinGraph at runtime/myelin/runner.cpp:778)
[E] [inline single-rank] handleRequest failed: Failed to execute base model for prefill step.

Why this is expensive to diagnose

Nothing before inference fails, so there is no earlier signal to work from:

• the CuTe DSL archive builds (both groups present in metadata.json if you built them)
• the plugin compiles, links and registers — the registry reports its creators
• the ONNX graph parses with 0 errors
• the engine builds and serialises
• the runtime loads it, allocates tensors and creates an execution context

The first and only symptom is at generation, and it names a tactic id and a Myelin
callback, which reads as a kernel fault. I checked the archive metadata, the weights
(byte-identical against a known-good export), the plugin attributes (gemm_n, gemm_k,
group_size), the graph shape and the runtime config before instrumenting
cuteDslInt4GemmLoadModules() — and getting no output at all from it was what finally
showed the block had been compiled out rather than failing inside.

Reproduction

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release   # ENABLE_CUTE_DSL defaults to "fmha"
cmake --build build --target NvInfer_edgellm_plugin
# build an engine from any W4A16 export, then run one request

Fix by reconfiguring with -DENABLE_CUTE_DSL="fmha;int4_fp16_gemm".

Suggested fix

Two options, smallest first:

1. Log once from the disabled branch, naming the flag. Proposed in
   #209 — 13 lines, no behaviour
   change, no new includes.
2. Warn at configure time. cmake knows both whether the INT4 plugin is being built and
   whether int4_fp16_gemm is in ENABLE_CUTE_DSL, so this could be caught before a
   single kernel compiles. Better, but it touches the build system rather than one plugin.

A documentation note would also help on its own: the direct-builder and quantisation docs
do not mention that an INT4 model needs a non-default ENABLE_CUTE_DSL.

Found while bringing up an INT4-AWQ Cosmos3-Edge checkpoint on a DGX B300 during the
NVIDIA / OpenHackathons / Oracle Open Models Codefest 2026, for an offline-first
search-and-rescue robotics entry (Team UBR Stack). The production target is a Jetson Orin
Nano; the B300 is a bench machine used for evaluation.

Review PR #209 and the disabled branch reached by cuteDslInt4GemmLoadModules() in the Int4GroupwiseGemmPluginV2 path. Reproduce with the default ENABLE_CUTE_DSL setting, build NvInfer_edgellm_plugin, and run an INT4 request; done means the missing int4_fp16_gemm configuration produces a diagnostic instead of an unexplained status -1.