一张生成的主视觉标题卡,写着“MiniCPM-V 4.7 35B-A3B vs PixelUMM”,副标题为“一份许可证在基准测试之前就决定了这一切”,还有三个数据标签,分别写着“MiniCPM-V:Apache-2.0”、“PixelUMM 检查点:仅限非商业用途”和“基准测试:两者均未公布”,页脚为“PixelUMM 许可证仅限研究和评估用途”。OrcaRouter 徽标位于右下角。
Guides & Insights

MiniCPM-V 4.7 35B-A3B 对比 PixelUMM:在基准测试给出结论之前,一份许可证就已决定了这一点

作者

Alistair Wren

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

在 MiniCPM-V 4.7 35B-A3B 和 PixelUMM 之间,有一个决定你无需阅读任何基准测试就能做出,而且它很可能正是最重要的那个决定。MiniCPM-V 4.7 35B-A3B 采用 Apache-2.0。PixelUMM 的模型检查点则不是——它依据 NVIDIA 的 One-Way Noncommercial License 发布,该许可证仅允许研究和评估用途,而且 NVIDIA 自己表示,这个检查点“尚未针对生产或高风险用途进行验证”。如果你正在构建某样打算出售的东西,那么这两款模型中有一款根本不能选,剩下的比较也就只是纸上谈兵。如果你在做研究,选择空间就打开了,而有趣的问题会变成:NVIDIA 的无编码器设计实际上是在赌什么行不通——因为它所赌的,恰恰就是 MiniCPM-V 4.7 所采用的那种架构行不通。

两款模型都悄然发布。PixelUMM 的权重于 2026 年 10 月 1 日 21:40 UTC 上线 Hugging Face,没有博客文章、没有新闻稿,也没有主题演讲;项目页面 URL 仍然显示为“preview”。MiniCPM-V 4.7 于 10 月 6 日以同样方式出现,而 OpenBMB 直到 10 月 12 日才为其添加模型卡、许可证或声明部分。两者都没有经过任何人的独立评估,也都没有可供读者引用的基准测试表——PixelUMM 的模型卡完全没有报告任何分数,而 MiniCPM-V 4.7 的性能声明存在于图表图像中,而非文本中。以下内容将仓库所陈述的内容与两个实验室之外尚无人证实的内容区分开来。

用一段话说明 PixelUMM 是什么

PixelUMM 是一个拥有 15,199,672,064 个参数的仅解码器 Transformer,带有迭代式像素生成头,构建在固定到特定修订版本的 Qwen3-8B 主干之上。它的核心论点写在模型卡片的第一行,而且确实反主流:没有 VAE,也没有视觉编码器。常规统一模型带有两个视觉接口——一个用于理解、产生语义特征的视觉 Transformer,以及一个用于生成、产生重建潜变量的变分自编码器——而 PixelUMM 两者皆无。图像被切成 16×16 像素块,视频被切成四帧时空 tubelet,二者都仅通过单层线性投影抵达主干,生成工作则由迭代去噪完成。论文将其描述为一种 Mixture-of-Transformers,把共享注意力与任务特定参数配对。它可处理文生图、以图像为条件的文本生成、以视频为条件的理解与视频生成,包括 96 帧、24 fps、四秒的文本生成视频。

它周围的线索前后持续了大约四周,全程悄无声息。GitHub 仓库 nv-tlabs/PixelUMM于 2026 年 9 月 4 日在 Apache-2.0 下创建,并在当月大部分时间里都只有一个提交。9 月 28–29 日,初始提交落地,arXiv 分配了预印本 2609.38597,其作者名单横跨 NVIDIA 和滑铁卢大学。模型仓库本身于 10 月 1 日 21:40 UTC 出现,距 GitHub 上添加论文引用的最终提交仅八分钟。论文没有标注发表场所——没有会议,也没有“accepted to”字样——这读起来像是研究团队在将一件研究产物直接推送上线,而不是产品发布,不过这是对证据的观察,并非对意图的断言。

A headless-browser capture of the Hugging Face model page for nvidia/PixelUMM (captured 13 October 2026) showing the nvidia-one-way-noncommercial-license tag, 83 likes, a downloads panel noting downloads are not tracked for this model, the card heading 'PixelUMM: Encoder-Free Unified Image and Video Understanding and Generation', an architecture diagram with raw image and raw video paths through linear layers, the quoted line 'PixelUMM is released for non-commercial research or evaluation purposes only.', the supported-task list (text-to-image generation, image-conditioned text generation, video-conditioned understanding, video generation), and a model tree showing Qwen/Qwen3-8B as the base model.

MiniCPM-V 4.7 35B-A3B 是什么

MiniCPM-V 4.7 35B-A3B 是 OpenBMB 在 MiniCPM-V 系列中的首个 MoE 成员:256 个专家,每个 token 激活 8 个,40 层,262,144 token 的上下文窗口以及 248,144 token 的词表,在 35.2B 总参数中约有 3B 激活参数。视觉部分通过 SigLIP2 模块运行,采用 LLaVA-UHD v4 的 ViT 内早期压缩,并提供可选的 4x/16x 混合视觉 token 压缩模式——默认使用 16x 以提升吞吐量,在细节重要时使用 4x。它能够理解单张图像、多张图像和视频,并以文本作答。它不生成图像。

该卡片的主打宣传是:这是首个开源 MoE 模型,具备无损、流畅的端侧推理能力,依托 Lookahead Expert Scheduling、细粒度逐层量化,以及通过独立 DSpark 草稿进行的推测采样,据称在 iPhone 17 Pro Max 上达到每秒 13+ tokens。该数字由厂商报告,未经复现,也未加限定。该卡片还声称,其 Instruct 模式总体得分高于 Qwen3.6 35B-A3B,且推理时间更短——这一说法出现在图表图片中,意味着它不是可直接引用的数字,也不应被当作可引用数字对待。

MiniCPM-V 4.7 明确领先的地方不在任何记分牌上,而在它的配角阵容里,而这一切都是真实且可下载的:base、FP8、int4、AWQ、GPTQ 和 GGUF 权重;对 SGLang、vLLM、llama.cpp、Ollama 和 OpenVINO 的支持;iOS、Android 和 HarmonyOS 应用;以及首日就列出支持的 Rockchip、Houmo、Intel、AMD 和 Arm 芯片。六周前,对这个模型最诚实的批评是:它只是一个没有文档的检查点。如今已不再如此——它是一个有文档、却没有基准测试的检查点。问题不同了,也更小了。

A headless-browser capture of the Hugging Face model page for openbmb/MiniCPM-V-4.7-35B-A3B (captured 13 October 2026) showing the Apache-2.0 licence tag, 37 likes, 166 downloads last month, a safetensors panel reading '35B params' and 'BF16', and a model card whose claims read 'The First Open-Source MoE Model with Lossless, Smooth On-Device Inference', '13+ tokens/s on iPhone 17 Pro Max', 'achieves a higher overall score in less inference time than Qwen3.6 35B-A3B', mixed 4x/16x visual token compression, and support for iOS, Android and HarmonyOS alongside SGLang, vLLM, llama.cpp and Ollama.

隐藏在比较背后的架构论点

这两个模型在一个根本性问题上存在分歧,而这一点值得点明,因为它是这场较量中比两个模型本身都更长久的部分。

• 视觉如何抵达语言模型——PixelUMM 使用原始像素和单一线性投影,整个技术栈中没有任何预训练视觉编码器;MiniCPM-V 4.7 使用 SigLIP2 编码器,并在 ViT 内部进行早期压缩,且下采样比例可配置。

• 生成机制 — PixelUMM 通过一个与自回归文本预测联合训练的流匹配头迭代地预测像素;MiniCPM-V 4.7 只生成文本,不生成其他内容。

• 这换来了什么——PixelUMM 得到一组权重,既能描述图像,又能生成图像,代价是仅限研究用途的许可证且没有生产验证;MiniCPM-V 4.7 得到一个小型、可量化、可部署在手机上的模型,它能读懂世界,却不能重绘世界。

• 参数量——15.2B 偏稠密,对比总计 35.2B、其中 3B 为激活参数。激活参数量才是预测推理成本的那个指标,而在这个维度上,MiniCPM 模型是两者中较小的那个,小了一个数量级。

• 磁盘上的权重 — PixelUMM 的仓库包含 491 个文件,涵盖四种检查点变体;MiniCPM-V 4.7 的基础构建是十六个 BF16 分片,约 70 GB。

• 许可 — 对于检查点,Apache-2.0 与 NVIDIA One-Way Noncommercial 相对;Apache-2.0 仅适用于 PixelUMM 的源代码,而 Qwen3-8B 基础模型另行采用 Apache-2.0。PixelUMM 的模型卡还指出,其包含源自 BAGEL 的修改代码,因此上游条款也叠加适用。

• 公开评估——双方均无。MiniCPM-V 4.7 至少宣称了性能表现;PixelUMM 的模型卡则完全没有给出任何基准测试数据。

A generated two-column scoreboard titled 'MiniCPM-V 4.7 35B-A3B vs PixelUMM - the scoreboard'. The left column lists Vision encoder: SigLIP2 plus compression; Parameters: 35.2B total, 3B active; Output: text only; Context: 262,144 tokens; Licence: Apache-2.0; Evaluation: none published. The right column lists Vision encoder: none, raw 16x16 pixels; Parameters: 15.2B on a Qwen3-8B backbone; Output: text, images and video; Context: not stated; Licence: NVIDIA noncommercial only; Evaluation: none published. The footer reads 'Vendor-reported cards; neither model independently reproduced.'

哪一个是你实际上能放到用户面前的

把许可证和部署方案结合起来考虑,选择基本上就不言自明了。

PixelUMM 是更有意思的研究产物,却是更不好用的产品。非商业许可的检查点直接堵死了显而易见的商业用途,模型卡上没有部署方案,没有量化版本,没有上下文长度数据,83 个点赞对零下载记录——基本说明作者之外没人跑过它。它当下的价值在于:它是一份已发表的、有力的论据,说明视觉编码器或许并非必要。无论你是否真的会加载这份权重,这个论据都值得一听。

MiniCPM-V 4.7 是那个具备通往生产环境路径的模型,这条路径狭窄但真实。Apache-2.0 消除了许可问题。六种量化格式和五种推理运行时意味着你无需编写自定义内核。未量化构建需要两块或更多 GPU 是障碍;量化构建和端侧方案是变通办法,而端侧的说法恰恰是尚未经过独立验证的那一个。把它当作一个你今天就能运行的模型,以及一个你尚不能指望的性能声明。

对于答案是“都不是,我们会调用别的模型”的团队来说,与 MiniCPM 这种形态最接近的托管方案是 Qwen3.6 35B A3B——同样是 35B 总参数量、同样 3B 激活参数、同样 262K 上下文、同样的文本-图像-视频输入能力——而且它通过 OrcaRouter 以供应商的标价提供,零加价,每百万输入 token 0.25 美元、每百万输出 token 1.48 美元,并且当某条供应商路由质量下降时可自动故障转移。它不是本文中任何一个模型的替代品;它是那个对照组,告诉你自托管一个 70 GB 的稀疏多模态 MoE 究竟买到了什么。

这将如何收场

抛开架构不谈,剩下的就是两个悄无声息的发布,却指向相反的方向。NVIDIA 发布了一件论文级的产物,其许可证让大多数人无法使用,还附带一个没有训练配方、没有基准测试、也没有下载的代码库。OpenBMB 发布了一个有文档、采用宽松许可证、支持多种运行时的模型,附带一项引人注目的效率声明,却没有任何评估表来支撑。

能分别为两者一锤定音的就只有一件事:对 PixelUMM 来说,是任何独立复现——0 次下载意味着外界根本不存在数据点,而“无编码器”这一论点恰恰是那种一旦接触第二个实现,要么站得住脚、要么彻底崩掉的主张。对 MiniCPM-V 4.7 来说,则是一张基准测试表,或是在 DSpark 草稿上复现出的接受长度,而后者是该系列中唯一带有已公布数值的部分。两者目前都不存在。正因如此,这两个模型仍值得关注,而不是被归档——它们进入公众视野的时间比相关报道所暗示的更短,而且打造它们的实验室都还没有将其称为一次发布。