本文由 莫潇羽@无忆研习社（www.wuyi.wiki）原创撰写，转载请注明出处。
一、前言：端侧AI迎来全模态时代
过去两年，大语言模型的参数规模一路水涨船高，从几十亿到几千亿参数已经见怪不怪。然而，参数量越大就意味着对算力的要求越高，普通开发者和终端用户在本地设备上根本跑不动那些动辄需要数十张显卡才能推理的庞然大物。正因如此，"端侧部署"成了行业内一个持续升温的话题——如何在手机、平板、智能眼镜这类算力有限的终端设备上，也能享受到大模型的能力？
这个问题并不只是技术圈内的讨论，它直接关系到AI技术能否真正落地到普通人的日常生活中。试想一下，如果你的智能眼镜需要每次都连上高速网络才能帮你识别面前的路况信息，那它在地铁里、在山区、在信号不好的老旧建筑内就完全成了摆设。端侧部署的核心价值就在于让AI能力变得随时可用、离线可用、低延迟可用，让AI真正成为每个人触手可及的日常工具。
面壁智能（OpenBMB）给出的答案是 MiniCPM-o 4.5。这是一个仅有 9B（约90亿）参数的全模态大模型，却在视觉理解、语音交互、文档解析、声音克隆等多个维度上展现出了令人惊喜的表现。更关键的是，它采用了端到端的全模态架构设计，能够同时处理图像、视频、文本和音频输入，并以自然的方式输出文本和语音——这意味着你可以和它进行像真人一样的"边看、边听、边说"的实时对话，而不是传统的一问一答的对讲机模式。
对于关注AI前沿技术的开发者来说，MiniCPM-o 4.5 的另一个重磅亮点在于它是完全开源的。模型权重、代码、部署工具链全部公开，你可以自由地将它部署到自己的设备上，也可以基于它进行二次开发和微调。莫潇羽在无忆研习社（www.wuyi.wiki）长期跟踪各类开源AI项目，坦率地说，能在 9B 参数规模下达到这种全模态水平的开源模型，MiniCPM-o 4.5 目前确实是非常亮眼的存在。
接下来这篇文章，我会从技术原理到实际操作，一步一步带你全面了解 MiniCPM-o 4.5 的方方面面。文章篇幅比较长，建议收藏后慢慢阅读。不管你是想快速体验一下它的能力，还是想把它部署到自己的项目中，又或者是想深入理解它的架构设计思路，这篇指南都能帮到你。全文覆盖了从技术架构原理、环境安装配置、Python代码实战、视频分析与语音克隆、llama.cpp高性能部署，到在线体验和实际应用场景评估等方方面面的内容，力求让不同技术背景的读者都能找到对自己有用的信息。
二、MiniCPM-o 4.5 到底是什么
MiniCPM-o 4.5 是面壁智能（OpenBMB）推出的 MiniCPM-o 系列中最新一代的全模态大模型。如果你之前关注过他们的产品线，可能知道 MiniCPM-V 系列主要聚焦在视觉理解上，而 MiniCPM-o 系列则是在此基础上进一步扩展了音频输入和语音输出的能力，实现了真正意义上的"全模态"。
从底层构成来说，MiniCPM-o 4.5 是基于四个核心组件以端到端方式构建的：视觉编码器采用的是 SigLip2，负责处理图像和视频帧的特征提取；音频编码器选用的是 Whisper-medium，用于理解语音和声音输入；语音合成模块基于 CosyVoice2，支持高质量的文本转语音输出和声音克隆；而语言模型主干则是 Qwen3-8B，负责核心的文本理解与生成推理。这四个模块通过稠密特征紧密连接，总参数量约为 9B。相比前代的 MiniCPM-o 2.6（基于 Qwen2.5-7B 和 ChatTTS 构建），MiniCPM-o 4.5 在每个模块上都做了升级换代，尤其是语音合成从 ChatTTS 切换到了 CosyVoice2，语音输出的质量和稳定性有了质的提升。
说到这里需要解释一下"全模态"和"多模态"的区别。很多人习惯性地把能处理图片加文字的模型就叫做多模态模型，但 MiniCPM-o 4.5 所追求的"全模态"是更进一步的——它不仅能同时接收图像、视频、音频和文本这四种模态的输入，还能同时输出文本和语音两种模态的内容，而且这些输入和输出流之间是互不阻塞的。换句话说，模型可以一边"看"着视频画面、一边"听"着环境声音、一边"说"着自己的分析结论，三件事同时发生，而不是像传统模型那样必须等一个处理完再进行下一个。这种能力在技术上被称为"全双工多模态实时流"，是 MiniCPM-o 4.5 区别于大多数现有多模态模型的核心特性，后续章节会详细拆解其实现原理。
在性能评测方面，根据 OpenCompass 综合评估（涵盖8个主流评测基准），MiniCPM-o 4.5 在仅 9B 参数的情况下取得了 78.2 的平均分，视觉理解能力超过了 GPT-4o 和 Gemini 2.0 Pro，接近 Gemini 2.5 Flash 的水平。同时它还支持指令模式（instruct mode）和思考模式（thinking mode）两种推理方式的自由切换，让用户可以根据实际场景在效率和精度之间灵活取舍。
为了让大家对这个评分有一个更直观的感受，可以做一个简单的对比：GPT-4o 在同一评测体系中的分数大约在 73 到 75 之间，Gemini 2.0 Pro 大约在 76 左右，而 Gemini 2.5 Flash 则在 79 到 80 之间。MiniCPM-o 4.5 以 78.2 的分数紧追 Gemini 2.5 Flash，这对于一个 9B 参数的开源模型来说是非常亮眼的成绩。当然评测分数不能完全代表实际使用体验，但至少说明在基础能力层面，MiniCPM-o 4.5 已经具备了与主流商业模型同台竞技的实力。
项目的开源地址如下，所有代码和模型权重均可免费获取：
- GitHub 仓库：https://github.com/OpenBMB/MiniCPM-o
- Hugging Face 模型：https://huggingface.co/openbmb/MiniCPM-o-4_5
- 官方文档（CookBook）：https://minicpm-o.readthedocs.io/
三、为什么是9B参数——端侧部署背后的逻辑
看到这里可能有朋友会疑惑：现在动不动就是 70B、400B 参数的大模型满天飞，面壁智能为什么偏偏要做一个 9B 的"小"模型？这背后其实有一套非常清晰的产品逻辑。
首先要理解端侧设备的现实约束。所谓"端侧设备"，指的是手机、平板、智能眼镜、车载终端、边缘服务器这类终端硬件。这些设备的算力和显存资源非常有限，以一台搭载 M4 芯片的 iPad Pro 为例，它的统一内存也就 16GB 到 24GB 左右。一个 70B 参数的大模型，即便经过 INT4 量化，模型文件本身也要占掉 35GB 以上的空间，根本塞不进去。但 9B 参数的模型在 INT4 量化后只需大约 5GB 到 6GB 的空间，在绝大多数现代移动设备上都可以流畅运行。
其次是网络依赖的问题。如果你想在端侧设备上用大模型的能力，目前主流的方案有两条路：一条是通过网络调用云端的 API 接口，把推理任务交给云端服务器完成；另一条是直接把模型部署在本地设备上。云端 API 方案的好处是不受设备算力限制，可以用上最大最强的模型，但坏处也很明显——严重依赖网络连接。现实场景中，进电梯、进地下车库、处于信号盲区的时候，云端方案就完全失灵了。对于一些对实时性要求很高的应用场景（比如智能眼镜的实时视觉辅助），几百毫秒的网络延迟可能就是不可接受的。而且从数据隐私角度来看，将摄像头拍摄的画面持续上传到云端进行分析，在很多场景下也是用户难以接受的。
在这个背景下，本地部署小参数模型就是一个更加务实的选择。MiniCPM-o 4.5 的 9B 参数规模恰好落在了一个甜蜜点上——参数足够多，使得模型的理解能力和生成质量不至于太差（官方评测显示在多个基准上已经超越了 GPT-4o）；参数又不算太多，使得模型可以在消费级硬件上以可接受的速度运行。
还有一个经常被忽视的因素是功耗。移动设备的电池容量有限，一个需要持续高功率运算的大模型会在很短时间内耗尽设备电量并导致设备严重发热。9B 参数模型在 INT4 量化后的推理功耗相对可控，不会让你的手机在半小时内变成"暖手宝"。根据官方测试数据，MiniCPM 系列在 iPhone 16 Pro Max 上运行时不会出现过热问题，首 Token 延迟低于 2 秒，解码速度可达 17 Token/秒以上，这些指标对于实际使用来说是完全可接受的。
面壁智能一直将 MiniCPM 系列定位为"端侧小钢炮"，强调的就是在有限参数规模下追求最高的能力密度。MiniCPM-o 4.5 不仅在模型能力密度上更上了一个台阶，同时也在推理效率上做了大量优化——更低的显存占用、更快的首 Token 响应速度、更少的推理开销，这些都是端侧部署必须考虑的关键指标。
四、核心技术架构深度拆解
要真正理解 MiniCPM-o 4.5 为什么能在 9B 参数下做到全模态交互，就需要深入看一下它的架构设计。这里把它的技术架构拆开来详细说明，方便大家建立一个完整的认知。
端到端全模态架构
MiniCPM-o 4.5 的整体架构可以拆解为四个关键模块：
视觉编码器（SigLip2）负责将图像和视频帧编码为高维度的特征向量。SigLip2 是 Google 发布的一种视觉-语言对比学习模型，相比早期的 CLIP 系列，SigLip2 在图文匹配精度和小分辨率输入处理上有明显优势。传统的视觉编码器在处理不同分辨率的图像时往往需要将其统一缩放到固定尺寸，这个过程会丢失很多细节信息。而 SigLip2 能够更好地适应不同分辨率和宽高比的输入。MiniCPM-o 4.5 利用它来处理各种分辨率和宽高比的图像输入，支持最高 180 万像素（例如 1344×1344）的高分辨率图像处理，这对于需要识别小字号文字的文档解析场景尤为重要。
音频编码器（Whisper-medium）负责将音频信号转化为特征表示。Whisper 是 OpenAI 发布的通用语音识别模型，它在训练时使用了海量的多语言语音数据，因此具备极强的跨语言语音理解能力。medium 规模版本在语音识别准确率和模型大小之间取得了不错的平衡——它的参数量不到 3 亿，却能在大多数语言上达到接近 large 版本的识别效果。在 MiniCPM-o 4.5 中，Whisper-medium 不仅能做基本的语音识别（ASR），还能理解说话者的情感、年龄、性别等特征信息，以及对环境声音进行场景标记，比如判断当前处于办公室、街道还是音乐会现场。
语音合成模块（CosyVoice2）负责将模型生成的文本转化为自然语音输出。CosyVoice2 是一个高质量的语音合成系统，支持零样本声音克隆——只需要一小段参考音频，就可以克隆出该说话者的声音特征。值得注意的是，MiniCPM-o 4.5 在声音克隆效果上甚至超越了 CosyVoice2 原始模型的独立表现，这说明端到端的训练方式确实能让语音合成模块从其他模态中获得额外的信息增益。
语言模型主干（Qwen3-8B）是整个架构的核心大脑，负责文本理解、逻辑推理和内容生成。Qwen3-8B 是第三代通义千问系列中 8B 参数的版本，具备强大的中英双语理解和推理能力。选择 Qwen3 作为语言主干，一方面是因为它在同参数规模下表现优异，另一方面也是因为 Qwen3 原生支持中文处理，这对于面壁智能面向中文用户市场的定位来说非常重要。
这四个模块并不是简单的拼接或串联关系。在传统的多模态模型中，不同模态的编码器通常是独立工作的，编码完成后再把特征拼接在一起喂给语言模型。但 MiniCPM-o 4.5 采用的是"端到端"设计——各模态编码器和解码器通过稠密特征（dense features）与语言模型主干紧密连接，信息在各模块之间的流转是深度融合的，而不是表面层的简单拼接。这种设计带来的好处是：模型在训练过程中能够更充分地挖掘和利用跨模态的知识关联，比如视觉场景中的声音线索、语音内容中暗含的情感与画面的匹配等等。
架构设计的核心思想
如果要用一句话总结 MiniCPM-o 4.5 架构设计的核心思想，那就是"用尽可能少的参数，通过更聪明的连接方式和训练策略，获得尽可能强的全模态能力"。这是一种与"堆参数、堆数据"截然不同的技术路线，更适合端侧部署场景下的实际需求。
从更宏观的视角来看，MiniCPM-o 4.5 代表了大模型发展中一个重要的方向分支。行业里有一部分团队在不断追求更大的参数规模，期望通过规模效应获得能力的飞跃（即所谓的 Scaling Law）；而另一部分团队则在探索如何在固定的参数预算内，通过更精巧的架构设计、更高效的训练数据利用和更聪明的推理策略来逼近甚至超越大参数模型的表现。MiniCPM-o 系列明显属于后者。这种技术路线的商业价值在于，它能让更多的终端设备和更多的应用场景获得大模型的能力加持，而不是让大模型只能停留在少数拥有大规模算力的企业和研究机构手中。
五、四大核心机制详解
除了底层的四模块架构之外，MiniCPM-o 4.5 还引入了四项关键的技术创新，正是这些机制让它的交互体验产生了质的飞跃。下面逐一展开说明。
全双工多模态实时流机制
传统的AI语音助手（包括大部分多模态大模型）都是"半双工"的——你说完话，它才开始处理和回复，就像对讲机一样需要轮流说话。这种交互方式在聊天对话中尚可接受，但在实时场景中（比如驾驶时的语音助手、视频通话中的实时翻译）就显得非常不自然。你不得不等模型说完才能插话，模型也不能在你说话的过程中同时观察画面变化。MiniCPM-o 4.5 突破了这个限制，实现了"全双工"的实时流式交互。
具体来说，这个机制包含两个层面的创新。第一个是将离线的模态编码器和解码器改造成了支持流式输入和输出的在线全双工版本。以语音解码器为例，它采用了文本 Token 与语音 Token 交错建模的方式，这样即便模型正在生成语音输出，也能同时接收新的音频输入并做出即时响应。这种交错建模的方式还解决了一个长期困扰语音生成领域的问题——长语音（超过一分钟）生成的稳定性。在传统的非交错方案中，语音生成到后半段经常会出现质量下降、甚至崩溃的问题，而交错方式让每一段语音片段都能得到更好的控制。
第二个层面是时分复用（Time Division Multiplexing）机制。模型在毫秒级的时间线上同步管理所有的输入流和输出流，通过将并行的全模态数据流划分为微小的周期性时间片，在每个时间片内按照固定顺序处理信息。打个更通俗的比方：如果把语言模型主干想象成一个人的大脑，它在任意一个瞬间只能集中注意力处理一件事，但通过极快的切换速度（毫秒级），就可以造成"同时"处理多路信息的效果。这个思路其实借鉴了通信领域的经典技术——就像一条电话线可以通过时分复用同时承载多路通话一样，一个语言模型主干也可以通过时分复用同时处理视频帧、音频信号和文本生成。这种设计的巧妙之处在于，它不需要为每种模态单独维护一个模型分支，从而大幅节省了参数量和计算资源。
主动交互机制
绝大多数现有的AI助手都是"被动"的——你不问它就不说话。但真正自然的人类对话并不是这样的，一个好的对话伙伴会在观察到某些情况时主动开口提醒或评论。比如你和朋友一起逛街，朋友看到你喜欢的品牌在打折，不需要你主动询问就会提醒你。MiniCPM-o 4.5 的主动交互机制就是为了实现这种更自然的交互模式。
其实现原理是：语言模型模块会持续不断地监控输入的视频和音频流，并以 1Hz 的频率（即每秒一次）自动做出"说还是不说"的决策。这个 1Hz 的决策频率看起来不高，但考虑到模型需要综合理解当前画面内容、音频信息和对话上下文来判断是否值得主动发言，这个频率其实已经足够支撑流畅的交互体验了。
举个实际的例子：当你戴着搭载 MiniCPM-o 4.5 的智能眼镜过马路时，模型通过实时视频流"看到"有车辆快速驶来，它就可以主动提醒你注意安全，而不需要你先开口问"前面有没有车"。这种主动交互能力结合全双工特性，让整个交互体验从"工具使用"变成了更接近"伙伴对话"。
可配置语音建模设计
MiniCPM-o 4.5 延续了 MiniCPM-o 2.6 的多模态系统提示词设计，同时支持文本系统提示词和音频系统提示词。音频系统提示词的主要作用是指定输出语音的音色特征——你只需提供一段几秒钟的参考音频，模型就能在推理过程中克隆该音色并用于后续的所有语音输出。这种设计的优雅之处在于，声音风格的切换完全在推理阶段通过提示词实现，不需要对模型进行任何重新训练或微调。
这一设计让很多有趣的应用成为可能：你可以用自己的声音作为参考音频，让AI用你的声音说话；你也可以用某个喜欢的角色的声音片段，让AI扮演那个角色与你对话。更实用的场景是在客服、导播等行业应用中，可以方便地配置统一的品牌声音。从技术角度来看，MiniCPM-o 4.5 的声音克隆能力得益于端到端训练的优势——语音合成模块在训练过程中不仅学习了声音特征的提取和重建，还从视觉和文本模态中获取了额外的语境信息，使得合成出来的语音在情感表达和语调匹配上更加自然。
混合推理模式
值得一提的还有 MiniCPM-o 4.5 支持的混合推理模式切换。在实际使用中，不同场景对模型的响应速度和推理深度有不同的要求。简单的日常对话追求的是快速响应，不需要模型做太深入的推理；但如果是复杂的图表分析或数学推理任务，就需要模型花更多时间"想一想"。MiniCPM-o 4.5 在单一模型中同时支持 instruct 模式（快速响应）和 thinking 模式（深度思考），开发者可以通过设置 enable_thinking 参数在两种模式之间灵活切换，无需加载不同的模型权重。
六、环境准备与依赖安装（全平台指南）
了解完原理之后，接下来进入实操环节。莫潇羽@无忆研习社（www.wuyi.wiki）会从零开始，手把手带你完成 MiniCPM-o 4.5 的环境配置。这部分内容面向有一定 Python 基础的开发者，如果你是完全零基础的小白，建议先了解一下 Python 环境配置和 pip 包管理的基本操作。
硬件要求
在开始之前，先确认一下你的硬件是否满足最低要求。MiniCPM-o 4.5 的完整模型（包含视觉、音频和语音合成全部模块）在 BFloat16 精度下大约需要 18GB 到 20GB 的显存。这意味着一块 NVIDIA RTX 4090（24GB 显存）可以轻松跑完整模型，RTX 3090（24GB）也完全没问题，RTX 4080（16GB）则需要做一些裁剪。如果你的 GPU 显存不够，可以考虑以下几种方案：只加载视觉模块不加载音频和语音模块（设置 init_audio=False 和 init_tts=False），这样显存需求会降到 16GB 左右；使用 INT4 量化版本的模型，显存需求可以进一步降到 6GB 到 8GB 左右，一块 RTX 3060（12GB）甚至 RTX 3050（8GB）就能胜任；或者使用 llama.cpp 方案在 CPU 上运行，虽然速度慢一些，但对显存没有要求，只需要 8GB 以上的系统内存即可。
Python 依赖安装
MiniCPM-o 4.5 的 Python 依赖安装分为两种情况，取决于你是否需要语音合成（TTS）功能。
如果你不需要语音输出，只需要视觉理解和文本生成能力，安装基础依赖即可：
pip install "transformers==4.51.0" accelerate "torch>=2.3.0,<=2.8.0" "torchaudio<=2.8.0" "minicpmo-utils>=1.0.2"如果你需要完整的语音合成能力（包括声音克隆），则需要安装带有 [all] 后缀的完整版：
pip install "transformers==4.51.0" accelerate "torch>=2.3.0,<=2.8.0" "torchaudio<=2.8.0" "minicpmo-utils[all]>=1.0.2"两者的区别主要在于 minicpmo-utils 这个工具库。基础版只包含核心推理功能，而 [all] 版本额外包含了 CosyVoice2 语音合成所需的全部依赖。在安装过程中，torch 和 torchaudio 的版本需要严格对应，否则可能会出现各种兼容性问题。如果你在安装过程中遇到版本冲突的报错，建议先创建一个干净的 Python 虚拟环境再进行安装：
python -m venv minicpm_env
source minicpm_env/bin/activate # Linux/macOS
# 或者 minicpm_env\Scripts\activate # Windows在虚拟环境中安装可以有效避免系统级的 Python 包版本冲突问题。另外需要注意的是，transformers 库目前需要指定 4.51.0 这个特定版本，使用过高或过低的版本都可能导致模型加载失败，因为 MiniCPM-o 4.5 使用了一些较新的自定义模型架构特性。
安装 ffmpeg
由于 MiniCPM-o 4.5 需要处理视频和音频数据，ffmpeg 是一个必不可少的工具。ffmpeg 是一个开源的音视频处理框架，几乎所有涉及音视频编解码的项目都离不开它。不同操作系统的安装方式如下：
Windows 系统：前往 ffmpeg 官网（https://www.ffmpeg.org/）下载对应的可执行文件包。下载完成后解压到某个目录，然后把该目录下的 bin 文件夹路径添加到系统的环境变量 PATH 中。添加完成后，打开命令提示符输入 ffmpeg -version，如果能看到版本信息输出就说明安装成功了。
macOS 系统：如果你已经安装了 Homebrew（macOS 上最常用的包管理器），一条命令就能搞定：
brew install ffmpegUbuntu/Debian 系统：同样非常简单，使用 apt 包管理器即可：
sudo apt update && sudo apt install ffmpeg安装完成后同样可以通过 ffmpeg -version 命令验证安装是否成功。
关于 CUDA 和 GPU 驱动
如果你打算使用 GPU 来运行模型（这也是推荐的方式，推理速度会比 CPU 快一个数量级以上），需要确保你的 NVIDIA 显卡驱动和 CUDA 工具包已经正确安装。MiniCPM-o 4.5 支持 CUDA 11.8 及以上版本。你可以通过 nvidia-smi 命令查看当前的驱动版本和 CUDA 版本信息。如果输出信息中看不到 CUDA 版本号或者版本低于 11.8，就需要去 NVIDIA 官网下载并安装对应的驱动和 CUDA 工具包。如果你使用的是 AMD 显卡，也可以尝试通过 ROCm 来运行，不过目前官方文档中对 AMD 的支持说明较少，可能需要自行摸索。对于苹果 M 系列芯片的 Mac 用户，通过 llama.cpp 方案可以利用 Metal 框架进行 GPU 加速推理，效果也相当不错。
七、Python API 本地部署实战
环境准备好之后，就可以正式开始加载和使用模型了。这一章我们通过 Python 代码一步步走完从模型下载到实际推理的全流程。
模型下载与初始化
MiniCPM-o 4.5 的模型托管在 Hugging Face 上，完整模型文件大约有 18GB 左右，下载时请确保你的磁盘空间充足。首次运行时 from_pretrained 方法会自动从 Hugging Face 下载模型文件到本地缓存目录（默认在 ~/.cache/huggingface/ 下），后续再次使用时会直接从缓存加载，不再重复下载。如果你的网络环境访问 Hugging Face 不太顺畅，可以提前通过 huggingface-cli 命令手动下载到指定目录：
pip install huggingface-hub
huggingface-cli download openbmb/MiniCPM-o-4_5 --local-dir ./MiniCPM-o-4_5国内用户也可以通过 ModelScope（魔搭社区）下载，速度通常更快：
pip install modelscope
modelscope download --model openbmb/MiniCPM-o-4_5 --local_dir ./MiniCPM-o-4_5下载完成后，就可以用以下 Python 代码加载模型了：
import torch
from transformers import AutoModel
# 加载全模态模型（默认: init_vision=True, init_audio=True, init_tts=True）
# 如果只需要视觉功能: 设置 init_audio=False 和 init_tts=False
# 如果只需要音频功能: 设置 init_vision=False
model = AutoModel.from_pretrained(
"openbmb/MiniCPM-o-4_5",
trust_remote_code=True,
attn_implementation="sdpa", # 可选 sdpa 或 flash_attention_2
torch_dtype=torch.bfloat16,
init_vision=True,
init_audio=True,
init_tts=True,
)
model.eval().cuda()
# 初始化TTS模块，用于语音输出
model.init_tts(streaming=False) # streaming=True 可启用流式语音输出这段代码有几个关键参数值得说明。trust_remote_code=True 是必须的，因为 MiniCPM-o 使用了自定义的模型架构代码，Transformers 库需要信任并执行这些远程代码。attn_implementation 参数用于选择注意力机制的实现方式，sdpa 是 PyTorch 自带的 Scaled Dot-Product Attention 实现，如果你安装了 Flash Attention 2 库，也可以选择 flash_attention_2 来获得更快的推理速度。torch_dtype=torch.bfloat16 指定使用 BFloat16 半精度来加载模型，这是在显存占用和推理精度之间的一个良好平衡点。
单图理解推理
加载完成后，最简单的使用方式就是给模型一张图片，让它分析图片内容：
from PIL import Image
# 加载图像
image = Image.open("test_image.png").convert("RGB")
question = "请详细描述这张图片中的内容。"
# 构造消息
msgs = [{"role": "user", "content": [image, question]}]
# 推理
res = model.chat(msgs=msgs, use_tts_template=False)
print(res)这里的 model.chat 方法是 MiniCPM-o 提供的高层封装接口，它会自动处理图像预处理、特征提取和文本生成的全过程。你不需要手动对图片进行裁剪、缩放或归一化等操作，模型内部会自动完成这些步骤。use_tts_template=False 表示本次推理不使用语音输出模板，只输出纯文本。如果你想让模型同时输出语音，需要将这个参数改为 True 并设置输出音频路径。
值得一提的是，model.chat 方法支持多轮对话。你可以在 msgs 列表中依次添加多轮 user 和 assistant 的消息，实现连续追问的效果。比如先问"图片里有什么"，得到回答后再追问"左边那个物体是什么颜色的"，模型会结合之前的对话上下文来回答。
多图对比分析
MiniCPM-o 4.5 同样支持多图输入，你可以在一个对话中同时传入多张图片让模型进行对比分析：
image1 = Image.open("image1.jpg").convert("RGB")
image2 = Image.open("image2.jpg").convert("RGB")
question = "请对比这两张图片，告诉我它们之间的主要区别。"
msgs = [{"role": "user", "content": [image1, image2, question]}]
res = model.chat(msgs=msgs, use_tts_template=False)
print(res)消息内容列表中的元素顺序就代表了模型接收到的信息顺序——先看第一张图，再看第二张图，最后看到文字问题。这种直观的接口设计让多图分析变得非常简单，你可以传入两张、三张甚至更多的图片让模型进行综合分析。在实际应用中，多图对比在电商场景（比较不同商品的外观差异）、医疗场景（对比治疗前后的影像变化）和工业质检场景（比较合格品与缺陷品的区别）中都有广泛的用途。
单工模式与双工模式切换
MiniCPM-o 4.5 支持两种工作模式：单工模式（simplex）和双工模式（duplex）。单工模式就是常规的一问一答方式；双工模式则开启了全双工流式交互能力，允许模型在生成输出的同时持续接收新的输入。模式切换非常简单：
# 从单工模式切换到双工模式
duplex_model = model.as_duplex()
# 从双工模式切换回单工模式
simplex_model = duplex_model.as_simplex(reset_session=True)双工模式主要用于实时流式交互场景（比如视频通话中的实时分析），对于离线的图片或文档分析任务，使用默认的单工模式就够了。
八、视频分析与语音克隆实战
单张图片的理解只是 MiniCPM-o 4.5 能力的冰山一角，它真正的杀手锏在于对视频流的实时分析以及语音克隆输出。这一章我们来看看如何实现这些更高级的功能。
视频分析完整流程
对视频进行分析的核心思路是：将视频按帧拆解，把每一帧图像和对应的音频片段按时间顺序组织好，然后一起传给模型进行全模态推理。MiniCPM-o 4.5 提供了一个很方便的工具函数 get_video_frame_audio_segments 来自动完成视频的拆帧和音频切割工作：
from minicpmo.utils import get_video_frame_audio_segments
# 确保模型已加载并初始化TTS
model.init_tts(streaming=False)
video_path = "test_video.mp4"
# （可选）设置参考音频用于声音克隆
ref_audio_path = "reference_voice.wav"
sys_msg = model.get_sys_prompt(
ref_audio=ref_audio_path,
mode="omni",
language="zh" # 中文场景设置为 "zh"，英文为 "en"
)
# 提取视频帧和音频片段
# stack_frames=1 表示逐帧处理，设为5可启用高刷新率模式
video_frames, audio_segments, stacked_frames = get_video_frame_audio_segments(
video_path, stack_frames=1
)
# 组装全模态内容
omni_contents = []
for i in range(len(video_frames)):
omni_contents.append(video_frames[i])
omni_contents.append(audio_segments[i])
if stacked_frames is not None and stacked_frames[i] is not None:
omni_contents.append(stacked_frames[i])
msg = {"role": "user", "content": omni_contents}
msgs = [sys_msg, msg]这段代码的关键在于 stack_frames 参数。当设为 1 时，模型逐帧处理视频，分析精度最高但速度也最慢；当设为 5 时，每 5 帧会被堆叠压缩成一组特征，处理速度大幅提升但可能丢失一些细节。对于大多数日常使用场景，stack_frames=1 已经足够。如果你处理的是长视频或者实时流式场景，可以适当调高这个值来平衡速度和精度。另外需要注意的是，视频的分辨率也会影响处理速度——一个 4K 视频的每一帧包含的像素数量是 1080P 视频的四倍，相应的处理时间也会大幅增加。如果对速度有要求，建议在喂入模型之前先对视频进行降分辨率处理。
还有一个实用的技巧：get_video_frame_audio_segments 函数默认按照视频的原始帧率来提取帧。如果你的视频是 30fps 甚至 60fps 的高帧率视频，但实际上画面变化并不剧烈（比如监控摄像头的画面），那么可以在预处理阶段先降低帧率到 3 到 5fps，这样在几乎不损失信息的前提下可以大幅减少需要处理的帧数。
带语音输出的完整推理
组装好消息之后，调用 model.chat 方法进行推理，并通过参数控制是否生成语音：
res = model.chat(
msgs=msgs,
max_new_tokens=4096, # 最大生成Token数
do_sample=True, # 启用采样
temperature=0.7, 
