PAN 2 先有了服务路径，之后才有了公告

2026年11月10日16:03 UTC，一个为 PAN 2 的文本生成视频和图像生成视频增加 Day-0 支持的拉取请求完成合并，进入 vLLM-Omni。同日20:55 UTC，第二个拉取请求新增了说明如何部署该模型的 recipe 页面。PAN 2 是 MBZUAI 基础模型研究所（Institute of Foundation Models）推出的一个290亿参数视频扩散 Transformer，而这两次合并之所以成为新闻，关键在于它们到来的先后顺序。Hugging Face 仓库的时间是2026年10月7日，GitHub 仓库是11月5日，因此在五周时间里，该模型唯一的公开痕迹就是仓库元数据。我能找到的第一条第一方声明，是该实验室自己的 X 账号 @IFM_AI 发布的一条帖子，时间戳为11月10日17:00 UTC——比 vLLM-Omni 合并晚五十六分钟，比 recipe 早近四小时。帖子写道：“推出 PAN 2：一个面向物理智能的开放基础世界模型”，配有一段视频，除自身外没有链接到任何内容。没有博客文章，没有论文 URL，没有托管端点，没有定价页面，没有新闻稿。所以服务路径确实先于公告出现，而当公告到来时，它比合并本身还要小：几百个点赞和两段文字。存在的东西是86.17 GB的 Apache-2.0 检查点、一个框架集成，以及一条推文。

实际落地了哪些内容，顺序又是怎样的

发生了四件彼此独立的事，而把它们混为一谈，正是让一次静默发布被误认为一次正式发布的原因。

• 权重——Hugging Face 上的 IFM/PAN2，仓库创建于 2026 年 10 月 7 日 23:42 UTC，最后修改于 2026 年 11 月 9 日 21:52 UTC，其中一次提交添加了安全检查器支持，作为 Diffusers 模块化流水线组件。共六十个文件，86.17 GB，无访问限制，Apache-2.0。

• 代码——github.com/ifm-ai/PAN2，创建于 2026 年 11 月 5 日，当天 20:13 UTC 推送了唯一一次提交。这不是一个 README 已失效的研究资料堆砌：其中有推理脚本、环境版本锁定、训练配置、一个提示词重写器技能，以及部署、训练和推理文档。

• 服务路径——用于 Day-0 文本到视频和图像到视频支持的 vLLM-Omni PR #8602，于 11 月 10 日 16:03 UTC 合并；以及 vLLM recipe PR #10126，于当晚 20:55 UTC 合并。

• 声明——X 上的 @IFM_AI，11月10日 17:00 UTC：“推出 PAN 2：一个面向物理智能的开放基础世界模型。”两段文字、一段视频，没有指向帖子、论文或页面的链接。

这种先后顺序很不寻常，而那条公告正是让事情显得更古怪、而不是更正常的因素。通常，一家实验室会先发布公告、公布权重，随后框架支持会在接下来的几周里陆续到位，同时用户提交 issue。而在这里，框架合并先发生，公告在五十六分钟后才出现，配方又在四小时之后才来。这个模型短暂生命周期中最实质性的公开产物仍然是一个拉取请求，这多少说明了这次发布是如何进行的：它像是面向那些会读代码仓库的人做的一次产物投放，而社交平台帖子几乎像是事后才补上的。

仓库会告诉你什么

比大多数发布文章更胜一筹。PAN 2 是一个世界模型，而不是一款带有电影化倾向的视频生成器——这一区别是架构层面的，而非修辞层面的。它实现了 《世界模型批判》（arXiv 2507.05169）中描述的 Generative Latent Prediction 模式，并将任务拆成两部分。概念推理器——即任何遵循指令的语言模型——读取观测和所请求的动作，并将下一世界状态写成结构化、以时间为锚定的字幕：按顺序列出事件、把动作绑定到行动者、描述摄像机运动。一个冻结的文本编码器将该字幕映射为条件特征。随后，一个 29B 多模态扩散 Transformer——它在数亿个以相同格式标注的视频上从头训练——预测字幕未涉及的感知细节。Wan 2.2 VAE 解码潜在表示，最终得到的是一段最长 20 秒、704×1248、24 帧/秒的视频。

已公布的配置足够具体，可以用来核算成本。Transformer 配置列出了 44 层、32 个注意力头（每个 128 维）、1×2×2 的 patch 大小、97 个输入通道和 48 个输出通道。默认采样器为 50 步，flow shift 为 9，每一步都使用 2.5 的无分类器引导。默认长度为 241 帧，约十秒；上限为 481 帧。文本编码器是 Qwen3.5-9B，已冻结且未修改，VAE 则来自 Wan 2.2。两者都从各自的仓库下载——MBZUAI 不再分发它们，模型卡也特意说明了这一点。

仓库里还附带了一个 prompt-rewriter 技能，其中包含系统提示词、固定的负面提示词，以及一个校验器；该校验器会依据文本编码器的 token 预算来检查说明文字：软限制为 1,480 个 token，硬容量为 1,536 个 token。这是这批交付物中最有用的单个产物。它说明该模型其实并不能很好地处理自由文本，也说明团队对此心知肚明。

它不会告诉你的事

买家几乎会问的所有问题，这里都已涵盖。没有价格，因为没有 API。MBZUAI 没有提供托管端点。也没有独立基准测试：模型卡中的数字都是团队自己测得的，用的是他们自己的测试框架，而且模型卡对测试条件的说明异常坦率——Physics-IQ Verified 经过归一化处理，使两次真实拍摄之间的方差等于 100；PhyGround 由 Qwen3.8-27B 按五分制评分；RBench 则是对五项任务和四个具身类别取未加权平均值。这些都是站得住脚的选择，但没有一项属于第三方验证。

人工评估是此次发布中最有力的证据，也是最有限的证据。针对 140 个提示词的盲测成对偏好——其中 90 个文生视频、50 个图生视频——由 13 名评审在 1,400 次比较中根据动作遵循、物理规律和世界一致性进行评判，Elo 采用 Bradley–Terry 拟合，并以 1500 为中心。13 名评审是一个小评审团，而且他们评判的是团队自己的模型与基线模型的对比。这比大多数实验室公布的内容都多。但它不是排行榜。

而局限性部分的措辞比这类文献的惯例更为直白：大约每三份模拟计划中就有两份，至少包含一个并未被执行的步骤。这一句话是整份发布材料中最重要的数字，也正是发布宣传稿会刻意掩埋的那一个。

配方中的吞吐量数字才是真正的关键。

框架支持之所以重要，是因为该配方所声称的内容，而不是因为加了个 logo。vLLM 配方页面称，PAN 2 在四块 B300 GPU 上大约 119 秒即可生成 13 秒的 704×1248 视频，其中采用跨两个 rank 的无分类器引导并行，以及跨两个 rank 的 Ulysses 序列并行。默认配置是八块 H200、BF16 精度，而文档中给出的 serve 命令还在 tile 模式下增加了跨四个 rank 的 VAE patch 并行——这个细节之所以重要，仅仅是因为解码一段 20 秒的 704×1248 视频本身就是一个显存难题。

把这些数字与采样器设置对照来看。五十步且每一步都启用引导，意味着每个片段都要通过一个 29B Transformer 进行一百次前向传递。这就是为什么该指南以并行而非串行方式运行引导。这也是为什么关于 PAN 2 的实际问题不是“它有多好”，而是“一个片段要花我多少成本”，而按照厂商自己的配方，答案是每十三秒视频需要一个四 GPU 节点运行两分钟。还没有人公布更便宜的配置，而该配方默认使用八块 H200，这表明四块 B300 的配置是勉强压缩出来的，而不是一个舒适的下限。

如果你想试试，规划器就是你可以租用的那部分

PAN 2 的两阶段设计带来了一个奇怪的实际后果。昂贵的那一半——29B 的扩散主干——正是你必须自行托管的那一半，因为没有人把它作为服务提供，而 MBZUAI 也没有构建这样的服务。便宜的那一半，即编写结构化世界状态描述的概念推理器，是一个普通的文本模型，可以是任何遵循指令的模型。

这正是路由器发挥作用的地方。PAN 2 报告评估了四个推理模型，并按完整计划完成度对它们进行排名：Claude Opus 5.5 第一，其次是中等强度的 GPT-6 Astra，然后是 Kimi K3，最后是 Qwen3.8-Flash。Qwen3.8-Flash 已接入 OrcaRouter，因此你可以通过一个 API 密钥驱动 PAN 2 的字幕阶段，并具备自动故障转移，而不必在扩散栈旁再部署第二个本地模型；并且按提供商的标价付费，0% 加价转嫁。渲染器留在你的 GPU 上；规划器则不必如此。

要明确它是什么、不是什么。OrcaRouter 不托管 PAN 2，也无法路由它——任何地方都没有可路由的托管版 PAN 2。它能做的是，把世界模型流水线中语言这一半放在按量计费的 API 上，同时让你按自己的硬件来规划视频这一半的规模。如果你更愿意在本地运行这两个阶段，仓库也支持这种做法，并且专门为这种情况附带了 prompt-rewriter 脚本。

什么情况会被视为公告？

三件事，按重要性从低到高排列。一篇来自 IFM 或 MBZUAI 的帖子、论文或页面，其中点名 PAN 2，并说明发布日期或版本——11 月 10 日的推文只满足了前半部分，没有满足后半部分。一个托管式推理端点，这将使成本比较成为可能：与闭源视频模型比较，而不是与 GPU 租用比较。以及一项由并非该模型作者的人运行的独立基准测试——由第三方在团队并未选择的提示词上对 Physics-IQ、PhyGround 或 RBench 进行评分。

至少在其中第一项完全到位之前，对 PAN 2 的诚实描述是这样的：一个 Apache-2.0 研究工件，具备可用的服务路径、有文档记录的提示格式、坦诚的局限性说明、一篇社交帖子，背后没有任何商业报价。这比预印本多一点，比产品少一点。11 月 10 日到来的框架支持并没有让它成为一次发布。它只是让那些不想为了得到第一帧就去给仓库打补丁的人也能运行它。

底线

PAN 2 是一个罕见案例：工程实现走在了文书工作前面。如果你正在构建智能体仿真、机器人评估或物理推理研究，并且拥有一台四 GPU 节点，那么权重已经就位，训练配方已经就位，两阶段设计也有足够充分的文档可供复现。如果你需要每个片段的单价、服务级别协议，或者一个可以打电话联系的供应商，这些目前都还不存在，而 11 月 10 日的合并也没有创造出它们。该模型悄无声息地发布了——如果“发布”这个词还能用于一个代码仓库、一次合并和一篇两段话的帖子的话。至于它最终是否会以买家能识别的方式被正式宣布，这与它是否能工作是两个独立的问题，而今天只有其中一个问题有答案。