2.0 KiB
Action-aware constraint pilot v1 amendment
Status: FROZEN AFTER V0 OPERATIONAL STOP AND BEFORE V1 GPU RUNS.
Date: 2026-07-14 (Asia/Singapore).
The complete claim, workload, baselines, metrics, action matrix, analysis gates, and data-validity requirements remain those in the v0 protocol. This amendment changes only the token-bound source severity and adds an operational burn-in gate.
Why v0 produced no comparative evidence
The first v0 session used MNS=64 and MBBT=256. During the 510-request, 60-second burn-in, the client had run for 197 seconds and the engine still held 64 requests: 13 running and 51 waiting. The last step scheduled exactly 256 tokens, KV usage was 0.01151, and there were zero preemptions. No measured run or target configuration had started.
The session was stopped and cleanly released all GPUs after consuming 0.3859868995 H20-hours. This is evidence that MBBT=256 is a real token-budget bottleneck, but it is not an admissible source for the 2.125 requests/s/GPU comparison because it cannot sustain the offered load. V0 contributes no tuning label and none of its runtime data is reused by V1.
Authoritative failure artifact:
/home/admin/cpfs/wjh/action-aware-constraint-v0-20260714/operational-stop-v0.json.
V1 changes
b_base: MNS=64, MBBT 2048 instead of 256.b_mns: MNS=128, MBBT 2048 instead of 256.- The B-family MBBT action is therefore 2048 -> 8192.
- All five configurations and all three repetitions run fresh under a new V1 run root.
- Before any measured run, every config's 510-request/60-second burn-in must drain in at most 90 seconds. A slower config is an operational failure; the controller stops before comparative analysis.
- V1 incremental hard cap is 7.6140131005 H20-hours so that V0 plus V1 remains within the original global 8.0 H20-hour cap.
The V0 protocol's crossed-response and source-only binding gates are unchanged. In particular, V1 still requires three-of-three action-family predictions in both regimes and a different real winner in Regime A versus Regime B.