MiniCPM-V 4.7：OpenBMB 上传了一个 35B-A3B 视觉语言模型，既无模型卡、无许可证，也无基准测试

MiniCPM-V 4.7 于 2026 年 10 月 6 日晚在 Hugging Face 上亮相，仓库为 openbmb/MiniCPM-V-4.7-35B-A3B——而这是 MiniCPM 系列有史以来发布过的最奇怪的东西之一，因为随它一同发布的内容几乎没有。没有模型卡。没有 README。没有声明任何许可证。没有基准测试表，没有发布帖，没有技术报告，OpenBMB 自己的 GitHub 文档中也没有条目；截至本周，该文档仍称 MiniCPM-V 4.6 是“MiniCPM-V 系列中最新的、最高效的模型”。确实存在的是 16 个 bfloat16 权重分片，总计 70.4 GB，它们描述了一个 352 亿参数的混合专家视觉语言模型，具有 256K 上下文窗口和异常激进的混合注意力设计。这足以说明这个模型是什么。但还不足以说明它擅长什么，而本文会严格区分这两者。

实际落地的究竟是什么，一个字节都不差

该仓库创建于 2026 年 10 月 6 日 UTC 18:36，最后一次提交是在十二分钟后的 UTC 18:48。在此期间，上传者推送了 Transformers 加载器所需的权重文件和配置，然后就停止了。完整文件列表共有十八个条目：

• 权重 — 十六个 safetensors 分片，命名为 model-00001-of-00016 到 model-00016-of-00016，索引文件为 model.safetensors.index.json，报告的张量总大小为 70,425,751,648 字节。

• 参数量 — Hugging Face API 读取到 35,212,875,824 个参数，全部为 BF16。注意，这是总数，对于稀疏 MoE 来说，这并不是任何给定 token 上激活的参数数量。

• 配置 — config.json（2,984 字节）、generation_config.json（186 字节）、preprocessor_config.json、processor_config.json。

• 分词器 —— tokenizer.json（20 MB）、tokenizer_config.json和 chat_template.jinja（7,250 字节）。

• 缺失 — README.md。直接抓取原始文件会返回 HTTP 404。在 Hugging Face 上，README 缺失意味着没有模型卡，也就意味着没有许可证字段，也就意味着该仓库根本不带 license: 标签。

该仓库有三个点赞、零次下载，讨论标签页空空如也。一个 70 GB 检查点的社区上传通常会在数小时内引来评论——关于量化的问题、关于部署的问题、关于许可证是什么的问题。这个却没有，这与它只是被少数关注 openbmb组织的人发现，而不是向任何人公布的情况相符。

架构，直接从 config.json 读取

由于没有模型卡可供转述，配置文件就成了主要来源，而它提供的信息异常丰富。类别是MiniCPMV4_7ForConditionalGeneration，模型类型是minicpmv4_7，并且它由 Transformers 5.2.0 保存——所有这些都表明，这是 MiniCPM-V 主线中由 OpenBMB 官方发布的检查点，而不是一个冒用此名的社区微调版本。

• 语言主干 — model_type: qwen3_5_moe_text。一个源自 Qwen3.5 的稀疏 MoE，这是 MiniCPM-V 系列首次使用 Qwen-MoE 文本栈，而不是驱动 MiniCPM-V 4.5 和 4.6 的稠密小型 Qwen 变体。

• 稀疏性——256 个专家，每个 token 选中 8 个，专家中间层大小为 512，并配有一个规模相同的共享专家。一个 35B 总参数量的检查点采用 8-of-256 的路由模式，每次前向传播只激活其中一小部分，这正是 A3B 这个名字的全部意义所在：权重大，计算量不大。

深度与宽度——40个隐藏层，隐藏维度2048，16个注意力头（含2个键/值头），头维度为256。

• 混合注意力——layer_types 数组长度为 40，每三个linear_attention层对应一个full_attention层，间隔固定为 4。这四十层中有十层执行常规注意力；其余三十层使用 Mamba 风格的线性路径，卷积核为 4。这是该文件中影响最为深远的一项设计选择，也正是整个领域在 2026 年间所走的同一方向。

• 位置编码——使用 theta 为 10,000,000 的 RoPE，以及 partial_rotary_factor: 0.25，这意味着每个头的维度中只有四分之一会被旋转。多模态 RoPE 已启用，使用 mrope_interleaved: true、[11, 11, 10] 的分段划分，以及 mrope_mode: canvas。

• 上下文 — max_position_embeddings: 262144，且分词器的 model_max_length与此一致。即 256K 个 token。

• 多 token 预测 —— mtp_num_hidden_layers: 1，单个投机解码头，与 MiniCPM-V 4.6 采用的同一技巧。

• 视觉塔——minicpmv4_7_vision，隐藏维度 1152，27 层，采用 GELU-tanh 激活，patch 尺寸为 14，image_size 为 980，insert_layer_id 为 6，视觉嵌入正是在此处被拼接进语言栈。该塔的结构与 MiniCPM-V 4.6 中的结构相近，因此视觉部分属于演进，而非重建。

• 视觉压缩 — downsample_mode: "16x" 和 max_slice_nums: 9 位于图像处理器中。MiniCPM-V 4.6 引入了可切换的 4x/16x token 压缩方案；4.7 配置宣称将 16x 设置作为默认值，切片器允许高分辨率输入最多使用九个子图像。

• 词表 — 248,144 个 token，其中<|image_pad|>位于 id 248,056，<|video_pad|>位于 248,057。视频是一等输入，与自 MiniCPM-V 4.5 以来一直如此。

一个奇怪的遗留——分词器配置仍然声明了<|audio_start|>、<|audio_end|>和<|audio_pad|>。这几乎可以肯定意味着词表是与 omni MiniCPM-o 分支共享的，而不是 MiniCPM-V 4.7 能处理音频。将其解读为音频功能会是一个仅凭配置无法排除的错误。

家族告诉我们、而这个存储库没有告诉我们的内容

4.6 代是参照基准，而对比正是关键所在。MiniCPM-V 4.6 于 2026 年 5 月 11 日发布，是一个 13 亿参数的模型，基于 SigLIP2-400M 视觉编码器和 Qwen3.5-0.8B 语言模型构建，采用 Apache-2.0 许可，并给出了明确的卖点：它在 Artificial Analysis Intelligence Index 上得分为 13——这是厂商报告的数据——同时所用 token 数量远少于同类小型模型，而且可在 iOS、Android 和 HarmonyOS 上运行，其端侧适配代码已开源。它的全部定位就是“小巧、高效、端侧”。

MiniCPM-V 4.7 是 1.3B 乘以约 27。35B-A3B 这个名字把它归入了稀疏旗舰模型所在的类别，而非手机。OpenBMB 究竟是想把它当作边缘产品线的服务端搭档、未来小模型的教师模型，还是一次能力上限的测试，任何地方都没有说明，仓库中也没有任何相关的暗示。

真正新鲜、并且值得任何关注这个系列的人留意的，是 Qwen-MoE 骨干网络加上 3:1 的线性注意力与全注意力之比。两者都是对既有做法的偏离。OpenBMB 发布的关于该系列的一切内容仍围绕 4.6 来写，所以这个检查点已经跑在了它自己的文档前面。

目前尚不可知的是什么——以及为什么这份清单很重要

值得直言不讳地指出这里的缺口有多大，因为面对一个 70 GB 的检查点，诱惑就在于用看似合理的推断来填补它。

• 没有许可证。这不是走形式。MiniCPM-V 4.6 采用 Apache-2.0 许可，社区已经对这条产品线抱有这种期待。一个没有 license: 标签的仓库，在大多数司法管辖区默认保留所有权利——在标签出现之前，你无法安全地基于它进行构建。那唯一缺失的文件是该仓库中后果最严重的缺失。

• 没有基准测试，无论是厂商报告的，还是其他来源的。没有任何一个数字可争论。今天任何引用 MiniCPM-V 4.7 的 MMMU 或 OCRBench 分数的人，引用的都是源中不存在的东西。

• 没有独立评估。Artificial Analysis 及类似的追踪平台按名称索引模型；一个既没有模型卡、也没有发布公告的 checkpoint，通常会在相当长一段时间内无人评测。

• 没有现成的部署方案。已发布的权重能否在 vLLM、SGLang 或 llama.cpp 中原生运行，OpenBMB 之外的任何人都没有测试过。这些自定义代码路径（MiniCPMV4_7ForConditionalGeneration、MiniCPMV4_7Processor、MiniCPMV4_7ImageProcessor、MiniCPMV4_7VideoProcessor）全都需要 trust_remote_code，而 MoE 与线性注意力的组合并非每个推理引擎都具备相应 kernel 的形态。

• 没有量化版本。MiniCPM-V 4.6 发布了 GGUF、AWQ、GPTQ 和 BNB 变体，并于 2026 年 6 月进入 Ollama 的模型库。4.7 则一个都没有。对于 35B 模型来说，这就是笔记本与集群之间的差别。

• 未说明与 4.6 有何关系。OpenBMB 可能是在替换这条边缘线、对其进行扩展，或是在测试某种正交的东西。代码仓库没有说明，GitHub README 也没有——截至其 2026 年 9 月 8 日的提交，README 仍将 4.6 列为当前版本。

对这条时间线还存在一种说得通但尚未证实的解读：从仓库创建到最后一次提交之间那十二分钟的空档、一张卡片的缺席，以及任何帖子的缺席，恰恰是一个检查点在为发布预先布置、而非在发布之后才出现时所呈现的样子。这是关于意图的假设，而不是关于这件产物的既成事实，也应当被当作假设来对待。

你实际上会怎样运行它，当确实有东西可运行的时候

这里目前还没有任何东西可以作为受支持的路径来引用，但配置确实限制了可选方案。一个 35B 参数的 BF16 检查点在 KV 缓存之前就需要大约 70 GB 的加速器内存，因此在量化方案落地之前，单 GPU 爱好者部署是不可行的。256K 上下文和 3:1 的线性注意力比例意味着，KV 缓存增长远比同深度的传统 Transformer 慢得多，而这正是该架构值得这份复杂度的原因——长上下文多模态工作正是该设计收回成本的地方。当有卡出现时，首先要检查的是许可证、是否发布了官方 vLLM 或 SGLang 方案，以及 16x 下采样默认值能否换成 4.6 所暴露出的 4x 设置。

对于希望在一款模型变得可用的那一刻就评估它的团队来说，实际问题不在于权重，而在于围绕权重的配套设施。运行在你自己 GPU 上的模型仍然需要它周围的一切——一个路由器，把 200 多个托管模型放在一个密钥之后，按各提供商的标价提供，不叠加我们的加价，并且在某个提供商服务降级时自动故障转移。这正是 OrcaRouter 的用途所在，而且值得直说：MiniCPM-V 4.7 本身并不是托管模型：它是一个开放权重检查点，由你自己提供服务。路由器在这里之所以重要，是因为它是架构的另一半——你的 4.7 机器把困难案例交给的前沿模型，可以通过你已经写好的同一客户端访问。

现状，以及需要刷新的那个文件

MiniCPM-V 4.7 确实存在。其权重今天便可下载，参数规模确切可查，而它训练时期的设计选择——稀疏 MoE、3:1 线性注意力、256K 上下文、16 倍视觉压缩——全都能从配置文件中读出来。不存在的，是 OpenBMB 就该模型能做什么、实际运行成本几何，或者你被允许拿它做什么所给出的任何说明。对于一个上一个视觉模型还是 1.3B Apache-2.0 边缘端发布、并附有完整对比表的实验室而言，这是一道刺眼的落差，而明智的姿态是盯着代码仓库，而不是盯着舆论。唯一值得不断刷新的文件是 README.md：它一出现，就会带上许可证、基准测试结果，大概还会有关于一个 35B 的 MiniCPM-V 为什么会出现在一个以小模型起家的系列里的解释。

在那之前，最诚实的总结就是这条乏味的结论。这是来自真实实验室的一个真实检查点，悄无声息地上传了，而那个真正有意思的问题——它到底好不好——尚无公开答案。

OrcaRouter 只需一个密钥即可接入 200 多个托管模型，各提供商的原价以 0% 加价直接透传，并支持提供商之间的自动故障转移。提供商原价以 0% 加价透传 MiniCPM-V 4.7 并不在其中——它是由你自己部署的开放权重检查点，而路由器则位于交接的另一端。