{"slug": "fasth3-on-apple-silicon-and-dgx-spark", "title": "FastH3 on Apple Silicon and DGX Spark", "summary": "FastH3, MiniMax's video-and-audio generation model, now runs on Apple Silicon via MLX and on NVIDIA's DGX Spark desktop, with two Sparks able to generate one clip together. The release also debuts the FastVideo Cookbook, featuring MiniMax H3 with CUDA, native MLX, and a local OpenAI-compatible server. On an Apple M4 Max with 36 GB of unified memory, a four-step INT6 run reduced denoising time from 386.47 to 348.75 seconds with bit-exact latents, while peak memory rose slightly to 19.46 GiB.", "body_md": "FastH3 now runs on a Mac and on NVIDIA DGX Spark. Two Sparks can generate one clip together.\n\nH3 generates video and audio together. That used to mean a data-center GPU.\nOur [FastH3 Preview](/blogs/fasth3-preview/) distilled it into a few steps on\nBlackwell. This release puts that model on Apple Silicon through MLX, and on a\ndesktop GB10 through CUDA 13. The Mac path needs 36 GB of unified memory or\nmore. Spark has 128 GB.\n\nThis post also publishes the [FastVideo Cookbook](/FastVideo/cookbook/) for\nthe first time. MiniMax H3 is on it, with CUDA, native MLX, and a local\nOpenAI-compatible server.\n\n## Generated locally[#](#generated-locally)\n\nThe same prompts on an Apple M4 Max, a DGX Spark, and four GB200s. Turn the audio on.\n\nThose six clips are the same recipe: 832×480, 124 frames, four-step FastH3, full VAE. The chart splits a first generation from a repeat. Spark repeat is a second generate in the same process, not a loaded server. Qwen and DiT still reload. Most of those 20 to 31 seconds are VAE compile already paid. GB200 is a loaded server. 350 s of model start sits outside both bars.\n\nOn the Mac, denoising is most of the wait. On Spark with the full VAE, decode is.\n\n## INT8, INT6, and INT4[#](#int8-int6-and-int4)\n\nEvery Mac number in this post comes from an M4 Max with 36 GB of unified memory.\n\nINT8 keeps more of the original weights. INT4 leaves the most room for activations. INT6 is the default we timed. Wall clock barely moves across the three. Peak memory does. Same prompt, same seed.\n\n## How H3 runs on a Mac[#](#how-h3-runs-on-a-mac)\n\nThe weights are only part of the problem. H3 also needs a large text encoder, working memory for denoising, and decoders for video and audio. Load all of that at once on a 36 GB Mac and there is nothing left to generate with.\n\nSo the runtime never tries. It runs in phases. Encode the prompt, denoise, decode, export. Each phase loads what it needs and frees the rest.\n\n**Encode** Stream the text encoder\n\n**→**\n\n**Denoise** Video and audio together\n\n**→**\n\n**Decode** Frames and soundtrack\n\n**→**\n\n**Export** One synchronized MP4\n\nH3 reads an intermediate layer of Qwen3-VL, so the encoder skips the last 14 layers. It streams the rest one layer at a time and keeps only the embedding rows the prompt uses. An uncached prompt used to spend about 80 seconds here. A single bounded read per tensor brings that to about 17 seconds, with the same hidden features. Cache those embeddings and the next prompt skips this stage.\n\nAfter denoising, tiled video decode and a native audio decoder finish the clip without rebuilding the whole frame buffer at once.\n\nSmaller weights are not always faster. H3 multiplies large video and audio matrices. At those shapes, unpacking a quantized weight into BF16 and using MLX’s dense matrix multiply beat the quantized kernel. The unpacked copy is discarded after the multiply.\n\nOn a four-step INT6 run, denoising dropped from 386.47 seconds to 348.75 seconds. The video and audio latents were bit-exact. Peak MLX memory rose from 19.31 GiB to 19.46 GiB. That run used 832×480, 124 frames, and dense attention, so this is the matmul path, not Video Sparse Attention.\n\nThe Mac path still implements Video Sparse Attention. Selected video tiles attend. The rest do not.\n\n## FastH3 on DGX Spark[#](#fasth3-on-dgx-spark)\n\n[DGX Spark](https://www.nvidia.com/en-us/products/workstations/dgx-spark/)\nis a desktop Blackwell machine. GB10 GPU, 128 GB of unified LPDDR5X, CUDA 13,\nARM64. The FastH3 CUDA path from the Preview release now runs on that box.\n\nThe model fits. Loading it the usual way does not.\n\nThere is no separate VRAM. CPU and GPU share one pool, at roughly 270 GB/s, about a tenth of datacenter HBM. FastH3’s encoder, transformer, and decoders add up to more than the 121 GB a workload actually gets. Keep them all resident and the process dies before the first frame.\n\nSo the pipeline never holds them together. It encodes the prompt, drops the text encoder, loads the transformer, denoises, drops the transformer, then loads the VAE. Patch size and compression ratios come from the checkpoint config, so decode does not keep a 65 GB DiT loaded just to read a patch size.\n\nOn a discrete GPU, copying weights to the host frees device memory. On Spark that copy lands in the same pool. We stopped it. DiT weights load straight onto the GPU. On one GB10 that cut the transformer load from 445 seconds to 39 seconds, and a 768×1344, 124-frame run from 772 seconds to 336 seconds.\n\nH3 never uses the last layers of its text encoder. The Spark path skips them,\nsame as the Mac path. Video Sparse Attention stays on CUDA. The FastVideo\nkernel builds from source for `sm_121`\n\n.\n\nTwo Sparks can run that clip together. Sequence parallel splits denoising and decode across both GB10s over the QSFP link. Each box still loads components in phases. The transformer is copied onto both, so neither can skip the phased load.\n\nOn the same 768×1344, 124-frame recipe, two Sparks finished in 292 seconds. One Spark took 374. TAEH3 on that pair was 195 seconds. A 345-frame clip, about 14 seconds of video, finished in 581 seconds on the pair with the full H3 VAE.\n\nInstall from the\n[CUDA 13 Spark guide](/FastVideo/getting_started/installation/spark/). For two\nboxes, follow the\n[pair guide](/FastVideo/getting_started/installation/spark_pair/), then pick a\nCUDA recipe in the [Cookbook](/FastVideo/cookbook/minimax-h3/).\n\n## Full VAE versus TAEH3[#](#full-vae-versus-taeh3)\n\nThe full H3 VAE is the quality path. [TAEH3](https://github.com/madebyollin/taehv)\nis the preview path. It reconstructs the same latents much faster, and fine\ndetail goes softer. Hair, fabric, and distant backgrounds lose bite.\n\nOn an M4 Max, tiled H3 VAE decode took 104 seconds. TAEH3 took one second. On one Spark, VAE decode was 114 seconds and TAEH3 was 1.3 seconds. End-to-end with TAEH3 was 134 seconds on that box, 119 seconds on two. At 768×1344 on two Sparks, TAEH3 decode was 12.5 seconds and the clip finished in 195 seconds. Use TAEH3 to check a prompt. Render with the full VAE when you like what you see.\n\nSame prompt and seed. First row is the full VAE. Second row is TAEH3. Columns are an M4 Max, one Spark, and two Sparks.\n\n## Faster drafts[#](#faster-drafts)\n\nA native-resolution clip takes a while. That is fine for a final render. It is a lot to pay to find out the prompt is wrong.\n\n`--fast`\n\ndenoises fewer video frames, then interpolates back to 124.\nThis run generated 73 frames. RIFE filled the rest. Audio keeps its full\nduration.\n\n`--fast-spatial`\n\ndenoises a smaller canvas, then resamples up. The clip\nbelow is the conservative setting, 672×384 up to 832×480. Composition and\nfine detail get softer. Treat it as a preview knob, not a final render.\n\nSame prompt and seed on the M4 Max. INT6, cached prompt, full VAE.\n\n## FastVideo Cookbook[#](#fastvideo-cookbook)\n\nOpen the [Cookbook](/FastVideo/cookbook/), pick a model, pick a recipe, and copy\na command we actually run.\n\nH3 is there with CUDA, the four-step preview, LoRA, native MLX, and a two-Spark recipe.\n\nYou can also serve FastH3. Start the server once on CUDA or on MLX. Then\nchange prompts from the playground, from cURL, or from an OpenAI-compatible\nSDK in your app. Later prompts reuse that process. You do not reload the\nmodel for every try. Open the [H3 recipes](/FastVideo/cookbook/minimax-h3/)\nor the [server guide](/FastVideo/cookbook/openai-api/). Spark users should\ninstall from the\n[CUDA 13 Spark guide](/FastVideo/getting_started/installation/spark/) first.\nTwo boxes should follow the\n[pair guide](/FastVideo/getting_started/installation/spark_pair/).\n\n**Maintained inference recipes, starting with MiniMax H3. Distillation, training, and evaluation land in the same catalog as they ship.**\n\n[FastVideo Cookbook](/FastVideo/cookbook/)We are still cutting latency, adding distilled models, and looking at schedules with fewer than four steps. The RTX family, including the 5090 and 4090, is the next CUDA focus.\n\nApple just announced\n[M6 in the Mac mini and M5 Ultra in the Mac Studio](https://www.apple.com/newsroom/2026/08/apple-introduces-m6-and-m5-ultra-for-a-big-leap-in-performance-and-ai-compute/).\nWe have not run FastH3 on those, or on M5 Max or M5 Pro Mac mini. Every Mac\nnumber here is from an M4 Max. The MLX path is the same on those chips. They\nshould be faster, especially M5 Ultra with its unified memory and GPU. We\nwant to measure them.\n\nIf you measure a new machine, improve a kernel, or hit a bug, start from the\n[contribution guide](/FastVideo/contributing/overview/) or the\n[repository](https://github.com/hao-ai-lab/FastVideo). Include hardware,\nsettings, timings, and the output.\n\n## Acknowledgements[#](#acknowledgements)\n\nFastH3 builds on [MiniMax H3](https://huggingface.co/MiniMaxAI/MiniMax-H3).\nWe thank the MiniMax team for releasing its weights and code.\n\n[Nuva Lab](https://nuvalab.ai/) and\n[NVIDIA FastGen](https://github.com/NVlabs/FastGen) collaborated on\n[FastH3 Preview](/blogs/fasth3-preview/).\n\nWe thank Ollin Boer Bohan for [TAEH3](https://github.com/madebyollin/taehv),\nthe optional preview decoder this release uses. The Mac path is built on\n[MLX](https://github.com/ml-explore/mlx) and the community around it.\n\n## FastVideo team[#](#fastvideo-team)\n\n**Contributors:** Aryan Kumar\n[\n](https://github.com/aryan5v)[,\nSatyam Srivastava\n](https://x.com/aryan_xv)[\n](https://github.com/Satyam-53)[,\nKyle Hu\n](https://x.com/Sat_53)[,\nIshan Vaish\n](https://github.com/KyleNeverGivesUp)**Tech lead:** Will Lin\n[\n](https://github.com/SolitaryThinker)**Advisor:** Hao Zhang\n[\n](https://github.com/zhisbug)", "url": "https://wpnews.pro/news/fasth3-on-apple-silicon-and-dgx-spark", "canonical_source": "https://haoailab.com/blogs/fasth3-local/", "published_at": "2026-09-01 07:00:00+00:00", "updated_at": "2026-09-01 19:25:22.546434+00:00", "lang": "en", "topics": ["artificial-intelligence", "generative-ai", "ai-products", "ai-infrastructure"], "entities": ["MiniMax", "Apple", "NVIDIA", "DGX Spark", "FastH3", "MLX", "CUDA 13", "M4 Max"], "alternates": {"html": "https://wpnews.pro/news/fasth3-on-apple-silicon-and-dgx-spark", "markdown": "https://wpnews.pro/news/fasth3-on-apple-silicon-and-dgx-spark.md", "text": "https://wpnews.pro/news/fasth3-on-apple-silicon-and-dgx-spark.txt", "jsonld": "https://wpnews.pro/news/fasth3-on-apple-silicon-and-dgx-spark.jsonld"}}