Self-host open video models or call a hosted API?

Updated 2026-10-17

Open-weight video models make self-hosting tempting, and for some teams it is the right call. For many it is not, for reasons that show up in operations, not in the model. This page lays out what each path actually involves so you can decide on the work, not the sticker price.

What "build" really contains

Running a model is the easy part. The system around it is the work:

• GPU capacity and scheduling. Video models are memory-hungry and a single generation can occupy a GPU for minutes. You provision for peak or accept queueing, and you pay for idle time between bursts.
• A job queue. Generation is long-running, so you need a durable queue, worker heartbeat, timeouts, cancellation, and a status endpoint. A synchronous HTTP handler will not survive.
• Model and dependency management. Checkpoints, CUDA and library versions, quantisation choices, and re-validating output quality every time you upgrade.
• Storage and delivery. Outputs need storing, signing and expiring.
• Observability. Per-job latency, failure causes, GPU utilisation, cost per accepted clip.
• Staying current. Newer releases keep arriving, and each one is a new deployment to evaluate.

What "buy" contains

A hosted API collapses most of that into POST /videos and polling. With a gateway like VideoRouter you additionally get several hosts per model behind one request shape, so the failure mode "my provider is down or throttling" becomes a retry on another host serving the same checkpoint rather than an outage. Billing is per request from the requested duration, with no idle cost.

What you still build on the buy side is smaller but real: a job table, a poller or worker, copying outputs into your own storage, a retry policy, spend monitoring and a review step. The quickstart shows the request side.

A cost model that is honest about idle time

Do not compare a per-second hosted price with a GPU hourly rate directly. Build a model with these terms and plug in your own numbers:

self_hosted_cost_per_clip =
    (gpu_hourly_rate * seconds_gpu_busy_per_clip / 3600) / utilisation
    + ops_labour_per_month / clips_per_month
    + storage_and_egress_per_clip

hosted_cost_per_clip = requested_seconds * price_per_second * (1 + platform_fee)

utilisation is the term teams underestimate: if your GPUs are busy 20% of the time, the effective cost per clip is five times the busy-time cost. Hosted pricing has no utilisation term; you pay when you generate. The break-even point therefore depends on sustained volume, not total volume. Also count retries on both sides: the rejected-clip rate multiplies cost either way.

For the hosted side, the current spread is in the table below; the same checkpoint can cost noticeably different amounts depending on host.

Per second, before VideoRouter's 2.5% platform fee. For tiered models each row compares the resolution tier with the widest host-to-host gap. Built 2026-10-17 from the live catalog.

Failover is the hidden differentiator

A single self-hosted cluster has one failure domain. A hosted gateway routes around a failing host: unpinned requests retry once on the same host, then walk other hosts serving the same checkpoint, cheapest first. You can also set failover.on_timeout_sec to hedge to the next host if a job stalls, but note that both attempts are billed if both land. Rebuilding this yourself means contracts, keys and integrations with multiple providers, which is most of the value of the gateway.

The people cost

The line item that most often gets left out of a build estimate is attention. Someone has to watch queue depth, handle a driver update that breaks a pipeline, evaluate each new open release, and answer the pager when a node dies at night. Even a small team doing this part-time is a real monthly cost, and it does not shrink when volume is low. If you do the arithmetic and the labour term dominates, that is your answer; if your clips-per-month is large enough that labour is a rounding error against GPU savings, building starts to make sense.

When building is the right answer

• You have a model that is not offered by any host, such as your own fine-tune, or you need weights on your own hardware for contractual or data-residency reasons.
• Your volume is high and steady enough to keep GPUs well utilised, and you have people who want to run them.
• You need control over the inference stack itself.

When buying is the right answer

• Volume is spiky or still being discovered.
• You want to compare several model families before committing, which a single endpoint makes a one-string change.
• You do not want on-call responsibility for GPUs.
• You want the newest hosted models without a deployment each time.

A hybrid that works

Start hosted, instrument cost per accepted clip and the share of traffic going to each model, then self-host only the one model that dominates steady volume. Keeping the request shape behind your own thin wrapper means moving that one model later is a config change. See use cases for the workflows that tend to dominate volume, and the pricing page for current per-model numbers.

Create a key and measure your real rejected-clip rate on a few hundred prompts first; that number decides the comparison more than any benchmark.

Frequently asked questions

Keep reading

• What Is a Video Generation API? How It Works and What It Costs
• Video Generation API Use Cases and the Workflow Each Needs
• Text-to-Video vs Image-to-Video vs Reference-to-Video (API)
• Best Video Generation APIs: How to Evaluate Them (Checklist)