核心观点
大模型与多模态模型的近期主线，不是单纯把参数、上下文或榜单继续推高，而是把模型做成能在设备、浏览器、机器人、文档系统和语音链路里长期驻留的能力单元。MiniCPM-o 4.5、Gemma 4/LiteRT-LM、OpenAI 实时语音模型、Mistral OCR 4、Gemini Robotics-ER 1.6 和 DeepSeek V4 Preview 指向同一个变化：模型正在从“被调用一次的云服务”变成“持续感知、持续生成、持续接工具的本地或半本地模块”。一个可辩论判断是，未来 1 到 2 个月，端侧与机器人场景更缺的不是更大的通用模型，而是能稳定处理流式音视频、文档结构、空间坐标、工具调用和低内存运行的专用模型。另一个反共识判断是，9B 到 13B active 这类小模型和稀疏模型，可能比新的超大闭源模型更快改变硬件选型，因为它们直接影响手机、AI PC、工业盒子和机器人主控能否独立完成任务。
本期主线
本期模型进展的共同主线，是“驻留化”。过去模型发布最容易被简化成参数规模、榜单排名和 API 价格，现在更有产业含义的指标变成了：能否在 12GB 内存以内实时交互，能否在浏览器和手机侧稳定跑，能否一边听一边说，能否把 PDF、表格、版面和置信度交给 RAG，能否把图像、视频、音频和语言转换成机器人可执行的空间结构，能否用 1M 上下文降低 Agent 的检索和摘要损耗。
这会反过来影响端侧芯片和软件栈。对 NVIDIA Jetson、瑞芯微 RK3588/RK3576、Qualcomm、Intel、联发科、全志、星宸、地平线、黑芝麻和爱芯元智来说，模型侧的压力不只是“跑不跑得动大模型”，而是能否持续喂给模型音频、视频、传感器、文档和工具结果，并在功耗、内存、延迟、热设计和隐私边界内完成闭环。真正会改变采购决策的模型，往往不是发布页上最强的模型，而是能被 SDK、运行时、量化格式和业务流程稳定吸收的模型。
重点进展
MiniCPM-o 4.5 把端侧多模态推向全双工交互
- 事实：OpenBMB 的 MiniCPM-o 4.5 演示仓库显示，该模型基于 SigLip2、Whisper-medium、CosyVoice2 和 Qwen3-8B 以端到端方式构建，总参数量 9B，支持实时连续视频和音频输入，同时并发生成文本和语音输出。论文页面进一步说明，MiniCPM-o 4.5 采用 Omni-Flow 统一流式框架，目标是实时全双工全模态交互，并称其可在低于 12GB RAM 成本的边缘设备上运行。
- 我的判断：这条动态的重要性不是“9B 模型又刷新了多模态分数”，而是它把端侧交互从轮流问答推进到持续感知。机器人、车载、陪伴设备和工业助手真正需要的是模型在说话时仍然能看、听和修正，而不是等用户停顿后再处理一个完整回合。
- 产业影响：全双工多模态会提高端侧平台对音视频同步、缓存、编解码、麦克风阵列、ISP、NPU/CPU 协同和散热的要求。瑞芯微、Qualcomm、Intel、联发科和 Jetson 类平台如果只优化单次文本解码，很难覆盖这种长期在线交互负载。
- 后续观察：看 MiniCPM-o 4.5 的 GGUF、Ollama、llama.cpp 和移动端适配是否能稳定支持打断、回声消除、长时运行和低功耗；看真实设备是否披露端到端延迟、内存峰值和连续运行温度。
- 来源：OpenBMB MiniCPM-o-Demo、MiniCPM-o 4.5 arXiv
Gemma 4 与 LiteRT-LM 把本地 Agent 做成运行时问题
- 事实：Google AI Edge 博客显示，LiteRT-LM 面向 Gemma 4 的跨平台端侧部署，覆盖 Android、iOS 和 Web。官方披露 Gemma 4 E2B 在 Android GPU 后端解码速度为 52 tokens/s，在 iOS Metal 上为 56 tokens/s，在 MacBook Pro WebGPU 上可达 76 tokens/s；LiteRT-LM 原生支持 Gemma 4 的 Multi-Token Prediction，可带来最高 2.2 倍加速，并通过权重缓存让约 2.58GB 的 Gemma 4 E2B 在 Apple 移动 CPU 上以 607MB 物理内存占用运行。另一篇 Google 开发者博客把 Gemma 4 12B 与 LiteRT-LM 的本地 OpenAI-compatible endpoint 绑定到本地 Agent 工作流。
- 我的判断：Gemma 4 的产业意义不只是开放权重，而是 Google 把模型、运行时、端点协议和本地 Agent 串成一条可部署路径。模型能否上端，越来越取决于运行时是否能处理 MTP、KV cache、动态加载视觉/音频组件和浏览器 WebGPU。
- 产业影响：端侧模型竞争会从“谁给出权重”转向“谁给出可复用运行时”。这会给 ONNX Runtime、OpenVINO、TensorRT、RKNN、Qualcomm AI Stack 和 llama.cpp 带来压力：开发者会优先选择能在手机、浏览器、AI PC 和工作站之间迁移的路径。
- 后续观察：看 Gemma 4 12B 在普通 AI PC 和高端手机上的真实长会话内存、工具调用延迟和电池消耗；看 LiteRT-LM 的 OpenAI-compatible endpoint 是否被本地 coding agent、RAG 工具和浏览器插件采用。
- 来源：LiteRT-LM 端侧部署博客、Gemma 4 12B 本地 Agent 博客
OpenAI 实时语音模型把语音入口从听写推向 Agent 控制
- 事实：OpenAI 开发者模型页显示，GPT-Realtime-2 是面向实时语音交互的推理模型，支持文本、音频和图像输入，输出文本和音频，支持可配置 reasoning effort、更强指令跟随和更可靠工具使用，模型页列出 128,000 context window 与 32,000 max output tokens。OpenAI 的实时翻译 Cookbook 说明
gpt-realtime-translate面向直播、通话和视频会话的语音到语音翻译，可在处理输入音频的同时流式返回译文音频；GPT-Realtime-Whisper 模型页则显示其面向实时转写，按音频时长计费。 - 我的判断：语音模型正在从 ASR/TTS 管线变成 Agent 控制入口。过去语音只是把用户的话转成文本，再交给 LLM；现在语音模型本身要承担实时推理、打断处理、工具策略和跨语言输出，端侧设备会被要求长期维护低延迟音频会话。
- 产业影响：车载、智能音箱、可穿戴、会议终端和服务机器人会更早感受到这类模型的压力。硬件平台不只要跑 LLM，还要处理回声消除、VAD、语音流、工具调用和多轮上下文，单纯堆 TOPS 不一定能改善体验。
- 后续观察：看 GPT-Realtime-2 是否在真实客服、会议、车载和机器人产品中披露打断成功率、工具调用失败率、端到端延迟和音频 token 成本；看本地语音模型是否能在隐私敏感场景替代云端实时链路。
- 来源：GPT-Realtime-2 模型页、Realtime Translation Cookbook、GPT-Realtime-Whisper 模型页
Mistral OCR 4 把多模态文档模型做成可自托管入口
- 事实：Mistral AI 2026 年 6 月 23 日发布 OCR 4，称其新增 bounding boxes、block classification 和 inline confidence scores，支持 170 种语言、10 个语言组，并可在单个容器中运行，面向企业搜索、RAG 和领域检索管线；官方还强调自管理部署面向企业客户可用，以满足数据驻留、主权和合规要求。
- 我的判断：OCR 4 的价值不是 OCR 本身，而是把文档多模态模型从“抽文字工具”升级为“结构化知识入口”。Agent 读企业资料时，真正需要的是版面、表格、图片、置信度和位置关系，而不是一串丢失上下文的纯文本。
- 产业影响：企业 RAG、工业运维、金融合规和科研 Agent 会更依赖文档理解模型。端侧或私有化服务器如果能本地解析高价值文档，就能减少把敏感资料送到云端大模型的需求，也会拉动 CPU/GPU/NPU 上的批处理吞吐和存储带宽。
- 后续观察：看 OCR 4 的自托管容器是否披露硬件要求、吞吐、单页成本和复杂表格错误率；看企业是否把置信度和 bounding boxes 用于 Agent 审计，而不是只把 OCR 结果塞进向量库。
- 来源：Mistral OCR 4
Gemini Robotics-ER 1.6 把机器人模型输出变成可执行结构
- 事实：Google AI for Developers 文档显示，Gemini Robotics-ER 1.6 面向机器人场景，可接收图像、视频、音频输入和自然语言提示，理解物体、场景关系、任务指令、空间与时间关系，并输出点或 bounding boxes 等结构化坐标。文档还说明该模型具备 agentic 能力，可把复杂任务拆成子任务，并通过函数调用或代码执行来编排长程任务；thinking budget 可用于在低延迟和高准确率之间调节。
- 我的判断：机器人基础模型的关键不只是“能看懂场景”，而是能否把场景理解转成控制系统可消费的中间结构。点、框、子任务和函数调用，比自然语言解释更接近机器人主控和运动控制栈的接口。
- 产业影响：这会改变机器人端侧平台的模型分工：大模型负责空间语义、任务分解和工具编排，实时控制仍由本地控制器完成。Jetson、Qualcomm、Intel、地平线、黑芝麻和瑞芯微平台需要证明自己能承接这种“多模态理解 + 结构输出 + 本地控制”的混合负载。
- 后续观察：看 Robotics-ER 1.6 是否开放更多 SDK、模型卡和真实机器人案例；重点验证 structured output 在多视角、遮挡、动态物体和低光照场景下的稳定性，以及 thinking budget 对延迟和成功率的真实影响。
- 来源：Gemini Robotics-ER 1.6 文档
DeepSeek V4 Preview 把长上下文竞争拉回成本效率
- 事实：DeepSeek 官方 2026 年 4 月 24 日发布 V4 Preview，称其进入 1M context length 时代并已开源。页面列出 DeepSeek-V4-Pro 为 1.6T total、49B active params，DeepSeek-V4-Flash 为 284B total、13B active params，并说明网页和 API 已更新可用。
- 我的判断：V4 Preview 的信号不只是上下文窗口变长，而是 DeepSeek 继续把超长上下文和 MoE active 参数绑定到成本叙事上。Agent、代码仓库分析、长文档问答和多轮业务流程最怕的是上下文压缩损耗，1M context 如果价格和延迟可控，会减少一部分复杂 RAG 和摘要工程。
- 产业影响：超长上下文会提高云端推理与私有化服务器的显存、KV cache 和调度压力，也会影响端侧策略。很多端侧设备可能不直接运行 V4-Pro，但会通过小模型做前处理、本地过滤和隐私裁剪，再把更少但更长的上下文交给云端或边缘服务器。
- 后续观察：看 DeepSeek 是否披露 1M 上下文下的真实延迟、价格、丢针测试、工具调用表现和长会话稳定性；看 V4-Flash 的 13B active 路线是否被国内 Agent、代码助手和企业知识库产品规模采用。
- 来源：DeepSeek V4 Preview Release
反共识观察
第一，模型产业短期最重要的竞争可能不是“谁的通用模型更聪明”，而是“谁的模型更容易驻留在真实系统里”。MiniCPM-o 4.5 解决的是连续音视频交互，Gemma 4/LiteRT-LM 解决的是本地运行时，OpenAI 实时语音模型解决的是语音 Agent 控制，Mistral OCR 4 解决的是文档结构入口，Gemini Robotics-ER 1.6 解决的是机器人结构化输出，DeepSeek V4 解决的是超长上下文成本。它们不在同一张榜单上竞争，但都会影响客户到底买云服务、AI PC、边缘盒子还是机器人主控。
第二，小模型和专用模型可能比 frontier 模型更快改变端侧硬件需求。原因很简单：frontier 模型定义上限，但端侧采购需要确定功耗、内存、热设计、离线能力、SDK 适配和长期维护。一个 9B 全双工模型、一个 12B 本地 Agent 模型、一个面向机器人或文档结构的专用模型，可能比新的闭源超大模型更快进入产品规格书。这个判断可以验证：如果未来 1 到 4 周更多发布强调 GGUF、Ollama、LiteRT、OpenAI-compatible endpoint、single-container self-host、structured output、thinking budget 和 on-device latency，而不是只强调参数规模和综合榜单，说明模型竞争已经向驻留化迁移。
观察清单
- MiniCPM-o 4.5 是否在真实手机、AI PC、机器人开发板和边缘盒子上披露低于 12GB RAM 的连续音视频交互实测。
- Gemma 4 与 LiteRT-LM 是否被本地 coding agent、浏览器插件、移动 App 和企业桌面工具采用，尤其是 OpenAI-compatible endpoint 的生态兼容性。
- GPT-Realtime-2、GPT-Realtime-Translate 和 GPT-Realtime-Whisper 是否披露真实场景的打断、延迟、翻译稳定性和工具调用失败率。
- Mistral OCR 4 的自托管容器是否给出硬件规格、吞吐、复杂表格准确率和置信度审计案例。
- Gemini Robotics-ER 1.6 的 structured output 是否能被更多机器人控制栈直接消费，而不是停留在演示级空间理解。
- DeepSeek V4 Preview 的 1M 上下文是否在 Agent、代码仓库和企业知识库中产生可复现的成本和质量优势。
评论