Repository navigation
Canary --prefill-decode-interval 2 on the W4AFP8 long-context r2 - #299
Conversation
r1 stays the #294 control at pdi 1; r2 runs pdi 2, and the replicas' config_variant differs only in pdi1/pdi2 so prod dashboards compare them directly. On stored long-tier traffic (gpu31, 2026-09-24, both island orders) pdi 2 cut TPOT p50 to 0.53-0.72x of pdi 1 at a paired TTFT cost of at most 2%, with 100% completion. The generator sets the interval per replica, the validator pins each replica's argv and variant (and rejects either taking the other's value), and the rollout doc gains an r2-only canary procedure and readout. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
✅ OpenCodeReview: Review failed: 0 finding(s); 3 of 3 selected item(s) failed. |
lloydmak99
left a comment
There was a problem hiding this comment.
Canary move of r2 to --prefill-decode-interval 2 while keeping r1 at 1 as a live control. The generator, generated YAML, validator, and tests are internally consistent: r1's command stays byte-identical to the pre-canary config (pdi 1), r2 correctly overrides to pdi 2, and the per-replica divergence in the command/labels/deploy fields is properly excluded from the validator's shared-runtime check, so nothing new trips. No blocking issues found.
Checks: git diff --check passed; prepare_glm53_w4afp8_long_context.py --check exited 0 (generated file not stale); GeneratedFileTest 4/4 passed; grep confirmed r1=pdi1 / r2=pdi2 anchors and 3×pdi1 + 3×pdi2 config_variant labels; worktree clean. The Ruby validator and ValidatorContractTest couldn't run (no ruby in this environment) and were verified by inspection — author reports 10/10 pass under Ruby 3.3.
Brings in #299, #300, #302 and #307. Conflicts in the W4AFP8 long-context generator, validator and test are resolved by taking main's per-replica logic (both replicas on the v2 QSPLIT image at chunk 8192, r1 pdi 1 / r2 pdi 2, r2's own environment list derived from the anchor) and re-applying this branch's tracing additions on top: --enable-trace and the OTLP endpoint on both replicas, SGLANG_TRACE_ASYNC=1 / SGLANG_TRACE_LEVEL=0 in the anchor environment (and therefore in r2's derived list), the -trace-async-armed variant suffix on both variants, and the glm53-trace-control job. The compose file is regenerated, not hand-merged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Summary
Runs gpu02's long-context r2 at
--prefill-decode-interval 2(two decode steps between prefill chunks). r1 stays exactly #294 at pdi 1 and serves as a live control. The two replicas'config_variantdiffers only inpdi1/pdi2, so prod dashboards can compare them directly.Why: under long prefills, W4AFP8's larger KV pool keeps about 3 sequences decoding while the next ~700K-token prefill runs. At pdi 1, each of their decode steps waits behind a prefill chunk. That is most of the long tier's loaded-TPOT penalty.
Evidence (gpu31, stored long-tier traffic, 2026-09-24)
pdi 2 vs pdi 1, paired, both island orders: TPOT p50 0.53–0.72×, paired TTFT ≤ 1.02×, 100% completion.
Ship qualification of the full candidate (pdi 2 + the DSA indexer split from the companion PR + chunk 16384) vs GLM-5.3 Flash: W4AFP8 + HiCache long-context file for gpu02 (both replicas = campaign-2 L2) #294, on the same GPUs:
Both arms: 0 restarts, 0 OOMs, 0 fatal log lines. Quality at the noise floor (GSM8K, MMLU, passkey, teacher-forced agreement).
Write-up: Notion
Changes
config_variant.compose/downthencompose/up, a dry-run gate that must plan exactly r2, the r1-vs-r2 readout over 24 h+, and rollback.Validation
prepare_glm53_w4afp8_long_context.py --checkpasses.test_glm53_w4afp8_long_context.py: 10/10 pass under Ruby 3.3. Local Ruby 2.6 lacksfilter_map.scripts/validate_*.rbpass.Notes
🤖 Generated with Claude Code