Open Source
Open Source

One RTX 4090, One Interactive World Model: Hy-Nomas Reviewed

Tencent Hunyuan open-sourced Hy-Nomas, an interactive video world generation model (code on October 21, weights October 23, about 8B, Apache 2.0 with third-party notices): multi-turn control via text and camera trajectories, persistent KV cache memory across segments, 54 dual-stream MMDiT blocks plus a Qwen2.5-VL-7B text encoder; output at 704x1280@24FPS (playback rate, not generation speed), with 4/6/8-step distillation variants coexisting; the 280-case Hy-Nomas-Bench is self-reported with no third-party comparison at release. A single RTX 4090 runs it via INT8 weights, an FP8 decoder, and CPU offload (about 22.5GB minimum download) — with the trade-offs stated plainly: no LoRA on INT8, sliding-window KV sacrifices long-range memory, and the FP8 kernel targets SM89 only (3090 need not apply). Cold water included: the KV cache guarantees no stable 3D scene graph, no deterministic rigid-body physics, and zero official VRAM or latency figures.

Published October 27, 202611 min read
<!-- hy-nomas-interactive-world-opensource-resource | open-source | One RTX 4090, One Interactive World Model: Hy-Nomas Reviewed -->

What Actually Shipped

"World model" has become one of the most abused labels in AI. Most releases are closed-source demo reels, or open weights gated behind eight-GPU servers. This one is different, at least on paper. On October 21, Tencent Hunyuan pushed the code repository for Hy-Nomas, an interactive world generation model, onto GitHub (Tencent-Hunyuan/Hy-Nomas). On October 23 at 11:18 UTC, the full weight set landed on Hugging Face in a single commit: 196.4GB across 46 files [secondary, based on third-party verification of the repository commit]. The official X account announced the release the same day [official]. The first line of the README sets the hook: with the low-memory inference configuration, the model runs on a single RTX 4090 [official]. Repository: github.com/Tencent-Hunyuan/Hy-Nomas.

Before going deeper, a note on coverage boundaries: our October 16 review of realtime playable world models and an earlier world-model comparison handle multi-vendor selection, while this piece is a single-model deep dive covering architecture, licensing, interaction granularity, and the real cost of consumer-grade deployment.

A GitHub API snapshot taken October 27, 2026 [official] shows 241 stars, 28 forks, a repository created on October 21, and no releases yet. For a world model public for just one week, that is a starting position, not a verdict. Community integrations such as the ComfyUI port are appearing, but third-party benchmarking remains scarce, so every number here carries a source tag.

What "Interactive" Means Here

The official site, hy-nomas.hy.tencent.com, frames the model as Interactive World Modeling and lists five capability blocks: multi-turn prompt control, interleaved text and camera control, long world generation, consistent world memory, and diverse perspectives and styles, alongside 83 real generated worlds [official claims]. The interactivity rests on three mechanisms.

First, segment-autoregressive generation. The world advances segment by segment, each one steerable by a fresh text prompt or camera control signal. The official site caps duration at 60 seconds with a 360K token context [official]. Second, a persistent KV cache: text and video keys and values from the previous segment carry into the next, forming cross-segment memory. This is the difference between a "world" and a sequence of disconnected clips. Third, camera conditioning: camera extrinsics are injected into the video stream through per-block cross-attention, so you can choreograph pans, push-ins, and perspective switches with geometric precision rather than vague camera-direction keywords.

The experience shift is easy to summarize: from pulling slot-machine levers to navigating. Conventional video generation is a one-shot gamble; a bad roll means rerolling everything. Segmented generation with persistent memory means you can change the weather, shift the time of day, or reposition the camera, then keep editing the same world across turns. Against the closed alternative, Genie 3, which keeps its weights private, caps sessions at 60 seconds, and sits behind a subscription, Hy-Nomas releases weights, code, and its evaluation set in full. That one contrast is enough here.The hosted demo requires account registration [secondary] and relies on a prompt-enhancement service called Nomas-PE that converts casual instructions into structured prompts [official]. That helper alone weighs 55.6GB across 18 shards [secondary], and the web demo runs on a separate multi-GPU path; the single-card offline inference below is a different pipeline. The site also demonstrates a 60-second generation built from five text rounds of roughly 12 seconds each [secondary], confirming that segmented generation plus cross-segment memory can chain context together. Whether it chains it reliably is a question for the cold-water section.

Architecture, With the Numbers Straightened Out

Parameter count: approximately 8B [official, per the official site]. The 8.6B figure circulating in some posts appears nowhere in verifiable official material, so we skip it. The backbone consists of 54 dual-stream MMDiT blocks with no single-stream blocks, a hidden size of 2,048, and 16 attention heads [transcribed from the model card]. Text conditioning comes from Qwen2.5-VL-7B-Instruct, whose hidden states pass through a two-layer token refiner [transcribed]. The video decoder is PixelUMM, decoding in a single step [transcribed], and the latent space is handled by DCAE-V with 32 channels, 32x spatial compression, and 4x temporal compression [transcribed].

Resolution and framerate need untangling. The official site says 720p [official], but the code and the Diffusers examples produce 704x1280 at 24FPS. The difference matters because 720p is a rounding, and this article sticks to the 704x1280 figure. More importantly, 24FPS is the playback framerate, not the generation speed; actual throughput depends on hardware, resolution, segment length, and history length, in the README's own words [official].

The distillation story is also a case of coexisting numbers: the distilled weights support 4, 6, or 8 denoising steps, the interactive demo defaults to 8, and the Diffusers example uses 4 [official]. All three are correct; they come from different places. Pick the one that matches your inference route. One lineage note: Tencent's world-model line previously open-sourced HY-World 2.0, which outputs editable 3D meshes and Gaussian splats. Hy-Nomas outputs streaming video with no downloadable 3D mesh. They are different projects, and mixing them up is already a common error in third-party coverage [secondary].

The 4090 Route: Four Mechanisms, Four Trade-Offs

The deployment path is well documented. A pre-packaged Docker image is the recommended route; manual installation requires Linux, Python 3.12 or later, uv, the CUDA 13.0 toolkit, and a C++ compiler, with PyTorch 2.10.0 plus FlashAttention and MagiAttention among the dependencies [official]. Single-4090 inference runs through the low-memory configuration:

bash
# Download weights (preserve the repository directory structure; official tool is hf)
export Hy_Nomas_Model_Path=/path/to/Hy-Nomas
hf download tencent/Hy-Nomas --local-dir "${Hy_Nomas_Model_Path}"

# Single-4090 low-memory inference: INT8 DiT + FP8 decoder
bash scripts/inference/inference_from_config.sh configs/experiment/single_gpu_low_mem_inference.yaml \
  dit_weight="${Hy_Nomas_Model_Path}/DiT/distilled_int8/diffusion_pytorch_model_ema_0_995_int8.safetensors" \
  model.vae.checkpoint="${Hy_Nomas_Model_Path}/VAE/PixelUMM_FT_FP8/diffusion_pytorch_model_fp8.safetensors" \
  inference.prompt=/path/to/prompts.json \
  inference.save_path=./outputs/single_gpu

Start with the storage ledger [secondary]: the INT8 DiT weighs about 9.06GB, the FP8 PixelUMM decoder about 9.13GB, plus DCAE-V at roughly 4.28GB and supporting components, so the minimal 4090 download is about 22.5GB instead of the full 196.4GB. That is what "runs on one RTX 4090" means on the storage side.

Fitting everything into 24GB of VRAM relies on four mechanisms, and each extracts a price [official README, with kernel-level details transcribed from source]. One: INT8 weights and INT8 KV cache. Linear layers and attention still compute in BF16; only storage is quantized. The cost is that the INT8 inference loader cannot mount a separate LoRA adapter, so your own fine-tuned styles are off the table on this route. Two: CPU offload. The text encoder, DiT, and VAE move onto the GPU for their processing stages and return to CPU afterward. The cost is transfer overhead, plus a hard requirement that system RAM holds the full model set and the growing KV history archive evicted from the GPU. Three: sliding-window history. The GPU keeps only 18 past frames (past_frames=18), with older context archived to CPU. The cost is truncated long-range memory; run far enough and the model may forget the world you built at the start. Four: the FP8 decoding kernel uses CUTLASS and is compiled only for the Ada architecture, SM89. Among 24GB cards, only the 4090 can take the official path; the RTX 3090 is Ampere, SM86, and does not qualify. The README never mentions this constraint; it surfaces from the JIT compilation flags in the source code [secondary].

One conspicuous gap: no official documentation publishes peak VRAM, system RAM requirements, or latency figures, only a note that peak GPU memory depends on resolution and segment length [official]. For contrast, the standard configuration runs eight-GPU sequence parallelism with FP32 weights and full KV history resident in VRAM [official], and the realtime Reactor runtime references eight B200s [secondary]. "Runs on a single card" is true; the price did not make it into the headline.

For a speed reference, there is one secondary data point: the community ComfyUI port (nynxz/Hy-Nomas) already works, with an RTX 5090 measuring roughly 21 seconds of generation for a 3-second segment plus about 4 seconds of decoding per window [secondary]. A 4090 will be slower still, and the gap between "runs" and "feels realtime" is wide.

Fine-tuning deserves a paragraph. LoRA training must start from the non-distilled base_ar checkpoint and merge back into the distilled weights [official]. The reference configuration uses LoRA rank and alpha of 256, the Muon optimizer, a constant learning rate of 1e-4, 2,000 steps, and a reference scale of 128 GPUs [official]. Read that last number twice before planning a personal reproduction. Two ready-made adapters ship officially: a Cinematic LoRA lifting visual quality, and a Robotics LoRA built on the real dual-arm dataset RealSource-World for robot simulation [official]. Remember the first trade-off above: the INT8 route cannot carry LoRA at all.## Cold Water and a Bench With No Scores

First bucket: consistency through a persistent KV cache is not the same as a stable 3D scene graph. Coherence is maintained by attention caching, and nothing official promises that the scene's 3D structure stays stable; after complex camera moves or long editing chains, objects can deform or vanish. There is no physics engine here either, no deterministic rigid-body simulation; collisions and gravity are unreliable, so do not import game-engine expectations.

Second bucket: the evaluation. Hy-Nomas-Bench covers four test sets totaling 280 cases plus 220 reference camera trajectories, spanning multi-turn text instructions, camera navigation, interleaved text-and-camera control, and spatial memory [official claims]. Here is what must be said plainly: at release, the bench contained no scores at all, neither for Hy-Nomas itself nor for any competitor. It is best understood as an open exam that third parties can use to re-examine the model, not as a report card. Until independent numbers appear, any "state of the art" framing is unsupported.

Third: the license, which needs precise wording. The README and its badge say Apache 2.0, and the LICENSE file is in fact the full Apache 2.0 text merged with a Tencent copyright notice and a third-party notice list. Because it is a merged file, GitHub's license detection reports NOASSERTION [official]. One more wrinkle: the PixelUMM decoder is a Tencent fine-tune of NVIDIA's version, and at least one third party claims the derived weights may fall under NVIDIA's non-commercial license. That claim awaits confirmation from the official model card, so treat commercial use with due caution [secondary, unverified]. Two smaller caveats: the tech report status is contradictory, with the site showing "Tech Report (Coming Soon)" while the README says a PDF has been added to the repository [official, conflicting claims reported as-is], and Diffusers support depends on a third-party fork rather than the mainline library [official]. None of this negates the project; the architecture documentation, deployment guide, and open evaluation set are more generous than typical. But this is a week-old release, the community is still finding the potholes, and the report card has not been issued.

FAQ

Q1: I only have one RTX 4090. Can I really run this locally?

A1: Yes, via the single_gpu_low_mem_inference.yaml configuration, with a minimal download of about 22.5GB [secondary]. Prepare three things: system RAM for the full model set plus the KV archive, a CUDA 13.0 environment, and acceptance of the INT8 and 18-frame sliding window trade-offs. Cards other than the 4090, including the RTX 3090, cannot take the official FP8 decoding path.

Q2: Can I attach a LoRA in the 4090 mode?

A2: No. The INT8 inference loader does not support mounting a separate LoRA adapter [transcribed]. To use the official Cinematic or Robotics LoRA you must move to the standard BF16 route, with higher VRAM demands. Fine-tuning itself is heavier still: the reference training configuration is 128 GPUs [official].

Q3: Is 24FPS the generation speed?

A3: No. 24FPS is the playback framerate of the output video. Generation speed depends on hardware, resolution, segment length, and history length, and no throughput figures have been published [official]. The only public reference is a ComfyUI community measurement on an RTX 5090: roughly 21 seconds of generation for a 3-second segment plus about 4 seconds of decoding [secondary], clearly short of realtime.

Q4: Can I use it commercially?

A4: The main license is Apache 2.0 with an attached third-party notice file, which GitHub reports as NOASSERTION [official]. However, the PixelUMM decoder is a Tencent fine-tune of NVIDIA's version, and one third party claims the derived weights may fall under NVIDIA's non-commercial license. Pending confirmation from the official model card, review the terms before commercial deployment [secondary, unverified].

Q5: Does Hy-Nomas-Bench come with a scoreboard?

A5: No. At release the bench consists of four test sets with 280 cases and 220 reference trajectories, containing no model scores and no third-party comparisons [official claims]. It is an open evaluation set third parties can use to re-examine Hy-Nomas or benchmark rivals. Until those numbers exist, no "leading model" claim has any basis.

Sources

Related reading

This article is based on public repositories and official pages as of October 27, 2026. All figures carry source tags; the official pages prevail.

This article is AI-assisted and human-edited. Last updated: 2026-10-27

FAQ

I only have one RTX 4090. Can I really run this locally?
A1: Yes, via the single_gpu_low_mem_inference.yaml configuration, with a minimal download of about 22.5GB [secondary]. Prepare three things: system RAM for the full model set plus the KV archive, a CUDA 13.0 environment, and acceptance of the INT8 and 18-frame sliding window trade-offs. Cards other than the 4090, including the RTX 3090, cannot take the official FP8 decoding path.
Can I attach a LoRA in the 4090 mode?
A2: No. The INT8 inference loader does not support mounting a separate LoRA adapter [transcribed]. To use the official Cinematic or Robotics LoRA you must move to the standard BF16 route, with higher VRAM demands. Fine-tuning itself is heavier still: the reference training configuration is 128 GPUs [official].
Is 24FPS the generation speed?
A3: No. 24FPS is the playback framerate of the output video. Generation speed depends on hardware, resolution, segment length, and history length, and no throughput figures have been published [official]. The only public reference is a ComfyUI community measurement on an RTX 5090: roughly 21 seconds of generation for a 3-second segment plus about 4 seconds of decoding [secondary], clearly short of realtime.
Can I use it commercially?
A4: The main license is Apache 2.0 with an attached third-party notice file, which GitHub reports as NOASSERTION [official]. However, the PixelUMM decoder is a Tencent fine-tune of NVIDIA's version, and one third party claims the derived weights may fall under NVIDIA's non-commercial license. Pending confirmation from the official model card, review the terms before commercial deployment [secondary, unverified].
Does Hy-Nomas-Bench come with a scoreboard?
A5: No. At release the bench consists of four test sets with 280 cases and 220 reference trajectories, containing no model scores and no third-party comparisons [official claims]. It is an open evaluation set third parties can use to re-examine Hy-Nomas or benchmark rivals. Until those numbers exist, no "leading model" claim has any basis. **Sources** - GitHub repository Tencent-Hunyuan/Hy-Nomas (README, README_CN, LICENSE, low-memory inference config): https://github.com/Tencent-Hunyuan/Hy-Nomas - Official site hy-nomas.hy.tencent.com (8B/720p/60s/360K token specifications and five capability blocks, all official claims): https://hy-nomas.hy.tencent.com/ - Hugging Face weight repository tencent/Hy-Nomas (196.4GB, 46 files, uploaded October 23, 2026): https://huggingface.co/tencent/Hy-Nomas - Official X account @TencentHunyuan announcement (October 23, 2026): https://x.com/TencentHunyuan - GitHub API snapshot (October 27, 2026, 241 stars/28 forks): https://api.github.com/repos/Tencent-Hunyuan/Hy-Nomas - dev.to/alanwest single-card deployment walkthrough (4090 config fields and the 22.5GB download figure): https://dev.to/alanwest/how-to-run-tencent-hy-nomas-locally-on-an-rtx-4090-live-demo-needs-8-gpus-15a3

Related

Open Source

AWS Infinity: an Agent Runtime Where Waiting Costs Nothing

AWS open-sourced Infinity, a suspend-and-resume agent runtime: the code lives in the hydro-project organization (aws/ and aws/hydro both 404), Apache-2.0, written in Rust, from the AWS x UC Berkeley Hydro collaboration. The official benchmark runs 80,000 agents for 20 rounds each — 3.2 million completions — at roughly 100KB of memory per agent on a single-threaded EPYC 9R14, extrapolating to about 75,000 agents in 8GB (an extrapolation; the Raspberry Pi 5 is only a memory analogy). This deep dive covers the serverless four-piece design, the simulated-model qualifier, the community critique list (durable I/O, race transfer, 25 stars and untested by the market), and how to get started.

Oct 26, 202611 min read
Open Source

A 0.9B Model Just Topped the OCR Leaderboard: How Real Is It?

GLM-OCR, open-sourced by Zhipu on February 3, 2026, has only 0.9B parameters (a 0.4B CogViT encoder plus a 0.5B GLM decoder) yet scored 94.62 on the vendor-reported OmniDocBench v1.5 board, above Gemini-3 Pro's 90.33 and GPT-4o's 75.02, with official cost at roughly one-tenth of traditional pipelines. This deep dive covers the three-way license split (weights MIT, code and PP-DocLayoutV3 Apache-2.0), the MTP design worth about 50 percent throughput, three verdicts on how real the top score is (PaddleOCR-VL-1.6 has since passed it, cross-board numbers are not comparable, and the official tagline contradicts its own table), the 37.6 percent weakness on aged scans, and four ways to run it: SDK, vLLM, SGLang, and Ollama.

Oct 25, 202611 min read
Open Source

AI Memory Framework, Open-Sourced: Tencent's 3B Tops Opus 5

Tencent Hunyuan open-sourced all three layers of Hy Memory 2.0 on 2026-10-16: the model layer Hy-Memory-30B-A3B (30B total parameters with about 3B active per token, a sparse MoE on HuggingFace at tencent/Hy-Memory-30B-A3B, arXiv 2610.22196), the SDK layer hy-memory (2.0.3 on PyPI at writing time) and the tool layer MemHub (CLI v1.0.3, bootstrapped via the npm memhub-cli package). License check: the GitHub API reports NOASSERTION (non-standard text), but the raw LICENSE file is Apache-2.0 with a Tencent preamble and no added restrictions - this article follows the LICENSE text. Official documents mix two spellings, "Hy-Memory-30A3B" and "Hy-Memory-30B-A3B"; we follow the HF repository name. Official benchmarks (vendor-reported): first place at 55.49 in a four-way memory-system comparison, ahead of Opus 5 (54.62) and DeepSeek-Flash (53.64), while Qwen3-30B-A3B scores only 44.37; MemoryArena 55.31 percent, leading runner-up EverOS by 10.2 points; CodeMemoryBench 64.2/35.6; SWE-ContextBench 28.3; LoCoMo 72.6 percent with memory tokens cut from 1159 to 703 (-39.3 percent). Internal business validation (vendor-reported): stock-picking multi-hop recall up from 50 to 90 percent, iWiki up 48.6 percent relative. Positioning is a memory-writer workhorse (analyst take, secondary): the model specializes in writing and updating memory and can in principle sit under existing systems like Mem0 or MemOS. MemHub tool count in two versions: the README lists 5 while the official WeChat article says 10 - go by actual CLI output. Five limitations stated as-is: vendor-only benchmarks without third-party replication, preview-stage API churn, MemHub limited to Linux/macOS, a 30B-class model that is nontrivial to self-host, and thin English docs. Repository: github.com/Tencent-Hunyuan/Hy-Memory (verified reachable). Division note: ai-agent-long-term-memory-sop (2026-08-08) covers the build-your-own mem0/Letta route; this piece covers Tencent's ready-made stack.

Oct 20, 202610 min read