Dev.to AI 🤖 Ai 👁 0 📖 4 min read

Serving a stateful video world model on one RTX 4090: memory, flags and seeds in Hy-Nomas

Most open video models give you a clip and drop it. Hy-Nomas holds on to the world between calls, and that reshapes the server around it. The model comes from Tencent Hunyuan, with weights and code under Apache-2.0 on t

Serving a stateful video world model on one RTX 4090: memory, flags and seeds in Hy-Nomas

Most open video models give you a clip and drop it. Hy-Nomas holds on to the world between calls, and that reshapes the server around it.

The model comes from Tencent Hunyuan, with weights and code under Apache-2.0 on the Hy-Nomas model card and in the Tencent-Hunyuan/Hy-Nomas repository. You steer it in 5-second turns, each built on the frames already made. The default launch shares one video between eight GPUs, but the authors also ship a low-memory preset for a lone RTX 4090. We tried it as published, on a 24 GB RTX 4090 on our cloud. Every figure below comes from the Hy-Nomas single-GPU research write-up.

Headline numbers: 88 to 94 seconds of GPU work per 5-second segment once warm (after the first call has loaded everything), an 18.5 GiB peak on the card, and a scene that stayed coherent for three turns.

The server is stateful, so plan in worlds

As it draws, the model writes notes on the scene and reads them before the next turn. The preset keeps only the newest few seconds of notes on the GPU and parks the rest in main memory (host RAM). Our backend, a small program between the platform's API and the model, wraps the authors' own generation service and keeps a single world resident. A request carries one turn and returns a 5-second MP4; the next one picks up where it ended.

So one GPU holds exactly one live world, for one person. Size the fleet by open worlds, not requests per second.

Host RAM is the second budget. The parked notes grew by about 5.9 GiB per segment, linearly over the three segments we ran. Our SDK example requests 64 GB of RAM, a provisioning pick rather than a measured floor. A one-minute world is twelve segments, so check the host side first.

The trap: two decode flags from the live-demo script

Decoding turns the model's internal result into video frames. The authors' live-demo script starts it while the video model still sits on the GPU:

inference.seg_ar_segment_vae_decode=true
model.vae.stable_prefix_streaming=true

On 24 GB, the pair runs out of memory. We removed both, so decoding waits until drawing is done. Status: worked around in our example, not yet reported upstream.

The hardware check that is easy to miss

The preset compiles a GPU routine (a kernel) for its decoder on NVIDIA's CUTLASS, using 8-bit numbers (FP8). It targets one GPU generation only: Ada, the RTX 4090 family. Any other generation gets an error, so an RTX 5090 or an A40 should fail, though we ran neither. The spec is "24 GB and Ada", not just "24 GB".

To find the floor, we capped memory on the same card:

Memory available Result
24 GB RTX 4090, real card works, 88 to 94 s per segment
capped at 20 GiB works over two turns, no slowdown
capped at 16 GiB fails while moving the text reader to the GPU

At 16 GiB it crashes before drawing anything, so lower resolution would not help. We have not tried a real 20 GB card, and the authors' own one-card run hit 20.53 GiB with segments longer than ours.

What to log on every turn

Of a ninety-second turn, roughly 35 seconds is drawing, roughly 9 is writing the scene notes, and the remainder goes to decoding frames and encoding the MP4. A cold first call after a restart took as long as 138 seconds. The per-stage timings in the Hy-Nomas write-up show which stage a faster turn would have to shrink.

Log per call:

  • GPU seconds per segment, warm and cold
  • peak GPU memory, which crept up each turn for reasons we did not find
  • host RAM after each segment
  • an md5 hash of each segment's video file

A seed is the fixed random number that drives generation. The same turns and seed produced byte-identical files in four runs on one machine. A bug report can ship its exact inputs and reproduce the clip. The seed also belongs to the world: an early backend answered a seedless continue turn with an HTTP 400, as the seed no longer matched. Backend 0.1.2 now keeps the seed from the first turn.

Two platform limits, both open, shaped the API: calls that wait for the answer stop at 300 seconds, so one segment per call, and messages cap at 8 MB, so the client stitches segments itself.

What the model did and did not follow

Turn 2 and turn 3 of one Hy-Nomas world on an RTX 4090: blue flowers appear beside the fox as asked, while the requested snow never comes and the fox walks on when asked to stop

Continuity was the strength: fox, path and light survived from call to call. Steering was weak: one scene change in four landed. Flowers showed up; snow, a storm and requested actions did not. Our prompts were handwritten, without Nomas-PE, the authors' far larger prompt rewriter; whether it brings the weather is untested, like camera paths.

At roughly 18 times slower than real time, this is for sketching scenes that stay put across turns. Think rehearsal room, not stage.

Credits: the model, its single-GPU preset, its INT8 and FP8 weights and the generation service our backend wraps are the work of Tencent Hunyuan, described in their paper on arXiv. Tencent fine-tuned the decoder from PixelUMM (Wei et al., 2026) and published a Diffusers conversion built on a fork by jiaxiangc. Qwen2.5-VL-7B, from the Qwen team, reads the instructions, and NVIDIA's CUTLASS sits under the FP8 kernel. We first saw the model in a news video from AI Search. Our share: the backend, measurements, memory caps and SDK example. The per-turn table, request format, setup steps and every problem with its status are in the full Hy-Nomas test on one RTX 4090.

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.