[amy-why-3459]

Refs #320.

Record the requester-selected four-device Ascend910B1 MiniMax-H3 Ref2VA campaign, separately from eight-device910B1 and four-logical-device910C work. The target is at least30% lower E2E latency independently at5s and15s, with full50-step BF16 dense execution and no quality loss. This draft records evidence, not an achieved optimization.

Original5s baseline: two warmups965.546s/855.532s and one measured request814.064s, all HTTP200. Worker teardown failed: four terminate/four kill actions, all exit receipts null/alive. Traces identified terminal rank-local CPU weight restoration exceeding the15s deadline. The shutdown-only candidate from vLLM-Omni#9698 subsequently completed a four-rank short-step diagnostic and the full15s baseline with all workers exit0, no forced signals. No inference speedup is attributed to shutdown changes.

Shutdown-fixed15s baseline: warmup2597.200s and one measured request2475.906s, all HTTP200. These one-server feasibility samples do not establish reliable steady-state/tail latency or paired gains. Both5s and15s repeated baseline outputs differ in decoded video/audio. Perceptual gates pass, but losslessness remains INCONCLUSIVE.

The first15s validator rejected audio15.075s versus video362/24s. The separately versioned validator-v2 follows the pinned model's exact40Hz audio-latent rounding:603/40=15.075s. It retains timestamp continuity, sample coverage, finite-output and codec-padding checks. Original failed observations remain recorded; this correction is not arbitrary tolerance expansion. Detailed provenance is in validator-v2/README.md.

All four ranks' five-step traces were exported with driver-backed offline analysis. Rank0 kernel duration sums include LaserAttention47.96s, MatMulV315.53s, All-to-All7.52s and AllGather6.18s. These potentially overlapping diagnostic durations are not exclusive E2E contributions. Actual-shape NPU screening rejected the alternative dense kernel (201.82ms Laser vs311.75ms fused score) and combined QKV (17.24ms separate vs18.78ms combined views;20.29ms contiguous). QKV outputs were exact, but slower. No model gain is qualified. The rank-local24-resident-layer screen was early rejected after its first measured pair:173.211s control versus365.884s candidate, both clean exits. The planned ABBA is explicitly incomplete. Its media gates pass, but losslessness remains INCONCLUSIVE. Prompt attention was also rejected:201.83ms Laser versus325.69ms prompt on the main captured shape, with numerical differences. The isolated canonical-loader/pinned-host-weight diagnostic was manually interrupted after a multi-minute pinned allocation delay. Initialization eventually completed and warmup began while the stop decision was being executed; no candidate request completed, so this is INCONCLUSIVE rather than a measured rejection or proven initialization failure. Cleanup finished with exit137 before the next reservation. The TP4/SP1 resident-DiT screen failed its first warmup with HTTP500: RoPE preparation ran before the first forward hook placed the DiT buffers. A candidate enters the existing component residency context before denoise preparation; its regression fails before the fix and17focused CPU tests pass afterward. The fixed four-device bringup completed both requests with HTTP200, measured173.937s for five diagnostic steps, and all four workers/server/container exiting0 without forced signals. Media coverage passes, but decoded equality is false and lossless acceptance remains INCONCLUSIVE; this is not a paired speedup result. The fix is now in the existing engine PR#9698 at a0e7b09c8, with17focused CPU tests and precommit checks passing on the integrated revision. NPU bringup used isolated revision0be853d4. The TP2xSP2 screen completed its warmup but failed its measured request during reference-video VAE encoding: retained DiT weights left insufficient capacity for another1.15GiB allocation at57.82GiB active. The clean control was166.572s; no candidate speedup denominator is produced from the failed request. All workers/server exited0 but container exit1 makes lifecycle qualification fail. The follow-up query-chunk operator probe completed cleanly; all three chunk sizes were slower and not bit-exact, so none is promoted. A replacement serial four-device reservation is queued: a BF16 fused projection/SUM operator probe first, followed by the unchanged task-queue level1/2 A/B. The original unstarted reservation was canceled and preserved, and a separate stage-offload capacity recipe is prepared but not launched. Further dense-operator screens found exact head-layout equivalence but no material speedup, while precision-matched fused/prompt/FIA alternatives remained slower and numerically different.

A further FIA v2 screen included BF16/FP16 conversions and contiguous output materialization on both arms. BNSD measured305.694ms versus205.769ms Laser; BSND314.069ms versus206.488ms. Both were finite but not exact, so neither is promoted. The four-device queue was prospectively reissued as v3 after this one-device screen; model arms and gates are unchanged, and no earlier queued model experiment had started.

Integer-nanosecond interval unions of the retained diagnostic trace show a77.23s main-denoise span,7.65–7.91s communication outside other device tasks, and0.12–0.19s with no device kernel. This narrows candidate selection; these intervals are not assumed removable, and are not an E2E speedup or universal hardware lower bound. Raw trace digests and the analysis script are included.

The four-device BF16 fused projection/SUM probe completed cleanly: attention-output35.431ms→29.126ms andFFN-output39.929ms→29.230ms, but every rank was nonexact, so it is not promoted as lossless. A separate original-Laser copy/layout screen found exact finite synthetic outputs. Through the public API, refiner9.831ms→8.529ms and main207.771ms→203.935ms include range scaling and output materialization; these are operator observations, not model gains. Local candidate8cbe1a1dd makes this legacy-FP16 preparation opt-in, with117CPU tests and precommit passing. A real-activation comparison recipe is frozen and waits for current queue A/B and CPU scoring to finish. The queue control completed at168.956s with clean lifecycle; its candidate is still running.

Final acceptance still requires baseline-repeatability adjudication, independent video/audio checks, source-attributed individual candidate measurements and direct final-combination A/B at both durations. Accepted engine changes remain intended for the single vLLM-Omni PR#9698. Earlier frozen receipts remain unchanged and historical; original logs/media are external artifacts identified by digests.

Validation:37 focused inventory/bundle tests passed; evidence validation checked471 hashes with zero errors. Repository checks do not qualify losslessness or performance. Independent review has not been performed.

AI assistance: Codex prepared campaign implementation, evidence and validation under the requester's authorization.

[Dong1017]

Scoped static review of draft #321 at 9c528c7d: the new 5s baseline receipts correctly keep latency, media repeatability, and worker teardown INCONCLUSIVE rather than claiming an optimization. One P2 evidence-consistency finding is inline: the earlier results/status.json still reads as a current queued/zero-sample status despite the newly committed four-device HTTP baseline. Please distinguish a frozen preparation snapshot from current campaign progress so human and automated readers cannot silently discard or misclassify the measured sample. I reviewed the relevant added evidence, its integrity manifest, governing #320 status, and existing discussion; did not execute tests or any model/device experiment. This does not grant campaign acceptance.

[Dong1017]

P2 · evidence status ambiguity. This added status record says execution: "queued", four_device_samples: 0, and No four-device execution result yet, while the same head now includes results/baseline-5s-complete.json with one completed 4×910B1, 50-step HTTP measurement (814.064 s) and explicit failed worker teardown. plan/preflight-integrity.json hashes this older status, so it may intentionally be a frozen preparation snapshot; without a snapshot/stage marker, readers of results/status.json as the campaign status will conclude that no run exists. Please either mark this file explicitly as a historical preflight snapshot and link a current receipt, or refresh the status plus its integrity hash to acknowledge one baseline preflight sample, while retaining INCONCLUSIVE / no speedup / failed lifecycle. This is not a request to mark the campaign PASS.