從 Fine-tuning 微調到模型部署，掌握將 AI 從實驗室帶進真實世界的工程能力。
🔧 Fine-tuning 微調模型
預訓練模型很強大，但不一定完全符合你的需求。Fine-tuning（微調）就是用你自己的數據在大模型上做「加強訓練」。
三種微調方式
💡 微調方法比較 全參數微調：修改模型所有參數，效果最好但成本極高，需要大量 GPU LoRA（Low-Rank Adaptation）：只訓練少量新增參數（~1-2%），大幅降低成本，效果接近全參數 QLoRA（Quantized LoRA）：LoRA + 量化，在消費級 GPU（如 RTX 4090）上就能微調 70B 模型
什麼時候需要微調？
- 需要模型學會特定領域的「語感」（如法律文書、醫療報告）
- 需要產出特定格式的輸出（如 JSON、特定報表格式）
- Prompt Engineering 已經不夠用的情境
📋 實際案例 假設你經營一間電商，想讓 AI 客服回答時使用你品牌的語氣和專業知識。你可以用過去的客服對話紀錄（幾千筆就夠了）對 LLaMA 做 LoRA 微調，成本只需幾百台幣的 GPU 時間。
想深入了解？看我們的 Fine-tuning 完全指南。
🚀 模型部署
模型訓練好了，怎麼讓用戶使用它？這就是部署要解決的問題。
部署方式比較
💡 本地 vs 雲端 本地部署：在自己的伺服器上運行，數據不離開公司。適合高隱私需求（銀行、醫院） 雲端部署：使用 AWS、GCP、Azure 等雲服務。彈性擴展，按用量付費 Docker 容器化：無論本地或雲端，用容器確保環境一致性
常見部署工具
- FastAPI — 輕量快速的 Python API 包裝工具，支援非同步處理和 GPU 推理
- vLLM — 大語言模型專用推理伺服器，支援連續 batching 和 PagedAttention
- Triton Inference Server — NVIDIA 的多模型推理平台，適合複雜的推理流水線
- Ollama — 最簡單的本地部署方案，一行指令就能跑（Ollama 教學）
部署決策矩陣
| 場景 | 推薦方案 | 理由 |
|---|---|---|
| 個人實驗 | Ollama | 最簡單，一行指令 |
| 原型開發 | FastAPI + HuggingFace | 彈性高，快速迭代 |
| 生產環境 | vLLM / Triton | 效能優化，可擴展 |
| 企業內部 | 本地 GPU + Docker | 數據隱私保障 |
| 大規模 SaaS | 雲端 GPU + K8s | 彈性擴展，高可用 |
⚙️ MLOps 入門
MLOps（Machine Learning Operations）是讓 AI 模型從實驗走向生產的關鍵。就像軟體有 DevOps，AI 也需要系統化的管理流程。
MLOps 的核心環節
- 數據版本控制 — 追蹤訓練數據的每次變更（工具：DVC）
- 實驗追蹤 — 紀錄每次訓練的參數和結果（工具：MLflow、Weights & Biases）
- 模型監控 — 模型上線後持續監控效能，偵測模型退化（Model Drift）
- 自動化流水線 — 數據更新 → 自動重訓練 → 自動部署（CI/CD for ML）
常用 MLOps 工具
| 工具 | 用途 | 特色 |
|---|---|---|
| MLflow | 實驗追蹤 + 模型管理 | 開源，社群大 |
| Weights & Biases | 實驗視覺化 | 最佳 UI，團隊協作 |
| DVC | 數據版本控制 | Git 風格管理大數據 |
| Kubeflow | ML 流水線 | Kubernetes 原生 |
| BentoML | 模型打包部署 | 簡化部署流程 |
⚠️ 常見錯誤 很多團隊只專注於訓練更好的模型，卻忽略了 MLOps。結果是：Notebook 裡的模型很好，但永遠上不了線。記住：能穩定運行的 80 分模型，比只存在 Notebook 裡的 95 分模型更有價值。
🗄️ 向量資料庫
還記得 RAG（檢索增強生成） 嗎？向量資料庫就是 RAG 的核心基礎建設。
為什麼需要向量資料庫？
傳統資料庫用關鍵字搜尋：搜「蘋果」只能找到包含「蘋果」的文件。向量資料庫用語義搜尋：搜「水果」也能找到「蘋果」「香蕉」的文件，因為它們在語義上相近。
主流向量資料庫
| 資料庫 | 類型 | 特色 | 適合 |
|---|---|---|---|
| Pinecone | 全託管雲端 | 開箱即用 | 快速起步 |
| Chroma | 開源內嵌 | 輕量簡單 | 原型開發 |
| Weaviate | 開源企業級 | 混合搜尋 | 企業應用 |
| Qdrant | 開源高效能 | Rust 寫的 | 高效能場景 |
| FAISS | 底層函式庫 | Meta 開發 | 客製化方案 |
| pgvector | PostgreSQL 擴充 | 整合現有 DB | 已用 PostgreSQL |
向量資料庫的運作流程
- 文字切片 — 把長文件拆成小段落（Chunk）
- Embedding — 用 Embedding 模型把文字轉成向量（一串數字）
- 儲存 — 把向量存入向量資料庫
- 搜尋 — 使用者提問 → 轉成向量 → 找到最相似的段落
- 生成 — 把找到的段落送給 LLM 生成回答
⚡ 效能優化
大模型很慢、很吃記憶體。效能優化讓模型跑得更快、更省資源。
三大優化技術
💡 優化方法 量化（Quantization）：用更低精度的數字表示模型參數，體積可減少 50-75%。把 FP32 → INT8 或 INT4。 蒸餾（Distillation）：讓「學生模型」從「老師模型」學習精華，得到更小但效果接近的模型。 剪枝（Pruning）：去掉模型中不重要的連接（權重），讓模型變得更稀疏、更快。
實際效果
| 模型 | 原始大小 | 量化後 | 速度提升 | 品質損失 |
|---|---|---|---|---|
| LLaMA-2 70B | 140GB（FP16） | 35GB（4-bit） | 2-3x | < 5% |
| Mistral 7B | 14GB（FP16） | 4GB（4-bit） | 3-4x | < 3% |
| Qwen 2.5 72B | 144GB（FP16） | 40GB（4-bit） | 2x | < 5% |
推理加速技術
- KV Cache — 快取已計算的注意力鍵值對，避免重複計算
- Continuous Batching — 動態合併多個請求，提高 GPU 利用率
- PagedAttention — vLLM 的核心技術，像作業系統管理記憶體一樣管理 KV Cache
- Speculative Decoding — 用小模型預測、大模型驗證，加速生成
❓ FAQ
不會寫程式也能做 AI 工程嗎？
AI 工程需要一定的程式能力，特別是 Python。但隨著工具越來越成熟，門檻正在降低。建議先從 Python 入門 開始，再逐步學習 AI 相關框架。
Fine-tuning 和 Prompt Engineering 怎麼選？
90% 的場景先用 Prompt Engineering 就夠了——成本低、迭代快。只有當 Prompt Engineering 無法達到需求（如特定語氣、格式、領域知識）時，才考慮 Fine-tuning。
向量資料庫選哪個好？
快速起步選 Pinecone（全託管）；原型開發選 Chroma（簡單內嵌）；企業級應用選 Weaviate 或 Qdrant；已經用 PostgreSQL 的專案直接加 pgvector 擴充。
量化後模型品質會下降很多嗎？
4-bit 量化通常品質損失在 5% 以內，大部分應用場景感受不到差異。8-bit 量化幾乎沒有損失。只有在極端精確度要求的場景（如醫療、金融）才需要特別注意。