1. 为什么是 MiniCPM-o 4.5多模态双工智能体的选型逻辑先交代一下背景。我一直在做端侧多模态 Agent 相关的项目之前用过不少开源多模态模型但始终有几个痛点在纠缠一是视觉、音频、文本三个模态的模型往往是分开的要做全双工对话就得拼装 ASR、LLM、TTS 三套管线延迟和稳定性很难控二是端侧模型一旦做多模态融合参数量上去了推理速度又拉胯三是即使把模型跑起来了想在业务场景里微调出符合自己需求的效果资料少、坑却特别多。关注面壁智能的 MiniCPM-o 4.5 有一段时间了最初看到它的定位是“新一代多模态模型”支持视觉、音频、文本的任意组合输入输出我当时的第一反应是这种全模态架构如果真的在端侧能跑那对做智能体的人来说是个很大的变量。后来亲眼看到它的全双工语音演示才决定把这个模型作为 Gander 的基座模型。Gander 这个项目的目标很明确在 MiniCPM-o 4.5 的基础上微调出一个具备全双工对话能力的多模态智能体。双工意味着什么最简单的理解是——对话双方可以同时说话AI 不再是你一句我一句的“按键对讲机”而是像真人一样能听、能想、能回应、能在你说话中途插话或者被插话。这种体验上的跨越对智能客服、口语陪练、智能硬件助手这类场景来说是质变。选型的过程其实没有那么复杂我给自己定了几个硬性指标必须是单一模型支持视觉、音频、文本的多模态输入输出而不是三个模型拼装必须能在消费级 GPU 上完成微调项目预算和算力都不允许我用几百张卡去训练全双工语音交互能力是必备项最好是模型原生支持而不是靠外部模块硬凑有社区活跃度有可参考的微调实战案例。对比了一圈之后MiniCPM-o 4.5 确实是当时最贴合这几个要求的开源模型。它不是简单的“视觉模型 语音模型”缝合而是在架构上做了统一的模态建模同时通过 LoRA 这类轻量微调技术给二次开发留了很大的空间。这一点后面会详细展开。对普通读者来说你不需要一上来就理解所有架构细节只需要先建立一个认知MiniCPM-o 4.5 是一个能干“看、听、说、写”四件事的开源多模态模型而 Gander 要做的就是把这些能力通过微调和工程化变成真正能在业务里跑起来的双工智能体。2. 微调方案拆解四个关键技术点决定了 Gander 的成败2.1 全参微调 vs 参数高效微调为什么我选了后者在真正动手之前先得把微调路线想清楚。大模型微调目前常见的有四种方式我梳理了一下基本是这么个递进关系全参微调Full Fine-tuning把所有模型参数都参与训练效果上限最高但显存开销巨大、训练时间长而且对小规模数据容易灾难性遗忘MiniCPM-o 4.5 这种 8B 级别的多模态模型全参微调在单卡上基本不现实适配器微调Adapter在模型层之间插入小型可训练模块冻结原模型训练参数量小但推理时会增加额外的计算延迟对于强调实时性的双工语音场景来说不够友好前缀微调Prompt/Prefix Tuning在输入序列前加一组可学习的虚拟 token改动极小但效果不稳定尤其在多模态任务里很难控制不同模态之间的平衡LoRA 微调Low-Rank Adaptation通过低秩分解矩阵来近似参数更新量只训练新增的小矩阵既保留了原模型的通用能力又能在特定任务上快速收敛。Gander 最终选择的是 LoRA 路线而且用的是它的增强版 QLoRA。为什么最核心的原因是双工智能体这个场景很特殊它要求模型在对话过程中同时处理语音流和视觉流推理链路长、实时性要求高。LoRA 在推理时可以把训练好的低秩矩阵合并回原模型权重不引入任何额外的推理时延这一点对双工体验至关重要。另外还有一个很现实的考虑数据量。Gander 的微调数据并不是百万级的通用语料而是围绕特定业务场景整理的高质量指令数据几千到几万条的量级。在这种中小规模数据集上LoRA 微调比全参微调更稳不容易把模型原有的多模态对齐能力冲掉。2.2 LoRA 的低秩适配原理用“翻译助手”的比喻理解它如果不做技术研究理解 LoRA 可以从一个类比入手。想象你有一本写好的英文原版书预训练模型现在想把它翻译成特定领域的中文微调目标但你又不想把整本书重新写一遍。LoRA 的做法是在旁边放一个小小的“翻译助手”这个助手只学一个低维度的翻译规则把原版书里的关键段落“转译”过去而不是动原版书的任何一页。数学上LoRA 的想法是模型参数更新量 ΔW 虽然维度很高但它的“内在秩”其实很低可以用两个低秩矩阵 A 和 B 的乘积来近似。训练过程中原模型权重 W 保持冻结只有 A 和 B 在更新。实际使用时把 AB 合并回 W模型结构和推理速度都不受影响。具体到 MiniCPM-o 4.5 上它的架构包含视觉编码器、音频编码器和语言模型主干各模块之间存在复杂的对齐关系。直接对所有模块施加 LoRA 并不是最优选择我更推荐的做法是重点在语言模型主干的 attention 层上加 LoRA视觉和音频编码器保持冻结。为什么这样设计因为多模态模型中编码器已经学到了高质量的模态语义表示真正需要被业务数据“重塑”的是语言模型如何理解和推理这些模态信号。2.3 QLoRA 的量化策略在 24G 显存上跑 8B 多模态模型这里延伸讲一下 QLoRA。QLoRA 是在 LoRA 基础上叠加了量化思想把预训练模型以 4-bit 或 8-bit 的精度加载到显存中只对 LoRA 分支保持较高精度训练。效果就是显存占用大幅下降而模型能力基本不损失。MiniCPM-o 4.5 完整加载的显存开销在 16GB 到 20GB 之间加上训练时的梯度、优化器状态和激活值如果不用量化消费级显卡几乎不可能训练。我实际测试下来用 4-bit 量化加载模型配合 LoRA rank16 的配置24GB 显存的 RTX 3090 / 4090 就能稳定跑完整个微调流程batch size 设为 1梯度累积步数设为 8等效 batch size 是 8训练稳定性非常好。这里有一个需要注意的细节量化加载对多模态模型的输入编码有影响。特别是在视觉 token 和音频 token 进入语言主干之后量化误差可能会在某些任务上放大。我的解决方案是量化配置中保留 feed-forward 层的部分参数为 bf16即所谓“量化敏感层豁免”这个操作能明显提升多模态任务的稳定性而显存开销只增加了 1GB 左右。3. 数据是重头戏多模态数据集从哪来、怎么构造3.1 数据获取公开数据集与自建数据的比例控制微调效果的上限很大程度由数据质量决定。MiniCPM-o 4.5 本身在多模态对齐和数据覆盖上已经做得不错所以微调数据的核心目标不是“教它认识世界”而是“教它在你的场景里如何表现”。我用的数据分为三大类通用多模态对话数据包括图像描述、视觉问答VQA、图文推理、音频事件理解等。这类数据用来保持模型的多模态能力不退化占比约 40%。公开来源有 COCO Caption、LLaVA 的指令数据、AudioCaps 等按需采样就行不需要全部拿来训练。场景业务数据这部分是 Gander 的灵魂。我针对智能助手这个场景手工构建了约 3000 条中文多模态指令数据覆盖了用户拿着摄像头拍物体问“这是什么”、发一张图片让 AI 描述并给出建议、语音直接提问并期望语音回答等典型交互。占比约 30%。双工特征数据这是全双工智能体独有的数据形式。除了正常的“用户问—AI 答”之外还需要构造“用户话没说完AI 已经理解意图并给出回应”、“用户说话中途被打断后重新组织语言”之类的交互样本。这部分数据很难公开获取是影响 Gander 体验的关键占比约 30%。三类数据合在一起过滤后大概 8000 条左右对于一个以 LoRA 方式微调的项目来说这个量级是合理的。数据规模不是越大越好关键是覆盖面和数据质量。3.2 数据清洗与格式转换一个容易翻车的环节多模态微调的数据格式比纯文本微调复杂得多因为每条样本可能同时包含图像、音频和文本三种模态。MiniCPM-o 4.5 的输入格式有明确规范我踩过的坑是不同来源数据的采样率不一致。音频部分模型要求 16kHz 采样率的单声道 WAV而很多公开数据集是 22.05kHz 或 44.1kHz。光做重采样还不够响度归一化peak normalization也很重要否则训练时同一批数据里音量忽大忽小模型会困惑。我统一用 ffmpeg 做了批处理重采样到 16kHz、转单声道、归一化到 -1.0dBFS。视觉部分图片不需要统一尺寸MiniCPM-o 4.5 的视觉编码器会做自适应处理但要注意图片格式最好是 RGB 三通道透明度通道会导致编码异常。有少数数据集的图片是 RGBA训练时 loss 倒不会崩但生成效果会间歇性出问题这个很难排查。指令格式上我参考了 MiniCPM-o 4.5 官方微调脚本中推荐的对话模板每条数据构造如下{ messages: [ {role: user, content: [ {type: image, image: path/to/image.jpg}, {type: audio, audio: path/to/audio.wav}, {type: text, text: 请帮我看看这个物品是什么} ]}, {role: assistant, content: [ {type: text, text: 从图片来看这是一个机械键盘它的键帽配色是白蓝相间……} ]} ] }在构造数据时一定要带着“真实交互”的视角去写而不是堆模板。比如智能助手场景里用户不会一板一眼地说“请描述图片内容”而是更口语化的表述。这些口语化变体要主动构造进去否则微调出来的模型在真实对话中会很“僵硬”。3.3 双工数据的三段式结构全双工交互最独特的地方在于AI 的回应往往发生在用户说话结束之前或同时。为了让模型学会这种能力我把双工数据形式化为“三段式”结构第一段是用户的部分语音输入比如“你能不能帮我看看这个——”第二段是用户的完整语音输入或补充输入“——这个螺丝的型号”第三段才是 AI 的完整回复。在训练中模型需要学习的是当语音流还未完全结束时多模态特征已经充分激活可以提前触发推理。这种数据构造方式需要人工精心标注和剪辑也是 Gander 项目最耗时的一部分。但如果没有这一步全双工就只剩一个空壳。很多人问全双工的“提前回应”为什么不让工程层做比如通过 VAD语音活动检测判断用户停顿就触发回复我的经验是只靠 VAD 不够。因为真实对话中停顿的原因很多有的是思考有的是语气延宕如果一停顿就触发回复体验反而很糟糕。模型原生学会“听完再回 / 没听完就回”的判别是更优雅的方案也是把双工能力沉淀在模型权重里而不是写死在代码里的关键。4. 微调实操从环境搭建到损失收敛的完整过程4.1 环境准备与依赖安装一天搞定的“顺手”过程先说环境。我用的是一台单卡 RTX 409024GB 显存64GB 内存Ubuntu 22.04CUDA 12.1。理论上 3090 也能跑只是慢一些。Python 环境建议直接用 conda 新建一个独立环境Python 版本选 3.10 就好。核心依赖如下conda create -n gander python3.10 -y conda activate gander # 安装 PyTorch根据你的 CUDA 版本选择对应命令 pip install torch2.3.0 torchvision0.18.0 torchaudio2.3.0 --index-url https://download.pytorch.org/whl/cu121 # 安装 transformers 与 accelerate注意版本兼容性 pip install transformers4.42.0 accelerate0.30.0 # 安装 peftLoRA 微调的核心库 pip install peft0.10.0 # 安装 bitsandbytesQLoRA 量化需要 pip install bitsandbytes0.43.0 # 安装 deepspeed可选用于加速 pip install deepspeed0.13.2这里有一个让我印象很深的坑transformers 版本不能太新。我用过 4.45 以上的版本MiniCPM-o 4.5 的某些模态编码器接口在加载时直接报错来回排查了很久才发现是版本兼容性问题退回 4.42 才稳定。所以如果你的环境是全新的直接按上面的版本号装能少走很多弯路。4.2 模型加载与 LoRA 配置一个最小可用示例模型加载部分面壁官方提供了微调脚本我们基于它做修改。核心逻辑是这样import torch from transformers import AutoModelForCausalLM, AutoProcessor from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training # 以 4-bit 量化加载模型降低显存压力 model AutoModelForCausalLM.from_pretrained( openbmb/MiniCPM-o-4_5, torch_dtypetorch.bfloat16, load_in_4bitTrue, device_mapauto, trust_remote_codeTrue ) processor AutoProcessor.from_pretrained(openbmb/MiniCPM-o-4_5, trust_remote_codeTrue) # 关键冻结量化前的敏感层保留 bf16 精度 from transformers import BitsAndBytesConfig bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_use_double_quantTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.bfloat16 ) model AutoModelForCausalLM.from_pretrained( openbmb/MiniCPM-o-4_5, quantization_configbnb_config, device_mapauto, trust_remote_codeTrue ) # 准备 k-bit 训练 model prepare_model_for_kbit_training(model) # LoRA 配置 lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) model.print_trainable_parameters() # 这里会输出trainable params: 大概 25M只占全模型的 0.3% 左右这个配置的逻辑是LoRA rank 设为 16alpha 设为 32两者比值是 2这是 LoRA 调参中比较常用的默认范围。target_modules 覆盖了注意力层和前馈层因为这两个部分的权重对多模态指令跟随的影响最大。dropout 设 0.05 是为了防止小数据量下过拟合。有人可能会问target_modules 要不要包含多模态编码器我的测试结果是不建议。视觉编码器和音频编码器如果也套 LoRA训练不稳定还容易把预训练学到的模态表征搞坏。保持编码器冻结只训练语言主干是更稳妥的做法。4.3 训练参数与损失收敛完整跑通一遍训练参数方面我用的是一套“保守但可靠”的配置。batch size 为 1梯度累积 8 步等效 batch size 为 8学习率 2e-4采用 cosine 学习率调度训练轮数 3 个 epoch优化器用 AdamW8-bit 版本warmup 比例设为 0.03最大序列长度 2048但多模态样本中图像 token 和音频 token 占用的长度远超文本所以需要开启 packing 或动态拼接。这里有个值得一提的细节多模态训练时单条样本的 token 长度差异非常大纯文本样本可能只有几百 token带图像的样本能到 1500 token带音频的样本甚至能超过 2000。如果直接按最大长度 padding会浪费大量显存。我的做法是开启pad_to_multiple_of8并在 DataCollator 里做动态 padding训练速度能提升 20% 左右。训练脚本的核心部分from transformers import Trainer, TrainingArguments training_args TrainingArguments( output_dir./gander_checkpoints, per_device_train_batch_size1, gradient_accumulation_steps8, learning_rate2e-4, num_train_epochs3, lr_scheduler_typecosine, warmup_ratio0.03, logging_steps10, save_steps500, save_total_limit3, fp16True, # 如果你的显卡支持 bf16更推荐 bf16True report_tonone, )训练过程中我观察到 loss 变化大致是这样的趋势第一个 epoch 开始后不久loss 从 1.6 左右快速下降到 1.0 附近第二个 epoch 缓慢降到 0.7 左右第三个 epoch 基本收敛在 0.6 上下。如果你发现 loss 在 2.0 以上徘徊不下去大概率是数据格式有问题或者模态数据处理环节出了错先检查数据加载不要盲目调学习率。4.4 蒸馏与合并把 LoRA 权重落回模型训练完成后LoRA 权重是独立保存的 adapter 文件。推理阶段有两种选择一是动态加载 adapter二是把 adapter 合并进原模型。双工智能体对响应速度敏感我选择合并后导出。from peft import PeftModel base_model AutoModelForCausalLM.from_pretrained( openbmb/MiniCPM-o-4_5, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue ) lora_model PeftModel.from_pretrained(base_model, ./gander_checkpoints/checkpoint-2400) merged_model lora_model.merge_and_unload() merged_model.save_pretrained(./gander_merged)合并后的模型权重大约比原模型多了几十 MB 的 LoRA 增量推理速度和原模型完全一致非常干净。5. 双工机制实现让 Gander 真正“边听边说”5.1 整体系统设计不用外部拼装靠模型原生能力MiniCPM-o 4.5 支持全双工音频交互这也是它区别于其他多模态模型的地方。在模型层面它能够同时处理输入的音频流和文本指令并以语音或文本方式输出。Gander 的系统设计核心思路是让模型内部的模态对齐来处理对话节奏尽量减少外部管线的干预。整体架构可以拆成四个模块音频输入流麦克风采集 16kHz 单声道音频流按 320ms 一个 chunk 送进系统视觉输入流摄像头以 5fps 的帧率采集图像送入视觉编码器提取特征推理引擎将音频 chunk、图像帧和对话历史拼装成多模态输入交给微调后的模型推理输出控制模型输出的文本通过 TTS 合成语音播放同时支持在用户插话时“暂停回应”。外部干预的环节只有 VAD用于判断用户是否在说话和中断检测用于决定是否暂停当前回复。对话节奏和语义理解全部交给模型本身这是 Gander 和“拼装式智能体”最大的区别。5.2 流式推理与增量解码延迟优化的关键双工体验最核心的指标是“实时性”。如果用户说完话到 AI 回应之间的延迟超过 1.5 秒全双工的体验感就会崩塌。所以推理链路的延迟优化至关重要。我做了两个层面的优化第一个层面是音频流切分。传统的做法是等用户说完一整句才触发识别这会产生固定延迟。Gander 的做法是每 320ms 的音频 chunk 送入模型后立即判断是否有足够的语义信息可以生成回复。模型在感知到用户意图完整时会主动开始解码。这种“边听边想”的模式让响应延迟从传统的 1.2 秒降低到 500ms 左右。第二个层面是推理优化。我使用了torch.compile对模型进行图编译graph compilation推理速度提升了大约 15%。更有效的是把图像编码和音频编码的中间结果缓存起来。对固定场景的摄像头画面来说视觉特征可以做到每 500ms 更新一次而不是每帧都重新编码。音频编码则采用流式窗口重叠计算避免重复编码带来的开销。下面是流式推理的核心伪代码逻辑while True: audio_chunk mic_stream.read(chunk_size320ms) frame camera_stream.read() # 多模态特征提取 audio_features audio_encoder(audio_chunk) visual_features visual_encoder(frame) # 模型推理融合音频 视觉 文本历史 response model.generate( audio_featuresaudio_features, visual_featuresvisual_features, text_historyconversation_history, max_new_tokens64, streamTrue ) if user_interrupts(): model.stop_generation() conversation_history.append(user_interrupted) continue for token in response: tts_speak(token)5.3 打断与恢复全双工体验中“最微妙”的部分全双工和普通的流式语音交互最大的不同是“打断处理”。用户可能在 AI 说话过程中插话模型需要判断是“话题转移”还是“补充信息”从而决定是继续说完还是让出新的话轮。MiniCPM-o 4.5 原生具备一定的打断理解能力但微调让这个能力变得更可控。我在数据集中专门构造了“用户打断 AI 回复”的样本让模型学会在被打断后记录当前的语义位置等用户补充完信息后再从断点继续回应。实现上有两个要点一是打断检测要分级不能像 VAD 那样二元判断。我把用户的插话按能量和语义完整度分成三个等级轻微噪声不打断、试探性插话暂停倾听但保留上下文、明确新指令清空当前回复重新规划。这个分级逻辑放在模型层做而不是放在工程层硬编码。二是上下文拼接。当用户打断后模型需要把被打断前的半句话、用户的新指令、以及视觉场景信息三者融合生成新的回复。这个能力纯粹是微调数据教出来的我给模型喂了一部分“半截回复 用户插话 最终完整回复”的三元组样本训练后模型在被打断场景下的表现提升非常明显。6. 效果评估与排坑实录实测中遇到的和解决的6.1 三类任务的实测表现微调完成后我对 Gander 做了一轮系统评估。评估分为三类任务纯视觉问答、纯语音交互、视觉语音双模态融合交互。每类任务 50 条测试样本人工打分1-5 分结果如下任务类型微调前微调后提升幅度纯视觉问答VQA3.54.20.7纯语音多轮对话3.84.50.7视觉语音双模态交互2.94.31.4全双工打断与恢复2.14.01.9这个结果说明两个问题第一LoRA 微调对单一模态能力的保持和提升是有效的第二双模态融合和全双工这类场景微调带来的收益远超单模态任务。这也印证了一个观点MiniCPM-o 4.5 原厂的通用能力已经够强微调的核心价值在于把模型拉向“特定交互模式”。6.2 训练中的损失震荡多模态任务的一个经典问题训练过程中我遇到过一个比较典型的问题loss 会在某一批数据上突然飙升然后慢慢回落到正常水平。排查后发现是多模态批次拼接不均匀导致的——某些 batch 里全是带长音频的样本token 长度接近上限梯度更新幅度过大。解决方式有两个一是洗牌时按 token 长度做分桶bucket尽量保证同一 batch 内的样本规模相近二是使用梯度裁剪设置max_grad_norm1.0避免极端 batch 造成梯度爆炸。两个措施叠加后loss 曲线平滑了很多。6.3 四比特量化下的性能损失一个容易忽视的暗坑前面提到了 QLoRA 的 4-bit 量化加载可以大幅降低显存需求但量化会带来一个副作用合并 LoRA 权重后模型的推理精度在少数高难度视觉任务上会略低于 bf16。我在实际测试中发现对 OCR 类任务4-bit 合并模型偶尔会出现识别不准的情况。这里有一个实际可行的选择如果业务场景不需要极低显存部署建议在合并 LoRA 后用 bf16 精度重新加载模型把 4-bit 量化仅仅当作训练阶段的省显存手段而不是部署阶段的状态。这样既完成了微调又保住了推理精度。6.4 全双工体验中的三个工程坑第一个坑是“音频回声”。全双工意味着扬声器和麦克风同时工作回声不可避免。如果不做回声消除AEC模型会把自己的输出语音当成用户输入造成无限循环。我的解决方案是在输入管线上加轻量级回声消除模块基于 webrtc 的 AEC 算法处理延迟在 5ms 以内。第二个坑是“视觉帧与音频流的对齐”。当用户指着一个物体说话时视觉帧和语音是同时进入系统的但摄像头帧率和音频 chunk 的粒度不同5fps vs 每 320ms时间戳如果不做对齐模型会看到“过期的画面”。我实现了一个简单的滑动窗口机制让视觉特征始终对应音频 chunk 时间点前后各 100ms 内的最新帧。第三个坑是“半句语义触发”。双工模式下模型可能在用户说了一半时就开始生成回复但如果模型生成太快反而会打断用户。为了让模型学会“等一等”我在训练数据中刻意加入了一部分“用户停顿但语义未完整”的样本期望输出设为模型保持静默或只输出一个简短的“嗯哼”。实测下来这种训练方式明显改善了模型在犹豫和停顿场景下的行为。7. 一些碎碎念把多模态智能体推上线后的真实心得项目做了三个多月从第一行代码到 Gander 真正跑出稳定的全双工效果中间反复打磨了不少轮。最大的体会有三点分享给想上车的朋友。第一别迷恋模型能力而上头微调数据一定是你花时间最多的地方。我前两周大部分时间都耗在数据构建和清洗上训练本身反而是最“顺”的环节。很多人在数据不足时强行开训结果模型只是记住了训练集里的几个固定答案稍微换个说法就崩这种“背题”现象在 LoRA 里尤其明显。第二全双工的终极体验瓶颈不在模型而在交互链路。模型再聪明如果音频采集有回声、帧对齐不准、打断响应迟钝用户感知到的依然是一个“痴呆”的智能体。模型微调只解决“智力”问题工程优化解决“体验”问题两者缺一不可。第三尽可能利用模型原生的多模态能力而不是自己拼装。如果对 MiniCPM-o 4.5 这类“原生全模态”模型的内部机制不够了解最稳妥的方式是先把官方 demo 跑通然后逐层加自定义逻辑。我见过太多项目在一开始就设计了一套复杂的微服务架构把 ASR、LLM、TTS 分开部署结果延迟大增交互体验远不如单模型方案。最后分享一个小技巧如果你也想在 MiniCPM-o 4.5 上做业务场景微调强烈建议先解析官方发布的数据样例严格按照它的格式构造自己的数据哪怕你觉得某些字段多余。因为这类模型在微调时数据格式的微妙差异会直接影响效果而报错信息通常不会告诉你问题出在哪。Gander 目前已经在几个内部测试场景里跑起来了下一步我计划扩展它的视觉记忆能力让它能记住之前“看”过的东西实现更长时间跨度的多模态上下文理解。这条路还在走后续有新的实践结论再来更新。
基于MiniCPM-o 4.5的多模态全双工智能体微调实践
1. 为什么是 MiniCPM-o 4.5多模态双工智能体的选型逻辑先交代一下背景。我一直在做端侧多模态 Agent 相关的项目之前用过不少开源多模态模型但始终有几个痛点在纠缠一是视觉、音频、文本三个模态的模型往往是分开的要做全双工对话就得拼装 ASR、LLM、TTS 三套管线延迟和稳定性很难控二是端侧模型一旦做多模态融合参数量上去了推理速度又拉胯三是即使把模型跑起来了想在业务场景里微调出符合自己需求的效果资料少、坑却特别多。关注面壁智能的 MiniCPM-o 4.5 有一段时间了最初看到它的定位是“新一代多模态模型”支持视觉、音频、文本的任意组合输入输出我当时的第一反应是这种全模态架构如果真的在端侧能跑那对做智能体的人来说是个很大的变量。后来亲眼看到它的全双工语音演示才决定把这个模型作为 Gander 的基座模型。Gander 这个项目的目标很明确在 MiniCPM-o 4.5 的基础上微调出一个具备全双工对话能力的多模态智能体。双工意味着什么最简单的理解是——对话双方可以同时说话AI 不再是你一句我一句的“按键对讲机”而是像真人一样能听、能想、能回应、能在你说话中途插话或者被插话。这种体验上的跨越对智能客服、口语陪练、智能硬件助手这类场景来说是质变。选型的过程其实没有那么复杂我给自己定了几个硬性指标必须是单一模型支持视觉、音频、文本的多模态输入输出而不是三个模型拼装必须能在消费级 GPU 上完成微调项目预算和算力都不允许我用几百张卡去训练全双工语音交互能力是必备项最好是模型原生支持而不是靠外部模块硬凑有社区活跃度有可参考的微调实战案例。对比了一圈之后MiniCPM-o 4.5 确实是当时最贴合这几个要求的开源模型。它不是简单的“视觉模型 语音模型”缝合而是在架构上做了统一的模态建模同时通过 LoRA 这类轻量微调技术给二次开发留了很大的空间。这一点后面会详细展开。对普通读者来说你不需要一上来就理解所有架构细节只需要先建立一个认知MiniCPM-o 4.5 是一个能干“看、听、说、写”四件事的开源多模态模型而 Gander 要做的就是把这些能力通过微调和工程化变成真正能在业务里跑起来的双工智能体。2. 微调方案拆解四个关键技术点决定了 Gander 的成败2.1 全参微调 vs 参数高效微调为什么我选了后者在真正动手之前先得把微调路线想清楚。大模型微调目前常见的有四种方式我梳理了一下基本是这么个递进关系全参微调Full Fine-tuning把所有模型参数都参与训练效果上限最高但显存开销巨大、训练时间长而且对小规模数据容易灾难性遗忘MiniCPM-o 4.5 这种 8B 级别的多模态模型全参微调在单卡上基本不现实适配器微调Adapter在模型层之间插入小型可训练模块冻结原模型训练参数量小但推理时会增加额外的计算延迟对于强调实时性的双工语音场景来说不够友好前缀微调Prompt/Prefix Tuning在输入序列前加一组可学习的虚拟 token改动极小但效果不稳定尤其在多模态任务里很难控制不同模态之间的平衡LoRA 微调Low-Rank Adaptation通过低秩分解矩阵来近似参数更新量只训练新增的小矩阵既保留了原模型的通用能力又能在特定任务上快速收敛。Gander 最终选择的是 LoRA 路线而且用的是它的增强版 QLoRA。为什么最核心的原因是双工智能体这个场景很特殊它要求模型在对话过程中同时处理语音流和视觉流推理链路长、实时性要求高。LoRA 在推理时可以把训练好的低秩矩阵合并回原模型权重不引入任何额外的推理时延这一点对双工体验至关重要。另外还有一个很现实的考虑数据量。Gander 的微调数据并不是百万级的通用语料而是围绕特定业务场景整理的高质量指令数据几千到几万条的量级。在这种中小规模数据集上LoRA 微调比全参微调更稳不容易把模型原有的多模态对齐能力冲掉。2.2 LoRA 的低秩适配原理用“翻译助手”的比喻理解它如果不做技术研究理解 LoRA 可以从一个类比入手。想象你有一本写好的英文原版书预训练模型现在想把它翻译成特定领域的中文微调目标但你又不想把整本书重新写一遍。LoRA 的做法是在旁边放一个小小的“翻译助手”这个助手只学一个低维度的翻译规则把原版书里的关键段落“转译”过去而不是动原版书的任何一页。数学上LoRA 的想法是模型参数更新量 ΔW 虽然维度很高但它的“内在秩”其实很低可以用两个低秩矩阵 A 和 B 的乘积来近似。训练过程中原模型权重 W 保持冻结只有 A 和 B 在更新。实际使用时把 AB 合并回 W模型结构和推理速度都不受影响。具体到 MiniCPM-o 4.5 上它的架构包含视觉编码器、音频编码器和语言模型主干各模块之间存在复杂的对齐关系。直接对所有模块施加 LoRA 并不是最优选择我更推荐的做法是重点在语言模型主干的 attention 层上加 LoRA视觉和音频编码器保持冻结。为什么这样设计因为多模态模型中编码器已经学到了高质量的模态语义表示真正需要被业务数据“重塑”的是语言模型如何理解和推理这些模态信号。2.3 QLoRA 的量化策略在 24G 显存上跑 8B 多模态模型这里延伸讲一下 QLoRA。QLoRA 是在 LoRA 基础上叠加了量化思想把预训练模型以 4-bit 或 8-bit 的精度加载到显存中只对 LoRA 分支保持较高精度训练。效果就是显存占用大幅下降而模型能力基本不损失。MiniCPM-o 4.5 完整加载的显存开销在 16GB 到 20GB 之间加上训练时的梯度、优化器状态和激活值如果不用量化消费级显卡几乎不可能训练。我实际测试下来用 4-bit 量化加载模型配合 LoRA rank16 的配置24GB 显存的 RTX 3090 / 4090 就能稳定跑完整个微调流程batch size 设为 1梯度累积步数设为 8等效 batch size 是 8训练稳定性非常好。这里有一个需要注意的细节量化加载对多模态模型的输入编码有影响。特别是在视觉 token 和音频 token 进入语言主干之后量化误差可能会在某些任务上放大。我的解决方案是量化配置中保留 feed-forward 层的部分参数为 bf16即所谓“量化敏感层豁免”这个操作能明显提升多模态任务的稳定性而显存开销只增加了 1GB 左右。3. 数据是重头戏多模态数据集从哪来、怎么构造3.1 数据获取公开数据集与自建数据的比例控制微调效果的上限很大程度由数据质量决定。MiniCPM-o 4.5 本身在多模态对齐和数据覆盖上已经做得不错所以微调数据的核心目标不是“教它认识世界”而是“教它在你的场景里如何表现”。我用的数据分为三大类通用多模态对话数据包括图像描述、视觉问答VQA、图文推理、音频事件理解等。这类数据用来保持模型的多模态能力不退化占比约 40%。公开来源有 COCO Caption、LLaVA 的指令数据、AudioCaps 等按需采样就行不需要全部拿来训练。场景业务数据这部分是 Gander 的灵魂。我针对智能助手这个场景手工构建了约 3000 条中文多模态指令数据覆盖了用户拿着摄像头拍物体问“这是什么”、发一张图片让 AI 描述并给出建议、语音直接提问并期望语音回答等典型交互。占比约 30%。双工特征数据这是全双工智能体独有的数据形式。除了正常的“用户问—AI 答”之外还需要构造“用户话没说完AI 已经理解意图并给出回应”、“用户说话中途被打断后重新组织语言”之类的交互样本。这部分数据很难公开获取是影响 Gander 体验的关键占比约 30%。三类数据合在一起过滤后大概 8000 条左右对于一个以 LoRA 方式微调的项目来说这个量级是合理的。数据规模不是越大越好关键是覆盖面和数据质量。3.2 数据清洗与格式转换一个容易翻车的环节多模态微调的数据格式比纯文本微调复杂得多因为每条样本可能同时包含图像、音频和文本三种模态。MiniCPM-o 4.5 的输入格式有明确规范我踩过的坑是不同来源数据的采样率不一致。音频部分模型要求 16kHz 采样率的单声道 WAV而很多公开数据集是 22.05kHz 或 44.1kHz。光做重采样还不够响度归一化peak normalization也很重要否则训练时同一批数据里音量忽大忽小模型会困惑。我统一用 ffmpeg 做了批处理重采样到 16kHz、转单声道、归一化到 -1.0dBFS。视觉部分图片不需要统一尺寸MiniCPM-o 4.5 的视觉编码器会做自适应处理但要注意图片格式最好是 RGB 三通道透明度通道会导致编码异常。有少数数据集的图片是 RGBA训练时 loss 倒不会崩但生成效果会间歇性出问题这个很难排查。指令格式上我参考了 MiniCPM-o 4.5 官方微调脚本中推荐的对话模板每条数据构造如下{ messages: [ {role: user, content: [ {type: image, image: path/to/image.jpg}, {type: audio, audio: path/to/audio.wav}, {type: text, text: 请帮我看看这个物品是什么} ]}, {role: assistant, content: [ {type: text, text: 从图片来看这是一个机械键盘它的键帽配色是白蓝相间……} ]} ] }在构造数据时一定要带着“真实交互”的视角去写而不是堆模板。比如智能助手场景里用户不会一板一眼地说“请描述图片内容”而是更口语化的表述。这些口语化变体要主动构造进去否则微调出来的模型在真实对话中会很“僵硬”。3.3 双工数据的三段式结构全双工交互最独特的地方在于AI 的回应往往发生在用户说话结束之前或同时。为了让模型学会这种能力我把双工数据形式化为“三段式”结构第一段是用户的部分语音输入比如“你能不能帮我看看这个——”第二段是用户的完整语音输入或补充输入“——这个螺丝的型号”第三段才是 AI 的完整回复。在训练中模型需要学习的是当语音流还未完全结束时多模态特征已经充分激活可以提前触发推理。这种数据构造方式需要人工精心标注和剪辑也是 Gander 项目最耗时的一部分。但如果没有这一步全双工就只剩一个空壳。很多人问全双工的“提前回应”为什么不让工程层做比如通过 VAD语音活动检测判断用户停顿就触发回复我的经验是只靠 VAD 不够。因为真实对话中停顿的原因很多有的是思考有的是语气延宕如果一停顿就触发回复体验反而很糟糕。模型原生学会“听完再回 / 没听完就回”的判别是更优雅的方案也是把双工能力沉淀在模型权重里而不是写死在代码里的关键。4. 微调实操从环境搭建到损失收敛的完整过程4.1 环境准备与依赖安装一天搞定的“顺手”过程先说环境。我用的是一台单卡 RTX 409024GB 显存64GB 内存Ubuntu 22.04CUDA 12.1。理论上 3090 也能跑只是慢一些。Python 环境建议直接用 conda 新建一个独立环境Python 版本选 3.10 就好。核心依赖如下conda create -n gander python3.10 -y conda activate gander # 安装 PyTorch根据你的 CUDA 版本选择对应命令 pip install torch2.3.0 torchvision0.18.0 torchaudio2.3.0 --index-url https://download.pytorch.org/whl/cu121 # 安装 transformers 与 accelerate注意版本兼容性 pip install transformers4.42.0 accelerate0.30.0 # 安装 peftLoRA 微调的核心库 pip install peft0.10.0 # 安装 bitsandbytesQLoRA 量化需要 pip install bitsandbytes0.43.0 # 安装 deepspeed可选用于加速 pip install deepspeed0.13.2这里有一个让我印象很深的坑transformers 版本不能太新。我用过 4.45 以上的版本MiniCPM-o 4.5 的某些模态编码器接口在加载时直接报错来回排查了很久才发现是版本兼容性问题退回 4.42 才稳定。所以如果你的环境是全新的直接按上面的版本号装能少走很多弯路。4.2 模型加载与 LoRA 配置一个最小可用示例模型加载部分面壁官方提供了微调脚本我们基于它做修改。核心逻辑是这样import torch from transformers import AutoModelForCausalLM, AutoProcessor from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training # 以 4-bit 量化加载模型降低显存压力 model AutoModelForCausalLM.from_pretrained( openbmb/MiniCPM-o-4_5, torch_dtypetorch.bfloat16, load_in_4bitTrue, device_mapauto, trust_remote_codeTrue ) processor AutoProcessor.from_pretrained(openbmb/MiniCPM-o-4_5, trust_remote_codeTrue) # 关键冻结量化前的敏感层保留 bf16 精度 from transformers import BitsAndBytesConfig bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_use_double_quantTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.bfloat16 ) model AutoModelForCausalLM.from_pretrained( openbmb/MiniCPM-o-4_5, quantization_configbnb_config, device_mapauto, trust_remote_codeTrue ) # 准备 k-bit 训练 model prepare_model_for_kbit_training(model) # LoRA 配置 lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) model.print_trainable_parameters() # 这里会输出trainable params: 大概 25M只占全模型的 0.3% 左右这个配置的逻辑是LoRA rank 设为 16alpha 设为 32两者比值是 2这是 LoRA 调参中比较常用的默认范围。target_modules 覆盖了注意力层和前馈层因为这两个部分的权重对多模态指令跟随的影响最大。dropout 设 0.05 是为了防止小数据量下过拟合。有人可能会问target_modules 要不要包含多模态编码器我的测试结果是不建议。视觉编码器和音频编码器如果也套 LoRA训练不稳定还容易把预训练学到的模态表征搞坏。保持编码器冻结只训练语言主干是更稳妥的做法。4.3 训练参数与损失收敛完整跑通一遍训练参数方面我用的是一套“保守但可靠”的配置。batch size 为 1梯度累积 8 步等效 batch size 为 8学习率 2e-4采用 cosine 学习率调度训练轮数 3 个 epoch优化器用 AdamW8-bit 版本warmup 比例设为 0.03最大序列长度 2048但多模态样本中图像 token 和音频 token 占用的长度远超文本所以需要开启 packing 或动态拼接。这里有个值得一提的细节多模态训练时单条样本的 token 长度差异非常大纯文本样本可能只有几百 token带图像的样本能到 1500 token带音频的样本甚至能超过 2000。如果直接按最大长度 padding会浪费大量显存。我的做法是开启pad_to_multiple_of8并在 DataCollator 里做动态 padding训练速度能提升 20% 左右。训练脚本的核心部分from transformers import Trainer, TrainingArguments training_args TrainingArguments( output_dir./gander_checkpoints, per_device_train_batch_size1, gradient_accumulation_steps8, learning_rate2e-4, num_train_epochs3, lr_scheduler_typecosine, warmup_ratio0.03, logging_steps10, save_steps500, save_total_limit3, fp16True, # 如果你的显卡支持 bf16更推荐 bf16True report_tonone, )训练过程中我观察到 loss 变化大致是这样的趋势第一个 epoch 开始后不久loss 从 1.6 左右快速下降到 1.0 附近第二个 epoch 缓慢降到 0.7 左右第三个 epoch 基本收敛在 0.6 上下。如果你发现 loss 在 2.0 以上徘徊不下去大概率是数据格式有问题或者模态数据处理环节出了错先检查数据加载不要盲目调学习率。4.4 蒸馏与合并把 LoRA 权重落回模型训练完成后LoRA 权重是独立保存的 adapter 文件。推理阶段有两种选择一是动态加载 adapter二是把 adapter 合并进原模型。双工智能体对响应速度敏感我选择合并后导出。from peft import PeftModel base_model AutoModelForCausalLM.from_pretrained( openbmb/MiniCPM-o-4_5, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue ) lora_model PeftModel.from_pretrained(base_model, ./gander_checkpoints/checkpoint-2400) merged_model lora_model.merge_and_unload() merged_model.save_pretrained(./gander_merged)合并后的模型权重大约比原模型多了几十 MB 的 LoRA 增量推理速度和原模型完全一致非常干净。5. 双工机制实现让 Gander 真正“边听边说”5.1 整体系统设计不用外部拼装靠模型原生能力MiniCPM-o 4.5 支持全双工音频交互这也是它区别于其他多模态模型的地方。在模型层面它能够同时处理输入的音频流和文本指令并以语音或文本方式输出。Gander 的系统设计核心思路是让模型内部的模态对齐来处理对话节奏尽量减少外部管线的干预。整体架构可以拆成四个模块音频输入流麦克风采集 16kHz 单声道音频流按 320ms 一个 chunk 送进系统视觉输入流摄像头以 5fps 的帧率采集图像送入视觉编码器提取特征推理引擎将音频 chunk、图像帧和对话历史拼装成多模态输入交给微调后的模型推理输出控制模型输出的文本通过 TTS 合成语音播放同时支持在用户插话时“暂停回应”。外部干预的环节只有 VAD用于判断用户是否在说话和中断检测用于决定是否暂停当前回复。对话节奏和语义理解全部交给模型本身这是 Gander 和“拼装式智能体”最大的区别。5.2 流式推理与增量解码延迟优化的关键双工体验最核心的指标是“实时性”。如果用户说完话到 AI 回应之间的延迟超过 1.5 秒全双工的体验感就会崩塌。所以推理链路的延迟优化至关重要。我做了两个层面的优化第一个层面是音频流切分。传统的做法是等用户说完一整句才触发识别这会产生固定延迟。Gander 的做法是每 320ms 的音频 chunk 送入模型后立即判断是否有足够的语义信息可以生成回复。模型在感知到用户意图完整时会主动开始解码。这种“边听边想”的模式让响应延迟从传统的 1.2 秒降低到 500ms 左右。第二个层面是推理优化。我使用了torch.compile对模型进行图编译graph compilation推理速度提升了大约 15%。更有效的是把图像编码和音频编码的中间结果缓存起来。对固定场景的摄像头画面来说视觉特征可以做到每 500ms 更新一次而不是每帧都重新编码。音频编码则采用流式窗口重叠计算避免重复编码带来的开销。下面是流式推理的核心伪代码逻辑while True: audio_chunk mic_stream.read(chunk_size320ms) frame camera_stream.read() # 多模态特征提取 audio_features audio_encoder(audio_chunk) visual_features visual_encoder(frame) # 模型推理融合音频 视觉 文本历史 response model.generate( audio_featuresaudio_features, visual_featuresvisual_features, text_historyconversation_history, max_new_tokens64, streamTrue ) if user_interrupts(): model.stop_generation() conversation_history.append(user_interrupted) continue for token in response: tts_speak(token)5.3 打断与恢复全双工体验中“最微妙”的部分全双工和普通的流式语音交互最大的不同是“打断处理”。用户可能在 AI 说话过程中插话模型需要判断是“话题转移”还是“补充信息”从而决定是继续说完还是让出新的话轮。MiniCPM-o 4.5 原生具备一定的打断理解能力但微调让这个能力变得更可控。我在数据集中专门构造了“用户打断 AI 回复”的样本让模型学会在被打断后记录当前的语义位置等用户补充完信息后再从断点继续回应。实现上有两个要点一是打断检测要分级不能像 VAD 那样二元判断。我把用户的插话按能量和语义完整度分成三个等级轻微噪声不打断、试探性插话暂停倾听但保留上下文、明确新指令清空当前回复重新规划。这个分级逻辑放在模型层做而不是放在工程层硬编码。二是上下文拼接。当用户打断后模型需要把被打断前的半句话、用户的新指令、以及视觉场景信息三者融合生成新的回复。这个能力纯粹是微调数据教出来的我给模型喂了一部分“半截回复 用户插话 最终完整回复”的三元组样本训练后模型在被打断场景下的表现提升非常明显。6. 效果评估与排坑实录实测中遇到的和解决的6.1 三类任务的实测表现微调完成后我对 Gander 做了一轮系统评估。评估分为三类任务纯视觉问答、纯语音交互、视觉语音双模态融合交互。每类任务 50 条测试样本人工打分1-5 分结果如下任务类型微调前微调后提升幅度纯视觉问答VQA3.54.20.7纯语音多轮对话3.84.50.7视觉语音双模态交互2.94.31.4全双工打断与恢复2.14.01.9这个结果说明两个问题第一LoRA 微调对单一模态能力的保持和提升是有效的第二双模态融合和全双工这类场景微调带来的收益远超单模态任务。这也印证了一个观点MiniCPM-o 4.5 原厂的通用能力已经够强微调的核心价值在于把模型拉向“特定交互模式”。6.2 训练中的损失震荡多模态任务的一个经典问题训练过程中我遇到过一个比较典型的问题loss 会在某一批数据上突然飙升然后慢慢回落到正常水平。排查后发现是多模态批次拼接不均匀导致的——某些 batch 里全是带长音频的样本token 长度接近上限梯度更新幅度过大。解决方式有两个一是洗牌时按 token 长度做分桶bucket尽量保证同一 batch 内的样本规模相近二是使用梯度裁剪设置max_grad_norm1.0避免极端 batch 造成梯度爆炸。两个措施叠加后loss 曲线平滑了很多。6.3 四比特量化下的性能损失一个容易忽视的暗坑前面提到了 QLoRA 的 4-bit 量化加载可以大幅降低显存需求但量化会带来一个副作用合并 LoRA 权重后模型的推理精度在少数高难度视觉任务上会略低于 bf16。我在实际测试中发现对 OCR 类任务4-bit 合并模型偶尔会出现识别不准的情况。这里有一个实际可行的选择如果业务场景不需要极低显存部署建议在合并 LoRA 后用 bf16 精度重新加载模型把 4-bit 量化仅仅当作训练阶段的省显存手段而不是部署阶段的状态。这样既完成了微调又保住了推理精度。6.4 全双工体验中的三个工程坑第一个坑是“音频回声”。全双工意味着扬声器和麦克风同时工作回声不可避免。如果不做回声消除AEC模型会把自己的输出语音当成用户输入造成无限循环。我的解决方案是在输入管线上加轻量级回声消除模块基于 webrtc 的 AEC 算法处理延迟在 5ms 以内。第二个坑是“视觉帧与音频流的对齐”。当用户指着一个物体说话时视觉帧和语音是同时进入系统的但摄像头帧率和音频 chunk 的粒度不同5fps vs 每 320ms时间戳如果不做对齐模型会看到“过期的画面”。我实现了一个简单的滑动窗口机制让视觉特征始终对应音频 chunk 时间点前后各 100ms 内的最新帧。第三个坑是“半句语义触发”。双工模式下模型可能在用户说了一半时就开始生成回复但如果模型生成太快反而会打断用户。为了让模型学会“等一等”我在训练数据中刻意加入了一部分“用户停顿但语义未完整”的样本期望输出设为模型保持静默或只输出一个简短的“嗯哼”。实测下来这种训练方式明显改善了模型在犹豫和停顿场景下的行为。7. 一些碎碎念把多模态智能体推上线后的真实心得项目做了三个多月从第一行代码到 Gander 真正跑出稳定的全双工效果中间反复打磨了不少轮。最大的体会有三点分享给想上车的朋友。第一别迷恋模型能力而上头微调数据一定是你花时间最多的地方。我前两周大部分时间都耗在数据构建和清洗上训练本身反而是最“顺”的环节。很多人在数据不足时强行开训结果模型只是记住了训练集里的几个固定答案稍微换个说法就崩这种“背题”现象在 LoRA 里尤其明显。第二全双工的终极体验瓶颈不在模型而在交互链路。模型再聪明如果音频采集有回声、帧对齐不准、打断响应迟钝用户感知到的依然是一个“痴呆”的智能体。模型微调只解决“智力”问题工程优化解决“体验”问题两者缺一不可。第三尽可能利用模型原生的多模态能力而不是自己拼装。如果对 MiniCPM-o 4.5 这类“原生全模态”模型的内部机制不够了解最稳妥的方式是先把官方 demo 跑通然后逐层加自定义逻辑。我见过太多项目在一开始就设计了一套复杂的微服务架构把 ASR、LLM、TTS 分开部署结果延迟大增交互体验远不如单模型方案。最后分享一个小技巧如果你也想在 MiniCPM-o 4.5 上做业务场景微调强烈建议先解析官方发布的数据样例严格按照它的格式构造自己的数据哪怕你觉得某些字段多余。因为这类模型在微调时数据格式的微妙差异会直接影响效果而报错信息通常不会告诉你问题出在哪。Gander 目前已经在几个内部测试场景里跑起来了下一步我计划扩展它的视觉记忆能力让它能记住之前“看”过的东西实现更长时间跨度的多模态上下文理解。这条路还在走后续有新的实践结论再来更新。