[None][chore] Update flashinfer-python from 0.6.15 to 0.6.16

[nv-guomingz]

Summary

• Bump flashinfer-python from 0.6.15 to 0.6.16 (latest stable).
• Updated version pins in requirements.txt, security_scanning/pyproject.toml, and ATTRIBUTIONS-Python.md.
• Regenerated security_scanning/poetry.lock via poetry lock (poetry check --lock passes): the flashinfer-python entry (version + wheel/sdist sha256 hashes) and metadata.content-hash.
  • This also refreshes flashinfer's own declared transitive constraint recorded in its [package.dependencies] block: nvidia-cudnn-frontend >=1.13.0 -> >=1.25.0. This is exactly flashinfer 0.6.16's requires_dist (0.6.15 declared >=1.13.0). It is metadata only: the locked nvidia-cudnn-frontend package version is unchanged at 1.26.0, which satisfies both, so no package is upgraded/downgraded. Note security_scanning/poetry.lock is not consumed by the L0 test pipeline (it feeds the separate security-scan / PLC job), so it is not a candidate cause of an L0 test failure.

Test plan

• pip install -r requirements.txt installs successfully
• pytest tests/unittest/_torch/flashinfer/ -v
• CI pre-merge (L0) passes

Dev Engineer Review

• Updated flashinfer-python from 0.6.15 to 0.6.16.
• Updated dependency pins and attribution data.
• Regenerated security_scanning/poetry.lock with refreshed FlashInfer hashes and metadata.
• Updated the declared nvidia-cudnn-frontend constraint. The locked version remains 1.26.0.
• No code or API changes were made.
• The reported waives.txt failures are pre-existing base-branch infrastructure issues.

QA Engineer Review

No test changes.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

The pull request updates flashinfer-python from version 0.6.15 to 0.6.16 in dependency pins and attribution metadata.

Changes

FlashInfer version update

Layer / File(s)	Summary
Align dependency pins and attribution requirements.txt, security_scanning/pyproject.toml, ATTRIBUTIONS-Python.md	Updates flashinfer-python from version 0.6.15 to 0.6.16 in dependency pins and attribution metadata.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Suggested reviewers: zhanruisunch

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title follows the required format and clearly states the dependency update from 0.6.15 to 0.6.16.
Description check	✅ Passed	The description explains the update, affected files, lockfile changes, test coverage, and CI status in sufficient detail.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@security_scanning/pyproject.toml`:
- Line 57: Regenerate security_scanning/poetry.lock from the flashinfer-python
0.6.16 requirement declared in pyproject.toml, ensuring the lockfile resolves
0.6.16 before installation or security scanning.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 7d1ea504-9d1e-425a-9c4f-1c2d06985ee6

📥 Commits

Reviewing files that changed from the base of the PR and between 24d0a8e and 28a9afd.

📒 Files selected for processing (3)

• ATTRIBUTIONS-Python.md
• requirements.txt
• security_scanning/pyproject.toml

[nv-guomingz]

/bot run

[tensorrt-cicd]

PR_Github #63349 [ run ] triggered by Bot. Commit: 668f13f Link to invocation

[tensorrt-cicd]

PR_Github #63349 [ run ] completed with state FAILURE. Commit: 668f13f
/LLM/main/L0_MergeRequest_PR pipeline #51337 completed with status: 'FAILURE'

CI Report

⚠️ Action Required:

• Please check the failed tests and fix your PR
• If you cannot view the failures, ask the CI triggerer to share details
• Once fixed, request an NVIDIA team member to trigger CI again

CI Agent Failure Analysis

Link to invocation

[BowenFu]

L0 is red on 668f13f, so this isn't mergeable yet — but two things in the diff are worth checking before the next run:

• The description says security_scanning/poetry.lock is left untouched. The diff does change it, including content-hash.
• That lock change also tightens a transitive pin: nvidia-cudnn-frontend >=1.13.0 → >=1.25.0. It isn't in the summary, and it's the most plausible candidate in this diff for the failure.

Unrelated but useful for #17165, which works around the DynamicTensorSpec hash/eq inconsistency in the autotuner: I diffed that class between 0.6.15 and 0.6.16 and it's byte-identical — same @dataclass(slots=True), same __hash__ carrying the same FIXME, still no __eq__. So that workaround is still needed after this bump rather than obviated by it, and the two PRs don't conflict.

[nv-guomingz]

Thanks @BowenFu — addressed the first two, and I dug into the L0 failure; it turns out to be unrelated to the lock change.

1. Description mismatch — fixed. Updated the PR description: security_scanning/poetry.lock was regenerated (flashinfer entry + hashes + content-hash), and I documented the transitive-pin refresh explicitly.

2. nvidia-cudnn-frontend >=1.13.0 → >=1.25.0 — metadata only, and not on the L0 path. That line is flashinfer 0.6.16's own declared requires_dist (0.6.15 declared >=1.13.0), faithfully recorded by poetry lock inside the flashinfer-python [package.dependencies] block. The locked nvidia-cudnn-frontend package is unchanged at 1.26.0 (satisfies both), so nothing is up/downgraded. Separately, security_scanning/poetry.lock is only consumed by the security-scan / PLC job (jenkins/TensorRT_LLM_PLC.groovy) — the L0 test pipeline installs from requirements.txt, not this lock — so it cannot be the L0 cause.

3. Actual L0 failure — pre-existing waives.txt inconsistency on the base, not this PR. Pulling the report for build 51337: every Build stage is SUCCESS, there are 0 failed tests, and the only red is the Check Test List infra stage (s_ai_failure_type: User / Configuration error). Its log:

Invalid cases:
{"invalid": ["cache_transceiver_precheck[gen_0]", "cache_transceiver_precheck[ctx_0]"]}
Invalid test names found, please correct them first!!!
Non-existent test name in l0 or qa list found in waives.txt: cache_transceiver_precheck[ctx_0]
Non-existent test name in l0 or qa list found in waives.txt: cache_transceiver_precheck[gen_0]

waives.txt:106-107 reference cache_transceiver_precheck[ctx_0]/[gen_0], which are not valid IDs in the L0/QA lists (the real tests are test_cache_transceiver_precheck_{config,run,e2e}.py). This commit touches only requirements.txt, security_scanning/{pyproject.toml,poetry.lock}, and ATTRIBUTIONS-Python.md — nothing under test_lists/. It is a base-branch issue that any PR on this base hits. I will rebase onto a main where those waive entries are corrected (or they can be fixed independently) and re-run.

Re #17165: thanks for the DynamicTensorSpec diff — agreed it is byte-identical across 0.6.15/0.6.16 (same @dataclass(slots=True), same __hash__ with the FIXME, still no __eq__), so that autotuner workaround is still needed after this bump and the two PRs do not conflict.

[nv-guomingz]

/bot run

[tensorrt-cicd]

PR_Github #63404 [ run ] triggered by Bot. Commit: 7977538 Link to invocation

[BowenFu]

Both points check out — thanks for digging in.

Confirmed the nvidia-cudnn-frontend bump is inside flashinfer-python's own [package.dependencies] block and no [[package]] version is up/downgraded anywhere in the lock diff, so it is metadata only.

One correction on the plan though: rebasing will not clear the red. waives.txt:106-107 still has those two entries on main right now (24d0a8e1c, merged 03:15Z as part of #17174) — your head 7977538e2 carries them too. So PR_Github #63404 will fail Check Test List the same way. Someone has to drop or re-scope those two lines on main first; cache_transceiver_precheck[ctx_0]/[gen_0] are synthetic JUnit case names emitted by jenkins/scripts/perf/disaggregated/slurm_ct_precheck_gate.sh, not pytest IDs in any l0/qa list, so the validator will keep rejecting them.

Nothing else from me on the diff — held only on CI.

[tensorrt-cicd]

PR_Github #63404 [ run ] completed with state FAILURE. Commit: 7977538
/LLM/main/L0_MergeRequest_PR pipeline #51383 completed with status: 'FAILURE'

CI Report

⚠️ Action Required:

• Please check the failed tests and fix your PR
• If you cannot view the failures, ask the CI triggerer to share details
• Once fixed, request an NVIDIA team member to trigger CI again

CI Agent Failure Analysis

Link to invocation

[nv-guomingz]

/bot run

[nv-guomingz]

/bot run

[tensorrt-cicd]

PR_Github #63424 [ run ] triggered by Bot. Commit: 4deb2e0 Link to invocation

[tensorrt-cicd]

PR_Github #63425 [ run ] triggered by Bot. Commit: 4deb2e0 Link to invocation

[tensorrt-cicd]

PR_Github #63424 [ run ] completed with state ABORTED. Commit: 4deb2e0

Link to invocation

[tensorrt-cicd]

PR_Github #63425 [ run ] completed with state FAILURE. Commit: 4deb2e0
/LLM/main/L0_MergeRequest_PR pipeline #51399 completed with status: 'FAILURE'

CI Report

⚠️ Action Required:

• Please check the failed tests and fix your PR
• If you cannot view the failures, ask the CI triggerer to share details
• Once fixed, request an NVIDIA team member to trigger CI again

CI Agent Failure Analysis

Link to invocation

[nv-guomingz]

/bot run --disable-fail-fast

[tensorrt-cicd]

PR_Github #63728 [ run ] triggered by Bot. Commit: c5dd39a Link to invocation

[tensorrt-cicd]

PR_Github #63728 [ run ] completed with state SUCCESS. Commit: c5dd39a
/LLM/main/L0_MergeRequest_PR pipeline #51680 completed with status: 'FAILURE'

CI Report

⚠️ Action Required:

• Please check the failed tests and fix your PR
• If you cannot view the failures, ask the CI triggerer to share details
• Once fixed, request an NVIDIA team member to trigger CI again

CI Agent Failure Analysis

Link to invocation

[nv-guomingz]

/bot run --disable-fail-fast

[tensorrt-cicd]

PR_Github #63795 [ run ] triggered by Bot. Commit: c5dd39a Link to invocation

[tensorrt-cicd]

PR_Github #63795 [ run ] completed with state SUCCESS. Commit: c5dd39a
/LLM/main/L0_MergeRequest_PR pipeline #51741 completed with status: 'FAILURE'

CI Report

⚠️ Action Required:

• Please check the failed tests and fix your PR
• If you cannot view the failures, ask the CI triggerer to share details
• Once fixed, request an NVIDIA team member to trigger CI again

CI Agent Failure Analysis

Link to invocation

[nv-guomingz]

/bot run --disable-fail-fast

[tensorrt-cicd]

PR_Github #63874 [ run ] triggered by Bot. Commit: 3848242 Link to invocation

[BowenFu]

The squashed head retains the approved behavior. The added positional False matches the FlashInfer 0.6.16 API and its upstream call site. Approved.

Please mention that the lockfile also raises the nvidia-cudnn-frontend minimum from 1.13.0 to 1.25.0.

[tensorrt-cicd]

PR_Github #63874 [ run ] completed with state SUCCESS. Commit: 3848242
/LLM/main/L0_MergeRequest_PR pipeline #51816 completed with status: 'FAILURE'

CI Report

⚠️ Action Required:

• Please check the failed tests and fix your PR
• If you cannot view the failures, ask the CI triggerer to share details
• Once fixed, request an NVIDIA team member to trigger CI again

CI Agent Failure Analysis

Link to invocation

[yihwang-nv]

LGTM

[yihwang-nv]

We don't need change the security_scanning/poetry.lock file. Modifying it can easily cause PR conflicts. It seems there's a bot that modifies the hash.

[nv-guomingz]

/bot run --disable-fail-fast

[tensorrt-cicd]

PR_Github #63949 [ run ] triggered by Bot. Commit: 3848242 Link to invocation

[nv-guomingz]

We don't need change the security_scanning/poetry.lock file. Modifying it can easily cause PR conflicts. It seems there's a bot that modifies the hash.

Thanks @yihwang-nv , I updated it via bot per #17175 (comment)

What are the guidelines for updating the security_scanning/poetry.lock file? If we leave it as is, could it trigger any security scan issues?

[tensorrt-cicd]

PR_Github #63949 [ run ] completed with state SUCCESS. Commit: 3848242
/LLM/main/L0_MergeRequest_PR pipeline #51884 completed with status: 'FAILURE'

CI Report

⚠️ Action Required:

• Please check the failed tests and fix your PR
• If you cannot view the failures, ask the CI triggerer to share details
• Once fixed, request an NVIDIA team member to trigger CI again

CI Agent Failure Analysis

Link to invocation

[nv-guomingz]

/bot run --disable-fail-fast

[tensorrt-cicd]

PR_Github #63975 [ run ] triggered by Bot. Commit: d53c44a Link to invocation

[BowenFu]

Flagging that the scope grew after the existing approvals: d53c44aa9 adds nvlink_two_sided_flashinfer.py (+51/−7), which was not in 38482428d. The approvals on this PR predate that file, so they don't cover it.

The change itself is well-reasoned and the containment is the right one — a module-scope from flashinfer.comm... that raises would break import tensorrt_llm outright, and deferring it behind lru_cache confines the failure to this one strategy. The narrow (ImportError, TypeError) catch is justified in the docstring rather than being a bare except, which I'd rather see than the alternative.

What I think needs to be stated in the description, though, is that this makes the bump non-neutral on a supported configuration. setup.py:483 is python_requires=">=3.10, <4" with a 3.10 classifier at :447. If 0.6.16's comm/fd_exchange.py really does evaluate array.array[int] at module scope, then on 3.10/3.11 _flashinfer_mnnvl() returns None, is_platform_supported() returns False, and the NVLinkTwoSidedFlashinfer MoE alltoall strategy stops being available on those interpreters — it works on main today at 0.6.15. That is a capability regression riding along with a [chore] version bump, not just a lock-file change.

Two things that would close it:

1. Say explicitly what happens downstream when is_platform_supported() returns False — if strategy selection falls back automatically, this is a silent perf change on 3.10/3.11 announced only by a log warning; if any config selects this strategy explicitly, the constructor's RuntimeError turns it into a hard failure at model init. Those are very different user impacts and the PR should name which one it is.
2. Link the upstream issue. The docstring calls it an upstream bug, which I agree with, but there's no tracking link — without one there's nothing to tell us when the workaround can come out, and lazy-import shims tend to outlive their cause.

Not blocking, and I'm not asking for the workaround to be removed — the containment is correct. But a MoE communication path going away on 3.10/3.11 shouldn't be discoverable only by reading the diff of a version bump.