[RFC] Selective debug windows in dual-profile builders - extend the sana_wm/gemma pattern to generic families

Draft — issue/RFC para NVIDIA/TensorRT-Model-Connect

Summary

debug_layer_outputs=True currently expels generic families from the dual-profile
builder: the routing comment in e.g. python/tensorrt_model_connect/families/qwen/standard_decoder_builder.py
(~L118–135) lists it among the paths the dual-profile builder "does not yet cover", so
instrumented builds fall back to the legacy single-profile graph (and are excluded from
the qualified FP8 route in families/qwen/plugin.py).

Meanwhile, families/sana_wm/components/gemma/dual_profile_decoder_builder.py already
implements debug windows inside the dual-profile graph, selectively per layer
(debug_layer = debug_layer_outputs and layer_idx == 0), emitting ~16 named outputs for
that layer plus debug_hidden_{i} per layer, and the C++ runtime consumes them
(src/runtime/models/sana_wm/pipeline.cpp requires debug_embed/debug_hidden_* from
the Gemma text-encoder plan).

Proposal

Port the sana_wm/gemma pattern to the generic dual-profile builders (llama, qwen, bloom,
qwen_moe, …), with layer selectivity as part of the API, e.g.
debug_layer_outputs: bool | Sequence[int], so a build can open a handful of windows
without leaving the fast graph or paying for all layers.

Motivation

Observability at production speed: monitoring, drift detection, quantization debugging,
and interpretability signals read from a deployed engine without runtime interception.
The memory cost of a hidden-state window is small (S×d per layer); selectivity keeps the
marginal cost bounded and user-controlled.

We are currently benchmarking the throughput cost of N windows on consumer RTX hardware
(TensorRT-RTX backend) and can attach numbers to a follow-up PR.

Questions for maintainers

1. Would a PR in this direction be welcome, or is dual-profile debug coverage already
   planned internally?
2. Preferred API shape: extend the existing boolean, or a separate debug_layers=[...]?
3. Should selected debug outputs flow into the bundle io_map so the C++ runtime can
   address them generically (as sana_wm does ad hoc)?

Start with the routing comment in python/tensorrt_model_connect/families/qwen/standard_decoder_builder.py and compare it with families/sana_wm/components/gemma/dual_profile_decoder_builder.py. Trace the related output handling in families/qwen/plugin.py and src/runtime/models/sana_wm/pipeline.cpp, including the named debug outputs and io_map question. Done means an agreed selective API and generic-family scope that keeps selected debug windows in the dual-profile graph and makes their outputs addressable.