What Runway Characters does with a single photo
Characters turns one photo into a live character you can talk to. Behind it sits an autoregressive video model of roughly 57B parameters, a video DiT by architecture. It builds each chunk through four denoising passes and delivers 704×1088 at 24 fps.
The rhythm is arithmetic. Four frames every 166.7 ms. That obligation holds for every single step, and an average over a minute will not satisfy it. One session, one user: batch size one. That is the turn in the whole post.
Why batch size one breaks the usual GPU maths
Regular inference lives by the rule of filling a batch and spreading the cost across everyone in it. Fifty requests at once are cheaper than fifty one at a time, and most cost models are built on that.
A conversational avatar cannot work that way. The research post says it plainly: one session occupies 2.24 PFLOP/s of useful work, and a second user cannot ride along in the same tick. Everybody pays for their own GPU. A real-time video model counts hardware per person, and the old batch arithmetic has nothing to say here.
The 166.7 ms budget versus a 240.9 ms step
Characters launched at eight H100s per session, and that was the starting point. The honest comparison is what four cards actually produce: the baseline step on four H100s took 240.9 ms, against a budget of 166.7 ms. That is more than seventy milliseconds over, and in live video it shows up as visible lag.
Production settings take it to 159.3 ms, which is 24.5 fps sustained, a 1.51× speedup. A fused kernel that pulls the all-reduce inside the FP8 matrix multiply reaches 147.4 ms, 1.63× over baseline.
Cache: 240 attention calls and work moved to write time
The second saving lived in how the model reads its own memory. Every chunk takes 240 attention calls, and each call reads a 5,788-slot KV cache in which only 757 tokens are new. In the original step, 29% of GPU time went to recomputing a nearly unchanged cache, while attention itself took about 6%.
That work moved to write time: a ring cache, RoPE and FP8 quantization applied once per write, and a delta rotation whenever positions reset. Cache upkeep dropped from 69.7 ms to 6.2 ms per step. Positions reset every 42 steps.
The decoder gets its own GPU
The third decision is about hardware. The decoder that turns latents into finished frames got a GPU of its own and runs in parallel with denoising. It costs 114 ms but fits inside the same window where diffusion is computed. On a shared B200 with a power cap, that arrangement slows diffusion by 18-26%.
Launch lessons: a fused kernel, an OOM and a rollback
The fused kernel shipped in August 2026 and went straight into production. After a PyTorch and NCCL upgrade it started throwing memory errors: OOM under real load. The team rolled back, found the cause and re-enabled the kernel on October 8. Over the fifteen days that followed, sessions dropping to 24 fps or below made up 0.7% of the total, against 7-23% before the fix.
How they measured quality
Measuring an autoregressive model in pixels is pointless: PSNR has no reference to compare against here. The baseline is different, a run against another run. Across 51 scored clips the mean lip-sync difference stayed at or under 0.03, which sits inside the model's own run-to-run variation. Four ten-minute sessions produced the same order of magnitude.
Latency came from live conversations. The median from the end of a user's sentence to the avatar's response was 2.13 s. Inside that turn the voice agent takes 1.42 s, the video pipeline 0.49 s, and delivery about 190 ms.
Blackwell: three B200s against four H100s
Numbers for newer hardware exist too. Three B200s deliver about 154.3 ms. Eight H100s compute diffusion in 118.2 ms but bottleneck on the decoder, landing at 128.7 ms, or 31 fps. The compute headroom is real, it just goes to the decoder and the small steps around it.
A talking avatar from one photo: what it does to a budget
My read is short, and it is about the second half of the post. There is no pricing in the research write-up, it is an engineering report about serving, and I am not going to hang a number on Characters that Runway never published.
Look at what did change: a live session is now counted in four GPUs instead of eight. For a studio pricing a live avatar, that is a direct cut to the denominator. It matters more to teams designing conversational products and estimating GPU cost per hour, and it barely matters to anyone rendering 15-second ad clips offline. There you pay per second of render. Sustained pace is a separate line item.
Yesterday's roundup on Kling 4.0 Flash, Gemini Omni and Muse added a third story about real time, and the difference finally reads clearly: one is serving at batch one, one is clip length, one is a conversational toy.
For day-to-day production the reference point stays the same. Conversational spots and scenes with a talking person we build on a pipeline with a human owning the frame, handcrafted AI videos from $190, where everything except the GPU hour is predictable. Batches of vertical scenes where AI video runs at volume live on a different calculation, up to $2.40 per 1000 views. When the job is literally a conversation with a character and nothing gets filmed, we have a separate guide to a real-time talking avatar. The hardware underneath is getting cheaper, so the limit on session length will stop being a technical one.
