Skip to content

Add DRAM KV offloading (HiCache) to GLM-5.2 NVFP4 B300 SGLang agentic recipe#2279

Merged
Oseltamivir merged 3 commits into
mainfrom
add-glm5.2-b300-agentic-hicache
Jul 19, 2026
Merged

Add DRAM KV offloading (HiCache) to GLM-5.2 NVFP4 B300 SGLang agentic recipe#2279
Oseltamivir merged 3 commits into
mainfrom
add-glm5.2-b300-agentic-hicache

Conversation

@Oseltamivir

Copy link
Copy Markdown
Collaborator

Summary

Follow-up to #2268. Run 29651235293 showed both arms falling off a cliff once the 1M-context agentic corpus working set outgrows the HBM KV pool: gpu_kv_cache_usage_pct pins at 1.0 past conc 8 (TP8 arm) / conc 64 (DP8 attention-DP arm), and the radix hit rate collapses from a ~0.97 theoretical ceiling to 0.04–0.06. Every post-knee turn then re-prefills its entire 100k+-token history (at conc 32: 2,350 input tok/s/gpu vs 14.5 output tok/s/gpu), so throughput drops instead of plateauing while TTFT blows out to minutes — all post-knee points land dominated in the low-interactivity/low-throughput corner.

This enables DRAM KV offloading on all points of both arms so evicted prefixes spill to a pinned host pool and come back at C2C bandwidth instead of being recomputed:

  • kv-offloading: dram + kv-offload-backend: hicache on both search-space arms (conc lists unchanged)
  • HiCache flags follow the qwen3.5-fp8-b300-sglang-agentic-hicache recipe: --page-size 64, --hicache-io-backend kernel, --hicache-mem-layout page_first, write policy write_through_selective (overridable)
  • Per-rank pool = TOTAL_CPU_DRAM_GB / TP (= 2399/8 ≈ 299 GB/rank at the configured 0.80 dram-utilization); GLM-5.2 is plain GQA so there is one host pool per rank and GB-based --hicache-size works (the DSv4 ratio-based sizing is a DSv4-only workaround)
  • Changelog entry appended (processor is append-only); pr-link filled in the follow-up commit

Validation

  • process_changelog.py --base-ref origin/main --head-ref HEAD emits all 13 benchmark rows + the SWE-bench agentic_evals row with kv-offloading: dram, backend hicache, total-cpu-dram-gb: 2399
  • pytest utils/matrix_logic/test_validation.py utils/test_process_changelog.py: 135 passed
  • bash -n on the recipe script
  • sweep-agentic-evals job confirmed to plumb KV_OFFLOAD_BACKEND (run-sweep.yml:670)

🤖 Generated with Claude Code

Run 29651235293 showed the 1M-context corpus working set outgrowing the
HBM KV pool past conc 8 (TP8) / conc 64 (DP8): gpu_kv_cache_usage pinned
at 1.0 while the radix hit rate collapsed from a ~0.97 theoretical
ceiling to 0.04-0.06, so every post-knee turn re-prefilled its whole
history and throughput fell together with interactivity, leaving the
frontier a single dominated cliff. Spill evicted prefixes to a per-rank
pinned host pool (0.80 x node DRAM / TP) instead of recomputing them,
following the qwen3.5 b300 hicache recipe; GLM-5.2 is plain GQA so there
is one host pool per rank and GB-based --hicache-size works (the DSv4
ratio-based sizing is a DSv4-only workaround).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@github-actions

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

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

@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.

LGTM — the HiCache DRAM-offload wiring is correct and consistent with the existing qwen3.5 hicache recipe pattern. The one reported issue is a minor process nit (missing bilingual PR title/description), not a functional bug.

Extended reasoning...

Overview

This PR removes the hard KV_OFFLOADING != none guard in glm5.2_fp4_b300_sglang.sh and wires up SGLang HiCache DRAM KV offloading for both search-space arms of the GLM-5.2 NVFP4 B300 agentic recipe, plus the corresponding configs/nvidia-master.yaml search-space update and an append-only perf-changelog.yaml entry.

Security risks

None. This is benchmark harness/config code with no auth, crypto, or externally-exposed surface — it only affects internal sweep runs.

Level of scrutiny

I verified the new require_agentic_kv_offload_backend hicache gate matches the existing helper in benchmarks/benchmark_lib.sh, and that the per-rank sizing math (TOTAL_CPU_DRAM_GB / TP) is correct given that TOTAL_CPU_DRAM_GB is already utilization-adjusted upstream in utils/matrix_logic/generate_sweep_configs.py::agentic_dram_offload_gb (applies dram-utilization and the gpu_count/gpus_per_node ratio before the script ever sees it) — so the script correctly just divides by TP for the per-rank pool, matching the PR description's math (2399/8 ≈ 299 GB/rank). The new flags mirror the referenced qwen3.5-fp8-b300-sglang-agentic-hicache recipe. This is a moderate-scrutiny benchmark-recipe change (not production-critical, no user-facing or security surface), and the logic checks out against the codebase as it stands today.

Other factors

The only finding from this run is a nit about the PR title/description missing the required bilingual Chinese section per AGENTS.md — a process/compliance gap, not a code defect. Given the underlying script and config changes are correct and follow an established pattern, this alone doesn't warrant blocking approval.

Comment thread perf-changelog.yaml
Comment on lines +4953 to +4958

- config-keys:
- glm5.2-fp4-b300-sglang-agentic
description:
- "Enable DRAM KV offloading (SGLang HiCache) on all points of both arms: per-rank pinned host pool = 0.80 x node DRAM / TP, page size 64, io-backend kernel, mem-layout page_first, write policy write_through_selective"
- "Run 29651235293 showed the 1M-context corpus working set outgrowing the HBM KV pool past conc 8 (TP8) / conc 64 (DP8): gpu_kv_cache_usage pinned at 1.0 and the radix hit rate collapsed from a ~0.97 theoretical ceiling to 0.04-0.06, so every post-knee turn re-prefilled its full history and throughput fell together with interactivity"

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.

🟡 This PR's title and description are English-only, but AGENTS.md (line 7) mandates that every PR title follow the <English title> / <中文标题> format and that the body include a Chinese translation section (e.g. ## 中文说明). Please add the missing Chinese title suffix and translation section.

Extended reasoning...

AGENTS.md explicitly states: "PR and GitHub-issue titles & descriptions must be bilingual — include a Simplified Chinese version in addition to English. Title format: <English title> / <中文标题>. In the PR/issue body, follow the English content with its Chinese translation (e.g. a ## 中文说明 section mirroring the summary; ...). This applies to every PR and every issue..."

This PR's title is plain English: "Add DRAM KV offloading (HiCache) to GLM-5.2 NVFP4 B300 SGLang agentic recipe" — there is no / <中文标题> suffix. The description body contains only ## Summary and ## Validation sections, both in English, with no ## 中文说明 (or equivalent) section anywhere.

Why existing tooling doesn't catch this: the repo has a codeowner-signoff-verify.yml workflow that checks for the exact English sign-off phrase ("As a PR reviewer and CODEOWNER, I have reviewed this and have"), but that workflow verifies reviewer sign-off content, not author-side PR title/description bilingual formatting — there's no automated gate that rejects an English-only PR title or body before merge.

Step-by-step proof of the violation:

  1. Open AGENTS.md and read line 7 — it defines the exact required title format <English title> / <中文标题> and requires a Chinese translation section in the body.
  2. Read this PR's actual title: "Add DRAM KV offloading (HiCache) to GLM-5.2 NVFP4 B300 SGLang agentic recipe". Compare against the required format — there is no / <中文标题> suffix.
  3. Read this PR's description — it has ## Summary and ## Validation, both English, no Chinese section.
  4. Conclude: the required bilingual elements (title suffix + body translation section) are both absent, which is a direct, checkable violation of an explicit repo-mandated rule (not a matter of style/subjectivity).

Impact: Because this is a process/documentation compliance rule rather than something that affects the benchmark scripts, config, or changelog data added in this PR (benchmarks/single_node/agentic/glm5.2_fp4_b300_sglang.sh, configs/nvidia-master.yaml, perf-changelog.yaml all look functionally correct), it does not cause any runtime failure, incorrect benchmark behavior, or crash. It is a compliance gap against an explicit repo convention.

Fix: rename the PR title to append / <中文标题> with an idiomatic Chinese translation, and add a ## 中文说明 section to the description mirroring the ## Summary (and optionally ## Validation) content, following the translation quality bar described later in AGENTS.md (idiomatic technical Chinese, preserving model/hardware/framework names and flags in English).

@github-actions

Copy link
Copy Markdown
Contributor

Run 29678598595 OOM-killed both arms at scheduler init: GLM-5.2 runs
attention_backend=dsa (DeepSeek-sparse family; the 169.98 GB device KV
pool is replicated on every rank), so the GB-based --hicache-size of
TOTAL_CPU_DRAM_GB/TP pinned the whole 0.80-DRAM budget (8 x 299 GB =
2.4 TB) on top of 465 GB of weights on a 3 TB node. Control host
capacity through the host/device token-capacity ratio like the DSv4
recipe — but DSv4's ratio=2 default also OOMs here (2 x 170 GB x 8 =
2.7 TB; GLM-5.2's device pool is far larger than DSv4's), so use
fractional ratio 0.75 = ~128 GB/rank = ~1.0 TB total, matching the
cluster's proven host-pool envelope. Adopt DSv4's write_back / direct /
page_first_direct transfer flags. Validated on-node (b300-019,
2026-07-19): both sizing regressions reproduced, ratio 0.75 boots in
~290 s and survives a 4.2M-token overflow bench that forces eviction
through the DSA KV+INDEXER host pools.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

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

Projects

Development

Successfully merging this pull request may close these issues.

1 participant