最近開源 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 卡可能支援度低，檢查時留意驅動版本。

這篇文章要解決一個很實際的問題：每次要發版，手動構建、上傳 AAB、填測試記錄，既重複又容易出錯。用 fastlane 把它自動化之後，本地一行指令、或是在 CI 推版自動觸發，就能把新版本送到 Google Play 的測試軌或正式版。

適用場景與核心目標

• 適用：原生 Android、Flutter（build/app/outputs/bundle/release/...）、React Native 等任何能產出 AAB 的專案。
• 核心目標：用 fastlane 把「構建 Release AAB → 上傳到 Google Play」這條路徑自動化，涵蓋本地執行與 GitLab CI/CD 兩種情境。

本文假設你已經有 Google Play Developer 帳號、在 Play Console 建立好 App，也能手動構出一個 Release AAB。如果 App 還是草稿狀態（商店資料、Data safety 沒填完），即使 automation 配好也可能發不出去，請先確認前置條件。

先看結論

整條流程長這樣：

1
2
3

1. Google Cloud Console：建 Project → 啟用「Google Play Android Developer API」→ 建 Service Account → 下載 JSON key
2. Google Play Console：邀請該 Service Account 帳號 → 給它最小必要權限
3. 本地 / CI：用 JSON key + fastlane 構建 AAB 並上傳到指定軌道

跟 iOS 用 App Store Connect 那套 API Key ID / Issuer ID / API Secret 不同，Google Play 這側只需要一個 Service Account JSON key，fastlane 直接讀整個檔案即可。

開始前確認你已經有：

1. Google Play Developer 帳號
2. 在 Play Console 建立好 App
3. 包名（applicationId / package name）已確定
4. 能構出 Release AAB
5. 環境裝好 Ruby 與 fastlane

前置條件：先確認能手動構出 Release AAB

自動化之前，請先確保你能手動產出可用的 AAB。原生專案在專案根目錄執行：

1

./gradlew bundleRelease

成功後會產生（預設路徑）：

1

app/build/outputs/bundle/release/app-release.aab

Flutter 則是：

1

build/app/outputs/bundle/release/app-release.aab

如果這一步就有問題（例如簽名、編譯錯誤），先把它修好再談自動化。

簽名：Release AAB 怎麼來

Release AAB 必須用你的私鑰簽過名。你需要一個 keystore 檔案（.jks）。如果還沒有，可以用 keytool 產生一支：

1
2
3
4
5
6
7
8

keytool -genkeypair -v \
    -keystore release.jks \
    -alias release-key \
    -keyalg RSA \
    -keysize 2048 \
    -validity 36500 \
    -storepass YOUR_STORE_PASSWORD \
    -keypass YOUR_KEY_PASSWORD

接下來讓 Gradle 在構建 Release 時用它簽名。為了讓同一套設定能在本地與 CI 通用，建議用環境變數來讀簽名資訊，而不是硬編碼密碼：

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

// app/build.gradle
android {
    ...
    signingConfigs {
        release {
            storeFile file(System.getenv('KEYSTORE_PATH') ?: "release.jks")
            storePassword System.getenv('KEYSTORE_PASSWORD')
            keyAlias System.getenv('KEY_ALIAS')
            keyPassword System.getenv('KEY_PASSWORD')
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
            minifyEnabled false
        }
    }
}

這樣本地只要準備好 release.jks 並設定環境變數就能簽；CI 則在執行時再注入這些變數，密碼永遠不進 Git。

第一步：在 Google Cloud 建立專案與服務帳號

fastlane 要用 Service Account JSON key 來授權，這東西放在 Google Cloud Console：

1. 開 Google Cloud Console，在頂部 Project selector 選 New project，命名例如 google-play-fastlane。
2. 這個 Cloud Project 只用來承載 API 與服務帳號，不是你的 App。

啟用 Google Play Android Developer API

在 Cloud Console 搜尋 Google Play Android Developer API，進入頁面後點 Enable。

注意不要啟錯 API，你要的是 Google Play Android Developer API，不是 Android Management API、Google Maps API 或 Firebase API。沒啟用這個，後面就算 JSON 建好了 fastlane 也連不上。

建立 Service Account 並下載 JSON

進入 IAM & Admin → Service Accounts → Create service account：

1
2

Service account name: fastlane-supply
Description: Used by fastlane to upload Android releases to Google Play

建立後會得到一個帳號郵箱，格式類似：

1

fastlane-supply@your-project-id.iam.gserviceaccount.com

把它記下來，稍後要在 Play Console 邀請它。接著下載金鑰：

1. 點進剛建立的 Service Account。
2. Keys → Add key → Create new key → Key type: JSON → Create。
3. 瀏覽器會下載一個 your-project-id-xxxxxx.json。

這個 JSON 裡已經包含 client_email、private_key、project_id 等認證資訊，fastlane 直接讀整個檔案。不要把裡面的 private_key 單獨拆出來，也不用去找額外的 api key。

第二步：在 Play Console 授權服務帳號

只在 Google Cloud 建好服務帳號還不夠，Play Console 必須顯式授權它，否則會報權限錯誤。

1. 開 Google Play Console，選目標 App。
2. Users and permissions → Invite new users，填入剛才的服務帳號郵箱。
3. 按用途分配最小權限，常見幾種：

1
2
3
4
5
6
7
8
9
10

- 只上傳到測試軌（internal / closed / open）：
    View app information
    Create and edit releases
    Release apps to testing tracks

- 要發正式版：再加
    Release apps to production

- 要管理商店頁文案、截圖、圖標：再加
    Edit store listing

如果只是用 fastlane 上傳 AAB，不需要給 Edit store listing，更別開內購、訂單管理的權限。權限給太少會報這些錯：

1
2
3

The caller does not have permission
Insufficient permissions
Package not found

第三步：本地安裝與初始化 fastlane

如果還沒裝 fastlane：

1

gem install fastlane

團隊協建建議用 Bundler 固定版本。在專案根目錄：

1

bundle init

然後在 Gemfile 加入：

1
2
3

source "https://rubygems.org"

gem "fastlane"

1

bundle install

接著進入 Android 專案根目錄初始化：

1
2

cd your_android_project
fastlane init

它會偵測你的專案並產生 fastlane/ 資料夾，裡面有 Appfile 與 Fastfile。

第四步：設定 Appfile 與 Fastfile

Appfile 告訴 fastlane 包名與 JSON key 位置：

1
2
3

# fastlane/Appfile
package_name("com.yourcompany.yourapp")
json_key_file("/Users/yourname/.keys/play-store-credentials.json")

建議把 JSON key 放在專案外，例如 ~/.keys/play-store-credentials.json。如果一時必須放進專案，務必加進 .gitignore：

1
2

fastlane/*.json
*.jks

Fastfile 定義發布 lane。下面是一個上傳到內部測試軌的範例：

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

# fastlane/Fastfile
default_platform(:android)

platform :android do
  desc "Build signed release AAB and upload to internal testing"
  lane :internal do
    gradle(
      task: "bundle",
      build_type: "Release"
    )
    upload_to_play_store(
      track: "internal",
      aab: "app/build/outputs/bundle/release/app-release.aab",
      release_status: "draft"
    )
  end

  desc "Build signed release AAB and upload to production"
  lane :production do
    gradle(task: "bundle", build_type: "Release")
    upload_to_play_store(
      track: "production",
      release_status: "inProgress"
    )
  end
end

因為簽名設定在 build.gradle 的 signingConfigs.release，gradle bundle 構 Release 時就會自動簽名。如果已在 Appfile 寫入 json_key_file 與 package_name，這裡就不用重複寫。

Flutter 專案的 AAB 路徑不同（build/app/outputs/bundle/release/...），請在 lane 裡用 aab: 明確指定路徑。

執行（用 Bundler 時建議都加 bundle exec）：

1

bundle exec fastlane android internal

驗證 JSON key 是否可用

上傳前可以先驗證格式與基礎認證沒問題：

1

fastlane run validate_play_store_json_key json_key:/Users/yourname/.keys/play-store-credentials.json

常用軌道與發布狀態

Google Play 常見軌道：

1
2
3
4

internal     內部測試
alpha        封閉測試（舊寫法）
beta         開放測試（舊寫法）
production   正式版

release_status 常見值：

1
2
3
4

draft       上傳後不會推給任何人，自己去 Play Console 檢查後再提交
inProgress  進入該軌道的審核/發布流程
completed   直接完成發布
halted      暫停

開發階段建議先用 draft，確認流程穩定後再考慮自動發布。正式環境剛接入 fastlane 時，completed 要謹慎使用。

versionCode 遞增：CI 必做的環節

Google Play 要求每個版本號（versionCode）必須唯一且遞增。手機時代你可能每次手動 +1，自動化後應該讓 CI 自動處理，否則會遇到 Version code has already been used。

最簡單的做法是在 workflow 裡讀取目前的 versionCode、加一後寫回：

1
2
3
4

CURRENT=$(grep -m1 'versionCode' app/build.gradle | grep -oE '[0-9]+' | head -1)
NEW=$((CURRENT + 1))
sed -i "s/versionCode ${CURRENT}/versionCode ${NEW}/" app/build.gradle
echo "新版本號：$NEW"

這個寫法假設 versionCode 定義在 app/build.gradle。如果你的版本號是用其他方式管理（例如 Flutter 在 pubspec.yaml，或用了 flavor），請改用對應的遞增方式；在 GitLab 中直接用上面那段 script 遞增即可。

安全：金鑰與 keystore 不要進 Git

這兩樣東西一旦提交到公開倉庫就等於暴露，務必小心：

• JSON key：本地放 ~/.keys/；CI 裡整份內容存成倉庫 Secret，執行時再寫成檔案。
• keystore 與密碼：keystore 轉 base64 存 Secret，簽名密碼也各存一個 Secret。

.gitignore 至少包含：

1
2
3

*.jks
fastlane/*.json
local.properties

CI/CD：用 GitLab CI/CD 自動發布

下面是一個完整範例：推 tag（例如 v1.2.0）時自動構建並上傳到正式版。把這個 .gitlab-ci.yml 放到專案根目錄即可。

GitLab 的機密資料放在 Settings → CI/CD → Variables，不是 GitHub 那套 Secrets。新增以下變數（建議勾選 Masked；keystore 與 JSON key 再勾選 Protected）：

1
2
3
4
5

GOOGLE_PLAY_SERVICE_ACCOUNT_JSON   # JSON key 整份內容
ANDROID_KEYSTORE_B64               # keystore 的 base64（請存成單行，不要換行）
ANDROID_KEYSTORE_PASSWORD          # keystore 密碼
ANDROID_KEY_ALIAS                  # 鑰別名
ANDROID_KEY_PASSWORD               # 私鑰密碼

Gemfile 與 Gemfile.lock 要提交到倉庫（fastlane 依賴）：

1
2
3

# Gemfile
source "https://rubygems.org"
gem "fastlane"

CI job（.gitlab-ci.yml）：

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

stages:
  - deploy

deploy_play:
  stage: deploy
  # 需在專案 Settings → CI/CD → Runners 指定具有 JDK 17 + Ruby 的自管 runner，或在此加 runner tags
  tags:
    - android-runner
  rules:
    - if: '$CI_COMMIT_TAG'
  script:
    # 寫入 Google Play service account JSON key
    - mkdir -p ~/.keys
    - echo "$GOOGLE_PLAY_SERVICE_ACCOUNT_JSON" > ~/.keys/play-store-credentials.json

    # 解碼 keystore（與 signingConfigs.release 的 KEYSTORE_PATH 對應）
    - mkdir -p app
    - echo "$ANDROID_KEYSTORE_B64" | base64 -d > app/release.jks

    # 簽名環境變數（Gradle signingConfigs.release 會讀這些）
    - export KEYSTORE_PATH=app/release.jks
    - export KEYSTORE_PASSWORD="$ANDROID_KEYSTORE_PASSWORD"
    - export KEY_ALIAS="$ANDROID_KEY_ALIAS"
    - export KEY_PASSWORD="$ANDROID_KEY_PASSWORD"

    # versionCode 自動遞增
    - CURRENT=$(grep -m1 'versionCode' app/build.gradle | grep -oE '[0-9]+' | head -1)
    - NEW=$((CURRENT + 1))
    - sed -i "s/versionCode ${CURRENT}/versionCode ${NEW}/" app/build.gradle

    # 構建並上傳 AAB
    - bundle install
    - bundle exec fastlane android production

幾個重點：

• rules: if: '$CI_COMMIT_TAG' 表示只有推 tag 才觸發，等同 GitHub Actions 的 on: tags。要更精控（例如只在 main 分支發正式版、其他軌道另開 lane）可改用 when: $CI_COMMIT_BRANCH 等條件。
• GitLab 變數用 $VAR 引用（跟 shell 一樣），不需要 ${{ secrets.X }} 這種語法。
• keystore 解碼後放在 app/release.jks，對應前面 signingConfigs.release 的 KEYSTORE_PATH；存 base64 時請確保是單行，否則 base64 -d 會失敗。
• 這個 job 假設 runner 已裝好 JDK 17 與 Ruby（自管 runner 最省事）。若想要容器化，可改用 image: 指定鏡像並自行安裝工具鏈，或寫一個 Dockerfile。

常見問題除錯

1. The caller does not have permission / Insufficient permissions
多半是 Play Console 沒邀請服務帳號，或沒給對應 App 的發布權限。回到 Users and permissions 檢查。

2. Package not found
檢查 package_name 是否寫錯、App 是否真的建立、服務帳號是否有該 App 的權限。

3. Version code has already been used
versionCode 重複了。CI 環境務必加上自動遞增那一步；本地手動發版時記得先 +1。

4. 上傳成功但 Play Console 看不到正式版
檢查：上傳到哪個 track、release_status 是 draft 還是 completed、Managed publishing 是否開啟、App dashboard 是否還有必填項未完成。

5. JSON key 驗證通過卻還是連不上
確認 Google Play Android Developer API 有啟用，且 Play Console 已邀請該帳號並授權目標 App。

上線前檢查清單

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

Google Cloud：
[ ] 建立 Cloud Project
[ ] 啟用「Google Play Android Developer API」
[ ] 建立 Service Account
[ ] 下載 JSON key（放到 ~/.keys/，不要進 Git）

Play Console：
[ ] 邀請服務帳號郵箱
[ ] 給目標 App 最小必要權限

本地：
[ ] 能手構出簽名過的 Release AAB
[ ] signingConfig.release 可用環境變數讀到簽名
[ ] Appfile 設定 package_name 與 json_key_file
[ ] Fastfile 定義 internal / production lane
[ ] validate_play_store_json_key 通過

GitLab CI/CD：
[ ] 在 Settings → CI/CD → Variables 新增所有變數
[ ] Gemfile 與 Gemfile.lock 已提交
[ ] keystore 解碼路徑與 KEYSTORE_PATH 一致
[ ] versionCode 自動遞增
[ ] 推 tag 能觸發並成功上傳

參考資料

• Google Play Developer API Getting Started：https://developers.google.com/android-publisher/getting_started
• fastlane upload_to_play_store：https://docs.fastlane.tools/actions/upload_to_play_store/
• fastlane validate_play_store_json_key：https://docs.fastlane.tools/actions/validate_play_store_json_key/
• Android 簽名文件：https://developer.android.com/studio/publish/app-signing
• GitLab CI/CD 文件（YAML、Variables）：https://docs.gitlab.com/ee/ci/

用 AI 寫程式越來越普及，但付費訂閱動輒每月數百到上千美元，對個人開發者或學生是不小負擔。本文整理多款「可以免費使用」雲端模型的 AI coding agent——Hermes Agent、Freebuff、opencode，以及 Cline、Continue、Aider、Goose、Kilo Code 與 GitHub Copilot Free，說明它們各自是如何做到免費、是永久免費還是限時額度、適合什麼情境，以及要注意的地方。

先下一個結論：這些工具的「免費」原理大致分為幾類——

• Hermes Agent 是開源自架工具，靠切換雲端免費模型供應商來省錢。
• Freebuff 以廣告補貼，開箱即用，官方稱永久免費。
• opencode 本身不綁定廠商，接 OpenRouter 免費層即可零成本使用雲端模型。
• 還有一群開源「自帶模型」Agent（Cline、Continue、Aider、Goose、Kilo Code），工具本身免費，再接 OpenRouter 免費層的雲端模型。
• GitHub Copilot Free 是廠商提供的永久免費層，有固定每月額度。

重要：免費分為兩種——「永久免費」指該方案長期存在（如 $0/月方案、廣告補貼），只要廠商營運就一直在；「免費額度」指註冊時送的額度或每月上限，用盡或政策調整就可能改變。下文會分別標示。

一、Hermes Agent（Nous Research）

Hermes Agent 由 Nous Research 開發，採 MIT 授權開源。它的賣點是內建「自我改進」學習迴圈：會在使用中建立 skills、跨工作記憶、支援多子代理與 cron 排程，可從終端機、桌面版、GitHub Actions 或訊息平台（Telegram、Discord、Slack 等）操作。

如何免費

它本身不綁定單一模型，而是透過供應商中繼來切換，用 hermes model 一命令就能換模型，不用改程式。免費主要靠以下幾個雲端供應商的免費層：

安裝方式

1
2
3

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
source ~/.bashrc
hermes setup

跑完 hermes setup 後選擇 OpenRouter 或 NVIDIA NIM 即可開始，兩者都免信用卡。日常開發遇到速率上限時，用 hermes model 換供應商即可。

二、Freebuff（Codebuff）

Freebuff 由 Codebuff（YC F24，創辦人 James Grugett，X 帳號 @jahooma）出品，定位是「完全免費的 coding agent」，主打替代 Claude Code、Cursor、Codex、Lovable 等付費工具。核心模式是廣告補貼：使用期間顯示文字廣告來支付模型成本，因此無需訂閱、無需 API key、無需信用卡。程式碼採 Apache 2.0 開源，背後還有付費版 Codebuff。官方首頁明確標示「$0 / yr」與「Freebuff is $0. Forever.」。

五種介面

Freebuff 在同一套免費服務下提供多種使用方式：

• CLI：終端機內直接使用，npm install -g freebuff 後執行 freebuff。
• Desktop：macOS／Windows／Linux 原生應用程式，可平行運行多個代理。
• Web：瀏覽器內建全棧網頁應用，從提示到上線網址。
• Cloud：雲端 IDE，連到任意 GitHub repository，含沙箱與預覽。
• Chat：免費 AI 聊天，適合研究與深度思考。

目前使用的模型包含 DeepSeek V4 Flash、GPT 5.6 Luna、MiniMax M3 等（實際可用模型會調整）。

三、opencode

opencode 是開源（MIT）、以終端機為主的 AI coding agent，截至 2026 年 8 月已是 GitHub 上最受歡迎的 coding agent（約 193K star）。它透過 AI SDK 與 Models.dev 整合 75+ 模型供應商，最大特色是不綁定單一廠商。

如何免費

opencode 本身不收錢，費用來自後端模型。零成本的做法是接入 OpenRouter 免費層：與 Hermes 相同，用 OpenRouter 標 :free 的雲端模型，一組 key 即可開始（長期免費層，有速率限制）。設定時在 opencode 的設定檔中選 OpenRouter 供應商並指定一個 :free 模型即可。

四、其他開源、自帶模型的 Agent（BYOM）

這群工具與 opencode 理念相近：工具本身免費且開源，再接 OpenRouter 免費層的雲端模型。適合已經知道要用哪個模型的人。

• Cline：最流行的開源擴充之一，支援 Anthropic、OpenAI、Google、OpenRouter 等，並已推出獨立 CLI。
• Continue：強調「即插即用」的程式碼編輯器擴充，可接雲端免費模型。
• Aider：終端機優先，與 Git 深度整合，適合習慣命令列與版本控制的開發者。
• Goose：由 Block（Square）出品，原生桌面版＋CLI，除寫碼外也能做研究、自動化等通用任務。
• Kilo Code：Roo Code 於 2026 年 5 月停運後，由社群維護的活躍分支，延續相似操作體驗。

五、廠商官方免費層（GitHub Copilot Free）

如果不想自己管理 API key，可以直接用廠商提供的免費層。GitHub Copilot Free 經官方頁面核實為永久免費（$0／月／使用者），有固定每月額度：

• 包含內容：每月 2,000 次程式補全、50 次聊天請求（含 Copilot Edits）、Copilot CLI、社群支援。
• 可用模型：Haiku 4.5、GPT-5 mini 等。
• 資格：個人開發者即可；持有 Business／Enterprise 席位的用戶不符合。無需信用卡。
• 說明：這是長期存在的 $0 方案，額度每月重置，用盡可下月恢復或付費升級 Pro（$10／月）。

其他廠商（如 Amazon Q Developer）也有免費層，但本會無法取得其官方頁面核實當前額度與期限，故暫不列入；如需可另行確認後再補上。

六、綜合比較

七、該如何選擇

• 想快速上手、不想碰設定：選 Freebuff。安裝後就能用，適合學生、興趣專案或不想處理 API 的人。代價是用廣告換免費，且主要走雲端，需接受其隱私權政策。
• 想要彈性、喜歡自架與學習原理：選 Hermes Agent。可自由切換雲端免費供應商，適合想深入理解 agent 運作、需要記憶／排程／多代理功能的開發者。
• 已經在用終端機 agent：選 opencode 或 Cline／Goose／Aider等，接 OpenRouter 免費層即可零成本使用雲端模型。
• 只想少量使用、連 key 都不想管：選 GitHub Copilot Free，每月 2,000 次補全加 50 次聊天夠入門使用。

八、注意事項

免費使用通常伴隨以下代價，挑選前請留意：

1. 「永久」不等於「無限」：即使是永久免費方案（如 Copilot Free、Freebuff），也有每月額度或速率上限；用盡需等待重置或付費。
2. 速率限制：例如 OpenRouter 免費層為 200 請求／天、20 請求／分，agentic 多步任務容易觸限，需準備備用供應商。
3. 廣告與雲端隱私：Freebuff 以廣告換免費且主要走雲端，處理機密程式碼前請閱讀其隱私權與服務條款。
4. 模型品質與穩定性：免費層多用較小或較新的模型，品質、速度、穩定度通常不如付費方案。
5. 政策會變動：廠商免費額度與可用模型可能隨時調整，建議不要單點依賴，保留切換能力。

總結來說，這些工具都能零成本起步：Freebuff 最省事且官方稱永久免費、Hermes 最彈性、opencode／Cline／Goose／Aider 適合已在 IDE 或終端機工作流的人，GitHub Copilot Free 則是最省手的廠商永久免費層。可依「怕不怕設定」與「重不重視隱私」來決定從哪個開始嘗試。

前面第 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 圖像生成