[AMD] dsv4 atom-disagg eval sweep — validate reduced ATOM logging#1882
[AMD] dsv4 atom-disagg eval sweep — validate reduced ATOM logging#1882Oseltamivir wants to merge 15 commits into
Conversation
# Conflicts: # perf-changelog.yaml
…gl-disagg-evals-atomlog # Conflicts: # perf-changelog.yaml
The atom engine (atom.entrypoints.openai_server) is vLLM-based and reads
VLLM_LOGGING_LEVEL; env_atom.sh only set VLLM_LOG_LEVEL (a no-op for vLLM),
so the engine emitted its per-request KV-connector logs
([CONSUMER]/[PRODUCER]/[PD-*]/Engine Core) at INFO for the whole run.
- env_atom.sh: set VLLM_LOGGING_LEVEL=WARNING (real lever) plus
ATOM_UVICORN_ACCESS_LOG=0 / ATOM_UVICORN_LOG_LEVEL=warning (drop per-request
uvicorn access logs) and ATOMESH_LOG_LEVEL=warn. All overridable.
- server_atom.sh: atomesh router --log-level info -> ${ATOMESH_LOG_LEVEL}.
|
Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook If it is not, please create a PR first before we can merge your single node PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you 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. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers. If additional help is needed, PR authors can reach out to core maintainers over Slack. 感谢你的贡献!对于 vLLM 与 SGLang,请确保你的 recipe 与官方 vLLM recipes 和/或 SGLang cookbook 保持一致 如果不一致,请先创建一个 PR,之后我们才能将你的单节点 PR 合并到 master 分支。让我们确保文档保持一流水准,使整个 ML 社区都能从你的辛勤工作中受益!谢谢 PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动(flake),重新运行失败的任务即可解决。如果选择重新运行失败的任务,PR 作者有责任确保其最终通过。参见 GitHub 关于重新运行失败任务的文档:https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow 一般而言,PR 作者应先向相应公司的 CODEOWNERS 请求审阅并获得 PR 批准,然后再请求核心维护者审阅。 如需更多帮助,PR 作者可通过 Slack 联系核心维护者。 |
1 similar comment
|
Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook If it is not, please create a PR first before we can merge your single node PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you 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. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers. If additional help is needed, PR authors can reach out to core maintainers over Slack. 感谢你的贡献!对于 vLLM 与 SGLang,请确保你的 recipe 与官方 vLLM recipes 和/或 SGLang cookbook 保持一致 如果不一致,请先创建一个 PR,之后我们才能将你的单节点 PR 合并到 master 分支。让我们确保文档保持一流水准,使整个 ML 社区都能从你的辛勤工作中受益!谢谢 PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动(flake),重新运行失败的任务即可解决。如果选择重新运行失败的任务,PR 作者有责任确保其最终通过。参见 GitHub 关于重新运行失败任务的文档:https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow 一般而言,PR 作者应先向相应公司的 CODEOWNERS 请求审阅并获得 PR 批准,然后再请求核心维护者审阅。 如需更多帮助,PR 作者可通过 Slack 联系核心维护者。 |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 9e44be0. Configure here.
| if [[ "$DECODE_MTP_SIZE" -gt 0 ]]; then | ||
| MORI_MAX_DISPATCH_TOKENS_DECODE=$((MORI_MAX_DISPATCH_TOKENS_DECODE * (DECODE_MTP_SIZE + 1))) | ||
| MORI_MOE_MAX_INPUT_TOKENS_DECODE=$((MORI_MOE_MAX_INPUT_TOKENS_DECODE * (DECODE_MTP_SIZE + 1))) | ||
| # MORI_MOE_MAX_INPUT_TOKENS_DECODE=$((MORI_MOE_MAX_INPUT_TOKENS_DECODE * (DECODE_MTP_SIZE + 1))) |
There was a problem hiding this comment.
MoE input token scaling removed
Medium Severity
The DP+EP and MTP branches no longer recompute MORI_MOE_MAX_INPUT_TOKENS_PREFILL / MORI_MOE_MAX_INPUT_TOKENS_DECODE, so every non–DeepSeek-V4-Pro disagg job keeps the static defaults from env.sh even when dispatch tokens and bench concurrency are scaled. That desyncs MoE limits from the tuned DP+EP path.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit 9e44be0. Configure here.
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=27941462066 |
…TOM logging Repoint the new perf-changelog entry from sglang-disagg to atom-disagg so the all-evals/evals-only sweep runs the ATOM engine path (atom.entrypoints.openai_server) and exercises the VLLM_LOGGING_LEVEL/uvicorn/atomesh log-spam reduction.
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=27942496140 |


Description
Eval-only / all-evals sweep to validate the reduced ATOM multinode logging on hardware. Based on current
main(includes merged #1879: 8k1k-only--all-evals, per-conc score labels,--expected-concs), seeded from #1818's dsv4 disagg scaffolding, with theperf-changelog.yamlentry pointed atdsv4-fp4-mi355x-atom-disaggso the sweep exercises the ATOM engine path.Reduced ATOM logging (the thing under test)
The atom engine (
atom.entrypoints.openai_server) is vLLM-based and readsVLLM_LOGGING_LEVEL, butenv_atom.shonly setVLLM_LOG_LEVEL(a no-op for vLLM) — so the engine logged its per-request KV-connector flood ([CONSUMER]/[PRODUCER]/[PD-*]/Engine Core, ~6.5k lines in run 27924353733) at INFO.env_atom.sh: setVLLM_LOGGING_LEVEL=WARNING(the real lever) +ATOM_UVICORN_ACCESS_LOG=0,ATOM_UVICORN_LOG_LEVEL=warning,ATOMESH_LOG_LEVEL=warn. All overridable.server_atom.sh: atomesh router--log-level info→${ATOMESH_LOG_LEVEL}.Labels
all-evals,full-sweep-enabled,evals-only(all-evals also disables artifact reuse, so the run executes fresh).Validation target
Compare the atom-disagg eval job logs from this sweep against run 27924353733: the
[CONSUMER]/[PRODUCER]INFO flood and uvicorn access lines should be gone.Note: test/validation PR; not intended to supersede #1818.