[TRTLLM-4629][doc] Add B300 & GB300 in documents

[VALLIS-NERIA]

Summary by CodeRabbit

• Documentation
  • Expanded GPU architecture support documentation with new Blackwell SM103 and models including B300, GB300, and RTX Pro 6000 SE with FP4 optimization.
  • Updated support matrices to include Blackwell SM103 support for quantization, chunked prefill, and KV cache features.
  • Added NVIDIA GB300 NVL72 GPU model entry to reference documentation.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

Description

Test Coverage

PR Checklist

Please review the following before submitting your PR:

• PR description clearly explains what and why. If using CodeRabbit's summary, please make sure it makes sense.

• PR Follows TRT-LLM CODING GUIDELINES to the best of your knowledge.

• Test cases are provided for new code paths (see test instructions)

• Any new dependencies have been scanned for license and vulnerabilities

• CODEOWNERS updated if ownership changes

• Documentation updated as needed

• Update tava architecture diagram if there is a significant design change in PR.

• The reviewers assigned automatically/manually are appropriate for the PR.

• Please check this after reviewing the above items as appropriate for this PR.

GitHub Bot Help

/bot [-h] ['run', 'kill', 'skip', 'reuse-pipeline'] ...

Provide a user friendly way for developers to interact with a Jenkins server.

Run /bot [-h|--help] to print this help message.

See details below for each supported subcommand.

Details

run [--reuse-test (optional)pipeline-id --disable-fail-fast --skip-test --stage-list "A10-PyTorch-1, xxx" --gpu-type "A30, H100_PCIe" --test-backend "pytorch, cpp" --add-multi-gpu-test --only-multi-gpu-test --disable-multi-gpu-test --post-merge --extra-stage "H100_PCIe-TensorRT-Post-Merge-1, xxx" --detailed-log --debug(experimental)]

Launch build/test pipelines. All previously running jobs will be killed.

--reuse-test (optional)pipeline-id (OPTIONAL) : Allow the new pipeline to reuse build artifacts and skip successful test stages from a specified pipeline or the last pipeline if no pipeline-id is indicated. If the Git commit ID has changed, this option will be always ignored. The DEFAULT behavior of the bot is to reuse build artifacts and successful test results from the last pipeline.

--disable-reuse-test (OPTIONAL) : Explicitly prevent the pipeline from reusing build artifacts and skipping successful test stages from a previous pipeline. Ensure that all builds and tests are run regardless of previous successes.

--disable-fail-fast (OPTIONAL) : Disable fail fast on build/tests/infra failures.

--skip-test (OPTIONAL) : Skip all test stages, but still run build stages, package stages and sanity check stages. Note: Does NOT update GitHub check status.

--stage-list "A10-PyTorch-1, xxx" (OPTIONAL) : Only run the specified test stages. Examples: "A10-PyTorch-1, xxx". Note: Does NOT update GitHub check status.

--gpu-type "A30, H100_PCIe" (OPTIONAL) : Only run the test stages on the specified GPU types. Examples: "A30, H100_PCIe". Note: Does NOT update GitHub check status.

--test-backend "pytorch, cpp" (OPTIONAL) : Skip test stages which don't match the specified backends. Only support [pytorch, cpp, tensorrt, triton]. Examples: "pytorch, cpp" (does not run test stages with tensorrt or triton backend). Note: Does NOT update GitHub pipeline status.

--only-multi-gpu-test (OPTIONAL) : Only run the multi-GPU tests. Note: Does NOT update GitHub check status.

--disable-multi-gpu-test (OPTIONAL) : Disable the multi-GPU tests. Note: Does NOT update GitHub check status.

--add-multi-gpu-test (OPTIONAL) : Force run the multi-GPU tests in addition to running L0 pre-merge pipeline.

--post-merge (OPTIONAL) : Run the L0 post-merge pipeline instead of the ordinary L0 pre-merge pipeline.

--extra-stage "H100_PCIe-TensorRT-Post-Merge-1, xxx" (OPTIONAL) : Run the ordinary L0 pre-merge pipeline and specified test stages. Examples: --extra-stage "H100_PCIe-TensorRT-Post-Merge-1, xxx".

--detailed-log (OPTIONAL) : Enable flushing out all logs to the Jenkins console. This will significantly increase the log volume and may slow down the job.

--debug (OPTIONAL) : Experimental feature. Enable access to the CI container for debugging purpose. Note: Specify exactly one stage in the stage-list parameter to access the appropriate container environment. Note: Does NOT update GitHub check status.

For guidance on mapping tests to stage names, see docs/source/reference/ci-overview.md
and the scripts/test_to_stage_mapping.py helper.

kill

kill

Kill all running builds associated with pull request.

skip

skip --comment COMMENT

Skip testing for latest commit on pull request. --comment "Reason for skipping build/test" is required. IMPORTANT NOTE: This is dangerous since lack of user care and validation can cause top of tree to break.

reuse-pipeline

reuse-pipeline

Reuse a previous pipeline to validate current commit. This action will also kill all currently running builds associated with the pull request. IMPORTANT NOTE: This is dangerous since lack of user care and validation can cause top of tree to break.

[coderabbitai]

📝 Walkthrough

Walkthrough

This change updates documentation to reflect expanded GPU architecture support for Blackwell GPUs, specifically adding SM103 support details to quantization and model support matrices, along with new GPU models (B300, GB300, RTX Pro 6000 SE) to architecture support lists across multiple documentation files.

Changes

Cohort / File(s)	Summary
Quantization and Hardware Support Documentation docs/source/features/quantization.md	Added Blackwell SM103 entry to Model Supported Matrix and Hardware Support Matrix; updated explanatory notes to reference MXFP8 recipe for both SM100 and SM103, and clarified SM90 uses a different FP8 recipe.
Support Matrix Documentation docs/source/legacy/reference/support-matrix.md	Added NVIDIA GB300 NVL72 GPU model entry; updated Blackwell precision line from "SM100/SM120" to "SM100/SM103/SM120".
Model Feature Support Documentation docs/source/models/supported-models.md	Updated Multimodal Feature Support Matrix footnotes: Chunked Prefill now includes SM103; KV cache reuse expanded to include SM103 alongside existing SM90/SM100 support.
Architecture Overview Documentation docs/source/overview.md	Expanded "Latest GPU Architecture Support" section: Blackwell line now includes B300, GB300, and RTX Pro 6000 SE with FP4 optimization; Hopper line formatting clarified.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

• All changes are documentation-only updates with no code logic alterations
• Updates follow existing patterns and naming conventions consistently
• Primary review focus: verify GPU model names (SM103, B300, GB300, RTX Pro 6000 SE) and confirm feature support mappings are accurate across all references

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description is entirely the template structure with placeholder comments and no actual content filled in—no explanation of changes, test coverage details, or checklist items completed.	Fill in the Description section explaining what was changed and why. Add Test Coverage section listing relevant documentation validation tests. Complete the PR Checklist items as applicable to this documentation update.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the main changes: adding B300 and GB300 GPU models to documentation files, which aligns with the changeset modifications across quantization, support matrix, models, and overview documents.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0a6fd1d and 726c034.

📒 Files selected for processing (4)

• docs/source/features/quantization.md (1 hunks)
• docs/source/legacy/reference/support-matrix.md (2 hunks)
• docs/source/models/supported-models.md (1 hunks)
• docs/source/overview.md (1 hunks)

🧰 Additional context used

🧠 Learnings (13)

📓 Common learnings

Learnt from: venkywonka
Repo: NVIDIA/TensorRT-LLM PR: 6029
File: .github/pull_request_template.md:45-53
Timestamp: 2025-08-27T17:50:13.264Z
Learning: For PR templates in TensorRT-LLM, avoid suggesting changes that would increase developer overhead, such as converting plain bullets to mandatory checkboxes. The team prefers guidance-style bullets that don't require explicit interaction to reduce friction in the PR creation process.

Learnt from: nzmora-nvidia
Repo: NVIDIA/TensorRT-LLM PR: 9163
File: tensorrt_llm/_torch/auto_deploy/custom_ops/quant.py:107-113
Timestamp: 2025-11-14T11:22:03.729Z
Learning: In TensorRT-LLM AutoDeploy custom ops, when adding hardware capability checks to select between kernel implementations (e.g., cuBLAS vs. CUDA kernel), use descriptive variable names that identify the specific GPU architectures or families being targeted (e.g., `is_blackwell_geforce_or_ada`) rather than generic names like `enable_cuda_core`. This makes it clear that the code is selecting an implementation path based on hardware capabilities, not enabling/disabling hardware features.

📚 Learning: 2025-11-14T11:22:03.729Z

Learnt from: nzmora-nvidia
Repo: NVIDIA/TensorRT-LLM PR: 9163
File: tensorrt_llm/_torch/auto_deploy/custom_ops/quant.py:107-113
Timestamp: 2025-11-14T11:22:03.729Z
Learning: In TensorRT-LLM AutoDeploy custom ops, when adding hardware capability checks to select between kernel implementations (e.g., cuBLAS vs. CUDA kernel), use descriptive variable names that identify the specific GPU architectures or families being targeted (e.g., `is_blackwell_geforce_or_ada`) rather than generic names like `enable_cuda_core`. This makes it clear that the code is selecting an implementation path based on hardware capabilities, not enabling/disabling hardware features.

Applied to files:

• docs/source/legacy/reference/support-matrix.md
• docs/source/overview.md
• docs/source/features/quantization.md

📚 Learning: 2025-09-23T15:12:38.312Z

Learnt from: nv-lschneider
Repo: NVIDIA/TensorRT-LLM PR: 7910
File: cpp/tensorrt_llm/thop/allreduceOp.cpp:352-446
Timestamp: 2025-09-23T15:12:38.312Z
Learning: In TensorRT-LLM NCCL device implementation, NCCL version 2.28+ requirements are handled at runtime in the nccl_device/config layer rather than with compile-time guards. This allows the allreduceOp to remain version-agnostic and delegates version compatibility validation to the appropriate lower-level components that can gracefully handle unsupported configurations.

Applied to files:

• docs/source/legacy/reference/support-matrix.md
• docs/source/overview.md

📚 Learning: 2025-08-26T09:49:04.956Z

Learnt from: pengbowang-nv
Repo: NVIDIA/TensorRT-LLM PR: 7192
File: tests/integration/test_lists/test-db/l0_dgx_b200.yml:56-72
Timestamp: 2025-08-26T09:49:04.956Z
Learning: In TensorRT-LLM test configuration files, the test scheduling system handles wildcard matching with special rules that prevent duplicate test execution even when the same tests appear in multiple yaml files with overlapping GPU wildcards (e.g., "*b200*" and "*gb200*").

Applied to files:

• docs/source/legacy/reference/support-matrix.md
• docs/source/overview.md

📚 Learning: 2025-08-27T14:23:55.566Z

Learnt from: ixlmar
Repo: NVIDIA/TensorRT-LLM PR: 7294
File: tensorrt_llm/_torch/modules/rms_norm.py:17-17
Timestamp: 2025-08-27T14:23:55.566Z
Learning: The TensorRT-LLM project requires Python 3.10+ as evidenced by the use of TypeAlias from typing module, match/case statements, and union type | syntax throughout the codebase, despite some documentation still mentioning Python 3.8+.

Applied to files:

• docs/source/legacy/reference/support-matrix.md
• docs/source/overview.md

📚 Learning: 2025-08-21T00:16:56.457Z

Learnt from: farshadghodsian
Repo: NVIDIA/TensorRT-LLM PR: 7101
File: docs/source/blogs/tech_blog/blog9_Deploying_GPT_OSS_on_TRTLLM.md:36-36
Timestamp: 2025-08-21T00:16:56.457Z
Learning: TensorRT-LLM container release tags in documentation should only reference published NGC container images. The README badge version may be ahead of the actual published container versions.

Applied to files:

• docs/source/legacy/reference/support-matrix.md
• docs/source/overview.md

📚 Learning: 2025-09-23T15:13:48.819Z

Learnt from: nv-lschneider
Repo: NVIDIA/TensorRT-LLM PR: 7910
File: cpp/tensorrt_llm/kernels/nccl_device/multimem.h:20-30
Timestamp: 2025-09-23T15:13:48.819Z
Learning: TRT-LLM targets modern CUDA toolkits that support FP8 datatypes, so cuda_fp8.h can be included unconditionally without version guards in TRT-LLM code.

Applied to files:

• docs/source/legacy/reference/support-matrix.md
• docs/source/overview.md
• docs/source/features/quantization.md

📚 Learning: 2025-09-24T03:31:28.908Z

Learnt from: tongyuantongyu
Repo: NVIDIA/TensorRT-LLM PR: 7520
File: tensorrt_llm/_torch/pyexecutor/resource_manager.py:605-613
Timestamp: 2025-09-24T03:31:28.908Z
Learning: In TensorRT-LLM Ray orchestrator mode, ProcessGroups are initialized with both Gloo and NCCL backends (e.g., "cuda:nccl,cpu:gloo"), allowing PyTorch distributed to automatically route CPU tensors through Gloo and GPU tensors through NCCL. This eliminates the need for manual device placement when performing allreduce operations on base types.

Applied to files:

• docs/source/legacy/reference/support-matrix.md

📚 Learning: 2025-09-19T21:28:13.751Z

Learnt from: jhaotingc
Repo: NVIDIA/TensorRT-LLM PR: 7856
File: cpp/tensorrt_llm/thop/fp8BlockScaleMoe.cpp:159-166
Timestamp: 2025-09-19T21:28:13.751Z
Learning: In TensorRT-LLM blockScaleMoe routing (cpp/tensorrt_llm/kernels/trtllmGenKernels/blockScaleMoe/runner.cu), the DeepSeek routing method performs reinterpret_cast<float*>(routingLogits) at line 89, which could cause issues if routing_logits are BF16. However, Qwen3-FP8 models use RenormalizeNaive routing method and are not affected by this dtype casting issue.

Applied to files:

• docs/source/legacy/reference/support-matrix.md
• docs/source/features/quantization.md

📚 Learning: 2025-08-06T03:47:16.802Z

Learnt from: venkywonka
Repo: NVIDIA/TensorRT-LLM PR: 6650
File: tests/integration/test_lists/qa/llm_perf_cluster.yml:33-37
Timestamp: 2025-08-06T03:47:16.802Z
Learning: Ministral is a valid and distinct model family from Mistral AI, separate from their regular Mistral models. Ministral 8B is specifically designed for edge computing and on-device applications, released in October 2024. In TensorRT-LLM test configurations, "ministral_8b" and "ministral_8b_fp8" are correct model identifiers and should not be changed to "mistral_8b".

Applied to files:

• docs/source/legacy/reference/support-matrix.md

📚 Learning: 2025-09-18T05:41:45.847Z

Learnt from: pengbowang-nv
Repo: NVIDIA/TensorRT-LLM PR: 7120
File: tensorrt_llm/llmapi/llm.py:690-697
Timestamp: 2025-09-18T05:41:45.847Z
Learning: Kimi model support is currently focused on the PyTorch backend path, with TRT path support potentially coming later.

Applied to files:

• docs/source/overview.md

📚 Learning: 2025-11-24T17:09:17.870Z

Learnt from: CR
Repo: NVIDIA/TensorRT-LLM PR: 0
File: CODING_GUIDELINES.md:0-0
Timestamp: 2025-11-24T17:09:17.870Z
Learning: Applies to **/*.py : The code developed for TensorRT-LLM should conform to Python 3.8+

Applied to files:

• docs/source/overview.md

📚 Learning: 2025-08-13T08:21:13.006Z

Learnt from: dbari
Repo: NVIDIA/TensorRT-LLM PR: 6714
File: tests/integration/defs/triton_server/build_model.sh:724-726
Timestamp: 2025-08-13T08:21:13.006Z
Learning: Mistral Small 3.1 multimodal (pixtral model type) supports any batch size for the multimodal encoder, not just batch size 1. The max_batch_size parameter can be set to values like 2 without conflicts with the runtime batching logic.

Applied to files:

• docs/source/models/supported-models.md

🪛 markdownlint-cli2 (0.18.1)

docs/source/features/quantization.md

103-103: Tables should be surrounded by blank lines

(MD058, blanks-around-tables)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Pre-commit Check

🔇 Additional comments (8)

docs/source/legacy/reference/support-matrix.md (2)

135-135: ✓ GPU model addition is well-formatted.

The GB300 NVL72 entry follows established conventions with proper hyperlink formatting and positioning.

---

161-161: ✓ Blackwell precision entry correctly expanded for SM103.

The explicit inclusion of SM103 alongside SM100/SM120 is consistent with hardware architecture documentation practices.

docs/source/features/quantization.md (2)

99-99: ✓ Blackwell(sm103) entry correctly positioned and configured in Hardware Support Matrix.

The new row aligns feature support (MXFP8-based block scaling) with SM100 capabilities and is properly ordered between SM120 and SM100.

---

105-105: ✓ Note text correctly updated to cover both sm100/103.

The clarification of MXFP8 recipe scope for sm100/103 with explicit distinction from SM90 is accurate and helpful.

docs/source/models/supported-models.md (2)

40-40: ✓ Chunked Prefill footnote correctly extended to SM103.

The update from "SM100" to "SM100/SM103" accurately reflects feature availability scope across Blackwell variants.

---

41-41: ✓ KV cache reuse footnote correctly extended to SM103 with dtype constraints preserved.

The update from "SM90/SM100" to "SM90/SM100/SM103" maintains the critical precision qualifier (BF16/FP8 KV cache dtype) and accurately documents multi-architecture support.

docs/source/overview.md (2)

52-52: ✓ Blackwell GPU model list correctly expanded with B300 and GB300.

The additions are properly positioned and maintain consistency with feature qualifiers (FP4 optimization). Product names match current NVIDIA portfolio.

---

53-53: ✓ Hopper GPU model list is comprehensive and accurately qualified.

The explicit listing of H100, H200, and GH200 with FP8 acceleration is consistent with marketing positioning and technical accuracy.

[VALLIS-NERIA]

/bot run

[tensorrt-cicd]

PR_Github #26774 [ run ] triggered by Bot. Commit: 09d4c79

[tensorrt-cicd]

PR_Github #26774 [ run ] completed with state SUCCESS. Commit: 09d4c79
/LLM/release-1.1/L0_MergeRequest_PR pipeline #553 completed with status: 'SUCCESS'