Wan 3D-VAE decode parity on CPU (Swift): pinning the layout contract

Contribution

Claimed. A from-scratch Swift CPU reimplementation of the Wan2.1 AutoencoderKLWan decode path reaches cosine 1.0 against the diffusers reference decode. The value of the result is that it independently pins three layout/semantic contracts that the rest of the video pipeline depends on: the z latent layout (orientation / channel order), the causal-convolution semantics (temporal causality inside the 3D convolutions), and the temporal-upsample behaviour. Because the decode that turns latents into pixel frames is verified in isolation, upstream parity work (encoder, diffusion transformer) can be trusted to compose end to end rather than being undermined at the final hop.

NOT claimed. This is a correctness-validation (parity) result, not a novel algorithm and not a performance result. It does not claim decode throughput — the CPU naive-convolution implementation is explicitly slow. It does not claim perceptual or generation quality: numeric cosine parity against the reference is not a statement about visual fidelity of generated video. It does not cover the encode side, other VAE variants, or any non-decode path. The altitude here is an engineering correctness anchor, not a research advance.

Methods

Results

No other quantitative measurements (timing, tensor shapes, PSNR, sample count) are recorded in the source note for this decode parity.

Threats to validity / Limitations

• Single reported metric, single configuration. The note records exactly one number (cosine 1.0) from what is structurally a parity smoke test. There is no reported sample size (number of latents / prompts), no variance, and no multi-input sweep — this validates the layout contract, not statistical robustness across inputs.
• Parity is not quality. Cosine 1.0 against the diffusers reference confirms the reimplementation matches that reference's numerics; it says nothing about perceptual quality of generated frames, and it inherits any limitation of the reference itself.
• No throughput claim, and CPU is slow. The implementation uses naive convolution on CPU and is explicitly not a performance vehicle; no timing is recorded here.
• Scope is decode-only. Encode side, other VAE variants, and non-decode pipeline stages are out of scope and untested by this note.
• Precision ceiling / details unrecorded. Reference precision, reference version, exact latent shape, and hardware SKU are not recorded in the source notes; "cosine 1.0" is reported as-is without an explicit numeric tolerance gate.
• Evidence standing. The note documents a single decode-parity figure; treat it as the standing claim rather than a fresh independent re-measurement.

Reproducibility / Provenance

• Implementation: Swift CPU AutoencoderKLWan decode, validated by cosine comparison against the diffusers reference decode.
• Build commands / version pins: not recorded in source notes for this specific decode-parity note.
• Sovereignty: no third-party ML framework is used in the decode path (vendor-native math primitives only).
• Oracle caveat: validate the diffusers reference decode against known-good output before treating engine-vs-oracle parity as meaningful; the parity statement is only as strong as the reference it is compared to.