Questions about M4 Max support, 720p 15‑second generation time, and GUI

[Slzx1]

Hello,

I am very interested in using h3.c on my Mac with an M4 Max chip and 64GB of unified memory. Before diving in, I have three practical questions that I hope you or the community could help clarify.

1. M4 Max (64GB) compatibility and performance
   The README mentions that current optimizations are incremental for M3 Max and M5 Max. Has there been any testing on the M4 Max? Are there any known performance figures (e.g., time per step for a 512×512, 22‑frame run) or special environment variables (like H3_NAX or Metal flags) that might improve performance on this chip? Also, does the 64GB memory size handle the full model comfortably, especially when using the --show preview (which adds ~10 GiB extra memory)?

2. Estimated generation time for a 15‑second 720p video
   The benchmarks in the README show impressive speeds for short 512×512 clips. However, I would like to generate longer, higher‑resolution videos – for example, 15 seconds at 720p (roughly 362 frames at 24 fps, e.g., 1344×768 or 1280×720). Could you provide an approximate generation time on a typical M5 Max or M4 Max, assuming default settings (e.g., 20 steps, 45 layers, reuse 2)? If no direct numbers exist, any rough estimate or scaling rule (e.g., time proportional to frames × pixels) would be very helpful. I am also open to using internal render resolution or token reduction to speed things up, but I would like to know if the quality‑time trade‑off is acceptable for such long videos.

3. Graphical user interface (GUI) support
   I know there are community‑made ComfyUI nodes (like H3 Studio, ComfyUI‑H3‑Conditioning‑Cache‑AI‑Drama‑Production‑Suite, etc.). Does the official h3.c project plan to provide its own integrated GUI in the future? Alternatively, do you recommend any particular third‑party frontend that offers a user experience similar to ComfyUI (e.g., node‑based workflow, real‑time preview, easy parameter tuning)? If the official stance is to keep it command‑line only, that is fine, but I would appreciate some guidance on which external tool is most actively maintained and supports the full feature set (including first/last frame, audio references, etc.).

Thank you for developing this excellent project. I look forward to any insights you can share.

Best regards,
Slzx1

[Berserk-hub150]

Hi! I'd be happy to work on the documentation side of this issue.

I can add a concise compatibility section covering the behavior that can already be verified from the current code: the M4 execution path versus the M5 TensorOps/NAX path, memory/preview considerations, guidance for profiling long 15-second 768p runs, and the current CLI/interactive frontend status.

I will avoid claiming unmeasured M4 benchmark numbers or making assumptions about future GUI roadmap decisions.

Could you please assign this issue to me?

Thanks!

[Berserk-hub150]

I've opened PR #8 with the documentation clarification discussed above:

#8

The PR focuses only on behavior that can be verified from the current implementation and leaves actual M4 benchmark figures and future GUI roadmap decisions open for maintainer/community input.

[Slzx1]

I've opened PR #8 with the documentation clarification discussed above:

#8

The PR focuses only on behavior that can be verified from the current implementation and leaves actual M4 benchmark figures and future GUI roadmap decisions open for maintainer/community input.

@Berserk-hub150 Thank you for your prompt response and for offering to work on the documentation. The areas you outlined (M4 execution path, memory/preview notes, long‑run profiling guidance, and the CLI/status of the frontend) align closely with my original concerns.

[Berserk-hub150]

Thanks! Glad the documentation changes address the main points you raised.

PR #8 is ready for review. If a maintainer agrees with the changes, hopefully it can be merged soon.

[Keylin2935]

Hey @antirez and everyone,

Since I wasn't entirely sure where the best place to drop performance feedbacks is right now, I am posting this performance breakdown directly here. Feel free to move or re-file this comment to a more appropriate place if needed!

Following up on my local tests using h3.c with the MiniMax-H3 checkpoint on an Apple Silicon MacBook Pro M4 Max (64 GiB Unified Memory), I wanted to share a complete performance matrix including the exact bash commands with full prompts used for each test.

I also pushed the limits by attempting a full 10-second monolithic generation (243 frames) in 960x544 using optimization flags (--layers 45 --core-reuse 4 --token-reduction). While it successfully completed, it heavily hammered macOS memory management, pushing the swap usage up to 64 GiB (with only ~80 GiB free on disk), nearly triggering an Out-Of-Memory system crash.

Here is the updated benchmark table:

# | Resolution & Duration | Core Parameters | Peak Memory | Denoise / Total Wall Time | Output Status
-- | -- | -- | -- | -- | --
1 | 512 × 512 (Square)22 frames (~1s) | --steps 20--reuse 2 | 32.8 GiB | 68.8s / 81.7s | ✅ Success (outputs/fox-fast.mp4)
2 | 1280 × 768 (HD Wide)22 frames (~1s) | --steps 20--reuse 2 | 33.4 GiB | 477.7s / 489.7s | ✅ Success (outputs/fox_hd.mp4)
3 | 1024 × 576 (Cinema)73 frames (~3s) | --steps 16--reuse 2 | 37.6 GiB | 932.9s / 945.5s | ✅ Success (outputs/superman_vs_penguin.mp4)
4 | 960 × 544 (Optimized Part 1)121 frames (~5s) | --steps 16--reuse 2 | 38.3 GiB | 1594.0s / 1606.2s | ✅ Success (outputs/superman_vs_penguin_5s_544p.mp4)
5 | 960 × 544 (Optimized Part 2)121 frames (~5s) | --steps 16--reuse 2 | 38.4 GiB | 1666.7s / 1679.7s | ✅ Success (outputs/superman_vs_penguin_part2.mp4)
6 | 960 × 544 (Monolithic 10s)243 frames (~10s) | --steps 20, --layers 45--core-reuse 4, --token-reduction | 37.7 GiB | 2102.2s / 2113.9s (~35m) | ⚠️ Success with Heavy Swap Spike (outputs/video_10s_544p.mp4)

Reference Bash Commands Used (With Full Prompts):

Test 3 (3-second cinema clip):

Bash

./h3 --profile -d ./MiniMax-H3 -p "Cinematic medium shot of Superman walking in the streets of Paris..." --width 1024 --height 576 --frames 73 --steps 16 --reuse 2 -o outputs/superman_vs_penguin.mp4

Test 4 (5-second first part - Superman vs Penguin):

Bash

./h3 --profile -d ./MiniMax-H3 -p "[0s-5s] Cinematic medium opening shot in the streets of Paris with Haussmann-style architecture. A powerful Superman stumbles backward on the pavement, looking shocked, overwhelmed, and cornered, while a fierce, determined small penguin wearing a tiny custom Linux Tux t-shirt aggressively advances and begins to dominate the street fight. Dynamic camera, realistic lighting." --width 960 --height 544 --frames 121 --steps 16 --reuse 2 -o outputs/superman_vs_penguin_5s_544p.mp4

Test 5 (5-second second part - Chained via First-Frame Conditioning):

Bash

./h3 --profile -d ./MiniMax-H3 --first-frame ./outputs/last_frame.png -p "[5s-10s] Continuation of the cinematic street fight in Paris. The fierce penguin in the Linux Tux t-shirt triumphantly overpowers Superman, who desperately tries to block the relentless punches while sliding on the wet pavement. Dynamic camera, highly detailed textures, realistic lighting." --width 960 --height 544 --frames 121 --steps 16 --reuse 2 -o outputs/superman_vs_penguin_part2.mp4

Test 6 (10-second monolithic stress-test):

Bash

./h3 --profile -d ./MiniMax-H3 -p "My_prompt" --first-frame outputs/Image1.png --width 960 --height 544 --frames 243 --steps 20 --layers 45 --core-reuse 4 --token-reduction -o outputs/video_10s_544p.mp4

Key Technical Takeaways & Workflow Tips:

1. The Resolution Sweet Spot vs Monolithic Danger:

   While dropping native generation to 960x544 makes a 10-second (243 frames) monolithic generation technically possible (Test 6) using optimization flags (--layers 45 --core-reuse 4 --token-reduction), it pushes macOS memory management to its absolute limits. During the final VAE decoding phase, it triggered a massive swap spike reaching 64 GiB, which is dangerous for SSD wear and risks a system-level Killed: 9 crash if background apps are open.

2. Why Chunking Remains the Best Practice:

   Even though Test 6 succeeded, the safest and most hardware-friendly workflow for multi-second sequences on a 64GB Mac remains chunking into 5-second blocks (Tests 4 & 5) combined with --first-frame conditioning and lossless FFmpeg concatenation. It keeps the system well within physical RAM safety boundaries.

3. Prompt Structuring:

   Following MiniMax's native guidelines by splitting long prompts into explicit time-bracketed chunks (e.g., [0s-5s] followed by [5s-10s]) drastically improves narrative continuity across frames and helps the DiT model track actions properly over extended durations.

Massive thanks for writing this pure C/Metal implementation. It runs exceptionally well on Apple Silicon hardware!

[HuaChayu]

The M4's speed is quite slow. However, if we integrate a 4-step acceleration LoRA to run with just 8 steps, combined with a lower quantization version, it might be possible to keep the generation time for a 10-second video under 15 minutes. Plus, this approach would be much safer for memory usage, and the quality loss is acceptable.

[Henninges]

Hi @Slzx1, chiming in with M4 Max 128 GB data to complement the excellent 64 GB benchmarks from @Keylin2935.
Hardware: Mac Studio M4 Max, 128 GB unified memory, Metal 4
End-to-end timings (incl. weight loading, DiT, VAE, FFmpeg):
Resolution
Frames
Steps/Layers
References
Time
512×512
243 (~10 s)
20 / 45
1 image + audio
32 min (cold weight load)
512×512
243 (~10 s)
20 / 45
4 images + audio
21 min (warm cache)
Memory: Peak stays well within 128 GB physical RAM — no swap pressure, no SSD streaming needed.
GUI question: I built an unofficial bilingual web GUI wrapper for Ref2VA + FL2VA workflows (incl. Context-IR prompt builder, 9 image refs, 3 video refs, 3 audio refs). Would there be interest in a community tool like this? Published here: https://github.com/Henninges/h3-Studio
Key takeaways for lip-sync music videos: explicit "the person shown in Picture 1 sings the vocals, lips in perfect sync with the voice" in the Action field works reliably. References also carry pose cues — a back-view image may turn the person around mid-clip, so pin with "stays facing the camera".