多模态大模型这两年从论文里的概念快速落到了工程现场，图片理解这条线尤其明显。我最早接触 LLaVA 系列是在一个内部知识库的图文检索需求里，当时团队想给一批产品图自动打标签、生成描述，再喂给下游的搜索和推荐。试过纯视觉分类模型，标签粒度太粗；试过调用闭源接口，成本和数据合规都卡脖子。后来把目光转到开源可本地部署的 LLaVA-v1.5-7b 上，才算找到一条能自己掌控的路线。这篇就围绕这个模型，把我从环境搭建、推理调参到效果优化踩过的坑完整梳理一遍，适合想在自己机器上跑通图片理解、又不想被云服务绑死的中高级开发者参考，新手也能照着步骤走下来。
1. 为什么选 LLaVA-v1.5-7b 做图片理解
1.1 这个模型到底解决了什么问题
图片理解听起来玄乎，拆开看其实就是三件事：看懂图里有什么、用自然语言描述出来、再根据人的提问给出针对性回答。传统方案里，检测模型负责框物体，分类模型负责打标签，OCR 负责抠文字，最后靠规则引擎拼成一句话，链路长、维护累、跨场景迁移几乎要重写。LLaVA 这类多模态大模型的思路是把视觉编码器和语言模型对齐，让语言模型直接“读”视觉特征，输出端就是一段通顺的自然语言，省掉了中间那一堆胶水代码。
LLaVA-v1.5-7b 具体是这么个结构：视觉侧用 CLIP 的 ViT-L/14-336 做图像编码，把图片切成 patch 变成视觉 token；中间一个两层 MLP 做投影，把视觉特征映射到语言模型的词嵌入空间；语言侧挂的是 Vicuna-7B 这个对话模型。整个推理过程就是图片进、文字出，支持多轮对话式的追问。7b 这个参数量是它最讨喜的地方——单张 24G 显存的卡就能跑起来，量化之后 16G 甚至 12G 也能凑合，对个人开发者和小团队非常友好。
它擅长的是开放域的图片描述、物体识别、场景理解、简单的关系推理，以及图片里的文字读取（虽然 OCR 精度不如专用模型）。不擅长的是精细计数、密集小目标检测、需要精确坐标的任务。搞清楚这个能力边界，后面调参和评估才不会跑偏。
1.2 选型时我对比过的几条路线
当时摆在面前的选择大概有四类，我列个表把关键维度摊开看：
| 方案类型 | 代表形态 | 部署成本 | 数据合规 | 效果上限 | 定制空间 |
|---|---|---|---|---|---|
| 闭源 API | 各类云端多模态接口 | 按调用量付费 | 数据出域 | 高 | 几乎为零 |
| 专用小模型组合 | 检测+分类+OCR | 低 | 可控 | 中 | 中等 |
| 开源多模态大模型 | LLaVA 系列 | 中 | 完全可控 | 较高 | 大 |
| 自研多模态 | 从零训练 | 极高 | 可控 | 取决于数据 | 最大 |
闭源接口效果确实好，但我们的图片涉及内部资料，出域这条直接否掉。专用小模型组合跑得快，可一旦业务方改需求，比如从“描述图片”变成“回答关于图片的问题”，规则引擎就得推倒重来。自研更不现实，7b 级别的多模态训练数据量和算力都不是小团队能扛的。LLaVA-v1.5-7b 落在中间那个甜点区：开源可改、本地可跑、对话式交互天然适配问答场景，社区生态也成熟，遇到问题搜得到答案。
1.3 7b 这个尺寸的取舍逻辑
有人会问为什么不直接上 13b 甚至更大的。我实测过 13b 在同样硬件上的表现，单张图推理延迟大概翻倍，显存占用从 14G 左右涨到 26G 上下，24G 卡直接爆。7b 在多数通用图片理解任务上和 13b 的差距没有想象中大，尤其是描述类任务，7b 的输出已经足够通顺准确。真正拉开差距的是复杂推理和长尾知识，那部分如果业务确实需要，再考虑上更大模型或者做领域微调。对绝大多数“给图片生成描述、回答图片相关问题”的场景，7b 是性价比最高的起点。
2. 环境搭建与模型加载的实操细节
2.1 硬件与依赖的底线要求
先把硬件账算清楚。7b 模型 fp16 精度下权重约 14G，加上视觉编码器（约 0.6G）和推理时的 KV cache、激活值，单张图推理峰值显存在 16G 到 18G 之间浮动，取决于图片分辨率和生成长度。所以 24G 卡（比如 3090、4090）是最舒服的，16G 卡（比如 4080）需要控制生成长度，12G 卡就得走 4bit 量化。
软件侧我用的组合是 Python 3.10、PyTorch 2.1、CUDA 11.8，transformers 版本建议 4.36 以上，因为 LLaVA 的对话模板和 processor 接口在旧版本上有兼容问题。装依赖时有个坑：accelerate和bitsandbytes的版本要匹配，量化推理依赖后者，版本不对会报算子找不到。我一般直接锁版本：
pip install torch==2.1.0 torchvision==0.16.0 --index-url https://download.pytorch.org/whl/cu118 pip install transformers==4.36.2 accelerate==0.25.0 bitsandbytes==0.41.3 pip install pillow sentencepiece protobuf注意：不要图省事直接
pip install transformers拉最新版，多模态模型的 processor 接口变动频繁，最新版经常和模型权重里的配置对不上，报一些莫名其妙的 key error。
2.2 模型权重的获取与目录组织
权重从官方模型仓库拉下来后，目录结构要保持原样，别自己重命名文件。一个完整的 LLaVA-v1.5-7b 目录大概长这样：
llava-v1.5-7b/ ├── config.json ├── generation_config.json ├── tokenizer.model ├── tokenizer_config.json ├── special_tokens_map.json ├── preprocessor_config.json └── 若干 .safetensors 分片preprocessor_config.json里定义了图像预处理参数，包括裁剪尺寸 336、均值方差这些，加载时 processor 会读它，手动改容易出问题。我见过有人为了适配非方形图片去改这里的 crop_size，结果模型输出质量断崖下跌——因为视觉编码器就是在 336 方形输入上训练的，改了等于分布偏移。
2.3 加载代码与量化开关
标准 fp16 加载的代码不复杂，关键是device_map和torch_dtype两个参数：
from transformers import AutoProcessor, LlavaForConditionalGeneration import torch model_id = "./llava-v1.5-7b" processor = AutoProcessor.from_pretrained(model_id) model = LlavaForConditionalGeneration.from_pretrained( model_id, torch_dtype=torch.float16, device_map="auto", low_cpu_mem_usage=True, ) model.eval()显存不够时加量化配置，4bit 能把权重压到 4G 左右，整体显存降到 8G 上下：
from transformers import BitsAndBytesConfig bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_compute_dtype=torch.float16, bnb_4bit_quant_type="nf4", ) model = LlavaForConditionalGeneration.from_pretrained( model_id, quantization_config=bnb_config, device_map="auto", )量化会带来轻微的效果损失，主要体现在细节描述和文字读取上，通用描述任务几乎感知不到。我的经验是：如果只是做图片打标和粗描述，4bit 完全够用；如果要做精细问答，尽量上 fp16。
3. 推理流程拆解与提示词设计
3.1 一次完整推理的四个阶段
把图片喂给模型到拿到文字，中间其实分了四步，每一步都有可调的地方。
第一步是图像预处理。processor 会把图片 resize 到 336x336、归一化、转成 tensor。这里有个细节：LLaVA-v1.5 用的是 CLIP 的预处理，默认会做中心裁剪，如果原图是长条形（比如全景图、截图），裁剪会丢掉两侧内容。我的处理办法是推理前先把长图做等比缩放加白边填充成方形，保住全部信息，实测比直接裁剪的描述完整度高不少。
第二步是构造对话输入。LLaVA 用的是特定的对话模板，图片占位符<image>必须放在用户消息里，格式错了模型会把它当普通文字。标准构造方式：
conversation = [ { "role": "user", "content": [ {"type": "image"}, {"type": "text", "text": "请详细描述这张图片的内容。"}, ], } ] prompt = processor.apply_chat_template(conversation, add_generation_prompt=True) inputs = processor(images=image, text=prompt, return_tensors="pt").to("cuda", torch.float16)第三步是生成。generate的关键参数是max_new_tokens和do_sample。描述类任务我一般设max_new_tokens=256、do_sample=False（贪心解码，输出稳定可复现）；需要多样性时开采样，temperature=0.7、top_p=0.9。
第四步是解码输出。把生成的 token 去掉输入部分再 decode，就得到最终文字。
3.2 提示词怎么写才不浪费模型能力
提示词对 LLaVA 的输出质量影响比想象中大。同一个模型，问法不同，结果能差出一个档次。我总结了几条实用规律。
描述类任务，提示词要具体到维度。光说“描述这张图”，模型容易给一句泛泛的概括；改成“请从主体、场景、颜色、可能的用途四个角度描述这张图片”，输出结构立刻清晰。问答类任务，要把约束条件写进去，比如“只根据图片中可见的信息回答，不要推测”“如果图中没有相关信息，直接说无法判断”，能显著减少幻觉。
多轮追问时，历史对话要完整保留在 conversation 列表里，模型靠上下文理解“它”“那个”指代什么。但历史太长会挤占视觉 token 的空间，我一般控制在三轮以内，超过就重新开一轮带图的新对话。
实操心得：中文提示词和英文提示词效果有差异。LLaVA-v1.5 的训练数据以英文为主，英文提问在细节描述上通常更准，中文提问在表达流畅度上更好。如果下游要中文结果，可以用英文提问再翻译，或者中文提问但接受偶尔的用词偏差。我做过小样本对比，英文提问的物体识别准确率大概高 5 到 8 个百分点。
3.3 批量推理的工程化处理
单张推理跑通后，实际业务往往是成百上千张图。直接 for 循环一张张跑，GPU 利用率上不去。我的做法是把图片按分辨率分桶，同尺寸的拼成一个 batch，processor支持批量输入，generate一次出多条结果。batch size 根据显存调，24G 卡上 336 尺寸的图大概能塞 8 到 12 张。
批量推理要注意 padding 问题：不同长度的 prompt 需要 pad 到等长，processor的padding=True能处理，但生成时要传attention_mask，否则 pad token 会干扰输出。另外批量生成时do_sample=False更稳，采样模式下 batch 内各条结果的随机性不好控制。
4. 效果优化与常见问题排查
4.1 输出质量不达预期的排查路径
模型跑起来容易，输出让人满意难。我整理了一张排查表，按现象倒推原因：
| 现象 | 可能原因 | 处理办法 |
|---|---|---|
| 描述过于笼统 | 提示词太宽泛 | 指定描述维度，加示例 |
| 出现图中没有的物体 | 模型幻觉 | 提示词加“仅基于可见信息”，降低 temperature |
| 文字读取错误 | OCR 能力弱 | 换专用 OCR 模型补位，或放大文字区域再问 |
| 计数不准 | 模型短板 | 不依赖模型计数，改用检测模型 |
| 输出截断 | max_new_tokens 太小 | 调到 256 以上 |
| 中文表达生硬 | 训练数据偏英文 | 英文提问后翻译，或做中文微调 |
幻觉是这类模型最普遍的问题，尤其问“图里有没有 XX”时，模型倾向于顺着提问说“有”。我的应对是把是非问句改成开放式问句，比如不问“图里有没有猫”，而问“图里有哪些动物”，让模型自己列举，准确率高很多。
4.2 领域适配的微调思路
通用模型在垂直领域会露怯，比如医疗影像、工业质检图，模型没见过类似分布，描述容易跑偏。这时候微调是正路。LLaVA 官方提供了 LoRA 微调的脚本，7b 模型用单张 24G 卡就能跑，关键是数据构造：每条样本是“图片 + 指令 + 标准回答”的三元组，标准回答的质量直接决定微调效果。
数据量不用很大，我试过 2000 条左右的高质量领域数据，LoRA rank 设 16、学习率 2e-4、训练 3 个 epoch，领域描述准确率能提升明显。数据构造时要注意指令多样性，别全是同一种问法，否则模型会过拟合到特定句式。微调后的权重是 LoRA adapter，推理时和基座模型合并加载，不改变原始权重，方便回滚对比。
4.3 推理性能的优化手段
延迟敏感的场景，几个优化点值得做。一是图片分辨率，336 是模型原生输入，但如果业务图本身很小，强行放大到 336 反而增加无效计算，可以按需调整但别偏离训练分布太远。二是 KV cache 复用，多轮对话时历史部分的 KV 可以缓存，避免重复计算，transformers 的generate默认开启。三是用torch.inference_mode()替代no_grad()，省一点显存和开销。四是考虑 vLLM 这类推理框架，不过多模态支持需要额外适配，我目前还是用原生 transformers，稳定优先。
实测数据供参考：24G 卡、fp16、单图单轮、输出 128 token，端到端延迟约 1.8 秒，其中图像编码占 0.3 秒左右，生成占大头。4bit 量化后延迟降到 1.2 秒上下，质量损失可接受。
5. 落地场景与能力边界的清醒认知
5.1 适合直接上手的几类场景
图片自动打标和描述生成是最直接的用法，电商商品图、内容平台的配图、素材库的图片，批量跑一遍就能得到结构化描述，喂给搜索和推荐。图文问答是第二类，比如内部文档里的图表，用户问“这张图说明了什么趋势”，模型能给出解读。辅助无障碍也是很有价值的场景，给视障用户描述图片内容，7b 的输出流畅度已经够用。
还有一类是作为流程中的“理解前置”，比如审核系统里先用模型生成图片描述，再用文本规则或小模型做二次判断，比纯视觉方案灵活得多。
5.2 哪些活别硬派给它
精细计数、密集小目标、需要精确坐标的任务，别指望 7b 模型。我试过让它数货架上的商品，超过十个就开始出错。这类需求老老实实上检测模型。高精度 OCR 也一样，模型能读大字，但票据、表格这种密集文字，专用 OCR 的准确率高一个量级。实时视频流理解也不合适，单帧延迟摆在那，帧率上不去。
把这些边界摸清楚，方案设计时该组合就组合，模型负责它擅长的语义理解，专用模型负责它擅长的精确感知，各司其职比指望一个模型包打天下靠谱得多。
5.3 成本与效果的平衡账
最后算笔账。本地部署 7b 模型，硬件是一次性投入，推理边际成本几乎为零，适合调用量大的场景。调用量小的时候，硬件闲置也是成本，这时候要权衡。我的判断标准是：日均图片处理量超过几千张，本地部署就划算了；量小且对数据合规不敏感，用现成服务更省心。数据合规是硬约束的场景，本地部署没有替代方案。
模型选型上没有银弹，7b 是个务实的起点，跑通了、摸清边界了，再根据实际短板决定是微调、换更大模型还是补专用模型。我在几个项目里都是这个路径，先小步验证，再逐步加码，比一上来就追求最强配置稳得多。
