FFmpeg on serverless: CPU vs GPU, cold vs warm, cost per job

Both campaigns ran the same FFmpeg 9.0.1 build, the same 60-second fixtures stored in Cloudflare R2 (a 1080p source, a 4K source, a 720p clip for concatenation and picture-in-picture, a captions file and an alpha watermark) and the same recipe matrix, which is the set of constrained operations KinoPipe exposes as typed tools: H.264 fast and balanced transcodes, 4K downscale, portrait 9:16 crop, subtitle burn-in, watermark, picture-in-picture, two-clip concatenation, VP9, a 4 s GIF and MP3 extraction. GPU runs target H.264 through NVENC. VP9, GIF and audio stay on CPU because the current pipeline does not accelerate those codecs on NVIDIA hardware.

The RunPod campaign retained 325 successful runs and no failed measured run, with separate cold, warm, burst and tuning phases and at least 5 repetitions per comparison. Its warm matrix covered eleven CPU recipes and eight NVENC-compatible GPU recipes. RunPod latency is end to end, delayTime + executionTime, with client polling delay stored separately. The Cloud Run campaign retained 95 successful warm runs, one warm instance of each type, 5 repetitions per provider and scenario; latency there is direct HTTPS end to end including the R2 input download and output upload.

Every run records end-to-end latency, worker total time and FFmpeg-only time, download, probe and upload time, FFmpeg speed versus real time, input and output bytes, the exact CPU model, logical CPU count, RAM, FFmpeg build and visible NVIDIA GPU, and an estimated job cost from the configured hourly rate. Cost figures below are estimates from those rates: RunPod billing data was still lagging the final campaign when the endpoints were deleted.

The RunPod 16 GB endpoint requested the Ampere category; the worker actually measured was an RTX A4000. RunPod Serverless does not guarantee a specific GPU model inside a generic category, which matters when you read the GPU rows below.

The three headline recipes on RunPod, warm workers, 60 s inputs. "Tuned" means the NVENC CQ and thread settings adopted at the end of the campaign, described further down.

Two things stand out. The A40 at $1.224/h matched the cheaper GPU pool on 1080 fast and was slower on the other two recipes, so it buys nothing for these workloads. And the 8 vCPU CPU worker at 16 threads lands within 0.7 s of the GPU pool on 1080 fast; the GPU advantage only becomes decisive on the balanced preset and on 4K input.

Hourly rates are hard to compare across providers with different billing bases, so here is the same table as compute cost for one thousand 60 s 1080p fast jobs, computed as rate multiplied by the measured p50 and nothing else. No storage, no egress, no queue wait, no minimum billing window.

Cloud Run L4 is instance-based with a 60 s minimum, so an isolated job that wakes an instance is billed for at least 60 s. Cloud Run CPU adds $0.40 per million requests, negligible at this scale, and an idle minimum instance on that shape costs about $0.216/h before free-tier discounts. These are compute figures for provider selection, not KinoPipe's credit pricing, which also covers storage and delivery.

With workersMin: 0, the first request pays for the container start. On RunPod CPU the cold H.264 fast p50 was 18.1s on 4 vCPU and 11.4s on 8 vCPU, against 13.5s and 10.0s warm. The first encode after rolling the final GPU image took 23.9s, then 6.8 to 8.7 s for the following warm requests.

A fresh Cloud Run revision returned 13.5s on CPU and 10.9s on the L4 for the first request, but container timestamps show Cloud Run had started both workers about 19 seconds earlier as part of the revision rollout. We keep those as post-deployment, pre-warmed measurements, not as cold-start proof. A strict scale-to-zero cold campaign has to wait until the platform actually terminates the idle instances, and we have not run it yet.

Twenty jobs submitted at once, which is the shape of an agent fanning out a batch. Latency includes real scale-out where noted.

The GPU p95 of 20.0s includes scaling from one warm worker to four. One operational lesson: RunPod configuration PATCHes can report the new worker maximum before the data plane accepts requests, so control-plane propagation must be excluded from measured runs.

Cloud Run request logs classify the CPU failures as "no available instance": the client received 5 HTTP 500s and 2 HTTP 429s in the scale-from-one run, and only 2 additional instances started during the burst. Quota was not the limit: europe-west1 exposed 200 vCPU and 400 GiB while the test needed 32 vCPU and 64 GiB at concurrency four. Requesting four minimum instances only raised success to 80%. Concurrency three completed reliably. Direct synchronous FFmpeg traffic to Cloud Run therefore needs idempotent retry with backoff for 429 and infrastructure 500 responses, or, better, an asynchronous queue in front of it.

The full warm matrix on Cloud Run, one warm instance of each type. The speedup column is CPU p50 divided by L4 p50.

Cloud Run CPU performance turned out to be host-dependent even with an identical advertised shape. The same VP9 recipe took 86.4 to 90.6 s on AMD EPYC placements and 139.6 to 169.8 s on a generic Intel Xeon 2.80 GHz placement. The five 16-thread VP9 runs all landed on EPYC 9B14 and were much tighter, 82.9 to 86.5 s.

The whole Cloud Run warm matrix cost about $1.33 before free tier, network, storage, build and invoice rounding: $0.509 of active CPU time plus $0.032 of idle minimum, and $0.793 for the L4 over the 45.46-minute wall clock. The recorder's own sum of request-duration compute was $0.664, which understates the deliberately warm L4 because it excludes the time spent waiting for CPU runs.

Benchmarks are only useful if they change the defaults. Three did.

VP9

Balanced VP9 now uses deadline=good, cpu-used=4, row multithreading and two tile columns. Explicit encoder threads stay optional because FFmpeg's default was as fast or faster on the tested 4 and 8 vCPU shapes.

Quality moved from SSIM 0.98278 to 0.98254 at an unchanged PSNR of 28.98 dB. Output size grew from 67.2 to 73.2 MB, a deliberate 9% storage trade for the compute reduction.

CPU threads

For H.264 fast, forcing threads made the 4 vCPU worker slower, so it keeps FFmpeg's auto-selection. On 8 vCPU, 16 threads improved p50 from 10.0s to 8.9s. On the Cloud Run 8 vCPU service, 16 threads beat 8 on H.264 fast (22.2s to 19.2s, -13.6%) and on VP9 (90.6s to 84.8s, -6.4%). Going from 4 to 8 FFmpeg and filter threads on the 4 vCPU L4 shape made 4K slower, 26.6s to 28.3s, so that shape keeps 4.

NVENC constant quality

The original CQ mapping over-produced quality and bytes. The validated defaults are now CQ 34 for fast and CQ 29 for balanced; the quality preset keeps its previous mapping because it was not part of this tuning gate.

Smaller outputs also shorten the R2 upload and cut storage and egress. One build detail worth knowing: the GPU images pin nv-codec-headers 12.2. The 16 GB pool exposed NVENC API 12.2 while the A40 exposed 13.0, and building against 13.x broke the cheaper pool.

RunPod Serverless is KinoPipe's single compute provider, with two endpoint classes: the 4 vCPU CPU shape as the cost-first default for ordinary H.264, VP9, GIF and audio, and the 16 GB Ampere-category GPU pool for 4K, composition-heavy H.264 and latency-sensitive bursts. The A40 is out: more than twice the price and not faster for these recipes. Both endpoints start at workersMin: 0; a warm worker only gets added when observed traffic makes its latency benefit worth the continuously billed idle time. R2 stays the shared input and output store. The tested Cloud Run L4 service is technically sound and remains a fallback.

The trade-offs are explicit. Scale-to-zero means the first job after idle pays the 18.1s cold start on CPU. The generic GPU category can hand you a different card than the one you benchmarked. And any provider needs an asynchronous queue in front of FFmpeg for bursts, which is why every KinoPipe edit is a job you poll or receive by webhook rather than a synchronous request. That is also what lets compound edits compile to a single FFmpeg pass instead of a chain of re-encodes.

• Cost per job is derived from configured rates and measured p50, not from invoices; RunPod billing data was still lagging when the endpoints were deleted.
• The 4K pipeline still decodes and scales in software on the GPU. CUDA and NPP filters are the next optimisation to test and could change the 4K rows.
• No strict scale-to-zero cold campaign on Cloud Run yet; its cold numbers above are pre-warmed by the rollout.
• One region and one day per provider. Cloud Run CPU placement varied between AMD EPYC and Intel Xeon hosts within the same shape, which is a variance source we cannot control.
• The RunPod GPU category did not deliver the requested model; results are for an RTX A4000, not a guaranteed Ampere SKU.
• SaladCloud and Koyeb were set up but not run: the organisation and images exist, no paid container was created.
• Quality (SSIM and PSNR) was checked on the tuned recipes only, not across the whole matrix.

The harness lives in the KinoPipe repository under benchmark/. It runs the same constrained recipes on RunPod, SaladCloud, Koyeb and Cloud Run, stores fixtures and outputs in R2 and writes JSONL, CSV and Markdown comparisons. It does not provision provider resources, and external provider calls are disabled unless --execute is passed. The steps, in order:

npm --prefix benchmark install
npm run bench:check            # local setup
npm run bench:check:r2         # one R2 bucket HEAD request
npm run bench:fixtures -- --generate
npm run bench:fixtures -- --upload
cp benchmark/config.example.json benchmark/config.json   # enable providers, fill current rates
npm run bench:run -- --execute
npm run bench:report
npm run bench:quality          # SSIM / PSNR on the outputs

If you rebuild it elsewhere, keep the three things that make results comparable: the same FFmpeg revision on every provider, the same fixtures, and cold, warm and burst measured as separate phases. Comparing advertised hourly prices without startup, idle timeout and provider queue behaviour tells you very little.