Refresh B200 MiniMax M3 TRT AgentX with stream interval 20 - #2686
Conversation
|
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 For PR verification, add the 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 模板，包括保留英文语句 如需进行 PR 验证，请为此 PR 添加 PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动（flake），重新运行失败的任务即可解决。参见 GitHub 关于重新运行失败任务的文档 |
|
Claude finished @cquil11's task in 1m 3s —— View job Review
LGTM - no blocking issues found The change is a single-value update ( |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — this is a single-line config change (stream_interval: 100 → 20) with a matching perf-changelog entry, and it is already merged into main matching this diff exactly.
Extended reasoning...
Overview
The PR changes one YAML key in minimaxm3_fp4_b200_trt_mtp.sh (stream_interval: 100 → 20) plus a corresponding perf-changelog.yaml entry referencing PR #2686. I confirmed against git log that this exact change is already present on main (commits 942386d and d377065), so the repository state matches the diff precisely.
Security risks
None. This is a purely internal benchmark tuning parameter for TensorRT-LLM's streaming response cadence — no auth, credential, or network-surface changes.
Level of scrutiny
Minimal scrutiny is warranted: this is a mechanical, single-value config tweak in a non-critical benchmarking script, well justified by the stated rationale (avoiding collapsed streaming updates for short generations skewing client-side latency metrics), and it follows the exact pattern of prior similar refresh PRs in this repo's history.
Other factors
No outstanding review comments beyond the automated CODEOWNER/labeling reminder, which is boilerplate and not a substantive concern. No bugs were reported by the bug hunting system.
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=32310416645 |
|
/reuse-sweep-run |
# Conflicts: # perf-changelog.yaml
2 participants
Summary
Why
A stream interval of 100 can collapse short generations into a single content update. That makes client-observed inter-token latency and interactivity unrepresentative for those requests. A lower interval provides enough intermediate observations to measure the client experience more faithfully.
Performance changelog
Refresh with lower stream interval to collect correct client metrics
Validation
bash -n benchmarks/single_node/agentic/minimaxm3_fp4_b200_trt_mtp.shgit diff --check