Record corrected Frontier liveness probe

This commit is contained in:
2026-07-17 22:50:00 +08:00
parent d3be91dd58
commit 47355a9411

View File

@@ -114,6 +114,32 @@ The legacy surface runner writes an offered-rate summary assuming a fixed
arrival clocks. The materialized trace manifests are authoritative: they
record global 0.215/0.430/0.860 req/s and the matched 0.215 req/s/GPU rate.
## Corrected-adapter CPU liveness probe (2026-07-17)
One deliberately narrow CPU-only rerun tested the causal fix before launching
another surface: TP2/MNS16, the same 129-request Trace-PD input, MBT=8192,
prefix caching and chunked prefill enabled, and the original Frontier commit.
It changed only the simulator-facing prefix projection from
`ceil(ISL / 16)` to `floor(ISL / 16)`; the private real replay remained bytewise
unchanged. The materialized trace records 36,321 complete blocks (36,443 raw
runtime identities; 122 prompts with a discarded partial final block), global
arrival rate 0.430 req/s, and the required 0.215 req/s/GPU.
The run completed **129/129** requests in 105.8 CPU wall-clock seconds with no
stall. This is a direct liveness validation of the diagnosis above: the
partial-block adapter, rather than KV capacity, caused the old deadlock.
It is **not** a valid latency or selection result. Even after the repair,
Frontier reports p50 TTFT=946,973 ms, p50 TPOT=96.37 ms, p50 E2E=1,305,128 ms,
and 112.2 generated decode tokens/s. The trace supplies 460,490 output tokens
over a 298.5-s TP2 arrival horizon (about 1,543 output tokens/s), so the
simulated service rate is below the offered decode work and its queue must
grow. The corresponding real TP2/MNS16 replay has mean/p90 TPOT 14.1/16.1 ms
and mean/p90 TTFT 34,443/77,922 ms. Thus the post-fix discrepancy is a
decode-service-model / runtime-semantics question, not residual evidence from
the invalid cache metadata. The probe artifact is
`/home/admin/cpfs/wjh/aituner/simulator-tuning-latency-q30-tp-normalized-u0p01-20260717/frontier-contract-probe-v1`.
## Real result (2026-07-17)
All **36/36** `config × trial` replays completed with exit code zero. Each
@@ -145,19 +171,23 @@ claim that one configuration simultaneously optimizes all three.
## Correct conclusion and next gate
This run establishes a **harness finding**, not a Frontier capability finding:
the initial simulator-facing Trace-PD prefix contract was invalid. The valid
real surface remains a frozen ground truth, but all raw Frontier numbers above
are excluded from the research claim. We therefore retract the prior bounded
counterexample and do not yet know whether Frontier selects the correct config
on this case.
This run establishes two bounded findings, neither of which is a full Frontier
selection verdict: (1) the initial simulator-facing Trace-PD prefix contract
was invalid, and (2) its corrected TP2/MNS16 liveness probe estimates a much
smaller decode service rate than the real system. The valid real surface remains
a frozen ground truth, but all raw Frontier numbers above are excluded from the
research claim. We therefore retract the prior bounded counterexample and do
not yet know whether Frontier selects the correct config on this case.
Before a CPU-only Frontier rerun, the comparison must additionally record
these remaining alignment gaps:
1. real vLLM uses `FULL_AND_PIECEWISE` CUDA graphs, whereas the raw Frontier
command explicitly used `--decode_cuda_graph_mode none`; Frontier exposes
`full_decode_only` and `piecewise`, not the identical combined mode;
`full_decode_only` and `piecewise`, not the identical combined mode. More
importantly, Frontier chooses kernel-only predictor families whenever this
mode is non-`none`, so a graph-compatible rerun also requires corresponding
kernel-only profile coverage rather than merely changing the CLI flag;
2. Frontier used one explicit KV-block count per TP, while real vLLM's graph
capture changes the count with MNS (the mismatch is small but measurable);
3. Frontier skipped CPU-overhead modeling, and its MoE CSV has only