Skip to content

chore(dsv4): rerun GB300 TRT-LLM AgentX / 重新运行 GB300 TRT-LLM AgentX 配置 - #2891

Closed
RohitNagraj wants to merge 3 commits into
mainfrom
dsv4-fp4-gb300-dynamo-trt-agentx-rerun
Closed

chore(dsv4): rerun GB300 TRT-LLM AgentX / 重新运行 GB300 TRT-LLM AgentX 配置#2891
RohitNagraj wants to merge 3 commits into
mainfrom
dsv4-fp4-gb300-dynamo-trt-agentx-rerun

Conversation

@RohitNagraj

@RohitNagraj RohitNagraj commented Sep 8, 2026

Copy link
Copy Markdown
Collaborator

Description

Re-run the existing DeepSeek V4 GB300 Dynamo TensorRT-LLM AgentX configuration to verify KV offload environment propagation. This PR changes only the performance changelog; the benchmark configuration and recipes are unchanged.

中文说明

重新运行现有的 DeepSeek V4 GB300 Dynamo TensorRT-LLM AgentX 配置,以验证 KV 卸载环境变量的传递。本 PR 仅更新性能变更日志,不修改基准测试配置或配方。

Related Issue

N/A

Type of Change

  • Bug fix
  • New feature
  • Configuration change
  • Documentation update
  • Other: configuration rerun

Checklist

  • I have tested my changes locally
  • I have updated documentation if necessary
  • For every change that can affect benchmark performance and every recipe addition or modification, I have appended a new entry to the physical end of perf-changelog.yaml and have not edited historical entries
  • Before merging via reuse, an authorized maintainer (OWNER/MEMBER/COLLABORATOR) has commented /reuse-sweep-run on this PR. Do this only once there is a final full sweep that is all green with evals passing, since after this comment the sweep label will no longer automatically kick off new sweeps. Remove and re-add the label to force one.

Note

Low Risk
Changelog-only change with no recipe or runtime configuration edits.

Overview
Documents a configuration rerun in perf-changelog.yaml for dsv4-fp4-gb300-dynamo-trt-agentx under the agentic-coding scenario.

The entry records re-executing the existing DeepSeek V4 GB300 Dynamo TensorRT-LLM AgentX setup to confirm KV offload environment variables propagate correctly. No benchmark recipes or config files are modified in this PR—only the changelog at the end of the file.

Reviewed by Cursor Bugbot for commit 7dcd29b. Bugbot is set up for automated code reviews on this repo. Configure here.

重新运行 GB300 Dynamo TensorRT-LLM AgentX 配置,以验证 KV 卸载环境变量的传递。
@github-actions

github-actions Bot commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

Thanks for the contribution! Please reach out to respective companies' CODEOWNER to fill in the latest PR_REVIEW_CHECKLIST.md before pinging core maintainer on Slack for review. In order for the signoff PR check bot to trigger, you must follow the PR_REVIEW_CHECKLIST.md template correctly, including the phrase As a PR reviewer and CODEOWNER, I have reviewed this and have.

For PR verification, add the full-sweep-fail-fast label (strongly recommended) to this PR — the benchmark sweep only runs on labeled PRs. Use full-sweep-enabled only if you need matrix jobs to keep running past a failure.

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. See GitHub's docs on re-running failed jobs


感谢你的贡献!请联系相应公司的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md,然后再在 Slack 上联系核心维护者进行审阅。为了触发 signoff PR 检查机器人,你必须正确遵循 PR_REVIEW_CHECKLIST.md 模板,包括保留英文语句 As a PR reviewer and CODEOWNER, I have reviewed this and have

如需进行 PR 验证,请为此 PR 添加 full-sweep-fail-fast 标签(强烈推荐)— 基准测试 sweep 仅在带有标签的 PR 上运行。仅当需要矩阵任务在失败后继续运行时才使用 full-sweep-enabled

PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动(flake),重新运行失败的任务即可解决。参见 GitHub 关于重新运行失败任务的文档

在性能变更日志中补充 PR #2891 链接。
恢复既有变更日志条目,并将 PR #2891 链接写入本次重新运行条目。

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reviewed this PR and didn't find any bugs in the appended entry's content. Because the append's correctness depends on a byte-level detail of the repo's changelog validator that I could not execute in this environment, a human (or a CI run of utils/validate_perf_changelog.py) should still confirm this specific append passes before merge.

What was reviewed:

  • The new entry's fields (config-keys, scenario-type, description, pr-link) against the existing entry shape/conventions in perf-changelog.yaml.
  • Append-only/byte-immutability: no historical bytes changed; the new block is appended at the physical tail.
  • The pull/XXX pr-link placeholder: the validator's PR_LINK_PLACEHOLDERS set explicitly allows this placeholder for PR-numbered runs, so it is not a defect on its own.
  • The separator line right before the new entry: the preceding historical entry (PR #2866) ends its block with a whitespace-only line (" \n") rather than a true blank line. Reading validate_raw_change() in utils/validate_perf_changelog.py, this makes base_raw.endswith(b"\n\n") false, which sets expected_start = b"\n- config-keys:" — i.e. it appears to require an extra blank line before the new entry that this diff does not add. I could not run the validator in this sandbox to confirm whether it actually rejects this append, so this is worth a human/CI check rather than a firm finding.
Extended reasoning...

Overview

The diff touches a single file, perf-changelog.yaml, appending one new entry (config-keys: dsv4-fp4-gb300-dynamo-trt-agentx, scenario-type: agentic-coding) with a description of a configuration re-run and a pr-link using the placeholder pull/XXX. No recipe, benchmark, or script files changed, matching the PR description's claim that this is changelog-only.

Security risks

None. This is a data-only YAML append with no executable code, credentials, or configuration that affects auth, permissions, or crypto paths.

Level of scrutiny

This warrants light-but-careful scrutiny: the change is trivial in size and intent, but the repository's own docs (AGENTS.md, CONTRIBUTING.md) stress that perf-changelog.yaml is append-only and byte-sensitive, and a dedicated validator (utils/validate_perf_changelog.py) enforces exact append-boundary formatting. I read that validator's source directly. Its validate_added_pr_link() explicitly allows the pull/XXX placeholder for PR-numbered runs, so that part is fine. However, tracing validate_raw_change() against the actual bytes at the append point (confirmed via Read/Grep that the preceding historical entry's trailing separator line is " \n", two spaces, not a true blank line) suggests the boundary check suffix.startswith(expected_start) may fail for this specific append, since base_raw.endswith(b"\n\n") evaluates false and the diff does not add the extra blank line the code path appears to require. I was unable to execute the validator or a Python check in this sandboxed session (all python3 invocations were denied), so I could not empirically confirm this one way or the other — it is a plausible but unverified concern rather than a confirmed bug, and it stems from a pre-existing quirk in the historical file rather than anything the author did wrong.

Other factors

The PR author's own checklist and description are consistent with the diff (changelog-only, append-only, no code/recipe changes). Given the automated bug hunt found nothing and the only two candidate concerns raised were investigated (pr-link placeholder is allowed by design; the separator issue is unverifiable without code execution but plausible from reading the validator), a defer with the "what was reviewed" framing is more honest than a bare approve, since a human with the ability to actually run utils/validate_perf_changelog.py can settle the one open question in seconds.

This review covers commit 860d76e, which is no longer the latest commit on this pull request; later commits are not covered by it.

@github-actions

github-actions Bot commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

@RohitNagraj

Copy link
Copy Markdown
Collaborator Author

Just a perf test PR. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Development

Successfully merging this pull request may close these issues.

1 participant