概念位置

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 範圍、視推論伺服器支援度成熟度補。

本指南預設讀者已經會用過雲端 LLM（ChatGPT、Claude）、熟悉終端機操作、想以工程視角理解 LLM。寫 code 場景是主要使用例、但模組二 / 三 / 四 / 六多數章節跨場景通用：想懂 reasoning model / RAG / embedding model 內部、即使不裝本地 LLM 也能讀。硬體前提分兩條路線：Apple Silicon Mac（M1 ~ M4、統一記憶體）走模組一；Windows / Linux + 獨立 GPU（NVIDIA / AMD、獨立 VRAM + 系統 RAM）走模組五。文章不販賣 LLM 焦慮、也不誇大本地能取代雲端的程度；它的責任是給每條讀者旅程的最短可行路徑、並標出每個階段的取捨。

模組零（心智模型）是所有讀者旅程的共同前置。模組一跟模組五是「裝本地 LLM」的兩條硬體路線、依平台選一條；想懂底層走模組二跟模組三（跟硬體無關、含 reasoning model / speculative decoding 等推論細節）；想看 LLM 作為系統元件走模組四（12 章涵蓋 RAG、tool use、agent、應用層協議、workflow、production resource、long context、embedding model、benchmarking、vision、靜態 deployment）；本地工作流跑穩想看安全議題走模組六（個人 dev 視角的供應鏈、伺服器綁定、tool use 權限、prompt injection、跨雲端邊界、production routing）。

教材邊界

學習路線

本指南分成七個模組加一組前置卡片（111 張）。讀者依目的選讀、不需要從頭到尾全讀：

• 想用 Apple Silicon Mac 裝本地 LLM 寫 code：讀模組零 + 模組一（最短路徑）
• 想用 Windows / Linux + 獨立 GPU 裝：讀模組零 + 模組五
• 想懂 LLM 內部原理：模組二（數學） + 模組三（理論、含 reasoning models / speculative decoding）— 跟硬體無關
• 想做 LLM 應用開發（含 RAG / agent / VLM / 靜態 deployment）：模組四（12 章、跨工具世代不變的原理）— 跟硬體無關
• 想懂本地工作流的安全議題：模組一 / 五跑穩後接模組六（個人 dev 視角）
• 想選 RAG 的 storage 方案（pickle / vector DB / hosted SaaS）：直接看 4.22 RAG storage 工程
• 想在靜態網站加 RAG / 智能搜尋：直接看 4.16 靜態 / serverless RAG deployment
• 想在本機 fine-tune 模型：模組三 3.4 訓練流程原理 → 本機 QLoRA hands-on
• 想跟最新進展接軌：讀完模組後進推薦的公開課程跟 paper（模組二 2.4 + 模組三 3.10）

前置知識卡片

用原子化卡片整理 token、自回歸、KV cache、量化、speculative decoding、MTP、MLX、推論伺服器、OpenAI 相容 API、memory bandwidth、統一記憶體、TTFT、prefill、context window、Transformer、Diffusion 等核心概念。章節文章專注情境推導、術語背景交由卡片維持一致。

模組零：基礎知識與心智模型

整理本地 vs 雲端 LLM 的差異、自回歸架構與記憶體頻寬瓶頸、介面 / 伺服器 / 模型三層心智模型、OpenAI 相容 API 為何重要、MLX / MTP / oMLX 三個容易搞混的術語、Apple Silicon Mac 記憶體與模型大小的對應關係、判讀本地 LLM 資訊的五個框架。

模組一：本地 LLM 服務的安裝與應用

整理 Ollama、LM Studio、llama.cpp 三個主流推論伺服器的現況差異與安裝路徑、用 Continue.dev 把本地 LLM 接到 VS Code 的完整步驟、寫 code 場景下模型選型的優先順序、本地模型的期望管理、想進一步玩 coding agent、Web UI、產圖時的延伸方向。

模組二：LLM 的數學基礎

整理 LLM 推論背後的數學工具：線性代數（向量、矩陣、空間）、機率與資訊論（softmax、cross-entropy、KL、perplexity）、微積分與最佳化（gradient、SGD / Adam）、數值精度（fp32 / bf16 / Q4 / Q8 的取捨）。每章末尾接到公開課推薦。

模組三：LLM 的理論基礎

整理 LLM 內部運作機制、共 11 章：神經網路基礎、embedding 空間、attention 機制、Transformer 架構、訓練流程（pre-train → SFT → RLHF / DPO）、sampling 策略、tokenization 算法、跨語言場景原理、Reasoning models（o1 / R1 / QwQ 等 test-time compute paradigm）、Speculative decoding 內部（drafter / MTP / EAGLE）。每章末尾接到公開課推薦（Karpathy、Stanford CS224N / CS25 / CS336、DeepLearning.AI）。

模組四：LLM 應用層原理

整理 LLM 作為系統元件的設計原理、共 12 章：RAG、tool use、agent 架構、應用層協議、workflow 編排模式、Production resource planning、衍生產物管理、Long context engineering、Embedding model 內部、Benchmarking 方法論、Vision in coding workflow（本地 VLM 接 IDE）、靜態 / serverless RAG deployment（沒 backend 場景）。本模組刻意只寫跨工具世代不變的原理、避開 LangChain / LlamaIndex 等具體 framework 教學。

模組五：Windows / Linux + 獨立 GPU

整理消費級 PC（Windows / Linux + NVIDIA / AMD 獨立 GPU）跑本地 LLM 的硬體判讀模型與工程選項：VRAM + RAM 分層預算、MoE 模型的 CPU 卸載策略（--n-cpu-moe）、KV cache 量化（K=Q8 / V=Q4）跟 context 長度的權衡、llama.cpp 在 PC 上的調參空間。本模組跟模組一是平行的硬體路線、共用模組零的心智模型跟卡片。

模組六：本地 LLM 的安全與權限

整理個人 dev 在自己機器上跑本地 LLM 的安全議題：模型供應鏈與信任邊界、推論伺服器的綁定與暴露範圍、tool use 與 MCP server 的權限模型、IDE 場景的 prompt injection、跨雲端 / 本地的資料邊界、跨進 production 的 routing 中樞。framing 是個人 dev 視角、不是 enterprise 資安管理；production / 多租戶 LLM 服務的特殊資安議題見 Backend 模組七 資安與資料保護 的 LLM 相關章節。

模組之間怎麼配合

模組二跟模組三可並讀。閱讀模組三遇到陌生數學詞時跳回模組二補完、再回模組三繼續。模組四在前面模組之上、但讀者熟悉 LLM 應用詞彙也可直接從這裡讀起。模組一跟模組五依硬體選一條主路線、共用模組零的心智模型與 knowledge-cards。模組六在模組一 / 五跑穩後接、處理「跑起來後該注意什麼」。

適合的讀者

用語約定

本指南使用的關鍵術語在第一次出現時都附原文。為避免歧義，下列詞彙在本指南內固定指涉：

1. 本地 LLM：跑在使用者自己機器（Mac 或 PC）上的大型語言模型推論、prompt 留在本機。
2. 推論伺服器（inference server）：負責載入模型權重、處理 prompt、產生 token 的常駐程式、例如 Ollama、LM Studio 內建 server、llama.cpp server。
3. 介面層：使用者實際打字互動的工具、例如 VS Code + Continue.dev、CLI、Web UI。介面層透過 API 跟推論伺服器溝通。
4. 模型（model）：權重檔本身、例如 gemma4:31b、qwen3-coder:30b。模型可以在不同推論伺服器之間共用、前提是格式相容。
5. 量化（quantization）：把模型權重從高精度（如 bf16）壓成低精度（如 Q4）以減少記憶體佔用、代價是少許品質下降。

不在本指南內的主題

本指南不討論：

• Speech / audio LLM：跟核心文字 LLM 是不同方向、本指南不涵蓋。Vision（VLM）原本不放、但因 coding 工作流的 vision use case 進入主流、補上 4.15 Vision in coding workflow；video LLM 仍不放。
• 資料中心訓練的工程細節：data parallelism、ZeRO、tensor parallelism 等屬於專門課程的範圍。
• 向量資料庫的 vendor 比較（Pinecone vs Weaviate vs Chroma 等）：vendor 格局半年一變、不適合寫入教材。RAG 的 storage 工程原理（升級判讀、index 生命週期、dependency 約束）見 4.22 RAG storage 工程。
• Kubernetes / 資料中心級分散式推論：跟個人機器本地 LLM 方向不同、需另尋專門教材。
• 多卡 NVLink、tensor parallelism：消費級 PC 場景通常單卡、本指南不涵蓋多卡分散式推論。

若讀完本指南後想往這些方向走：

1. 想做 RAG 應用：先把 Ollama + Continue.dev 跑穩、再讀 模組四 4.1 RAG 原理 建立設計取捨判讀、或 模組三 3.8 推薦 的 DeepLearning.AI short courses。
2. 想跑 coding agent：先讀 4.4 Agent 架構原理 建立判讀、再看 1.6 延伸方向 了解 aider、Cline 等工具的定位差異。
3. 想跑產圖模型：Diffusion 跟 Transformer 是不同架構、請另尋 ComfyUI / Draw Things / Diffusers 教材。
4. 想自己訓練 / fine-tune：讀完模組三、進入 Karpathy zero-to-hero、Stanford CS336、Hugging Face NLP Course 等推薦資源。

文件版本：v0.7.0 最後更新：2026-05-12 系列狀態：七個模組 + 125 張知識卡片。模組零（9 章）/ 一（10 章 + hands-on、含 QLoRA + judge harness）/ 二（5 章）/ 三（12 章、含 reasoning / speculative / constrained decoding）/ 四（17 章、含 long context / embedding / benchmarking / VLM / 靜態 deployment / coding agent harness / prompt caching / agent memory / tracing / LLM-as-judge）/ 五（7 章）/ 六（7 章、含 OWASP 對照）。