mac mini 24gb success story
Community Feedback: Mac Mini M4 (24GB) Performance & V2 Update Findings
Hey! We've been heavily testing the new mmh3-turbo-clipproj4b-fl2va-v2-q4tp.cmf update on a Mac Mini M4 (24GB Unified Memory). Here are our complete findings regarding the V2 split-projection update, memory limits, and optimizations.
1. The V2 Update is a Massive Success
The split-projection layer completely solved the "Picasso-melting" issue.
Previously, on the 14GB Draft model, characters' faces would instantly smear or deform by frame 12 during movement. With the V2 patch, the identity and facial structure remain perfectly locked in. We get 25GB-level face consistency at 14GB generation speeds. This makes Draft Mode completely viable for actual production testing!
2. The 24GB Unified Memory "Sweet Spot"
Because the cortiq engine loads the model, DiT activations, KV cache, and the uncompressed video block into the same memory pool, the 24GB RAM limit creates a very strict ceiling before the system violently drops into SSD Swap Memory (which causes severe "Swap Thrashing" and stalls the GPU down to 0 Watts).
Safe Limits for 24GB M4 Mac Mini:
- High Quality / Cinematic Model (25GB):
- 512x256 (Standard): Safe up to ~70-90 frames.
- 768x448 (High-Res): Hard cap at 40-50 frames. Attempting 90 frames at this resolution pushes RAM to 22.2GB and Swap to 1.1GB, causing the GPU to stall and the generation time to balloon.
- Draft V2 Model (14.5GB):
- Because the model is 10GB smaller, it is much more forgiving with frame limits, but 448x768 at 90 frames is still the absolute physical threshold before memory paging begins. 50 frames at 448x768 is the golden sweet spot (averaging a blistering 136 seconds per step).
3. The VAE CPU Bottleneck (Reference Images)
When using a --first-frame reference image, the Video VAE Encoder runs entirely on the CPU (E-Cores at 100%, P-Cores asleep). This adds a massive ~100 second penalty to the start of the generation (e.g., encode 0/1 (140.8s)).
When doing pure Text-to-Video without a starting frame, this step drops to 0.1s. If Metal GPU shaders are ever implemented for the VAE's 3D-conv layer, generation times for Image-to-Video will drop significantly.
4. Bypassing the Strict mm_kill Timeout (100% GPU Success)
The qtensor.rs timeout budget (239ms) is currently too strict for the massive integrated multimodal prompt matrix multiplications. The engine kept falsely throwing the device contended, CPU for the rest of the process warning and falling back to the CPU.
Our Hack: We modified crates/cortiq-engine/src/gpu.rs to hardcode mm_killed() to false and gutted mm_kill().
The Result: Flawless success. The denoise loop ran at 100% GPU utilization (15.6W) without a single crash or graphical glitch. The engine successfully chewed through 50 frames of 448x768 in just 9 minutes. The fallback logic is overly aggressive for standard desktop use!
5. Lifting the Apple Metal Limits (Sysctl)
Apple Silicon artificially limits Metal buffers to ~13.6GB. To run the 25GB Cinematic Model, users must run sudo sysctl iogpu.wired_limit_mb=... to allocate more RAM to the GPU. Without this, the engine fails to map the model into memory. We highly recommend adding a warning or helper script in the documentation for Mac users so they know they need to manually lift this limit!
anime cooking clipi
same script but photo realism
Both halves of this report are in cortiq 0.5.80 (out now: cargo install cortiq-cli, or the release binaries):
- The
mm_killhack is no longer needed. The contention kill is disarmed for the whole prompt-encode phase and arms only when the denoise loop starts — the encoder is a one-shot pass over 12 GB, and on a 24 GB box it streams from disk for reasons that are not contention. Three consecutive strikes are still required after that.CMF_MM_KILL=0remains as the big switch. - P-cores for the keyframe encode. Your
asitop(E-cores at 100%, P-cores asleep during the--first-frameVAE encode) was the pool's worker threads landing wherever the scheduler put them; they now ask forQOS_CLASS_USER_INITIATED. That shortens the ~100–140 s encode; a device path for the encoder's 3-D convolutions is the real fix and is on the list. - Your frame budgets are in the model card (Field notes): 25.7 GB file — 512×256 safe to ~70–90 frames, 768×448 caps at 40–50; v2 14.5 GB file — 448×768 × 50 frames at 136 s/step, 90 frames is the paging edge. And the v2 face-consistency confirmation, in your words.
Thank you — please break it again.
Cortiq v0.5.82 Field Report: I2V Pipeline & Memory Stress Testing
Hardware: Apple Mac Mini (M4, 24GB Unified Memory)
Model: mmh3-turbo-clipproj4b-fl2va-v2-q4tp.cmf (14.5 GB)
Resolution: 768x448
1. Validating the v0.5.82 Upgrades
The latest adjustments to core scheduling and contention detection are working exactly as intended. We ran several Image-to-Video (--first-frame) benchmarks to validate the pipeline:
- P-Core Wakeup (
QOS_CLASS_USER_INITIATED): Successfully verified. During the massive 12GB prompt-encode phase, macOS properly routed the workload.asitopreadings showed P-cores pinned at100% @ ~3900 MHz, while E-cores hovered around70-96%. mm_killDisarmament: The engine no longer throws false-positive contention kills during the heavy initial VAE encode. The 164–174 second image encode phase completes smoothly, allowing the engine to successfully transition into the denoise loop.- Performance Parity: For a 39-frame I2V generation, the overall denoise speed stabilized at ~18.0 seconds/step. This perfectly matches our historical averages for standard Text-to-Video runs, meaning the engine is absorbing the heavy I2V encode overhead without degrading overall batch performance.
2. Pushing the "Paging Edge" (How We Break It)
We specifically set out to test your hypothesis regarding the memory paging edge. While you estimated the edge to be around 90 frames for the 14.5 GB v2 model, our telemetry suggests the true cliff for a 24GB machine is much lower—likely right around 50 frames.
The "Nuke Test" (120 Frames)
To completely break the engine, we launched a 120-frame I2V generation. Here is the lifecycle of the system collapse:
- Encode Phase: Survived. RAM sat comfortably at ~5.7GB.
- Transition to Denoise: As the engine allocated the massive 120-frame latent tensor, the system instantly flatlined into swap death.
- Telemetry at Collapse:
- Physical RAM:
22.0 / 24.0 GB - Swap:
4.0 GB used / 5.0 GB capacity(macOS forcefully doubled the swap capacity in real-time to prevent a kernel panic). - GPU Usage: Plummeted from ~77% down to 53% (and falling) as the cores starved waiting for data to be dragged across the swap boundary.
- Physical RAM:
We manually bailed out (SIGINT) right as denoise 1/4 began to spare the SSD, so we didn't wait to see if the 3-strike mm_kill would formally execute the process. However, the system was undeniably thrashing.
Conclusion:
The 0.5.82 engine is remarkably stable and fast. 40-frame runs are the undisputed "sweet spot" for 24GB hardware (~20.1GB RAM used, 0.9GB swap). Pushing beyond 50 frames invites steep swap penalties, and 120 frames is a guaranteed system stall.
Thank you for the excellent update!
"Claire's Day"