[Klaud Cold][agentic experiment][Variant B] Kimi-K3 B200 agg TP8xPP2 agentic — vLLM tool-call-parser flags / Kimi-K3 B200 聚合式 TP8xPP2 智能体实验——vLLM tool-call-parser 参数

[functionstackx]

Summary

Parser-flag experiment (variant B) for the Kimi-K3 MXFP4 B200 aggregated TP8×PP2 agentic bring-up — plain vLLM parser spellings.

Identical to the base bring-up PR in every way (srt-slurm v1.0.36, dynamo hash-pinned to the day-zero Kimi-K3 commit ba83080e / tag v1.4.0-kimi-k3-dev.1, vllm/vllm-openai:kimi-k3, conc-8 smoke test) except the worker parser flags:

--tool-call-parser kimi_k3
--reasoning-parser kimi_k3

Related experiments

Three sibling PRs race the same recipe with different worker parser flags; whichever goes green first merges and the others close:

• Variant A (base PR): --dyn-tool-call-parser kimi_k3 --reasoning-parser kimi_k3 --dyn-reasoning-parser kimi_k3 — [Klaud Cold][agentic experiment][Variant A] feat: add Kimi-K3 MXFP4 B200 aggregated TP8xPP2 Dynamo-vLLM agentic bring-up / 新增 Kimi-K3 MXFP4 B200 聚合式 TP8xPP2 Dynamo-vLLM 智能体编码基准测试（bring-up） #2355
• Variant B (this PR): --tool-call-parser kimi_k3 --reasoning-parser kimi_k3
• Variant C: no parser flags on the worker — [Klaud Cold][agentic experiment][Variant C] Kimi-K3 B200 agg TP8xPP2 agentic — no parser flags / Kimi-K3 B200 聚合式 TP8xPP2 智能体实验——不带解析器参数 #2358

中文说明

Kimi-K3 MXFP4 B200 聚合式 TP8×PP2 智能体 bring-up 的解析器参数实验（变体 B）——vLLM 原生写法。

除 worker 解析器参数外与基础 PR 完全一致（srt-slurm v1.0.36、dynamo 固定到 day-zero Kimi-K3 提交 ba83080e / 标签 v1.4.0-kimi-k3-dev.1、vllm/vllm-openai:kimi-k3 镜像、并发 8 冒烟测试）：worker 使用 --tool-call-parser kimi_k3 --reasoning-parser kimi_k3。

相关实验

三个兄弟 PR 以不同的 worker 解析器参数并行竞跑同一配方，先通过者合并、其余关闭：变体 A（基础 PR，dynamo --dyn-* 命名空间参数）#2355；变体 B（本 PR，vLLM 原生写法）；变体 C（不带解析器参数）#2358。

🤖 Generated with Claude Code

[github-actions]

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 关于重新运行失败任务的文档

[github-actions]

see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=30299707008
see unofficial run visualizer at https://inferencex.semianalysis.com/evaluation?unofficialRun=30299707008

[claude]

🟡 The recipe deliberately sets health_check.max_attempts: 1440 (4hr window) for the ~1.4TB MXFP4 checkpoint load off shared Lustre, but runners/launch_b200-dgxc.sh's pre-existing multinode-path sed (s/^ max_attempts: [0-9]*/ max_attempts: 720/) unconditionally matches the recipe's 2-space-indented line and silently clamps it back to 720 (2hr). This is the first multinode+agentic recipe on cluster:b200-dgxc to carry max_attempts > 720, so this PR is the first to collide with that override — the author's explicit 4hr intent is currently a dead value; worth scoping the sed (e.g. only bump if the value is below 720) or dropping/correcting the recipe's comment so it doesn't mislead future readers.

Extended reasoning...

The bug: benchmarks/multi_node/srt-slurm-recipes/vllm/kimi-k3/agentic/agg-b200-tp8pp2-agentic.yaml sets:

health_check:
  interval_seconds: 10
  max_attempts: 1440

with an explicit design rationale nearby ("~1.4TB of MXFP4 weights off shared Lustre: keep the engine-ready window generous"), i.e. a deliberate 4-hour health-check window (1440 × 10s).

However, runners/launch_b200-dgxc.sh (unmodified by this PR, but exercised for the first time by this recipe on this runner) contains, in the IS_MULTINODE branch:

sed -i 's/^  max_attempts: [0-9]*/  max_attempts: 720/' "${CONFIG_FILE%%:*}"

This runs unconditionally on every multinode job, after the recipe file has been copied into the srt-slurm checkout and referenced via CONFIG_FILE. The pattern ^ max_attempts: [0-9]* (anchored, exactly two leading spaces) matches the recipe's max_attempts: 1440 line exactly, so the sed rewrites it in place to max_attempts: 720 before srtctl apply ever reads the file. The recipe's intended 4-hour window is silently reduced to 2 hours — the 1440 value the author wrote (and commented on) never actually reaches the health-check logic.

Why nothing else in the pipeline prevents this: the sed has no guard for "only bump if lower" — it's a blind overwrite regardless of the file's existing value, so it clamps down just as readily as it bumps up. Nothing in the recipe YAML or configs/nvidia-master.yaml routing opts out of this launcher step, and there's no comment in the recipe warning that max_attempts is moot on this runner — so a reader of the recipe today would reasonably (and incorrectly) believe the 4-hour window is honored.

Why this specific PR is the one that surfaces it: all other recipes with max_attempts: 1440 in the repo are wired to the gb200/gb300 launchers (launch_gb200-nv.sh / launch_gb300-nv.sh), which don't contain this sed. This Kimi-K3 config is the first multinode+agentic recipe on cluster:b200-dgxc (launch_b200-dgxc.sh) to specify a health-check window above 720, so it's the first config to actually collide with the override — it isn't a hypothetical, it directly affects this PR's own recipe.

Step-by-step proof:

1. configs/nvidia-master.yaml routes kimik3-fp4-b200-dynamo-vllm-agentic to runner: cluster:b200-dgxc, i.e. launch_b200-dgxc.sh, with additional-settings: CONFIG_FILE=recipes/vllm/kimi-k3/agentic/agg-b200-tp8pp2-agentic.yaml.
2. IS_AGENTIC=1 triggers the overlay step, copying benchmarks/multi_node/srt-slurm-recipes/vllm/kimi-k3/agentic/ into the srt-slurm clone's recipes/vllm/kimi-k3/agentic/ — this is the actual file CONFIG_FILE points at.
3. Because IS_MULTINODE == "true" for this recipe, the script reaches the line sed -i 's/^ max_attempts: [0-9]*/ max_attempts: 720/' "${CONFIG_FILE%%:*}".
4. The copied file contains max_attempts: 1440 at 2-space indent — matches the anchor exactly — sed rewrites it to max_attempts: 720.
5. srtctl apply -f "$CONFIG_FILE" ... runs immediately after, reading the now-mutated file: the health check will poll for 720 × 10s = 7200s = 2hr, not the author's intended 14400s = 4hr.

Impact and why it's a nit, not a blocker: the mechanism is real and the author's stated intent is genuinely defeated, but a concrete failure at merge is unlikely for two independent reasons already present in this same PR: (1) the recipe sets VLLM_ENGINE_READY_TIMEOUT_S: "3600" (1hr) in aggregated_environment, so vLLM's own engine-init timeout fires at 1hr regardless of the health-check window — the clamped 2hr window is never actually the binding constraint versus the intended 4hr, since both exceed the 1hr engine timeout; and (2) the PR's own perf-changelog.yaml entry records the observed engine-ready time as "~14 min via fastsafetensors," roughly 8x under even the clamped 720-attempt/2hr window. So the failure mode the recipe's comment is defending against (Lustre contention pushing load past 2hr) is not observed in practice here.

Suggested fix: either scope the launcher's sed to only raise max_attempts when it's below the floor (e.g. compare before overwriting), or update the recipe's max_attempts/comment to reflect that 720 is the effective ceiling on cluster:b200-dgxc until the launcher is changed — as-is, the 1440 value and its accompanying comment are misleading to future readers of this recipe.

[functionstackx]

Variant B is definitively dead: even on the day-zero Kimi-K3 dynamo build (ba83080e / v1.4.0-kimi-k3-dev.1), the dynamo-vllm worker entrypoint rejects the plain vLLM spelling — __main__.py: error: unrecognized arguments: --tool-call-parser kimi_k3 (sweep job 90089820192). The surviving experiments are Variant A (#2355, dynamo --dyn-* namespaced args, which the worker accepts) and Variant C (#2358, no parser flags). Closing.

中文：变体 B 已确定失败：即使在 day-zero Kimi-K3 dynamo 构建（ba83080e / v1.4.0-kimi-k3-dev.1）上，dynamo-vllm worker 入口仍拒绝 vLLM 原生写法（unrecognized arguments: --tool-call-parser kimi_k3）。存活的实验为变体 A（#2355，dynamo --dyn-* 命名空间参数，worker 可接受）与变体 C（#2358，不带解析器参数）。现关闭本 PR。