research: prove doctrine-shaped frozen-plan realization - #16
Conversation
ezutfen
left a comment
There was a problem hiding this comment.
R1 physical evidence looks strong, but I found three blocking correctness gaps in the generic frozen-plan realization/audit substrate. These matter because R1's result is the substrate itself, not merely the Block A happy path.
-
Staging release is not actually gated on an observed required persistent realization. In
realize_frozen_plan(),realized_required_idsincludes anyPLANNED_AND_REALIZEDrecord, including the transient staging record itself.final_existsthen checks that the plan contains a required persistent candidate for the same logical state and that the state ID appears inrealized_required_ids. Therefore staging can be released even when the persistent counterpart returned a failed/non-realized status. Fix the release predicate to require the specific required+persistent planned counterpart (or an equivalent legal final materialization) to have an observedPLANNED_AND_REALIZEDrecord. Add a regression where staging realizes but the final persistent materialization does not; staging must not be released and realization must fail closed. -
Released transient materializations bypass reconciliation of where/what was actually staged.
reconcile_realization()immediatelycontinues forTRANSIENT_RELEASED_AS_PLANNED, so a staging materialization can have the wrong actual representation/resource (or wrong pre-release byte count) and still reconcile cleanly once released. R1 requires intended-vs-observed reconciliation for staging too. Preserve/report the pre-release observed bytes (the existingreleased_bytescan serve this purpose) and still reconcile logical state, representation, resource, and expected staging bytes before accepting the released status. Add wrong-resource/wrong-representation/released-byte regressions. -
The physical adapter does not independently realize/observe mutable authority.
QwenBlockAResearchAdapter.observe_authorities()returnsself.plan['authorities']verbatim, so the observed authority side is tautologically equal to intended authority. R1 requires mutable authority to be part of observed realization, not just validated plan text. Establish/store the active authority as runtime realization state only after the planned mutable-authority materialization has actually been realized (an internal adapter field/callback is sufficient; no public API needed), and haveobserve_authorities()return that realized state. Add a regression proving missing/wrong authority establishment fails reconciliation.
The committed physical result otherwise matches the stated R1 claims: frozen digest/provenance, clean materialization happy-path reconciliation, host staging release, zero unexplained mirror, and exact repeated correctness. I would consider this mergeworthy after these three audit/realization holes are closed; regenerate the physical result if the result schema/reconciliation fields change.
ezutfen
left a comment
There was a problem hiding this comment.
Re-review at head f8e9e8f7301e50ce1b42851ebd5e7191e3c71bfe: the three blocking R1 audit findings are resolved.
- Staging release now requires a distinct required persistent materialization for the same Logical State Unit that is actually observed live and matches its planned resource, representation, and bytes. Missing/not-realized final residency leaves staging unreleased and fails reconciliation.
TRANSIENT_RELEASED_AS_PLANNEDnow retains and reconciles pre-release bytes/resource/representation, post-release zero bytes, released-byte accounting, lifecycle, and the exact qualifying final materialization IDs.- Mutable authority is now recorded only when the mutable runtime materialization is physically realized;
observe_authorities()returns runtime-owned observations rather than echoing the plan, and reconciliation verifies that authority is backed by a live realized owner.
The regenerated physical result keeps the frozen-plan bytes/digest unchanged, has clean reconciliation, 0 unplanned persistent bytes, 0 unexplained persistent host mirror bytes, exact prefill + four decode repetitions, and all staging/source sentinels clean. The focused suite is reported as 74 passed; the repository-wide collection limitation remains the pre-existing benchmarks namespace collision.
No remaining blocker found. PR #16 is mergeworthy for the stated R1 proof boundary. I am not merging it in this review.
Links Zutfen-LLC/inferswarm#50. This PR does not close the issue and must not be merged automatically; issue acceptance remains gated on review of the committed physical evidence.
Provenance
poc/r1-frozen-plan-realizationpoc/n0-selective-model-block-loading2d435c5b8addc4032fd1be3198d796e632648ac8(merge commit of FreeToken PR research: prove accelerator residency without host mirror #15)bc8e95514ee41b23f5741cf6b5e10870f00698def8e9e8f7301e50ce1b42851ebd5e7191e3c71bfenvidia/Qwen3.6-35B-A3B-NVFP4491c2f1ea524c639598bf8fa787a93fed5a6fbceFrozen plan
inferswarm.r1.frozen-plan/1r1-block-a-v1sha256:430f84e406f51d037ab8ae2844865ff4d6b60d17a1d43d54180d509682ca228111bebfc891d078eafafeddc78a36bc7aba3943b97a849e02a72a480e55115062e7d04bbafb9a26178690a589c65301a4e8918e880e61bd11a56a5d6b07cb484eThe manifest records the Swarm/Node/Compute Unit/Memory Resources/backing/links, four Logical State Units, five materializations, roles and persistence, execution placement and required state, one mutable authority lineage, capacity expectations, and the forbidden persistent host mirror. It intentionally retains the exact N0 selective-key set so the pinned checkpoint selection is fully frozen.
These are internal research mappings and plain structures, not a final
ExecutionPlan, resource schema, planner API, or model-strategy ABI. Generic validation/reconciliation contains no Qwen/MoE/expert/router/NVFP4/CUDA Graph vocabulary; the pinned mechanics live behind one narrow adapter.Plan-driven realization
The runner only loads the frozen plan, constructs/verifies the known physical environment, calls
realize_frozen_plan(...), executes repeated correctness decode, and writes evidence.The generic realizer validates first, asks the adapter to realize each planned materialization, infers the release transition from:
The pinned adapter then invokes FlashML-org#48's existing
detach_host_sources_for_full_residency()boundary. That boundary independently validates complete accelerator residency before detach. The runner contains no selective-load/populate/detach sequence and no R1 experiment-name branch. Plan interpretation ends at setup; decode uses the existing backend-native frozen device slot mapping.Physical result
Committed status:
R1_FROZEN_PLAN_REALIZATION_PASS.Hardware/software:
inferswarm01GPU-1fc28f83-1d45-926e-54d0-ba1e835ef099Plan validation rejected heavyweight execution unless the exact digest, model/revision, references, representations, authority, execution legality, forbidden persistence, and known capacity were valid. The plan declared 10,391,381,656 required persistent VRAM bytes, below the measured target capacity.
Observed reconciliation:
TRANSIENT_RELEASED_AS_PLANNEDMemory accounting
VmRSS, VmHWM, RssAnon, RssFile, RssShmem, VmSwap, CUDA allocated/peak, and page/swap counters are retained per checkpoint. Component ownership remains authoritative because the pinned allocator may retain freed raw pages without retaining a live Logical State Unit materialization.
Correctness and backend execution
The physical runner did not capture CUDA Graph decode. Graph compatibility is therefore claimed only as structurally preserved and regression-tested, not physically benchmarked.
Tests
74 passed: R1 validation/reconciliation tests, focused graph lifecycle regression, fix: use current GPU for e4m3 capability FlashML-org/FreeToken#48 resident-only lifecycle, canonical N0 selective block tests, and relevant ordinary offload tests.tests/benchmarksversus top-levelbenchmarksnamespace collision:tests/benchmarks/test_phase0_profile_provenance.pycannot importbenchmarks.inferswarm_phase0. No unrelated test-layout changes are included.Proof boundary
This proves that one predeclared doctrine-shaped plan caused the pinned runtime to validate, realize, audit, and correctly execute the exact intended resource/state/materialization arrangement without reintroducing an implicit persistent host mirror.
It does not prove automatic placement, candidate comparison, a planner optimizer, R2 split execution, multi-GPU/network/multi-node execution, elasticity, Adaptive Demand Profiles, health/quarantine, public strategy plugins, a final execution-plan schema, production discovery, non-NVIDIA support, or model generality.
Review fixes