[WIP] Test Kimi 2.5 B300 Agg#1998
Conversation
|
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 联系核心维护者。 |
| MOONCAKE_EVICTION_HIGH_WATERMARK_RATIO=0.80 | ||
| MOONCAKE_EVICTION_RATIO=0.10 | ||
| MOONCAKE_KV_LEASE_TTL=60s | ||
|
|
||
| echo "Starting Mooncake master on port $MOONCAKE_MASTER_PORT..." | ||
| mooncake_master --port "$MOONCAKE_MASTER_PORT" \ | ||
| --default_kv_lease_ttl=1h \ | ||
| > "$MOONCAKE_MASTER_LOG" 2>&1 & | ||
| MOONCAKE_MASTER_PID=$! | ||
| sleep 2 | ||
| if ! kill -0 "$MOONCAKE_MASTER_PID" 2>/dev/null; then | ||
| echo "Mooncake master died during startup." >&2 |
There was a problem hiding this comment.
🟡 The three variables MOONCAKE_EVICTION_HIGH_WATERMARK_RATIO=0.80, MOONCAKE_EVICTION_RATIO=0.10, and MOONCAKE_KV_LEASE_TTL=60s (lines 97-99) are assigned but never referenced by the mooncake_master invocation, which instead hardcodes --default_kv_lease_ttl=1h — directly contradicting the declared 60s — and omits the two eviction flags entirely, so upstream defaults (~0.95/0.05) apply. Every sister Mooncake recipe (dsv4_fp4_b200_vllm.sh, dsv4_fp4_b300_vllm.sh, minimaxm3_fp8_*) plumbs all three variables through with --eviction_high_watermark_ratio, --eviction_ratio, and --default_kv_lease_ttl. Either wire the vars in (and pick one lease TTL) or delete the dead assignments.
Extended reasoning...
What the bug is. In the new Mooncake branch of kimik2.5_fp4_b300.sh, three env-style vars are declared at lines 97-99 and never referenced again:
MOONCAKE_EVICTION_HIGH_WATERMARK_RATIO=0.80
MOONCAKE_EVICTION_RATIO=0.10
MOONCAKE_KV_LEASE_TTL=60sThree lines later, the master is launched with a hardcoded lease TTL and no eviction flags:
mooncake_master --port "$MOONCAKE_MASTER_PORT" \
--default_kv_lease_ttl=1h \
> "$MOONCAKE_MASTER_LOG" 2>&1 &Two concrete defects.
--default_kv_lease_ttl=1hcontradictsMOONCAKE_KV_LEASE_TTL=60s. One of these values must be wrong — both cannot represent the author's intent. Since the declared variable is dead, whichever value was tuned first was lost during editing.- The two eviction flags are absent. Without
--eviction_high_watermark_ratioand--eviction_ratio, the master falls back to upstream defaults (roughly 0.95 / 0.05), not the 0.80 / 0.10 the vars declare.
Cross-recipe comparison. Every other agentic Mooncake recipe in this repo declares the same three variables and wires them through:
benchmarks/single_node/agentic/dsv4_fp4_b200_vllm.sh:139-141— passes all three:--eviction_high_watermark_ratio="$MOONCAKE_EVICTION_HIGH_WATERMARK_RATIO" --eviction_ratio="$MOONCAKE_EVICTION_RATIO" --default_kv_lease_ttl="$MOONCAKE_KV_LEASE_TTL".benchmarks/single_node/agentic/dsv4_fp4_b300_vllm.sh:136-142— same pattern, with a comment stating the eviction tuning exists to "start eviction before an imbalanced rank exhausts its segment, and reclaim enough space for several concurrent multi-GB batch puts".benchmarks/single_node/agentic/minimaxm3_fp8_h100.sh:66-68(and the h200/mi300x/mi325x siblings) — all wire both eviction flags.
Step-by-step proof.
- This PR's config adds
{ tp: 4, ep: 1, kv-offloading: dram, kv-offload-backend: mooncake, conc-list: [64, 72, 80] }toconfigs/nvidia-master.yaml. - That takes the script down the
mooncake)branch (line 61+). - Lines 97-99 assign the three variables. No other line in the file (or in
benchmark_lib.sh) references them — grep confirms zero uses. - Line 101-104 launches the master with
--default_kv_lease_ttl=1hand nothing else. So the actual runtime state is: watermark ≈ 0.95, evict-ratio ≈ 0.05, lease = 1h. Declared intent (0.80 / 0.10 / 60s) never takes effect.
Impact. The sweep will still run — Mooncake defaults are functional. But the tuned eviction knobs exist in sister recipes for a documented reason (imbalanced-rank segment exhaustion under concurrent multi-GB puts), and this sweep hits the same regime: TP=4, CONC 64/72/80 with DRAM offload. Without --eviction_high_watermark_ratio and --eviction_ratio, if a single rank drifts hot it can OOM its segment before eviction begins. Additionally, the 60s-vs-1h contradiction leaves a live ambiguity — a future reader looking at MOONCAKE_KV_LEASE_TTL=60s will reasonably assume 60s is in effect and act on that belief.
Fix. Either plumb the variables through, matching the sister B300 recipe:
mooncake_master --port "$MOONCAKE_MASTER_PORT" \
--eviction_high_watermark_ratio="$MOONCAKE_EVICTION_HIGH_WATERMARK_RATIO" \
--eviction_ratio="$MOONCAKE_EVICTION_RATIO" \
--default_kv_lease_ttl="$MOONCAKE_KV_LEASE_TTL" \
> "$MOONCAKE_MASTER_LOG" 2>&1 &…or delete the three unused assignments and accept 1h / defaults as the intended configuration.
|
see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=28634655906 |
No description provided.