TensorRT-LLM is not the runtime for rocket

Rejected on model fit and kernel ownership. Superseded within the hour: two of the four objections were precedent, not evidence.

Important

Superseded by rejected as a runtime, not as a kernel source. Objections 1, 3 and 4 do not hold. Left unedited as history.

Question. Build rocket on TensorRT-LLM instead of our own compiler? It is an ahead-of-time graph compiler with a thin runtime, which is the shape the doctrine describes.

setup
node	head
target	GB10, compute capability 12.1 (sm_121)
method	packaging and architecture analysis, nothing installed

Packaging first, because an earlier local note called it unavailable on aarch64.

source	result
PyPI tensorrt-llm	1.2.1, sdist only, 0 wheels across all releases
NVIDIA index	93 aarch64 wheels, latest 1.3.0rc9-cp312-cp312-linux_aarch64

That objection is dead. Point pip at the NVIDIA index. What decided it instead:

1. GLM-5.3-Flash is not a stock model definition. KDA, sparse MLA with a top-2048 DSA indexer, 288-expert top-8 MoE, MTP head. Adopting it means plugins for every interesting layer.
2. Our differentiator lives inside its abstractions: the atomic (KV, KDA) entry in the state cache and compile-time expert placement sit in its KV manager and graph builder.
3. sm_121 coverage unproven. Published matrix names SM100/103/120; its FMHA runner refused this hardware once with “Unsupported architecture”.
4. Closed kernels leave no way to fix an sm_121 gap ourselves.

Verdict. Rejected as the runtime. Fit and cost, not a measured performance loss.

Reopen if.

• NVIDIA ships sm_121-tuned kernels with a hybrid linear-attention model definition
• our grouped expert GEMM lands far enough below achievable bandwidth that theirs beats it on sm_121