M4 Pro 24GB verification: official sharded weights render cleanly; misaligned repacked weights produce garbage (confirms PR #14)

[AideYu]

Device: Mac mini M4 Pro, 24 GB unified memory, macOS 26.6.1
Build: commit 8974cc0, --ssd-streaming (BF16 DiT layers streamed from SSD)

Sharing M4 Pro (24GB) results with the official MiniMaxAI/MiniMax-H3 sharded weights, to complement the existing M4 Max (64GB) data in #5.

Timing (full pipeline, includes text encoder + VAE + FFmpeg)

Canvas	Frames	Steps	Total time
256×256	22	20	3m46s
512×512	22	20	4m29s
832×480	124	20	44m46s

Prompt: official README example ("A red fox walks through fresh snow in a pine forest."), layers 50, reuse 1, default seed.

Root-cause confirmation for the noise issue

Previously, with the Comfy-Org repackaged single-file weights (safetensors with misaligned data segments — our text_encoder data offset %8 = 5, video_vae %8 = 7), every render came out as uniform texture noise (T2VA and FL2VA alike, both warm-up and full runs).

After switching to the official MiniMaxAI/MiniMax-H3 shards (13-piece transformer + 14-piece text encoder + official F32 video VAE, no conversion, no repacking), renders are completely clean — proper detail, no artifacts, verified at both 256 and 512 canvases.

This is a practical confirmation that the misalignment issue described in PR #14 is real: unaligned repacked weights silently decode to garbage on the GPU path, while official weights work as-is.

For reference: 1344×768 / 124 frames / 6 steps was ~71.5 min total with the old (repacked) weights.

Happy to provide more data (e.g., first/last frame conditioning timings at 832×480) if useful.

[dongioia]

Your numbers here are what caught a bad configuration on my side. Posting the
correction in case anyone else falls into the same hole.

Same machine as yours: Mac mini M4 Pro, 24 GB, macOS 26.6.2, official
MiniMaxAI/MiniMax-H3 FL2VA/ shards.

I had skipped --ssd-streaming because H3_ZERO_COPY_WEIGHTS=1 appeared to make it
unnecessary. The DiT reported a 36.167 GiB peak on a 24 GB machine and the OS showed
plenty of free memory, which I read as "the mapped path fits, streaming is a
memory/speed tradeoff I can skip". Your 4m29s for 512²/22f at 20 steps didn't fit that
story at all. I was taking 10m30s for four steps, so I measured the two side by
side. Same preset, only the flag changed:

	H3_ZERO_COPY_WEIGHTS=1	--ssd-streaming
denoise	508.4 s	188.7 s
encode	334.4 s	0.095 s
wait	169.3 s	60.5 s
DiT peak	36.167 GiB	1.714 GiB

2.7x faster and 20x less memory. On a machine smaller than the model, zero-copy doesn't
make the weights fit. It makes the kernel page them off disk implicitly, which is the
dumb version of what --ssd-streaming does deliberately with two blocks at a time. The
334 s of encode were page-fault stalls, not command-buffer construction; with
streaming they collapse to 0.095 s. The "high peak, plenty of free memory" reading was
the tell, and I misread it as reassurance.

With streaming the denoise is I/O-bound on this box, and the arithmetic closes. Of
188.7 s: encode 0.1, wait 60.5, leaving 128.1 s unaccounted. My weights live on an
external SSD I measured at 1208 MB/s with F_NOCACHE. The DiT is ~782 MB per block, so
50 blocks x 4 steps = 156 GB, which at that rate is 129 s. Predicted 129, measured
128.

That model also predicts the --layers behaviour, which is just "read fewer blocks":

	denoise	delta	wait	inferred I/O	linear predicted
--layers 50	188.7 s	—	60.5	128.1	—
--layers 45	170.8 s	-9.5%	54.5	116.2	169.8
--layers 40	151.8 s	-19.5%	48.3	103.4	151.0
--token-reduction	189.4 s	+0.4%	41.5	147.8	—

--token-reduction cuts GPU wait by a third and buys nothing, because it doesn't
change how many blocks get read.

If this holds, disk bandwidth is the first thing to fix on a 24 GB box, ahead of any
flag. On internal storage I measure 6980 MB/s versus 1208 external, which would put the
I/O term at roughly 22 s instead of 128 and the denoise near 82 s. I can't test it, since the
internal disk has 53 GB free against 62 GB for the transformer alone. But if your
weights are on internal storage it would go some way toward explaining the gap between
your timings and mine. Might be worth stating in the README that where the shards live
matters more than the sampling flags.

Disclosure: this was done in a Claude Code session with Opus 5, including the wrong
first version. It produced the zero-copy conclusion confidently and I believed it until
your numbers contradicted it. Reading the open issues before writing my own turned out
to be the step that mattered.