探究的三条路线

它们并不是在回答同一道 benchmark 题。DeepSeek 关注推理时“我指的是谁”，MiniMax 暴露了产品体验中的 首 token 延迟（Time to First Token，TTFT），MiniCPM-o 则进一步改变了系统的工作单位：不再等待完整输入和完整输出，而是持续处理每个时间片里新到达的信息。

DeepSeek：视觉原语让模型边想边指

我最初把视觉原语理解成一种更彻底的视觉—语言融合：模型不再需要某个模块先“翻译”图片，因此也许能降低首字延迟，甚至意味着语言模型本身具备了理解图形的能力。

同时我又隐约记得 Google 很早以前就做过相近方案。如果坐标 token、视觉 grounding 都不是第一次出现，那么 DeepSeek 具体做了什么？它对前端截图理解又是否会更有帮助？

这几个问题里混着一些自然但并不准确的猜测。

MiniMax：它真的是级联的“假多模态”吗？

我曾经开了一个月 MiniMax Coding Plan，却只用半小时就弃用了。原因很直接：在我的使用场景中，带图请求多次出现高达十秒的首字延迟，而且开始输出前几乎没有可见反馈。与 DeepSeek 网页端带图时不到 1 秒开始回复的体验相比，慢得让我根本无法忍受。

我当时用的模型是 MiniMax-M3。

当时无论怎么询问图片内容，M3 都经常在思考过程中先写出一段完整的图片描述，再阅读问题并回答。我猜测，这一大段描述就是拖慢首字 token 的元凶。这让我和同学产生了另一个猜测：它是不是先让独立视觉模型把图片翻译成长 description，再把 description 拼给文本模型？

MiniCPM-o：实时视频不是逐帧写 description

MiniCPM-o 的实时音视频即时对话演示是真的馋哭了。

它似乎可以让 LLM 和 TTS 全双工工作：文字和语音都在流式回复，首字延迟也很低。可我自己在本地同时运行独立 LLM 和 TTS 时，两边经常争抢资源，最后停滞甚至异常退出。MiniCPM-o 是怎样均衡资源的？

另一个问题是视频理解。普通 VLM 为单帧生成完整 description，端到端可能需要数秒；MiniCPM-o 又怎么可能持续处理视频？它真的每秒理解那么多帧吗？视频在模型内部是怎么被增量处理的？

我本地有一块 4060ti-16G，也许你可以用它举例。

Opus

按消费速度来决定生产速度：它不是每秒让 VLM 重新描述整张画面

普通的视频问答通常先抽帧，将若干帧一次性塞给 VLM，等模型看完再回答。MiniCPM-o 的实时模式则将时间切成约 1 秒一个 chunk。第 $k$ 秒新增的画面、声音和模型输出分别编码为：

$$g_k=[v_k;a_k;o_k]$$

然后将 $g_1,g_2,\ldots$ 依次追加到同一个因果语言模型会话中。官方将这种组织方式称为 时分复用（Time-Division Multiplexing，TDM）：逻辑上存在视频、环境音和回答三条并行流，实际计算时则被序列化成一组组带时间边界的 token。

每个 chunk 先写入刚到达的视觉和音频 token，再决定这一秒是继续听，还是生成回答。因此，输出能注意到最新画面，而不是等整段视频结束。

实时模式也不会按摄像头原始的 30 FPS 全部推理。4.5 的训练在 1～5 FPS 之间采样，默认示例每秒取一组画面；stack_frames=5 才是高刷新模式。单帧最高按 448×448 处理：SigLIP2 先产生 1024 个 patch token，再由 resampler 压成 64 个视觉 token。

所以，默认每秒送入语言模型的不是几十张完整图片，而是少量、强压缩的视觉特征。多帧的时序理解主要来自这些帧按时间顺序进入同一上下文和 KV cache，并非额外运行一个 3D 视频模型。

这也是它与传统 VLM 延迟形态最大的区别：普通 VLM 常常先为一张高分辨率图完成一次较大的视觉 prefill，再连续生成几十到几百个 description token；MiniCPM-o 将输入成本摊到每个时间片，而且不要求每一帧先写一篇完整描述。

全双工不是两套大模型同时抢 GPU

MiniCPM-o 4.5 仍然是模块化系统：

1
画面 → SigLIP2 视觉编码器 ─┐
2
声音 → Whisper-medium ─────┼→ Qwen3-8B → 文字
3
                            │       └→ 0.3B 语音 token 解码器
4
参考音色 ──────────────────┘                └→ 流式 flow-matching 声码器 → 波形

但它与“单独启动一个 LLM 服务，再启动一个完整 TTS 服务”不同。所有可训练模块连接为一个约 9B 的模型，共用一次会话和同一条时间轴。

Whisper 每秒原本产生 50 个音频特征 token，projector 将其压成 10 个/秒；Qwen3-8B 只需以接近人类说话速度生成约 3～4 个文字 token/秒。高频的语音建模——约 25 个 speech token/秒——交给约 0.3B 的 speech-token decoder，再由流式声码器逐块合成波形。

因此，这里的全双工主要是细粒度交错调度，而不是已经证明在 CUDA 上同时并行执行视觉编码、8B LLM 和 TTS 三套 kernel。每个 1 秒窗口里依次吸收新画面和声音、预测 [listen] 或 [speak]、生成少量文字，再让轻量语音解码器追上播放进度。

时间对齐交错生成（Time-Aligned Interleaving，TAIL）还会根据已积累的语音延迟，动态减少或增加当前 chunk 的文字量，避免文字跑得太远，嘴里仍在说几秒前看到的东西。

这就解释了为什么自己拼接独立 LLM 与 TTS 容易卡死：两个完整服务各自长期占据权重、KV cache、CUDA allocator 和临时 workspace，还可能从不同线程同时提交大型 kernel；显存接近上限时，碎片化或一次峰值分配就足以 OOM。

MiniCPM-o 则将主要显存留给唯一的 8B 主干，只附加较小的编码器和语音解码器，再由同一个推理框架按时间片安排工作，避免两个重量级生成循环无节制竞争。

不过，它也没有魔法般省显存。4.5 官方报告约占 19GB（bf16）或 11GB（int4）；原生 PyTorch 全双工 demo 为中间激活和运行余量推荐至少 28GB NVIDIA 显存。真正面向边缘设备的是专门优化的 llama.cpp-omni：官方要求 NVIDIA 至少 12GB，并在 RTX 4090、5080、5070 上测得全双工实时因子分别为 0.21、0.32、0.40，均低于 1，意味着生成速度快于实际播放速度。

所以，16GB RTX 4060 Ti 的容量高于官方列出的约 11GB int4 模型占用，但能否流畅运行全双工仍取决于推理后端、运行时余量和实际吞吐；8GB 版本无法将约 11GB 的模型完整放入显存，必须进一步卸载或换用更旧、更小的 2.6 int4，性能自然会下降。

MiniCPM-o 真正改变了什么？

它的优势不是某个模块突然比普通 VLM 快几十倍，而是重新设计了工作单位与调度方式：

• 将视频变成低帧率、强压缩的增量视觉 token；
• 将音频压到每秒 10 个 token；
• 让 8B 主干只低频生成文字；
• 将高频语音生成下放给轻量解码器；
• 最后通过 1 秒时间片与共享 KV cache 将所有流组织起来。

它用“持续追加少量状态”代替“反复理解整张图片并生成完整描述”，所以才能在本地设备上表现得像边看边说。

但长期记忆如何淘汰，技术报告没有公布明确的滑动窗口或 KV eviction 策略，上下文上限仍然存在。4.5 报告也承认，在漫长、持续变化的现实流中，稳健性仍需改进。它更像一个训练和推理共同设计的实时系统，而非已经解决无限视频记忆的通用方案。

参考资料：MiniCPM-o 4.5 技术报告、MiniCPM-o 官方仓库、MiniCPM-o 2.6 模型卡。

魔法没有消失，只是被拆成了工程约束

MiniCPM-o 本质上是一个高阶的、按模块与时间片分配资源的流式系统。它也受到类似 RVC 与流式 TTS 的限制：如果本地机器生成一段音视频所花的时间超过这段内容本身的播放时间，也就是实时因子大于 1，系统就会不断落后，最终无法维持实时交互。

所以魔法其实没有那么多。

但“让每一秒观察到的内容与这一秒应该说什么发生关联”，仍然很有意思。它要求模型不只回答问题，还要知道什么时候继续听、什么时候开口，以及嘴里正在说的内容是否已经落后于环境。

普通的无状态图片问答 API 确实不适合每秒上传四五张完整图片：反复上传、视觉编码与 prefill 很快就会将延迟堆起来。不过，这不是说“只要调用 API 就不可能实时看图”。如果服务提供持久会话、增量 KV cache，以及 WebSocket 或 WebRTC 这样的长连接，MiniCPM-o 同样可以部署在远端，以流式 API 提供实时交互。

本地部署也不必然意味着上下文和 tool call 能力差。更准确地说，当前能在消费级设备上实时运行的小型 omni 模型，往往需要在模型规模、上下文、工具调用、画面精度与语音实时性之间作出取舍。云端大模型与本地实时系统只是在优化不同目标。

算力和钞能力当然可以买来更强的模型与 API，解决上下文、工具调用和部分延迟问题。但如果模型只是一个只会被动回复的 API，那么即便它能看懂视频，对我来说也依然很无趣。我真正关注的，仍然是怎样让它持续感知、主动行动，最后拥有一点像灵魂的东西。