AI video GPU capacity cannot be planned from an average render time alone. A video request combines duration, frame rate, resolution, controls, retries, and queue behavior. In P-Video 2, a team can choose 5, 10, 15, or 20 seconds; 720p or 1080p; and 24 or 48 FPS. That range turns one endpoint into several distinct infrastructure workloads. Teams that classify them early can protect interactive previews while keeping final exports predictable.
AI video GPU capacity starts with workload shape
A text model often produces a short response after a bounded decode. Video generation must keep spatial detail coherent across time. That temporal dimension makes the work much heavier. NVIDIA describes video diffusion as especially demanding because standard diffusion sampling can take tens to hundreds of denoising steps, while a video adds a temporal axis to every generation problem. Its FastGen overview reports that a 14B-parameter Wan2.1 text-to-video model was distilled to two steps using 64 H100 GPUs over 16 hours. That is a training result, not a sizing number for P-Video 2, but it explains why video inference deserves its own capacity model.
P-Video 2 gives operators useful workload labels. A 5-second, 720p, 24 FPS draft render is an exploratory job. A 20-second, 1080p, 48 FPS output with a start frame, end-frame reference, and audio is a production job. Treating both as identical requests hides the load that arrives at the scheduler.
Use frame-pixel math as a planning proxy
Frame-pixels provide a quick, honest first-pass proxy. They do not replace measurements because model architecture, sampling steps, attention strategy, conditioning, and worker hardware change the final cost. They do reveal the scale hidden behind a simple duration menu.
| Job class | Frames | Pixels per frame | Frame-pixels | Relative proxy |
|---|---|---|---|---|
| 5 s, 720p, 24 FPS | 120 | 921,600 | 110.6 million | 1.0x |
| 10 s, 720p, 24 FPS | 240 | 921,600 | 221.2 million | 2.0x |
| 10 s, 1080p, 24 FPS | 240 | 2,073,600 | 497.7 million | 4.5x |
| 20 s, 1080p, 48 FPS | 960 | 2,073,600 | 1.99 billion | 18.0x |
The arithmetic is simple. Moving from 720p to 1080p raises pixels per frame from 921,600 to 2,073,600, or 2.25x. Increasing a clip from 5 seconds to 20 seconds adds 4x the frames. Moving from 24 to 48 FPS doubles them again. Before model-specific overhead, the largest row carries 18x the frame-pixel volume of the smallest row.
That ratio matters during a launch, batch creative refresh, or customer upload spike. If a service has capacity for 40 small jobs in an hour, it does not automatically have capacity for 40 high-fidelity jobs. Capacity planning should convert incoming requests into a normalized workload unit, then reserve headroom for variance and retry traffic.
Build three service classes
Start with preview, standard, and final classes. Preview can allow 5 seconds, 720p, 24 FPS, and draft mode. Standard can permit 10 seconds at a defined resolution. Final can admit longer clips and higher frame rates only through a separate queue. P-Video 2 exposes draft mode for a faster, lower-quality preview, which is a practical tool for keeping ideation from consuming the same GPU pool as delivery work.
Set a concurrency limit for each class rather than a single global request limit. A global limit can leave expensive jobs blocking cheap previews. Per-class limits make the tradeoff visible: a team can reserve two worker slots for final renders while allowing a larger preview pool to drain quickly.
Split queues and set admission rules
Queue separation is not just a latency trick. It changes what the product can promise. Put the request parameters, prompt version, input asset IDs, output target, and job class into the queue record. Include a cost estimate based on the frame-pixel proxy. When the backlog passes a threshold, reject or delay final jobs before accepting them, while still serving small drafts.
Reference controls need extra care. P-Video 2 supports an input image, optional last-frame image, and optional audio. The documented behavior says audio longer than the selected duration is trimmed; shorter audio produces a shorter video. A scheduler should validate those inputs before a GPU reservation. Fetching a missing image, transcoding unsupported audio, or discovering a duration mismatch after assignment creates idle worker time and false capacity alarms.
For reproducibility, retain the seed and change one variable per experiment. That makes a rerun interpretable. It also lets infrastructure teams distinguish a rendering fault from a creative retry. The model supports a fixed integer seed, a useful handle when measuring how settings affect latency or output stability.
Measure approved outputs, not requests
Track queue wait time by service class, render duration by parameter bundle, completion rate, GPU-seconds per completed asset, retry count, and GPU-seconds per approved asset. The last metric catches a common failure mode: plenty of jobs finish, but weak prompts or unstable references send users back for several more attempts.
Also record p50, p95, and p99 queue waits. An average can look healthy while a few final jobs wait long enough to miss a campaign handoff. Record saturation separately for GPU compute, video decode or encode, object storage reads, and outbound delivery. A GPU fleet may look full when the true stall sits in asset preparation or a slow upload path.
Run a weekly load test with a known mix. For example, begin with 70% preview, 20% standard, and 10% final jobs. Then test a burst where final work reaches 30%. The goal is not to predict every customer prompt. It is to learn the queue depth at which latency starts rising sharply, then set an admission threshold below that point.
Practical operating rules
- Default experiments to 5-second, 720p, 24 FPS draft renders.
- Require an explicit final class for 1080p, 48 FPS, or 15- to 20-second work.
- Estimate work from frames multiplied by output pixels, then calibrate it with measured GPU-seconds.
- Validate image and audio references before placing a job on a GPU queue.
- Keep preview and final queues separate, with protected capacity for each.
- Alert on p95 queue wait and GPU-seconds per approved output, not just average render time.
For a closer look at output behavior, see P-Video 2: 5 Real Tests and the Limits of Fast Video. The infrastructure lesson is direct: AI video GPU capacity comes from workload classes, measured service levels, and admission control. Run controlled video experiments and scale the queueing policy around them on Wiro.
