[MPSNDArrayMatrixMultiplication encodeToCommandBuffer:] destination ... is too large for kernel on M3 Max 64 GB

[rideapandafly]

Reproduction
Any generation where the combined video+audio token sequence grows past ~26k. Two confirmed failures, both at denoise 0/20:
A. 1024×576, 8 s (192 frames):
./h3 -d ./MiniMax-H3 -p "..." --width 1024 --height 576 --seconds 8
--steps 20 --layers 45 --reuse 2 -o outputs/out.mp4

B. 896×512, 8 s (192 frames): same command with --width 896 --height 512.
Both abort with:
MPSNDArrayMultiaryKernel.mm:2644: failed assertion `[MPSNDArrayMatrixMultiplication encodeToCommandBuffer:] destination: [
<MPSTemporaryNDArray ...> Rank: 4, MPSDataTypeBFloat16, Device: Apple M3 Max

• dimensionLengths = [ 33654, 33654, 56, 1, ... ] (case A)
• dimensionLengths = [ 26358, 26358, 56, 1, ... ] (case B)
• strideElements = [ 1, 33656, ... ] / [ 1, 26360, ... ]
  ] is too large for kernel. Encode failed.'
  zsh: abort

Analysis
The failing op is an explicitly materialized attention-score matrix: 56 heads × S×S BF16, i.e. 56 × S² × 2 bytes:

Canvas / duration | Sequence S | Score-matrix footprint
1024×576 × 8 s | 33,654 | ≈ 127 GB
896×512 × 8 s | 26,358 | ≈ 78 GB

where S ≈ (W/32)×(H/32)×⌈frames/4⌉ + audio tokens. Both footprints far exceed a 64 GB unified-memory machine. Development appears to happen on a 128 GB M5 Max, where the 78 GB case fits — which is presumably why this hasn't been caught. M3 Max also has no Metal 4/TensorOps attention path, so it falls into this MPS path even at shapes that work on M5.
Meanwhile small sequences work fine on the same machine: the README's 512×512 / 22-frame fox validation runs correctly.

Expected behavior
M3-class / ≤ 64 GB machines need a fallback that doesn't materialize the full S×S score matrix — e.g. a chunked/tiled SDPA (flash-attention style), or dispatching to an MPSGraph scaled-dot-product path when S exceeds a memory-derived threshold.

Suggested immediate mitigation for users
Keep 56 × S² × 2 ≤ ~22 GB of temp headroom (DiT at --layers 45 already resident at ~33 GB). On a 64 GB machine that means S ≲ 14,000, e.g. 864×480 × 5 s (S = 14,339) is the largest validated-geometry shape expected to work; longer videos must be produced as chained shorter segments via --ref-video.
Happy to run any diagnostics / patched builds on this machine.

[rideapandafly]

Update — bisection complete, ceiling located:

table-1789465649688.csv

The cutoff lies between S = 9,122 (9.3 GB destination) and S = 12,362 (17.1 GB). Note the 17.1 GB failure cannot be explained by total-memory pressure either (17.1 GB temp + ~34 GiB resident DiT + OS overhead < 64 GB), and the 2^32 total-element hypothesis is dead (4.66B elements passed). This points to an internal MPS limit on the M3 fallback path — per-allocation quota or kernel bound — that M5 avoids by dispatching large sequences to MPSGraph.

Impact: on M3-class machines the practical ceiling is ~73 frames per segment at 864×480 (3 s of video). Longer clips require segment chaining. A chunked/tiled attention implementation for the non-Metal-4 path would remove the ceiling.

[rideapandafly]

Update 1 — silent latent corruption on M3, distinct from (and below) the MPS crash ceiling:

table-1789479554289.csv

864×480 × 73 frames corrupts silently at any step count, while the same frame count at 512×512 is clean — so the corruption threshold lies between S≈6,500 and S≈9,122, below the "too large for kernel" crash ceiling (S between 9,122 and 12,362). Both modalities corrupted → the DiT latent stream itself, not the VAE decoders. Suspect an indexing/aliasing bug in the M3 copied-buffer attention path (ring depth 2) that activates past a token threshold at the 27×15 spatial grid. Could you run 864×480 × 73f on M5 to confirm it's M3-path-specific? A cheap improvement regardless: a NaN/range sanity check on latents before VAE decode so corruption fails loudly instead of writing a broken MP4.