Runpod workers: GPU memory, CPU work and job economics

The retained XGen materials do not establish the historical Runpod Pod IDs, GPU allocations or container images. The profiles in this article are explicit reference configurations for implementing the requested pipeline. They should be benchmarked before adoption rather than presented as recovered client infrastructure.

That still permits a concrete design. We can choose a baseline workload, calculate its resource drivers, request a suitable worker and define the evidence required to accept it.

Freeze the workload before sizing

The baseline is one Wan 2.1 I2V 14B job at 832 × 480, 81 frames and batch size one. It uses FP16 diffusion weights and an FP8 text encoder in the supplied graph. Increasing frame count, resolution, precision or batch size changes the memory and time profile.

Fourteen billion parameters at two bytes each occupy approximately 28 GB, or 26.1 GiB, for the diffusion weights alone. That already exceeds a 24 GB card before considering the text encoder, vision encoder, VAE, activations and workspaces. Quantization and offload can change placement, but introduce their own compatibility and latency trade-offs.

The small latent allocation is not the complete VRAM requirement. Nor does one model’s published low-memory configuration establish that another checkpoint fits.

Three reference worker profiles

These are resource requests, not a guarantee that every marketplace listing pairs that GPU with those CPU and RAM allocations. Confirm the actual Pod configuration, GPU type and available memory. vCPU is an allocation unit, not a claim about physical cores or processor model. Runpod GPU guidance

The machine-readable profiles record the same choices. The default graph must not be deployed unchanged to the 24 GB lane under an assumption that all its FP16 weights will fit.

Separate the worker lifecycles

Keep generation, encoding and delivery as distinct stages. A GPU worker owns one admitted sampling job. A CPU worker can encode frames, prepare thumbnails and package deliverables while the GPU begins another accepted job.

Start with one generation at a time per GPU process. Increase concurrency only after measuring peak memory and tail latency. Two individually successful jobs can fail when their text encoding, denoising or decoding peaks overlap.

Limit CPU thread pools as well. Multiple encoders, image decoders and numerical libraries can oversubscribe the same host. Record CPU utilization and queue delay before assuming a GPU upgrade will improve throughput.

Storage is part of startup time

Model downloads and deserialization can dominate cold startup. Keep verified model artifacts on persistent storage and use worker-local caching where appropriate. Container scratch space, Pod volumes and network volumes have different lifetimes; accepted outputs should survive termination of the generation worker. Runpod storage documentation

The model cache should be keyed by artifact hash and checked before admission. An existing filename is not enough if the file is partial or belongs to a different version. Keep temporary downloads separate and promote them atomically after verification.

Reserve space for decoded frames as well as weights. An 81-frame RGB sequence at 832 × 480 contains about 97 MB of raw pixel data before compression; multiple intermediate representations and attempts increase the working set.

Pin the runtime after validating it

The kit records the ComfyUI source revision inspected for the graph contract. The complete worker additionally needs a mutually compatible GPU driver, CUDA/PyTorch combination and dependency set. Preserve the validated container digest and package lock after the first smoke run.

A readiness check should establish more than “the process is listening.” It should verify required nodes, model presence and a successful budgeted generation using the intended precision. Cold and warm timings should be recorded separately.

No image is automatically production-ready because a registry tag looks official. The useful release artifact is the exact image that passed the workflow and output checks.

Job ownership and retries

A job record should include tenant, input hashes, configuration hash, deadline, maximum spend and an attempt lease. The worker heartbeats while executing. If the lease expires, reconciliation checks whether completed artifacts already exist before admitting another attempt.

Use attempt-specific output prefixes and a durable completion receipt. A failed upload after successful generation should not necessarily trigger another diffusion run. Retry the failed stage when its inputs and outputs permit it.

The example allows at most two generation attempts and requires remaining budget before retry. Those are reference policy choices, not universal defaults. Cancellation should stop new work and classify any already-created artifacts explicitly.

Compare cost per accepted clip

A useful cost equation is:

attempt cost = billable worker seconds × hourly rate / 3600
accepted-clip cost = all attempt and finishing costs / accepted clips

For an illustrative $1.20/hour worker and a 300-second billed attempt, compute cost is $0.10. If only half the attempts are accepted, that becomes $0.20 per accepted clip before image generation, storage, encoding and review. These are chosen example inputs, not a quoted Runpod price or XGen result.

Higher utilization can reduce cold-start overhead, while a larger GPU can improve headroom. Neither guarantees better economics until acceptance rate and total billed time are measured on the same workload.