OpenClaw 完美結合 120B 大模型「對不起，地端 AI 我回來了！」：Agent Skill 實測，這才是完全體！
在上一集影片中，我們分享了使用 OpenClaw 搭配本地模型踩坑的慘痛經驗，當時的結論似乎是「雲端模型還是比較香」。然而，影片發佈後，許多熱心的技術先進在留言區提供了寶貴建議，特別是關於 Context Window 和推理引擎的選擇。
受到這些建議的啟發，我們決定重燃挑戰決心！這次花了整整四天晚上，交叉測試了 Ollama、vLLM、LM Studio 以及 llama.cpp 四大引擎，終於找到了一個真正穩定、可用的本地端解決方案。
本篇文章將為大家詳細導讀這段「從踩坑到成功」的技術探索之旅。
一、試錯之路：那些年我們踩過的坑
在找到正解之前，我們嘗試了幾種主流的本地模型運行方式，但都遇到了致命的問題。
1. Ollama：Context Window 的陷阱
Ollama 是目前最親民的本地模型工具。我們嘗試在 Ollama 中將 Context Window 調大到 65536 (64k)，希望能處理更長的對話歷史。
- 問題：雖然我們使用了一張擁有 96GB VRAM 的 NVIDIA RTX Pro 6000 顯卡，且模型確實載入到了 GPU 中，但推理速度卻異常緩慢。
- 原因：當 Context Window 設定過大時，Ollama 判斷 VRAM 不足以容納巨大的 KV Cache，因此自動將運算 Offload 到 CPU。導致「模型在 GPU，計算在 CPU」的詭異現象，生成一個回應要等好幾分鐘。
2. vLLM：Docker 下載無底洞
vLLM 以高效能著稱，支援 PagedAttention 等先進技術。我們嘗試使用 Docker 部署 vLLM 來載入 GPT-OSS-120B。
- 問題：模型下載始終無法完成。雖然指令看起來沒問題，網路也有在跑，但就是卡在下載階段。這可能是 Docker 網路設定或是 Hugging Face 連線的問題。
3. LM Studio：記憶體怪獸
LM Studio 是另一個介面友善的選擇。我們嘗試載入 120B 模型並設定 64k Context。
- 問題：系統主記憶體 (System RAM) 直接被吃到 99%！注意，不是 VRAM，而是系統 RAM。電腦幾乎當機，模型載入進度條也卡死不動。
二、最佳解方：llama.cpp 的逆襲
在歷經多次失敗後，我們回歸到最底層、最硬核的解決方案：llama.cpp。
一開始使用 llama.cpp 時，我們也遇到了模型「鬼打牆」、不斷重複輸出的問題。經過深入研究，我們發現了兩個關鍵參數：
關鍵參數解析
- 不要手動指定 Chat Template：讓引擎自動從 GGUF 檔案的 metadata 讀取正確的 template，避免格式錯誤導致模型錯亂。
--no-mmap：這是救命稻草！這個參數告訴 llama.cpp 不要使用記憶體映射 (Memory Mapped) 載入模型，這成功避免了系統 RAM 被吃滿的問題，讓模型乖乖待在 GPU VRAM 裡。
最終成功的啟動指令：
llama-server.exe -m "模型路徑" -ngl all -c 65536 -t 8 -np 1 --port 8080 --no-mmap -fa on三、OpenClaw 實戰：Agent Skill Demo
成功運行本地模型後，我們將其接入 OpenClaw 進行實測。我們給它一個任務：「規劃沖繩自由行，並截圖 Google Maps 路線圖存到 Word 檔」。
實測結果
- 耗時：約 9 分鐘。
- Token 消耗：約 71,745 tokens。
- 表現：雖然最終完成了任務，但過程並不順利。模型有時會忘記放圖，有時會突然用全英文寫作，需要人工介入糾正。
這顯示出本地模型 (GPT-OSS 120B) 與雲端頂級模型 (如 Claude 3.5 Sonnet) 之間仍有明顯差距。如果是用 Claude，這個任務可能一次指令就能完美達成。
四、總結：你適合本地模型嗎？
這場實驗證明了本地端運行 120B 大模型並執行 Agent 任務是完全可行的，但它有門檻，也有代價。
- 如果你追求效率與省事：請繼續使用雲端模型 (Claude/OpenAI)。它們更聰明、更快、更穩定。
- 如果你是技術狂熱者、在意隱私、或想完全掌控系統：那麼挑戰本地模型絕對值得。你會清楚知道每一筆資料的流向，每一個參數的意義。
希望這篇導讀能幫助大家在本地 AI 的建置路上少走一點彎路。如果你也有類似的經驗，歡迎留言交流！
