We tried to make LTX 2.5 twice as fast on a Mac. Memory was the real problem.
We profiled LTX 2.5 video generation on Apple Silicon to make it dramatically faster. Attention turned out to be a tenth of the work and the weights were already at full speed. The real limit was memory, and fixing it halved the peak, made 1280 renders fit on a 64 GB Mac, and made 20-second clips possible. The study, the data and the fixes are now public.
19 September 2026Team COEY
LTX 2.5 is one of the best open video models you can run on your own machine. On a Mac it runs through ltx-2-mlx, an MLX port by Damien Grauet, and GroundSlate uses it for AI Video. We set out to make it dramatically faster. We came back with something different: the speed was already close to what this hardware allows, and the thing actually holding it back was memory.
This post covers what we measured, what worked, what did not, and why the result matters more than the speedup we were chasing. Everything is public: the study, all 73 measurement rows, the memory logs, the quality gates and the tools are in coeyai/ltx-2-mlx-speed-study, and the fixes that belong in the library are with its maintainer as a pull request and two proposals.
How we measured
One prompt, one seed, one Mac: a MacBook Pro with an M3 Max and 64 GB. Every render ran under a watchdog that reads the process's physical footprint every three seconds. That footprint is the number Activity Monitor shows, and it matters, because MLX keeps its weights in Metal buffers that the usual RSS figure cannot see. A render holding 41.7 GB showed 0.48 GB of RSS.
Quality was measured, not eyeballed: SSIM, LPIPS and VMAF against a reference, plus side-by-side stills. And the reference is exact. Two plain renders of the same seed on an idle Mac decode to identical frames, so any score below a perfect 1.000 means the picture really changed. That sounds like a small point. It is what separates "a bit faster and just as good" from "faster and a different video".
Attention is not the bottleneck
The popular speedups for video diffusion target attention: sparse attention, sliding windows, tile attention. They make sense on a big GPU with a long schedule. On this chip they have little to work with.
At the largest shape we render, attention is about a fifth of a transformer block. At 768x512 it is a tenth. We timed the ideal case, a kernel that looks at only a tenth of the keys and costs nothing else, and it would take at most 16% off a refinement step at 1280 and 9% at 768. MLX's attention is already a flash kernel, too: its memory is linear in the number of tokens at every size we tried.
We built one anyway. A windowed attention over a 3x3x3 neighbourhood of tiles, no custom kernel, took 22% off a 1280 render. The picture did not survive it: a ghosted double image, VMAF 1.5 against the normal render. The model was not trained for that pattern, and no amount of engineering on our side changes that.
The weights were no better a target. The 8-bit weights run within 13% of full 16-bit on the same matrix multiply, and 4-bit is no faster. Changing the schedule does not help either. The distilled sampler adds fresh noise at every one of its eight steps, so dropping a step or reusing a previous step's work does not give a faster version of your video. It gives you a different video.
Memory was the real limit
The peak of a render was never the transformer. It was the last step, the VAE decode that turns the latent into pixels: 53.4 GB at 768x512 for five seconds of video. At 704x1280 the decode never finished on a 64 GB Mac; the watchdog had to stop it at 52 GB.
The library already tiles the decode, but only in time, and its estimate of how much memory the decode needs was about 80 times too low, so at these sizes it never tiled at all. Forcing its temporal tiles on did not help at 1280 either: 52.9 GB, because the peak sits inside one chunk at full frame size.
Two changes fixed it.
Tile in space as well as time. Splitting the decode into 512-pixel squares as well as 40-frame chunks brought the 1280 decode from 52.9 GB to 26.4 GB for about two seconds more. The cost is the blend where tiles overlap, which scores SSIM 0.988 against a single pass. You can measure it against an exact reference. You cannot see it in the frames.
Stop the allocator hoarding. With the transformer kept in memory between renders, most of what remained was MLX's cache of freed buffers, memory nothing was using. Limiting that cache during the decode alone took the footprint from 44.2 GB to 25.8 GB, with identical pixels.
With those two, plus keeping the transformer between renders and freeing the text encoder once the prompt is read, a five-second render now peaks at 26.0 GB at 768x512 and 28.7 GB at 704x1280.
Why the memory matters more than speed
A render that fits in 26 GB instead of 53 changes more than a number on a chart.
The biggest shots fit. 704x1280, vertical HD, used to fail on a 64 GB Mac. Now it renders with room to spare.
Longer clips fit. Memory grows slowly and in a straight line with length, so a 20-second clip, 481 frames at 768x512, rendered at a peak of 27.8 GB. What limits length now is time, not whether the Mac runs out of memory.
Your Mac stays usable. A render that holds half the machine instead of all of it leaves room for everything else you have open.
The speed we did find
Two things made a real difference to how long you wait.
A preview that is really a preview. Running the refinement stage in one step instead of three is 1.55x faster, with the same seed, composition and motion. It is not a lower-quality copy. The gaze and the fine detail are not settled yet, so treat it as an audition of the shot. Getting there turned up a bug in the library: asking it for fewer refinement steps cut the schedule short, so it never finished removing the noise. The fix is with the maintainer now.
Finish the preview instead of starting over. The first stage of a preview is identical to the first stage of the full render. So the preview keeps that stage's output, under half a megabyte, and finishing it picks up from there. The finished video is bit-for-bit the full render, and auditioning then finishing costs 18 to 20% less than auditioning then rendering from scratch.
Smaller savings add up across a session: caching the prompt so a re-seed skips 8 to 9 seconds of text encoding, and keeping the transformer loaded between renders.
What we are sharing
The fixes that belong in the library have gone to its maintainer: the schedule fix as a pull request, and the decode memory and the two-phase render as proposals with the data attached. That is where they help the most people.
The study itself is at coeyai/ltx-2-mlx-speed-study, MIT licensed: every row, every log, every still, the dead ends as well as the wins, and the tools to re-run any of it. If you are working on video models on Apple Silicon, the dead ends may save you the most time.
In GroundSlate, it is already on
You do not need any of the above to use it. The memory work ships in GroundSlate's AI Video, on by default: tiled decodes where memory is tight, the bounded cache, the transformer kept between renders and cached prompts. The preview tier and the finish are in GroundSlate's generate_video tool, so an assistant working in GroundSlate can audition a shot and finish the one you pick. Everything runs on your Mac and nothing is uploaded.