概念位置

CLIP 的訓練架構（簡化）：

 14 億組 (image, caption) 從網路爬：
 2  (photo of cat, "a fluffy orange cat sitting")
 3  (screenshot of code, "Python error: NameError x undefined")
 4  ...
 5
 6訓練：
 7  image → Image encoder（ViT-L/14）→ image_embedding
 8  caption → Text encoder（Transformer）→ text_embedding
 9
10  正向對（matching image-caption）：embedding 應該相似
11  負向對（同 batch 內其他不匹配）：embedding 應該遠
12
13  [Contrastive learning](/llm/knowledge-cards/contrastive-learning/) loss

訓完後得到：

1. 共享 embedding 空間：圖跟文字 embedding 都在 768/1024 維空間、相似度比較有意義
2. Zero-shot classification 能力：給一張圖、給 100 個文字標籤、看哪個 embedding 最接近 → 不用 fine-tune 就能分類
3. Image search / 多模態 retrieval：text 跟 image 互查、是 multimodal RAG 基底

對 VLM 的影響：

1CLIP 訓出來後：
2  image encoder 已經學會「把圖片變成有意義的 embedding」
3
4VLM 訓練時：
5  - 直接拿 CLIP 的 image encoder 當 vision encoder（凍住或一起 fine-tune）
6  - 接上 LLM、用 image-text 任務資料訓 alignment
7  - 不用從頭訓 vision encoder、省下大量 compute

跟 SigLIP 的關係：SigLIP（Zhai et al., 2023）是 Google 提出的 CLIP 變體、用 sigmoid loss 取代原本 InfoNCE、訓練更穩、品質略佳；Gemma 3 / Idefics 等用 SigLIP 而非原 CLIP。

設計責任

讀 VLM paper / model card 看到「CLIP backbone」「SigLIP encoder」「OpenCLIP weights」就是這 family。寫 code 場景的判讀：

1. CLIP 本身不是 VLM：CLIP 只有 image-text 相似度、不能生文字回答；VLM 是「CLIP 的 image encoder + LLM + alignment training」
2. 不同 CLIP 變體影響 VLM 能力：CLIP ViT-L/14 是經典、SigLIP / DFN（Apple）等變體在某些任務更強
3. Multimodal RAG 直接用 CLIP：純 image-text retrieval（如「找跟這張圖相似的 doc」）不需要完整 VLM、CLIP-like 模型就夠
4. CLIP 用於 zero-shot 分類仍實用：給定固定的 class label set（如「截圖 / 設計稿 / 程式碼 / 文件」）、CLIP 能直接 zero-shot 分類、不需要訓 specific classifier

概念位置

從圖到 image token 的轉換：

1Input image: 1024×1024 RGB
2   ↓ Patchify（切 14×14 patch、得 ~5000 個 patch）
3   ↓ Vision encoder（ViT 處理每個 patch、產 768/1024 維向量）
4   ↓ Optional: 2D position embedding
5   ↓ Optional: pooling / merging（減少 token 數）
6Image tokens: ~500-2500 個（依模型設計）
7   ↓ Projection（vision_dim → LLM hidden_dim、配合 LLM 內部維度）
8   ↓ 跟 text token 串成單一 sequence
9   ↓ Transformer 跟一般 token 一樣處理

主流 VLM 的單張圖 token 用量（粗略、依模型 / 解析度而變）：

事實查核註：上述 token 數量級依模型版本、推論配置（如「low / high detail」模式）變化、引用前以對應 model card 跟 API 文件為準。

設計責任

讀 VLM API / 推論 log 看到「image tokens used: 1247」「visual tokens: 580」就是這指標。寫 code 場景的判讀：

1. 多張截圖 = context 吃緊：一張 1500 token、丟 10 張就 15K、加上 prompt 跟回答、long context 模型才能 handle
2. 同張圖、解析度模式影響成本：許多 API 提供 low / auto / high detail 模式、low detail 約 1/10 token；OCR 需要高解析、不細節辨識可選 low
3. 本地 VLM 推論 prefill 慢：image token 多、prefill 階段（TTFT）對應變長、第一個字出來要等較久
4. API 計費通常 image token 跟 text token 同價：算成本看實際用了多少 image token、不要假設「一張圖 = 一個 token」
5. Image token 是消耗品、不是參數：跟模型內部權重不同、純粹是「這次 forward pass 的 input」

概念位置

三種 fusion 方式的對比：

1. Early Fusion（最主流）

1image → vision encoder → image tokens ─┐
2                                       ├→ concat 成單一 sequence → 同 LLM Transformer 處理
3text → tokenizer → text tokens ────────┘

• 特性：image token 跟 text token 在同一個 token sequence、共用 LLM 的 attention / FFN
• 代表：LLaVA、Qwen2-VL、Llama 3.2 Vision、Pixtral、GPT-4V 多數變體
• 優點：實作簡單、可重用 LLM 的 weight、訓練資料效率高
• 缺點：image token 佔 context、長對話 / 多圖時 context budget 吃緊

2. Cross-Attention（Flamingo-style）

1image → vision encoder → image features ─┐
2                                          │ Cross-attention 層
3text → tokenizer → tokens → LLM Transformer ──┤  插在每幾層 Transformer 之間
4                                          │ Image features 不進 LLM 主流
5output ←─────────────────────────────────┘

• 特性：image features 不變成 LLM 的 token、透過額外的 cross-attention 層注入
• 代表：Flamingo（DeepMind）、Idefics（Hugging Face）、部分 video LLM
• 優點：text token sequence 不會被 image 撐大、長文字 + 多圖比較友善
• 缺點：架構複雜、訓練難、推論伺服器支援度差

3. Native Multimodal（unified token space）

1image → patchify → discrete image tokens（如 VQ-VAE 編碼）
2text → tokenizer → text tokens
3
4兩者共用 vocab、同一個 Transformer 從頭訓
5（沒有「分開的 vision encoder」、modality 在 vocab level 統一）

• 特性：架構上「圖跟文字是同一種東西」、共用 vocab
• 代表：Chameleon（Meta 研究）、未來 trend
• 優點：理論最 clean、跨模態 generation 自然（生圖 + 生文都同個模型）
• 缺點：訓練極貴、目前研究階段為主、實用 VLM 仍以 early fusion 為主流

主流選擇對比

設計責任

讀 VLM paper / blog 看到「early fusion」「LLaVA-style」「Flamingo-style」「cross-attention adapter」就是這分類。寫 code 場景的判讀：

1. 本地跑 VLM 多半是 early fusion：選 Qwen2.5-VL / Llama 3.2 Vision / Gemma 3 Vision 都是這條路線、推論伺服器（llama.cpp、Ollama、LM Studio）都支援
2. Cross-attention 模型本地跑可能撞牆：推論伺服器對 Idefics 等 cross-attention 模型支援度差、不一定能跑 GGUF
3. 理解 fusion 影響 token 估算：early fusion 下「image token = 真的進 context」、cross-attention 下不算進 context window 主流
4. 未來 trend 是 unified：但現在做 production / 本地工作流不必等、用 early fusion 主流模型即可

概念位置

Vision encoder 在 VLM 中的位置：

1Input image（如 1024×1024 RGB）
2   ↓ 切 patch（如 14×14 patch、每張圖 ~5000 個 patch）
3   ↓ Vision encoder（ViT 或 CLIP image encoder）
4Image feature vectors（每個 patch 對應一個 768/1024 維向量）
5   ↓ Projection layer（vision dim → LLM hidden dim）
6[Image tokens](/llm/knowledge-cards/image-token/)（變成 LLM 可吃的「視覺 token」）
7   ↓
8跟 text token 混合 → Transformer → output token

主流 vision encoder 設計：

Vision encoder 的關鍵設計取捨：

1. 解析度：固定（224×224 / 336×336）vs 動態（依輸入圖大小）
2. 參數量：vision encoder 0.3B-1B 是主流；太小辨識能力差、太大拖累整體推論速度
3. Pretrain 來源：用 CLIP / SigLIP 預訓練的權重起始、加上 multimodal fine-tune；少數從頭訓
4. 跟 LLM 結合方式：見 multimodal fusion 卡

設計責任

讀 VLM model card 看到「vision tower」「ViT backbone」「image encoder」就是這部分。寫 code 場景的判讀：

1. 解析度影響細節辨識：低解析度（224）對「截圖中的小字 / 細邊框」可能模糊、看不清；高解析度（1024+）能看清楚但 token 用量大
2. Token 用量估算：一張 1024×1024 圖經過 vision encoder 後、產出 ~500-2500 image tokens（依設計）、相當於一段中等長度的文字 prompt
3. 動態解析度模型更實用：Qwen2.5-VL / GPT-4V 等支援動態解析度、不會把高清截圖縮成 224 失去細節
4. Vision encoder 不能單獨 fine-tune：通常跟 LLM 一起訓、單獨換 vision encoder 會破壞 alignment

概念位置

VLM 跟純文字 LLM 的差異：

1純文字 LLM：
2  text → tokenizer → token IDs → embedding → Transformer → output token
3
4VLM：
5  text → tokenizer → text token IDs ─┐
6                                     ├→ 統一 token sequence → Transformer → output token
7  image → vision encoder → image tokens ─┘

主流 VLM family（2026/5）：

事實查核註：主流 VLM family、本地可跑狀態、coding 場景強項在 2026/5 是估計、依模型更新跟推論伺服器支援度持續變化、引用前以對應 model card 跟 Hugging Face leaderboard 為準。

設計責任

讀 model card 看到「vision」「VL」「multimodal」「-VL」「visual」就是 VLM。寫 code 場景的判讀：

1. 任務適合用 vision 才用：純文字描述夠清楚就別塞圖、image token 多、context 跟推論成本上升
2. 本地跑 VLM 比純文字 LLM 吃資源：vision encoder 通常 0.3-1B 參數、image 處理階段算力需求大、TTFT 變長
3. OCR-heavy 任務不一定要 VLM：純 OCR（識別截圖中文字）用專門 OCR 工具（Tesseract / PaddleOCR）可能更穩、VLM 強項在「理解圖 + 推理」
4. 影片不是免費：「VLM 看影片」本質是抽 frames 變多張圖、token 用量爆炸、效益看任務

本章 framing 重點：教材整體聲明過「不放多模態」、但 VLM 在 coding 工作流的 trigger 已經響（雲端 IDE 普遍整合、本地推論伺服器陸續支援）、重新評估後加入本章。本章聚焦「跨工具世代不變的原理 + 寫 code 場景特有的判讀」、避開「具體 IDE plugin API」這類易過時內容。

本章目標

讀完本章後、你應該能：

1. 解釋 VLM 跟純文字 LLM 在 coding 場景的能力差異。
2. 看到截圖 / mockup / 設計稿時、判斷該用 VLM 還是純文字描述。
3. 對自己硬體預算選擇本地 VLM（Qwen2.5-VL / Llama 3.2 Vision / Gemma 3 Vision）。
4. 估算 VLM 推論的 context budget（image token + text token）。
5. 知道 IDE 整合 VLM 的現狀跟 trigger 訊號（什麼時候該升級到 vision-native workflow）。

Coding 場景的 vision use cases

寫 code 工作流中、有 vision 跟沒 vision 的差距：

判讀反射：任務需要看「整體 visual context」（如 layout 對齊、設計稿 → code）→ VLM 顯著贏；純 OCR（只認字）→ 專門 OCR 工具（Tesseract / PaddleOCR）可能更穩。

VLM 在 coding 場景的失敗模式

VLM 不是萬能、寫 code 場景的常見失敗：

1. 看不清細節：低解析度模式下、截圖中的小字 / 細邊框 / 1px 對齊看不出來；要開高解析度模式 + 高 image token budget
2. OCR 出錯：手寫字 / 模糊截圖 / 特殊字型上錯字、特別是中文 / 程式碼 special character
3. 空間關係推理弱：「左上角的按鈕」「flexbox 第二行第三個」這類描述、VLM 推理仍不穩
4. DPI 跟縮放問題：Retina 截圖、放大縮小、subpixel 等情況、不同 VLM 結果差異大
5. 多張圖比較：比兩張截圖差異、VLM 容易遺漏細節；最好給明確指令「請對比 A、B 兩張圖的 X 元素」

緩解：

• 截圖前裁切到「跟問題相關的區域」、別整個螢幕丟
• 高細節任務開高解析度模式（API 的 detail: high 或本地 VLM 的 min_pixels 設高）
• OCR-only 任務改用專門工具、不靠 VLM

本地 VLM 選型（2026/5）

本地可跑的主流 VLM：

事實查核註：本地 VLM 的推論伺服器支援度（llama.cpp、Ollama、MLX）依模型 / 推論伺服器版本變動很快、引用前以對應 release notes 為準。2026/5 主流是 llama.cpp 對 Qwen2-VL / Llama 3.2 Vision / Gemma 3 Vision 支援度較好、其他模型可能要等。

硬體 vs 模型對照

跟純文字 LLM 對照的記憶體成本

本地 VLM vs 雲端 VLM 的分工

跟模組六的 跨雲端 / 本地資料邊界 同邏輯、按任務分流：

混用配置（同 4.11 long-context 跟 6.4 cross-cloud 推薦模式）：

1Continue.dev config：
2  Local VLM（default for vision）：Qwen2.5-VL-32B
3    日常 vision 工作、敏感內容
4  Cloud VLM（manual switch）：Claude 4 vision
5    複雜 Figma → code、高品質要求
6
7Local text model：Qwen3-Coder-30B-Instruct
8  純文字 coding 任務

Image token 跟 context budget

VLM 推論時、image token 跟 text token 共用同一個 context window。預算估算：

 1一張 1024×1024 截圖：
 2  低細節（low detail）：~85-256 image tokens
 3  中等：~500-1000 image tokens
 4  高細節（high detail）：~1500-3000 image tokens
 5
 6VLM 對話的典型 context 構成：
 7  System prompt：~500 token
 8  之前對話歷史：~2000-5000 token
 9  3 張截圖：~3000-6000 token
10  使用者當前 prompt：~200 token
11  → 合計 ~6K-12K input
12  → 加上 generated answer 跟 reasoning trace（若 VLM 也支援 reasoning）
13  → 16K context 模型開始吃緊

實務建議：

1. VLM 工作流配 long context 模型：至少 32K context、64K 更好
2. 多輪對話控制歷史長度：每幾輪 trim 舊截圖、避免 context 爆
3. 裁切截圖、只貼相關區域：別把整個 4K 螢幕貼進來、跟問題相關的窗口就行
4. 看清楚 API 文件的 detail 模式：不需要看小字的任務用 low detail、省 token

IDE 整合的現狀（2026/5）

事實查核註：IDE 跟推論伺服器對 VLM 的支援度 2026/5 仍在快速演化、引用前以各工具當前 release notes 為準。雲端 IDE（Cursor / Claude Code）的 vision 支援多半成熟、本地 IDE plugin + 本地 VLM 的組合仍在追趕。

Trigger 訊號

判斷「該升級到 vision-native coding workflow」的訊號：

1. Continue.dev / Ollama release notes 出現「first-class vision support」「image input now stable」
2. 本地 VLM 在自己工作流的 use case（如 debug UI）品質追上 2024 年的 Claude 3 vision
3. 同事 / 社群開始日常用截圖 + IDE 互動
4. 自己工作流出現「人類花時間文字描述視覺問題給 LLM」的 friction

任一觸發 → 開始 explore 本地 vision plugin、設配置。

Multimodal RAG 跟 VLM 的關係

RAG 章節覆蓋了 text-based retrieval。Multimodal RAG 加上 vision 維度：

1傳統 RAG：
2  text query → text embedding → 檢索 text docs
3
4Multimodal RAG：
5  text or image query → multimodal embedding → 檢索 text + image
6  例：「跟這張 UI 截圖相似的設計」、「跟這個 error 一樣的 issue ticket」

Multimodal RAG 的 embedding 通常用 CLIP-style 模型（跟 4.12 embedding model internals 介紹的 text-only embedding model 訓練 paradigm 同源、都用 contrastive learning、但同時 embed 圖跟文字到共享空間）。

寫 code 場景的潛在應用：

• 設計系統 RAG：把過去設計稿、UI screenshots 都 embed 起來、給新 task 截圖時 retrieve 相似 case
• Bug screenshot 知識庫：歷史 bug 截圖 + 解法 embed、給新 bug 截圖時找相似 case
• Architecture 圖譜：架構圖 retrieve、給新需求找對應的舊架構

目前實用度比 text RAG 低、需要的 infrastructure（multimodal embedding service、image-friendly vector DB）尚不普及。

Tripwire（什麼時候值得評估 multimodal RAG）：

1. 推論伺服器（Ollama / llama.cpp）的 release notes 出現 first-class CLIP-style embedding 支援
2. Vector DB（Qdrant / Milvus / Weaviate）的 image embedding 索引從 experimental 變 stable
3. 自己工作流累積 1000+ 截圖（設計稿 / UI bug / 架構圖）、且 text 描述 retrieval 已撞天花板
4. Team 開始把「跟 X 類似的舊 case」當常規查詢、不只是「找特定關鍵字」

任一觸發 → 評估 multimodal RAG；都沒觸發 → 仍用 text RAG。

不在本章內的主題

1. 影片理解 / video LLM：寫 code 場景用得到的相對少（screen recording 倒是會用、但實作上多半切 keyframe 變多張圖）、見專門 video LLM 教材
2. Vision-only model（不含語言）：OCR、object detection、image classification 等專門 vision 任務、用 specialised 工具更好
3. 生圖（Diffusion 等）：跟 VLM 完全不同 paradigm、見 Diffusion 卡片 跟 ComfyUI 教材
4. 3D / point cloud：CAD / 3D 模型理解、目前 VLM 支援少、屬研究階段
5. 具體 IDE plugin 設定：Continue.dev 的 image upload UI、Ollama 的 vision API 細節等、隨版本變、見各工具當前文件

何時過時 / 何時不過時

不會過時的部分：

• Coding 場景 vision 的 use case 分類（UI debug、mockup → code、OCR 等）
• 本地 vs 雲端的分流邏輯（沿用 cross-cloud-local-data-boundary 框架）
• Image token 跟 context budget 的關係
• VLM 的失敗模式分類（細節、OCR、空間推理、DPI）
• Multimodal RAG 的概念框架

會變的部分：

• 具體本地 VLM 模型（Qwen2.5-VL → 2.6 → …、Llama 3.2 → 4 → …）
• 推論伺服器對 VLM 的支援度（llama.cpp、Ollama、LM Studio 都在追）
• IDE plugin 的 vision integration（Continue.dev、Cursor、Aider 都在演化）
• Vision encoder 設計（CLIP → SigLIP → DFN → …）
• 雲端跟本地的品質差距（會持續縮小）

跟其他章節的關係

本章是 4.1 RAG / 4.3 Tool use / 4.12 embedding model 在 vision 延伸的補完；隱私 / 跨雲端分流邏輯沿用 6.4；本地 VLM 配 IDE 的 hands-on 屬於 模組一 hands-on 範圍、視推論伺服器支援度成熟度補。