最近開源 LLM 幾乎每週都有新模型推出，每次看到有趣的檔案，心裡總會冒出一個問號：「我的電腦跑得動嗎？」

本機跑大模型最關鍵的不是 CPU 多強、記憶體多大，而是 GPU 的 VRAM（顯存）。VRAM 不夠，再大的模型也塞不進去，只能退而求其次降量化、縮上下文，甚至根本起不動。手動算每個模型的容量很累人，好在有幾款工具可以一鍵幫你檢查。

為什麼 VRAM 是關鍵？

比喻一下：

• VRAM = 工作桌的面積。模型越大、量化越低（精度越高），佔用的桌面越大。
• 系統記憶體（RAM） = 抽屜。空間不夠時可以暫時塞進去，但拿出來會慢很多。
• CPU / GPU = 你的手。手快（GPU 強）取東西才快，生成才會順。

所以判斷「跑得動嗎」，第一步就是看你的 VRAM 夠不够把這個模型（加上上下文）裝下。接下來這些工具就是幫你自動算這道題。

目前主流檢測工具一覽

首推：llmfit（本地工具）

llmfit（GitHub： https://github.com/AlexsJones/llmfit ）。

快速安裝
curl -fsSL https://llmfit.axjns.dev/install.sh | sh -s -- --local

安裝後輸入一行命令，它會自動偵測你的：

• CPU
• 系統 RAM
• GPU（含 VRAM）
• 其他加速器設定

然後比對上百個開源 LLM，從四個维度打分：

1. 質量：哪個量化版本能保住效果。
2. 速度：預估生成快慢。
3. 適配度：你的硬體跟這個模型的契合程度。
4. 上下文：還能留多少空間給對話歷史。

它預設開的是互動式 TUI（終端介面），畫面會列出「哪些模型能跑、跑多快、用哪個量化最合適」。如果你習慣傳統 CLI，也可以直接關掉互動模式。

更實用的是，llmfit 可以實際下載並執行模型、量出真實的 tokens/sec，把數據分享出去幫到其他人。

不想裝東西？用線上網站

有時候你只是在別人電腦上、或懶得安裝，這時線上工具最方便：

• GPUFits（ https://gpufits.com/en/ ）：標題就是「你的 GPU 跑得動這個 LLM 嗎？」，整合 VRAM 計算、兼容性檢查、本機 vs API 成本比較。
• Local LLM Compatibility Checker（ https://opensourcesai.com/tools/local-llm-compatibility-checker/ ）：純 VRAM 計算器，輸入就出結果，最快最直觀。

該怎麼選？

• 想認真了解自己這台機器 → 裝 llmfit，順手跑一次 benchmark，數據最可靠。
• 只想快速查一下、不想安裝 → 用 GPUFits（查兼容性）或 Local LLM Compatibility Checker（查 VRAM）。

要注意的問題

• VRAM 會吃滿：就算模型剛好吃進去，剩下給上下文的空间可能就很少，對話長了就 OOM。
• 估算 ≠ 實測：線上網站多是根據型號推算，實際速度還是要看你的驅動、量化方式、並行設定。
• Mac 不算「GPU VRAM」：M 系列是統一記憶體，要看總内存夠不夠（建議至少 16GB 起步）。
• 舊卡驅動：很老的 NVIDIA 卡可能支援度低，檢查時留意驅動版本。

前面第 08 篇《Local LLM 部署：用 Ollama》介紹了 Ollama 這一款工具，但很多人會發現：本地跑大模型的工具其實有很多種，名字聽起來都差不多。為什麼需要這麼多工具？它們有什麼不同？我該選哪個？ 這篇就是來回答這個問題。

先講結論：沒有所謂「最好」的工具，只有最適合你需求的工具。有人想要一行命令快速上手，有人想要點一點就有圖形介面，有人想要最強功能願意折騰。下面從「背後的共同原理」講到「各工具差異」，最後給你一張決策表。

如果你只想用 Ollama，直接回頭看 Local LLM 部署：用 Ollama 就好；這篇則帶你看完整生態。

為什麼有多種本地工具？

因為大家的需求不一樣，主要分成幾個取向上：

• 圖形介面（GUI）vs 命令列（CLI）：有人喜歡點按鈕、拖模型；有人習慣終端機一行指令，適合接進腳本與自動化。
• 簡單 vs 可控：有人只想「跑起來聊天」；有人想要微調模型、接 API、做圖片生成、擴充插件。
• 硬體限制：有人用高階 Mac 或 NVIDIA 顯卡，有人只有普通筆電，對效率與相容性要求不同。

這些取向的差異，就催生了不同的工具。而它們大多建立在同一套底層技術上——接下來解釋這個關鍵概念。

背後的共同原理：llama.cpp 與 GGUF

理解這一點，你就懂為什麼工具這麼多還長得很像。

llama.cpp 是一個用 C/C++ 寫成的開源引擎，能在各種硬體（包含只有 CPU 的電腦）上執行大語言模型。它幾乎是「本地模型」這領域的基礎設施——Ollama、LM Studio 等大多數圖形工具，底層調用的就是 llama.cpp。

而模型的檔案格式叫 GGUF（llama.cpp 提出的格式）。你從各處下載的本地模型，幾乎都是 GGUF 檔。這就像：llama.cpp 是「引擎」，GGUF 是「燃料規格」，各家工具只是換了不同的「車體與儀表板」。

了解這個之後，再看各工具的差異就清楚多了：它們大多共用同一套引擎，差別在於包裝、功能與易用性。

主流工具介紹

以下四個是 2026 年最具代表性的本地模型工具。

Ollama — 最簡單，開發者首選

Ollama 用命令列為主，一行指令就能下載並跑模型（ollama run qwen3:8b），還內建 OpenAI 相容的本地 API，接進自己的程式或開發工具都方便。**詳細用法見 Local LLM 部署：用 Ollama**。

• 優點：安裝與使用最簡單、文件多、開發者生態最強（接 API、接 Claude Code／OpenCode 等代理都方便）。
• 缺點：原生沒有漂亮的圖形介面（雖然後來加了輕量視窗），進階功能較少。
• 適合：開發者、想接程式、習慣命令列的人。

LM Studio — 圖形介面最順，新手友好

LM Studio 是我最推薦給「想要 GUI 又不想折騰」的人。它現在不只是下載模型的瀏覽器，還整合成能處理工作與程式的 agent，底層同時支援 MLX（Mac 高效運算）與 llama.cpp，跨 Mac／Windows／Linux。除了點點點的介面，也提供命令列 lms 與 SDK，對開發者也算友善。內建模型庫可以直接搜、直接下，免費離線、重視隱私。

• 優點：介面清晰、模型庫好找、圖形操作順、同時有 CLI/SDK、Mac 效能佳。
• 缺點：功能深度不及 TextGen（例如進階微調、圖片生成較弱）。
• 適合：想要好用 GUI、又想兼顧一點開發需求的人。

TextGen（oobabooga）— 功能最強大，進階玩家最愛

TextGen（原名 Text Generation WebUI，由 oobabooga 維護）是功能最全面的一個。它不只是文字對話，還能做圖片生成、視覺理解、工具調用、提供 API、LoRA 微調模型，並有大量擴充插件。它提供易用的桌面 App 與瀏覽器 Web UI，後端還支援多種引擎，適合想深度玩本地模型的人。

• 優點：功能最完整、擴充性強、能微調與做多模態。
• 缺點：設定較複雜、文件偏技術、對新手不太友善。
• 適合：進階玩家、研究者、想要一站式（文字＋圖片＋微調）的人。

llama.cpp — 給想要完全控制的人

就是前面提到的那個引擎本身。如果你不想依賴任何圖形工具，想自己編譯、自訂參數、在特殊硬體上最佳化，可以直接用 llama.cpp 的命令列。它是「最原始」的選擇。

• 優點：完全可控、效率最高、相容性最廣（CPU/GPU/Mac 都能跑）。
• 缺點：沒有圖形介面，需要命令列與技術背景。
• 適合：開發者、研究者、想徹底理解或最佳化效能的人。

該選哪個？看這張表

如果還是猶豫，我的建議是：開發者用 Ollama，一般使用者用 LM Studio。這兩個能涵蓋九成情境，也是本篇前面幾篇已經深入介紹過的工具。

小結

• 本地模型工具很多，但大多共用同一套底層 llama.cpp 與 GGUF 格式，差別在包裝與功能。
• Ollama 最簡單、開發者最愛；LM Studio 圖形介面最順；TextGen 功能最強；llama.cpp 給想要完全控制的人。
• 選型關鍵看三件事：要不要 GUI、需不需要進階功能、是不是開發者。
• 只想用 Ollama？回頭看 Local LLM 部署：用 Ollama，那篇會帶你把一個工具玩透。

《AI 新時代》系列第 14 篇。相關：Local LLM 部署（Ollama）

上一篇介紹了如何在 Unity 中使用 Cursor AI，這篇換成遊戲開發者常用的 Godot。Cursor 是一個 AI 程式編輯器（基於 VS Code 打造），能幫你補碼、生成與修改程式。在 Godot 中主要用來撰寫 GDScript 或 **C#**，讓 AI 參與腳本開發。

與 Unity 不同的是，Godot 不需要安裝任何套件，只要在設定裡把 Cursor 設成「外部編輯器」即可。以下分 Mac 與 Windows 兩種平台說明。

步驟一：安裝 Cursor

1. 前往 https://www.cursor.com/ 註冊帳號並下載對應作業版本的 Cursor 安裝。
2. 開啟後登入，建議先到設定裡選好要用的模型（例如 Claude、GPT 等）。

步驟二：將 Cursor 設為 Godot 的外部編輯器

1. 在 Godot 4 編輯器右上角，點擊 Editor -> Editor Settings（或直接按 Ctrl + ,／⌘ + ,）。
2. 在左側展開 General，找到 Text Editor，再點開 External。
3. 勾選 Enabled，讓 Godot 允許用外部程式開啟腳本。
4. 設定 Exe/Path（Cursor 的執行檔路徑）與 Args（傳遞給 Cursor 的參數）。

Mac 使用者

• Exe/Path 填入：

  1	/Applications/Cursor.app/Contents/MacOS/cursor

• Args 填入：

  1	{file}:{line}

Windows 使用者

• Exe/Path 填入 cursor.exe 的路徑。如果不知道裝在哪，可以到「開始選單」找到 Cursor、右鍵選擇「開啟檔案所在位置」，即可看到執行檔，再把完整路徑複製過來。
• Args 同樣填入：

  1	{file}:{line}

參數說明：{file} 會被替換成腳本檔案的完整路徑，{line} 則是你在 Godot 中游標所在的行號。這樣 Cursor 開啟時會直接定位到該行。

5. 回到 Text Editor 上層，把 External -> Use External 勾選起來，確保生效。
6. 點擊右下角的 Apply、OK 完成設定。

步驟三：在 Godot 中開啟腳本

1. 在場景樹或檔案系統中，雙擊一支 GDScript／C# 腳本，它會在 Godot 內建的編輯器打開。
2. 點擊右上角的「用外部編輯器開啟」圖示（看起來像一支筆或外框箭頭），Godot 就會呼叫 Cursor 在同一支檔案上打開。
3. 之後每次改腳本，只要點該圖示，就會直接用 Cursor 開啟，方便直接使用 AI 功能。

替代做法：直接用 Cursor 開啟整個專案

如果你希望 AI 能理解整個 Godot 專案的上下文（而不只是單一腳本），可以直接用 Cursor 打開專案資料夾：

1. 在 Cursor 中點擊 Open Folder，選擇你的 Godot 專案資料夾（包含 project.godot 的那一層）。
2. 此時 Cursor 會把整個專案當作品程開啟，AI 能讀取所有腳本、資源與結構。
3. 改完後回到 Godot，腳本通常會自動偵測到變更；若沒更新，按右鍵選擇 Reload 即可。

這種方式適合想讓 AI 跨檔案理解邏輯、進行重構或除錯的情境。

使用 Cursor 的 AI 功能

開啟腳本後，你可以用以下快捷鍵呼叫 AI：

• ⌘ + L（Mac）／Ctrl + L（Windows）：開啟 AI 對話視窗。你可以在這裡向 AI 闡述問題或需求，讓它生成、解釋或修改程式碼。
• ⌘ + K（Mac）／Ctrl + K（Windows）：在你選中的段落上直接改寫。先選取一段程式，再按快捷鍵並描述你想做的變更。
• **Tab**：行內補碼。輸入部分邏輯時，Cursor 會建議接下來的內容，按 Tab 接受。

小結

• Godot 4 不需要套件，只要在 Editor Settings -> Text Editor -> External 把 Cursor 設成外部編輯器。
• Mac 路徑為 /Applications/Cursor.app/Contents/MacOS/cursor；Windows 則指向 cursor.exe，參數都用 {file}:{line}。
• 想讓 AI 理解全專案，可以直接用 Cursor 開啟整個 Godot 資料夾。
• 常用快捷鍵：L（對話）、K（選取改寫）、Tab（補碼）。

如果你也用 Unity，可以參考上一篇〔How to use Cursor AI in Unity〕(/2024/09/22/2024-09-22-how-to-use-cursor-ai-in-unity/)，兩者的核心概念相同，只是設定位置不同。

《AI 新時代》系列第 13 篇。上一篇：AI 趨勢倫理 · 相關：Cursor in Unity

這是《AI 新時代》系列的一環。前面 11 篇我們從概念、工具、實作一路走到 Agent，這篇退後一步，帶你看全局：AI 現在到哪了、未來往哪去，以及這些強大技術帶來的倫理責任。讀完你會不僅「會用」，還會「想得清楚」。

發展現況：熱情之後的冷靜

生成式 AI 在 2023 年被捧上天，但到了 2025 年，許多企業發現落地比想像難——整合不易、資料品質參差、投資報酬不明顯。分析師因此用「Gartner 炒作循環（Hype Cycle）」來形容：熱潮過後進入「幻滅谷底」，接著才是務實的成長期。

這對使用者的意義：AI 很強，但不是萬能。把它當成有專長但會犯錯的助手，搭配人的判斷，才是最健康的用法。

四個值得關注的趨勢

1. 多模態成為標準

現在的模型越來越能同時處理文字、圖片、影片、音訊，單一「只會聊天」的 AI 正被「什麼都能懂能做」的多模態模型取代。

2. Agent 生態成形

從第 11 篇的單一步驟工具調用，發展成能自主規劃、多 agent 協作的系統。AI 正在從「對話工具」變成「工作夥伴」。

3. 具身智能（Embodied AI）

把大模型的智慧裝進機器人、無人機等實體，讓 AI 不只是在螢幕裡，而是能在現實世界行動。這仍是早期，但進展迅速。

4. 開放 vs.封閉的競爭

像 DeepSeek、Qwen、Llama 等開放權重模型持續進步，讓個人與企業能免費本地部署（見第 08 篇），打破大廠對先進模型的壟斷。

必須面對的倫理議題

資料隱私與版權

• AI 模型多用受版權保護的資料訓練，常未經授權，引發大量訴訟。
• 個人資料輸入給雲端 AI，可能被記錄或用於訓練。重要資料優先選本地部署。
• AI 生成內容的版權歸屬，目前法律尚不明確。

深度偽造（Deepfake）與假訊息

• 能逼真模擬任何人的聲音、臉，被用於詐騙、謠言、惡搞。
• 「看不到真影片也不敢信」成為新社會風險。辨識 AI 生成內容、驗證資訊來源變得重要。

偏見與公平性

• 模型會繼承訓練資料裡的社會偏見（種族、性別等），輸出可能不公平。
• 需要人為審查與更多元的訓練資料。

工作與社會影響

• 自動化會改變許多職缺，部分重複性工作受衝擊最大。
• 與其擔心「被取代」，不如學習如何與 AI 協作——把 AI 當成放大自己能力的工具。

環境成本

• 訓練與運行大模型耗電量大，資料中心能源消耗與水資源使用引發關注。

開發者應該準備什麼？

回到你（技術讀者）的角度，幾個具體建議：

1. 掌握基本操作：會用 Prompt、懂 API、知道怎麼接自己的資料（RAG）。
2. 學會審查 AI 輸出：AI 會錯、會有偏見、會被注入攻擊，人的判斷不可取代。
3. 重視安全與隱私：key 管理、權限控制、個人資料處理都要留意。
4. 保持學習：這個領域幾個月就大變，維持好奇心與實驗精神。

系列總整理

回顧這 12 篇你學到的主線：

小結

• AI 正從「炒作」走向務實應用，多模態、Agent、具身智能是方向。
• 隱私、版權、深度偽造、偏見、環境都是真實挑戰。
• 對開發者：會用 + 會審查 + 重安全，才是長久之道。

感謝閱讀整個系列！如果這些內容幫到了你，歡迎分享給朋友。也歡迎在留言區告訴我，下一個系列你想看什麼主題。

《AI 新時代》系列第 12 篇。上一篇：AI Agent

前面我們學了：RAG 讓 AI「讀資料」（第 06 篇）、Function Calling 讓 AI「調工具」（第 07 篇）。當這些能力串起來、讓模型自己決定下一步該做什麼，就變成了 AI Agent（智能體）——這可能是今年最重要的應用方向。

什麼是 Agent？

傳統的 AI 你問一句、它答一句。Agent 則是有「自主性」的 AI：給你一個高層目標，它會自己拆解步驟、選擇工具、執行、檢查結果，直到完成。

比喻：

• 一般 LLM = 會回答問題的專家。
• Agent = 給它一個任務、資源和工具，它能像助理一樣自己安排做完。

Agent 的三個核心元件

有了這三個，Agent 才能「思考 → 行動 → 觀察 → 再思考」。

ReAct：最主流的 Agent 模式

ReAct = Reasoning（推理）+ Acting（行動）。它把過程明確分成循環：

1

思考 (Think) → 行動 (Act) → 觀察 (Observe) → 思考 → …… → 結論

舉例：目標是「幫我做一趟東京旅行的規劃」：

1. Think：「我需要知道東京的熱門景點。」→ 行動：呼叫旅遊 API。
2. Observe：拿到景點清單。
3. Think：「再查交通票券。」→ 行動：呼叫訂票工具。
4. Observe：拿到票券資訊與價格。
5. Think：「整合成一日行程表。」→ 輸出最終結果。

每一步都「邊想邊做、根據回饋調整」，所以比一次生成的答案更可靠。

用框架來實作

自己從零寫 Agent 很繁瑣，通常用現成框架：

• LangChain / LangGraph：Python／JS 最流行，工具與鏈結方便，適合各種場景。
• AutoGen（Microsoft）：強調多Agent對話，讓多個有不同角色的 agent 協作完成任務。
• CrewAI、LlamaIndex：各自在團隊協作、資料檢索上有專長。

對你這種有 Java／Python 背景的人，從 LangChain 入手最順。

實際應用案例

• 程式開發 Agent：讀整個 repo、自動修 bug、寫測試、做重構（接第 04 篇的 Claude Code、OpenCode）。
• 資料分析：連資料庫、跑查詢、生成報表與圖表。
• 自動化工作流：監控郵件 → 分類 → 摘要 → 發通知。
• 研究助理：多網站查資料 → 交叉驗證 → 整理成報告（結合 RAG）。

要注意的現實問題

• 會跑飛：Agent 可能執行與目標無關的操作，一定要設邊界、可中斷。
• 累積錯誤：步驟越多，前面錯一步後面全歪的風險越高。
• 成本與速度：每一步都是一次模型請求，多步 Agent 的 token 消耗快。
• 安全：能執行指令／改檔案的 Agent，權限要收緊，避免被提示注入（prompt injection）操縱去做惡意動作。

小結

• Agent = 有自主性、能自己規劃並用工具完成多步任務的 AI。
• 三元件：規劃 + 工具調用 + 記憶；主流模式是 ReAct。
• 用 LangChain / AutoGen 等框架加速開發。
• 潛力大但要設邊界，注意跑飛、累積錯誤、成本與安全。

這是把前面所有能力整合的終極形態。最後一篇，我們退後一步看全局：AI 趨勢展望與倫理議題。

《AI 新時代》系列第 11 篇。上一篇：AI 影片與語音 · 下一篇預告：AI 趨勢與倫理

圖像已經夠強，更動的影片和語音這兩年也爆發性進展。這篇文章把這些工具串成一個完整的「AI 多模態創作」地圖，並在文末接上本站的 LTX-Video、ComfyUI 實作教學。

AI 生成影片：技術現況

文字或圖像生成影片（Text-to-Video / Image-to-Video）是近年來進步最快的領域。2026 年主流產品：

兩種主要方式

1. Text-to-Video（文字生影片）：只給一句描述，模型直接生成。適合概念短片、靈感素材。
2. Image-to-Video（圖生影片）：給一張基圖 + 動機描述，讓圖片「動起來」。可控性較高，本站 LTX-Video 教學中的範例即屬此類。

接上本站的 LTX-Video 實作教學

本站先前用 Python 實際跑過開源、可本地部署的 LTX-Video，這個流程正是 AI 影片創作的標準範式：

1
2
3
4
5
6
7
8
9

# 文字生成影片
python inference.py --ckpt_path /path/to/ltx-video-2b \
    --prompt "A monkey dance" --height 768 --width 1024 \
    --num_frames 10 --seed 2

# 圖片生成影片
python inference.py --ckpt_path /path/to/ltx-video-2b \
    --prompt "A monkey dance" --input_image_path /path/image.png \
    --height 768 --width 1024 --num_frames 200 --frame_rate 20 --seed 3

注意版本：LTX-Video 更新很快，範例中的 v0.9.1 已是舊版，目前 2B 最新是 0.9.8 系列。實際檔名請到 HuggingFace（Lightricks/LTX-Video） 下載最新的 2B checkpoint 後替換。

幾個重點參數：--prompt（描述）、--seed（固定種子重複）、--num_frames（幀數，決定長度）、--frame_rate（每秒幀數）。

本地 vs 雲端怎麼選？

• LTX-Video 本地跑：免費、隱私、可批量，但吃硬體（尤其長影片、高幀數）。
• Sora / Veo 雲端：品質與方便度高，按量付費，不用管硬體。

實務上很多人用雲端做高品質成品，用開源模型做快速迭代測試。

AI 語音與配音

除了畫面，聲音也是創作的關鍵：

AI 配音流程通常是：腳本 → TTS 產生語音 → 剪輯合成到影片。ElevenLabs 目前是這個領域的標竿。

倫理與版權（多模態更要小心）

動態內容的風險比圖像更高：

• 深度偽造（Deepfake）：用他人聲音／臉生成虛假影片，可能被用於詐騙、謠言，已有法律制裁。
• 聲音克隆授權：複製任何人（含自己以外）的聲音做商用，需取得同意。
• 內容標示：多地法規要求 AI 生成的影音必須標註，避免誤導。

這也是為什麼工具方都開始加入水印與偵測機制。創作自由與責任要平衡。

小結

• AI 影片分 文字生影片 與 圖生影片，2026 主流是 Sora、Veo、開源的 LTX-Video。
• 本地跑 LTX-Video 用 --prompt/--seed/--num_frames/--frame_rate，雲端用 Sora/Veo 取品質（本站有完整教學）。
• ElevenLabs 是 AI 配音標竿，可支援語音克隆。
• 深度偽造、聲音克隆授權、內容標示是必須重視的倫理法律紅線。

學會圖、聲、影片後，最後把「能讀能做」的能力整合起來——下一篇：AI Agent。

《AI 新時代》系列第 10 篇。上一篇：AI 圖像生成 · 下一篇預告：AI Agent

上一篇聊到 LLM 處理文字，這篇換個心情看 AI 畫圖。你會發現「畫圖」和「聊天」背後其實是不同類型的模型（上篇《什麼是生成式 AI》提過的 Diffusion）。這篇文章帶你理解原理、比較工具、學會寫提示詞。

原理回顧：Diffusion 是怎麼畫的？

記憶一下：Diffusion 模型從全雜訊的圖片開始，反覆「去噪」一步步清成清晰圖像，而你給的描述會引導清理的方向。所以 AI 畫圖本質上是從隨機噪音中，把你想看的東西慢慢顯現出來。

三大工具比較

怎麼寫好的圖像提示詞？

跟文字 Prompt 原相通，但更強調「視覺元素」。一個完整公式：

主題 + 細節 + 風格 + 燈光 + 構圖 + 品質修飾詞

範例對比：

• ❌ 「一隻貓」
• ✅ 「一隻橘貓坐在窗台上，油畫風格，溫暖的夕陽光，景深效果，高細節，傑作」

常用修飾詞：

• 風格：水彩 (watercolor)、像素風 (pixel art)、3D 渲染、賽博龐克 (cyberpunk)、扁平插畫 (flat illustration)
• 燈光：自然光、霓虹燈、黃金時刻 (golden hour)、影棚光
• 構圖：特寫、廣角、俯視角、對稱構圖
• 品質：高細節、4K、傑作 (masterpiece)

兩個重要觀念

負向提示詞（Negative Prompt）

告訴模型「不要什麼」，能有效減少 unwanted 的元素。例如：低品質、模糊、多手指、水印。這個設定在後續的 ComfyUI 實作教學裡會實際用到。

種子（Seed）

每次生成都是隨機的。固定 seed 就能重複出同一張圖，方便你在現有基礎上微調。這是「改一點點」而不是「重畫」的關鍵。

接上本站的 ComfyUI 實作教學

本站先前介紹過《Mac 使用 ComfyUI》，Stable Diffusion 最強大的地方就是能在本地用 ComfyUI 完成從設定到出圖的完整流程：

• Img2Img（圖生圖）：給一張基圖，調整去噪強度（denoising），讓 AI 在原有基礎上變化。這與影片生成「圖生影片」的思路雷同。
• ControlNet：用線稿或姿勢來精確控制構圖。
• 擴充/重繪（Inpainting）：只改圖片的某個區域，例如換背景、修細節。

如果還沒實際操作 ComfyUI，可以把這篇學到的提示詞技巧直接套進教學裡的 workflow 試試。

一定要知道的：授權與版權

• 商用前看清授權：Midjourney 付費方案才具商用權；Firefly 因用授權資料訓練，商業最安全。
• 別生成侵權內容：模仿特定註冊角色、商標或有版權的風格，可能有法律風險。
• 各地法規不同：AI 生成內容的版權歸屬目前仍在發展中，商用前最好確認當地規範。

小結

• AI 畫圖靠 Diffusion 模型，從噪音逐步顯影。
• Midjourney 美感強、Stable Diffusion 可本地自訂（本站另有 ComfyUI 實作教學）、Firefly 商用最安全。
• 好提示詞 = 主題 + 細節 + 風格 + 燈光 + 構圖，善用負向提示與 seed。
• 授權與版權一定要留意，尤其商用時。

下一篇看更動的：AI 影片與語音生成（Sora、Veo、LTX-Video、ElevenLabs）。

《AI 新時代》系列第 09 篇。上一篇：Local LLM · 下一篇預告：AI 影片與語音

付費 API 雖然方便，但有兩個痛點：用多了要花錢，而且資料會傳到別人伺服器。如果你重視隱私、想免費測試、或需要離線環境，本地部署大模型就是答案。

這篇文章帶你用 Ollama（目前最流行的本地模型工具）在自己的電腦跑起來。你之前看過《Mac 安裝 ComfyUI》，這篇的步驟同樣簡單。

為什麼要本地部署？

• 隱私：資料永遠留在自己機器，不上傳。
• 免費：不用付 API token 費用（只有電費與硬體成本）。
• 離線可用：沒有網路也能用。
• 開發測試：接進自己的程式做原型，不用付錢調來調去。

安裝 Ollama

1. 到 https://ollama.com 下載對應作業版本的安裝包並安裝。
2. 安裝後開啟終端機（Mac/Linux 的 Terminal），Ollama 會自動在背景執行。
3. 驗證：輸入 ollama 或 ollama list，沒報錯就成功了。

選一個模型跑起來

Ollama 上有大量開放權重模型。2026 年較熱門的幾個（依 Ollama 排行）：

初次使用建議從小尺寸開始（例如 Qwen3 的 8B 級，約 5GB），確認硬體跟得上再換大的。想測試能「看圖」的多模態模型，可以試 Llama 4（Maverick 版約 67GB，記憶體要夠）。

一行命令下載並執行

1
2
3
4
5

# 入門：小、快，適合大多數電腦
ollama run qwen3:8b

# 多模態（能理解圖片），硬體要求較高
ollama run llama4:16x17b

跑起來後，終端機就會變成一個聊天視窗，直接打字提問即可。按 Ctrl+D 或輸入 /exit 離開。

常用指令：

1
2
3

ollama list          # 列出已下載的模型
ollama pull qwen3:8b # 只下載不立即對話
ollama rm qwen3:8b   # 刪除模型

你的硬體跟得上嗎？

本地跑模型最看重 RAM（記憶體） 與 VRAM（顯存，若有 NVIDIA 卡）。規則大致是：

• 模型參數越大，需要的記憶體越多。一個大概估算法：7B 模型約需 4～6GB，70B 則要 40GB 以上。
• Mac 使用者：統一記憶體（Unified Memory）越大越好，M 系列晶片對本地模型支援佳。
• 跑不動大模型？ 用較小尺寸或「量化版」（檔名常帶 :b 或 :q），犧牲一點精度換更小佔用。

接進自己的程式（OpenAI 相容 API）

Ollama 內建一個 OpenAI 相容的本地 API，所以上一篇寫的程式碼幾乎不用改就能改用本地模型：

1
2

# 預設監聽 localhost:11434
ollama serve

Python 呼叫範例（把 base_url 指向本地）：

1
2
3
4
5
6
7
8
9
10
11
12

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",  # 本地模型隨便填
)

response = client.chat.completions.create(
    model="qwen3:8b",
    messages=[{"role": "user", "content": "解釋什麼是向量資料庫"}],
)
print(response.choices[0].message.content)

這樣你就用免費、離線的模型跑出了跟 OpenAI 一樣的程式。

接進開發工具

Ollama 也能直接接進編輯器與 AI 開發代理（例如 Claude Code、OpenCode），在 ollama 的整合清單裡就能看到。設定後，寫碼時調用的就是你本地的模型，既免費又隱私。

小結

• Ollama 是本地上線大模型最簡單的工具，一行命令即可。
• 2026 熱門本地模型：Qwen3（入門）、Llama 4（多模態），依硬體選尺寸。
• 重點看硬體（RAM/VRAM），跑不動就換小尺寸或量化版。
• 內建 OpenAI 相容 API，上一篇的程式碼幾乎不用改就能本地化。

學會本地模型後，你已經能免費玩各種 AI。下一篇回到創作面向：AI 圖像生成。

《AI 新時代》系列第 08 篇。上一篇：Function Calling · 下一篇預告：AI 圖像生成

RAG 讓 AI 能「讀資料」，但現實中更多工作需要它執行動作：查天氣、訂機票、查庫存、算匯率。這些都在外部系統裡，模型本身做不到。

Function Calling（函式呼叫） 解決這件事：你可以定義一些工具給模型，當它判斷需要時，會回傳「要呼叫哪個函式、參數是什麼」，由你的程式去執行。

為什麼需要 Function Calling？

LLM 訓練完的那一刻，知識就停止了。它不知道：

• 台北現在幾度
• 某支股票現在的價格
• 資料庫裡這個帳號的訂單狀態

但它可以呼叫你提供的函式拿到這些即時資訊，再據此回答。這讓 AI 從「只會聊天」變成「能做事的助理」。

運作原理：一次來回

Function Calling 不是模型自己跑程式，而是兩方配合：

1. 使用者提問：「台北今天天氣如何？」
2. 模型判斷需要天氣資料，回傳一個結構化請求：{"function": "get_weather", "args": {"city": "Taipei"}}。
3. 你的程式收到這個請求，去執行真正的 get_weather API，拿到結果（例如 28°C 晴）。
4. 你把結果回給模型。
5. 模型用真實資料組織成自然語言回答：「台北今天約 28 度，天氣晴朗。」

重點：模型只負責決定「要調哪個工具、參數多少」，實際執行是你的程式。

怎麼定義一個工具？

你需要用 JSON Schema 描述這個函式，讓模型知道有哪些參數、什麼類型：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "取得指定城市目前的天氣",
    "parameters": {
      "type": "object",
      "properties": {
        "city": {
          "type": "string",
          "description": "城市名稱，例如 Taipei、Tokyo"
        }
      },
      "required": ["city"]
    }
  }
}

完整實作（Python）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

import os, json
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

# 你的真實工具：實際去呼叫天氣 API
def get_weather(city):
    # 這裡換成真正的 API 呼叫
    return f"{city} 現在 28°C，晴"

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "取得指定城市目前的天氣",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "城市名稱"}
            },
            "required": ["city"]
        }
    }
}]

# 第一步：送出問題與工具定義
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "台北今天適合出門嗎？"}],
    tools=tools,
)

message = response.choices[0].message

# 模型決定要呼叫工具
if message.tool_calls:
    for call in message.tool_calls:
        args = json.loads(call.function.arguments)
        # 第二步：你的程式執行真實函式
        result = get_weather(**args)
        # 第三步：把結果回給模型
        messages.append({
            "role": "tool",
            "tool_call_id": call.id,
            "content": result
        })
    # 第四步：讓模型根據實資組織回答
    final = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=messages
    )
    print(final.choices[0].message.content)

實際應用場景

• 查即時資訊：天氣、股價、交通、匯率。
• 操作資料庫：查詢訂單、用戶資料後作答。
• 觸發動作：寄郵件、建立 ticket、發送通知。
• 計算器／程式碼執行：讓模型呼叫計算工具，避免算錯。
• 結合 RAG：RAG 給「讀」的能力，Function Calling 給「做」的能力，兩者常一起用。

注意事項

• 驗證參數：模型可能傳入錯誤或惡意參數，執行前務必檢查。
• 安全邊界：不要給模型能刪除資料、付款等高危工具的未經審查存取。
• 網路延遲：每次工具來回都是一次等待，多輪工具會變慢。
• 成本：每調一次工具就多一次請求，注意 token 累積。

小結

• Function Calling = 定義工具讓模型決定何時呼叫，你的程式負責實際執行。
• 流程：問 → 模型回傳工具請求 → 你執行 → 回結果 → 模型組織回答。
• 用 JSON Schema 描述函式參數。
• 結合 RAG 與 Agent，就能打造能「讀又能做」的完整助理。

學會單個工具後，下一篇我們玩更大的：用 Ollama 在自己的電腦本地部署大模型，完全離線、免費、隱私。

《AI 新時代》系列第 07 篇。上一篇：RAG · 下一篇預告：Local LLM

上一篇學會用 API 呼叫模型，但你會發現一個致命問題：AI 只知道它訓練時學到的知識，不知道你的私人文件、最新資料或公司內部資訊，有時還會「一本正經地胡說八道」（幻覺）。

RAG（Retrieval-Augmented Generation，檢力增強生成） 就是為了解決這個問題而生的技術，也是目前企業應用 AI 最主流的做法。

問題：為什麼模型會不知道你的資料？

有三種方式讓 AI 知道特定內容，各有限制：

RAG 的思路很聰明：不改模型本身，而是在它回答前，先幫它查到相關資料塞進去。

RAG 怎麼運作？兩個階段

階段一：建立索引（離線處理）

當文件進系統時：

1. 切分（Chunking）：把長文件切成一小塊一小塊（例如每段 500 字）。
2. 轉成向量（Embedding）：用 Embedding 模型把文字轉成一串數字（向量）。意思相近的句子，向量在空間裡也接近。
3. 存進向量資料庫：保存這些向量，方便日後比對相似度。

階段二：回答時檢索（線上處理）

當使用者提問時：

1. 把問題也轉成向量。
2. 在資料庫中找出與問題最相似的幾個文件區塊。
3. 把這些區塊 + 問題一起送給 LLM。
4. LLM 就「開著參考資料」作答，答案會附上來源。

比喻：RAG 就像讓員工回答前，先去公司資料庫翻相關檔案，而不是憑記憶瞎猜。

關鍵詞：Embedding 與向量資料庫

• Embedding（嵌入）：把文字轉成能表達「語意」的數字向量。例如「今天很熱」和「天氣很炎熱」的向量會很接近。
• 向量資料庫：專門儲存並快速搜尋相似向量的資料庫，常見的有 Chroma、Pinecone、Qdrant、Weaviate，Python 的 FAISS 也常用。
• 相似度搜尋：找出與問題最相近的文件區塊，是 RAG 品質的關鍵。

最小實作流程（概念碼）

用 Python 大致長這樣（搭配 LangChain 這類框架會更簡單）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

from langchain.document_loaders import TextLoader
from langchain.text_splitter import CharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA

# 1. 讀文件
docs = TextLoader("公司手冊.txt").load()

# 2. 切分區塊
splitter = CharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_documents(docs)

# 3. 建 embedding 並存進向量庫
vectorstore = Chroma.from_documents(chunks, OpenAIEmbeddings())

# 4. 建立檢索問答鏈
qa = RetrievalQA.from_chain_type(
    llm=ChatOpenAI(model="gpt-4o-mini"),
    chain_type="retrieve",
    retriever=vectorstore.as_retriever()
)

print(qa.run("請說明公司的請假規定"))

為什麼企業都愛 RAG？

• 資料私有且即時：用你自己的文件，而且更新文件就好，不用重訓模型。
• 減少幻覺、可溯源：答案有根據，還能標註來源讓使用者查證。
• 成本低：只傳相關的幾區塊，省 token。
• 跨語言／多格式：PDF、Word、網頁都能處理。

要注意的風險

• 檢索失準就答錯：如果沒查到正確文件，答案還是會偏。這稱為「垃圾進、垃圾出」。
• RAG poisoning（投毒）：惡意人在文件中放入誤導內容，可能操縱模型輸出。企業應用要留意資料來源可信度。
• 切分方式影響效果：區塊切太好太壞，直接決定搜尋品質，需要反覆調整。

小結

• RAG = 回答前先檢索相關文件，再結合給模型。
• 核心三步驟：切分 → Embedding → 向量資料庫。
• 優點是資料私有、即時、可溯源、成本低。
• 要注意檢索失準、投毒攻擊、切分品質。

RAG 是我們「用自己的資料」的關鍵技術。下一篇更簡單有趣：Function Calling——讓 AI 學會使用外部工具與 API。

《AI 新時代》系列第 06 篇。上一篇：OpenAI API 入門 · 下一篇預告：Function Calling