一張 RTX 3060 Ti 跑 4 隻 AI Agent：完整硬體配置、效能調校與 30 天實戰數據
一張 RTX 3060 Ti 跑 4 隻 AI Agent
「RTX 3060 Ti 不是遊戲卡。它是一台 $300 美金的 AI Agent 伺服器，24/7 不休息。」
大多數部署 AI Agent 的團隊完全依賴雲端 API — OpenAI、Anthropic、Google。每次請求都有成本、每次請求資料都離開你的網路、每次請求都依賴別人的 uptime。
我們走了不同的路。Ultra Lab 的 4 隻自治 AI Agent 全部跑在一張 NVIDIA RTX 3060 Ti 上。本地推論、完全隱私、邊際成本趨近於零。
這篇文章完整涵蓋：硬體、模型選擇、效能調校、和 30 天生產環境數據。
硬體規格
| 項目 | 規格 |
|---|---|
| GPU | NVIDIA RTX 3060 Ti（8GB GDDR6X） |
| VRAM | 8GB（模型使用 5.7GB） |
| CUDA Cores | 4,864 |
| 環境 | WSL2 Ubuntu on Windows 10 |
| 推論引擎 | Ollama |
| 成本 | 約 $300 USD（二手） |
RTX 3060 Ti 是甜蜜點：VRAM 夠跑量化 7B 模型、CUDA 核心數夠用、價格低到 ROI 用週計算。
模型：ultralab:7b
我們基於 Qwen 2.5 7B 建了自訂模型：
基底：qwen2.5:7b（Q4_K_M 量化）
大小：4.7 GB
上下文：16,384 tokens
自訂：品牌知識、產品資料、語氣風格直接寫進系統提示詞
透過自訂 Modelfile，品牌身份、產品知識和溝通風格直接注入模型。每隻 Agent 共用同一個基底模型，但有各自的角色系統提示詞。
為什麼不用更大的模型？
我們測過 Qwen 3 8B，結果：
| 模型 | 大小 | VRAM | 速度 | 結論 |
|---|---|---|---|---|
| qwen2.5:7b（Q4_K_M） | 4.7 GB | 5.7 GB | 13.2 tok/s | 上線使用 |
| qwen3:8b | 4.9 GB | >8 GB | 1.7 tok/s | 放棄 |
Qwen 3 8B 慢了 7.8 倍。模型勉強塞進 8GB VRAM，大量 CPU offload。而且它有「思考模式」，每次回應都有額外開銷。不值得。
教訓：8GB VRAM 上，調好的 7B 模型永遠贏過硬塞的 8B 模型。
效能：真實數字
經過大量調校後的生產環境數據：
吞吐量： 13.2 tokens/second
GPU Offload：88%（5.7 / 6.5 GB VRAM 使用中）
上下文窗口： 16,384 tokens
首 token 延遲：~200ms
Uptime： 99.9%（systemd 自動重啟）
上下文窗口陷阱
我們一開始設 32,768 tokens。效能直接崩到 0.1 tok/s — 慢了 132 倍。KV cache 溢出 VRAM 灌到系統記憶體，CPU-GPU 資料傳輸成為瓶頸。
降到 16,384 tokens 後速度完全恢復。對 Agent 任務（社群發文、互動回覆、內容生成），16K 上下文綽綽有餘。
規則：8GB VRAM + 7B 模型，上下文永遠不要超過 16K。
4 隻 Agent 艦隊
每隻 Agent 有獨立角色，自治運作：
| Agent | 角色 | 平台 | 每日任務 |
|---|---|---|---|
| UltraLabTW | CEO 兼品牌策略 | Moltbook, Discord | 8 篇貼文 + 策略 |
| MindThreadBot | 社群媒體專家 | Moltbook | 8 篇貼文 + 互動 |
| UltraProbeBot | AI 安全研究員 | Moltbook | 8 篇貼文 + 研究 |
| UltraAdvisor | 智能顧問 | Moltbook | 內容 + 分析 |
編排架構
┌─────────────────────────────────────┐
│ OpenClaw Gateway │
│ (Port 18789) │
├─────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────────────┐ │
│ │ Ollama │ │ 25 個 Systemd │ │
│ │ Server │ │ 定時器 │ │
│ │ │ │ │ │
│ │ ultralab │ │ 62 個腳本 │ │
│ │ :7b │ │ (bash + node) │ │
│ │ │ │ │ │
│ │ RTX 3060 │ │ 19 個情報檔案 │ │
│ │ Ti CUDA │ │ (.md) │ │
│ └──────────┘ └──────────────────┘ │
│ │
│ ┌──────────────────────────────┐ │
│ │ 4 個 Agent 工作區 │ │
│ │ (每隻 Agent 獨立上下文) │ │
│ └──────────────────────────────┘ │
└─────────────────────────────────────┘
所有 Agent 共用同一張 GPU。Ollama 處理請求排隊 — 一次一個推論（NUM_PARALLEL=1）。25 個定時器在一天中交錯執行，GPU 衝突極少。
Systemd 配置
穩定性來自 systemd。Ollama 作為系統服務運行，有效能覆寫設定：
# /etc/systemd/system/ollama.service.d/performance.conf
[Service]
Environment="OLLAMA_KEEP_ALIVE=2h"
Environment="NUM_PARALLEL=1"
Environment="MAX_LOADED_MODELS=1"
關鍵設定：
- OLLAMA_KEEP_ALIVE=2h：模型在 VRAM 保持載入 2 小時。載入/卸載 4.7GB 模型要 ~8 秒 — 排程任務無法接受。
- NUM_PARALLEL=1：單一推論串流。8GB VRAM 上平行推論會 OOM 崩潰。
- MAX_LOADED_MODELS=1：VRAM 只放一個模型。所有 Agent 用同一個模型，沒問題。
健康監控
systemd 定時器每 10 分鐘驗證 Ollama 和 OpenClaw gateway 是否正常：
# 健康檢查：驗證 Ollama 有回應
curl -sf http://localhost:11434/api/tags > /dev/null || systemctl restart ollama
Ollama 偶爾會掛（連續運行 ~72 小時後少見但會發生），自動重啟。模型 ~8 秒重新載入。不需要人工介入。
30 天生產環境數據
連續運行一個月後：
| 指標 | 數值 |
|---|---|
| 總推論請求 | ~3,150 |
| 平均每日任務 | 105 |
| GPU 使用率（平均） | 12-18% |
| GPU 使用率（尖峰） | 94%（批次生成時） |
| 停機事件 | 2 次（自動恢復） |
| 人工介入 | 0 次 |
| 電費 | ~$5/月 |
| 雲端 API 費用 | $0 |
GPU 大部分時間閒置。Agent 任務是 bursty 的 — 幾秒鐘 90%+ GPU 使用率，然後幾分鐘閒置。RTX 3060 Ti 滿載 ~200W，閒置 ~15W。
成本比較：本地 GPU vs 雲端 API
以我們的工作量（~3,150 請求/月，平均每次回應 200 tokens）：
| 方案 | 月費 | 隱私 | 延遲 | Uptime 控制 |
|---|---|---|---|---|
| RTX 3060 Ti（本地） | ~$5（電費） | 完全 | 200ms | 你自己 |
| OpenAI GPT-4o-mini | ~$6.30 | 無 | 500ms+ | OpenAI |
| Anthropic Haiku | ~$7.90 | 無 | 400ms+ | Anthropic |
| Google Gemini Flash | 免費（1,500 RPD） | 無 | 300ms+ | |
| RunPod（A40 時租） | ~$50+ | 部分 | 150ms | RunPod |
低量 Agent 工作負載下，成本差異不大。本地推論真正的優勢是：
- 隱私：敏感資料（客戶洞察、商業策略）永遠不離開你的網路
- 穩定性：沒有 API 限速、沒有你無法控制的停機
- 客製化：品牌調教的模型，內建領域知識
- 可預測：固定成本，不管用量如何波動
我們踩過的坑
1. 下載模型會殺死推論
下載新模型的同時跑推論，吞吐量從 13.2 tok/s 掉到 0.1 tok/s。Ollama 的下載和推論共用 GPU 記憶體匯流排。
解法：只在沒有排程任務的維護時段下載模型。
2. 32K 上下文災難
在 Agent 設定裡寫 contextWindow: 32768 看起來合理。結果慢了 132 倍。KV cache 超出 VRAM 溢到系統記憶體。
解法：contextWindow: 16384。部署前一定要測你的 VRAM 預算。
3. Timeout 層級混亂
OpenClaw 有三個地方可以設 timeout：agents.defaults.timeoutSeconds、payload.timeoutSeconds、和 --timeout。只有第一個真正控制 timeout。
解法：永遠在 openclaw.json 的 agents.defaults.timeoutSeconds 設定。其他的忽略。
4. Gemini 計費陷阱
切換到本地推論前，我們用 Gemini API。從啟用計費的 Google Cloud 專案建立的 API key，7 天燒了 $127.80。思考 token 要 $3.50/1M — 比輸入 token 貴 47 倍。
解法：所有 Agent 推論遷到本地 Ollama。零 API 費用。零帳單意外。
什麼時候適合本地 GPU 推論
適合你的情況：
- 你跑的是重複性自動化任務（不是偶爾查詢）
- 你處理敏感資料，不能離開你的網路
- 你需要可預測的成本，不要按 token 計費
- 你想完全掌控 uptime 和模型版本
- 你手邊有閒置的 NVIDIA GPU
不適合的情況：
- 你需要 GPT-4 或 Claude 等級的推理能力（7B 模型無法匹敵前沿模型）
- 你的工作負載是零星的（GPU 反正大部分時間閒置）
- 你需要 >32K 上下文窗口（需要 24GB+ VRAM）
下一步
我們的 roadmap：
- 多 GPU 擴展：加第二張 RTX 做平行 Agent 推論
- 更大的模型：RTX 4090（24GB VRAM）可以全速跑 14B-32B 模型
- 企業級本地安全掃描：讓 UltraProbe 的弱點分析在本地 NVIDIA GPU 上跑，服務無法將資料送上雲端的企業
- 模型微調：在 NVIDIA 硬體上訓練領域特定的 LoRA adapters
RTX 3060 Ti 證明了生產級 AI Agent 基礎設施不需要雲端 GPU 或企業級硬體。一張 $300 的顯卡、好的工程、和 systemd 的穩定性，就夠了。
自己試試
我們的 Agent 艦隊架構已開源：
- GitHub: free-tier-agent-fleet
- Agent 艦隊戰情室: ultralab.tw/agent
- 架設教學: OpenClaw AI Agent 架設指南
Ultra Lab 造 AI 產品。我們有 4 個上線產品，包括由 NVIDIA GPU 推論驅動的自治 Agent 艦隊。了解更多：ultralab.tw