PAN 2 对决 Qwen3.8-27B：对手已在模型之中

大多数模型对比都有清晰的边界：两个检查点、两个厂商，二选一。这个对比却没有，因为 Qwen 同时贯穿 PAN 2 的三处底层管线。PAN 2 将 Qwen3.5-9B 作为其冻结的文本编码器加载，该组件把结构化的世界状态描述转换为供其 290 亿参数扩散 Transformer 使用的条件特征。PAN 2 自家技术报告中的 PhyGround 分数由 Qwen3.8-27B 评判，而本页名义上正是拿 PAN 2 与这个模型作比较。并且 Qwen3.8-Flash 是该报告为撰写 PAN 2 的描述文本而进行基准测试的四个概念推理器之一。因此，诚实的表述框架并不是 PAN 2 对 Qwen3.8-27B。它其实是一个来自 MBZUAI 基础模型研究所的视频世界模型——低调发布、从未正式推出，建立在 Qwen 组件之上，部分由 Qwen 裁判评分——与阿里巴巴一个 270 亿参数的视觉语言模型相比较，而后者本身就是一个完整产品。有趣的问题是，当你选择要部署什么时，这些关系中哪些才值得你关心。

共享DNA意味着什么、不意味着什么

这并不意味着这两个模型可以相提并论。PAN 2 输出视频；Qwen3.8-27B 输出文本。共享编码器中的任何内容都不会改变这一点，也不存在任何能将二者相互排名的基准测试。任何给出正面对比分数的人，给出的都只是一种印象。

这确实意味着，这种比较在来源信息上具有非同寻常的揭示力。当 PAN 2 读取你的说明文字时，它是通过一个由 MBZUAI 从其自有代码仓库中原样下载、未经修改的 Qwen 编码器来读取的，而且模型卡明确说明：Qwen3.5-9B 的权重按发布时的原样使用，MBZUAI 并未对其进行微调。提示词验证器所执行的 token 预算——软性上限 1,480 个 token，硬性上限 1,536 个 token——是 Qwen3.5-9B 的预算，而不是 PAN 2 的预算。而当报告声称某个 PhyGround 数字时，该数字是通过让 Qwen3.8-27B 按五分制对生成的视频打分而产生的。评判者正是竞争对手。

这不是丑闻。使用强大的开放模型作为自动评分器是标准做法，而且公开披露这一点比大多数实验室做得更好。但这确实意味着，PAN 2 的证据链在三个不同环节都要经过阿里巴巴的模型系列；如果你在评估 PAN 2，就应该知道它的哪些数字是对 PAN 2 的测量，哪些是 Qwen 所看到的 PAN 2 的测量。

Qwen3.8-27B，以它自己的方式

阿里巴巴的模型则完全是另一类对象：一个拥有 270 亿参数、带视觉编码器的因果语言模型，基于 Qwen3.5 架构，采用混合布局——每三个 Gated DeltaNet 块后接一个 Gated Attention 块，如此重复十六次，共 64 层，隐藏维度为 5,120，填充词表大小为 248,320 个 token。原生上下文为 262,144 个 token，可扩展至 100 万。它采用 Apache-2.0 许可，于 2026 年 8 月 5 日上线 Hugging Face，月下载量为 740 万次。

厂商给出的数据很强，而且这张模型卡在开放权重领域属于更完整的之一：GPQA Diamond 89.2，HLE 30.8，LiveCodeBench v6 90.3，SWE-bench Pro 61.7，Terminal-Bench 2.1 为 73.0，OSWorld-Verified 84.3，OmniDocBench 1.5 为 91.1，CharXiv 推理 83.7，IFBench 79.5，CoWorkBench 70.7。在 MathVision 上，它报告无思维链时为 90.0，有思维链时为 94.6。这些是阿里巴巴自己的评估，对照的是阿里巴巴自己的基线；这一保留意见同样适用于本站每一张厂商表格，包括 PAN 2 的表格。

• 模态 — Qwen3.8-27B：输入文本、图像和视频；输出文本。PAN 2：输入可选的首帧加结构化描述；输出 MP4。

• 规模 — Qwen3.8-27B：27B 稠密模型，64 层，约 278 亿个 safetensors 参数。PAN 2：一个 29B 的扩散 Transformer，BF16 下为 67.37 GB，外加一个 15.87 GB 的冻结 Qwen3.5-9B 编码器和一个 Wan 2.2 VAE。

• 上下文 — Qwen3.8-27B：原生 262,144 个 token，最高可达 100 万。PAN 2：单条描述文本上限为 1,536 个文本编码器 token，并提供一张起始帧。

• 许可证 — Qwen3.8-27B：Apache-2.0。PAN 2：其自身权重采用 Apache-2.0，第三方组件则遵循其各自的条款。

• 服务 — Qwen3.8-27B：Transformers、vLLM、SGLang、TokenSpeed，以及 Alibaba 列为即将推出的托管式 Qwen Cloud 端点。PAN 2：Diffusers、vLLM-Omni 和仓库自带的 generate.py，运行在你的硬件上，且不在任何地方托管。

为什么编码器的选择是 PAN 2 卡片中最关键的一行

冻结一个 9B 文本编码器、只训练扩散主干，是一个站得住脚的工程决策，也正是 PAN 2 的扩散部分为 {{1}}29B{{/1}} 而非 {{2}}40{{/2}} 的原因。这也硬性限制了 PAN 2 所能接收的信息。概念推理器写出描述文本；Qwen3.5-9B 将其映射为特征；扩散模型再根据这些特征进行渲染。无论描述文本有多好，Qwen3.5-9B 无法表示的内容，PAN 2 就无法模拟。

这解释了一个卡片上直白写明、而大多数读者会略过的局限：模型对提示词的措辞很敏感，超出训练分布的示例依赖手工精炼的提示词，而文本动作对灵巧操作的描述只能达到粗略程度。这并不是三个彼此独立的问题。它们是同一个问题从三个角度呈现出来的样子——语言描述与固定文本编码器之间的接口，而一侧是 1,536 个 token 的预算和冻结的词表。

将其与 Qwen3.8-27B 处理同一任务的方式进行对比。它把推理器和编码器合为一体，具有 262,144 token 的上下文窗口、可按请求禁用的原生思考控制、一个 reasoning_effort 参数，以及用于跨轮次保留推理上下文的 preserve_thinking。如果你的任务是把场景和计划描述得足够详细，以便下游能据此采取行动，那么 Qwen3.8-27B 正是为此而构建，而 PAN 2 则是为了消费其输出而构建。它们并非争夺同一位置的竞争对手；一个位于另一个的上游。

没人会写进对比表里的部署不对称性

Qwen3.8-27B 是一个大模型，运行起来就像一个普通的大模型。270 亿参数在 BF16 精度下大约是 55 GB 的权重，可以放进一块 80 GB 的加速卡，并且还留有 KV 缓存的空间；模型卡上还列出了四套服务栈，另有一个兼容 OpenAI 的托管端点即将推出。你决定使用它的当天下午，它就能开始应答请求。

PAN 2 共有六十个文件、总计 86.17 GB，其服务计算以节点分钟为单位。采样器进行五十步，且每一步都启用无分类器引导，这意味着每个片段都要让一个 29B transformer 完成一百次前向传递。vLLM 方案的亮点是在四块 B300 GPU 上，用约 119 秒生成 13 秒的 704×1248 视频；其中引导在两个 rank 上并行，Ulysses 序列并行则在另外两个 rank 上运行。其默认配置是八块 H200、BF16，并在 tile 模式下跨四个 rank 进行 VAE patch 并行。仓库自带的推理脚本更简单，也更吃资源：每块 GPU 一个 worker，每个 worker 都持有一份完整的 67.37 GB transformer，并各自处理每第 N 个提示词。

把这两者放在一起看，实际结论并不接近。一次 Qwen3.8-27B 调用只是一个请求。一个 PAN 2 片段则是一项附带 GPU 预留的批处理任务。如果你只需要制作一次一段二十秒的视频，PAN 2 就是一下午的配置加三分钟的渲染。如果你要模拟一千个方案，你买的是某个节点上的时间，真正有意义的比较对象是其他视频世界模型，而不是语言模型。

两者真正交汇的唯一之处

PAN 2 的预期用途是模拟推理：智能体会设想每个候选行动的结果，然后选定最佳行动。这一循环需要一个生成候选行动的规划器，以及一个呈现其后果的模拟器。Qwen3.8-27B 是一个可信的规划器——在 IFBench 上以 79.5 展现出强大的指令遵循能力，在 CoWorkBench 上以 70.7 展现出长周期办公工作能力，在 Terminal-Bench 2.1 上以 73.0 展现出智能体终端编码能力——而且它已经身处这一循环之中，因为 MBZUAI 曾让它作为四位图注撰写者之一，对 PhyGround 和 Qwen3.8-Flash 进行评判。

如果你构建那个循环，规划器是你可以按 token 购买的部分，而模拟器是你无法购买的部分。Qwen3.8-27B 已在 OrcaRouter 上线，因此只需一个 API key，你就能获得一个具备自动故障转移、可决定哪些请求发往何处的路由规则，以及按供应商标价0% 加价原样传递的规划器——包括阿里巴巴在其降价生效当天的自有降价。OrcaRouter 不托管 PAN 2，也无法路由它；没有人托管 PAN 2。这种分离不是路由器的局限，而是市场的形态：托管语言模型已是商品，托管视频世界模型尚不存在。

选择路由而不是固定规划器，还有第二个更低调的理由。PAN 2 的报告按完整计划完成度对四个推理模型进行了排名，而这个排名并不是大多数人会猜到的——Claude Opus 5.5 第一，GPT-6 Astra 在中等投入下第二，Kimi K3 第三，Qwen3.8-Flash 第四。该顺序是在 MBZUAI 的提示词、他们的字幕策略和他们的验证器上测得的。你的结果会有所不同。能够在不重新改造整套技术栈的情况下重新运行这项比较，其价值超过了其中任何一个单一模型的选择。

如何处理这个对比

如果你来这里是想从中挑一个，那么诚实的答案是：这个问题本身就问得不成立。Qwen3.8-27B 是一个通用的视觉语言模型，你今天就能在单块加速器上部署服务，下周也能按 token 租用。PAN 2 则是一个研究产物：它能渲染出后果，需要多 GPU 节点，没有托管端点，而且截至 2026 年 11 月 11 日，它从未由自己的作者发布过——实验室 X 账号上那篇两段式帖子就是全部公告。它的 Hugging Face 仓库日期为 10 月 7 日，GitHub 仓库日期为 11 月 5 日，而它发生的最实质性的公开事件，是 vLLM-Omni 的 Day-0 支持于 11 月 10 日合并。

值得做的比较范围更窄。如果你的流水线需要一个规划器，Qwen3.8-27B 是一个强大、文档完善、采用 Apache-2.0 的选择，而这个决定属于路由决策。如果你的流水线需要在执行动作之前看清它会带来什么结果，PAN 2 是极少数尝试这一方向的开放权重模型之一；无论你是否注意到，它都会运行在 Qwen 组件上；而对其能力最诚实的总结，就是它自己“局限性”部分里的那句话：大约三分之二的模拟计划中，至少有一个步骤没有被执行。这才是你制定计划时应当围绕的数字，也是整个比较中唯一一个没有任何编码器、评判器或路由器能替你改善的数字。