Making one of these videos is four different jobs, and only one of them runs on a machine you can rent. That is the whole reason a bigger CPU keeps disappointing you.
Reading the script, deciding what each scene shows, writing the animation code.
Narration is generated, then transcribed back to line up every word with the picture.
Copies of a browser draw all ~5,700 frames, then they get squeezed into an MP4.
Frames get pulled out and inspected, then the file is filed and uploaded.
The design work is not a heavy calculation that a faster chip finishes sooner. It is a language model reading your script and writing code, and that happens on servers you do not own. There is no setting on your machine that speeds it up, and there is no GPU in the world that touches it.
So a 32-core box makes one of the four stages faster. Which raises the obvious question: how much faster?
This is the part that explains your 1.35×. A render has three phases, and only the middle one gets faster with more cores.
If roughly a third of the job refuses to run in parallel, then even an infinite number of cores only gets you about 3×. Sixteen cores landing at 1.35× sits right in that range. Doubling to 32 does not double anything: you are pushing harder on the one phase that was already the fast part.
Two things also quietly cap it. Each parallel worker is a full copy of a browser, so memory runs out before cores do — set the worker count too high and it gets slower, not faster. And frames stream to disk, so a slow drive throttles the whole thing.
Ranked by how much time each one gives back, not by how technical it sounds.
This is not a hardware trick and it beats every hardware trick. A full pass of 36 modules is about three and a half hours. Catching a mistake before the render instead of after is worth more than any machine you can rent, because it removes a whole pass instead of shaving one.
Here is the key idea: one video does not split well, but thirty-six videos split perfectly. Four machines each taking nine modules is close to four times faster, with none of the ceiling above. Rent width, not depth.
The official tool for exactly this. It chops one video into many small pieces, renders them on hundreds of cloud machines at once, and stitches them back together. Remotion says most people render several minutes of video for a few pennies. It needs an AWS account set up once, and a licence check for commercial use.
There is a sweet spot and it is findable rather than guessable — Remotion ships a benchmark command for it. Above the sweet spot you lose time to memory pressure.
The two serial phases care about how fast one core is, not how many there are. A high-clock 8-core often beats a slow 32-core for this work.
Half-size, cheaper compression while you are still deciding things. Only the final approved pass needs to be perfect.
Only helps 3D and WebGL work — Three.js, maps, shader effects. These videos are text, shapes and motion, which the processor draws. Confirmed in Remotion’s own docs.
Stages 1 and 2 happen on other people’s servers. No machine you buy or rent participates.
| If you want to… | Do this | Not this |
|---|---|---|
| Finish a batch of 36 sooner | Two to four modest machines, each rendering a different slice of the list | One very large machine |
| Get a single video out fast | Cloud render farm, or accept the ceiling | More cores |
| Speed up the design work | Nothing hardware can do. It is model quality and how much gets caught before rendering | CPU, GPU, RAM |
| Stop wasting whole passes | Automatic checks before the render, which are free and instant | Rendering and then looking |
Two jobs rendering on the same machine fight over it and both get slower. That is what happened here: a stray render was still running alongside the main queue. Before renting anything, make sure only one render owns a machine at a time — it is free and it was worth more than the 1.35×.
Speed figures for the two serial phases are illustrative of the shape of the problem, not measured on your exact project; the ratio shifts with module length. Everything about what does and does not use the GPU, and how the cloud farm splits a render, comes from Remotion’s own documentation: Performance, Using the GPU, Lambda.