ProprietaryLegal's picture
PLI Labs public snapshot 2026-10-28 (history squashed)
e1acc15
|
Raw History Blame Contribute Delete
10.8 kB

PP4 on WIN2 (R-PP4) — fairer, deeper PP4 measurement and the production comparison

NDM 2026-10-27: "Fairer win rule is essential", "Do better deeper testing and measuring", "go window after window". Method: Fable review row 2 ("OFF/ON/OFF, pooled accepted-per-round … and pooled ms/round; short and 32K ×3 each; keep the #61161 RNG test as a gate") and WIN2.md. Code: pp4_measure_v2.py, pp4_window.py --measure-v2, pp4_rng_gate.py, PP4-production-policy.env, pp4_v2_stage.sh.

Two registered modes (one OFF/ON/OFF HOLD each)

Mode Starts Question
controlled s1-A / s2-B / s3-A fixed5 greedy drafts vs fixed5 sampled drafts on the PP4 runtime (Round5/6's question, re-decided)
production-policy s1-P / s2-B / s3-P does the PP4 promotion configuration (B = fixed5 sampled, PP4-sampled.env) beat production's own policy (adaptive K, [[1,2,5],[3,4,4]], greedy drafts)?

Role P (PP4-production-policy.env) is PP4-sampled.env's greedy role A with production's policy left in place: the five fixed-policy tokens are removed and SPEC_OVERRIDE is unset, so serve_exp.sh applies production's schedule and VLLM_DSV41_ADAPTIVE_K=1 / AK_* exactly as production serve.sh does. runtime() checks the P container env equals production's plus only the PP4 worker identities, the greedy switch and the round-trace mount, and that its speculative config is production's. P is production policy on the PP4 runtime (PP4 K2 worker + verifier overlay), not the production binary; the exact-binary comparison is the promotion window's G6.

Measurement

  • Decision cells short-b1 and 32k-b1 (B1, T=1, top_p=1, forced 512 tokens, fresh cache salt per stream). 32k-b4 is dropped so three repeats fit the HOLD.
  • Per start and cell: six waves = three repeats × two waves (one per public source family, opinions/filings), seed 42+wave matched across starts. Prompt order per family uses existing frozen cuts only (ORDERS).
  • A repeat pools its two waves' server counters (pp4_metrics.pool): rate = (rounds + accepted) / decode seconds, accepted/round, ms/round; plus mean TTFT and client decode tok/s.
  • Greedy (pp4-r14 1.1-nat; Round15 near-tie locator) on s2-B, and on s1-P in production-policy mode.

Decision (win2-v1, paired by repeat)

Control = mean of the two bracketing starts in repeat r; candidate = s2-B in repeat r.

Series per decision cell Role
pooled_rate_tps primary (WIN: point > 2 % and the 95 % paired-t interval excludes 0)
accepted_per_round, decode_tps guards (can only cause LOSS: worse than control spread in ≥ 2 of 3 repeats)
ms_per_round, ttft_s reported with their own win2-v1 verdict; never decide

WIN2.md prefers ms/round as the primary for decode cells. PP4 is the change that deliberately spends ms per round (+0.31 ms MEASURED) to buy accepted tokens (+6.9 % MEASURED offline), and the production-policy mode compares adaptive depths 2..5 with fixed 5, so ms/round alone can never show PP4's effect and would read its cost as a loss. The rate is (1 + accepted/round) / ms-per-round, so it charges that cost in full. decision.checklist_literal records what ms/round-primary would have said. Status turns INCONCLUSIVE when the starts ran at different GPU clock caps (parsed from each start's clock cap N MHz lines), at a cap other than production's configured one (each node's /etc/environment GPU_CLOCK_CAP, else dsv41.env's 2150 default; 2300 since CLOCK-PERSIST), or THERMAL-WATCH dialled the clock back inside the HOLD: the control is always a same-clock control. The archive's day-to-day spread for the primary (same cell, max_tokens 512, production commit and clock cap only; WIN2-R2 rows carry clock_cap_mhz per start from that start's own log, both Sparks agreeing) is reported next to the in-window OFF/OFF spread; the 2 % bar is never raised silently.

Gates before any host contact

  1. --qualification + --qualified-commit: the QUALIFIED admission receipt of the qualified commit, carried to HEAD only if every file outside the measurement layer is byte-identical (CARRIED_FILES/CARRIED_PREFIXES; that includes pp4_cells.py and PP4-sampled.env) and the runner's remote/runtime units are AST-identical (CARRIED_UNITS). The v2 budget must fit: total ≤ 85 min and measurement end ≤ 73 min.
  2. --rng-gate: a PASS pp4_rng_gate receipt at HEAD (AUD1's six #61161 tests + four PP4 sampled-q multi-round tests, CPU interpreter, ~3 min) whose generated PP4 kernel sha equals the admission's prepared verifier. Every start's speculative config must be standard verification (standard_spec).

ESTIMATED HOLD (registered round6 inputs; not measured v2 blocks)

Mode 333 s pair reserve measurement ends 600 s dry bound
controlled 80.1 min 68.1 min 84.5 min
production-policy 80.8 min 68.8 min 85.2 min (refuses; fits while the measured pair reserve ≤ 588 s)

Chain mode (WIN2-R2 chain.py)

  • Preflight. chain.preflight(serving, hold, placeholders_present=…). The placeholders are probed on both Sparks over an ordinary ssh (default tmux socket) only while the marker is present.
  • Chained start. Production comes from chain.production_snapshot() (sha-checked against the marker) unless --chain-production names a capture; commit/tag are checked; both Sparks are proved quiet; the HOLD opens with allow_unreachable=chain.allow_unreachable(mode).
  • End. chain.end_action(stop, hold):
    • chained (measurement window, no stop, not last): chain_close — default-socket hold placeholders started on both Sparks before the first fence (PP4's own placeholder lives on its hold scope's private tmux socket and dies with the fence; the shared chain.CHAINED_CLOSE cannot see it from inside a scope), then fences, pair close, experiment stop, quiet proof, production-DOWN proof, placeholder proof, scoped HOLD stash + commit-close, marker. Summary chain: CHAINED, restore status CHAINED: production left down.
    • restore: the strict W8 restore + watch. After the restore that ends a chain the runner takes the default-socket placeholders down (window.sh close's job, which cannot reach them from PP4's scope) and clears the marker only on watch PASS.
    • abort (marker present and no HOLD of ours, e.g. a chained start that failed before its HOLD): chain.abort, whose summary is the window's restore; decision REJECT.
    • Admission and pair-only windows never chain (their receipts need the restore and watch).
  • Gate the next window with chain_prev_ok.sh (it aborts the chain itself on any refusal while the marker is present).
  • Run the PP4 test suites with DSV41_CHAIN_MARKER pointing at a scratch path so a live chain cannot change them.

Coordinator launch (after an admission at the qualified commit is QUALIFIED)

C=/opt/dsv41/campaigns/DSV41-OFFLOAD
H=<offload/pp4-win2 HEAD, full sha>; Q=<admitted commit, e.g. 85b0d96ddf5bd3c2870eae7af092d679b00a6c26>
A=<QUALIFIED admission window dir at $Q>
cd <clean worktree at $H>
# 1. #61161 gate (CPU only, once per commit)
PYTHONPATH=$PWD:$PWD/offload/dspark CUDA_VISIBLE_DEVICES= TMPDIR=$C/scratch/p4v2 /home/operator/miniconda3/bin/python3 \
  -m offload.launch.windows.pp4_rng_gate --execute --out $C/scratch/PP4-coord/rng-gate-${H:0:12}.json --basetemp $C/scratch/p4v2/rng
# 2. stage the sparkhead checkout at $H (between windows; copies $Q's prepared verifier)
WINDOW_COORDINATOR=Deepseek/coordinator bash offload/launch/windows/pp4_v2_stage.sh --execute $H $Q
# 3. dry plan, then the window (production-policy first; controlled may follow in the chain)
bash offload/launch/windows/pp4_window.sh --measure-v2 production-policy
bash offload/launch/windows/chain_prev_ok.sh "$PREV_TMUX" "$PREV_FILE"
WINDOW_COORDINATOR=Deepseek/coordinator WINDOW_CHAIN=1 bash offload/launch/windows/pp4_window.sh --execute \
  --measure-v2 production-policy --qualification "$A/admission-receipt.json" --qualified-commit $Q \
  --rng-gate $C/scratch/PP4-coord/rng-gate-${H:0:12}.json --expected-experiment-commit $H \
  --remote-repo dsv41-deploy-pp4-v2-${H:0:12} --worker-tree /opt/dsv41/x86host-data/pp4/admission-${Q:0:12}/repo \
  --worker-commit $Q --worker-identity be2c1436fa9f9e66b398e1b1da2e140e6fddc82a11939e2ac4240a0ca79543bd \
  --worker-markov-identity 0b6e71e638abd5abce2db433965bb5ff523cbbe92ed7ae54324a50ccaeffa19a \
  --data-dir /opt/dsv41/data/bench-data --out $C/PP4-v2-prodpolicy-W-$(date -u +%Y%m%dT%H%M%SZ)

Before any admission: the API rehearsal against production (queue line, between windows)

PP4-90f admission cmd/0132 stopped on HTTP 400: the R16 terminator probe forced its token with logit_bias, which the image refuses whenever speculative decoding is on (image vllm/sampling_params.py:1103-1116 _validate_spec_decode, from SamplingParams.verify :850 via v1/engine/input_processor.py:128; 400 at entrypoints/serve/exception_handling/error_response.py:41-44). Production runs the same check, so the probe, not the candidate, was wrong; it now forces with allowed_token_ids. Every admission HTTP error now logs and carries the server's body. Rehearse every admission API probe against production (tiny: ≤ 8 generated tokens each, priority 10, no idle wait; one control request replays the R16 probe and must come back 400), and queue an admission only on PASS:

cd <clean worktree at the admission commit>
WINDOW_COORDINATOR=Deepseek/coordinator PYTHONPATH=$PWD:$PWD/offload/dspark CUDA_VISIBLE_DEVICES= \
  /home/operator/miniconda3/bin/python3 -m offload.launch.windows.pp4_api_rehearsal --execute \
  --url http://HEAD_IP:8000 --eos 1 --out $C/PP4-API-REHEARSAL-$(date -u +%Y%m%dT%H%M%SZ)

Exit 0 = PASS. rehearsal.json holds the verdict, cause_confirmed, the reading (4xx = probe wrong for this image; transport/5xx = no answer, rerun) and every probe's status, error body, finish/stop reason, usage and hashes; responses.jsonl (0600) holds the replies. --eos 1 is the model's EOS from PP4-90f admission-eos-source.json.

Use --measure-v2 controlled and an …-controlled-W-… out dir for the other mode; add WINDOW_CHAIN_LAST=1 on the chain's last window. Every v2 window appends its finished control starts to $C/control-archive.jsonl (cells pp4rt-fixed5-greedy-* / pp4rt-production-policy-*, max_tokens 512).

Promotion

PP4-PROMOTE-GATE-V2.md: the LOSS semantics already match offload/pp4-promote; its measurement_gate needs four changes to accept an R-PP4 measurement (metric set, carried-qualification binding, production-policy mode only, new recorded fields).