[Campaign] MiniMax-H3 Ref2VA lossless optimization on 4x910B1

Current state: Draft #321 (14de17a3) publishes author-reported baseline evidence: the original 5 s measurement was 814.064 s with failed worker teardown; the shutdown-fixed full 50-step 15 s baseline now reports a 2597.200 s warmup and one 2475.906 s measured request, with all four workers exiting 0 and no forced signals. These feasibility samples do not establish paired gains or steady-state/tail performance. Repeated decoded video/audio differs at both durations, so losslessness remains INCONCLUSIVE. The author separately versioned validator-v2 to interpret model audio-latent rounding and retained the original failed observations; this synchronization has not independently verified that validator behavior or the hardware results. The author now reports negative actual-shape dense-attention and combined-QKV screens, and an early-rejected resident-layer screen (173.211 s control versus 365.884 s candidate; planned ABBA incomplete). Prompt attention was also rejected; the author reports that the isolated canonical-loader/pinned-host-weight diagnostic was interrupted after a pinned-allocation delay. Initialization completed and warmup began during stopping, but no candidate request completed; its verdict is INCONCLUSIVE, not a measured rejection or proven initialization failure. Cleanup reportedly ended with exit 137. The author reports that the TP4/SP1 screen failed its first warmup with HTTP 500 because RoPE preparation preceded DiT buffer placement. The residency correction reportedly completed four-device bringup: 173.937 s for five diagnostic steps, HTTP 200 and clean exits, but decoded equality remains false and losslessness INCONCLUSIVE; this is not a paired speedup. A subsequent TP2/SP2 measured request failed with VAE allocation exhaustion; no candidate gain is inferred, and container exit 1 failed lifecycle qualification. Further query-chunk/FIA operator screens were rejected as slower and non-exact. The PR narrative reports a 168.956 s serial queue control with clean lifecycle while the candidate remains running. The latest review reports that this figure has no committed receipt at this head; it remains unverified author commentary, not qualified control evidence or a paired result. A fused projection/SUM operator probe was faster but nonexact on every rank and is not promoted as lossless. A separate copy/layout operator screen was exact on synthetic inputs, with real-activation qualification pending; these are not model gains. Diagnostic trace intervals are not removable-time or E2E gain claims. These are author-reported observations, not independently reproduced results. Current-head software smoke checks passed; they do not establish quality, speedup or campaign acceptance. The eight-device 910B1 and four-logical-device 910C campaigns remain separate.
Reported target update (pending acceptance-record reconciliation): The author records requester direction for at least 30% lower E2E latency separately at 5 s and 15 s in the pinned target record. This is an author-reported target, not an achieved result or a scope decision made by this synchronization; the existing requester/author retain its reconciliation. Original acceptance text and INCONCLUSIVE evidence remain unchanged.
Reported gate revision (pending acceptance-record reconciliation): The author-authored elementwise-v2 record requires exact model-output tensors plus decoded audio/video equality and says baseline nondeterminism does not excuse candidate mismatch. This differs from the original acceptance paragraph below. The latest review requests acceptance-owner reconciliation, provenance and freeze evidence; no new public requester decision was found in this synchronization. This note records the discrepancy without adopting a new gate, rewriting historical requirements or establishing efficacy.
Next action: The existing campaign author retains bringup and evidence delivery. Reconcile the updated review questions against the published bundle: the reviewer reports a contradictory worker-lifecycle summary, control-revision provenance gaps, historical status/freeze ambiguity, and missing public scope/target/stop-condition decisions. That review credits delivered bundle/validator evidence but does not establish hardware efficacy or requester acceptance; this synchronization has not independently reproduced its checks. Final acceptance remains with the requester.

Scope and authorization

The requester explicitly selected four local Ascend 910B1 devices (64 GiB each) for lossless MiniMax-H3 Ref2VA optimization. This is a distinct hardware contract from the eight-device #293 and four-logical-device 910C #297 campaigns. Codex acts as the implementation agent under the requester's instruction; final acceptance remains with the requester. No closure of other campaigns is requested.

The user needs lower delivered-media E2E latency at unchanged model quality on four devices. Work will use baseline profiling, individual source-attributed candidates and a directly measured final combination. Consolidate accepted engine changes in the existing vLLM-Omni PR vllm-project/vllm-omni#9698 where compatible; do not overwrite concurrent work. Reusable evidence belongs here, the canonical successor of OmniRSI.

Initial RunSpec

Original source baseline: c7f56f0155953c7d4a77276a2f4fcbd844ab0da2, isolated checkout.
Environment image: sha256:7fc6c73bd19a6ef4ee8d6048009972234796a1fc1bd3067168a425343cc476f7 (same environment lineage as [Campaign] MiniMax-H3 Ref2VA Ascend NPU latency optimization with video/audio quality gates #293; current runtime identity must be recorded).
Original BF16 Ref2VA weights, dense LaserAttention, 50 steps. No approximate caches/reference-KV reuse, quantization, sparsity, distillation or reduced steps.
USP4/ring1, text-encoder TP4, VAE tile4 and DLO; concurrency one.
1344x768, 24 FPS, seed 0, 5s and 15s workloads. Same reference inputs as [Campaign] MiniMax-H3 Ref2VA Ascend NPU latency optimization with video/audio quality gates #293; hashes retained in run receipts. Additional seeds/reference cases required before broader generalization.
First preflight: 5s only, two warmups and one measured request, original lifecycle. This establishes feasibility/repeatability diagnostics only, not a speedup. Timeout/failed outputs and actual worker exits are retained.
Every NPU workload uses npu run; paired comparisons will share one fixed four-device allocation. No results from another device count qualify this campaign.

Acceptance plan

Freeze candidate comparisons and validators before search. Record raw HTTP upload-to-full-response E2E, successful/failed requests, output coverage, memory and actual worker exits. Keep startup, warmup and traced stage/operator times separate from clean timing. Report each duration separately; do not estimate p95 from a few averages or add isolated percentage gains.

For losslessness, exact decoded video/audio equality is sufficient but perceptual thresholds alone are not. Establish control repeatability first; nonidentical candidates remain INCONCLUSIVE unless a stronger numerical-equivalence argument and independent automated checks establish preservation. Reuse the repaired duration/scorer identity checks from #318 and upstream media metrics as diagnostics, not permission for quality degradation. No audio-quality regression is accepted.

After bringup, freeze matched independent-server AB/BA repetitions for individual candidates and direct original-baseline versus final-combination qualification at both durations. Every accepted optimization needs its own source, enabled dispatch, quality result and measured effect. Missing quality or lifecycle evidence prevents PASS. No global-optimality claim: report the best validated configuration in the tested search space.

Candidate sources, not qualified four-device results:

Existing weight placement/transfer configuration: [diffusion][feature] Add component-selective offload policies vllm-project/vllm-omni#5929 and #5764.
Combined QKV communication proposal: [Perf] Combine QKV for Ulysses a2a for select models vllm-project/vllm-omni#4150; the local H3 adaptation and CPU checks from [Campaign] MiniMax-H3 Ref2VA Ascend NPU latency optimization with video/audio quality gates #293 require independent four-device NPU qualification.
Existing lifecycle fixes: [Hardware][Ascend] Improve MiniMax-H3 Ref2VA execution and offload lifecycle vllm-project/vllm-omni#9698; shutdown correctness is separate from inference speedup.

Status: INCONCLUSIVE, four-device preflight prepared; no new execution result or speedup.

Agent-assisted-by: Codex

Intent: the reporter proposes a new acceptance campaign that lowers delivered-media E2E latency for MiniMax-H3 Ref2VA on four local Ascend 910B1 (64 GiB) devices while keeping exact decoded video/audio quality, across 5 s and 15 s HTTP workloads, and states no speedup result yet. Verdict: needs information / human decision required — the charter does not yet meet this repository's acceptance-campaign prerequisites (no campaign ID or evidence path, no candidate revision, no frozen gate/validator identity, no in-repo preflight artifacts), and it asks for NPU measurement, not a code change in InferRSI. The Issue contains no sentence that authorizes a code change, so no development task is appropriate; the findings below are the gaps to close before it can be reviewed as an acceptance campaign. Labels: kind:acceptance, area:workbench (same campaign/acceptance line as #293 and #297; no priority label because this repository allows priority only with status:proposed or status:accepted).

Missing acceptance prerequisites: campaign ID, evidence path, candidate revision, frozen gates

Where: .github/ISSUE_TEMPLATE/campaign-acceptance.yml:13 (campaign_id), :29 (candidate_sha), :51 (gates), :62 (evidence_paths) are all marked required; docs/contributing.md:94-107 and AGENTS.md:64-66 ("Freeze gates before search", RunSpec snapshot) restate the rule.
Problem: the body gives the baseline SHA and image digest, but no campaign ID, no candidate revision, no gate checklist and no evidence path. It explicitly defers two of them ("Freeze candidate comparisons and validators before search"). Under docs/contributing.md:124-129, a comparison without that freeze is INCONCLUSIVE by definition, so this Issue can never reach a verdict as written.
Impact: reviewers cannot tell which evidence tree belongs to this hardware contract, and no candidate can be qualified against a pre-registered gate.
Fix: add a campaign ID plus evidence/<campaign-id>/{plan,results,patch,validator}/, the candidate revision (or an explicit "unselected" freeze record), the gate checklist with validator file hashes, and the downstream citation blurb. Do not reuse h3-ref2va-lossless-293, which draft PR H3 Ref2VA lossless follow-up: validate audio coverage and scorer identity #318 already occupies for the eight-device lossless follow-up.

The claimed "four-device preflight prepared" has no artifact in this repository

Where: evidence/ and tools/evidence_inventory.json; evidence/README.md:1-24 defines the required per-campaign layout.
Problem: the status line asserts a prepared four-device preflight, but no bundle exists. I ran python tools/validate_evidence.py: exit 0 with errors: [] and 425 hashed files, and the bundle list contains only h3-ref2va-ascend-293 for H3/910B1 (eight devices). No receipt, RunSpec or worker-exit record for a four-device 910B1 allocation is committed or linked.
Impact: the only current claim in the Issue (preflight prepared) is unverifiable, and the campaign has no in-repository deliverable even though the engine changes are intentionally routed to vLLM-Omni PR #9698.
Fix: commit the preflight receipts (RunSpec, npu run allocation identity, startup/warmup/measured timings, worker exits) under the new campaign path, register it in tools/evidence_inventory.json (docs/contributing.md:156-159 requires explicit classification), or drop the status claim until they exist.

The lossless gate depends on an unpinned draft validator; the committed validator cannot detect truncated audio

Where: evidence/h3-ref2va-ascend-293/validator/compare.py:24-54; dependency on draft PR H3 Ref2VA lossless follow-up: validate audio coverage and scorer identity #318 (open, head e59b39a3).
Problem: the Issue requires exact decoded equality and cites "the repaired duration/scorer identity checks from H3 Ref2VA lossless follow-up: validate audio coverage and scorer identity #318", but never pins that validator's identity. The validator committed to this tree checks width, height, fps, frame count, sample rate and channel count only — a truncated audio track of matching sample rate and channels passes probe(). The audio-duration/sample-count/continuity checks and exact-equality reporting exist only in PR H3 Ref2VA lossless follow-up: validate audio coverage and scorer identity #318's evidence/h3-ref2va-lossless-293/validator/compare.py and validator/gates.json, which are unmerged and may still change.
Impact: if the four-device runs reuse the committed validator, a quality-degraded (truncated) candidate can satisfy the media contract, directly contradicting the Issue's no-degradation acceptance.
Fix: freeze H3 Ref2VA lossless follow-up: validate audio coverage and scorer identity #318's validator bytes by path and SHA-256 (or merge H3 Ref2VA lossless follow-up: validate audio coverage and scorer identity #318 first) in this campaign's plan/, and record which gate file each duration uses.

Hardware-scope authorization, ownership and stop condition are asserted but not recorded

Where: docs/contributing.md:97 (campaign name, owner, goal/non-goals, stop condition), docs/agent-collaboration.md (material scope changes return to the authorized owner); contrast the scope-record comment linked from [Campaign] MiniMax-H3 Ref2VA Ascend NPU latency optimization with video/audio quality gates #293.
Problem: [Campaign] MiniMax-H3 Ref2VA lossless optimization on 4x910B1 #320 declares a new hardware contract (four physical 910B1 devices instead of [Campaign] MiniMax-H3 Ref2VA Ascend NPU latency optimization with video/audio quality gates #293's eight, distinct from [Campaign] MiniMax-H3 Ref2VA on 910C: 4 logical devices, 5s/15s × lossless/lossy optimization #297's four logical 910C) "under the requester's instruction", but links no authorization comment or acceptance record, names no accountable owner or acceptance owner beyond "final acceptance remains with the requester", and states no stop condition or budget. It also says "Codex acts as the implementation agent", which describes a role rather than authorizing work.
Impact: nobody can verify who accepted this fourth campaign or when it should stop, and the record cannot distinguish an accepted campaign from an agent-proposed one.
Fix: link the recorded scope acceptance for the four-device contract, name the accountable and acceptance owners, and add the stop condition, decision-needed and next-action lines used by [Campaign] MiniMax-H3 Ref2VA Ascend NPU latency optimization with video/audio quality gates #293/[Campaign] MiniMax-H3 Ref2VA on 910C: 4 logical devices, 5s/15s × lossless/lossy optimization #297.

Search space and prior work: no transferable gain, and most candidates are non-compute

Where: Related work verified through the GitHub API — [Campaign] MiniMax-H3 Ref2VA Ascend NPU latency optimization with video/audio quality gates #293 (merged PR Qualify MiniMax-H3 Ref2VA five-second Ascend optimization #294) is a PASS only for lossy caching on eight 910B1 devices at 5 s; [Campaign] MiniMax-H3 Ref2VA on 910C: 4 logical devices, 5s/15s × lossless/lossy optimization #297's four-logical-910C checkpoint (draft PR evidence: track H3 Ref2VA on four logical Ascend 910C devices #317) reports 1.57% lower complete-HTTP latency; H3 Ref2VA lossless follow-up: validate audio coverage and scorer identity #318 is the open eight-device lossless validator draft.
Problem: the Issue excludes caches, reference-KV reuse, quantization, sparsity, distillation and reduced steps, and its three candidate families are weight placement/transfer, combined QKV communication and lifecycle fixes. [Campaign] MiniMax-H3 Ref2VA on 910C: 4 logical devices, 5s/15s × lossless/lossy optimization #297's four-device measurement suggests limited headroom in that direction, and [Campaign] MiniMax-H3 Ref2VA lossless optimization on 4x910B1 #320 itself reports no new number.
Impact: expectations should stay at "best validated configuration in the tested space"; no cross-device or cross-policy gain may be cited from [Campaign] MiniMax-H3 Ref2VA Ascend NPU latency optimization with video/audio quality gates #293, Qualify MiniMax-H3 Ref2VA five-second Ascend optimization #294, [Campaign] MiniMax-H3 Ref2VA on 910C: 4 logical devices, 5s/15s × lossless/lossy optimization #297 or evidence: track H3 Ref2VA on four logical Ascend 910C devices #317.
Fix: none required for correctness — keep the cross-campaign non-transferability statement and name the rejected/expected ceilings explicitly in the plan.

Reviewed commit: 2baebf6
Coverage: Snapshot: 2637 files, 42149780 bytes; skipped 0 entries; Initial model context: 28 files; other accepted files available through tools; Git workspace contains a fixed snapshot, not full upstream history

Intent: the author wants a four-device Ascend 910B1 campaign that lowers delivered-media E2E latency for MiniMax-H3 Ref2VA (target 30% at 5 s and 15 s) with unchanged quality, and the edited Issue text now recounts a large set of author-reported baseline, negative-screen, lifecycle and interval results published in draft PR #321 rather than claiming a speedup. I checked that draft at b54dc33: python tools/validate_evidence.py exits 0 with 466 hashes and no errors (matching the declared inventory count), tests/test_evidence_inventory.py passes 17/17, all 41 bundle integrity entries match their files, the quoted 173.211 s/365.884 s, 814.064 s, 2597.200 s/2475.906 s and 173.937 s samples match the receipts, and the cited 40 Hz audio-latent rounding exists at public vllm-omni PR #9698 head a0e7b09c. Earlier gaps on campaign ID, evidence tree, hashed validator identity and truncation coverage are therefore addressed by the draft bundle; the remaining gaps are listed below. Verdict: needs information / human decision required. The Issue already carries kind:acceptance and area:workbench, and no status decision is recorded, so no additional or priority label is inferable.

The bundle's TP2/SP2 failure record contradicts itself on worker lifecycle

Where: evidence/h3-ref2va-4x910b1-320/results/hybrid-oom-query-result.json:274 versus the same file's lifecycle block at :237-260 (PR Record MiniMax-H3 four-device 910B1 lossless campaign #321).
Problem: the raw lifecycle block records container_exit: 1, forced_signals: 4 and worker exit_code: -15 (SIGTERM) for all four ranks, while the adjacent failure_analysis.lifecycle string says "All workers and server exited zero without forced signals, but container exit1 means full lifecycle qualification fails". The draft PR description repeats the contradictory wording ("All workers/server exited0 but container exit1").
Conditions: any reader or future lifecycle-qualification pass that uses the summary string instead of the raw block.
Impact: lifecycle correctness is one of this campaign's acceptance gates, and the record currently understates a forced teardown (four SIGTERMs, workers -15) as clean exits. The Issue text only says "container exit 1 failed lifecycle qualification", so the defect lives in the bundle and PR text, not the status block.
Fix: correct the summary string and PR text to "server exit 0, container exit 1, four workers SIGTERM (-15) after 4 forced signals", keep the raw block unchanged, and drive the lifecycle verdict from the raw block.

Requester scope, the 30% target and the stop condition still have no recorded decision

Where: .github/ISSUE_TEMPLATE/campaign-acceptance.yml:13,29,51,62 (required campaign ID, candidate SHA, gates, evidence paths); docs/contributing.md:97-100 (owner, goal/non-goals, stop condition, pinned revisions, frozen gates); the target record now linked from the Issue, evidence/h3-ref2va-4x910b1-320/plan/acceptance-30pct.json (PR Record MiniMax-H3 four-device 910B1 lossless campaign #321); the Issue's "Scope and authorization" section.
Problem: the four-device hardware contract, the "at least 30% lower E2E" gate and "Codex acts as the implementation agent" are all stated as requester direction, but [Campaign] MiniMax-H3 Ref2VA lossless optimization on 4x910B1 #320 has exactly one comment (the earlier bot review) and no timeline entry where the requester accepts either the hardware contract or the numeric target. No accountable owner, goal-acceptance owner or campaign stop condition is named — "the requester" and "the existing campaign author" are roles; the five-hour budget in plan/README.md is a per-reservation ceiling, not a stop condition.
Impact: the record still cannot distinguish an accepted campaign from one an agent proposed, and a numeric gate authored inside the PR can later be cited as requester-set. This is the one earlier-review gap that the new draft genuinely does not close.
Fix: the requester posts one scope/target acceptance comment linking [Campaign] MiniMax-H3 Ref2VA lossless optimization on 4x910B1 #320 and plan/acceptance-30pct.json, names the accountable and acceptance owners, and states the stop condition; then the Issue records it. A bot or the author must not self-record this decision.

The control revision behind the 15 s baseline and every four-device screen cannot be inspected

Where: evidence/h3-ref2va-4x910b1-320/results/baseline15-complete.json:3, validator-v2/contract-revision.json:3, results/queue-v3-prospective-revision.json:11, results/hybrid-oom-query-result.json:5,139 all use source revision ce216014…; plan/runspec.json:4 still pins only c7f56f0155953c7d4a77276a2f4fcbd844ab0da2; patch/ contains only the TP4 placement diff (PR Record MiniMax-H3 four-device 910B1 lossless campaign #321).
Problem: ce216014adb4c037dc15b3d49623e493ca3d3ac3 is not in the public vllm-omni repository (commit API returns 200 for PR #9698 head a0e7b09c83d0… and 422 for ce216014…), and the bundle neither says where that revision lives nor records how it relates to the pinned baseline or to the PR head. plan/runspec.json therefore implies the whole campaign runs on c7f56f01, while the 15 s denominator and all four-device screens actually run on ce216014…. The audio-latent contract is verifiable at the public head (I confirmed time_request.py:34-36 and pipeline_minimax_h3.py:3217 at a0e7b09c), but the record cites the unreachable revision instead.
Impact: the 15 s baseline denominator and matched baseline-vs-candidate repetitions cannot be audited or reproduced from the repository, which is exactly what final acceptance needs at both durations (docs/contributing.md:98); the lifecycle fix inside that revision is also not declared as a non-speedup change there.
Fix: record a per-duration baseline revision in plan/runspec.json, and either re-attribute the 15 s control to a reachable public head or add the exact diff/branch that produces ce216014… under patch/, citing the public head for the audio-duration contract.

The frozen gate record says no validator existed before search, but search had already run

Where: evidence/h3-ref2va-4x910b1-320/validator/README.md:5 — "No candidate validator is frozen yet and no candidate search has begun" — hash-pinned by plan/preflight-integrity.json:7; the actual gate lives in validator-v2/ and is hashed only under results/baseline15-profile-integrity.json:5-11; the Issue states the validator was versioned after the 15 s decode failed.
Problem: AGENTS.md:64 and docs/contributing.md:100 require the gate checklist and validator/input hashes to be frozen in plan/ before candidate experiments. Here the campaign's pre-search freeze record says no validator existed, then resident24, TP4/TP2, FIA v2 and query-chunk screens were measured, and the media gate was versioned afterwards. The contract revision itself is technically sound (the 40 Hz rounding is real and pinned baseline files are retained), but changing the audio-duration acceptance contract after observing a failure is a decision for the acceptance owner, not only an author README rationale.
Impact: per docs/contributing.md:128 the completed comparisons stay INCONCLUSIVE (as the Issue already says), and the future final A/B has no pre-registered gate a reviewer can hold it to.
Fix: place validator-v2/ (or a pointer to it) under the validator/ segment, record its hashes in a plan/ freeze file before the next measured arm, and have the requester accept contract-revision.json in the Issue.

The bundle's hash-frozen status artifact still reports that nothing ran

Where: evidence/h3-ref2va-4x910b1-320/results/status.json:3-9 ("execution": "queued", "four_device_samples": 0, "No four-device execution result yet", "No candidate search"), hash-pinned by plan/preflight-integrity.json:5 (PR Record MiniMax-H3 four-device 910B1 lossless campaign #321).
Problem: the same bundle now contains four-device TP4 bringup receipts (173.937 s, HTTP 200, clean exits), the TP2/SP2 failure and several rejected screens, and the Issue's current state describes them; but the standard status file still says the campaign has no four-device sample and no candidate search. Because the preflight snapshot is immutable, the contradiction will persist.
Conditions: any reader or tooling that uses results/status.json as the campaign's status.
Impact: the canonical status record points the opposite way from the evidence and the Issue, which is a real risk for a campaign whose whole value is auditable negative results.
Fix: add a separate current-status record (for example results/status-current.json) with actual sample counts, rejected screens and the queued reservation, give it its own integrity manifest, register it in tools/evidence_inventory.json, and label the existing file as the preflight snapshot.

Reviewed commit: 663f3b3
Coverage: Snapshot: 2645 files, 42462826 bytes; skipped 0 entries; Initial model context: 28 files; other accepted files available through tools; Git workspace contains a fixed snapshot, not full upstream history

Intent: the edited Issue governs a four-device Ascend 910B1 MiniMax-H3 Ref2VA campaign that must cut delivered-media E2E latency by at least 30% at 5 s and 15 s with unchanged quality; the edit adds author-reported queue-control and operator-screen outcomes. At draft PR #321 head 14de17a3, python tools/validate_evidence.py exits 0 with 475 hashes and pytest tests/test_evidence_inventory.py passes 17/17; the fused-projection and synthetic copy/layout claims are supported, but the new 168.956 s queue control exists only in PR text, and the head's new plan/acceptance-elementwise-v2.json gate supersedes the Issue's losslessness clause without being recorded here. Verdict: needs information / human decision required — earlier findings on lifecycle text, the missing requester decision, the unreachable control revision, the post-search gate freeze and the stale status artifact all remain open.

New elementwise gate at PR head supersedes the Issue's losslessness clause; the evidence pin is stale

Where: evidence/h3-ref2va-4x910b1-320/plan/acceptance-elementwise-v2.json at PR Record MiniMax-H3 four-device 910B1 lossless campaign #321 head 14de17a3 (recorded 2026-11-03T09:38:07Z, supersedes_lossless_adjudication_only: acceptance-30pct.json), hashed by results/strict-followup-integrity.json; the Issue's Acceptance plan and its df3723cd pin.
Problem: The new record requires elementwise-exact model output tensors plus decoded video/audio equality and says baseline nondeterminism does not excuse a candidate mismatch. The Issue still calls decoded equality sufficient and allows a nonidentical candidate to stand on a stronger numerical-equivalence argument. The body also pins df3723cd, one commit before the head that added this gate and the nz-weight (all four synthetic projections exact) and head-split (slower, nonexact) screens.
Impact: Two losslessness rules now exist. Both baselines are nondeterministic (results/baseline15-repeatability-v2.json and the 5 s records show exact_video: false, exact_audio: false), so under the new rule no candidate can pass until repeatability is resolved, but the Issue does not state that.
Fix: Record the current gate and head in the Issue (or merge Record MiniMax-H3 four-device 910B1 lossless campaign #321 first), make baseline repeatability the precondition for candidate acceptance, and have the acceptance owner confirm the stricter rule.

Requester scope, the 30% target and the stop condition still have no recorded Issue decision (earlier finding, still open)

Where: .github/ISSUE_TEMPLATE/campaign-acceptance.yml:13,29,51,62; docs/contributing.md:97-100; evidence/h3-ref2va-4x910b1-320/plan/acceptance-30pct.json; the Issue's Scope and authorization and Reported target update.
Problem: The body again calls the 30% target an author-reported target, and that record contains only target, metric, workload and evidence fields - no requester statement, link or owner. The [Campaign] MiniMax-H3 Ref2VA lossless optimization on 4x910B1 #320 timeline has only bot comments. The only requester wording is a user_instruction line inside the author-authored acceptance-elementwise-v2.json, which cannot substitute for an Issue record.
Impact: The record still cannot distinguish an accepted campaign from an agent-proposed one, and a numeric gate authored inside the PR could later be cited as requester-set.
Fix: The requester posts one scope/target/stop-condition acceptance comment linking [Campaign] MiniMax-H3 Ref2VA lossless optimization on 4x910B1 #320 and the current plan records, and names the accountable and acceptance owners. Neither the author nor a bot should self-record it.

The 15 s denominator and every four-device screen still run on an unreachable revision, and patch/README.md contradicts the patches (earlier finding, still open)

Where: results/baseline15-complete.json:3, results/hybrid-oom-query-result.json:5, validator-v2/contract-revision.json:3; plan/runspec.json still pins only c7f56f01; patch/README.md:3.
Problem: ce216014adb4c037dc15b3d49623e493ca3d3ac3 still returns 422 from the public vllm-omni commit API, while PR #9698 head is a0e7b09c. patch/ now holds the TP4 placement and 8cbe1a1d layout diffs, but nothing produces ce216014 (the new local 8cbe1a1d is also 422). patch/README.md still says no engine change is made and the original source is pinned in the RunSpec, which is false for both claims.
Impact: The 15 s baseline and matched comparisons cannot be audited or reproduced from the repository, and the patch status misstates what changed.
Fix: Add a per-duration baseline revision to runspec.json, add the exact diff/branch yielding ce216014 under patch/ (or re-attribute the 15 s control), and correct patch/README.md.

The pre-search freeze record still says no validator existed, and the governing gates were frozen after the search (earlier finding, still open)

Where: validator/README.md:5 ("No candidate validator is frozen yet and no candidate search has begun"), hash-pinned by plan/preflight-integrity.json:7; operative gates are hashed only in results/baseline15-profile-integrity.json and results/strict-followup-integrity.json.
Problem: validator-v2/ remains outside validator/, and plan/acceptance-elementwise-v2.json is another acceptance revision recorded after the dense, residency, TP4/TP2, FIA and query screens. AGENTS.md:64 and docs/contributing.md:100 require the checklist and validator/input hashes in plan/ before candidate experiments. I re-checked the 40 Hz audio-latent rounding at public vllm-omni head a0e7b09c (time_request.py:34-36, pipeline_minimax_h3.py:3217); the arithmetic is real, so the remaining issue is freeze timing and acceptance-owner sign-off.
Impact: Completed comparisons stay INCONCLUSIVE and the final A/B still has no pre-registered gate a reviewer can hold it to.
Fix: Move the operative gate (or a pointer plus hashes) into the validator//plan/ freeze before the next measured arm, and have the requester accept contract-revision.json and acceptance-elementwise-v2.json in the Issue.

The TP2/SP2 failure record still contradicts itself on worker lifecycle (earlier finding, still open)

Where: results/hybrid-oom-query-result.json:274 versus the raw block at :237-260; the current PR Record MiniMax-H3 four-device 910B1 lossless campaign #321 body repeats the contradictory wording.
Problem: The raw block records container_exit: 1, forced_signals: 4 and worker exit_code: -15 (SIGTERM) for all four ranks, while failure_analysis.lifecycle says all workers and server exited zero without forced signals. The PR body says all workers/server exited 0 but container exit 1. The Issue body only notes container exit 1, omitting the forced teardown.
Impact: Lifecycle correctness is an acceptance gate, and a forced four-worker teardown is currently described as clean exits.
Fix: Correct the summary string and PR text to server exit 0, container exit 1, four workers SIGTERM after four forced signals; keep the raw block and derive the verdict from it.

The hash-frozen status artifact still reports that nothing ran (earlier finding, still open)

Where: results/status.json:3-9 (execution: queued, four_device_samples: 0, no four-device result, no candidate search), hash-pinned by plan/preflight-integrity.json:5.
Problem: The bundle now has the 5 s and 15 s baselines, TP4 bringup, the TP2/SP2 failure and several rejected operator screens, yet the canonical status file still reads as an empty campaign. A human reviewer raised this on the PR at 9c528c7d; it remains unresolved.
Impact: Readers or tooling using results/status.json get the opposite of the Issue and the rest of the bundle.
Fix: Add a current status record with actual sample counts, rejected screens and the queued reservation, give it an integrity manifest, register it, and label the existing file as the preflight snapshot.

The new 168.956 s queue-control figure has no committed receipt

Where: the Issue's Current state sentence and the same sentence in the PR Record MiniMax-H3 four-device 910B1 lossless campaign #321 body. I checked all 72 bundle paths at head 14de17a3: no file contains 168.9, and results/dispatch-queue-stage-offload-plan.json still says the task-queue comparison is waiting for a four-device reservation.
Problem: Every other four-device number in the status block (814.064 s, 2597.200/2475.906 s, 173.937 s) has a receipt under results/, but the newly added queue control does not. The Issue's Next action asks for reconciliation against the published bundle, and this number cannot be reconciled.
Impact: A control timing that may become the queue-screen denominator has no raw sample, HTTP status or worker-exit record.
Fix: Commit the control receipt (request timing, HTTP status, worker exits, lifecycle) or mark the figure as uncommitted commentary and remove it from the acceptance status until the receipt exists.

Reviewed commit: 663f3b3
Coverage: Snapshot: 2645 files, 42462826 bytes; skipped 0 entries; Initial model context: 28 files; other accepted files available through tools; Git workspace contains a fixed snapshot, not full upstream history

The edit is a status sync for the four-device 910B1 MiniMax-H3 Ref2VA campaign: it now discloses that the 168.956 s queue control is unverified author commentary and that the author-authored elementwise-v2 record conflicts with the Issue's losslessness clause, while leaving scope, target and stop-condition acceptance unrecorded. Those two disclosures resolve the earlier "no receipt for 168.956 s" and "new gate supersedes the Issue / stale pin" findings at the Issue level; at PR #321 head 14de17a I confirmed python tools/validate_evidence.py exits 0 with 475 hashes and pytest tests/test_evidence_inventory.py passes 17/17, but the requester decision, the unreachable control revisions, the forced-teardown lifecycle text, the post-search gate freeze and the stale status.json remain open. Verdict: needs information / human decision required — no Issue sentence authorizes a code change in InferRSI, and no new label is inferable (kind:acceptance and area:workbench are already set and no status decision is recorded, so no priority label applies).

F1 — blocking, human decision — Scope, 30% target, owners and stop condition still have no requester record

Where: docs/contributing.md:97 (owner, goal/non-goals, stop condition); evidence/h3-ref2va-4x910b1-320/plan/acceptance-30pct.json at PR Record MiniMax-H3 four-device 910B1 lossless campaign #321 (target/metric/workload only; committed as Freeze requested lossless thirty-percent latency target, Signed-off-by: amy-why-3459); plan/acceptance-elementwise-v2.json (user_instruction: "必须逐元素一致…").
Problem: the edited body itself labels the target "author-reported" and says no new public requester decision was found, and the [Campaign] MiniMax-H3 Ref2VA lossless optimization on 4x910B1 #320 timeline still has no requester entry (three bot comments plus cross-references from Record MiniMax-H3 four-device 910B1 lossless campaign #321, #9698 and [Status 03] InferRSI evolution: 48e0d589 → 68108700 (2026-10-31 catch-up) #286). The only wording claiming a requester instruction is a field inside an author-committed PR record, which cannot substitute for an Issue record; no accountable or acceptance owner is named and the five-hour reservation ceiling is not a stop condition.
Impact: the record still cannot distinguish a requester-accepted campaign from an agent-proposed one, and a numeric gate authored inside the PR could later be cited as requester-set.
Next: the requester posts one scope/target/stop-condition acceptance comment naming the accountable and acceptance owners, and the Issue body links it. Neither the author nor a bot should record this decision.

F2 — high, must-fix — The 15 s denominator and the four-device screens still run on revisions nobody can fetch

Where: evidence/h3-ref2va-4x910b1-320/results/baseline15-complete.json:3, results/hybrid-oom-query-result.json:5, results/dispatch-queue-stage-offload-plan.json (source revision ce216014adb4c037dc15b3d49623e493ca3d3ac3), results/tp4-placement-npu-validation.json (isolated revision 0be853d46bcb1ae880d7582f4bed502ec29017af), plan/runspec.json:4 (pins only c7f56f0155953c7d4a77276a2f4fcbd844ab0da2), patch/README.md:3 (all at PR Record MiniMax-H3 four-device 910B1 lossless campaign #321 head 14de17a).
Problem: checked through the commit API today: ce216014… and 0be853d4… both return 422 in vllm-project/vllm-omni and InferMatrixLab/InferRSI, while PR #9698 head a0e7b09c… resolves. patch/ holds only the TP4 placement and FP16-layout diffs, and patch/README.md still says "No engine change is made by this preparation" and "Original source is pinned in the RunSpec".
Impact: the 15 s baseline and every matched candidate repetition cannot be reproduced or audited, and the patch status misstates what changed — exactly what final acceptance at both durations needs.
Next: add a per-duration baseline revision to plan/runspec.json, commit the exact diff/branch that yields ce216014… and the TP4 fix revision, and correct patch/README.md.

F3 — high, must-fix — The TP2/SP2 record still describes a forced four-worker teardown as clean exits

Where: evidence/h3-ref2va-4x910b1-320/results/hybrid-oom-query-result.json:274 versus the raw block at :237-260 (PR Record MiniMax-H3 four-device 910B1 lossless campaign #321 head 14de17a); PR Record MiniMax-H3 four-device 910B1 lossless campaign #321 body ("All workers/server exited0 but container exit1 makes lifecycle qualification fail").
Problem: the raw block records container_exit: 1, forced_signals: 4 and exit_code: -15 (SIGTERM) for all four ranks, while the adjacent failure_analysis.lifecycle string says "All workers and server exited zero without forced signals". The edited Issue repeats only "container exit 1 failed lifecycle qualification", and the 5 s baseline likewise records forced_signals: 8 with null worker exits, so a reader of the Issue alone cannot tell that teardown was forced.
Impact: lifecycle correctness is an acceptance gate; a forced teardown described as clean exits can hide a process-cleanup regression and understate the failure.
Next: correct the summary string and the PR text to server exit 0, container exit 1, four workers SIGTERM after four forced signals; keep the raw block unchanged and derive the verdict from it; reflect the forced signals in the Issue status.

F4 — high, must-fix — The freeze record still says no validator existed, and every governing gate was recorded after the search

Where: evidence/h3-ref2va-4x910b1-320/validator/README.md:5 ("No candidate validator is frozen yet and no candidate search has begun"), hash-pinned by plan/preflight-integrity.json:7; operative gates live in validator-v2/ and plan/acceptance-elementwise-v2.json (recorded_at 2026-11-03T09:38:07Z), hashed only under results/baseline15-profile-integrity.json:5-11 and results/strict-followup-integrity.json (PR Record MiniMax-H3 four-device 910B1 lossless campaign #321).
Problem: docs/contributing.md:101 and AGENTS.md:64 require validator/input hashes frozen before candidate search. Here the pre-search snapshot predates the operative gate, the dense/residency/TP4/TP2/FIA/query screens ran in between, and a second acceptance revision (acceptance-elementwise-v2.json) was added after the measured arms. The edit discloses the discrepancy but does not move the freeze. The validator-v2 bytes are now committed and hashed (good), but they are not the validator/ freeze the campaign's own plan claims.
Impact: completed comparisons correctly stay INCONCLUSIVE, and the future final A/B still has no pre-registered gate a reviewer can hold it to; an author-authored gate changed after a failure is not a substitute for an owner-approved one.
Next: place validator-v2/ (or a pointer plus hashes) under validator/, record the hashes in a plan/ freeze file before the next measured arm, and have the acceptance owner accept contract-revision.json and acceptance-elementwise-v2.json in the Issue (F1).

F5 — medium — The hash-frozen status artifact still reports an empty campaign

Where: evidence/h3-ref2va-4x910b1-320/results/status.json:3-9 (execution: queued, four_device_samples: 0, "No four-device execution result yet", "No candidate search"), pinned by plan/preflight-integrity.json:5; still-unanswered human inline P2 on PR Record MiniMax-H3 four-device 910B1 lossless campaign #321 at 9c528c7d.
Problem: the bundle now holds the 5 s and 15 s baselines, the TP4 bringup (173.937 s, HTTP 200, clean exits), the TP2/SP2 failure and several rejected screens, and the Issue describes them — yet the canonical status file says nothing ran. Because the preflight manifest is immutable, the contradiction persists.
Impact: any reader or tooling that uses results/status.json as the campaign status gets the opposite of the evidence and the Issue.
Next: add a current status record (for example results/status-current.json) with actual sample counts, rejected screens and the queued reservation, give it its own integrity manifest, register it in tools/evidence_inventory.json, and label the existing file as the preflight snapshot.

F6 — medium — The Issue's own closing status line says no execution result exists

Where: Issue [Campaign] MiniMax-H3 Ref2VA lossless optimization on 4x910B1 #320 body, last line of the Acceptance plan: "Status: INCONCLUSIVE, four-device preflight prepared; no new execution result or speedup."
Problem: the Current state block in the same body lists four-device executions — the 173.937 s TP4 bringup, the TP2/SP2 measured-request failure, rejected operator screens and a queue control. "No new execution result" is now false; only "no speedup" still holds. The line was not updated by this edit.
Impact: the Issue's bottom line contradicts its own record and can be quoted as evidence that nothing ran, which is the opposite of what this campaign's audit trail shows.
Next: change it to INCONCLUSIVE with executed-but-unqualified four-device samples and no speedup, keeping the no-speedup qualifier.

F7 — medium — PR #321's narrative still presents the unreceipted queue control as completed with a clean lifecycle

Where: PR Record MiniMax-H3 four-device 910B1 lossless campaign #321 body at head 14de17a: "The queue control completed at168.956s with clean lifecycle; its candidate is still running." The edited Issue now labels the same figure unverified author commentary. I searched all 68 changed paths at that head and found no 168.9 value, while results/dispatch-queue-stage-offload-plan.json still says the task-queue comparison is waiting for a four-device reservation.
Problem: the Issue-level qualifier does not travel with the PR text that external readers see, and "clean lifecycle" is unverifiable without the worker-exit and container-exit record.
Impact: a control timing that may become the queue-screen denominator has no raw sample, HTTP status or lifecycle receipt, in a campaign whose value is auditable negative results.
Next: commit the control receipt (request timing, HTTP status, worker exits, container exit) or qualify the PR text the same way the Issue now does.

Reviewed commit: 663f3b3
Coverage: Snapshot: 2645 files, 42462826 bytes; skipped 0 entries; Initial model context: 28 files; other accepted files available through tools; Git workspace contains a fixed snapshot, not full upstream history

Navigation Menu

Repository navigation

[Campaign] MiniMax-H3 Ref2VA lossless optimization on 4x910B1 #320

Scope and authorization

Initial RunSpec

Acceptance plan

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Campaign] MiniMax-H3 Ref2VA lossless optimization on 4x910B1 #320

Description

Scope and authorization

Initial RunSpec

Acceptance plan

Activity

agent-ci-infra-bot commented on Nov 2, 2026

agent-ci-infra-bot commented on Nov 3, 2026

agent-ci-infra-bot commented on Nov 3, 2026

agent-ci-infra-bot commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions