Hy-Nomas：腾讯开源了一款交互式世界模型，却对此只字未提

Tencent 今天上午上线了 Hy-Nomas 的评估套件和权重，但到当天结束时，仍未公布其中任何一项的哪怕一个分数。这就是这次发布的形态。Hy-Nomas 是一个视频世界模型，你可以用文本指令和镜头运动逐段操控它；其权重于今天 11:18 UTC 上传到 Hugging Face：一次提交包含 196 GB 的 Apache-2.0 检查点，同时还有一个同日上午 09:01 推送的代码仓库和一个可玩的演示。两天前，这两个仓库都已存在，但都是空的。没有博客文章，没有 arXiv 条目，模型卡上的“技术报告（即将推出）”徽章链接到一个返回 404 的文件。上传数小时后，模型页面显示零点赞、零下载，而唯一表明有人注意到的迹象是 GitHub 仓库：8 个 star、1 次提交、没有描述。

诚实的表述并不是“Tencent 发布了一个世界模型”。而是：Tencent 公开了权重、训练与推理代码、一个基准测试和一个演示站点，却尚未透露这些内容在评测中得分如何。以下每一项，要么是你可以自行核验的时间戳或文件大小，要么是 Tencent 自己写在其模型卡上的数字，要么是这张模型卡明显沉默之处。之所以刻意将这三类分开，是因为在这样一次发布中，沉默所承载的信息量与规格参数一样多。

到底是什么实际落地了，精确到小时

这些文物很容易确定年代，因为它们数量很少，而且没有一件被大幅修改过。

• 模型仓库 tencent/Hy-Nomas于 2026-10-21 02:17:37 UTC 在 Hugging Face 上创建，之后一直为空，直到其唯一一次提交于 2026-10-23 11:18:04 UTC 落地。该提交包含 46 个文件，总计 196.4 GB：两个 34.2 GB 的 fp32 DiT 检查点、一个 9.06 GB 的 INT8 DiT、两个 LoRA 适配器、一个 31.55 GB 的 PixelUMM 解码器及其 9.13 GB 的 FP8 孪生版本、一个 4.28 GB 的 DCAE-V 自编码器、一个由 18 个分片组成、总计 55.6 GB 的提示增强模型，以及常规的 tokenizer 和配置附属文件。

• 代码仓库 Tencent-Hunyuan/Hy-Nomas 是在 47 分钟后创建的，时间为 03:04:54 UTC，且未填写描述字段。其唯一一次提交创作于 10 月 21 日，但直到今天 09:01:42 UTC 才被推送。该仓库仍显示一次提交且没有发布版本，其中包含训练代码、推理脚本、一个 Docker 镜像以及一份 Web 演示部署指南。

• 基准数据集 tencent/Hy-Nomas-Bench创建于 2026-10-22 05:18:20 UTC，并于今天 09:10:51 UTC 收到了它唯一的一次提交。

位于 hy-nomas.hy.tencent.com 的演示会返回 HTTP 200 响应和一个页面标题。它是本次发布中唯一面向研究组以外所有人的部分。

这种悄无声息是该模型所特有的，而不是腾讯。该公司自己的 Hugging Face 组织却很忙碌：tencent/Hy4-preview自八月下旬起已获得 513 个赞和约 18,400 次下载，而tencent/Hy-Memory-30B-A3B自 10 月 15 日起在八天内获得了 297 个赞和约 3,300 次下载。在同一时间窗口上传、且规模大得多的 Hy-Nomas，却完全没有这些。无论内部原因是什么，这都不是一次表现不佳的发布。这是一次根本未被尝试的发布。

Hy-Nomas 能做到而文本到视频模型做不到的事

这种区别比参数规模更重要，因为这才是值得关注这次发布的原因。普通的文本生成视频模型接收一个提示词并返回一段视频；如果你想要不同的东西，就得重新开始，得到一段不相关的视频。Hy-Nomas 以片段链的形式生成一个世界，并保留自己的历史。

具体来说，这张卡片描述了同时发生的四件事。每个片段都有自己的提示词，因此你可以在生成过程中引入对象、改变风格、调整场景或描述动作，而不必事先就把这些都指定好。一个持久化的键/值缓存会把已生成的历史向前传递，因此后续片段会以已经生成的内容为条件，而不是从头凭空编造。相机运动是一条独立的条件控制路径，而不是靠散文式描述来实现：你提供相机到世界矩阵和内参，模型会在每个块中关注它们。而且由于片段是自回归生成的，只要你持续向它输入指令，世界就可以不断扩展。

提示词格式体现了这一过程有多字面化。离线推理接收一个 JSON 列表，其中每个条目都有一个风格、一个视角、一个主体列表，然后是分时段片段——开始和结束时间、一段较长的视觉描述，以及带有各自时间戳的包含动作。第一个片段确立世界；后续片段使用 description_change 字段来说明它应如何演变。随附示例围绕一只小橙狐构建了一片发光的森林，然后在两秒标记处于其路径旁绽放出发光的蓝色花朵。

卡片上的一个数字很容易被误读，而卡片本身也指出了这一点：24 FPS 是输出视频的播放速率，不是生成速度。模型实际运行得有多快，取决于硬件、分辨率、片段长度以及缓存中保留了多少历史信息。Tencent 也直接说明了这一点。在一份既没有公布延迟、也没有公布评分的发布中，这是对这个数字唯一诚实的解读。

卡片确实提供的规格表

腾讯在架构方面异常精确，这正是那些缺失的结果显得别有所指的原因。

• 主干网络 — 根据推理配置，包含 54 个双流 MMDiT 块，无单流块。

• 宽度——隐藏层大小为 2,048，具有 16 个注意力头，每个头 128 维，以及 4× 的前馈网络扩展至 8,192。

• 位置编码 — 采用维度为 [16, 56, 56]、theta 为 256 的 3D RoPE。

文本路径——Qwen2.5-VL-7B-Instruct 的语言模型组件，其 3,584 维隐藏状态经过两层 token 精炼器，并投影到 2,048 维的 DiT 空间。

• 相机路径——归一化的 4×4 外参，跨四帧分组并展平为 64 维，在每个块中通过交叉注意力加以应用。

• 潜在表示 — DCAE-V f32t4c32：32 个通道，32× 空间压缩，4× 时间压缩。

• 解码器——一个经过微调的 PixelUMM，具有 36 层、4,096 隐藏维度、32 个查询头和 8 个 KV 头，在 10 潜帧窗口（5 帧重叠）上运行一个解码步骤。

输出 — 720 × 1280，24 FPS，在蒸馏配置下采用 8 个去噪步骤；代码仓库称，蒸馏检查点支持 4、6 或 8 个步骤。

• 许可证 — Apache 2.0，其中 Qwen 文本编码器仍遵循其自身条款。

腾讯从未披露的一个数字是总参数量。最接近的数字是推算出来的，而非公布的：一个 34.2 GB 的 fp32 DiT 检查点按每个参数 4 字节计算，约为 85 亿个参数，而 9.06 GB 的 INT8 版本与此相符。应把它视为基于文件大小的算术推算，而不是规格表上的声明——厂商从未在任何地方确认过这一点。

运行成本是多少，这才是真正的门槛

这次发布对外部用户没有任何不友好之处，但默认部署假定你拥有的是一台节点，而不是一台笔记本电脑。标准推理配置采用 8 路序列并行，因此其默认启动要求在一个推理组中配备八块 GPU。README 对这一点写得很直白，而不是把它藏在深处。

确实存在一条真正的单 GPU 路径，而它是本次发布中最有意思的工程实现。它通过结合四种技巧在单块 RTX 4090 上运行：DiT 权重以及缓存的键和值以 INT8 存储，而计算仍保持 BF16；解码器通过 CUTLASS 以 FP8 运行；文本编码器和两个网络在各自阶段于 CPU 和 GPU 之间往返切换；活跃的 GPU 历史被限制在 18 个潜帧，较旧的历史则归档到系统内存中。最后这项取舍是在围绕它做规划之前需要理解的一点：归档会持续增长，18 帧的预算只限制驻留在 GPU 上的内容，而当前分段的显存占用完全不受它限制。腾讯明确表示，CPU–GPU 传输会增加延迟，并且峰值 GPU 显存会随分辨率和分段长度而变化。

下载量的推算来自文件大小。文档记录的演示路径需要蒸馏版 DiT（34.2 GB）、配套的 PixelUMM 解码器（31.55 GB）、DCAE-V（4.28 GB），以及 Qwen 编码器大约还要 16 GB——在开始生成任何内容之前，总共约 86 GB。单 GPU 路径改用 INT8 DiT 和 FP8 解码器，占用空间小得多，接近 38 GB 外加编码器。两个 LoRA 适配器需要分别占用磁盘：一个 6.12 GB 的电影风格适配器，以及一个 12.24 GB 的机器人适配器，后者在 RealSource-World 双臂数据集上训练；两者都旨在合并到浮点 DiT 中。INT8 加载器在推理时无法接受单独的 LoRA，因此这两条路径无法组合使用。

环境要求同样具体：Linux、Python 3.12 或更高版本、CUDA 13.0 Toolkit、PyTorch 2.10.0，以及 FlashAttention 2、FlashAttention 3 和 MagiAttention 的构建版本。推荐使用预构建镜像，hynomasoss/hynomasoss:cu130，而不是手动方式——原因在于注意力内核编译。代码仓库中的训练配置则更进一步：DP16 × SP8、128 块 GPU、序列打包至 360,000 个 token。无论你如何处理这些权重，你都不可能在家里重新训练它。

腾讯发布的基准测试没有附带分数

Hy-Nomas-Bench 并非事后补充。它是一个真实的数据集：包含四个评估套件，覆盖多轮自由形式文本交互、相机导航、交错的文本与相机控制以及空间记忆，共有 280 个测试用例、220 条参考相机轨迹、结构化提示、交互序列和键盘时间线，以 JSON 形式在 Apache 2.0 下发布，并组织为仅用于评估的划分。它大约比权重发布早两小时上线。

它没有附带的是结果表。没有排行榜，没有各测试套件的得分，没有与其他任何模型的比较，也没有任何迹象表明会有这些内容。而这张卡片措辞谨慎，读起来像是有意为之：在列出架构和采样默认值之后，它又加了一句——“架构和采样默认值属于配置细节，而非基准测试结果。”

那句话确实在发挥实际作用。它意味着八个去噪步骤、720 × 1280 分辨率和 1.0 的相机引导尺度并不能作为质量证据，而 Tencent 拒绝让它们被如此解读。对任何评估该模型的人来说，实际后果很简单：你可以自己运行评估；在那之前，你无法把 Hy-Nomas 与任何其他东西按数值并列比较。如果你想要一个结论，该套件才是值得下载的东西，因为没人会直接把结论交给你。

它与其他开放世界模型相比处于什么位置

2026年，该领域发展迅速，真正重要的比较并非参数数量，而是每次发布带来了哪些证据。

• 权重与许可——Hy-Nomas 采用 Apache 2.0，无访问限制。来自蚂蚁集团的 LingBot-World 于 2026 年 1 月下旬发布了开放权重，并被宣传为首个可与谷歌闭源的 Genie 3 相媲美的开放模型。

• 控制方案——Hy-Nomas 以文本为先，并采用逐段式的镜头轨迹。LingBot-World 和 Genie 3 系列则主打通过键盘和鼠标实时控制角色或摄像机，这属于另一种交互模型：连续游玩，而非定向构建。

• 硬件门槛——Hy-Nomas 默认需要八块 GPU，或一块 RTX 4090 并限制历史长度。2026 年 9 月发布的 Astronex-World 1.0 报告称，在单块 48 GB L20 上以 832 × 480 的分辨率实时串流，这一门槛明显更低。

• 证据——正是在这一点上，Hy-Nomas 孤零零地站在了错误的那一栏。LingBot-World 发布时附带了所报告的吞吐量和延迟数据；Astronex-World 发布时附带了 arXiv 论文和基准测试分数。Hy-Nomas 的技术报告是一个 404，而且没有任何分数。

沿革——腾讯此前的开放交互尝试 HY-WorldPlay，是在 720p 和 24 FPS 下基于起始图像外加姿态与动作输入运行的。Hy-Nomas 并非只是换了个名字的同一模型；文本多轮循环和按片段划分的提示结构都是新的，而且卡片并未声称其源自 HY-WorldPlay。

这些都不能说明质量如何。一个模型可以非常出色却缺乏文档记录，而腾讯的沉默无论怎样都不能作为证据——它只是意味着举证责任转移到了下载它的人身上。

现在谁应该碰它，谁应该等待？

如果你有一个八 GPU 节点，而你的问题是人类在生成过程中会编辑的世界状态——一个在第四秒增加了一个物体的场景、一个因为你让它转所以转动的相机、一个在你改变天气时仍保持几何结构的世界——这就是目前可下载的、对该想法最直接的开放实现，而 Apache 2.0 条款意味着你可以在无需谈判的情况下在其之上构建。机器人 LoRA 是一个信号，表明腾讯期望它被用在哪里：用于具身训练的仿真世界，而不是社交视频。

如果你在做出承诺之前需要一个数字，那就等等。不是因为模型可疑，而是因为没有什么可引用的。一个你必须自己运行的基准测试要花一周的工程工作，而技术报告出现时，很可能会改变你原本会测量的内容。

围绕这个模型还有一个较小的运维问题值得点明，因为任何试图复现该演示的人都会踩到这个坑。网页演示会把每条指令都经由 Nomas-PE 处理，这是一个独立的 55.6 GB 服务，负责把用户较为随意的措辞转换成 DiT 所期望的结构化 segment JSON，腾讯表示该演示需要它。离线推理会跳过这一步，并要求你自己编写结构化提示词。如果你在构建自己的前端，那么这个提示词构造层就是一次普通的语言模型调用——而与视频栈不同，这部分属于通用基础设施。OrcaRouter 并不提供 Hy-Nomas——一个 196 GB 的自托管扩散栈并不是 API 路由的用途所在。它路由的是围绕它的文本侧——用一个密钥以供应商标价 0% 加价访问 200 多个模型，并具备自动故障转移——因此，在自托管视频模型前面加上提示词重写或输出描述生成步骤，并不需要单独的供应商合同。

悬而未决的问题，以及哪些情况会改变这篇文章

有四件事确实尚属未知，而每一件都有一件足以定论的具体实物。

首先是质量。Hy-Nomas-Bench 已经存在，因此公布一份结果表显然是下一步，而缺少这份结果表正是本次发布与可引用版本之间的最大单一差距。

第二点是速度。卡片上任何地方都没有出现延迟数据，只有播放速率。总得有人在真实硬件上测量首段生成时间（time-to-first-segment），而八步蒸馏配置与基础自回归模型之间的差异，是值得量化而非想当然的。

第三是生态支持。仓库带有 diffusers 标签，但文档记录的路径是腾讯自家的 hymm 包和专门构建的 Docker 镜像；没有任何第三方运行时被列为支持。它能否像大多数开源视频模型最终那样，在主流库中获得一个 pipeline 类，决定了它仍是研究产物还是成为工具。

第四个问题是腾讯究竟有没有对此说过什么。技术报告标注为“即将推出”，目前访问会返回 404；没有 arXiv 预印本；截至 10 月 23 日也没有任何媒体报道。公司完全有可能是在等一篇论文或一个托管产品，然后再对外宣传这些内容。也有可能这次发布就是它看起来的样子：权重已发布留档，而公告则被推迟。

不管怎样，下载已经上线，许可证很宽松，而且演示今天就能接受指令。对于一个没人宣布过的模型来说，这比大多数静默发布提供的更多——也比一次正式发布少得多。