MiniCPM-V 4.7 vs NVIDIA Nemotron 3.5 Super VL：实际能运行这两款模型各自的最便宜设备

这两者都是开放权重视觉语言模型，都是混合专家架构，并且都会在语言模型看到视觉 token 之前对其进行压缩。因此，在 MiniCPM-V 4.7 35B-A3B 与 NVIDIA Nemotron 3.5 Super VL 之间做选择，并不是一个关于架构的决定。这是一个关于你愿意购买的最小机器，以及那台机器能以每小时多少页为你换来什么。按这种方式衡量成本，这两个模型完全落在不同的采购讨论中：一个只需 21 GB 下载，运行在你可能已经拥有的硬件上；另一个则要求四块 H100（BF16）或单块 H200（FP4）。本文替你完成规格表留给你的算术——逐个内存层级，逐页计算。 视觉栈留在你的硬件上。围绕它的编排则不必如此。 查看托管模型目录 200 多个托管模型共用一个密钥，目录价按 0% 加价传递。 诸如本次发布背后的有记录 AI 故障和智能体事件，均收录于 OrcaRouter AI Incident Archive 其中每条记录都带有自己的来源、严重程度、置信等级和争议标记。

两个量化阶梯，两个截然不同的下限

OpenBMB 和 NVIDIA 以相反的方向解决了同一个问题——模型太大，无法在你想要运行它的设备上运行。MiniCPM-V 4.7 35B-A3B 让一小部分活跃专家常驻内存，并从存储中流式加载其余专家，然后以所有 GGUF 尺寸发布整个模型，让你自行选择最低门槛。Nemotron 3.5 Super VL 则让完整模型常驻内存，转而训练出一个 4 位层级（NVFP4），在不带来事后量化损失的情况下将内存需求削减约四分之三。

• MiniCPM-V 4.7 35B-A3B，Q4_K_M — 磁盘占用 21.2 GB。能以很小余量装入 24 GB 消费级 GPU，或在 32 GB Mac 上留有充裕空间。

• MiniCPM-V 4.7 35B-A3B，Q8_0 / F16 —— 36.9 GB / 69.4 GB。需要 48 GB 显存的显卡或 96 GB 的工作站，具体取决于你希望在权重之外保留多少上下文。

• Nemotron 3.5 Super VL，BF16 —— 约 231.8 GiB 权重，分布在 64 个分片中。NVIDIA 自家的部署方案是：在 4 块 H100 上采用张量并行 4，或在 2 块 GB200 上采用 TP2。

• Nemotron 3.5 Super VL、NVFP4 — 根据其模型卡，可部署于 1 台 DGX Spark、1 台 H200、2 台 H100 或 1 台 GB200。

最后一行才是改变采购讨论的那个数字。在一个 H200 上而不是四个 H100 上运行 120B 模型，并不是边际节省；这是集群预留与单个节点之间的差别。而且，由于 NVIDIA 是在训练期间通过量化感知蒸馏完成 4 位转换，而不是事后进行，因此它声称没有推理开销——这一说法在宣传卡上有所陈述，但并未用已发布的 BF16 与 NVFP4 准确率差值来证实。

每小时页数，这才是决定一切的数字

以每秒 token 数衡量的吞吐量，是衡量文档处理工作的一项糟糕替代指标，因为一页的成本主要取决于编码器在语言模型说出一个词之前会输出多少视觉 token。两种设计的差异在这里最为悬殊，营销话术在这里也最没有用。

MiniCPM-V 4.7 35B-A3B 在视觉塔内部进行压缩，采用一种 OpenBMB 归功于 LLaVA-UHD v4 的早期压缩技术，混合了 4x 和 16x 下采样。默认是 16x；4x 是精细细节路径，按图像选择。密集的文字页面走低成本路径，零件图则走成本更高的路径。压缩发生在语言模型介入之前，而这正是让 35B 模型能在手机上可行的原因。

Nemotron 3.5 Super VL 并不以压缩为首要卖点。它的答案是上下文：最多一百万个 token，视频输入最长两分钟，并用混合 Mamba-2 层避免超长序列陷入二次方复杂度。其视频处理方案默认以 2 FPS 采样 256 帧，在 1080p 下降至 1 FPS 和 128 帧——这是一种采样策略，而非压缩技巧，而且如果工作负载是密集运动，你可以将其调高。

实际后果是：MiniCPM-V 4.7 提供固定且较低的每页 token 成本，但要求你接受细节损失；Nemotron 3.5 Super VL 让你保留细节，但要求你为上下文付费。对于一百页的合同审查，前者每页更便宜，而在条款藏在 6 磅脚注里的那一页，后者表现更好。对于一段两分钟的手术视频，只有后者还能被纳入考虑范围。

这些版本中，一个提供的是数字，另一个提供的是图表

这是比较中无论多少硬件算术都无法修正的部分，因此它应当放在这里，而不是被埋没在脚注里。

NVIDIA的模型卡附有一张约四十行的基准测试表，而且异常坦诚：它列出了基线，其中多行显示该模型落败。针对Qwen3.5-122B-A10B，其自身数据将MMLU-ProX列为76.91对83.2，tau2-bench telecom为73.19对87.2，OCRBench v2中文为59.15对67.3，MathVision为78.16对83.3。它以89.52比86.7赢得GPQA-Diamond，以51.78比44.9赢得SWE-bench Pro，并以10.86比1.1赢得CritPt。每个数字，包括基线，均通过NVIDIA自己的NeMo Gym测试框架收集——模型卡直接说明了这一点，并发布了可复现性说明。由厂商运行，标注诚实，且保留了失利项。

MiniCPM-V 4.7 的模型卡上有五张评估图表，却没有数值表。其中的对比性说法都是方向性的：在 Instruct 模式下，相比 Qwen3.6 35B-A3B，总体得分更高、推理时间更短；而 1B 变体相较 Qwen3.5 0.8B 有显著提升。没有任何可引用的单项基准分数，没有可查看的基线列表，也没有公布所绘制综合指标的权重。这并不等同于模型不好——工程细节记录在 config.json 中，权重可以逐字节核验——但这确实意味着这项比较中关于准确性的那一半无法建立。任何把 MiniCPM-V 4.7 的分数表与 Nemotron 3.5 Super VL 的数字对照呈现的人，都是在把一家厂商的图表当作测量结果来读，把另一家的表格当作中立数据来读。

运行时路径，以及哪一种会在日后给你带来麻烦

MiniCPM-V 4.7 的部署方案就像一份菜单：SGLang、vLLM、llama.cpp 和 Ollama，面向 Intel CPU、GPU 和 NPU 的 OpenVINO 路径，通过 SWIFT 和 LLaMA-Factory 进行微调，支持 GGUF、BNB、AWQ、GPTQ 和 FP8 量化，并声称在 Rockchip、Houmo、Intel、AMD 和 Arm 芯片以及 iOS、Android 和 HarmonyOS 上提供首日支持。广度本身就是产品。广度的代价是，没有人验证过你的特定组合，而且当前上游 llama.cpp 路径存在一个实际缺陷：图像标记位置计算错误，因此当你询问某个东西在哪里时，返回的坐标会系统性偏低。截至 10 月 20 日，一个经过测试的修复已公开但尚未合并。

Nemotron 3.5 Super VL 的故事主线是“窄而深”：vLLM 使用固定的镜像标签，SGLang 使用固定的标签，并且架构中内置了多 Token 预测（Multi-Token Prediction），因此不需要单独的草稿模型。说明卡之所以指定版本，是因为这些版本就是经过验证的组合。一旦偏离这些版本，原本能正常运行的部署就会变成一场调试噩梦。

如果你是在为适配模型而选择硬件，请选 MiniCPM-V 4.7。如果你是在为适配已有硬件而选择模型，请选 Nemotron 3.5 Super VL，并严格遵循其模型卡中的版本。

路由器在双盒架构中应处于什么位置

在生产环境中出现的模式并非在这两者之间做选择。而是由设备端或本地机器上的小模型承担必须即时且私密的工作，由大模型处理必须准确无误的工作。MiniCPM-V 4.7 35B-A3B 是为第一种角色打造的；Nemotron 3.5 Super VL 则是为第二种角色而生，它具备一百万 token 的上下文窗口和 12B 激活参数，足以承载长文档与智能体循环。

同时运行两者意味着两套模型栈、两组故障模式，而且——一旦你为围绕它们的编排再加一个文本模型——就变成三组。这正是 OrcaRouter 能帮上忙的地方，同时也不必夸大它的作用：这两个检查点都不在我们的目录中，因为它们都是你自行托管的开放权重，但围绕它们的文本模型和代码模型则在目录里。一个密钥通用于 200 多个托管模型，按提供商标价原样传递、0% 加价，并在上游服务劣化时自动故障转移。视觉栈仍留在你自己的硬件上；流水线的其余部分不再需要每次新增一个环节就签一份新合同。

每件事判断错了会让你付出什么代价

买下那个小盒子，却发现你需要的是长文档推理，那你就花掉了几千美元和一周时间。买四块 H100，却发现工作负载只是处理收据，那你为从未用到的能力付出了高得多的代价。这种不对称正是从低价档起步、再逐步升级的真正理由——也正是为什么端侧发布尽管基准测试方面的说法更单薄，却值得它正在获得的关注。

如果两台机器都可用，决胜因素就是像素所在的位置。无法离开这栋楼的帧，交给在楼内运行的模型。需要百万级 token 上下文和推理循环的帧，交给为此打造的那个模型，而你要把固定运行时版本当作入场代价来接受。