PAN 2 vs LFM2.5-2.6B-Base：两种专为微调而生的检查点

关于 LFM2.5-2.6B-Base，首先要注意的是 Base 这个词。Liquid AI 的这个 26.9 亿参数检查点并不是供你聊天的模型；它是预训练基底，经过后训练的 LFM2.5-2.6B 变体正是由此而来，公开发布是为了让别人也能构建自己的版本。PAN 2 是同一类对象，规模却是三十倍：一个来自 MBZUAI 的 Institute of Foundation Models 的 290 亿参数扩散 Transformer，以 Apache-2.0 许可发布，仓库中包含训练配置，意在供人适配，而非仅仅拿来使用。把它们放在一起看会显得荒谬——一个是能在笔记本电脑上运行的语言模型，另一个是需要四块 B300 的视频世界模型。但两者都是附带许可证的基础产物，而对于任何实际工作就是拿一个检查点、让它去做未被训练过的事情的人来说，真正有趣的比较根本不在能力。而在于各自为你提供了什么可用的东西，以及在你弄清它能做什么的过程中，持有它需要付出什么代价。

先从许可证说起，因为这是唯一一个硬性差异

PAN 2 自身的代码和权重采用 Apache-2.0 许可。第三方组件——作为文本编码器的 Qwen3.5-9B、作为 VAE 的 Wan 2.2、Diffusers——均按其各自条款使用，且不由 MBZUAI 再分发；你需要从各自作者处下载。这是一种干净、平淡、对企业法务友好的安排，也是拥有审核流程的公司能够采用 PAN 2 的主要原因。

LFM2.5-2.6B-Base 根据 LFM1.0 许可证发布，Hugging Face 将其记录为 其他，并附上 LICENSE 文件链接，而非 SPDX 标识符。这并不是批评——Liquid 的许可证允许在收入达到一定门槛前进行商业使用，这对开放权重发布来说是一种常见且合理的形态——但它与 Apache-2.0 的形态不同，而这种差异并不是你在微调之后才会发现的细节。如果您的法务团队有一份预先批准的许可证清单，那么这两个模型中的一个在清单上，另一个则需要进一步沟通。

这种不对称与参数量所体现的方向正好相反，值得好好琢磨。小模型才是那个附有条件的；而庞大的模型才是那个你可以不经任何人同意就发布的。

基础检查点实际上交给你的内容

LFM2.5-2.6B-Base 采用混合架构：共三十层，其中二十二层是双门控短卷积块，八层是分组查询注意力。这种混合正是 LFM 系列的核心所在——卷积块在长序列长度下开销低，注意力块则负责保持记忆召回——也正是它能在 26.9 亿参数下承载 131,072 个 token 上下文的原因。训练使用了 34 万亿个 token，词表规模为 128,000 个 token，覆盖十六种语言，包括阿拉伯语、日语、韩语、泰语和越南语。

它缺少的是任何后训练。没有指令微调，没有名副其实的聊天模板，也没有安全对齐。基础模型只预测下一个 token，仅此而已；这使它不适合在指令遵循基准上评估，却适合评估 LoRA 在你的领域上收敛得有多快。Liquid 单独发布经过后训练的兄弟模型，而该模型存在 GGUF 和 ONNX 构建版本，是最清晰不过的意图声明：这个模型家族就是用来在你自己的设备上运行的。

PAN 2 为你提供了相当多的脚手架，但在某个特定方面给你的自由度更少。仓库同时附带了预训练和有监督微调的训练配置——config/pretrain_29B_720p.yaml 和 config/sft_29B_720p.yaml——文档还要求你把它们的数据路径指向你自己的 latent。所以微调路径是存在的。但它所期望的数据并不是文本，而是以特定结构化描述格式标注的视频 latent：事件按顺序排列，动作绑定到主体，镜头运动，并且要控制在文本编码器 1,536 个 token 的预算内。如果你想在自己的领域上微调 PAN 2，你的第一个项目并不是一次训练运行，而是一条把你的素材转换成这种格式的数据流水线；仓库给了你一个校验器，却没有给你标注器。

• 微调所需算力 — LFM2.5-2.6B-Base：单块 GPU，在工作站上用 LoRA，数小时而非数周。PAN 2：一个在 BF16 下、尚未计入优化器状态就达 67.37 GB 的 Transformer，外加 15.87 GB 的冻结编码器和 VAE，作用于视频潜变量。多节点，且尚无人发布过配方。

• 你必须提供的数据 — LFM2.5-2.6B-Base：文本，采用你的任务所使用的任意格式。PAN 2：视频以及仓库模式中的结构化世界状态描述。

• 你会得到什么——LFM2.5-2.6B-Base：一个文本生成器；经过后训练后，则是一个助手或一个智能体策略。PAN 2：一段最长 20 秒、704×1248、24 fps 的视频，展示某个动作的后果。

• 许可证 — LFM2.5-2.6B-Base：LFM1.0，其他，请阅读。PAN 2：Apache-2.0 适用于其自身权重。

在它们几乎持平的那一项基准测试中

确实存在一处真实的重叠，而且它小得足以引人注意。OpenBMB 的 MiniCPM5-2B 模型卡将 LFM2.5-2.6B 与自家 2B 模型及其他若干模型进行基准对比，其中一行是长上下文。在 AA-LCR 上，OpenBMB 报告 LFM2.5-2.6B 为 5.3，而 MiniCPM5-2B 为 59.0。在 NoLiMa 上，为 0.7 对 68.1。在 LongBench v2 上，为 30.3 对 43.7。

{{1}}这些是竞争对手在其自家测试框架上报告的数字，而发布这些数字的模型卡在比较中显然存在利益关联。但两项最难的长上下文探针上的差距之大，并不是测试框架的选择所能解释掉的，而且它有助于纠正把“131,072 个 token 的上下文”当作能力主张来解读的做法。上下文窗口是一种容量；长距离召回是一种行为表现。Base 检查点具备前者，而根据第三方证据，后者并不算强——这正是为什么微调才是预期用途，而不是开箱即用的长文档助手。{{/1}}

PAN 2 没有同等的交叉核验。MBZUAI 之外无人对其进行基准测试，模型卡上的数字是唯一存在的数字。即便该模型的运行成本高出一百倍，其证据地位仍弱于 LFM2.5-2.6B-Base——这提醒我们，独立评估随采用而来，而采用又取决于能否真正运行它。

保留每个检查点的成本

LFM2.5-2.6B-Base 约有 27 亿参数。在 BF16 下，其权重轻松低于 6 GB，而经过后训练的同系列模型的 GGUF 构建版本更是将其降到远低于这一水平。你可以让它常驻在与其余技术栈相同的机器上，通宵微调，然后就忘了它的存在。

PAN 2 共有 60 个文件、总计 86.17 GB，而真正重要的不是总量，而是它的构成形态。Transformer 占 67.37 GB，并且每个推理工作进程都持有一份完整副本——该仓库自带的推理脚本会为每块 GPU 运行一个工作进程，每个进程处理每第 N 个提示词，因为这条路径中没有张量并行分片。vLLM 方案则是采用分片的选项，其亮点是在四块 B300 上，以约 119 秒生成 13 秒的 704×1248 视频，其中无分类器引导并行跨两个 rank，Ulysses 序列并行跨两个 rank。默认配置是八块 H200。一个 50 步采样器且每一步都启用引导，意味着每个片段要进行 100 次前向传播，而这就是该方案中每一项配置选择背后的算术。

所以，诚实的成本对比不是“6 GB 对 86 GB”，而是“每次推理的边际成本为零，对比每输出两分钟就要占用一个多 GPU 节点”。微调后的 2.6B 模型回答一次查询，成本低到无法测量。微调后的 PAN 2 渲染一段二十秒的片段，要占用一个 GPU 节点三分钟，而在你弄清微调是否奏效之前，你会把它运行数百次。

在路由器与其中任一者接触的位置

这两个模型都不是路由层能够服务的对象。LFM2.5-2.6B-Base 是一个基础检查点，没有值得路由过去的托管端点——它只是一个你下载的文件。PAN 2 根本没有任何托管端点，无论来自 MBZUAI 还是其他任何机构。如果你的方案涉及其中任何一个，那么你的方案就涉及 GPU。

之所以还是要提一下路由，是因为几乎没有人会孤立地部署基础模型。微调后的 LFM2.5 只是应用中的一个组件，而这个应用还需要一个通用推理器；PAN 2 模拟也只是流水线中的一个阶段，其第一阶段是语言模型编写结构化描述。200 多个模型提供单一 API 的价值所在：你可以把调优后的检查点留在自己的硬件上，将常规调用通过 OrcaRouter 按提供商标价路由，并享受0% 加价直通，还能在某个提供商出现故障时获得自动故障转移。具体到 PAN 2 流水线，描述生成阶段是弹性部分——报告按完整计划完成率对 Claude Opus 5.5、GPT-6 Astra、Kimi K3 和 Qwen3.8-Flash 进行排名，而 Qwen3.8-Flash 已在 OrcaRouter 上，因此你可以测试哪个规划器真正能完成你的计划，而无需配置四个模型。

OrcaRouter 不会做的，是托管其中任何一个 checkpoint。若说它会，那种说法听起来像功能，实际表现却像 bug。

基座模型框架掩盖了什么

严格来说，这两个发布版本都尚未完成。LFM2.5-2.6B-Base 按设计就没有进行指令微调；PAN 2 的局限性部分指出，大约三分之二的模拟计划包含至少一个未执行的步骤。两者都不是产品。区别在于“未完成”在每种情况下意味着什么。

对于 LFM2.5-2.6B-Base 而言，“未完成”只是厂商已在流水线下游走完的流程中的一个阶段——后训练模型已经存在，量化构建版本已经存在，而基础检查点则是为那些希望另辟蹊径的人发布的。这个缺口是有意为之，并且有文档说明。

对于 PAN 2 而言，未完成就是整个发布版本的状态。权重已经上线，框架支持于 11 月 10 日落地，而公众对此唯一能看到的表态，就是同一天下午实验室自己的 X 账号上的一篇两段式帖子。它的局限并不是作为设计选择交给下游用户的；它们是团队正在公开指出的未解决问题。如果你微调 PAN 2，你就会连同权重一起继承这些问题。

这才是真正的比较，而它不会归结为在这两个模型之间给出推荐，因为它们并非彼此的替代品。它归结为你项目中的一个问题：你是在改造一个已知可靠的组件，还是在一个失败模式仍在被测量的研究产物之上进行构建？LFM2.5-2.6B-Base 属于前者。PAN 2 属于后者，而 Apache-2.0 许可证是后者甚至能成为一个选项的唯一原因。