Duo-1.0-causal-base：153 GB 权重、一篇论文，却没有发布公告

11月12日06:32 UTC，一个名为Duo-1.0-causal-base的 Hugging Face 仓库完成了首次提交：80 个文件、153.46 GB，以及一个包含视觉语言主干、音视频扩散 Transformer、两个编解码器、一个语音识别器和一个强制对齐器的软件包。其背后的论文前一天已发布在 arXiv 上。二十四小时内又出现了三个姊妹仓库，其中一个今天上午仍在上传。该仓库自己日期为 11 月 13 日的新闻区块将这一切称为一次发布。除此之外，几乎没有任何其他来源这样称呼。我找不到任何发布帖、托管端点、定价页面，也找不到任何针对Duo-1.0-causal-base的独立基准测试——而那 153 GB 中的许可证文件将其授权范围排除欧盟、英国、韩国和美国。

所以这不是一篇发布稿，因为并没有发布。这也不是一篇爆料稿，因为权重是公开的、无需门槛、且完整。接下来的内容要把每当研究实验室以代码仓库而非产品的形式推出成果时总会被混淆的两件事区分开：文件和论文究竟确立了什么，以及哪些事情尚未得到任何人证实。

落地了什么，按什么顺序

该序列可从仓库元数据中读出，这一点很重要，因为它是唯一的第一方记录。

• 论文——arXiv 2611.15131，Duo：面向全双工交互的互惠世界模型，从 Hengyuan Cao 到 Zhenzhong Lan 的二十位作者，于 2026 年 11 月 11 日提交。Hugging Face 论文页面显示有 27 个点赞，除此之外没有任何报道。

• 权重——inclusionAI 组织下的四个仓库，该组织自称是 Ant Group AGI 计划的所在地，其项目页面带有 2026 Ant Research 版权。Duo-1.0-causal-base 和 Duo-1.2-causal-base 创建于 11 月 12 日 06:30 和 06:32 UTC；Duo-1.0-distill 早二十五秒；Duo-1.0-distill-quant 于今天上午 08:09 UTC。

• 代码——github.com/inclusionAI/Duo，Apache-2.0，创建于11月6日，但仅包含一个提交，时间戳为今天09:13 UTC，截至撰写时已有六个星标且没有分叉。

• 该声明——README 的新闻区块，全部三行均标注日期 2026/11/13：论文、vLLM-Omni 和 SGLang-Omni 流式管道，以及 v1 权重和离线推理代码。

打包体积是读者首先可以着手处理的事项，因为它们不可互换。

• {{KEEP}}Duo-1.0-causal-base{{/KEEP}} —— 分布在 80 个文件中共 153.46 GB。实现权重 69.07 GB，意图模型 66.73 GB，视频与音频编解码器 11.02 GB，语音栈 6.54 GB，以及一个 84.8 MB 的适配器。

• Duo-1.2-causal-base — 153.46 GB，分布在 80 个文件中，仅被描述为“生成质量提升”，其蒸馏版和量化版则列为即将推出。

• Duo-1.0-distill — 2.78 GB，共八个文件。它是一个叠加层，而非模型：它会下载到与基础包相同的目录中，并将采样器设置替换为 Euler、四步、flow shift 5.0，而基础版本则是五十步、1.0。

• Duo-1.0-distill-quant — 47.03 GB。同样的四步叠加在 ModelOpt FP8 中采用逐通道缩放，并且卡片明确说明运行时必须支持该格式，或提供转换途径。

两个模块和一个 708 毫秒的时钟

从配置文件中就能看清架构，这比大多数模型卡能提供的信息要多。Duo 把这项工作一分为二。

Intent 模块声明为 Qwen3VLForConditionalGeneration——64 层、隐藏维度 5120，64 个注意力头，其中 8 个键值头，中间层大小为 25600，词表包含 151,936 个 token，并带有一个 27 层视觉塔，patch 大小为 16。各分片合计为 66.71 GB 的 bfloat16 权重。这是一个大型视觉语言模型，而模型卡从未给出参数数量，因此其规模等级是根据配置推断出来的，而非厂商提供的数字。在其之上还叠加了一个 LoRA 适配器，秩为 8、alpha 为 16，作用于 query、key、value 和 output 投影以及语言模型头，并包含四个可训练的特殊 token：<wait>、<blank>、<chunk_708> 和 <speak>。

那组词元就是整个想法的缩影。在每个 chunk 中，Intent 模块要么输出带文本的 <speak>，要么输出不带任何内容的 <wait>。决定何时说话，与决定说什么，是两个彼此独立的预测；这正是“只在你停下时才作答的模型”与“能够插话、保持沉默，或在你说话的同时继续说下去的模型”之间的区别。

Realization 模块是一个 MiniMaxH3DiTModel：隐藏维度为 5376 的 50 层、56 个维度为 128 的头、前馈宽度为 14336、1×2×2 的 patch、视频 24 个潜在通道和音频 32 个潜在通道，以及一个两层 token 精炼器，将 Intent 模块的隐藏状态融入条件信息。它从 MiniMax H3 权重初始化，NOTICE 文件写明了上游许可证。各分片共 535 个张量，总计 66.28 GB。

将它们串联起来的那个时钟，是值得记住的数字。交互以 17 个视频帧为一块运行，帧率为每秒 24 帧——即 708 毫秒。每个块被编码为五个视频潜变量，采用 1-4-4-4-4 的帧拆分；并编码为 2×29 个音频潜变量，因为音频在 32 kHz 下以每声道每秒 40 个潜变量运行，即每 25 毫秒一个。位置编码是与播放时间挂钩的三维 RoPE。注意力掩码的构建使得任何块都无法看到自身未来的干净媒体，这正是让整个系统具备因果性、可流式处理，而不是一个需要先有完整片段才能开始的扩散模型的原因。

延迟方面的说法属实，而且这是针对八块 GPU 的说法。

论文中的流式处理部分是此次发布内容中最具体的部分，也是在大多数读者所拥有的硬件上最难复现的部分。

• 意图推断 — 每块 90 至 160 毫秒。

• 在 768×576 下的联合潜变量生成——200 至 450 毫秒。

• 流式解码——每组四帧约需 30 毫秒。

• 开销 — 约 40 毫秒。

• 总计 — 330 至 650 毫秒，而周期目标为 17/24 秒；如果话语在窗口中途结束，还会有额外 708 毫秒的采样延迟。

这些数字来自八块 GPU 的布局。Intent 模块在 GPU 0–3 上与语音识别器一起跨四个 rank 运行张量并行；扩散 transformer 分布到全部八块 GPU 上，按每个 chunk 在张量并行或序列并行中选择在内存约束下使周期时间最小的一种；流式 VAE 在 GPU 4–7 上按空间分成四块。GPU 0–3 为 chunk k+1运行 Intent，而 GPU 4–7 解码 chunk k。输出以一个单帧锚点加四个四帧数据包的形式发布，最短播放间隔为 1/24 秒，约 41.7 ms，刻意长于 30 ms 的解码时间，以便缓冲区吸收抖动。

现在把这一点对照 README 的要求来看。参考离线部署需要两块 CUDA GPU——一块用于 Intent 和编解码器，一块用于 Realization——还需要两个 Python 环境，因为固定版本的 qwen-asr 包会引入它自己的 Transformers 版本，并且 FFmpeg 要在 PATH 中。这正是随附演示实际运行的配置。330 到 650 ms 这个数字假设使用八块 GPU，但未说明具体型号。两个数字都是诚实的；它们回答的是不同的问题，而两者之间的差距，正是论文结果与你本周就能搭起来的一台机器之间的距离。

93.3% 是作者在给自己的考试评分

这次评估有其不寻常之处，值得在任何人引用该百分比之前先加以说明。

三十个实时双工案例在共享时间线上并排回放，并以正常播放速度带声音进行评判，依据六项二分类标准及书面失败条件：内容响应性、语言符合度、语音可懂度、视觉身份稳定性、视听同步性和视听情感一致性。在 180 项检查中，168 项通过——93.3%。语言符合度、语音可懂度和视觉身份稳定性三项合计的 90 项检查全部通过。情感一致性为 96.7%，唇部对齐为 90.0%，内容响应性为 73.3%，即 30 项中的 22 项。

接下来有三件事，只有第一件是恭维话。

首先，在180项二元检查中取得93.3%的成绩，并附有书面失败条件，这比排行榜上的Elo分数更可证伪，而且失败分析异常具体：笑话和需要模型读懂字面之外含义的间接言论，以及只有把语音和视频结合起来解读才能明确的意图——论文中的例子是，一名用户在室内提到共享单车时天开始下雨，模型将其视为寻求建议的请求，而不是场景变化。

第二，评判者就是作者本人。没有第三方运行，没有盲法成对比较研究，也没有外部评审小组。带有书面条件的二元评分量表是合适的工具；但把它应用于你自己的输出，并不构成独立验证。

第三，也最能说明问题的是，论文中任何地方都没有基线比较。唯一的定量对比是数据合成上的消融实验：在一个由十个六秒块组成的六十秒序列中，基线到第九个块时损失了 34.2 个亮度级，而所提方法稳定在约 99。相关工作——Moshi、Qwen-Omni、Wan-Streamer、EMO、OmniHuman、LiveTalk、Self Forcing、CausVid——只是定性讨论，没有任何正面对比数字。论文也从未说明参数量或训练数据量。因此，诚实的总结是：Duo v1 是按照评分标准衡量的，而不是与另一个模型对比。

许可证才是决定你这一周的关键部分

这是改变采购决策的部分，而它被埋在 17 KB 的 LICENSE 文件中，而不是模型卡的正文里。

权重并非 Apache-2.0 许可。代码仓库是；权重不是。每个 Duo 检查点都附带 minimax-h3-community-license，因为 Realization 模块是从 MiniMax H3 初始化而来，且该许可证随衍生作品一同适用。捆绑包内的协议日期为 2026 年 8 月 2 日，并将“M​iniMax”定义为 Nanonoble Pte. Ltd.

其授权在地域上受到限制。“适用地域”指全球范围，但不包括除外地域，而除外地域为欧盟、英国、大韩民国和美利坚合众国。许可证文本邀请上述地域内的任何人联系 MiniMax，以获取“基于稳健的控制措施与防护机制”的许可证，这是一条途径，而非一种许可。

实际上，新加坡、瑞士、日本、印度、巴西或加拿大的研究团队今天就可以按照所述条款下载并运行它。而旧金山、伦敦、柏林或首尔的团队，按该文件的字面理解则不能，也不应该在为期两周的集成工作结束时才发现这一点。这种不对称也正是为什么在安排任何事情之前，需要检查的是许可证——而不是基准测试。

你今天可以实际运行的内容

离线路径有文档说明，而且很短。克隆仓库，创建两个虚拟环境——一个用于 Realization，一个用于语音栈——下载基础包，把 configs/inference.example.json 复制为 configs/inference.json，将其指向权重文件和两个 Python 可执行文件，然后启动 run_demo.py --config configs/inference.json --port 4173。界面是位于 /video/index.html 的浏览器页面。

对于流式处理，README 指向两个分支：vLLM-Omni（标记为推荐）和 SGLang-Omni。那正是延迟数据所描述的路径，也是需要八 GPU 布局的那一个。

关于你将看到的内容，有两点需要说明。项目页面上的演示来自训练数据和离线推理——页面已说明这一点，并补充称实时全双工结果“将很快添加”。而且该发布明确是预览版：“Duo v1 是面向研究人员的预览版”，支持“基础的音视频对话”，并承诺 v2 将使 Realization 直接以用户的音频和视频为条件，从而实现视觉交互。如果你感兴趣的是一款能观察你并对物体做出反应的模型，那么这项能力并不在此次发布中。

本周谁该关注，谁该等待

• 全双工交互研究——这是该类别中最具体的公开成果：一篇论文，包含延迟预算、分块时钟、蒸馏配方，以及真正可下载的权重。双 rollout 蒸馏——先 rollout 冻结的 Intent 模块，然后从模型自身的输出而非记录的历史生成媒体——即使你从不运行 Duo，这也是可迁移的思路。

• 正在构建虚拟形象或陪伴产品的团队——单凭 708 毫秒这一表述框架就值得一读。这个数字决定了一次插话感觉像真人还是像延迟，而它是一个你无需采用该模型也能采纳的设计约束。

排除地区的团队——等等，要把许可证谈判视为关键路径，而不是 GPU 预算。

• 任何想要 API 的人——这不是。模型卡明确说明，没有任何推理提供商在提供它，也没有供应商端点。

最后这一点正是路由器真正适用和不适用之处。OrcaRouter 不托管 Duo-1.0-causal-base，也无法路由它：一个 153 GB 的双模块扩散栈，带有固定的 708 毫秒分块时钟，并不是 chat-completions 的目标，再多的路由也改变不了这一点。真正可路由的是大多数团队在双工实验藏在功能开关后面运行时上线的基于轮次的回退方案——语音输入、语言模型、语音输出。语音输出这一环可以是一个托管的文本转语音模型，而不是同一对 GPU 上的另一个进程；并且通过一个覆盖 200 多个模型的 API 来完成，按提供商标价以 0% 加价透传，这样当供应商调价时，成本计算仍保持不变。自动故障转移应属于那些托管支路，而不是自托管的那条：当提供商抖动时，它能让演示保持存活，而对你运行在自己硬件上的栈却毫无作用。

另一种诚实的用途是评估纪律。让生产路径继续使用你可以调用的模型，并把 Duo-1.0-causal-base 视为一项带有书面评估标准的基准实验——鉴于唯一现有的评估标准是由其作者自己应用的，它恰恰就是这样的实验。

什么会改变判决？

三件事，按其重要程度从低到高排列。

由第三方对 Duo 团队未选择的提示词按六项标准进行评分。评分细则已经公布，这使得别人做这件事成本很低，而如果内容响应性在未见案例上真的是 73.3%，那对模型来说代价就很高。

一个不假设需要八块 GPU 的托管端点或服务方案。双 GPU 离线演示与八 GPU 延迟声明二者都属实，而两者之间的落差，恰恰是大多数读者实际所处的境地。

包含被排除地区的许可条款。架构上的任何变化都改变不了这个算术结果，基准测试再怎么提升也同样改变不了。

在此之前，对 Duo-1.0-causal-base 的准确描述是这样的：一个完整、无访问限制、153 GB 的研究捆绑包，带有真实的延迟预算和自评分评估，以论文和代码仓库的形式发布，附有一条带日期的新闻简讯，背后却没有产品。这比预印本更有分量——权重就在那里，演示也能运行——但远不及一个可以围绕其规划一个季度的模型。未解的问题不是 Duo 能否以 708 毫秒的切片进行对话，而是团队之外的人是否会被允许核查。