Your plan vs the measured plan

Your plan is the one from the voice note: measure both machines → find bottlenecks → decide DGX or server room → render farm as stage two/three → push to 100 clips a day.

Direction
Right

Measuring before buying is exactly how we found the DGX ties a laptop.

Order
One step missing

Fix the single machine before building a farm of them.

Blind spot
The review loop

The plan is about render throughput. The bigger cost is rounds per reel.

Picture 1

Where your plan is right now.

✓ Done
Measure compute on the DGX
Every stage, codec, core and GB — report, zip and this site.
◐ Half
Measure on the MacBook
Only the screenshot table. No stage breakdown, and the one fact that matters most is unknown: which encoder it uses.
✓ Done
Find the bottlenecks
Nothing runs in parallel · picture encoded 3× · transcription 2.1× oversubscribed · 78 % of a text change wasted.
○ Not started
Optimise the compute
Zero lines of the pipeline changed so far.
◐ Answered
Decide: DGX or server room
Data says neither is the constraint yet. Decide after the code is fixed, not before.
○ Not started
Push to 100 clips a day
Not attempted. Still the only way to find the real wall.
○ Not started
Render farm across machines
Premature — see Picture 2.

Picture 2

Your order, and the order the measurements point to.

Your plan

1
Measure DGX + MacBook
2
Find the bottlenecks
3
Decide hardware — DGX or server room
4
Render farm — laptops + servers join the network
5
Push to 100 clips a day

Revised

1
Measure DGX + MacBook finish the Mac half — ask which encoder it uses
2
Find the bottlenecks done
3
Fix one machine first new · proxy + cache + repeatable renders · ~half a day
4
Push to 100 clips a day moved up · now you find the real wall, not the known ones
5
Decide hardware — with real numbers in hand
6
Render farm — only if 100/day doesn't fit moved down · projected ~2.6 h/day on one box after the fixes

Why the farm moves down: today every machine in it would run at 8 of 20 cores with two processes. A farm multiplies the waste — and adds shipping 1.27 GB masters and ~58 GB/day of scratch files over the network.

Picture 3

Where we agree, and where we don't.

"Compute doesn't solve it"Confirmed. The DGX spent 3.6× the CPU of the MacBook and finished in the same time.
Push 100/day to find the constraintsAgreed. My bet: human review breaks first, then ASR memory, then storage. Cores last.
Use the server roomAgreed — as the pool for final renders. 120 cores, already paid for.
Farm before fixing one nodeA farm doesn't make any single reel faster. It only runs more of them at once.
Throughput vs roundsThe plan never mentions the review loop. At 100/day × ~6 rounds, that's 600 review cycles. That is the real constraint.
"Do we need the DGX?"Wrong question. It's not for ffmpeg — it's for transcription and a model that checks b-roll fits the story.

Picture 4

What each path gets you.

TodayYour path
4-machine farm, code as is		Revised path
fix the code, one box
See a change
one review round		91 s91 s~8 s
100 final renders2.5 h~40 min~30 min
Build effort—job queue, network, ship footage to 4 machines~75 lines for the loop · ~200 for everything
Machines needed14+1 — the one you have

Both batch numbers are projections from measured factors, not end-to-end runs. The ~8 s proxy is an estimate until it's built. The row that matters is the first one — it's the loop you sit in a hundred times a day, and a farm doesn't touch it.

← measurements · the plan in diagrams