开源多模态模型怎么选不踩坑：许可证、本地部署与微调评测实战指南

我接触开源多模态模型是从一个很具体的需求开始的：手里有一批商品图，想批量生成描述，还要能回答用户关于图片细节的问题。当时第一反应是找现成的API，算完账发现量大之后成本压不住，数据也不能随便往外传。后来就把目光转向了开源模型。这一章我想把自己踩过的坑和梳理出来的判断框架讲清楚，算是给后面几章做个铺垫。

1.1 多模态模型的定义与核心能力边界

多模态模型，说直白一点，就是能同时处理两种以上信息形态的模型。最常见的组合是“图+文”：你给它一张图片和一段文字问题，它输出文字答案。也有“文+图”反向生成的，比如给一句话生成一张图。再往宽了走，还有音频、视频、表格、文档版面这些模态。我自己的理解是，多模态模型的核心不在于“能看”，而在于“能把不同模态的信息对齐到同一个语义空间里”。这句话听起来有点抽象，落到实际体验上就是：模型看到一张冰箱贴的照片，能理解上面写的是“记得买牛奶”，还能接着回答“这个冰箱贴是什么颜色”。

能力边界这件事需要提前说清楚，不然选型很容易跑偏。图文理解模型擅长描述、问答、OCR、图表解读，它不擅长凭空生成像素级图像。生成模型擅长出图，它对图像内容的逻辑推理往往不如理解模型。视频理解模型能抽帧分析动作和场景，它对长视频的时序理解仍有明显短板。我见过不少团队把生成模型拿去做文档问答，效果不理想，问题不在模型本身，在任务和模型能力没对上。

还有一点容易被忽略：多模态模型的“模态覆盖”不等于“模态精通”。一个模型号称支持图文、音频、视频，实际用下来可能只有图文部分能用，音频和视频只是勉强跑通。我的做法是拿到模型先做小样本压力测试，别只看模型卡上的宣传语。测试样本要覆盖真实业务里的脏数据：模糊图、旋转图、带水印的图、多栏排版的文档截图。这些样本最能暴露能力边界。

1.2 开源多模态模型的价值：可控性、成本、隐私与二次开发

我用开源模型最直接的动力是可控性。闭源API的版本说变就变，提示词模板、返回格式、限流策略都可能在某次更新后不一样。业务系统依赖这些接口，稳定性就成了被动的事。开源模型下载到本地之后，推理服务的版本由我自己锁，模型权重不动，输出行为就不会莫名其妙地漂移。这种确定性对生产环境太重要了。

成本这块要算总账，不能只比单次调用价格。开源模型的显存占用、运维人力、推理优化投入都是成本。我的经验是，请求量达到一定规模之后，本地部署的边际成本优势会很明显，尤其是需要批量跑图、跑文档的场景。量小的时候用API更省事，这一点没必要硬扛。我一般会做一个简单的盈亏平衡测算：把GPU租用或采购成本、电费、运维时间折算进去，再看每天的实际请求量。

隐私和合规是另一条硬价值。医疗影像、合同扫描件、用户上传的身份证照片，这些数据出域的风险很高。开源模型允许数据留在内网，推理链路可以审计，日志可以自己控制。二次开发的空间也大：可以改tokenizer、加视觉编码器、接自己的检索模块、做领域微调。闭源API很难让你动这些底层的东西。我做过一个票据识别项目，通用模型对特定版式的字段抽取总差一口气，后来在开源模型上做了一轮LoRA微调，准确率才拉上来。

1.3 开源许可证与商用合规初筛

许可证这件事，我建议在下载权重之前就看，别等模型跑通了才发现商用受限。常见的开源许可证里，Apache 2.0和MIT相对宽松，商用障碍小。Llama系列有自己的社区许可证，用户规模超过一定阈值需要额外申请。还有一些模型标注“仅限研究用途”，这种就不能直接拿去做商业产品。我见过团队把研究许可的权重打进SaaS产品，后来被迫换模型，返工成本很高。

模型卡里的许可证信息要逐字读，不能只看GitHub仓库首页的徽章。有些项目权重和代码是两套许可，代码是Apache 2.0，权重可能是另一份协议。数据集许可也要留意，训练数据来源不清的模型，商用风险会更高。我的习惯是建一个简单的合规表格：模型名、许可证类型、商用是否允许、是否需要署名、是否有用户规模限制、权重和代码许可是否一致。这张表在选型初期就能筛掉一批不适合的候选。

许可证之外还有一层是输出内容的合规。开源模型生成的内容由部署方负责，平台审核、敏感词过滤、日志留存这些工作不能省。我一般会在推理服务前面加一层内容安全网关，模型输出先过一遍规则和分类器，再返回给业务方。这件事和模型选型是并行的，别等到上线前才补。

1.4 选型评估维度：模态覆盖、参数规模、上下文长度、推理成本、中文能力、社区活跃度

选型这件事我习惯拆成几个可比较的维度，不然很容易被单一指标带偏。模态覆盖放在第一位，先确认模型支持的任务类型和你的业务是否匹配。图文理解、图文生成、视频理解、音频转写，这些能力差异很大，别指望一个模型全包。参数规模要和部署条件一起看，7B级别的模型在单张消费级显卡上能跑，70B级别就需要多卡或者量化方案。参数大不代表业务效果好，我见过小模型在垂直场景微调后超过大模型通用表现的情况。

上下文长度对文档类场景很关键。多页PDF、长图、带表格的扫描件，输入长度不够就只能截断，截断就会丢信息。推理成本要按实际吞吐算，不能只看模型参数量。量化版本、批处理大小、是否用vLLM这类推理框架，都会明显影响每千token的成本。中文能力需要单独测，很多英文榜单靠前的模型，中文问答和中文OCR的稳定性会掉一截。我的测试集里一定会有中文手写体、中文表格、中文菜单这类样本。

社区活跃度是一个软指标，实际影响不小。issue响应速度、模型更新频率、有没有人维护量化版本、教程是否跟得上，这些决定了你遇到问题时的排错效率。我一般会看Hugging Face上的下载量、最近三个月的提交记录、ModelScope上的中文文档完整度。一个模型再强，社区冷清，部署踩坑时连个参考都没有，时间成本会很高。

1.5 全文结构与阅读路径：从“有哪些”到“如何本地部署”

这篇内容我按三条线来组织，读的时候可以按需跳转。第二章回答“开源多模态模型有哪些”，把主流模型按模态组合、参数规模、生态来源做分类盘点。第三章讲本地部署，从环境准备、权重下载、推理框架选择到排错，尽量给可复现的步骤。第四章落到选型、应用和生态趋势，讲场景匹配、成本合规、微调评测和上线监控。三章之间是递进关系，先知道有什么，再知道怎么跑起来，最后知道怎么选、怎么用。

如果你时间紧，我的建议是先看1.4的评估维度和第二章的模型分类，快速圈定两三个候选，再跳到第三章跑最小推理示例。部署跑通之后回头读第四章的场景匹配和评测方法，避免一上来就陷进参数对比。如果你已经在做技术选型，可以直接看1.3的许可证初筛和4.2的成本合规评估，这两块最容易在后期变成返工点。

阅读过程中我会尽量保留第一人称的操作细节，包括具体的命令、显存数字、报错信息和踩坑记录。这些内容比单纯的模型介绍更有用。开源多模态模型这个领域更新很快，今天好用的模型半年后可能就被替代，我更希望你把这本书当成一套判断方法，而不是一份固定的模型清单。

上一章聊完选型框架，这一章我把视线落到具体模型上。我刚开始接触这块的时候，面对Hugging Face上一大堆名字，完全不知道该从哪个下手。后来我按自己的使用习惯做了几轮梳理，把模型按几个不同角度分了分类。这一章就把我自己的分类方式分享出来，不追求枚举所有模型，重点是把格局看清楚。

2.1 按模态组合分类：图文理解、图文生成、音视频理解、全模态统一模型

模态组合这个分类维度最直观，也是我拿到一个新模型最先看的一点。图文理解是当前开源生态里最成熟的一类，主要处理图像描述、视觉问答、OCR、图表解读这些任务。你给它一张图加一段问题，它输出文字。这类模型数量最多，迭代也最快。图文生成走的是反方向，输入文字生成图像，Stable Diffusion系列和Flux系列是典型代表，它们在创意设计、营销素材生成里用得很多。

音视频理解是另一个分支，处理音频转写、视频内容分析、动作识别这些场景。这类开源模型相对少一些，成熟度也比图文理解低，长视频的时序理解目前还是个瓶颈。全模态统一模型是最近一年的热门方向，一个模型同时支持图文理解、语音输入甚至视频，Qwen2.5-Omni就是我在实验里跑过的一个。我的感受是这类统一模型概念很好，实际使用时各模态的表现不太均衡，往往图文部分最稳，音频和视频还在追赶。

我建议在选型时先明确自己需要哪种模态组合，不要被“全模态”这个词带跑。你如果业务里九成是图文任务，找一个图文理解强的模型远比找一个号称全能的模型靠谱。我测试过一个统一模型，图文问答没问题，一上视频就频繁丢帧，最后只能换回专用的视频理解模型。

2.2 视觉语言理解代表模型盘点：LLaVA、Qwen-VL、InternVL、MiniCPM-V、CogVLM等

视觉语言理解这条线上，LLaVA是我最早跑通的模型之一。它的架构思路很清晰，视觉编码器接一个投影层连到语言模型上，社区生态也比较活跃，各种衍生版本和微调教程很多。我拿LLaVA-1.5做过一个商品图描述的试验，7B版本在单张24G显存的卡上跑得挺顺，输出质量对通用场景够用。它的问题是中文能力一般，直接拿来做中文OCR或者中文表格理解，效果会明显打折。

Qwen-VL系列是我在中文场景里用得最多的。Qwen2-VL和Qwen2.5-VL对中文文档、表格、手写体的识别稳定性比英文主导的模型好不少。我做过一个票据字段抽取的对比测试，Qwen2-VL在中文发票上的字段命中率比同参数规模的LLaVA高出不少。InternVL系列在参数规模上覆盖很全，从2B到70B以上都有，学术评测成绩经常排在前面，工程化做得也不错。我试过InternVL2-8B做多栏PDF的版面理解，表格还原的效果让我比较满意。

MiniCPM-V在端侧部署这个方向有特色，参数小，量化之后在消费级显卡甚至手机端能跑。我拿MiniCPM-V 2.6在笔记本上做过离线图片问答，响应速度可以接受，适合对隐私要求高、不想走网络的场景。CogVLM系列在视觉定位和精细理解上有自己的优势，它把视觉特征和语言模型结合的方式比较特别，对“图中某个坐标区域是什么”这类问题处理得不错。我在一个工业质检的项目里试过CogVLM做缺陷区域描述，效果比通用模型更有针对性。

这些模型我列一个自己的印象对比，方便快速定位：

2.3 多模态生成与统一模型代表：Stable Diffusion、Flux、Qwen2.5-Omni等方向

生成这条线上，Stable Diffusion是我最早接触的开源视觉生成模型。SD 1.5和SDXL的生态非常厚，LoRA微调、ControlNet控制、各种WebUI工具链都很成熟。我做电商背景图生成的时候，SDXL加上一个风格LoRA，基本能覆盖大部分需求。Flux是最近一年受到很多关注的模型，生成质量和提示词遵循度比SDXL又上了一个台阶，对显存的要求也更高。我试过Flux.1 dev版本，24G显存跑起来偏紧，量化之后才顺畅一些。

Qwen2.5-Omni走的是统一模型路线，文本、图像、音频、视频都能处理，输出也支持文本和语音。我在一个客服质检的场景里试过它做语音加文本的联合理解，能把通话录音转写之后结合上下文做意图判断，省掉了中间拼接多个模型的麻烦。它的视频理解能力我测试下来一般，处理短视频片段还行，长视频会丢细节。统一模型现在的状态是“什么都能做一点，但单项不一定最强”，适合任务类型杂、不想维护多套模型的团队。

我自己的判断是生成模型和理解模型在架构和目标上差别很大，短期内很难有一个开源模型在这两个方向都做到顶尖。选型的时候把“理解”和“生成”分开考虑，比追求一个全能模型更实际。

2.4 按参数规模与部署门槛分类：端侧轻量、中等通用、大规模高性能

参数规模直接决定部署门槛，我习惯按显存需求分成三档。端侧轻量档大概是0.5B到4B这个区间，量化之后在8G显存甚至手机端能跑。MiniCPM-V、Qwen2-VL-2B、InternVL2-2B都属于这一档。我做离线文档扫描加问答的原型时，用2B级别的模型在笔记本上跑，虽然精度有限，但验证流程足够了。

中等通用档大概在7B到13B，单张24G显卡加上量化基本能跑起来，这也是大多数团队起步的首选区间。Qwen2-VL-7B、InternVL2-8B、LLaVA-1.5-7B都在这一档。我自己的实验环境就是一张24G卡，这个区间的模型跑起来最舒服，批处理大小调到4到8之间，吞吐和延迟比较平衡。

大规模高性能档在30B以上，需要多卡或者A100/H100级别的硬件。InternVL2-40B、Qwen2-VL-72B属于这一档。我在一个文档理解项目里租过多卡跑72B版本，效果确实比7B版本好，尤其是复杂表格和长文档的推理，但推理成本要按多卡来算，小团队长期跑不太现实。我的建议是先用中等档跑通业务验证，确认效果瓶颈确实来自模型规模，再考虑上大模型。

2.5 按生态来源分类：Hugging Face、ModelScope、国产开源社区与高校项目

生态来源这个维度影响的是你获取模型和排错的便利程度。Hugging Face是模型最全的地方，几乎所有主流开源模型都会在上面发权重，模型卡、讨论区、量化版本都比较完整。我下载模型权重基本首选HF，但国内访问有时候不稳定，需要配镜像。

ModelScope上的中文模型覆盖很好，Qwen系列、InternVL系列、MiniCPM系列在上面都有官方页面，中文文档和示例代码比HF上的英文说明更贴合国内开发者的习惯。我调试Qwen-VL的时候，ModelScope上的教程帮我省了不少时间，尤其是处理器配置那块。

国产开源社区和高校项目也贡献了不少有意思的模型。智谱的CogVLM、CogAgent系列，上海AI Lab的InternVL系列，面壁的MiniCPM系列，背后都有比较活跃的团队在维护。高校项目里也有一些视觉语言方向的模型，学术创新点不错，工程成熟度和文档完整度参差不齐。我用高校项目模型的时候会先看最近半年的提交记录和issue回复情况，冷门项目排错基本靠自己读源码。

2.6 快速检索与跟踪方法：模型榜单、评测基准、论文与社区教程

模型更新太快，我没办法记住每个模型的最新版本。我的做法是固定看几个信息源。OpenCompass和LMSYS的榜单我每周扫一眼，主要看视觉语言和全模态方向的新模型排名变化。榜单不能全信，但能快速发现值得关注的候选。Hugging Face的Trending页面我也会偶尔翻，看看社区在讨论什么。

评测基准方面，MMMU、DocVQA、TextVQA这几个是我比较常看的，分别对应综合推理、文档理解和场景文字理解。我还会看模型卡里报告的评测数字，但不会直接拿来做决策，因为测试集和真实业务数据的分布差异往往很大。我自己的习惯是拿业务样本做一个小型测试集，跑一遍候选模型，看实际表现。

论文和社区教程是排错时的重要参考。arXiv上搜模型名加技术报告，能了解架构设计和训练数据的大致情况。GitHub仓库的README和issue区是我遇到部署问题最先翻的地方，很多时候别人已经踩过同样的坑。中文教程我会在ModelScope的社区和知乎上找，有些博主写的部署记录比官方文档还详细。这套跟踪方法不复杂，关键是保持固定的信息摄入节奏，别等到选型时才临时抱佛脚。 from transformers import AutoProcessor, AutoModelForVision2Seq from PIL import Image

processor = AutoProcessor.from_pretrained("Qwen/Qwen2-VL-7B-Instruct") model = AutoModelForVision2Seq.from_pretrained(

"Qwen/Qwen2-VL-7B-Instruct", torch_dtype="auto", device_map="auto"

)

image = Image.open("test.png") messages = [{"role": "user", "content": [

{"type": "image"}, {"type": "text", "text": "图中表格第三行第二列是什么数值？"}

]}] text = processor.apply_chat_template(messages, add_generation_prompt=True) inputs = processor(text=[text], images=[image], return_tensors="pt").to(model.device) output = model.generate(**inputs, max_new_tokens=128, do_sample=False) print(processor.batch_decode(output[:, inputs.input_ids.shape[1]:], skip_special_tokens=True)[0])

前两章把模型和部署都过了一遍，这一章聊点更实际的事：怎么把一个开源多模态模型真正用起来。我自己踩过最深的坑不在代码层面，而是在选型和落地流程上，模型跑通了但选错了方向，或者评估做得马虎，上线之后问题一堆。这章按从场景到趋势的顺序，把我在这条链路上的经验整理一下。

4.1 场景匹配选型：文档理解、视觉问答、内容审核、电商图文、教育辅助与无障碍应用

选型这件事我现在的做法是先看场景再挑模型，而不是拿着模型列表一个个试。文档理解是我接触最多的场景，票据、合同、报表这类图像对文字识别精度和版面理解要求高，我一般优先测InternVL和Qwen-VL系列，它们的文档训练数据比较充分，表格和密集文字的还原度更好。试的时候别只看清晰扫描件，拿手机拍的、有折痕的、光照不均的样本一起测，真实场景的退化比预想严重得多。

视觉问答场景的选型逻辑不太一样。通用图像问答对世界知识要求高，LLaVA这类在英文VQA基准上表现好的模型有优势，但中文场景我更倾向Qwen2-VL或MiniCPM-V。内容审核这类任务我踩过一个坑，一开始拿通用模型直接做违规图片识别，召回率一直上不去，后来换了在审核数据上微调过的模型，效果才明显改善。电商图文是个复合场景，既要理解商品图，又要读懂标题和详情页文案，我建议选上下文长度够大的模型，长文案和商品图的联合理解对上下文消耗不小。

教育辅助和无障碍应用是我觉得很有价值的两个方向。教育场景里解题类任务对推理链要求高，我用过Qwen2.5-VL做数学题解析，把题目图和文字一起输入，让它分步推导，效果比单问答案好不少。无障碍应用比如给视障用户描述图片内容，对模型的描述细腻度和中文流畅度要求高，我实测下来Qwen系列在中文描述的自然度上更占优。这类场景还有一个隐性要求是响应速度，端侧或轻量模型在延迟上更有优势，选型时要把推理时间和准确率放到一起权衡。

4.2 成本与合规评估：推理成本、数据隐私、商用限制、审计与模型溯源

成本这块我踩过一次教训。早期做项目时只算了模型权重和显卡的钱，上线之后才发现推理成本和调用量是线性增长的，并发一上来，单卡根本扛不住。我现在的做法是先用真实业务样本做一次压力估算，算清楚单次推理的token消耗和平均耗时，再反推需要多少卡、单次成本大概多少。量化版本能显著压低成本，但精度损失要提前评估，我一般会做一版4bit和一版fp16的对比，看业务指标差值能不能接受。

数据隐私是另一个容易忽略的点。做医疗、金融这类敏感行业的时候，我坚持本地部署，权重和数据都不出内网。有些团队图省事直接用云端API，数据合规上风险很大，尤其是涉及用户身份信息的图像。本地部署也有隐私细节，日志里别存原始图像，推理过程的中间结果及时清理，这些看起来是小事，审计的时候都是要查的。

商用限制这块我吃过一次亏。项目早期用了一个CC-BY-NC的模型做原型，效果很好，团队差点直接推到生产，后来法务提醒才发现这个许可证不允许商用。现在的流程是模型初筛阶段就把license字段过一遍，Apache 2.0和MIT最省心，自定义许可要逐条读。审计和模型溯源我现在也会做，模型版本、权重哈希、依赖版本都记录下来，出问题时能快速定位是哪个环节变了。这件事平时看不出价值，真出了线上事故，有没有溯源记录差别很大。

4.3 微调与评测方法：业务数据构造、LoRA与全参微调、公开基准与业务指标结合

微调这件事我的态度是能用提示词解决就别急着微调。很多业务场景通过精心设计的提示词加少量示例就能达到可用水平，微调的成本和后续维护开销不小。真要微调的时候，数据构造比调参重要得多。我做过一个票据字段抽取的微调项目，前两版数据都是团队自己标注的，效果一直卡在瓶颈，后来把业务方一线人员的真实工单拿进来，覆盖了各种模糊、倾斜、遮挡的情况，微调后的提升非常明显。

LoRA是我优先考虑的微调方式，显存占用小，训练快，一个7B模型单卡24G就能跑起来。全参微调我只在数据量足够大、LoRA效果不达预期的时候才上，代价是训练资源和调参复杂度都上了一个台阶。LoRA的rank和alpha这两个参数我一般从r=8或16起步，数据量小的时候别把rank设太大，容易过拟合。训练样本的格式要和推理时的chat模板对齐，这一点我见过有人踩坑，训练和推理的模板不一致，微调完效果反而不如原模型。

评测上我现在坚持公开基准和业务指标两条腿走路。公开基准比如MMBench、MMMU这些能帮我快速筛掉明显不合适的模型，但它们的分数和业务效果相关性有限。业务指标我会单独建一套评测集，从真实数据里采样，覆盖典型样本和困难样本，每次模型迭代都跑一遍。我一般会看准确率、召回率和人工抽检通过率三个数，单看准确率容易被简单样本拉高，掩盖掉困难样本上的问题。

4.4 典型落地流程：需求拆解、模型初筛、本地验证、评测调优、上线监控

落地流程我总结成五步，每一步都有明确的产出物。需求拆解阶段我会和业务方一起把任务拆到可测量的粒度，比如“文档理解”太宽泛，要拆成“识别票据类型”“抽取金额字段”“校验日期格式”这种具体子任务。拆得越细，后面选型和评测越有依据。这一步我一般会输出一份需求清单，标注每个子任务的优先级和可接受的错误率。

模型初筛阶段我会列一个候选清单，把许可证、模态覆盖、参数规模、中文能力这几个硬条件先过一遍，留下三到五个候选。本地验证阶段拿每个候选跑一批真实样本，重点看失败案例长什么样，有些模型在简单样本上表现都不错，一遇到困难样本就暴露出短板。这个阶段别急着调参，先用默认配置把各模型的基线跑出来。

评测调优阶段是最耗时间的，我会在业务评测集上跑全量对比，挑出表现最好的模型做针对性优化，提示词调整、量化、微调都可能用到。上线监控是我觉得最容易被低估的一步，模型上线只是开始，输入分布会漂移，用户行为会变化，我一般会配一个抽样人工复核的机制，定期看线上输出的质量。监控指标里我特别关注异常输入的比例，比如图像尺寸异常、文字密度突增这类，往往是新场景出现的信号。

4.5 生态趋势观察：统一多模态、端侧部署、轻量化与社区工具链演进

这两年我感受最深的变化是统一多模态模型的进展。早期做图文理解、图文生成、音频理解要用不同的模型拼起来，工程复杂度高。现在Qwen2.5-Omni这类模型把文本、图像、音频、视频统一到一个架构里，虽然各项能力未必都到顶尖，但工程上的整合成本大幅下降。我判断这个方向会继续走下去，未来业务里可能一个模型就能覆盖多个模态入口，省掉很多胶水代码。

端侧部署是另一个明显趋势。手机和笔记本的算力在涨，轻量化模型的质量也在提升，MiniCPM-V这类小参数模型在端侧跑图文问答已经可用。我试过在高端手机上跑量化后的轻量视觉模型，单张图问答延迟能压到可接受的范围。端侧部署带来的隐私优势很明显，数据不用出设备，省心很多。我估计未来一两年会有更多业务把简单的图像理解任务放到端侧，复杂任务再走云端，形成分层架构。

社区工具链的演进也不容忽视。vLLM、SGLang这些推理框架对视觉模型的支持在变好，Ollama这类本地工具在降低上手门槛，Hugging Face和ModelScope上的模型卡和示例代码也越来越规范。我自己的工具链这两年基本稳定在Transformers做原型、vLLM做服务、Gradio做界面的组合上，生态成熟之后切换成本低了很多。

4.6 学习资源与持续更新：模型榜单、部署教程、复现项目与最佳实践沉淀

资源这块我分几类在用。模型榜单我主要看OpenCompass和Hugging Face上的评测排行，前者中文场景覆盖得更全，后者更新快、模型全。榜单我一般当作初筛参考，不会直接按排名选模型，榜单上的评测集和真实业务分布差异不小。看榜单的时候我会注意评测的具体子项，比如文档理解里的表格识别分数，比总分更有参考价值。

部署教程我看得比较杂，官方模型卡里的示例代码是起点，社区博客和GitHub issue里的排错记录更实用，很多坑别人已经踩过并写出来了。复现项目我习惯找带完整代码和评测脚本的仓库，跑一遍能省很多自己搭环境的功夫。我自己的做法是建一个内部笔记，把每个模型的试用记录、踩过的坑、评测结果都记下来，团队里共享，新人上手能直接查。

最佳实践我越来越觉得需要主动沉淀。每个项目做完我会留半天时间做复盘，把选型理由、评测数据、上线效果和遇到的问题整理成文档。这件事短期看是额外工作量，长期看能避免重复踩坑。工具链也在持续变化，我每隔一段时间会重新跑一遍主流模型的评测，看看有没有新的候选值得替换。开源多模态这个领域迭代太快，保持更新本身就是一项需要投入的工作。