24 小時的團隊 AI Agent：GIGABYTE AI TOP / vLLM + 地端開源多模態模型 + Hermes Agent 部署攻略
DeepSeek 把 API 價格砍到 25 折，OpenRouter 上一堆模型也跟著殺價，一堆免費額度都等著你來用。但問題是：便宜的 API 解決得了「這次對話花多少錢」，卻解決不了「這些資料跟經驗，最後留在誰手上」。
想清楚這件事，我決定把整套 AI workflow 搬到地端，自己搞清楚模型、Agent、串接全部留在自己手上到底跑不跑得起來。第一步是找一台扛得住大型語言模型、也撐得住團隊多人同時請求的地端主機。
這篇不只是開箱文，是我把 vLLM、開源量化模型跟 Hermes Agent 兜起來、串進公司 Slack 的第一手部署紀錄，中間卡關卡到想放棄不只一次。這篇文章會老實告訴你：我們團隊測試出來的幾個心得、Agent 怎麼設計才不會炸 context、還有卡最久的報錯怎麼解。
這篇文章會依序談到：
- 一、為什麼選擇地端——人力資本與代幣資本的框架，以及整套系統的架構總覽
- 二、硬體與模型堆疊——vLLM vs Ollama vs LM Studio、模型怎麼選
- 三、上線之後：團隊實測出來的幾個心得——怎麼驗證 Agent 是不是真的在做事
- 四、跟自己的電腦比一比：地端 AI 工作站到底強在哪裡
- 後話——VRAM 精算、Agent 設計陷阱、三大報錯的踩坑速記
一、為什麼選擇地端
回到最開始的問題：便宜的 API 解決不了「資料跟經驗，最後留在誰手上」。
微軟執行長 Satya Nadella 有段話，是我開始這套實驗的契機：
"Every company is going to have to build what I think of as human capital and token capital. Human capital comprises the knowledge, judgment, relationships, ingenuity, and pattern recognition of its people, while token capital is the firm's AI capability it builds and owns... You can offload a task, or even a job, but you can never offload your learning."
翻成白話：每間公司都得建立兩種資本：人力資本是員工的知識、判斷力、人脈、創意跟辨識規律的能力；代幣資本是公司自己打造、擁有的 AI 能力。人力資本不會因為代幣資本變強而貶值，只會更值錢，因為人的能動性才是「驅動代幣資本成長的引擎」。真正的機會不是挑到最強的模型，而是在模型之上蓋出學習迴圈，讓兩種資本一起複利。
如果每次都丟一段 prompt 給雲端 API 換答案，錢花了答案也用完了，踩過的坑、磨合出來的默契不會留在自己系統裡，換一家供應商就歸零，這是用完就沒的代幣資本。地端部署真正值錢的不是省 API 費，是讓每次互動變成可以複利的東西。
想清楚動機之後，整套系統要兜起來其實就是四塊拼圖：
- vLLM 是地端推論引擎，負責把模型跑起來（其他的推論引擎像是 Ollama、LM Studio 也會在本篇做個簡單的比較，還有分享我個人使用的心得）
- Hermes 是 Agent 框架，負責邏輯編排、呼叫工具、對接 Slack
- 地端跑的開源多模態模型 Gemma 是真正的大腦，負責理解文字、圖片、做判斷（這次算是想為 Gemma 雪恥，之前用 8B 的版本，工具調用的能力不是太好）
- Slack gateway 則是團隊介面，讓所有人不用學新工具，在原本的聊天室就能呼叫這整套系統。
接下來就照這個順序，先講硬體跟模型怎麼選，再講怎麼把它們兜起來。
二、硬體與模型堆疊：主角正式登場
地端推論工具怎麼選：vLLM vs Ollama vs LM Studio
很多人接觸地端 AI，第一站是 LM Studio、Ollama，這兩種我都有用過，以下是這次加入 vLLM 實測之後的一些心得：
LM Studio（最適合新手）：桌面 GUI，滑鼠點一點就能載入模型對話，適合單機比較模型效果。但「最適合新手」不代表 LM Studio 不強——模型可以直接從 Hugging Face 下載，還有簡易的 RAG 功能，0 程式就能上手。
Ollama（最適合個人開發者）：指令列簡單（ollama pull、ollama run），這應該算是目前最多人使用的地端推論工具，也有一個非常簡單的 GUI（不過偏測試取向）。尤其現在有 Codex、Claude Code 這類 coding agent 的情況下，直接搭配 Ollama 對「個人用戶」來說也是非常棒的選擇。
最後要特別提到這次讓我非常驚豔的 vLLM。
過去跑 LM Studio 或 Ollama，只要 context 一長、對話人數超過 1 個，KV Cache 就會把 VRAM 吃到見底，電腦像整個卡住一樣。vLLM 的 PagedAttention 機制把每人的 KV Cache 切成一頁一頁動態管理，不各自佔死一塊 VRAM，多人同時發請求也不會卡死整張顯卡。
只要你的地端是想要多人使用，vLLM 就是最佳解法。個人玩模型，LM Studio、Ollama 夠用；牽涉到「全公司 Slack 同時打」，這條分界線就浮現。
為了驗證這套 Local AI 是否真的能支援團隊多人使用，我需要一台能同時兼顧 VRAM、記憶體與長時間穩定運作的平台，因此這次選擇以 GIGABYTE AI TOP 作為部署環境。
技嘉 AI TOP 100 Z890：為地端 AI 工作流而生的實戰工作站
真心要特別感謝技嘉，在 Computex 前後最忙碌的那段時間，二話不說借了我們一台 AI TOP 100 Z890，讓這整套地端 Agent 實驗能在時間壓力下如期跑起來。
AI TOP 100 Z890 是技嘉專為本地 AI 開發設計的桌上型工作站，官方規格包含：
- 搭載 Intel Core Ultra 9 285K 處理器（內建 AI Boost NPU）
- 搭載 GIGABYTE GeForce RTX 5090 WINDFORCE 32GB 顯示卡
- 128GB DDR5 記憶體（D5 Bionic Corsa 技術）
- 2TB SSD（AORUS Gen4 7300）＋ 320GB 快取硬碟（AI TOP 100E）
- 360mm 一體式水冷 ＋ 1,600W 80 Plus 白金認證電源
- 雙 10 Gbit/s 有線網路 ＋ WiFi 7，支援 Thunderbolt 5、雙顯卡設定
- 硬體直接可執行最高 110B 參數等級的大型語言模型；搭配 AI TOP Utility 的記憶體卸載（Memory Offloading）技術，微調工作負載最高可支援到 405B 參數等級
對這次的實驗來說，這台主機的意義不只是「跑得動 Gemma 4 31B」而已。128GB 系統記憶體加上 32GB VRAM 的組合，剛好卡在文章前面精算過的那個甜蜜點上——模型能完整常駐、KV Cache 留有餘裕、團隊多人併發也不會秒爆。能借到一台規格對得上需求的地端工作站，直接讓「把 AI workflow 搬回自己家」這個實驗，從紙上談兵變成真的能跑出結果。
模型怎麼選：不是參數越大、評分越高就越好
選好引擎，下一題選模型。這裡我一開始也犯了直覺錯誤，看排行榜分數、看參數量。但這次用途牽涉 Tool Calling（工具呼叫），情況不同。
Tool Calling 讓模型從「只會聊天」變成「可以做事」：模型吐出結構化指令，程式接住執行，結果餵回模型繼續推理。Hermes 能爬網頁、寫檔案、串 Slack，靠的就是這套機制。
而 Tool Calling 最吃重的是模型能不能穩定吐出格式正確的指令，這需要針對 tool-calling 微調過，參數大不會自動帶來這個能力。規模不頂尖但微調過的開源模型，搭配拉長 context length，做 web scraping、enrich 這類任務反而更順暢。Context 太短，任務還沒走完模型就忘了前面抓到的資料，這算是我的切身之痛。
Huggingface 上面有針對單一模型的各種版本，選擇與 vLLM 相容的即可使用
最後選定 gemma-4-31b（Gemma 4 31B INT4 量化版）：context 夠長、tool-calling 調校過、VRAM 固定佔用約 18.5GB 可控，還是原生多模態模型，圖片、影片、OCR、文件解析內建在同一顆模型，團隊丟進 Slack 的長文字或截圖，同一套架構都接得住。
三、上線之後：團隊實測出來的幾個心得
硬體跟模型都選定之後，真正的挑戰不是「系統能不能跑起來」，而是「它有沒有真的在動」。上線之後團隊陸續丟了不少真實任務進去，這裡分享幾個團隊測試出來的結果。
實測一：@Hermes enrich Computex 所有參展商資料
丟出這個任務後，它秒回一句聽起來很專業的話：
"I am currently working on extracting and enriching the full exhibitor list from the Computex website...（下略一千字）...I'll notify you as soon as the full list is ready!"
「我會盡快回覆你」聽起來很得體，但這種說法十之八九是因為 context length 早就爆了，模型只是禮貌性地敷衍過去，背景根本沒有真的在跑。判斷方法很簡單：叫它把檔案要存的絕對路徑講清楚，含糊其辭就是沒做事；開新終端機用 top、find 查有沒有進程或新檔案；或直接要求先吐部分結果，真貨吐得出具體資料，唬人的只會開始編。log 裡 tool_turns 大於 0，才代表真的呼叫了工具。
那這種問題怎麼解決呢？改成 cronjob（定時任務），讓它在電腦裡面慢慢建檔案，就像蒐集寶物一樣，一點一滴把 Computex 展商資料收齊。
實測二：RSS 搭配 Skill 意外好用
團隊後來也拿它訂閱幾條 RSS 來源、搭配寫好的 Skill 自動整理成摘要，這個組合效果比預期好，算是意外之喜。
還在路上：接下來想優化的地方
這套系統目前算是堪用，但還有幾個我自己覺得不夠漂亮的地方，之後會繼續動：
- Cronjob 只是暫時的權宜之計，不是真正的解法。 定時任務能解決「一次做太多會爆」的問題，但本質上還是在賭「跑久一點總會跑完」，比較理想的做法是把大型任務拆成真正的任務佇列（queue），依優先序、依資料量動態分批，而不是單純靠時間去堆疊進度。
- 多模態能力還沒真正派上用場。 Gemma 4 支援圖片、OCR、文件解析，但目前團隊在 Slack 上丟的還是以文字任務為主，像是展場名片、螢幕截圖辨識這類情境還沒真的上線測試，這是接下來想補的一塊。
- 併發上限還沒真正壓測過。 目前抓到的是約 5 人同時使用、RAM 佔用 35GB 左右的數字，但如果團隊人數再往上長，KV Cache 精算跟 fp8 優化夠不夠撐，還需要更嚴謹的壓力測試才敢下定論。
- 模型分工還停在概念階段。 前面提到「小模型做重複性任務、複雜判斷才升級大模型」這個委派邏輯，目前還是單一模型在扛所有任務，還沒真正做到多模型協作分工。
回頭看這整套從硬體選型、模型調校到 Agent 設計的過程，每個環節都是自己兜出來的，也正因為這樣，它才是真正握在自己手上的東西，我想，這才是把 token 花費變成 token capital 的意思。
四、跟自己的電腦比一比：地端 AI 工作站到底強在哪裡
所謂關公面前弄大刀大概就是在指我了，相比之下才知道自己的電腦硬體是輸了不只一截。我自己的配置是 RTX 5070 Ti 16GB VRAM + 64GB 系統記憶體，乍看之下也是一張夠力的顯卡，放在一般玩遊戲、跑跑輕量模型的情境完全夠用。但真的拿去跑這次用的 Gemma 4 31B INT4 量化模型，會馬上碰壁：光是模型權重固定佔用的 18.5GB，就已經超過 5070 Ti 的 16GB VRAM 上限
不是跑得慢，是模型根本載不進去，連第一步都跨不過去，更別說撐團隊多人併發。
AI TOP 100 Z890 的 32GB VRAM，等於先跨過「模型能不能完整常駐」這道最基本的門檻，才有資格去談後面 KV Cache、併發人數這些精算問題。系統記憶體也是同樣的道理：64GB 對個人單機使用勉強夠用，但要當成 vLLM Swap 機制的緩衝墊、撐好幾個人同時丟長 context，128GB 才有足夠的餘裕，不會讓系統在 Swap 高峰期直接被榨乾，這也是為什麼前面提到，AI TOP Utility 實測約 5 人同時呼叫，RAM 佔用僅約 35GB，還留有相當充裕的空間。
這也是這類地端 AI 工作站真正的價值所在。它不是把一般消費級電腦的規格往上加一點，而是把 VRAM、系統記憶體、散熱、供電這幾個項目同時拉到「能撐得住團隊等級工作負載」的門檻之上。
對個人拿來測試模型、玩玩效果的人來說，一張消費級顯卡已經夠用；但只要目標是讓一整個團隊都能依賴這套系統，地端 AI 工作站補上的，就是從「我自己測試著玩」到「全公司能長期依賴的基礎設施」中間那段差距。
後話：踩坑實錄速記
硬體規格底下真正踩過的坑，濃縮成重點給想動手做的人參考。
VRAM 精算與多人併發：Gemma 4 31B INT4 模型固定佔用約 18.5GB VRAM，vLLM 保留緩衝區後可用 28.8GB，扣掉模型只剩 10.3GB 給 KV Cache。一人開 32K context 約吃 3.85GB，5 人同時吃滿需要 19.25GB，遠超可用空間。靠 PagedAttention + Swap 機制撐住——VRAM 滿載時把排隊中的 KV Cache 搬到系統記憶體暫放，但代價是速度：5090 的 VRAM 頻寬 1.7TB/s，系統 DDR5 只有約 100GB/s，一觸發 Swap，一秒幾十字會掉到 2-3 個字。後來加了 --kv-cache-dtype fp8，KV Cache 體積砍半，緩解這個問題。
Agent 設計：單一 Session 陷阱：把 /enrich、/write 註冊成 Hermes 的 Tools，以為就是委派處理，結果 Hermes 的 ReAct Loop 會把工具結果塞回同一個對話歷史，兩萬字的擴充資料讓 context 瞬間暴增，白費了拆分的美意。解法：在工具腳本內部自己開一條獨立的 API 連線跟本機 vLLM 對話，做完就丟，只把最終成品回傳給主對話，中間產物不會反過來拖累 VRAM。
三大報錯：
- RuntimeError:...no API key found → Hermes 規定 provider 設成 openai-api 就要有 Key，即使地端 vLLM 也一樣，解法是塞假的 api_key: "none"
- ValueError: Auxiliary compression model...below 64,000 → 背景的輔助壓縮模型要求 64K context，補上 auxiliary.compression.context_length: 65536 覆蓋
- CLI 語法一路變、又撞上舊進程卡死 → 新版 Hermes 直接讀 config.yaml 的 slack: 設定，指令回歸 hermes gateway run，加 --replace 一次解決舊進程卡死
