Hy-Nomas on a 16 GB Card: Running an Interactive World Model Locally
Tencent's world model targets a 24 GB card. We ran it on a 16 GB RTX 5060 Ti by clearing four walls, and measured what a 5-second segment costs: about 6 minutes, $0.
Key takeaways
- Hy-Nomas is an Apache-2.0 world model: you steer a scene segment by segment with text and a camera trajectory, and a world memory keeps it the same place.
- Its official single-GPU target is a 24 GB RTX 4090. It runs on a 16 GB RTX 5060 Ti after four local fixes, with the 7B text encoder kept on the CPU.
- A 5-second segment takes about 6 minutes: ~30 s prompt encode, 98–110 s for 8 denoise steps, ~3.5 min decode. Ten seconds take about 13 minutes.
- Output is 1280x704 landscape at 24 fps with no audio. It is 704, not 720, because the model works in blocks of 32 pixels.
- The look is a game-engine render with soft texture: usable for drafts, plates and B-roll, not hero shots.
What a world model is, and why we wanted one
Most video models make a clip. A world model makes a place. Hy-Nomas, released by Tencent Hunyuan under Apache-2.0, generates video segment by segment: each segment has its own description and an optional camera trajectory, and a memory carried between segments keeps the trees, the path and the light where they were.
For a studio that is a different tool from a clip generator. It promises plates and fly-throughs that can be re-shot from another angle, and a scene that changes on command while staying the same world. The licence allows commercial use, which is why we tested it rather than just reading about it.
This piece covers getting it to run and what it costs. What the memory and the camera actually do is in World Memory Holds, New Objects Don't.
The four walls between a 24 GB model and a 16 GB card
Hy-Nomas runs on Linux only (CUDA 13, torch 2.10), so it lives in WSL on our workstation. The weights are 37 GB: a 9.1 GB INT8 distilled transformer, a 9.1 GB FP8 decoder, a 4.3 GB autoencoder used only in training, and a 16.6 GB Qwen2.5-VL-7B text encoder. Its official low-memory mode targets a single 24 GB RTX 4090. Ours is a 16 GB RTX 5060 Ti, and four things stood in the way.
- The text encoder does not fit on the card. At about 15.4 GB in bf16 it cannot move to a 16 GB GPU, and it fails with "device not ready" rather than an out-of-memory error, which sends you looking in the wrong place. We keep it on the CPU; encoding a prompt takes about 30 seconds.
- Flash attention is required at runtime. Two of its attention backends only exist for Hopper data-centre GPUs. We built FlashAttention 2.8.3 from source for this card, which took 24 minutes.
- The FP8 decoder is hard-wired to the previous GPU generation. Its kernel compiles only for Ada (sm_89). We recompiled it for Blackwell (sm_120) and checked the result against a bf16 matrix multiply: relative error 3.7%, normal for FP8.
- The kernel build was missing 75 CUDA headers that the system toolkit did not ship. We linked in exactly those, and nothing else, because a wider fix broke the compiler the other way.
WSL also needed more memory than its default: 52 GB of RAM and 32 GB of swap, because the CPU-offloaded parts did not fit in 31 GB.
What it costs to run
| Stage | 1 segment (5 s) | 2 segments (10 s) |
|---|---|---|
| Prompt encode (CPU) | ~30 s | ~30 s |
| Denoise, 8 steps | 98–110 s | 270 s |
| Decode | ~3.5 min | ~5 min |
| Total | ~6 min | ~13 min |
| Cost | $0 | $0 |
The decoder, not the generator, is the bottleneck. Eight denoise steps take under two minutes; turning the result into pixels takes longer than that.
Why 704 and not 720
Output is 1280x704 landscape at 24 fps, with no audio. The odd height is arithmetic. The model shrinks the image by a factor of 32 before it works on it, so both sides must divide by 32. 1280 / 32 = 40, but 720 / 32 = 22.5, and a latent grid cannot have half a cell. 704 / 32 = 22, so 704 is the nearest valid height below 720. Its training data was centre-cropped by 8 px at the top and bottom to match.
It does not cost us anything: the video is generated at 1280x704, so nothing is cut. If a delivery needs exact 16:9, a slight crop or a thin outpaint closes the gap.
We have not tried native 1080p. The model was trained in the 720p class, and video models pushed past their training resolution tend to repeat composition and break motion; attention cost would also rise roughly fivefold. Our chain instead renders native 720p, upscales 2x with FlashVSR to 2560x1408, then grades and interpolates.
What the output looks like
The scene is stable. Trees, path and light do not morph from frame to frame, and the camera follows the subject smoothly. But the image reads as a game-engine render rather than a photograph: texture is soft, and with no camera trajectory set, the fox's legs glide rather than walk. Kling and Wan are ahead on detail and motion realism.
That is the right verdict for a single clip, and the wrong question for a world model. Its value is in what happens across segments and under a camera move, which is where we went next: World Memory Holds, New Objects Don't.
The same fox clip became our test plate for three finishing techniques: grading only the hero, a LiDAR scan built from depth and a wireframe hologram.
Related
Building a Room Out of Holograms: Empty Set, Wireframe, Solid
An empty place fills up as wireframe holograms that turn solid on a spoken word. We did it on a locked Unreal shot and on handheld AI footage, then spent three rounds killing the flicker.
The Snap Reveal: Why MiniMax H3 Ignored the Gesture and Unreal Didn't
A woman snaps her fingers and a choir appears behind her. A frame-to-frame video model kept her playing and faded the choir in like ghosts. Blocking the gesture in Unreal put it exactly where we wanted it.
A Wireframe Hologram Effect Built from Depth, Not Generated
One object turns into a glowing digital twin while everything else stays real. A text prompt picks the object, depth wraps the grid around its curves, and it rendered on the first try for $0.