[Bug]: -a 107-real is silently folded to 100, no SM107 code is generated

System Info

• CPU architecture: x86_64
• GPU: not required (compile-only)
• TensorRT-LLM: main, commit 4476ee3eacc1639c28f7e3e845b67ec246f2e482
• CUDA: 13.4, nvcc V13.4.59, gcc 13.3.0, Ubuntu 24.04

Description

-a 107-real is accepted and reaches CMakeCache.txt intact, but no SM107 code is ever
generated. The resulting libtensorrt_llm.so contains none:

720  sm_90a
110  sm_100
 36  sm_89 / sm_86 / sm_80 / sm_120a / sm_100a
  0  sm_107

No warning or error is emitted.

Cause

cpp/cmake/modules/cuda_configuration.cmake normalizes requested architectures against

set(ARCHITECTURES_COMPATIBILITY_BASE 80 86 90 100 120)
set(ARCHITECTURES_NO_COMPATIBILITY 87 101)

An architecture in neither list is folded to the largest base with the same major
version. 107 is in neither, and 107 / 10 == 100 / 10, so it becomes 100. Extracting
that block and running it standalone:

90  -> unchanged
100 -> unchanged
103 -> folded to 100
107 -> folded to 100

Across the whole build tree this leaves compute_90a ×147, compute_100f ×145,
compute_103a ×2, and zero files carrying 107.

This looks like an oversight rather than a decision. 9f926654
("[None][infra] Recognize SM107 (Rubin) in build config and arch detection", 2026-08-10)
added 107 to two lists:

• the default architecture list, under CUDA_COMPILER_VERSION >= 13.4
• ARCHITECTURES_WITH_KERNELS

but left ARCHITECTURES_COMPATIBILITY_BASE untouched, so the normalization step still
folds 107 away.

Verification

Adding 107 to that one list:

-  set(ARCHITECTURES_COMPATIBILITY_BASE 80 86 90 100 120)
+  set(ARCHITECTURES_COMPATIBILITY_BASE 80 86 90 100 107 120)

and re-running configure with -DCMAKE_CUDA_ARCHITECTURES="90-real;100-real;103-real;107-real":

	before	after
compute_90a	147	147
compute_100f	145	145
compute_103a	2	2
compute_107f	0	133

Compiling one of the affected targets by hand
(tensorrt_llm/common/cudaFp8Utils.cu, with the flags CMake generated for it):

--generate-code=arch=compute_90a,code=[sm_90a]
--generate-code=arch=compute_100f,code=[sm_100f]
--generate-code=arch=compute_107f,code=[sm_107f]

rc=0
cuobjdump --list-elf:  sm_90a  sm_100  sm_107

So the sources do compile for SM107; only the normalization step was removing it.

What I am unsure about

I do not know whether folding 107 into 100 is currently intentional because Rubin-specific
kernel sources are not ready. generate_kernels.py contains no occurrence of 107 and
treats it as SM100 family via range(100, 110), while 805 precompiled sm107a cubins
ship in trtllmGenKernels. If the intent is "build SM100 code and run it on Rubin", then
this is working as designed and the only issue is that -a 107-real silently does
nothing. If SM107 is meant to get its own code, the one-line change above appears to be
what is missing.

Happy to open a PR for the one-liner if you confirm which of the two it is.

Start in cpp/cmake/modules/cuda_configuration.cmake and inspect the architecture normalization against ARCHITECTURES_COMPATIBILITY_BASE; compare with generate_kernels.py if the intended SM107 behavior is unclear. Re-run configure with -DCMAKE_CUDA_ARCHITECTURES="90-real;100-real;103-real;107-real" and verify that SM107 is not folded away and compute_107f code is generated.