站在2026年门口回看视觉开发这件事已经被多模态大模型重写了。我当年为一个垃圾分拣项目手工调颜色特征和边缘检测算子调得头皮发麻怎么都想不到今天接到的需求全是这样的拍一张货架照片既要统计哪些商品缺货又要读出价签上的促销文案还要判断陈列合不合规。换在以前这三件事得拆成检测、OCR、分类三条独立管线联调和维护的成本谁做谁知道现在用一个多模态视觉大模型一个接口全干了这就是这两年我最强烈的体感多模态正在把看、判、说统一进同一个模型。这篇文章不做论文搬运只讲开发落地。我会把多模态与视觉大模型开发中最实用的选型思路、环境配置、融合原理、微调步骤、部署评估和踩坑记录都过一遍适合正准备把多模态能力接进业务的后端或算法同学也适合想系统入门的读者。能直接照抄的命令和代码我会给全该解释的原理我尽量用大白话讲明白。1. 2026年的多模态开发从专用模型走向统一理解1.1 需求端在变一个模型吃下看、判、说先解释一下多模态这个概念因为确实有的朋友还停留在多模态就是看图说话的印象里。多模态是指让模型同时处理图像、文字、音频、视频这些不同类型的数据而不是像传统CV那样只处理图像。视觉大模型则是以语言模型为底座、把图片作为第二种语言输入的大模型它能看图、能读文档、能听指令输出结构化内容这也是为什么生产环境里越来越多需求往它身上靠。我梳理过手头两年代码项目里遇到的真实需求变化非常明显。以前客户提识别货架上有没有可乐现在提的是识别货架上的商品缺货的标出来、价签和线上价格不一致的列出来、顺便告诉我促销海报上写了什么。工业质检也一样从图片里有没有缺陷变成缺陷在哪、什么类型、怎么修、维修建议写一段。这些需求有一个共同特征单帧图片本身不够还要语义判断和语言输出。传统方案要多模型组装每个环节都要单独训练、单独测试任何一个环节的误判都会像滚雪球一样放大。而多模态大模型把感知和推理放在同一个网络里天然跨越了这条鸿沟。需要强调的是2026年做这件事的通用姿势不是从零训练模型而是在一个足够强的开源底座之上做任务适配。底座负责通用感知和常识推理你要做的是教它行话、输出格式和领域规则。这和自己搭ResNet的时代已经完全不是一回事了。1.2 开发范式在变提示词先行微调兜底我见到的很多团队还在用老思路拿到业务需求先搜集数据、标注、训练一个专用模型万事俱备才敢上线。这个流程放在大模型时代太长太重了。现在更合理的流程是这样先挑选一个合适的开源视觉大模型用提示词和少量示例直接跑真实业务数据摸清模型能力边界如果行话不懂、格式不对、领域事实总错再考虑用几百到两三千条领域数据做LoRA微调最后上服务框架部署配合一套回归评估持续迭代。为什么大多数任务不需要全参微调因为底模在训练阶段已经见过海量图文对视觉感知能力是足够的。业务场景的差异更多集中在这种设备叫什么、单位怎么写、异常怎么定义、回答要用什么结构。这些是知识分布和输出层面的适配低秩适配就能改得很到位。反过来如果你的任务是检测某个极其少见、底模完全没见过的新目标那要先诊断的是感知能力问题这时候光靠LoRA未必够往往需要补充数据增强甚至微调视觉编码器。1.3 2026年值得关注的能力栈关键词如果只圈重点2026年搞多模态开发绕不开这几个方向多模态融合算法怎么把图像、文本、时序信息合理地拧在一起、开源视觉大模型的选型与微调、多模态行为识别视频场景、多模态目标检测图文联合定位以及把多模态模型嵌进业务系统的工程能力。这里要特别提一句多模态观测与感知数据融合——很多传统项目里摄像头、传感器、工单文本是各管各的现在大家都在往把多模态观测数据统一处理的方向走这套能力比单点调参更值钱。工程侧的关键词也很明确。多模态模型很少单独存在通常会作为一个能力插件挂到Agent编排框架里比如LangChain那类工具链Web后端集成则常以Django、FastAPI这类框架统一对外暴露多模态API。换句话说会做模型只是第一步会把它做成服务并经受住线上数据考验才是2026年真正的分水岭。2. 16G显存玩家的环境与模型选型账本2.1 一套可以直接照抄的开发环境清单先给结论一张16G显存显卡RTX 4060 Ti 16G、4070 Ti Super、3090、4080都行足够跑通绝大多数开源7B/8B视觉大模型的4-bit推理和LoRA微调。如果你手头只有8G显存的卡也不是完全不能玩但要各种抠显存建议先上云。老实说我自己的主力卡就是一块4060 Ti 16G几个生产项目都是在它上面完成微调的。软件环境我给一个最省事的组合Ubuntu 22.04Python 3.10或3.11PyTorch 2.2以上transformers 4.45以上配套的accelerate、peft、bitsandbytes再加qwen-vl-utils处理多模态消息格式和vLLM部署推理。CUDA用12.x就行不一定追求最新版。这里单独提醒一点网上教程经常让你装flash-attention我建议第一轮开发先别装。它的编译时间长、依赖坑多先用eager attention跑通流程等确认瓶颈确实在注意力计算上再回来装也不迟。2.2 主流开源视觉大模型的横评与选型我把2025到2026年这个周期里16G显存玩家实际用得上、社区活跃度也高的几款模型整理成了一张表模型参数量视觉编码器主要强项16G显存用法Qwen2.5-VL-7B约70亿自研ViT中文、文档、视频、GUI、坐标定位4-bit量化 LoRAInternVL2.5-8B约80亿InternViT-300M多语言OCR、文档解析4-bit量化 LoRALLaVA-1.6-8B约76亿CLIP ViT-L学术基线、英文通用场景4-bit量化MiniCPM-V 2.6约80亿SigLIP-400MOCR、视频、端侧部署INT4量化GLM-4V-9B约90亿自研中文聊天、通用VQA4-bit量化选型核心逻辑就三条。第一看任务类型。文档、票据、GUI这类强文字任务优先Qwen2.5-VL或InternVL2.5端侧或成本敏感场景看MiniCPM-V中文通用问答优先Qwen和GLM想要最广泛的社区参考LLaVA是经典基线。第二看中文能力。不少英文模型效果虽好一遇到中文业务名词和中文文档就崩这块必须先用自己数据实测。第三看许可证。开源不等于完全免费商用商用前务必看清模型仓库里的License避免线上翻车。表格里的强项来自公开评测和我自己项目中的体感新版本迭代很快但选型思路不会变先拿你的业务图跑一轮用结果说话别只看论文里的分数。2.3 显存开销的计算方法与16G上限显存账必须学会算。最基本的一条BF16权重每参数2字节4-bit量化后每参数0.5字节。所以一个70亿参数的模型BF16权重约14GB4-bit后约3.5GB。推理时除了权重还要留出KV cache和激活值微调时还要加上梯度、优化器状态和更多激活值。我用一张表把几种方案的账列出来方案权重占用训练可行性备注7B BF16 全参微调约15GB16G基本不可行仅小图短输出可推理7B 4-bit LoRA约4GB16G推荐加激活/优化器后约8~11GB7B BF16 LoRA约15GB风险高容易OOM建议24G卡3B 4-bit LoRA约2GB16G非常轻松适合快速迭代72B 4-bit 推理约36GB16G别碰需要多卡或云端关于激活值和图像分辨率的关系这里多说一句。视觉大模型会把图片切成固定大小的小块比如28×28一个patch每个patch变成一个视觉token。图片越大token越多注意力计算和激活值暴增。举个例子448×448的图约等于256个视觉token但如果你把一张4K图塞进去视觉token直接奔着几千去16G显存当场爆掉。所以训练时严格控制processor的min_pixels和max_pixels比你省内存的其他技巧都更有效。3. 多模态融合的核心机制连接器决定模型听懂图像的方式3.1 为什么像素不能直接进入语言模型很多人第一次接触视觉大模型都会好奇为什么不把图片像素直接当作输入给LLM答案是语言模型输入的是离散的token序列每个token对应的embedding是语义空间里的一个点而原始图像像素只是一堆连续数值和语义毫无对齐关系。直接灌进去模型根本不知道哪个像素和哪个词相关。所以主流架构都走了同一条路先用一个视觉编码器通常是ViT并且在CLIP或SigLIP这类对比学习任务上预训练过把图像切块并编码成视觉特征再用一个连接器把这些视觉特征投影到大语言模型的embedding空间最后LLM像处理文本token一样处理视觉token继续做next token prediction。你可以把视觉编码器理解成一个信息提炼员把图像压缩成紧凑特征连接器则是翻译官负责把视觉特征的坐标系转到语言模型能懂的坐标系。这套设计的核心在于让视觉和文本在同一个表示空间里对齐。3.2 MLP、Q-Former与混合注意力三类连接器的取舍连接器虽然只占模型很小一部分参数但直接决定了视觉信息以什么姿态进入语言模型。这些年业界试过三种主流方案。第一种是MLP投影LLaVA是代表。每个图像patch的特征经过一个简单的线性层或两层MLP直接映射到LLM的hidden size。优点是简单、便宜、可训练性强缺点是每个patch独立映射patch之间没有先做交互遇到需要全局关联的任务会稍微吃力。第二种是Q-FormerBLIP-2和InstructBLIP是代表。通过一组可学习的query向量去查询视觉特征把一整张图压缩成固定几十个token再进入LLM。优点是token数少、效率高缺点是压缩过程可能丢掉细节遇到OCR、小目标这类任务容易吃亏。第三种是更激进的混合架构Qwen2.5-VL、Flamingo各有实现。视觉层和语言层交错排布或者让LLM的某些层额外做cross-attention到视觉特征上视觉信息是逐层渗透的。优点是信息保留好、支持视频和高分辨率缺点是计算量大、显存要求高。Qwen2.5-VL还引入了M-RoPE给每个视觉token注入位置信息让模型知道这个token属于第几帧、在画面哪个坐标这个设计对视频行为理解非常关键。对开发者来说理解连接器类型最大的价值是做故障定位。同样的bad case在MLP架构上可能是全局关系理解差在Q-Former架构上可能是细节丢失在混合架构上则更可能是训练数据不够。选型时不要只盯总分数要结合自己任务的失败模式来选。3.3 分辨率、视觉token数与信息保真度的三角权衡这一节是实操中最容易被忽略的。视觉大模型的输入分辨率不是死的训练和推理时都可以通过processor参数动态调整。图越大细节越清楚但同时token数涨、显存涨、延迟涨图太小小字、小目标直接糊掉。这是三角权衡没有免费午餐。我的经验是分场景设档位。纯自然场景识别短边448到768就够别盲目上高分辨率文档、票据、仪表读数这类强文字场景再往高处走比如把max_pixels放到1024×1024甚至更多视频场景则反过来每帧分辨率不用太高但帧率要稳定抽帧策略比单帧清晰度更影响效果。训练时把分辨率卡得死死的避免模型在不同分辨率区间之间来回漂移推理时再根据业务输入适当放宽这样既省显存又不损失效果。4. 实战一用Qwen2.5-VL LoRA微调一个设备巡检问答模型4.1 数据准备领域VQA数据的整理与清洗我拿一个真实的设备巡检场景来拆解。任务是给一线巡检人员做一个拍照问答助手拍一张仪表盘或开关柜照片模型要识别读数、判断是否正常、给出处理建议并以固定格式输出。这类任务用通用模型也能做但行话和格式往往不对LoRA微调的价值就在这里。数据格式建议直接对齐Qwen的多模态消息格式一行一个JSON{messages:[{role:user,content:[{type:image,image:data/instruments/ck_001.jpg},{type:text,text:请识别这块仪表盘的读数判断是否正常并给出处理建议。}]},{role:assistant,content:[{type:text,text:当前读数为1.85MPa处于正常范围1.6~2.0MPa建议继续观察。}]}]}数据清洗有几条硬性标准。第一分辨率太低、严重过曝或过暗的图直接剔除模型学不到东西还会学坏第二答案要标准化数字单位统一、判断结论统一为正常/异常/待核查这几个词别让模型去猜你的输出规范第三训练和验证集要按设备点位分组同一块表不要同时出现在两边否则测的是背题而不是泛化第四第一版有500到2000条就够启动不够再补数据质量远重要于数量。4.2 微调脚本基于transformers PEFT的最小实现用transformers加PEFT跑LoRA代码量不大。核心要点是底座用4-bit加载视觉编码器保持冻结只把LoRA挂在LLM的注意力层和FFN层上这样显存占用可控适配效果也够用。from transformers import AutoProcessor, Qwen2_5_VLForConditionalGeneration from transformers import BitsAndBytesConfig, TrainingArguments from peft import LoraConfig, prepare_model_for_kbit_training, get_peft_model import torch model_id Qwen/Qwen2.5-VL-7B-Instruct processor AutoProcessor.from_pretrained( model_id, min_pixels256 * 28 * 28, max_pixels1024 * 28 * 28, ) bnb BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_use_double_quantTrue, bnb_4bit_compute_dtypetorch.bfloat16, ) model Qwen2_5_VLForConditionalGeneration.from_pretrained( model_id, quantization_configbnb, torch_dtypetorch.bfloat16, device_mapauto ) model.config.use_cache False model prepare_model_for_kbit_training(model) lora LoraConfig( r32, lora_alpha64, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, ) model get_peft_model(model, lora) args TrainingArguments( output_dir./qe25vl_lora, per_device_train_batch_size1, gradient_accumulation_steps16, learning_rate2e-4, num_train_epochs3, logging_steps5, save_steps100, bf16True, gradient_checkpointingTrue, remove_unused_columnsFalse, report_towandb, )数据集加载这里用qwen-vl-utils的process_vision_info把messages里的图片路径解析出来再让processor把图像和文本拼成一个batchdef collate_fn(examples): texts, image_list [], [] for ex in examples: messages ex[messages] images, _ process_vision_info(messages) texts.append(processor.apply_chat_template( messages, tokenizeFalse, add_generation_promptFalse)) image_list.append(images) batch processor(texttexts, imagesimage_list, return_tensorspt, paddingTrue) return batch这里有个细节容易踩collate返回batch后要记得把labels设为input_ids的拷贝并用-100遮蔽掉prompt部分让模型只对assistant回复计算loss。上面代码为了简洁省略了这个构造实际训练时必须补上。关键参数说几个。LoRA rank取32是视觉任务里比较稳的中间值数据少就降到16数据多想过拟合就升到64学习率在4-bit底座上一般取1e-4到2e-4太高容易把量化底座顶坏视觉编码器这一版先冻结如果任务非常依赖细节比如仪表读数下一版再考虑带低rank的视觉LoRA。这也是我一直建议按最便宜方案先跑通的原则走的原因LoRA不够再考虑部分参数微调别一上来就上昂贵的全参优化。4.3 部署与推理vLLM接入业务的注意点微调完先合并LoRA权重再部署这是我最推荐的做法。合并后的模型就是一个标准模型后续用vLLM加载、做量化、做多副本都省心。vLLM起服务一条命令vllm serve /path/to/merged_model --max-model-len 8192 --gpu-memory-utilization 0.92业务端走OpenAI兼容接口多模态图片用base64串传from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) resp client.chat.completions.create( modelQwen2.5-VL-7B, messages[{ role: user, content: [ {type: image_url, image_url: {url: data:image/jpeg;base64,...}}, {type: text, text: 请识别仪表读数并判断是否正常。}, ], }], )微调后如果有线上吞吐需求可以把合并后的模型用AWQ量化再挂到vLLM上一张16G卡撑住一个小团队内部工具完全没问题。部署时有两件事容易踩一是max-model-len开太大大量并发时显存会涨二是并发数要压测视觉大模型首token延迟比纯文本模型高不少需要设置合理的超时和排队策略。4.4 效果验证与bad case迭代微调不是跑完就结束。我会固定留出50到100条业务测试图每轮迭代都用同一套case跑分先看三类问题读数对不对、格式对不对、有没有不懂装懂乱报异常。bad case收集要成为常规动作线上或验收阶段每发现一条就归到对应类别积累多了就变成下一轮的训练数据。按这个方法我的经验是一般两到三轮迭代后目标场景的准确率能稳定在可接受区间同时通用能力不会崩得太厉害。5. 实战二监控视频行为识别的多模态架构与落地链路5.1 视频行为识别的三个难点把场景切到园区或厂区安全监控需求通常是识别人员有没有做危险动作这类行为分析。听起来和图片分类差不多做起来完全是另一件事。第一个难点是目标小。监控画面里人往往只占画面几十个像素直接整帧丢给视觉大模型模型很难聚焦。第二个难点是语义模糊比如推搡和拉扯、弯腰捡东西和倒地单帧看起来可能一模一样必须结合时序上下文才能判断。第三个难点是长视频里的稀有事件危险行为可能几秒就结束但要在全天候数据里把它捞出来命中率不能低、误报不能多。这里必须先强调合规和边界。凡是涉及人的视频分析项目采集、标注、部署都要走公司内部审批人脸等生物信息要做脱敏处理模型和数据尽量部署在本地。这不是唱高调而是做这类项目必须守住的底线否则技术做得再好也会翻车。5.2 帧级感知 语义时序推理的混合架构我最终采用的不是一个端到端视频模型解决所有问题而是混合架构分五步走抽帧、目标检测与跟踪、目标裁剪、帧级语义描述、语义级时序推理。第一步按1到2fps抽帧可疑事件片段保留5到10秒。第二步用YOLO类检测器加ByteTrack跟踪得到每个目标的轨迹这一步纯CV做速度快、可解释。第三步按轨迹把目标区域裁剪出来保持时间顺序。第四步对每个目标逐帧调用Qwen2.5-VL这类视觉大模型生成简短的帧级描述比如一个人正在弯腰捡起地上的瓶子。第五步把连续帧的描述按时间顺序拼起来交给一个纯文本LLM做行为推断和风险分级输出结构化事件比如员工在非作业区域下蹲疑似摔倒风险等级高。之所以不用一个视频VLM一把梭原因是成本和可控性。端到端视频VLM听起来省事但训练和推理都贵bad case一多很难定位是感知错还是推理错。混合架构把感知和推理拆开每一层都可以单独检测、单独优化检测漏了查检测描述错了查视觉模型判断错了查LLM。我把几种方案做过对比方案精度成本可解释性纯CV规则中低低高帧级VLM串LLM中高中中高端到端视频VLM中高高低检测 VLM LLM混合高中中高这套架构本质上是多模态感知数据融合不是把像素硬拼在一起而是把检测结果、视觉描述、时间戳这些不同模态的信息统一到语义层做融合和推理。这也是我认为2026年工程上更实用的多模态融合形态尤其适合多模态观测数据来源复杂的场景。5.3 从离线分析到实时预警工程上还要补哪些业务一开始往往是离线分析把当天视频批量跑完生成事件报告。这个阶段验证的是算法准确率和流程跑不跑得通。但客户真正要的通常是实时预警这里工程复杂度立刻上一个台阶。实时链路里我会补这几样稳定的抽帧服务、消息队列做事件缓冲、一个目标状态机负责同一个人的连续帧聚合成一个事件以及告警去重和人工复核队列。性能预算也要提前规划YOLO检测加跟踪一帧控制在几十毫秒视觉模型单次调用几百毫秒所以绝不能每帧都调VLM。合理做法是先用CV规则做初筛只把可疑片段送进视觉大模型复核这样一张16G卡也能扛住几十路视频的并发。期间还要定期用新采集的事件数据做回归评估防止场景漂移把模型拖歪。6. 评估多模态模型宏F1的平衡度比总准确率更能说明问题6.1 主流多模态评测基准一览多模态模型到底行不行不能靠肉眼感觉必须有个体面的评测体系。公开基准里常用的有这些基准测什么什么时候用MMMU跨学科知识与推理底模选型MMStar / MM-Vet细粒度感知、组合认知底模选型、版本回归MathVista图表数学推理垂类需要时DocVQA / OCRBench文档文字读取文档、票据场景POPE物体级幻觉上线前必测自建业务集真实业务表现每版必测底模选型阶段我会拿MMMU、MMStar、MM-Vet这类综合基准的成绩作参考重点看模型在细粒度感知和组合推理上的表现而不是只看参数量。进入业务后自建测试集永远排在最高优先级公开基准只能用来防止你把模型的通用能力搞退化。6.2 平衡度与幻觉率两个被忽视的致命指标业务评估里最容易踩的坑是只盯总准确率。举个我真实遇到的例子一个安全帽佩戴检测的多模态方案测试集里未佩戴占80%模型学成了看见人就报未佩戴总准确率轻松到90%以上但已佩戴类别的召回烂得像纸糊。这时候看宏F1和每类召回问题一下就暴露了。所谓平衡度本质上就是看模型在各类别之间是不是一碗水端平特别要关注宏F1和微F1的差距差距越大说明模型越偏向高频类别。另一个致命指标是幻觉率。多模态模型特别容易自信地胡说明明图里没有安全绳它可能根据上下文推演出工人未系安全绳并一本正经地报警。这类错误在安全场景里比漏报还危险因为会消耗信任、淹没有效告警。上线前至少要用POPE这类方法验一遍物体级幻觉再人工抽看100条业务输出专门统计输出里有没有图里根本不存在的对象或数值。6.3 一套可落地的回归评估清单我的做法是建一套固定回归流程每次换模型、改提示词、调完LoRA都跑同一套脚本出三张表总体准确率、各类别细分指标、幻觉与拒答率。评估集规模不用大核心场景100到300条足够但要按类别、难度、分辨率分布分层抽确保能暴露问题。开放性问题用LLM-as-judge粗筛再抽20条人工校准避免自动评分器本身有偏见。最后把bad case归类为感知错、格式错、幻觉、知识错四类哪一类最多就先解决哪一类。这套清单看起来不酷但它是我多模态项目能不翻车的最重要保障。数据质量评估这件事也一样标注是否一致、图像清晰度分布如何都会直接决定指标的可靠性别只看最终分数。7. 踩坑实录显存爆炸、数据偏科与能力退化7.1 显存OOM的完整排查链路显存OOM是我给新手做技术支持时遇到最多的问题比模型效果差还常见。有一次我在4060 Ti 16G上微调Qwen2.5-VL跑到300步直接OOM进程被杀。那次排查我完整走了一遍链路先用nvidia-smi看显存占用发现16G吃满再用torch.cuda.max_memory_allocated()看峰值发现大头不在权重而在激活值接着怀疑是图像分辨率问题一查果然是max_pixels设得太高一张图生成近万个视觉tokenViT和注意力层的激活值直接失控。我把排查路径固定成一套动作。第一步确认是权重占大头还是激活占大头方法很简单开不开gradient checkpointing对比一下峰值。第二步检查processor的min_pixels和max_pixels训练分辨率压到业务需要的最低档这一招通常能立刻腾出好几个G。第三步确认batch_size1加gradient_accumulation把use_cache关掉这是训练侧的标准姿势。第四步如果还爆再考虑换3B模型或做CPU offload。最后给你一个锦囊设置环境变量PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True能缓解显存碎片导致的偶发OOM。7.2 训练数据配比失衡模型偏科了第二个高发坑是数据配比失衡。我之前有个项目训练集里皮带跑偏的样本特别多皮带撕裂特别少结果模型把什么都往跑偏上归现场工人哭笑不得。这种现象的根因是多数类在loss里占绝对主导LoRA学到的其实是数据分布而不是判断规则。修法也直接。一是对训练集做类别均衡采样或过采样让少数类占比至少到20%以上二是对少数类做针对性的图像增强比如旋转、亮度扰动、局部裁剪三是在prompt里把每个类别的定义和边界写清楚帮模型做语义区分四是在验证集上按类别单独统计召回率用宏F1而不是总准确率当主指标。数据偏科的问题只要肯在评估上多花功夫通常一轮就能发现并纠正。7.3 微调后通用能力退化原因与缓解第三个坑是最容易被忽略的LoRA微调完业务效果好了但模型变笨了。我遇到过微调之后让它识别一只简单的猫都失败的情况。原因通常是学习率太高、训练步数太长、训练数据太单一LoRA把模型往一个极窄的方向拽得太狠。缓解策略我在项目里反复验证过。第一LoRA rank别贪大r32起步数据量小就降到16。第二学习率控制在2e-4以内epoch一般2到3轮就够多训不一定更好。第三在训练集里混入5%到10%的通用图文指令数据等于给模型留记忆缓存防止它把常识忘光。第四每次微调后都跑一遍通用评估集一旦发现通用任务掉点超过阈值就回退上一步的超参数。还有一个容易被忽视的问题叫prompt敏感性模型对同一含义的不同问法给出完全不同的答案。我的做法是把业务prompt模板固化并在评估时就用这套固定模板减少线上不可控因素。最后说一个我做多模态项目以来最深的体会新项目拿到手别急着微调。先用最新开源底模配合提示词把真实业务数据跑一遍拿到基线和bad case分布再判断瓶颈到底是行话不懂、格式不对还是感知能力不够。前者才需要LoRA后者往往要先换更强的底座或补数据。我靠这个习惯省下的标注成本和显卡时间够买很多杯咖啡了。