[yguanrong]

What this changes

The development sm_110 CUDA limits audit reads register, static shared-memory and launch-bound usage from compiled cubins. The five release SMs keep their original launch opt-in flags and pinned usage records. This does not add a product GPU target or change inference launches.

• Issue: Refs CUDA: qualify Jetson AGX Thor (sm_110) for native Qwen3.8-27B MLX 4-bit and DFlash2 #2319. Qwen3.8 serving, exactness, vision and performance remain for later PRs.

• Stacked on: main at ab4b2f05cebcf893af79bb7e85bc7e1c0bf92f60; one commit, 11bf72e9d3d6e74000afbbbcb0956d40b4ad5018.

• Review fixes: the 12 release-wide .opt_in = true additions are gone. Only the SM110 audit applies the loader-backed opt-in list, with each loader's current allowDynamicShared source line beside its launch. Controls are counted per target. The docs require norms.fatbin in DIR; the CHANGELOG uses the requested wording in the new Unreleased section.

• ATC 0.7.0 was retried in a temporary copy with a 600-second total and 120-second request deadline. check 2319 completed with no limitations and confirmed this contributor's claim. board and overlap no longer hit timeLimit, but both remain incomplete because of pullFilesLimit. The one automatically tested overlap conflict (glm: TF_GLM_KV_LIVE_HALF=1 keeps the live half of the KDA state alone in a kept prompt state #2181) also conflicts with current main in the same three files; other unknown overlaps are not claimed clean.

Checks on this head

• Zig 0.17.0 on the SM110 test host: zig build test-kernel-contract -j2 --summary all exit 0 on both current-head base and PR head, 217/217 tests; compile-cuda-tests exit 0 on both, 9/9 steps. GitHub's current-head fmt check passed.

• git diff --check upstream/main...HEAD exit 0. Release launch and pinned usage rows are unchanged; the registry diff changes comments only. python tools/pr_check.py --base upstream/main --pr 2395 exit 0, 6 changed files, 0 errors and 0 warnings.

• Lean checker on current-head base ab4b2f05c and head 11bf72e9d: 116 findings on each, 0 new. The raw checker exits 1 for inherited findings; the PR preflight's delta exits 0.

• A broader Windows test-cuda-host -j2 --summary all attempt on former head e8c9dd329 was stopped after Dory numerical differences, GLM snapshot output, golden-hash differences and DeviceLost; exit 1. It is not a passing receipt, and these failures have not been attributed to this PR or to main.

• GitHub CI on current head 11bf72e9d: all seven checks passed.

• Current-head SM110 device audit: On NVIDIA Thor SM110 with nvcc 13.0.88, the positive limits audit exited 0 with 904 PASS limits, 2 expected RED, and 0 MISSED. A negative test replacing only the control fatbin with a deliberately over-wide launch bound exited 1 with exactly 1 MISSED and FAIL kernel-contract-limits: 1 problems; this is the expected detection.

• Build caveat: The unmodified CUDA fatbin build fails in zig/kernels/cuda/contract_controls.cu because the included prefill_attention_rows.cuh refers to undeclared P256, IDS, and PN. The same failure was reproduced on the base. For the device audit only, identical declarations were added to temporary extracted source copies for both base and PR head: P256 = false, IDS = false, and PN = 0 in the control kernel. These supply the names required by the shared header while keeping those paths disabled. This compatibility patch is absent from this PR; the device result does not establish an unpatched source build.

• Release-five comparison: Both base and PR-head runners used the same five-release-SM fatbin directory. Both exited 1 with the same 13 stale Flash Next/Qwen3.5 records, 1,516 RECORD lines, 5,028 PASS limits, 10 expected RED, and no MISSED. Full logs were byte-identical (SHA256 57b6eff0c1358a643c188660ca6ad0f79129adf356152fda61906b1f0f823182). This establishes no PR-specific regression, but the release-five gate is not passing.

• Not run: checkpoint, drafter, vision or performance tests, because this PR cannot reach inference. Metal/HIP devices, release CUDA GPUs and product -Dgpu=sm_110 are not qualified by this development audit.

Historical device evidence (superseded by the rebase)

• On former head c0234ee6 and Thor SM 11.0 with nvcc 13.0.88, the SM110 limits audit exited 0 with 896 normal checks passing, 2 planted controls red, and 0 missed/failed; a test-only raised-bound fatbin exited 1 with exactly 1 SM110 control missed. The positive and negative log SHA256 values were 2c7238619aff033eaef70247951211e140ef672ec4b378a3fd241c7541d17ad0 and 2ae4e4c691497b4efdc2f0c7d89f04c292fb3f8b3b3cc5d9b44a06ae66d82e74.

• A mixed six-SM pre-kernel contract: refresh 226 stale nvcc 13.0 resource slots across 57 CUDA kernels, so the GB10 limits gate passes on main #2390 check on 73897f7d had 12 controls red and 0 missed; its test-only negative variant had 11 red and exactly 1 SM110 missed. Both still hit the then-inherited 226 stale release records.

• On former base cce0bdea and former head c0234ee6, the five release-SM runners read the same 144-fatbin directory. Both exited 1 with the same 13 stale records, 0 resource-limit failures, 10 red controls and 0 missed. Their 1508 RECORD lines shared SHA256 6418227d1b55f8e87d6608e87074ef41c7956eae714c37c857617bc53535b37f, and full logs were byte-identical (SHA256 bc629315301660565cbbdd2494d422611fe37da2263281712d572cb9659073bf). These are historical base-vs-head results, not a passing receipt for current main.

Receipt

n/a — this changes the development kernel-limits audit and metadata only; the inference loader, dispatcher, model and GPU kernels are unchanged.

Checklist

• Title, issue, one-change scope, base and head match the pushed commit.

• Release launch and usage rows are unchanged; SM110 opt-in handling remains in the audit runner.

• Current-head CI 7/7, 217/217 host contract tests, diff check, lean delta and PR preflight are recorded above.

• No private hosts, paths, credentials, model artifacts or AI attribution are included.

• Run current-head SM110 positive/negative audits and release-five base-vs-head comparison with the same temporary, test-only compatibility patch on both sides.

• Restore an unpatched CUDA fatbin build; classify the inherited 13 stale release records before claiming the release-five gate passed.

• Classify current-head CI: all seven checks passed.

• Obtain a complete ATC overlap result or otherwise resolve any reported overlap before landing.

[ashhart]

Thanks @yguanrong, this is a careful first step for sm_110, and the Thor run and the base-vs-head logs help a lot. The cubin path is narrow, and it changes nothing a release build runs. A few things before it can land:

1. Please keep the release records as they are. The 12 .opt_in = true additions (the qmmf 48 KiB tiles, qmmf shared down 32 stride, prompt16 FP8 and h3_attention) apply on all five release SMs. There they lift the ceiling from 48 KiB to 99 KiB (163 KiB on sm_80). Pass/fail is the same today, but the guard gets wider, and the RECORD hash can't show that because it covers usage only. Since only sm_110 adds the extra static bytes, could the sm_110 path carry that instead? For example, a short list in the runner of the launches whose loaders raise the limit, each with its allowDynamicShared file:line.
2. Count controls per target. In a set with both release and sm_110 images, red adds both, so a control that is red on sm_80 but missed on sm_110 still passes.
3. norms.fatbin: release runs now need it to pick a mode. Could the mode come from each image's own SMs, or could the docs say the file is required?
4. CHANGELOG: please end the line with "(CUDA: audit sm_110 cubins without widening release records #2395, part of CUDA: qualify Jetson AGX Thor (sm_110) for native Qwen3.8-27B MLX 4-bit and DFlash2 #2319). Thanks to @yguanrong." and drop "keeping … unchanged" unless item 1 makes it true.
5. After kernel contract: refresh 226 stale nvcc 13.0 resource slots across 57 CUDA kernels, so the GB10 limits gate passes on main #2390 lands: that PR refreshes the 226 stale nvcc 13.0 records your release-five run hit. Could you repeat the release-five kernel-contract-limits run on main plus this PR then, and post main's and the branch's exit codes and RECORD hashes? With those records fixed, both should pass.

[yguanrong]

Thanks for the precise review. I rebased #2395 onto main cce0bde after #2390 merged (601c9bf); the updated single commit is c0234ee.

1. The 12 release-wide opt-in additions are gone. Only the sm_110 limits audit applies the loader-backed list, with an allowDynamicShared source file and line beside each entry.
2. Controls are counted per target. A six-SM mixed set reported 12 RED and 0 MISSED. A test-only variant that raises only the sm_110 bound reported 11 RED and exactly 1 MISSED; the problem count rose from 226 to 227. On the current head, the standalone sm_110 audit passed 896 normal checks with 2 RED controls, while the negative variant exited 1 with one MISSED.
3. The contract guide now requires norms.fatbin in DIR.
4. The CHANGELOG line ends with the requested wording.

For item 5, I rebuilt all five release SMs on main cce0bde with nvcc 13.0.88 (298/298 build steps). Both the main and branch runners read the same fatbin directory. Both exited 1 with the same 13 record-stale entries, no resource-limit failures, 10 RED controls and 0 MISSED. Their 1508 RECORD lines are byte-identical, SHA256 6418227d1b55f8e87d6608e87074ef41c7956eae714c37c857617bc53535b37f; the full logs are also byte-identical, SHA256 bc629315301660565cbbdd2494d422611fe37da2263281712d572cb9659073bf. The prior 226 stale records are gone, but these 13 remain on the measured main baseline. I kept release launch and usage records unchanged in this PR as requested. Please advise how you want the baseline refresh handled separately before landing.

Six CI jobs passed. The Windows Zig job failed after several host test commands reported DeviceLost or golden-hash differences and the job reached its one-hour limit: https://github.com/ashhart/TensorFold/actions/runs/42339910944/job/128305079381 . The Windows job on the measured main base passed: https://github.com/ashhart/TensorFold/actions/runs/42339202347/job/128302892417 . I attempted to rerun the failed job, but GitHub rejected it because this account lacks Actions admin rights. Could you rerun it?

[ashhart]

Thanks @yguanrong. The byte-identical RECORD lines and logs on main and the branch are what we needed: the release records don't change.

On your two questions:

• The 13 record-stale entries are main's own, so they don't belong in this PR. We'll refresh that baseline in a separate change.
• The Windows job has since passed on 11bf72e9d3, so there's nothing left to rerun.

There are no asks left, and it's in our landing queue now.

[ashhart]

Thank you @yguanrong. This is merged into main with your commits under your own name, so you're listed as a TensorFold contributor. It ships in the next release, credited to you in the changelog and the release notes.

[ashhart]

@yguanrong, the baseline refresh we mentioned is up as #2515. A GB10 audit of today's main found the same 13 stale nvcc 13.0 register slots you reported, and nothing else. Thanks for flagging them.