視覺大模型開發(fā)實戰(zhàn)：架構(gòu)、量化、微調(diào)與落地)
2026年做多模態(tài)和視覺大模型開發(fā)這幾件事必須提前想清楚從去年開始我陸續(xù)幫團隊落地了好幾個多模態(tài)相關(guān)的項目——圖文檢索、視覺問答、還有幾個內(nèi)部效率工具。說實話多模態(tài)開發(fā)跟純文本大模型完全是兩套玩法。以前做 LLM 應(yīng)用說白了就是 prompt 工程加 RAG最多再調(diào)調(diào)參數(shù)。但一旦涉及到視覺、音頻這些模態(tài)模型選型、顯存規(guī)劃、數(shù)據(jù)管線、評測方式全都變了。這篇博文就把我做多模態(tài)和視覺大模型開發(fā)實戰(zhàn)的一些積累整理出來。內(nèi)容包括整體技術(shù)架構(gòu)怎么拆分、16G 顯存能跑哪些模型、多模態(tài)融合到底怎么融、多模態(tài) RAG 和 Agent 怎么做、以及常見坑的排查思路。目標(biāo)是讓正在入門或準(zhǔn)備轉(zhuǎn)方向的同學(xué)少走彎路也讓已經(jīng)上手的同行能對照查漏補缺。1. 多模態(tài)開發(fā)全局思路先搞清楚架構(gòu)再動手1.1 多模態(tài)大模型的架構(gòu)流派做多模態(tài)之前先把架構(gòu)這件事想明白。市面上主流的多模態(tài)大模型大體上可以分成三類。第一類是雙塔融合結(jié)構(gòu)典型代表是 CLIP 和 SigLIP。這種結(jié)構(gòu)把圖像和文本分別編碼成向量然后拉到同一個向量空間里做相似度匹配。優(yōu)點是很輕量訓(xùn)練和推理都比較快適合做圖文檢索、零樣本分類這類任務(wù)。但缺點是它不擅長生成類任務(wù)因為本質(zhì)上它是一個度量學(xué)習(xí)框架不是生成模型。第二類是Tokenizer 統(tǒng)一結(jié)構(gòu)代表就是 GPT-4o、Gemini 這類原生多模態(tài)模型。它們把圖像、音頻都 Token 化喂給同一個 Transformer。這類模型有多模態(tài)能力上限最高但基本都是閉源或超大參數(shù)開源社區(qū)目前還很難復(fù)現(xiàn)。第三類是視覺編碼器LLM的復(fù)合結(jié)構(gòu)目前開源多模態(tài)模型里最主流Qwen2-VL、InternVL、MiniCPM-V 都是這類。圖像先經(jīng)過一個視覺編碼器比如 SigLIP 或 ViT變成視覺 Token再由一個投影層映射到語言模型的輸入空間。這種結(jié)構(gòu)的核心優(yōu)勢在于語言模型部分可以沿用純文本模型的成熟權(quán)重視覺部分可以靈活替換或凍結(jié)/微調(diào)。在 16G 顯存這個約束下能實踐的主要就是第三種結(jié)構(gòu)。后面我講到的模型選型、微調(diào)方案、Agent 開發(fā)也都是基于這個架構(gòu)展開的。1.2 開發(fā)路徑和技能棧拆解多模態(tài)開發(fā)比純文本開發(fā)多出來的一個關(guān)鍵環(huán)節(jié)是視覺編碼器的處理。整個鏈路可以拆成四個層次。第一個層次是推理部署就是能把現(xiàn)成模型跑起來。需要掌握 HuggingFace Transformers 的基本用法、vLLM 或 Ollama 這類推理框架以及量化工具。這個層次對應(yīng)的是會用。第二個層次是應(yīng)用開發(fā)就是基于多模態(tài)模型的 API 或本地部署實現(xiàn)具體的業(yè)務(wù)功能。比如圖文理解、視覺問答、多模態(tài) RAG這些需要懂 prompt 設(shè)計、檢索策略、后端服務(wù)封裝。這個層次對應(yīng)的是會做產(chǎn)品。第三個層次是模型微調(diào)與適配就是要解決預(yù)訓(xùn)練模型在特定業(yè)務(wù)場景下效果不佳的問題。需要掌握 LoRA、QLoRA 這些參數(shù)高效微調(diào)方法理解視覺 Token 是怎么參與訓(xùn)練的會處理多模態(tài)數(shù)據(jù)的預(yù)處理流程。第四個層次是算法創(chuàng)新就是做多模態(tài)融合算法的改進。這個層次已經(jīng)接近科研了要關(guān)注多模態(tài)特征對齊、跨模態(tài)注意力、模態(tài)缺失處理這些研究方向。在 2026 年這個時間點前兩個層次是必會第三個層次是加分項第四個層次是少數(shù)人的選擇。我建議普通開發(fā)者把主要精力放在第一和第二個層次上把推理部署和應(yīng)用開發(fā)玩熟再根據(jù)工作需要決定要不要深入微調(diào)。1.3 一張圖看懂多模態(tài)應(yīng)用的技術(shù)棧我自己習(xí)慣把多模態(tài)應(yīng)用的技術(shù)棧分成五層基礎(chǔ)設(shè)施層GPU 服務(wù)器、推理引擎vLLM / TensorRT-LLM / Ollama、模型量化工具模型層開源多模態(tài)模型Qwen2-VL、InternVL、MiniCPM-V或其 API能力層圖文理解、OCR 識別、視覺定位Grounding、視頻理解、音頻理解應(yīng)用框架層LangChain / LlamaIndexRAG、Agent 框架ReAct / Function Calling、向量數(shù)據(jù)庫業(yè)務(wù)層知識庫問答、內(nèi)容審核、輔助駕駛、醫(yī)療影像、工業(yè)質(zhì)檢等從開發(fā)者的角度看多數(shù)工作集中在能力層和應(yīng)用框架層之間的接口處。你需要清楚模型本身能做什么、不能做什么然后決定哪些能力要自己開發(fā)哪些直接調(diào)現(xiàn)成的 API。2. 16G 顯存怎么選模型、怎么量化顯存焦慮的破局方法2.1 主流開源多模態(tài)模型選型對比顯存不夠用是我在私信里被問得最多的問題。很多人以為跑多模態(tài)模型怎么也得 40G 顯存以上但實際經(jīng)過量化和小 Batch 配置16G 的可選范圍已經(jīng)不小了。我按實際使用體驗把適合 16G 顯存跑的多模態(tài)模型整理了一下。模型參數(shù)量視覺編碼器量化后顯存占用16G 卡適合場景備注Qwen2-VL-7B8.3BSigLIP-So400M8-10GAWQ 4bit通用圖文理解、OCR、視頻理解效果均衡工具調(diào)用能力強Qwen2.5-VL-7B8.4BSigLIP-So400M8-10GAWQ 4bit通用圖文問答、Agent相比 2-VL 推理更快InternVL2-8B8.1BInternViT-300M9-11GGPTQ 4bit中文場景、多輪對話中文數(shù)據(jù)支持好MiniCPM-V 2.68.1BSigLIP-So400M7-9GAWQ 4bit端側(cè)部署、長圖理解支持 180 萬像素輸入CogVLM2-9B9.7BViT12-14GGPTQ 4bit復(fù)雜視覺推理顯存偏緊吞吐受限Florence-2 0.7B0.7BViT-B2-3GOCR、定位、圖像描述極輕量只做視覺任務(wù)提示16G 顯存想跑得舒服優(yōu)先考慮 Qwen2-VL-7B 或 InternVL2-8B。前者綜合能力強且生態(tài)好后者中文場景表現(xiàn)更穩(wěn)。MiniCPM-V 適合顯存更小或端側(cè)部署的場景。2.2 量化方案選擇AWQ、GPTQ 怎么權(quán)衡量化是讓大模型在有限顯存下跑起來的核心手段。對于多模態(tài)模型量化的主要對象是語言模型部分視覺編碼器一般保持 FP16。因為視覺編碼器的參數(shù)量相對較小而且它對量化誤差更敏感。我在實踐中對比過 AWQ 和 GPTQ 兩種主流量化方案說下實際感受。AWQActivation-aware Weight Quantization基于激活值分布來選擇保留哪些權(quán)重通道的精度量化后模型輸出質(zhì)量更穩(wěn)視覺任務(wù)尤其明顯。它的速度也更快通常只在量化前做一次校準(zhǔn)校準(zhǔn)集大概需要 128-256 條樣本。我測試下來Qwen2-VL-7B 用 AWQ 和 FP16 相比圖像理解任務(wù)的準(zhǔn)確率差距基本在 2 個百分點以內(nèi)。GPTQ 則基于二階近似誤差最小化對語言任務(wù)的保持更好但在視覺任務(wù)上偶爾會出現(xiàn)目標(biāo)邊界框偏移之類的問題。它的歷史更早工具鏈成熟不過對于多模態(tài)場景我目前更傾向 AWQ。Bit 數(shù)方面4bit 是顯存和效果之間的甜點區(qū)。2bit 基本不用考慮圖片細(xì)節(jié)會嚴(yán)重丟失。如果顯存還有余量可以嘗試 4bit KV Cache 量化的組合比如 Qwen2-VL-7B 在 AWQ 4bit 基礎(chǔ)上再加 KV Cache 8bit顯存可以壓到 8G 左右同時保持良好效果。2.3 一個真實可跑的 16G 顯存部署示例我用一張 RTX 4080 16G 部署過 Qwen2-VL-7B-AWQ整個流程比較順分享出來給你參考。使用的推理后端是 vLLM它對 AWQ 支持很成熟OpenAI 兼容接口也讓后續(xù)開發(fā)省了很多事。部署步驟大概是這樣的# 1. 安裝 vllm建議使用 0.6 以上版本 pip install vllm # 2. 啟動模型關(guān)鍵參數(shù)是 quantization 和 max-model-len vllm serve Qwen/Qwen2-VL-7B-Instruct-AWQ \ --quantization awq \ --max-model-len 4096 \ --limit-mm-per-prompt image2 \ --gpu-memory-utilization 0.9 \ --port 8000這里--limit-mm-per-prompt控制每輪請求最多帶幾張圖我設(shè)為 2 是為了防止顯存溢出。--gpu-memory-utilization 0.9是讓 vLLM 最多用 90% 顯存做 KV Cache留一點余量給突發(fā)請求。啟動后用 Python 請求一下接口驗證import base64 import requests # 準(zhǔn)備一張測試圖片 with open(test.jpg, rb) as f: img_b64 base64.b64encode(f.read()).decode() payload { model: Qwen/Qwen2-VL-7B-Instruct-AWQ, messages: [ { role: user, content: [ {type: image_url, image_url: {url: fdata:image/jpeg;base64,{img_b64}}}, {type: text, text: 這張圖片里有什么} ] } ], max_tokens: 512 } resp requests.post(http://localhost:8000/v1/chat/completions, jsonpayload) print(resp.json()[choices][0][message][content])這套方案實測單張 16G 卡可以支持約 4 個并發(fā)請求單請求響應(yīng)時間在 1-2 秒級別做內(nèi)部工具和小規(guī)模產(chǎn)品驗證完全夠用。3. 多模態(tài)融合算法與視覺模型微調(diào)原理與實操兩手抓3.1 多模態(tài)融合的三個層面大家在網(wǎng)上經(jīng)?？吹蕉嗄B(tài)融合算法這個詞但不同場景下它指的東西差別很大。我按實際工作的層級拆解了一下。特征層面融合這是最底層也最經(jīng)典的融合方式。圖像經(jīng)過編碼器得到視覺特征向量文本經(jīng)過編碼器得到文本特征向量然后把它們拼接或加權(quán)求和再送入分類器或生成器。CLIP 的對比學(xué)習(xí)、雙塔模型的信息檢索本質(zhì)都屬于這一層。特征層面融合的優(yōu)勢是計算量可控適合做檢索和分類任務(wù)。交互層面融合視覺特征和文本特征在 Transformer 的每一層里互相做 Attention也就是交叉注意力。這種方式信息交互更充分但對算力要求更高訓(xùn)練難度也更大。Flamingo 的 Perceiver Resampler、Qwen2-VL 中視覺 Token 接入 LLM 的方式都屬于這個范疇。決策層面融合多個模態(tài)分別獨立推理最后在決策層投票或加權(quán)。比如一個模型只看圖、一個模型只看文本最后對結(jié)果做融合判斷。這種方式在不同模態(tài)的模型無法聯(lián)合訓(xùn)練時比較實用容錯性也更好但信息交互程度最低。我在實際項目里總結(jié)的經(jīng)驗是檢索類任務(wù)用特征層面融合就夠了理解類任務(wù)需要交互層面融合決策層面融合適合做兜底或集成。如果要做多模態(tài)融合算法改進方向的產(chǎn)出優(yōu)先在交互層面做文章這個方向的可挖掘空間最大。3.2 視覺編碼器的核心作用多模態(tài)模型里視覺編碼器承擔(dān)著翻譯官的角色。它把像素級的圖片輸入轉(zhuǎn)換成語言模型能理解的 Token 序列。目前主流的開源多模態(tài)模型使用的視覺編碼器主要分兩派。一派是 SigLIP。它的特點是訓(xùn)練方式上做了改進用 Sigmoid 損失替代了 InfoNCE 損失訓(xùn)練速度更快長尾數(shù)據(jù)上的表現(xiàn)也更穩(wěn)定。Qwen2-VL、MiniCPM-V 都采用了 SigLIP。另一派是 InternViTInternVL 系列自研的視覺編碼器在視覺感知的細(xì)節(jié)上做了強化特別適合做文檔理解和屏幕截圖理解。視覺編碼器內(nèi)部通常會做 Multi-View 或多尺度處理。比如 Qwen2-VL 會把圖片動態(tài)切分成多個像素塊Patch每個 Patch 單獨編碼再通過 MLP 投影層映射到語言模型的空間。這樣對大圖、長圖的處理效果會好很多。但這也會帶來視覺 Token 數(shù)量膨脹的問題——一張 1280x1280 的圖可能產(chǎn)生上千個視覺 Token直接拖累推理速度。一個實用的經(jīng)驗是如果你的任務(wù)場景是看清圖里的文字或定位目標(biāo)物體優(yōu)先選擇視覺編碼器更強的模型InternVL、Qwen2.5-VL如果是理解整張圖的語義選通用型模型的默認(rèn)配置就行沒必要過度追求分辨率。3.3 LoRA 微調(diào)實操參數(shù)計算與效果對比微調(diào)多模態(tài)模型時大多數(shù)人會直接上 LoRA 或 QLoRA。這里有個概念必須先厘清在多模態(tài)模型里L(fēng)oRA 可以加在語言模型部分也可以加在投影層和視覺編碼器上。不同位置的 LoRA 對不同能力的影響差異很大。我做過一組實驗對 Qwen2-VL-7B 分別做了三種 LoRA 方案方案 A只對語言模型部分加 LoRA最常見的做法方案 B對語言模型 投影層加 LoRA方案 C對語言模型 投影層 視覺編碼器后幾層加 LoRA訓(xùn)練數(shù)據(jù)用的是我整理的一批票據(jù)識別結(jié)構(gòu)化提取數(shù)據(jù)1600 條左右在單張 A100 上訓(xùn)練了 2 個 epoch實際 16G 顯存用 QLoRA 也可復(fù)現(xiàn)。結(jié)果是方案 A 在文字結(jié)構(gòu)化提取上 F1 得分提升最明顯從 0.62 到 0.87達到了業(yè)務(wù)可用水平方案 B 的提升反而不如 A因為投影層參數(shù)如果改動過大可能破壞原本的對齊空間方案 C 在把模型沒見過的票據(jù)版式描述出來這個能力上有幫助但訓(xùn)練穩(wěn)定性差損失波動大容易過擬合。所以我的建議是先無腦從語言模型 LoRA 開始rank 取 16 到 32如果任務(wù)非常依賴視覺理解再考慮把視覺編碼器末層也解凍訓(xùn)練。不要一上來就把所有部分都加 LoRA出了問題根本沒法定位。一個 LoRA 訓(xùn)練時的關(guān)鍵參數(shù)參考參數(shù)名建議值說明r16-32太低擬合不了太高容易過擬合alpha32通常取 r 的 1-2 倍target_modulesq_proj, k_proj, v_proj, o_proj語言模型的注意力層即可learning_rate1e-4 到 3e-4比純文本微調(diào)略低max_length2048多模態(tài)輸入 token 多太長顯存不夠batch_size1-2累積梯度受顯存限制配合 grad_accumulation注意多模態(tài) LoRA 訓(xùn)練時max_length要綜合圖片 token 和文本 token 一起算。比如 Qwen2-VL 默認(rèn)對每張圖會動態(tài)切 patch一張 1024x1024 的圖可能占幾百個 token所以文本部分不要寫太長不然會截斷。3.4 數(shù)據(jù)管線搭建圖文對到底怎么準(zhǔn)備多模態(tài)微調(diào)的數(shù)據(jù)格式和純文本有非常大的不同。以 Qwen2-VL 為例訓(xùn)練數(shù)據(jù)的基本格式是[ { id: sample_001, conversations: [ { role: user, content: [ {type: image, image: train/001.jpg}, {type: text, text: 請識別這張發(fā)票的總金額和開票日期} ] }, { role: assistant, content: [ {type: text, text: 總金額1234.56元開票日期2025-11-02} ] } ] } ]這個格式里最容易踩坑的點是 image 字段。如果 image 傳的是相對路徑訓(xùn)練腳本通常要根據(jù)一個 base_path 拼接成絕對路徑如果 image 傳的是 base64 字符串那么需要注意轉(zhuǎn)義問題和硬盤緩存問題。我建議在訓(xùn)練前先寫一個數(shù)據(jù)校驗?zāi)_本把每條樣本都取出來看一眼確認(rèn)圖片能正常打開、尺寸合適、文字沒截斷。數(shù)據(jù)量上如果只是做垂直領(lǐng)域適配一兩千條高質(zhì)量數(shù)據(jù)往往就夠了。但數(shù)據(jù)質(zhì)量要求很高——至少要有 10% 的負(fù)樣本或邊界案例否則模型容易產(chǎn)生幻覺在答案里編造圖片里沒有的內(nèi)容。4. 多模態(tài) RAG 與 Agent 實踐把圖文知識庫變成可用的產(chǎn)品4.1 多模態(tài) RAG 和純文本 RAG 的本質(zhì)差異多模態(tài) RAG 火起來是有原因的。傳統(tǒng)的純文本 RAG 只能檢索和生成文字內(nèi)容但現(xiàn)實世界里有大量知識是以圖片、掃描件、截圖的形態(tài)存在的。一個企業(yè)知識庫如果只能檢索文字等于把大約 30% 的信息直接扔掉了。多模態(tài) RAG 要解決的問題就是讓系統(tǒng)既能看、又能搜、還能回答問題。多模態(tài) RAG 和純文本 RAG 的本質(zhì)差異體現(xiàn)在兩個環(huán)節(jié)。索引階段純文本 RAG 直接把文本切塊嵌入多模態(tài) RAG 得先考慮——是一張圖配一段文字描述作為一個整體塊還是把圖里的 OCR 文字單獨提取出來建索引不同的策略決定了后續(xù)檢索的質(zhì)量。檢索與生成階段多模態(tài) RAG 里 query 可能是文字也可能是圖片——用戶拍一張海報來問這是什么活動。這種情況下query 和文檔之間的相似度計算就跨了模態(tài)。4.2 圖文知識庫的切分與索引策略我實踐下來比較可靠的多模態(tài)索引策略是雙路索引 交叉檢索。第一路是圖文聯(lián)合索引。對于帶圖的文檔PPT、PDF、網(wǎng)頁保留圖片相鄰文字作為一個整體文檔塊用多模態(tài)模型對圖片生成一段描述Caption把這個描述和原文字拼接再統(tǒng)一做向量化。這樣檢索的時候既可以通過文字匹配到內(nèi)容也可以通過圖片描述匹配到視覺信息。第二路是 OCR 文本索引。把所有圖片里的文字都做 OCR 提取純文本嵌入單獨建一個索引。這樣當(dāng)用戶查詢里包含明確的數(shù)字、專有名詞時OCR 文本索引的精準(zhǔn)度會很高。檢索階段把兩路結(jié)果做一個重排融合比如 RRFReciprocal Rank Fusion方法把兩路各自的排名結(jié)果合并。實際操作的時候我用 LlamaIndex 搭過一個基礎(chǔ)版本核心代碼如下你可以參考from llama_index.core import VectorStoreIndex, SimpleDirectoryReader from llama_index.multi_modal_llms.ollama import OllamaMultiModal from llama_index.core.node_parser import SentenceSplitter from llama_index.vector_stores.qdrant import QdrantVectorStore import qdrant_client # 1. 讀入圖文混排的文檔 documents SimpleDirectoryReader(./data/ppt).load_data() # 2. 對每個文檔塊生成圖像描述 mm_llm OllamaMultiModal(modelqwen2.5-vl:7b, temperature0.1) for doc in documents: if hasattr(doc, image_path): desc mm_llm.complete( prompt用20個字以內(nèi)描述這張圖片的內(nèi)容。, image_documents[doc] ) # 把描述并入文本節(jié)點 doc.text f[圖片描述] {desc} \n [原文本] {doc.text} # 3. 切塊向量化并寫入 qdrant client qdrant_client.QdrantClient(path./qdrant_db) vector_store QdrantVectorStore(clientclient, collection_namemultimodal_docs) splitter SentenceSplitter(chunk_size512, chunk_overlap50) nodes splitter.get_nodes_from_documents(documents) index VectorStoreIndex(nodes, vector_storevector_store) # 4. 查詢 query_engine index.as_query_engine(similarity_top_k4) resp query_engine.query(這份材料的核心結(jié)論是什么) print(resp)這里比較關(guān)鍵的是第二步——用多模態(tài)模型生成圖片描述。描述的質(zhì)量直接影響檢索召回率。生成描述時不要只寫這是一張圖表要盡量包含圖中的關(guān)鍵數(shù)字和結(jié)論。你可以手動挑 20 條典型圖片把描述風(fēng)格打磨好再批量跑。4.3 多模態(tài) Agent 架構(gòu)從看圖說話到看懂就做多模態(tài) Agent 和多模態(tài)模型的最大區(qū)別在于前者不光要理解還要執(zhí)行——根據(jù)圖片內(nèi)容做決策、操作工具、調(diào)用 API。打個比方視覺模型像一個解說員能告訴你畫面里發(fā)生了什么多模態(tài) Agent 更像一個助理看到信息后要替你干活。一個典型的多模態(tài) Agent 流程是這樣的用戶上傳一張訂單截圖并提問這個訂單發(fā)貨了嗎Agent 調(diào)用視覺模型識別截圖中的訂單號、物流狀態(tài)Agent 根據(jù)識別結(jié)果調(diào)用訂單查詢 API 獲取最新物流信息綜合視覺信息和 API 返回結(jié)果組織最終答案在實現(xiàn)層面Qwen2-VL 系列目前對 Function Calling 支持得不錯。模型在圖文輸入下可以輸出結(jié)構(gòu)化的工具調(diào)用指令格式和 OpenAI 的 Function Calling 一脈相承。一個簡易的 ReAct 多模態(tài) Agent 路徑示例如下import json from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) tools [ { type: function, function: { name: query_order, description: 根據(jù)訂單號查詢訂單狀態(tài), parameters: { type: object, properties: { order_id: {type: string} }, required: [order_id] } } } ] def query_order(order_id: str) - str: return json.dumps({order_id: order_id, status: 已發(fā)貨, tracking: SF1234567890}) # 用戶上傳截圖 messages [ { role: user, content: [ {type: image_url, image_url: {url: data:image/jpeg;base64,...}}, {type: text, text: 麻煩幫我查一下這個訂單的狀態(tài)} ] } ] # 第一輪讓模型理解圖片并產(chǎn)出工具調(diào)用 resp client.chat.completions.create( modelQwen/Qwen2-VL-7B-Instruct-AWQ, messagesmessages, toolstools, tool_choiceauto ) # 解析工具調(diào)用 assistant_msg resp.choices[0].message if assistant_msg.tool_calls: for tc in assistant_msg.tool_calls: args json.loads(tc.function.arguments) result query_order(args[order_id]) # 把工具結(jié)果返回給模型生成最終回復(fù) messages.append(assistant_msg) messages.append({ role: tool, tool_call_id: tc.id, content: result }) final_resp client.chat.completions.create( modelQwen/Qwen2-VL-7B-Instruct-AWQ, messagesmessages, toolstools ) print(final_resp.choices[0].message.content)這里有一個我在實踐中踩過的坑多模態(tài)模型輸出 tool_call 時如果圖片里要識別的文字比較長比如一長串訂單號容易識別錯一兩位。我后來在 prompt 里加了請仔細(xì)核對訂單號逐字識別這樣的提示同時在工具調(diào)用后加了一層校驗邏輯——如果查詢 API 返回訂單不存在就重新讓模型再看一遍圖。這種識別-執(zhí)行-校驗-重試的閉環(huán)能大幅提升多模態(tài) Agent 的可靠性。4.4 多模態(tài) Agent 的規(guī)劃器與注意點當(dāng) Agent 需要處理的任務(wù)比較長時建議把規(guī)劃器和執(zhí)行器分開。規(guī)劃器負(fù)責(zé)拆解任務(wù)順序執(zhí)行器負(fù)責(zé)具體步驟。比如整理這張財務(wù)報表并生成摘要可以拆成先 OCR 提取表格結(jié)構(gòu) → 再按列匯總關(guān)鍵指標(biāo) → 分條輸出摘要。每步調(diào)用不同的視覺能力或工具最后再合并結(jié)果。做多模態(tài) Agent 時除了模型能力還要注意三個問題。一個是圖片指紋與緩存。用戶上傳的圖片可能非常大如果每次都把原圖傳給模型不僅浪費 token 還會變慢。建議在上傳環(huán)節(jié)做壓縮和緩存比如把長邊壓縮到 1280px保存一張壓縮副本以圖片 MD5 為 key 緩存視覺理解結(jié)果。相同圖片重復(fù)問答時直接走緩存成本能降一半。另一個是 Token 預(yù)算控制。多模態(tài)模型的視覺 token 消耗很容易失控。一張 2K 分辨率的截圖可能產(chǎn)生超過 1500 個視覺 token放大到整個對話歷史里顯存和速度都扛不住。建議在 Agent 對話中定期精簡歷史只保留關(guān)鍵文本摘要 最近一張圖的縮略信息而不是把所有圖片都留在上下文里。還有一點是工具選擇的容錯。多模態(tài) Agent 經(jīng)常出現(xiàn)工具調(diào)對了但參數(shù)抽錯了的情況。比如用戶給了一張表格截圖模型想調(diào)用生成柱狀圖工具但把參數(shù) date_column 和 value_column 抽反了。我建議工具設(shè)計時多用顯式枚舉或 schema 校驗寧可多一步讓用戶確認(rèn)也不要讓它靜默出錯。5. 常見問題與排查技巧我把踩過的坑都寫在這里5.1 顯存不足與 OOM 排查多模態(tài)任務(wù) OOM 的發(fā)生頻率遠高于純文本任務(wù)最常見的原因有三個。一是圖片尺寸過大。模型默認(rèn)會動態(tài)把圖片切塊一張 4000x3000 的圖片可能切成幾十個 patch視覺 token 數(shù)量爆炸。排查方法是在模型輸入前打印 image token 的數(shù)量如果單張圖超過 1500 token就先壓縮圖片。二是并發(fā)請求擠爆顯存。vLLM 這類框架會根據(jù)max_num_seqs和max-model-len提前分配 KV Cache如果你設(shè)的 max-model-len 太大比如 32K16G 卡很容易在低并發(fā)時 OOM。建議把 max-model-len 調(diào)到 4096 或 8192并開啟--enable-prefix-caching減少重復(fù)計算。三是多輪對話的 KV Cache 累積。多模態(tài)對話中每輪都帶圖歷史圖片的視覺 token 會一直占著顯存。精簡歷史的方案上文已經(jīng)提到另一個辦法是限制對話的最大輪數(shù)比如超過 8 輪就自動摘要前文并清空圖片。5.2 視覺理解效果不佳的定位方法如果模型給出的答案明顯不對先別急著換模型或調(diào) prompt。我用了一個降級拆分的排查方法。第一步先不看圖只把圖中應(yīng)該提取出來的關(guān)鍵文本OCR 結(jié)果單獨拿給模型問同樣的題。如果這時模型答對了說明問題出在視覺編碼環(huán)節(jié)而不是語言理解環(huán)節(jié)。第二步如果 OCR 文本單獨能答對就把 OCR 結(jié)果和原圖一起給模型看它是被多余信息干擾了還是根本沒看見圖里的重點。第三步如果 OCR 都提取不對那就是視覺編碼器或圖片質(zhì)量的問題?？梢栽囋嚀Q更高分辨率的輸入或者換視覺能力更強的模型比如 InternVL。這個方法在絕大多數(shù)情況下都能快速定位問題所在。之前有個項目識別電子合同里的金額總是出錯最后排查發(fā)現(xiàn)是合同掃描件本身分辨率太低印章和數(shù)字疊在一起視覺編碼器提取不到完整數(shù)字。換了更高清的掃描文件后問題立刻解決。5.3 多模態(tài)數(shù)據(jù)加載常見問題速查問題現(xiàn)象可能原因解決方案訓(xùn)練時圖片加載異常路徑拼接錯誤或圖片損壞寫數(shù)據(jù)校驗?zāi)_本逐條檢查圖片能否打開loss 波動大、不收斂視覺編碼器層也加了 LoRA 且 lr 過高視覺部分 lr 降為語言部分的 1/10或先凍結(jié)視覺編碼器模型輸出和圖片無關(guān)圖片 token 被截斷檢查 max_length確保給圖片 token 留足空間圖片上傳太慢請求里傳了 base64 原圖壓縮圖片后再傳輸長邊限制到 1280-1600px工具調(diào)用參數(shù)識別錯誤圖片信息密度高、文字小prompt 中要求逐字核對 工具層加參數(shù)校驗重試檢索時永遠召回同一批文檔向量化時圖片描述太泛化改進 Caption 質(zhì)量加入關(guān)鍵數(shù)字、實體、結(jié)構(gòu)說明5.4 評測多模態(tài)模型到底行不行得用數(shù)據(jù)說話很多團隊把多模態(tài)模型接進來之后憑肉眼感覺判斷效果好不好。這其實不太靠譜因為視覺任務(wù)受圖片分布影響太大同一張圖換個角度、換種光照結(jié)果差異就會很大。一個簡單但有效的評測方法是圍繞你的業(yè)務(wù)場景準(zhǔn)備 200 到 500 條評測樣本每條樣本由圖片 問題 參考答案或標(biāo)注組成。評測時設(shè)置兩種任務(wù)類型。生成類任務(wù)用 LLM-as-a-Judge。就是讓一個更強的模型比如 GPT-4o 或更大參數(shù)的開源模型來給回答打分打分維度包括準(zhǔn)確性、完整性和與圖片的相關(guān)性。打分 prompt 要盡量具體比如如果回答中包含錯誤金額扣 3 分這類規(guī)則。結(jié)構(gòu)化提取任務(wù)用精確匹配或字段級 F1。比如識別發(fā)票金額就比對模型輸出的金額字符串是否和標(biāo)注一致。建議按字段分別計算避免一個字段錯誤影響整體判斷。另外提醒一點評測集要定期更新把線上真實的 bad case 沉淀進去。我習(xí)慣每周從線上日志里撈 50 條效果不佳的樣本人工標(biāo)注后加入評測集。這樣每次發(fā)版前跑一遍評測效果是升是降一目了然基本不會出現(xiàn)感覺變好了實際上線后被用戶罵的情況。6. 未來方向與學(xué)習(xí)路線2026 年這些能力會更值錢從整個行業(yè)趨勢來看多模態(tài)技術(shù)棧里的幾個方向值得持續(xù)關(guān)注。第一個是視頻理解。很多團隊做完了圖文理解接下來自然想處理視頻內(nèi)容。但視頻理解比圖片理解要難不少因為視頻是時空數(shù)據(jù)的組合需要處理幀間時序關(guān)系。目前開源模型在短視頻片段理解上已經(jīng)有基礎(chǔ)能力但長視頻、多鏡頭切換、音頻與畫面聯(lián)合理解仍然有大量優(yōu)化空間。16G 顯存現(xiàn)在要跑視頻模型非常吃力建議先用 API 或蒸餾方案驗證效果再考慮本地化。第二個是多模態(tài)評測和可觀測性。隨著模型越來越多怎么量化評估多模態(tài)效果會變成剛需。會寫評測工具鏈、會設(shè)計 bad-case 分析系統(tǒng)的人在各團隊里都會比較吃香。第三個是端側(cè)多模態(tài)。手機、邊緣設(shè)備上跑多模態(tài)模型會催生很多新應(yīng)用場景。MiniCPM-V 這類輕量模型的迭代會越來越快端側(cè)推理框架和量化壓縮技術(shù)也會成為熱門技能。學(xué)習(xí)路線方面我建議分三步走。第一步是跑通一個 16G 顯存的模型把部署、API 封裝、文圖問答、OCR 這四個基礎(chǔ)能力做扎實。你已經(jīng)會純文本開發(fā)的話這一步大概一到兩周就能完成。第二步是做一個小而完整的業(yè)務(wù)閉環(huán)。比如做一個發(fā)票拍照識別 自動歸檔 信息錄入的小工具覆蓋從圖片輸入到結(jié)構(gòu)化輸出的完整流程。過程里最好把數(shù)據(jù)校驗、prompt 調(diào)優(yōu)、異常兜底這些都寫上。這個階段會在實踐中理解多模態(tài)應(yīng)用開發(fā)的完整鏈路。第三步是根據(jù)項目需要深入 LoRA 微調(diào)或多模態(tài) RAG/Agent。把評測體系搭起來用數(shù)據(jù)驅(qū)動迭代。到了這一步你已經(jīng)能獨立負(fù)責(zé)一個多模態(tài)項目的技術(shù)選型和落地了。我在這個領(lǐng)域踩過的坑比多數(shù)人都要多但做下來最大的體會是多模態(tài)開發(fā)并不比純文本開發(fā)難太多關(guān)鍵在于養(yǎng)成用數(shù)據(jù)、評測、迭代驅(qū)動的習(xí)慣同時要對視覺編碼器、token 消耗、顯存預(yù)算這些多模態(tài)特有的問題保持敏感。把這篇博客里提到的方法都過一遍你至少可以省下兩周的自我摸索時間。 2026年多模態(tài)視覺大模型開發(fā)實戰(zhàn)：架構(gòu)、量化、微調(diào)與落地
2026年做多模態(tài)和視覺大模型開發(fā)這幾件事必須提前想清楚從去年開始我陸續(xù)幫團隊落地了好幾個多模態(tài)相關(guān)的項目——圖文檢索、視覺問答、還有幾個內(nèi)部效率工具。說實話多模態(tài)開發(fā)跟純文本大模型完全是兩套玩法。以前做 LLM 應(yīng)用說白了就是 prompt 工程加 RAG最多再調(diào)調(diào)參數(shù)。但一旦涉及到視覺、音頻這些模態(tài)模型選型、顯存規(guī)劃、數(shù)據(jù)管線、評測方式全都變了。這篇博文就把我做多模態(tài)和視覺大模型開發(fā)實戰(zhàn)的一些積累整理出來。內(nèi)容包括整體技術(shù)架構(gòu)怎么拆分、16G 顯存能跑哪些模型、多模態(tài)融合到底怎么融、多模態(tài) RAG 和 Agent 怎么做、以及常見坑的排查思路。目標(biāo)是讓正在入門或準(zhǔn)備轉(zhuǎn)方向的同學(xué)少走彎路也讓已經(jīng)上手的同行能對照查漏補缺。1. 多模態(tài)開發(fā)全局思路先搞清楚架構(gòu)再動手1.1 多模態(tài)大模型的架構(gòu)流派做多模態(tài)之前先把架構(gòu)這件事想明白。市面上主流的多模態(tài)大模型大體上可以分成三類。第一類是雙塔融合結(jié)構(gòu)典型代表是 CLIP 和 SigLIP。這種結(jié)構(gòu)把圖像和文本分別編碼成向量然后拉到同一個向量空間里做相似度匹配。優(yōu)點是很輕量訓(xùn)練和推理都比較快適合做圖文檢索、零樣本分類這類任務(wù)。但缺點是它不擅長生成類任務(wù)因為本質(zhì)上它是一個度量學(xué)習(xí)框架不是生成模型。第二類是Tokenizer 統(tǒng)一結(jié)構(gòu)代表就是 GPT-4o、Gemini 這類原生多模態(tài)模型。它們把圖像、音頻都 Token 化喂給同一個 Transformer。這類模型有多模態(tài)能力上限最高但基本都是閉源或超大參數(shù)開源社區(qū)目前還很難復(fù)現(xiàn)。第三類是視覺編碼器LLM的復(fù)合結(jié)構(gòu)目前開源多模態(tài)模型里最主流Qwen2-VL、InternVL、MiniCPM-V 都是這類。圖像先經(jīng)過一個視覺編碼器比如 SigLIP 或 ViT變成視覺 Token再由一個投影層映射到語言模型的輸入空間。這種結(jié)構(gòu)的核心優(yōu)勢在于語言模型部分可以沿用純文本模型的成熟權(quán)重視覺部分可以靈活替換或凍結(jié)/微調(diào)。在 16G 顯存這個約束下能實踐的主要就是第三種結(jié)構(gòu)。后面我講到的模型選型、微調(diào)方案、Agent 開發(fā)也都是基于這個架構(gòu)展開的。1.2 開發(fā)路徑和技能棧拆解多模態(tài)開發(fā)比純文本開發(fā)多出來的一個關(guān)鍵環(huán)節(jié)是視覺編碼器的處理。整個鏈路可以拆成四個層次。第一個層次是推理部署就是能把現(xiàn)成模型跑起來。需要掌握 HuggingFace Transformers 的基本用法、vLLM 或 Ollama 這類推理框架以及量化工具。這個層次對應(yīng)的是會用。第二個層次是應(yīng)用開發(fā)就是基于多模態(tài)模型的 API 或本地部署實現(xiàn)具體的業(yè)務(wù)功能。比如圖文理解、視覺問答、多模態(tài) RAG這些需要懂 prompt 設(shè)計、檢索策略、后端服務(wù)封裝。這個層次對應(yīng)的是會做產(chǎn)品。第三個層次是模型微調(diào)與適配就是要解決預(yù)訓(xùn)練模型在特定業(yè)務(wù)場景下效果不佳的問題。需要掌握 LoRA、QLoRA 這些參數(shù)高效微調(diào)方法理解視覺 Token 是怎么參與訓(xùn)練的會處理多模態(tài)數(shù)據(jù)的預(yù)處理流程。第四個層次是算法創(chuàng)新就是做多模態(tài)融合算法的改進。這個層次已經(jīng)接近科研了要關(guān)注多模態(tài)特征對齊、跨模態(tài)注意力、模態(tài)缺失處理這些研究方向。在 2026 年這個時間點前兩個層次是必會第三個層次是加分項第四個層次是少數(shù)人的選擇。我建議普通開發(fā)者把主要精力放在第一和第二個層次上把推理部署和應(yīng)用開發(fā)玩熟再根據(jù)工作需要決定要不要深入微調(diào)。1.3 一張圖看懂多模態(tài)應(yīng)用的技術(shù)棧我自己習(xí)慣把多模態(tài)應(yīng)用的技術(shù)棧分成五層基礎(chǔ)設(shè)施層GPU 服務(wù)器、推理引擎vLLM / TensorRT-LLM / Ollama、模型量化工具模型層開源多模態(tài)模型Qwen2-VL、InternVL、MiniCPM-V或其 API能力層圖文理解、OCR 識別、視覺定位Grounding、視頻理解、音頻理解應(yīng)用框架層LangChain / LlamaIndexRAG、Agent 框架ReAct / Function Calling、向量數(shù)據(jù)庫業(yè)務(wù)層知識庫問答、內(nèi)容審核、輔助駕駛、醫(yī)療影像、工業(yè)質(zhì)檢等從開發(fā)者的角度看多數(shù)工作集中在能力層和應(yīng)用框架層之間的接口處。你需要清楚模型本身能做什么、不能做什么然后決定哪些能力要自己開發(fā)哪些直接調(diào)現(xiàn)成的 API。2. 16G 顯存怎么選模型、怎么量化顯存焦慮的破局方法2.1 主流開源多模態(tài)模型選型對比顯存不夠用是我在私信里被問得最多的問題。很多人以為跑多模態(tài)模型怎么也得 40G 顯存以上但實際經(jīng)過量化和小 Batch 配置16G 的可選范圍已經(jīng)不小了。我按實際使用體驗把適合 16G 顯存跑的多模態(tài)模型整理了一下。模型參數(shù)量視覺編碼器量化后顯存占用16G 卡適合場景備注Qwen2-VL-7B8.3BSigLIP-So400M8-10GAWQ 4bit通用圖文理解、OCR、視頻理解效果均衡工具調(diào)用能力強Qwen2.5-VL-7B8.4BSigLIP-So400M8-10GAWQ 4bit通用圖文問答、Agent相比 2-VL 推理更快InternVL2-8B8.1BInternViT-300M9-11GGPTQ 4bit中文場景、多輪對話中文數(shù)據(jù)支持好MiniCPM-V 2.68.1BSigLIP-So400M7-9GAWQ 4bit端側(cè)部署、長圖理解支持 180 萬像素輸入CogVLM2-9B9.7BViT12-14GGPTQ 4bit復(fù)雜視覺推理顯存偏緊吞吐受限Florence-2 0.7B0.7BViT-B2-3GOCR、定位、圖像描述極輕量只做視覺任務(wù)提示16G 顯存想跑得舒服優(yōu)先考慮 Qwen2-VL-7B 或 InternVL2-8B。前者綜合能力強且生態(tài)好后者中文場景表現(xiàn)更穩(wěn)。MiniCPM-V 適合顯存更小或端側(cè)部署的場景。2.2 量化方案選擇AWQ、GPTQ 怎么權(quán)衡量化是讓大模型在有限顯存下跑起來的核心手段。對于多模態(tài)模型量化的主要對象是語言模型部分視覺編碼器一般保持 FP16。因為視覺編碼器的參數(shù)量相對較小而且它對量化誤差更敏感。我在實踐中對比過 AWQ 和 GPTQ 兩種主流量化方案說下實際感受。AWQActivation-aware Weight Quantization基于激活值分布來選擇保留哪些權(quán)重通道的精度量化后模型輸出質(zhì)量更穩(wěn)視覺任務(wù)尤其明顯。它的速度也更快通常只在量化前做一次校準(zhǔn)校準(zhǔn)集大概需要 128-256 條樣本。我測試下來Qwen2-VL-7B 用 AWQ 和 FP16 相比圖像理解任務(wù)的準(zhǔn)確率差距基本在 2 個百分點以內(nèi)。GPTQ 則基于二階近似誤差最小化對語言任務(wù)的保持更好但在視覺任務(wù)上偶爾會出現(xiàn)目標(biāo)邊界框偏移之類的問題。它的歷史更早工具鏈成熟不過對于多模態(tài)場景我目前更傾向 AWQ。Bit 數(shù)方面4bit 是顯存和效果之間的甜點區(qū)。2bit 基本不用考慮圖片細(xì)節(jié)會嚴(yán)重丟失。如果顯存還有余量可以嘗試 4bit KV Cache 量化的組合比如 Qwen2-VL-7B 在 AWQ 4bit 基礎(chǔ)上再加 KV Cache 8bit顯存可以壓到 8G 左右同時保持良好效果。2.3 一個真實可跑的 16G 顯存部署示例我用一張 RTX 4080 16G 部署過 Qwen2-VL-7B-AWQ整個流程比較順分享出來給你參考。使用的推理后端是 vLLM它對 AWQ 支持很成熟OpenAI 兼容接口也讓后續(xù)開發(fā)省了很多事。部署步驟大概是這樣的# 1. 安裝 vllm建議使用 0.6 以上版本 pip install vllm # 2. 啟動模型關(guān)鍵參數(shù)是 quantization 和 max-model-len vllm serve Qwen/Qwen2-VL-7B-Instruct-AWQ \ --quantization awq \ --max-model-len 4096 \ --limit-mm-per-prompt image2 \ --gpu-memory-utilization 0.9 \ --port 8000這里--limit-mm-per-prompt控制每輪請求最多帶幾張圖我設(shè)為 2 是為了防止顯存溢出。--gpu-memory-utilization 0.9是讓 vLLM 最多用 90% 顯存做 KV Cache留一點余量給突發(fā)請求。啟動后用 Python 請求一下接口驗證import base64 import requests # 準(zhǔn)備一張測試圖片 with open(test.jpg, rb) as f: img_b64 base64.b64encode(f.read()).decode() payload { model: Qwen/Qwen2-VL-7B-Instruct-AWQ, messages: [ { role: user, content: [ {type: image_url, image_url: {url: fdata:image/jpeg;base64,{img_b64}}}, {type: text, text: 這張圖片里有什么} ] } ], max_tokens: 512 } resp requests.post(http://localhost:8000/v1/chat/completions, jsonpayload) print(resp.json()[choices][0][message][content])這套方案實測單張 16G 卡可以支持約 4 個并發(fā)請求單請求響應(yīng)時間在 1-2 秒級別做內(nèi)部工具和小規(guī)模產(chǎn)品驗證完全夠用。3. 多模態(tài)融合算法與視覺模型微調(diào)原理與實操兩手抓3.1 多模態(tài)融合的三個層面大家在網(wǎng)上經(jīng)?？吹蕉嗄B(tài)融合算法這個詞但不同場景下它指的東西差別很大。我按實際工作的層級拆解了一下。特征層面融合這是最底層也最經(jīng)典的融合方式。圖像經(jīng)過編碼器得到視覺特征向量文本經(jīng)過編碼器得到文本特征向量然后把它們拼接或加權(quán)求和再送入分類器或生成器。CLIP 的對比學(xué)習(xí)、雙塔模型的信息檢索本質(zhì)都屬于這一層。特征層面融合的優(yōu)勢是計算量可控適合做檢索和分類任務(wù)。交互層面融合視覺特征和文本特征在 Transformer 的每一層里互相做 Attention也就是交叉注意力。這種方式信息交互更充分但對算力要求更高訓(xùn)練難度也更大。Flamingo 的 Perceiver Resampler、Qwen2-VL 中視覺 Token 接入 LLM 的方式都屬于這個范疇。決策層面融合多個模態(tài)分別獨立推理最后在決策層投票或加權(quán)。比如一個模型只看圖、一個模型只看文本最后對結(jié)果做融合判斷。這種方式在不同模態(tài)的模型無法聯(lián)合訓(xùn)練時比較實用容錯性也更好但信息交互程度最低。我在實際項目里總結(jié)的經(jīng)驗是檢索類任務(wù)用特征層面融合就夠了理解類任務(wù)需要交互層面融合決策層面融合適合做兜底或集成。如果要做多模態(tài)融合算法改進方向的產(chǎn)出優(yōu)先在交互層面做文章這個方向的可挖掘空間最大。3.2 視覺編碼器的核心作用多模態(tài)模型里視覺編碼器承擔(dān)著翻譯官的角色。它把像素級的圖片輸入轉(zhuǎn)換成語言模型能理解的 Token 序列。目前主流的開源多模態(tài)模型使用的視覺編碼器主要分兩派。一派是 SigLIP。它的特點是訓(xùn)練方式上做了改進用 Sigmoid 損失替代了 InfoNCE 損失訓(xùn)練速度更快長尾數(shù)據(jù)上的表現(xiàn)也更穩(wěn)定。Qwen2-VL、MiniCPM-V 都采用了 SigLIP。另一派是 InternViTInternVL 系列自研的視覺編碼器在視覺感知的細(xì)節(jié)上做了強化特別適合做文檔理解和屏幕截圖理解。視覺編碼器內(nèi)部通常會做 Multi-View 或多尺度處理。比如 Qwen2-VL 會把圖片動態(tài)切分成多個像素塊Patch每個 Patch 單獨編碼再通過 MLP 投影層映射到語言模型的空間。這樣對大圖、長圖的處理效果會好很多。但這也會帶來視覺 Token 數(shù)量膨脹的問題——一張 1280x1280 的圖可能產(chǎn)生上千個視覺 Token直接拖累推理速度。一個實用的經(jīng)驗是如果你的任務(wù)場景是看清圖里的文字或定位目標(biāo)物體優(yōu)先選擇視覺編碼器更強的模型InternVL、Qwen2.5-VL如果是理解整張圖的語義選通用型模型的默認(rèn)配置就行沒必要過度追求分辨率。3.3 LoRA 微調(diào)實操參數(shù)計算與效果對比微調(diào)多模態(tài)模型時大多數(shù)人會直接上 LoRA 或 QLoRA。這里有個概念必須先厘清在多模態(tài)模型里L(fēng)oRA 可以加在語言模型部分也可以加在投影層和視覺編碼器上。不同位置的 LoRA 對不同能力的影響差異很大。我做過一組實驗對 Qwen2-VL-7B 分別做了三種 LoRA 方案方案 A只對語言模型部分加 LoRA最常見的做法方案 B對語言模型 投影層加 LoRA方案 C對語言模型 投影層 視覺編碼器后幾層加 LoRA訓(xùn)練數(shù)據(jù)用的是我整理的一批票據(jù)識別結(jié)構(gòu)化提取數(shù)據(jù)1600 條左右在單張 A100 上訓(xùn)練了 2 個 epoch實際 16G 顯存用 QLoRA 也可復(fù)現(xiàn)。結(jié)果是方案 A 在文字結(jié)構(gòu)化提取上 F1 得分提升最明顯從 0.62 到 0.87達到了業(yè)務(wù)可用水平方案 B 的提升反而不如 A因為投影層參數(shù)如果改動過大可能破壞原本的對齊空間方案 C 在把模型沒見過的票據(jù)版式描述出來這個能力上有幫助但訓(xùn)練穩(wěn)定性差損失波動大容易過擬合。所以我的建議是先無腦從語言模型 LoRA 開始rank 取 16 到 32如果任務(wù)非常依賴視覺理解再考慮把視覺編碼器末層也解凍訓(xùn)練。不要一上來就把所有部分都加 LoRA出了問題根本沒法定位。一個 LoRA 訓(xùn)練時的關(guān)鍵參數(shù)參考參數(shù)名建議值說明r16-32太低擬合不了太高容易過擬合alpha32通常取 r 的 1-2 倍target_modulesq_proj, k_proj, v_proj, o_proj語言模型的注意力層即可learning_rate1e-4 到 3e-4比純文本微調(diào)略低max_length2048多模態(tài)輸入 token 多太長顯存不夠batch_size1-2累積梯度受顯存限制配合 grad_accumulation注意多模態(tài) LoRA 訓(xùn)練時max_length要綜合圖片 token 和文本 token 一起算。比如 Qwen2-VL 默認(rèn)對每張圖會動態(tài)切 patch一張 1024x1024 的圖可能占幾百個 token所以文本部分不要寫太長不然會截斷。3.4 數(shù)據(jù)管線搭建圖文對到底怎么準(zhǔn)備多模態(tài)微調(diào)的數(shù)據(jù)格式和純文本有非常大的不同。以 Qwen2-VL 為例訓(xùn)練數(shù)據(jù)的基本格式是[ { id: sample_001, conversations: [ { role: user, content: [ {type: image, image: train/001.jpg}, {type: text, text: 請識別這張發(fā)票的總金額和開票日期} ] }, { role: assistant, content: [ {type: text, text: 總金額1234.56元開票日期2025-11-02} ] } ] } ]這個格式里最容易踩坑的點是 image 字段。如果 image 傳的是相對路徑訓(xùn)練腳本通常要根據(jù)一個 base_path 拼接成絕對路徑如果 image 傳的是 base64 字符串那么需要注意轉(zhuǎn)義問題和硬盤緩存問題。我建議在訓(xùn)練前先寫一個數(shù)據(jù)校驗?zāi)_本把每條樣本都取出來看一眼確認(rèn)圖片能正常打開、尺寸合適、文字沒截斷。數(shù)據(jù)量上如果只是做垂直領(lǐng)域適配一兩千條高質(zhì)量數(shù)據(jù)往往就夠了。但數(shù)據(jù)質(zhì)量要求很高——至少要有 10% 的負(fù)樣本或邊界案例否則模型容易產(chǎn)生幻覺在答案里編造圖片里沒有的內(nèi)容。4. 多模態(tài) RAG 與 Agent 實踐把圖文知識庫變成可用的產(chǎn)品4.1 多模態(tài) RAG 和純文本 RAG 的本質(zhì)差異多模態(tài) RAG 火起來是有原因的。傳統(tǒng)的純文本 RAG 只能檢索和生成文字內(nèi)容但現(xiàn)實世界里有大量知識是以圖片、掃描件、截圖的形態(tài)存在的。一個企業(yè)知識庫如果只能檢索文字等于把大約 30% 的信息直接扔掉了。多模態(tài) RAG 要解決的問題就是讓系統(tǒng)既能看、又能搜、還能回答問題。多模態(tài) RAG 和純文本 RAG 的本質(zhì)差異體現(xiàn)在兩個環(huán)節(jié)。索引階段純文本 RAG 直接把文本切塊嵌入多模態(tài) RAG 得先考慮——是一張圖配一段文字描述作為一個整體塊還是把圖里的 OCR 文字單獨提取出來建索引不同的策略決定了后續(xù)檢索的質(zhì)量。檢索與生成階段多模態(tài) RAG 里 query 可能是文字也可能是圖片——用戶拍一張海報來問這是什么活動。這種情況下query 和文檔之間的相似度計算就跨了模態(tài)。4.2 圖文知識庫的切分與索引策略我實踐下來比較可靠的多模態(tài)索引策略是雙路索引 交叉檢索。第一路是圖文聯(lián)合索引。對于帶圖的文檔PPT、PDF、網(wǎng)頁保留圖片相鄰文字作為一個整體文檔塊用多模態(tài)模型對圖片生成一段描述Caption把這個描述和原文字拼接再統(tǒng)一做向量化。這樣檢索的時候既可以通過文字匹配到內(nèi)容也可以通過圖片描述匹配到視覺信息。第二路是 OCR 文本索引。把所有圖片里的文字都做 OCR 提取純文本嵌入單獨建一個索引。這樣當(dāng)用戶查詢里包含明確的數(shù)字、專有名詞時OCR 文本索引的精準(zhǔn)度會很高。檢索階段把兩路結(jié)果做一個重排融合比如 RRFReciprocal Rank Fusion方法把兩路各自的排名結(jié)果合并。實際操作的時候我用 LlamaIndex 搭過一個基礎(chǔ)版本核心代碼如下你可以參考from llama_index.core import VectorStoreIndex, SimpleDirectoryReader from llama_index.multi_modal_llms.ollama import OllamaMultiModal from llama_index.core.node_parser import SentenceSplitter from llama_index.vector_stores.qdrant import QdrantVectorStore import qdrant_client # 1. 讀入圖文混排的文檔 documents SimpleDirectoryReader(./data/ppt).load_data() # 2. 對每個文檔塊生成圖像描述 mm_llm OllamaMultiModal(modelqwen2.5-vl:7b, temperature0.1) for doc in documents: if hasattr(doc, image_path): desc mm_llm.complete( prompt用20個字以內(nèi)描述這張圖片的內(nèi)容。, image_documents[doc] ) # 把描述并入文本節(jié)點 doc.text f[圖片描述] {desc} \n [原文本] {doc.text} # 3. 切塊向量化并寫入 qdrant client qdrant_client.QdrantClient(path./qdrant_db) vector_store QdrantVectorStore(clientclient, collection_namemultimodal_docs) splitter SentenceSplitter(chunk_size512, chunk_overlap50) nodes splitter.get_nodes_from_documents(documents) index VectorStoreIndex(nodes, vector_storevector_store) # 4. 查詢 query_engine index.as_query_engine(similarity_top_k4) resp query_engine.query(這份材料的核心結(jié)論是什么) print(resp)這里比較關(guān)鍵的是第二步——用多模態(tài)模型生成圖片描述。描述的質(zhì)量直接影響檢索召回率。生成描述時不要只寫這是一張圖表要盡量包含圖中的關(guān)鍵數(shù)字和結(jié)論。你可以手動挑 20 條典型圖片把描述風(fēng)格打磨好再批量跑。4.3 多模態(tài) Agent 架構(gòu)從看圖說話到看懂就做多模態(tài) Agent 和多模態(tài)模型的最大區(qū)別在于前者不光要理解還要執(zhí)行——根據(jù)圖片內(nèi)容做決策、操作工具、調(diào)用 API。打個比方視覺模型像一個解說員能告訴你畫面里發(fā)生了什么多模態(tài) Agent 更像一個助理看到信息后要替你干活。一個典型的多模態(tài) Agent 流程是這樣的用戶上傳一張訂單截圖并提問這個訂單發(fā)貨了嗎Agent 調(diào)用視覺模型識別截圖中的訂單號、物流狀態(tài)Agent 根據(jù)識別結(jié)果調(diào)用訂單查詢 API 獲取最新物流信息綜合視覺信息和 API 返回結(jié)果組織最終答案在實現(xiàn)層面Qwen2-VL 系列目前對 Function Calling 支持得不錯。模型在圖文輸入下可以輸出結(jié)構(gòu)化的工具調(diào)用指令格式和 OpenAI 的 Function Calling 一脈相承。一個簡易的 ReAct 多模態(tài) Agent 路徑示例如下import json from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) tools [ { type: function, function: { name: query_order, description: 根據(jù)訂單號查詢訂單狀態(tài), parameters: { type: object, properties: { order_id: {type: string} }, required: [order_id] } } } ] def query_order(order_id: str) - str: return json.dumps({order_id: order_id, status: 已發(fā)貨, tracking: SF1234567890}) # 用戶上傳截圖 messages [ { role: user, content: [ {type: image_url, image_url: {url: data:image/jpeg;base64,...}}, {type: text, text: 麻煩幫我查一下這個訂單的狀態(tài)} ] } ] # 第一輪讓模型理解圖片并產(chǎn)出工具調(diào)用 resp client.chat.completions.create( modelQwen/Qwen2-VL-7B-Instruct-AWQ, messagesmessages, toolstools, tool_choiceauto ) # 解析工具調(diào)用 assistant_msg resp.choices[0].message if assistant_msg.tool_calls: for tc in assistant_msg.tool_calls: args json.loads(tc.function.arguments) result query_order(args[order_id]) # 把工具結(jié)果返回給模型生成最終回復(fù) messages.append(assistant_msg) messages.append({ role: tool, tool_call_id: tc.id, content: result }) final_resp client.chat.completions.create( modelQwen/Qwen2-VL-7B-Instruct-AWQ, messagesmessages, toolstools ) print(final_resp.choices[0].message.content)這里有一個我在實踐中踩過的坑多模態(tài)模型輸出 tool_call 時如果圖片里要識別的文字比較長比如一長串訂單號容易識別錯一兩位。我后來在 prompt 里加了請仔細(xì)核對訂單號逐字識別這樣的提示同時在工具調(diào)用后加了一層校驗邏輯——如果查詢 API 返回訂單不存在就重新讓模型再看一遍圖。這種識別-執(zhí)行-校驗-重試的閉環(huán)能大幅提升多模態(tài) Agent 的可靠性。4.4 多模態(tài) Agent 的規(guī)劃器與注意點當(dāng) Agent 需要處理的任務(wù)比較長時建議把規(guī)劃器和執(zhí)行器分開。規(guī)劃器負(fù)責(zé)拆解任務(wù)順序執(zhí)行器負(fù)責(zé)具體步驟。比如整理這張財務(wù)報表并生成摘要可以拆成先 OCR 提取表格結(jié)構(gòu) → 再按列匯總關(guān)鍵指標(biāo) → 分條輸出摘要。每步調(diào)用不同的視覺能力或工具最后再合并結(jié)果。做多模態(tài) Agent 時除了模型能力還要注意三個問題。一個是圖片指紋與緩存。用戶上傳的圖片可能非常大如果每次都把原圖傳給模型不僅浪費 token 還會變慢。建議在上傳環(huán)節(jié)做壓縮和緩存比如把長邊壓縮到 1280px保存一張壓縮副本以圖片 MD5 為 key 緩存視覺理解結(jié)果。相同圖片重復(fù)問答時直接走緩存成本能降一半。另一個是 Token 預(yù)算控制。多模態(tài)模型的視覺 token 消耗很容易失控。一張 2K 分辨率的截圖可能產(chǎn)生超過 1500 個視覺 token放大到整個對話歷史里顯存和速度都扛不住。建議在 Agent 對話中定期精簡歷史只保留關(guān)鍵文本摘要 最近一張圖的縮略信息而不是把所有圖片都留在上下文里。還有一點是工具選擇的容錯。多模態(tài) Agent 經(jīng)常出現(xiàn)工具調(diào)對了但參數(shù)抽錯了的情況。比如用戶給了一張表格截圖模型想調(diào)用生成柱狀圖工具但把參數(shù) date_column 和 value_column 抽反了。我建議工具設(shè)計時多用顯式枚舉或 schema 校驗寧可多一步讓用戶確認(rèn)也不要讓它靜默出錯。5. 常見問題與排查技巧我把踩過的坑都寫在這里5.1 顯存不足與 OOM 排查多模態(tài)任務(wù) OOM 的發(fā)生頻率遠高于純文本任務(wù)最常見的原因有三個。一是圖片尺寸過大。模型默認(rèn)會動態(tài)把圖片切塊一張 4000x3000 的圖片可能切成幾十個 patch視覺 token 數(shù)量爆炸。排查方法是在模型輸入前打印 image token 的數(shù)量如果單張圖超過 1500 token就先壓縮圖片。二是并發(fā)請求擠爆顯存。vLLM 這類框架會根據(jù)max_num_seqs和max-model-len提前分配 KV Cache如果你設(shè)的 max-model-len 太大比如 32K16G 卡很容易在低并發(fā)時 OOM。建議把 max-model-len 調(diào)到 4096 或 8192并開啟--enable-prefix-caching減少重復(fù)計算。三是多輪對話的 KV Cache 累積。多模態(tài)對話中每輪都帶圖歷史圖片的視覺 token 會一直占著顯存。精簡歷史的方案上文已經(jīng)提到另一個辦法是限制對話的最大輪數(shù)比如超過 8 輪就自動摘要前文并清空圖片。5.2 視覺理解效果不佳的定位方法如果模型給出的答案明顯不對先別急著換模型或調(diào) prompt。我用了一個降級拆分的排查方法。第一步先不看圖只把圖中應(yīng)該提取出來的關(guān)鍵文本OCR 結(jié)果單獨拿給模型問同樣的題。如果這時模型答對了說明問題出在視覺編碼環(huán)節(jié)而不是語言理解環(huán)節(jié)。第二步如果 OCR 文本單獨能答對就把 OCR 結(jié)果和原圖一起給模型看它是被多余信息干擾了還是根本沒看見圖里的重點。第三步如果 OCR 都提取不對那就是視覺編碼器或圖片質(zhì)量的問題?？梢栽囋嚀Q更高分辨率的輸入或者換視覺能力更強的模型比如 InternVL。這個方法在絕大多數(shù)情況下都能快速定位問題所在。之前有個項目識別電子合同里的金額總是出錯最后排查發(fā)現(xiàn)是合同掃描件本身分辨率太低印章和數(shù)字疊在一起視覺編碼器提取不到完整數(shù)字。換了更高清的掃描文件后問題立刻解決。5.3 多模態(tài)數(shù)據(jù)加載常見問題速查問題現(xiàn)象可能原因解決方案訓(xùn)練時圖片加載異常路徑拼接錯誤或圖片損壞寫數(shù)據(jù)校驗?zāi)_本逐條檢查圖片能否打開loss 波動大、不收斂視覺編碼器層也加了 LoRA 且 lr 過高視覺部分 lr 降為語言部分的 1/10或先凍結(jié)視覺編碼器模型輸出和圖片無關(guān)圖片 token 被截斷檢查 max_length確保給圖片 token 留足空間圖片上傳太慢請求里傳了 base64 原圖壓縮圖片后再傳輸長邊限制到 1280-1600px工具調(diào)用參數(shù)識別錯誤圖片信息密度高、文字小prompt 中要求逐字核對 工具層加參數(shù)校驗重試檢索時永遠召回同一批文檔向量化時圖片描述太泛化改進 Caption 質(zhì)量加入關(guān)鍵數(shù)字、實體、結(jié)構(gòu)說明5.4 評測多模態(tài)模型到底行不行得用數(shù)據(jù)說話很多團隊把多模態(tài)模型接進來之后憑肉眼感覺判斷效果好不好。這其實不太靠譜因為視覺任務(wù)受圖片分布影響太大同一張圖換個角度、換種光照結(jié)果差異就會很大。一個簡單但有效的評測方法是圍繞你的業(yè)務(wù)場景準(zhǔn)備 200 到 500 條評測樣本每條樣本由圖片 問題 參考答案或標(biāo)注組成。評測時設(shè)置兩種任務(wù)類型。生成類任務(wù)用 LLM-as-a-Judge。就是讓一個更強的模型比如 GPT-4o 或更大參數(shù)的開源模型來給回答打分打分維度包括準(zhǔn)確性、完整性和與圖片的相關(guān)性。打分 prompt 要盡量具體比如如果回答中包含錯誤金額扣 3 分這類規(guī)則。結(jié)構(gòu)化提取任務(wù)用精確匹配或字段級 F1。比如識別發(fā)票金額就比對模型輸出的金額字符串是否和標(biāo)注一致。建議按字段分別計算避免一個字段錯誤影響整體判斷。另外提醒一點評測集要定期更新把線上真實的 bad case 沉淀進去。我習(xí)慣每周從線上日志里撈 50 條效果不佳的樣本人工標(biāo)注后加入評測集。這樣每次發(fā)版前跑一遍評測效果是升是降一目了然基本不會出現(xiàn)感覺變好了實際上線后被用戶罵的情況。6. 未來方向與學(xué)習(xí)路線2026 年這些能力會更值錢從整個行業(yè)趨勢來看多模態(tài)技術(shù)棧里的幾個方向值得持續(xù)關(guān)注。第一個是視頻理解。很多團隊做完了圖文理解接下來自然想處理視頻內(nèi)容。但視頻理解比圖片理解要難不少因為視頻是時空數(shù)據(jù)的組合需要處理幀間時序關(guān)系。目前開源模型在短視頻片段理解上已經(jīng)有基礎(chǔ)能力但長視頻、多鏡頭切換、音頻與畫面聯(lián)合理解仍然有大量優(yōu)化空間。16G 顯存現(xiàn)在要跑視頻模型非常吃力建議先用 API 或蒸餾方案驗證效果再考慮本地化。第二個是多模態(tài)評測和可觀測性。隨著模型越來越多怎么量化評估多模態(tài)效果會變成剛需。會寫評測工具鏈、會設(shè)計 bad-case 分析系統(tǒng)的人在各團隊里都會比較吃香。第三個是端側(cè)多模態(tài)。手機、邊緣設(shè)備上跑多模態(tài)模型會催生很多新應(yīng)用場景。MiniCPM-V 這類輕量模型的迭代會越來越快端側(cè)推理框架和量化壓縮技術(shù)也會成為熱門技能。學(xué)習(xí)路線方面我建議分三步走。第一步是跑通一個 16G 顯存的模型把部署、API 封裝、文圖問答、OCR 這四個基礎(chǔ)能力做扎實。你已經(jīng)會純文本開發(fā)的話這一步大概一到兩周就能完成。第二步是做一個小而完整的業(yè)務(wù)閉環(huán)。比如做一個發(fā)票拍照識別 自動歸檔 信息錄入的小工具覆蓋從圖片輸入到結(jié)構(gòu)化輸出的完整流程。過程里最好把數(shù)據(jù)校驗、prompt 調(diào)優(yōu)、異常兜底這些都寫上。這個階段會在實踐中理解多模態(tài)應(yīng)用開發(fā)的完整鏈路。第三步是根據(jù)項目需要深入 LoRA 微調(diào)或多模態(tài) RAG/Agent。把評測體系搭起來用數(shù)據(jù)驅(qū)動迭代。到了這一步你已經(jīng)能獨立負(fù)責(zé)一個多模態(tài)項目的技術(shù)選型和落地了。我在這個領(lǐng)域踩過的坑比多數(shù)人都要多但做下來最大的體會是多模態(tài)開發(fā)并不比純文本開發(fā)難太多關(guān)鍵在于養(yǎng)成用數(shù)據(jù)、評測、迭代驅(qū)動的習(xí)慣同時要對視覺編碼器、token 消耗、顯存預(yù)算這些多模態(tài)特有的問題保持敏感。把這篇博客里提到的方法都過一遍你至少可以省下兩周的自我摸索時間。