這三十天（包含下訂、寫runbook、配送到貨、拆箱、安裝、逐字稿POC），我完成了一套地端 AI 工作站的部署。

開箱後七天內的安裝與試錯、從調 BIOS、部署 Docker、安裝 Agent，到最後成功跑完一本 786 頁繁體 PDF 的 OCR POC，前前後後踩了不少坑。

這 786 頁是手機截圖 PDF，本質是 image-based、又是 DRM 電子書、
超過雲端 100 頁 / 32MB / 200K tokens 的限制。
我在手機 App 的 AI 試過、在 Google AI Studio 試過，
都是「卡到版權限制」、「讀了幾頁就停」、「靜默截斷讓你以為讀完」。

我的 A9 + Qwen3.6-35B-A3B 用 8 小時 48 分鐘，
跑完整 786 頁、9.5/10 品質、平均每頁 40 秒。

至少在我實際測試的幾個雲端 AI 工具中，都無法完整完成這份 OCR 工作。

想把這段不算短的真實經歷寫下來。
這不是一篇「裝 AI 教學文」，而是一份完整 AI 部署決策的踩坑前傳。

結論先講
地端 AI 部署跟雲端使用 AI 不一樣。重點不是「模型跑得多快」，是「完整決策鏈能不能撐起來」。
我這 30 天繳了學費與花了大把時間試錯才學到：硬體怎麼選、顯存怎麼配、模型怎麼換、Agent 怎麼分工、POC 怎麼跑通。

第一個決定：硬體
朋友很興奮地分享買 Mac Studio M3 Ultra 進入 AI 供應鏈的經驗。
我最後是選 GEEKOM A9 Mega，AMD Strix Halo 128GB UMA 的迷你電腦，NT$105,000 左右。

很多人第一時間會問：為什麼不是 Mac Studio？或者 RTX 工作站？
我選擇 AMD Strix Halo，不是因為它最便宜，也不是因為它最快，而是因為它最符合我的工作場景。
第一，我每天處理的是合約、付款審核、ESG（EcoVadis、CDP）、資安與內部稽核文件，這些資料不能離開企業環境。
第二，我需要一台能直接融入既有 Windows 工作流程的工作站。Windows 11 搭配 Docker Desktop 可以自然整合 Active Directory、檔案伺服器、企業防毒、Group Policy 以及既有的 x86 工具鏈，部署與維運成本最低。
第三，128GB 的統一記憶體提供了比 96GB 更大的容量餘裕（Mac Studio M3 Ultra 上限 96GB），讓我能更靈活地在大型模型、KV Cache、Docker 服務與作業系統之間分配資源。
我選的不是「最便宜的 AI 電腦」，而是「最符合 24/7 AI workstation 工作流的硬體」。

第二個決定：顯存配置
買回來之後才發現，光有硬體還不夠，要讓 AMD Strix Halo 的 128GB UMA 真的發揮作用，得進 BIOS 調整一堆參數。
最有意思的學到是：LM Studio 用 ROCm 引擎時，可用的 VRAM 比用 Vulkan 引擎時大。
一開始我以為 Vulkan 比較通用（跨平台、跨廠商）應該比較好，實測之後才發現 AMD Strix Halo 的 128GB UMA 在 ROCm 路徑下才能完整發揮。
這跟我原本想的不一樣。我以為用通用的 Vulkan 引擎會比較穩定，結果發現工具鏈的成熟度才是關鍵。AMD 對 ROCm 的最佳化遠比 Vulkan 完整，VRAM 可用率與效能都比較好；速度兩者相近，但 ROCm 能用到的 VRAM 容量更大（87.87GB vs 64GB）。
這個部署踩到學到的是，選擇引擎時要看硬體廠商原生支援哪個，不是看哪個框架比較通用。

第三個決定：模型
原本的 Runbook 規劃是用 Qwen3-30B-A3B（MoE 架構，總參數 300 億、激活 30 億，Q4_K_S 量化約 18GB）。這是個合理的選擇：MoE 省記憶體，30B 級別的智能。
但實際部署之後，我改用 Qwen3.6-35B-A3B Q6_K（量化約 30GB）。多花了 12GB 顯存，換來兩個關鍵升級：
第一，原生 262K context。30B 的 hack 是改 max_position_embeddings，跑長文件會不穩。35B 是原生支援，可以一次處理大量合約條文或報告。
第二，內建視覺能力。35B 是多模態的，看圖不需要額外載 VL-7B，省了 5GB VRAM。原本規劃的「視覺模型 + 主模型雙載」變成「一個 35B 全包」。
這個決定不是「模型升級比較高級」那麼簡單，是看到 MoE 模型、原生 context、視覺這三個特性同時存在時的 engineering trade-off，而 128GB UMA 給了足夠的 VRAM 空間做這個交換。

第四個決定：兩個 AI Agent
Runbook v1.2 的原規劃是 OpenClaw 為主，因為它能在本地接 LM Studio API、做工作流觸發。
但實際安裝的時候，我重新評估了我的使用情境：我需要的是一個能跟我 Telegram 對話的數位助理，所以先裝了 Hermes Agent。
結果 Hermes跑背景任務的時候，有一次卡了 24 小時都沒回應。這讓我意識到，光裝一個 agent 不夠，我需要一個架構完全不同的備援。
這就是後來裝 OpenClaw 的起點，不是為了搶工作，是為了當 Hermes 卡住的時候我還有第二支 agent 可以問事。
裝完之後才發現這兩個的本質差異：
Hermes 是一個對話型 AI，適合日常問答，但跑背景任務時不會主動通知失敗。
OpenClaw 是一個執行型 AI，會自己 debug、自己找 root cause、主動回報失敗。
Hermes 卡住的時候，OpenClaw 自己修了 root cause，找到 Docker 配置的 IPv6 問題。這就是不同 stack 之間備援的真正價值，不只是「不同服務」，是「不同思維方式」。

第五個決定：放棄 MinerU 走 35B 直連
將近七天的地端AI部署與最後的OCR POC踩了八個坑，每一個教我一件事：
第一天：Hermes 卡了 24+ 小時無回應。學到：AI agent 也會 hang，要主動通知，不能只等使用者查。
第二天：MinerU VLM 報 500 Internal Server Error。學到：不是 LM Studio 問題，是 MinerU 工具鏈對 AMD 不友善。
第三天：OCR 跑出簡體字。學到：OCR 模型語言選錯，繁體書要用 ch_tra。
第四天：Pipeline 啟動立刻崩潰、log 空白。學到：subprocess Popen 緩衝，traceback 沒寫進去。
第五天：38 頁的 md 全變亂碼。學到：Windows 預設編碼是 cp950 不是 utf-8。
第六天：OpenClaw 卡死沒回應。學到：localhost 解析成 IPv6，LM Studio 只 listen IPv4。
第七天：重啟還是沒反應。學到：tools.profile coding 帶了 61 個 tool 定義，request body 巨大。

這背後有更深的事——這 61 個 tool 對雲端模型不算什麼，對本地 35B 卻是真實負擔。所以我先跑 minimal profile 把 POC 跑通。後來發現更乾淨的做法是新增 6 個 filesystem MCP tools——讓 35B 帶得動、又能做事。
第七天中午：換成 OpenClaw 跑同一個任務。學到：這次它自己找到根本原因。

修好之後寫了一個 143 行的 Python driver 跑 PyMuPDF 轉圖加 35B vision，POC跑了 786 頁繁體 PDF 逐字稿，編碼乾淨，沒有亂碼，平均每頁 40 秒。
但，POC跑完後，我加了一道品質驗收：逐頁掃描有沒有異常短的內容(timeout 中斷的頁面通常會是 0 字)， OCR log 看起來有20頁失敗——失敗頁數不是因為 vision timeout——是因為 vision 在某些頁決定輸出 0 chars——timeout 是一個可能原因——但不完全確定
還好，程式設計得夠穩健,沒讓整個任務崩潰,自動跳到下一頁繼續跑。所以後來修改了python driver後補齊了這timeout漏頁。
但因此我們在後續的逐字稿n8n工作流中加入自動檢查的流程——讓 AI 自己做這道檢查，而不是我每次都要回頭翻。
每一個都不是「裝好就跑」的問題，是系統設計的問題。

部署 AI 容易，營運它才是難的部分
LLM 跟 vision 能力早就夠強了，九成時間花在前置環境、編碼、權限、timeout、retry、dormant state 上面。
大家常問：「本地 AI 行得通嗎？」
我覺得這問錯了。
更好的問題是：「當你下班回家後，它還能持續運作嗎？」
因為部署 AI 很簡單。難的是後續的維運。

那 AI 能用了，然後呢？

我發現流程化（流程 SOP 化、agent 設定檔化、任務清單化）不是「技術進步」，是「把判斷從人腦搬到工具」。
這個過程中，我的角色從「執行者」變成「指導者」，我不再盯每個 OCR 頁，我變成那個寫「流程要這樣跑」的人。

AI workflow 不是把人換掉，是讓人做更上層的事。

結論：給想搞地端 AI 的人的三個問題

如果你正在評估本地 AI 部署，我建議先想清楚三件事：
(1) 你的資料能不能上雲。這決定你是雲派還是地端派，也決定你能選什麼硬體（Windows vs macOS 生態差異）。
(2) 從寫 Runbook 開始，然後實際部署時接受它會有錯。模型不會永遠最新，今天的 Q4_K_S 明年可能是 Q6_K；今天規劃的 OCR pipeline 明天可能整個重寫。重要的不是 Runbook 寫得多漂亮，是「你願不願意邊做邊修」。
(3) 兩個 AI Agent 比一個好。但要先裝第一個看出問題，再裝第二個看出差異。順序很重要。

我的地端 AI 部署完成了，然後呢？
答案不在技術裡，在用的人身上。技術是工具、是資源——但決定要用 6 個 tool 還是 61 個 tool、要看跑雲端還是跑本地、要讓 35B 帶不帶得動，這些都是人的取捨。

硬核的POC做完了，確認我的本地AI確實能妥善地完成他的工作，之後就是把我的工作流依序寫進n8n，然後透過telegram就可以遠端啟動工作流完成交辦的任務。

回頭看，真正有價值的不是最後跑完 786 頁 OCR。
而是每修掉一個 bug、每補上一個流程、每增加一道品質檢查，都讓這套 AI workflow 比昨天更可靠一點。

AI 不會因為部署完成就開始創造價值。真正的價值，是它每天都能穩定運作，並慢慢成為工作流程的一部分。

後續應該還會寫「為什麼 Runbook 永遠會錯」、「八個 deployment failures 教了我什麼」、「重做的話會做什麼不同」等更聚焦的文章。