Why self-host at all
The honest answer for most teams is not price. It is that a hosted API can change, reprice or disappear, and a model on your own hardware cannot.
- No deprecation risk. The model you validated is the model you keep running.
- No per-second billing surprises when a campaign scales unexpectedly.
- Data stays on your infrastructure, which matters for unreleased product footage and confidential material.
- You can fine-tune and pin, including LoRA adapters trained on your own assets.
The deprecation argument is the strong one: if you have ever been through an API shutdown, the value of a pinned version you control is obvious. If you have not, you will probably underweight it.
The economics honestly
| Volume | Hosted API | Self-hosted |
|---|---|---|
| Occasional, a few clips a week | Much cheaper | You pay for idle GPU |
| Steady moderate use | Usually cheaper | Approaching parity |
| Sustained high volume | Cost scales linearly and can hurt | Often cheaper per finished minute |
| Bursty with long idle gaps | Far cheaper | Poor fit unless you can scale to zero |
The crossover point depends on your GPU cost and utilisation. Model it with your own numbers rather than assuming self-hosting is cheaper — at low volume it almost never is.
What hardware you actually need
- VRAM is the binding constraint, not compute. Model size plus the resolution and clip length you want determines whether it runs at all.
- Quantisation trades some quality for large memory savings, and is often the difference between running and not running on available hardware.
- Generation time per clip matters for workflow. A model that takes ten minutes per clip is unusable regardless of quality.
- Consumer cards can run smaller models and shorter clips; longer high-resolution work generally needs more VRAM than a single consumer card provides.
Measure end-to-end: benchmark the full pipeline — load, generate, decode, write — on your hardware with your typical settings. Published benchmarks rarely match your setup.
What you gain: reproducibility
This is the underrated benefit and often the real reason teams move.
- Output is deterministic for a given seed and version, which makes A/B testing meaningful.
- You can freeze a model version and never worry that an update changes your output.
- Fine-tunes and LoRA adapters trained on your own assets become a durable competitive asset.
- Audit and compliance are simpler when nothing leaves your infrastructure.
What you give up
| You lose | Why it matters |
|---|---|
| Invisible improvements | Hosted models improve behind the API; yours only improves when you upgrade it yourself |
| Convenience | Setup, driver management, scaling and failure handling become your problem |
| Peak capability | The very largest models are often hosted-only for practical reasons |
| Elastic capacity | A deadline spike cannot be absorbed by adding GPUs in a minute |
Licence terms are not all the same
“Open weights” is not a single category. Read the licence before commercial use.
- Some licences permit commercial use freely.
- Some restrict commercial use above a revenue threshold.
- Some restrict redistribution or require attribution.
- Fine-tune rights and output ownership can differ from the base model terms.
Check before you build on it: licence friction discovered after you have built a pipeline is expensive. Verify commercial terms at evaluation time, not at launch.
How to decide
-
Measure your actual volume
Clips per week and minutes of output. Guess and you will get the decision wrong.
-
Price both options on list rates
Hosted at list price, not promotional. Self-hosted including GPU amortisation, power and your maintenance time.
-
Weight reproducibility
If you need to prove output has not changed, self-hosting may be worth a premium.
-
Check the licence
Confirm commercial use is permitted for your situation.
-
Prototype before committing
Run your real workload on rented hardware for a week. The measured numbers will settle the argument.