Select Page
Ornith 35B 配 Hermes 工作流,本地跑 Agent 真的香嗎?

Ornith 35B 配 Hermes 工作流,本地跑 Agent 真的香嗎?

Ornith 35B 真正有趣的地方,不是「小模型打敗大模型」這句話本身,而是它把本地 AI 編程 Agent 這條路線重新推到桌面上:我們是不是可以把一部分 coding agent 能力,從雲端 API 搬回自己的機器?

這個問題很現實。雲端工具反應快、整合好,但 token 成本、隱私、企業程式碼外流、模型選擇權,始終卡在開發者心裡。本地模型則剛好反過來:你要自己處理硬體、速度、部署與穩定性,但換來的是成本可控、資料留在本地,以及比較完整的架構控制權。

Ornith 1.0 前一篇已經整理過核心定位,這篇換個角度:如果把 Ornith 35B 接進 Hermes 這類 Agent 工作流,它應該放在哪裡?是主控模型、任務 worker,還是只適合做某些短程工具任務?

先講結論:35B 有想像空間,但不要把 benchmark 當保證書

Ornith 35B 的吸引力在於,它不是 397B 那種多 GPU 伺服器級模型,也不是 9B 那種比較像入門測試的輕量模型。35B 落在一個很微妙的位置:高階個人工作站有機會跑,能力又足以進入 coding agent 測試。

官方數據裡,Ornith 35B 在 Terminal-Bench 2.1 拿到 64.2,SWE-bench Verified 拿到 75.6。397B 更高,Terminal-Bench 2.1 為 77.5,SWE-bench Verified 為 82.4。這些分數很漂亮,但漂亮不等於放進你的專案就穩。

模型Terminal-Bench 2.1SWE-bench Verified適合觀察的方向
Ornith-1.0-9B43.169.4低成本本地測試、短程 worker
Ornith-1.0-35B64.275.6本地 coding agent 實驗主力
Ornith-1.0-397B77.582.4企業級或多 GPU 私有部署
Ornith 1.0 9B、35B、397B 在 Terminal-Bench 2.1 與 SWE-bench Verified 的比較圖

這也是為什麼我不想把它寫成「35B 擊敗雲端大模型」這種單線結論。更準確的說法是:Ornith 35B 在某些 agentic coding benchmark 和視覺/前端生成任務上很值得測,但長程任務和大型 codebase 仍要小心。

Self-Scaffolding RL 到底改變了什麼?

一般 coding agent 常見的架構,是人類工程師先寫好 harness:

什麼時候讀檔、什麼時候跑 command、失敗怎麼 retry、怎麼記憶、怎麼驗證。模型很聰明,但它通常只是被放進這套流程裡填空。

Ornith 1.0 的 Self-Scaffolding RL 想走的是另一條路:

讓模型不只學 solution rollout,也學會產生任務 scaffold。換句話說,它不只是演員,也開始學會改劇本,任務跑得好,解法和引導解法的 scaffold 都一起被獎勵;任務跑得差,兩者都會被調整。

這和 前一篇 Ornith 1.0 介紹裡談到的「先搭工作台,再開始解題」是同一件事。對開發者來說,重點不是模型多會補 code,而是它能不能在遇到限制、錯誤、缺資料時,重新安排自己的工作流程。

Hermes 的位置:還是 harness,但已經比較動態

Hermes 在這裡比較像運行時的動態編排層。它仍然是 harness,但不是傳統那種完全寫死的腳本;它可以在任務過程中調整步驟、改工具、補資料,讓 agent 比較像真的在做一件工作,而不是只照著固定模板回答。

把 Ornith 35B 接進 Hermes 的想像是:Hermes 負責任務框架、工具調用和流程管理,Ornith 35B 負責本地推理、程式生成、局部 debug 與前端/視覺任務。這樣的分工,比「讓 35B 一個模型主控所有事情」更合理。

站上之前有兩篇 Hermes 相關內容可以放在一起看:

Hermes Agent 完整實測Hermes Agent WebUI。如果 Hermes 是工作台,Ornith 35B 就是可以被放進工作台裡的一顆本地引擎。

實測起來

Ornith 的幻覺率仍然偏高,很多 fine-tune 模型 benchmark 強,但長程任務容易歇菜;更穩的方式可能是官方模型搭配優化過的 Jinja template 來跑長程任務。

小模型非常適合做 worker,處理葉節點任務,用完即毀;但如果拿它當整個系統的主控,很可能是用錯地方,可以當作 Ornith 35B 的導入原則。

  • 短程、明確、可驗證的任務,可以交給 35B worker。
  • 長程規劃、多輪重構、跨大型 codebase 的任務,先不要完全放權。
  • 需要主控決策時,最好搭配更強模型或更嚴格的 Hermes/harness。
  • 所有結果要能重跑、能測試、能看 log,不要只看模型自我回報。

這裡的核心不是「小模型沒用」,而是小模型要放對位置,主控、規劃、長上下文記憶是白領工作;批次修小 bug、生成局部元件、跑固定格式分析,反而是本地 35B 很適合切進去的地方。

本地部署的價值:不是零成本,而是可控成本

本地跑 Ornith 35B 很容易被包裝成「零 token 成本」。這句話只說對一半。雲端 token 成本下降了,但你換成了硬體成本、電費、散熱、維護、模型部署和速度瓶頸。

真正的優勢是可控。你知道模型跑在哪裡,知道資料是否離開內網,知道長任務不會因為 token 計費一路燒上去。對需要保護程式碼或內部文件的團隊,這比單純省錢更重要。

如果你本來就在研究本地 AI 開發環境,可以延伸看 Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本環境,以及 Mac Studio 跑大型模型的 VRAM 調整。Ornith 35B 的問題,最後仍然會回到你的硬體、記憶體和任務型態。

我會怎麼把 Ornith 35B 放進 Hermes?

我不會一開始就讓 Ornith 35B 當整個 Hermes 系統的最高決策者。比較合理的導入方式,是先讓它做 worker。

  1. 先挑 5 到 10 個固定任務,例如小型前端元件、局部 bug 修復、測試補齊、簡單重構。
  2. 每個任務都要有明確驗證方式,例如單元測試、Playwright 截圖、lint、build。
  3. Hermes 負責任務切分、重試策略、log 收集和失敗回報。
  4. Ornith 35B 只處理其中一段,不直接改全專案、不直接做不可逆決策。
  5. 連續跑幾輪,看錯誤類型是否固定,再決定要不要擴大權限。

這樣的測法比較慢,但比較接近真實工程,AI Agent 的能力不是靠一個漂亮 demo 決定,而是看它能不能在可重複、可驗證、可回滾的流程裡穩定工作。

Ornith 35B 是值得測的本地引擎,不是萬能主控

Ornith 35B 最好的位置,暫時不是取代 Claude Code、Codex 或雲端大模型,而是進入 Hermes 這類 agent 工作流,成為一顆可控、可替換、可驗證的本地推理引擎。

它的優點很清楚:成本可控、資料留在本地、前端與視覺任務有亮點、自我 debug 的思路值得追。它的風險也很清楚:benchmark 不能直接代表長程任務,幻覺與錯誤累積仍然存在,小模型放錯位置會把整個 agent 工作流拖垮。

所以我會把 Ornith 35B 放進觀察名單,但會用 worker 的方式開始,而不是把整個系統交給它。這條路如果走通,本地 AI 編程的價值就不是「省 token」而已,而是開發者重新拿回 AI 架構控制權。

Open Notebook 是什麼?自架版 NotebookLM 工具解析

Open Notebook 是什麼?自架版 NotebookLM 工具解析

如果你常把 PDF、論文、產業報告或內部文件丟進 AI 工具整理,Google NotebookLM 確實很方便;但只要資料牽涉商業機密、未公開研究、客戶內容或公司內部知識庫,雲端上傳與模型選擇限制就會變成真正的門檻,Open Notebook 的定位,正是把 NotebookLM 類型的文件理解、問答、摘要與 Podcast 生成,搬到更可控、更可自訂的開源工作流裡。

Open Notebook 私有 AI 研究工作流示意封面圖
圖:Open Notebook 私有 AI 研究工作流示意

Open Notebook 解決的是什麼問題?

傳統文件型 AI 助手最容易卡在兩件事:資料放在哪裡,以及模型能不能換。對個人研究來說,把公開文章交給雲端 AI 問答通常沒什麼壓力;但對企業團隊、顧問、研究員或寫作者來說,資料可能包含未公開策略、訪談紀錄、合約、財務數據或客戶文件。這時候,能否自架、能否控制資料歸屬、能否選用自己的模型,就不只是偏好,而是能不能導入的前提。

Open Notebook 的優勢在於,它不是只做一個聊天視窗,而是把「文件匯入、知識庫整理、跨文件問答、來源引用、Podcast 生成、模型配置」串成一套私有 AI 研究工作流。官方 GitHub 專案 lfnovo/open-notebook 目前採 MIT 授權,官方說明也把它定位為一個 privacy-focused alternative to Google NotebookLM,截至 2026-07-07,GitHub API 顯示約 35K stars,最新 release 為 v1.10.0。

核心亮點一:資料主權回到自己手上

Open Notebook 最吸引人的地方,是它把資料控制權從平台端拉回使用者端。你可以把文件、音訊、多媒體檔案、網頁等素材放進自己掌控的環境,再用 AI 做摘要、檢索與問答。對需要處理敏感研究、公司內部文件或客戶資料的人來說,這比「功能多一點」更重要。

這也讓 Open Notebook 很適合搭配文件前處理工具。例如需要先把 PDF、Word、PPT 轉成 AI 更容易讀的文字格式時,可以參考我之前寫過的 MarkItDown 教學,先把原始文件整理成更乾淨的資料,再交給知識庫系統分析。

核心亮點二:模型不再被單一供應商綁住

NotebookLM 的好處是省事,但限制也很明顯:使用者基本上跟著 Google 的模型與產品設計走。Open Notebook 則主打 18+ AI provider,官方 README 提到支援 OpenAI、Anthropic、Ollama、LM Studio 等供應商。這代表同一套知識庫可以依任務切換模型:便宜模型做初步整理,強模型做深入推理,本地模型處理敏感資料。

如果你的工作流已經開始用 Ollama 或本地模型,Open Notebook 的價值會更明顯。它可以成為文件層的操作介面,而模型層則交給你自己的 AI server,想走本地端路線的人,也可以延伸看 GraphRAG 使用本地端的 OllamaOllama 遠端連線教學,把模型部署與文件分析分開思考。

核心亮點三:Podcast 生成更像內容製作工具

Podcast 生成是 NotebookLM 很受歡迎的功能,但固定雙人對談也限制了內容形式。Open Notebook 的方向更偏向內容製作工具:可以做 1 到 4 位 speaker,並調整角色設定與對話形式。這讓它不只適合做「兩人解說」,也能做單人旁白、三人圓桌、多人辯論或不同角色的知識導覽。

對自媒體、研究型內容創作者或企業內訓來說,這點很實用。你可以先把一批文件整理成知識庫,再把其中的核心結論轉成 Podcast 腳本,甚至為不同聽眾設計不同敘事角色。它不是單純把文字念出來,而是把文件理解、腳本結構與音訊內容生產接在一起。

核心亮點四:Ask 模式更適合跨文件研究

Open Notebook 的 Ask 模式適合處理「不是問單一文件,而是要整合一批資料」的任務。例如你有 20 份產業報告,真正想問的不是某一頁寫了什麼,而是不同報告之間是否有共同趨勢、矛盾、缺口與可引用依據。這時候,單純的檢索式問答會不夠,需要能跨文件整理、比對與引用來源的研究流程。

這也是 RAG 類工具接下來會越來越重要的原因:文件不是只被「搜尋」,而是要被組織成可以反覆推理的知識庫。Open Notebook 提供的是比較完整的操作層;而像 GraphRAG、向量資料庫、本地模型與文件轉換工具,則是可以接在底下的技術層。把這些組起來,才會形成真正可重複的 AI 工作流

Open Notebook 和 NotebookLM 怎麼選?

比較面向Open NotebookNotebookLM
資料控制可自架,資料在自己掌控的環境以 Google 雲端服務為主
模型選擇可接多家 provider,也可接 Ollama / LM Studio主要使用 Google 模型
Podcast 形式可做 1-4 位 speaker 與自訂角色以固定形式為主
部署方式Docker、雲端或本地部署直接使用雲端產品
適合對象重視隱私、模型自由、工作流整合的人重視上手速度、不想部署的人

簡單說,如果你要的是「馬上可以用」,NotebookLM 仍然很省事;如果你要的是「資料可控、模型可換、流程可自訂」,Open Notebook 會更有想像空間。它不是每個人都需要的工具,但對研究、顧問、內容團隊與企業知識庫來說,很值得放進評估清單。

導入前要先確認的限制

Open Notebook 的自由度比較高,但也代表它不是完全零門檻。最基本的前提是你要能接受 Docker 或自架環境;如果公司電腦不能裝 Docker,或 IT 政策不允許本機服務,導入就會比較麻煩

Docker 新手可以先看 如何使用 Docker 跟用 command line 一樣,先把容器概念補起來。

算力也要看你的模型選擇。如果只是用雲端 provider,主要成本會落在 API;如果想完全本地跑模型,就要準備足夠的 GPU、記憶體與模型部署能力。換句話說,Open Notebook 降低的是資料與模型綁定,不是把所有基礎設施成本變成零。

誰最適合用 Open Notebook?

  • 研究員:需要整理大量論文、報告、訪談與來源引用。
  • 內容創作者:需要把資料轉成腳本、長文、Podcast 或系列內容。
  • 學生與知識工作者:需要把課堂筆記、PDF、網頁資料統一管理。
  • 企業團隊:需要建立內部知識庫,又不希望敏感文件全部交給外部雲端。

Open Notebook 適合把 AI 研究流程變成私有工作台

Open Notebook 的價值,不只是「開源版 NotebookLM」這麼簡單。它真正有意思的地方,是把資料主權、模型自由、Podcast 生成、跨文件研究與自架部署放在同一個工作台裡。對只想偶爾整理公開資料的人來說,它可能稍微重了一點;但對需要長期累積知識庫、處理敏感文件、或把 AI 研究流程變成團隊基礎設施的人來說,它是一個值得測試的選項。

Open Notebook Github

FAQ

Open Notebook 是 NotebookLM 的替代品嗎?

它可以被視為 NotebookLM 的開源替代方案,但重點不只是功能相似,而是提供自架、模型選擇、資料控制與更多自訂能力。

Open Notebook 一定要很強的電腦才能用嗎?

不一定。如果使用雲端模型,主要需要 Docker 與 API 設定;如果要完全本地跑大型模型,才需要更強的 GPU、記憶體與部署能力。

Open Notebook 適合企業內部知識庫嗎?

適合放進評估清單,尤其是重視資料控制、模型彈性與自架部署的團隊。不過正式導入前,仍要評估權限管理、備份、資安政策與維運成本。

AISA 是什麼?一個 API Key 讓 AI Agent 連上 X、YouTube、股票與支付

AISA 是什麼?一個 API Key 讓 AI Agent 連上 X、YouTube、股票與支付

AISA 最有意思的地方,不是「又多一個 API 聚合平台」,而是它把 AI Agent 真正需要的外部能力,整理成一個可以被 agent 呼叫的資源層。

以前要讓 agent 查 X/Twitter、找 YouTube 競品、讀股票資料、換不同模型、甚至呼叫付費 API,常常要準備一堆帳號、一堆 API Key、一堆 OAuth 設定和一堆帳單。

AISA 想做的事很直接:用一個 API Key,把模型、資料源、Skills 和機器支付放到同一個入口。

這個方向對 AI Agent 很重要。模型本身再聰明,如果不能拿到即時資料、不能安全地調用工具、不能控制支出,它還是停留在「回答問題」而不是「完成任務」。AISA 的定位,就是補上這一層。

AISA 是什麼?不是只有模型 Gateway

從官方頁的說法來看,AISA 是面向 Agent Economy 的能力層與交易網路。它包含模型 gateway,但不只是模型 gateway。官網 FAQ 明確提到,AISA 讓 agent 用一個 API Key 和統一帳單關係,在同一處存取模型、API、資料源、Skills,以及機器對機器支付能力。

這裡的差異很關鍵。像 OpenRouter 這類多模型統一平台,主要解決「不同模型如何用同一套 API 呼叫」;AISA 更進一步,把資料 API、封裝技能、金融資料、社群資料、搜尋能力和機器支付也放進同一個 agent 工作流。

換句話說,AISA 想解的不是「我要用哪個模型」,而是「我的 agent 要怎麼真的去外面做事」。

一個 API Key 可以接哪些能力?

官方 `llms.txt` 把 AISA 定義成 autonomous AI agents 的 unified API gateway,列出的範圍很廣:GPT、Claude、Gemini、Grok、DeepSeek、Qwen、Kimi、MiniMax、GLM 等模型,還有 100+ data APIs、Agent Skills 和 stablecoin payments。

官網頁面也把幾個能力直接列出來:Tavily 網頁搜尋、YouTube 搜尋、X/Twitter 公開資料、金融市場資料、預測市場、Agent Mail、Circle 小額支付、Machine Payments Protocol。對 agent 來說,這些不是靜態資料庫,而是可以被工作流呼叫的「手腳」。

能力類型AISA 提供的方向適合的 Agent 任務
模型 GatewayGPT、Claude、Gemini、DeepSeek、Qwen 等模型推理、寫作、程式、長上下文分析
X / TwitterTwitter API、Twitter Autopilot、X Intelligence Automation輿情監控、發文、互動、自動整理趨勢
YouTubeYouTube Search、YouTube SERP選題研究、競品內容分析、頻道資料整理
金融與市場股票、Crypto、Prediction Market、MarketPulse研報、行情追蹤、事件監控
機器支付x402、Circle Nanopayments、MPP按次付費 API、agent 自主購買資料或服務

這也回應了第一則留言裡的需求:有人正在找這類資料資源,想讓 Agent 幫忙發推文。AISA 的 X/Twitter Skills 正好對應這種場景。重點不是讓模型「想像社群趨勢」,而是讓 agent 真的去讀公開資料、整理噪音、再決定要怎麼輸出。

X、YouTube、股票資料:Agent 要有真實世界的入口

AI Agent 很容易卡在一個地方:它可以推理,但沒有即時資料。

問它今天 X 上 AI Agent 的討論方向,它如果沒有工具,就只能靠舊知識猜,問它 YouTube 上某個主題競爭激不激烈,它如果沒有搜尋能力,就只能給你方法論,問它最新財報,它可能知道公司很大,但不知道最新數字。

AISA 的價值,是把這些「資料入口」變成 agent 可以安裝和調用的 Skills,X/Twitter 可以做輿情和發文,YouTube 可以做選題研究,金融 API 可以做股票研報,搜尋 API 可以補足即時資訊。這時候 agent 才比較像一個能工作的小助手,而不是只會聊天的模型。

這條路線也可以和你站上之前整理的 Claude Code Workflow 放在一起看:Claude Code、Codex 或其他 CLI agent 是工作介面,AISA 則比較像它們背後的外部能力層。

Skills 的意義:把「會回答」變成「會操作」

AISA 文件中列出的 Skills 很多,從 Twitter Autopilot、YouTube Search、SEO Keyword Research,到 US Stock Analyst、Stock Portfolio、Perplexity Deep Research、Multi-source Search 都有。這裡真正值得看的不是數量,而是 Skills 把任務包成 agent 能理解的操作流程。

同一個問題,有沒有 Skill,結果會差很多。沒有 Skill 時,模型可能只能說「你可以去查財報」。有 Skill 時,agent 可以知道要調哪個 API、要拿哪些欄位、資料錯了要去哪裡補、最後怎麼整理成報告。

這跟前面談過的 Ornith 1.0 自己拆任務、搭 scaffold 的方向其實有點像:模型不是只輸出答案,而是要有一套能完成任務的流程。AISA 則把外部 API 和 Skills 變成這套流程可以調用的零件。

x402 與機器自主付款:很酷,但一定要有護欄

AISA 官網也把機器對機器支付列為核心能力之一,包含 Circle Nanopayments、Machine Payments Protocol,以及 x402 / HTTP 402 風格的支付流程。

HTTP 402 Payment Required 這個狀態碼很早就存在,但以前沒有真正成為日常網路支付流程。x402 類協議讓 agent 呼叫受保護端點時,可以收到付款要求,完成結算,帶著付款證明重試請求。這對付費 API、資料服務、agent-to-agent 交易很有想像空間。

用白話講,402 不是一般錯誤,而是一種「這個資源要先付費」的握手訊號。Agent 第一次呼叫付費 API 時,服務端可以回傳 HTTP 402,並附上價格、收款地址、可用付款網路、付款證明格式和過期時間。Agent 不需要猜怎麼付錢,而是照著這份付款要求完成結算,再把付款證明帶回去重送同一個請求。

AISA 與 x402 讓 AI Agent 自主付費的架構圖

這裡要分清楚一件事:不是把信用卡號交給模型,也不是讓模型任意花錢。比較安全的設計是讓 Agent 只取得「受限制的付款能力」:例如只允許特定 API、單次最高 0.05 美元、每日最高 1 美元、只讀資料可以自動付款、發文或交易則要人工確認。

AISA 在這裡扮演能力層與記帳層,幫 agent 把 API、付款握手、用量紀錄和預算控制串起來。

AI 自己付錢的 6 個步驟

AI Agent 透過 HTTP 402 與 x402 自己付錢的六步驟流程圖
  1. Agent 呼叫付費 API,例如查即時金融資料、X 資料或高價值搜尋結果。
  2. 服務端回 HTTP 402 Payment Required,告訴 agent 這次請求需要付款,並提供價格、收款地址和付款格式。
  3. AISA 或 agent runtime 檢查政策:這個服務是否在白名單內、金額是否低於單次上限、今天預算是否還夠。
  4. 若通過檢查,錢包用 USDC 或支援的付款方式簽名付款,產生 payment proof。
  5. Agent 帶著付款證明重送請求,通常會把 proof 放在 header 或協議要求的位置。
  6. 服務端驗證付款有效後回傳資料,AISA 同步記錄誰呼叫、花多少、成功或失敗。

不過這裡不能只看酷炫的一面。Agent 能自己付費,就代表它也可能亂花錢、重複呼叫、被錯誤 prompt 帶偏,甚至被惡意服務誘導。AISA FAQ 提到可以發放 API Key、監控用量、設定預算或限額,這是必要條件,不是加分功能。

  • 先用低額度測試,不要一開始就給大額預算。
  • 把可呼叫服務設白名單,尤其是會產生費用的 API。
  • 設定單次、每日、每月限額。
  • 高風險動作先要求人工確認,例如發文、寄信、交易、付款。
  • 保留完整日誌,能看出哪個 agent、哪個 skill、哪次呼叫花了多少錢。

這也是 AI Agent 進入實際工作流後一定會遇到的問題:能力越大,權限邊界就越重要。你可以把它和 自學型 AI Agent 一起看,兩者都指向同一件事:agent 不只是變聰明,還要能被管理。

怎麼開始接入?先用 llms.txt 讓 Agent 讀懂平台

AISA 官網給了一個很適合 agent 使用的入口:讓 agent 先讀 `https://aisa.one/docs/llms.txt`,再依照目前環境安全地連接、配置並使用 AISA 的 API、Skills 和 LLM。

閱讀 https://aisa.one/docs/llms.txt,幫我在這個 agent 環境中安全地連接、配置並使用 AISA 的 API、Skills 和 LLM。

實務上可以分三步走:先到 AISA Console 的 get-started 頁面註冊並取得 `AISA_API_KEY`,再把 key 放進 CLI agent 或 IDE agent 的環境變數,最後挑一個低風險 Skill 測試,例如搜尋、YouTube 研究或只讀型 X 資料整理。

如果你原本就在用 Claude Code、Codex 或本地端模型,AISA 比較像補上「外部能力」的那塊拼圖。你也可以對照 Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本環境 來思考:本地模型負責推理,AISA 負責外部資料和服務。

誰適合先試 AISA?

我會把 AISA 放在三種使用者的觀察名單裡。

第一種是內容創作者。你需要查 X 熱點、找 YouTube 競品、做 SEO keyword research,這些都很適合交給有資料 Skills 的 agent。

第二種是開發者和自動化玩家。你已經在用 Claude Code、Codex、OpenClaw 或其他 CLI agent,希望讓它們接更多真實 API,而不是每個服務都重新申請 key。

第三種是想做 agent 商業流程的人,例如市場開發、資料整理、金融監控、郵件自動化。這類任務需要的不只是模型,而是資料、工具、信箱、付款和成本控制一起工作。

至於只想聊天或單純換模型的人,AISA 可能不是最輕的選擇。這種情況,單純的模型 API 聚合平台或本地模型會更直接。可以參考你站上的 ApiFree:一個 API 打通所有 AI 模型 這類文章來比較不同路線。

結論:AISA 代表 Agent 從「模型」走向「資源層」

AISA 真正值得注意的,不是它支援多少模型,而是它把 agent 做事需要的資料、API、Skills、帳單和支付,往同一個入口收斂。

這會讓 AI Agent 的下一步變得更清楚:模型只是大腦,Skills 和 API 是手腳,預算和權限是安全邊界,支付能力則讓 agent 有機會直接參與服務交易。

短期內,我會先用只讀型任務測 AISA,例如 X 輿情整理、YouTube 競品研究、股票資料摘要。等日誌、成本和準確性都穩定,再逐步開放發文、寄信、付費 API 這類高風險能力。Agent 要進化成能工作的系統,靠的不是一次把權限全打開,而是一步一步把能力和護欄一起搭好。

FAQ

AISA 是什麼?

AISA 是面向 AI Agent 的能力層與交易網路,讓 agent 透過一個 API Key 連接模型、資料 API、封裝 Skills,以及機器對機器支付能力。

AISA 可以用 X 或 Twitter 嗎?

可以。AISA 官方文件列出 Twitter API、Twitter Autopilot、Twitter Command Center、X Intelligence Automation 等 Skills,適合做公開資料搜尋、輿情整理、發文和互動自動化。

AISA 跟 OpenRouter 有什麼不同?

OpenRouter 主要解決多模型 API 統一入口;AISA 包含模型 gateway,但更大的重點是把 API、資料源、Skills、Agent Mail、金融資料、搜尋與機器支付一起包成 agent 可用的資源層。

AISA 一定要用加密貨幣嗎?

不一定。官網 FAQ 提到可以從一般 AISA 帳號、API Key 和法幣充值額度開始,加密原生結算主要用在機器支付或 x402 類工作流,不是首次整合的必要條件。

Agent 自己付款安全嗎?

不能無限制開放。AISA 官網提到可透過 API Key、用量監控、預算或限額來控制 agent 支出,實務上應該先用低額度、白名單服務、日限額和人工審核逐步放權。

HTTP 402 如何讓 AI 自己付錢?

AI Agent 先呼叫付費 API,服務端回 HTTP 402 Payment Required,並附上付款要求,Agent 檢查預算和白名單後,用錢包簽名付款,取得付款證明,再帶著證明重送請求。服務端驗證付款後,才回傳資料。

Claude Memory 與 Dreaming 是什麼? 自學型 AI Agent 的下一步

Claude Memory 與 Dreaming 是什麼? 自學型 AI Agent 的下一步

AI Agent 記憶系統與 Dreaming 流程的抽象封面圖
Memory 讓 agent 記得自己的工作經驗,Dreaming 則負責在背景整理、驗證與回填這些經驗。

AI Agent 真正難的地方,不是只會不會呼叫工具,而是能不能在長時間、多任務、多 agent 的環境裡越做越好。MCP 解決的是工具與資料接入,Skills 解決的是可重複使用的能力封裝,但如果 agent 每次醒來都像第一次接觸專案,它就很難成為真正可靠的工作夥伴。

這也是 memory 和 dreaming 這兩個概念重要的原因。Memory 是 agent 的可讀寫經驗庫;Dreaming 則像一個離線整理程序,會在任務之外回看多個 session 的 transcript,找出共同錯誤、成功策略、重複資訊與過期記憶,再把它們整理成更可靠的記憶狀態。

為什麼 Agent 需要 Memory?

現在的 agent 已經可以跑很久,有些任務會持續數小時甚至接近數天。問題是,時間拉長後,上下文管理就會變成瓶頸。Agent 需要知道任務成功條件、常見錯誤、哪些策略行不通、專案檔案怎麼組織、以前有哪些調查結果,也要能從其他 agent 的經驗中學到東西。

這一點和我之前整理 Claude Code Workflow 時看到的問題很像:當你同時開多個 agent 或多個工作階段,真正會拖慢效率的,往往不是模型不夠聰明,而是每個 agent 都在重複摸索同一批上下文。

Memory 的設計:把記憶當成檔案系統

這套 memory 設計最有意思的地方,是它沒有把記憶包成一個過度抽象的黑盒工具,而是把 memory model 成一組檔案。Agent 可以像管理專案檔一樣,用熟悉的 bash、grep、檔案讀寫去整理記憶。這和 Claude Code 擅長操作檔案系統的能力剛好接上。

從實務角度看,這比單純塞一段「長期記憶摘要」更適合大型專案。記憶可以拆成不同檔案、不同層級、不同權限:有些是組織層級的 runbook 和最佳實務,應該只讀;有些是某個團隊或某個任務的 working memory,需要 agent 持續更新。

多 Agent 系統裡,記憶不能只有「我記得」

單一 agent 記得自己的工作經驗已經有幫助,但真正的難題在多 agent。當企業裡同時有數百甚至上千個 agent 在跑,它們會接觸同一套程式碼、同一批告警、同一組 runbook。如果每個 agent 都各自學一次,成本會很高,錯誤也會一直重複。

這裡需要兩種能力。第一是權限範圍:有些 memory store 只允許讀取,有些允許讀寫。第二是並行控制:多個 agent 同時更新同一份記憶時,不能互相覆蓋。用 content hash 做 optimistic concurrency,可以讓 agent 在寫入前確認自己沒有覆蓋別人的更新。

如果把這件事放進更大的 AI 工作流來看,它其實和 用 AI 組一家公司 的概念很接近:當 AI 不再只是單一助手,而是多個角色一起工作,組織記憶就會變成基礎設施。

Dreaming 是什麼?

Dreaming 可以理解成「離線記憶整理」。它不是 agent 正在執行任務時的熱路徑,而是一個非同步 batch process。它會回看最近的 agent sessions、transcripts 和工作結果,找出共同模式、重複錯誤、有效策略,再產生一組更新後的 memory diff。

這個設計很重要,因為單一 agent 在任務中只看得到自己的局部視角。Dreaming 則可以站在更高一層,同時看多個 agent 的工作紀錄。它能發現某個錯誤是不是很多 agent 都遇到過,某個 retry pattern 是不是固定在 60 秒後發生,或某份記憶是不是已經過期。

Memory 與 Dreaming 的差別

項目MemoryDreaming
運作時間任務進行中即時讀寫任務外的非同步整理
主要目標讓 agent 記得當前與過去經驗驗證、去重、回填與組織記憶
視角單一 agent 或單一 session 為主跨多個 sessions 與多個 agents
適合解決避免重複調查、保留工作脈絡找共同錯誤、萃取模式、清理 stale memory
對效能影響在任務路徑上,要注意 token 與延遲離線執行,不增加 hot path latency

早期案例透露了什麼?

早期案例有兩個數字值得注意。Rakuten 在內部 knowledge agents 裡導入 memory 後,first-pass mistakes 降低 90%。Harvey 在法律場景 benchmark 中導入 dreaming 後,其中一個 scenario 的 task completion rate 提升 6 倍。

Memory 與 Dreaming 在 Rakuten 與 Harvey 早期案例中的改善幅度圖表
圖表只是把兩個早期案例視覺化。它們不是通用保證,但足以說明 memory 與 dreaming 對長任務 agent 的潛力。

這些數字不能直接解讀成所有 agent 系統都會有同樣改善,但方向很明確:memory 先降低重複犯錯,dreaming 再把多個 agent 的經驗整理成更乾淨、更可用的知識庫。對企業來說,這會同時影響正確率、token 效率、延遲和維護成本。

SRE Agent 的例子最容易理解

假設一個 SRE agent 收到 P1 alert,它開始查 CPU utilization、流量模式、最近部署的 PR,最後把調查結果寫進 SRE memory store。幾分鐘後同樣 alert 又出現,另一個 SRE agent 啟動時,第一件事不是從零開始查,而是先讀到前一個 agent 留下的調查結果,直接避開重複工作。

這就是 memory 的即時價值:省 token、省時間、也讓後續 agent 站在前一個 agent 的肩膀上。再往下一層,dreaming 會回看過去 7 天相關 sessions,找出多個 agent 都沒有單獨注意到的模式。例如很多 alert 都剛好在上游 CPU spike 後 60 秒發生,那可能代表 retry logic 或排程邏輯有問題。

這種模式非常適合 自我進化 AI Agent 架構。但重點不是讓 agent 無限制亂寫記憶,而是要有版本歷史、attribution metadata、審核流程和可回滾能力。

實作時最該注意的三件事

第一,記憶要可審計。誰寫了什麼、什麼時候寫、基於哪個 session 寫,這些資訊必須留下來。否則 memory 一旦被污染,後續 agent 會把錯誤經驗當成事實。

第二,記憶要分層。組織層級 best practices、團隊 runbook、專案知識、個別任務 working memory,不應該全部混在同一個檔案。這和寫 AI 開發紀律 很像:越是長期會被重複使用的規則,越要整理成穩定結構。

第三,dreaming 不應該完全無人監督。它產生 memory diff 後,可以直接套用,也可以先走檢查、PII scanning、人工 review 或外部 pipeline。對企業 production agent 來說,這種控制權比單純「模型會自動學習」更重要。

我的判斷:Memory 會成為 Agent 系統的資料庫層

如果把 MCP 看成工具層,把 Skills 看成能力層,那 memory 很可能會變成 agent 系統的資料庫層。它不只是「記住使用者喜好」這麼簡單,而是把 agent 的工作歷史、錯誤模式、成功策略與環境知識變成可管理、可審計、可演進的資產。

Dreaming 則讓這個資料庫不只是被動儲存,而是能定期整理索引、刪除過期內容、回填驗證結果、把多個 agent 的經驗濃縮成明天可以直接使用的知識。未來真正強的 agent 系統,可能不是單一模型最聰明,而是整個系統能不能把每天做過的事變成明天的能力。


FAQ

AI Agent memory 是什麼?

AI Agent memory 是讓 agent 保留工作經驗、任務策略、環境知識與常見錯誤的記憶系統。它可以幫 agent 在長任務或多 session 工作中避免每次都從零開始。

Dreaming 和一般 memory 有什麼不同?

Memory 偏向任務進行中的即時讀寫;Dreaming 則是離線整理流程,會回看多個 agent sessions,找出共同模式、去重、驗證記憶並回填更好的內容。

Memory 會不會讓 agent 學到錯誤資訊?

會有這個風險,所以 production memory 需要版本歷史、attribution metadata、權限控管、PII scanning、人工 review 或自動檢查流程。記憶不是越多越好,而是要可靠、可追溯、可清理。

什麼情境最適合導入 agent memory?

最適合長任務、多 agent、重複問題多、環境複雜的場景,例如 SRE triage、程式碼維護、企業知識問答、法務研究、客服流程與內部自動化。

用 Impeccable 改善 AI 網站設計:告別模板感與 AI 味

當我們開始用 AI 寫網站、做 Landing Page、產生前端介面時,常常會遇到一個問題

畫面看起來很快就完成了,但總覺得「哪裡怪怪的」。

按鈕很像、卡片很多、漸層很浮誇、字級沒有層次、留白不夠精準,甚至每個 AI 產生的網站都像是同一套模板改出來的。這種「可以用,但不高級」的設計感,就是許多 AI 前端作品容易落入的平庸陷阱。

Impeccable 官方網站 想解決的,正是這個問題。

什麼是 Impeccable?

Impeccable 是一套專為 AI Coding Agent 設計的前端設計輔助工具,它不是單純幫你產生漂亮畫面的 AI 設計工具,而是提供一套「設計語彙」與「設計指令」,讓你可以更精準地指揮 AI 改善網站畫面。

簡單說,Impeccable 讓 AI 不只是會寫程式,也更懂設計。

它可以協助 AI 理解網站中的層級、對比、留白、色彩、字體、動畫、產品脈絡與品牌調性,讓 AI 產生的前端畫面不再只是堆滿卡片、套上漸層、加一點陰影,而是更接近真正設計師會思考的介面。

你可以把 Impeccable 想像成:

一套給 AI 前端工程師使用的設計總監指令集。

為什麼 AI 做出來的網站常常很平庸?

現在很多人會用 AI 幫忙做網站,例如請 Claude Code、Cursor、Codex CLI 或 Gemini CLI 產生頁面。AI 很擅長快速完成版型,但如果沒有足夠清楚的設計方向,它很容易產生幾種常見問題:

  1. 每個區塊都用卡片包起來,看起來很模板化
  2. 喜歡使用過度常見的紫色漸層、玻璃擬態、發光陰影
  3. 字體大小與層級不夠精準,主標、副標、內文沒有明確節奏
  4. 留白太平均,缺乏視覺重點
  5. 按鈕、表單、導覽列看起來功能正確,但沒有品牌感
  6. Landing Page 和後台 Dashboard 使用同一種設計邏輯
  7. 作品看起來像 AI 產物,而不是成熟產品

Impeccable 的價值就在於,它不是只叫 AI「設計得漂亮一點」,而是提供更具體的設計方向,例如讓畫面更有層次、更安靜、更大膽、更精煉、更符合產品情境。

Impeccable 的核心特色

1. 提供 AI 可理解的設計語言

Impeccable 的官方介紹中提到,它補上了 AI Agent 缺少的設計語彙,這代表你可以用更接近設計師的方式指揮 AI,例如改善排版、調整顏色、強化視覺層次、降低過度設計、整理產品脈絡。

這對不熟設計術語的人很有幫助,因為你不需要長篇大論解釋「我要更高級、更有質感、更像品牌網站」,而是可以透過 Impeccable 的指令,把設計意圖轉成 AI 比較能執行的動作。

2. 支援多種 AI Coding 工具

Impeccable 可以搭配多種主流 AI Coding 工具使用,例如 Cursor、Claude Code、GitHub Copilot、Gemini CLI、Codex CLI 等。

這代表它不是只服務單一平台,而是比較像一套可以帶進不同開發流程的設計輔助層。對於已經習慣用 AI 寫前端的開發者來說,Impeccable 可以直接加入現有工作流程,不需要重新學一套完整設計軟體。

3. 透過指令改善網站設計

Impeccable 提供多個設計指令,讓你可以針對不同設計任務下達命令。例如:

/impeccable init
用來初始化專案,建立產品脈絡與設計方向。

/impeccable shape
在寫程式前先規劃 UX / UI,避免一開始就產生雜亂版型。

/impeccable critique
針對畫面的層級、清楚度、情緒感與設計品質做評論。

/impeccable audit
檢查技術品質,例如可及性、效能與響應式設計。

/impeccable polish
進行最後修飾,讓畫面更接近可上線品質。

/impeccable bolder
讓太保守、太無聊的畫面更有張力。

/impeccable quieter
讓太吵、太過度設計的畫面更穩重。

/impeccable distill
把畫面精煉到最核心的內容與視覺重點。

這些指令的好處是,你可以更像在跟設計師溝通,而不是一直對 AI 說:「再漂亮一點」、「再高級一點」、「不要這麼普通」。

4. 幫你減少 AI 生成網站的套路感

很多 AI 產生的網站會有明顯套路,例如紫色漸層、大量圓角卡片、發光邊框、過度一致的版面節奏。Impeccable 內建反套路的設計檢查,可以幫助你找出這些容易讓網站看起來廉價、模板化或過度 AI 感的元素。

這對品牌網站、形象頁、SaaS Landing Page、產品頁、作品集網站尤其重要。因為這些頁面的重點不只是功能完成,而是要讓使用者在第一眼感覺到專業、信任與差異化。

5. 保留你的設計系統,不是硬套新風格

Impeccable 的另一個優點是,它不是粗暴地把你的網站改成另一種風格,而是會盡量尊重既有的設計系統,例如顏色、字體、元件、間距、按鈕樣式與品牌規則。

這對已經有產品雛形或既有網站的人很重要。你不一定想要整個重做,而是希望 AI 幫你把現有介面整理得更成熟、更一致、更像一個真正的產品。

Impeccable 適合誰使用?

Impeccable 特別適合以下幾種人:

1. 用 AI 寫前端的開發者

如果你常用 Cursor、Claude Code、Codex CLI、GitHub Copilot 來產生 React、Next.js、Astro、Tailwind CSS 或其他前端頁面,Impeccable 可以幫你補上 AI 在設計判斷上的不足。

2. 想快速做出高質感 Landing Page 的創業者

很多創業者會用 AI 快速做 MVP,但 Landing Page 如果太普通,會影響使用者信任感,Impeccable 可以幫助你把「能用的頁面」推進到「比較有品牌感的頁面」。

3. 會寫程式但不擅長設計的人

你可能知道功能怎麼做,但不知道為什麼畫面不夠好看。Impeccable 可以用指令化的方式協助你檢查排版、層級、色彩與互動細節。

4. 想降低 AI 生成感的網站製作者

如果你的網站看起來太像 AI 產物,Impeccable 可以幫你找出常見的 AI 設計套路,讓畫面更有辨識度。

如何安裝 Impeccable?

你可以到 GitHub 下載與查看 Impeccable 專案:

Impeccable GitHub 下載頁

官方建議可以在專案根目錄執行:

npx impeccable skills install

接著在你的 AI Coding 工具中執行:

/impeccable init

如果之後要更新,可以執行:

npx impeccable skills update

官方網站也提供更多說明與範例:

Impeccable 官方網站

使用 Impeccable 的工作流程建議

如果你正在做一個網站或前端產品,可以用以下流程開始:

第一步,先用 AI 產生基本頁面結構。
例如首頁、產品介紹、價格表、登入頁、後台儀表板。

第二步,執行 /impeccable init
讓 Impeccable 了解你的產品定位、使用者、品牌語氣與設計方向。

第三步,用 /impeccable shape 先整理畫面架構。
這一步可以避免一開始就把版面做得太滿、太亂。

第四步,用 /impeccable critique 檢查設計問題。
讓 AI 幫你指出畫面層級、訊息清楚度與互動細節的問題。

第五步,用 /impeccable polish 做上線前修飾。
這一步可以讓網站更一致、更乾淨,也更接近可交付品質。

第六步,必要時使用 /impeccable audit
檢查響應式、可及性、效能與技術層面的品質。

對 WordPress 網站製作者有什麼幫助?

雖然 Impeccable 本身比較偏向 AI Coding Agent 與前端開發流程,但對 WordPress 網站製作者也很有參考價值。

如果你使用 WordPress 搭配自訂佈景主題、區塊編輯器、Elementor、Bricks、Breakdance 或自製前端元件,你可以先在本機或開發環境中,用 AI 建立前端區塊,再透過 Impeccable 改善設計品質。

例如:

  • 首頁 Hero 區塊不夠有記憶點
  • 服務介紹區塊太像模板
  • 價格表太普通
  • Call to Action 不夠明確
  • 部落格列表頁缺乏層次
  • 後台管理介面太陽春
  • 品牌網站缺乏高級感

這些都可以透過 Impeccable 的設計指令進行調整,再整合回 WordPress 佈景主題或頁面模板中。

結論:Impeccable 讓 AI 網站設計從「能用」走向「有質感」

AI 讓網站製作變快,但速度不代表品質。真正影響使用者感受的,往往是那些細節:字體層級、留白、對比、色彩、互動節奏、品牌一致性,以及畫面是否有明確的設計意圖。

Impeccable 的重點不是取代設計師,而是讓 AI 更容易理解設計師的語言,也讓開發者可以用更精準的方式指揮 AI 做出不平庸的網站。

如果你正在用 AI 製作網站,卻覺得畫面總是差一點質感,那麼 Impeccable 很值得加入你的前端工作流程。

官方網站:
https://impeccable.style/

GitHub 下載:
https://github.com/pbakaus/impeccable

Nvidia DGX Spark 安裝 Holo-3.1

原本我在 Nvidia 都搭配 vLLM 啟動,這條路理論上可以發揮 NVFP4 權重的優勢,但在 DGX Spark 的 GB10 平台上,實際遇到 CUDA Kernel 與 Marlin repack 相容性問題。

最後我改採:

Hcompany/Holo-3.1-35B-A3B-GGUF

搭配 llama.cpp CUDA Build,成功啟動模型並提供 API 服務。

這篇文章記錄完整流程,也保留幾個重要的踩坑經驗。


環境

本次環境如下:

硬體:NVIDIA DGX SparkGPU:NVIDIA GB10系統:Ubuntu Linux模型儲存位置:/mnt/ai-models推論框架:llama.cpp模型格式:GGUF量化版本:Q4_K_M

DGX Spark 使用統一記憶體架構,因此 CPU、GPU 與系統服務會共用記憶體。這點對 vLLM 與 llama.cpp 都很重要。


為什麼放棄 NVFP4 + vLLM

一開始使用 vLLM 載入:

Hcompany/Holo-3.1-35B-A3B-NVFP4

後,權重其實已經完整載入:

Loading safetensors checkpoint shards: 100% Completed | 3/3Loading weights took 142.78 seconds

但載入完成後,仍然在 Marlin FP4 重新整理階段失敗:

NotImplementedError:Could not run '_C::gptq_marlin_repack'with arguments from the 'CUDA' backend

這代表模型檔案本身沒有問題,真正卡住的是 vLLM 的 CUDA Extension 在 DGX Spark GB10 上沒有完整提供所需的 Marlin CUDA Operator。

如果只是想先把 Holo 3.1 跑起來,不一定要繼續投入時間處理 NVFP4 相容性。改用 GGUF + llama.cpp 是更快、更穩定的選擇。


移除 NVFP4 模型快取

vLLM 下載的 Hugging Face 模型通常會放在:

/mnt/ai-models/huggingface/hub/

先確認路徑:

find /mnt/ai-models/huggingface \  -maxdepth 3 \  -type d \  -name 'models--Hcompany--Holo-3.1-35B-A3B-NVFP4' \  -print

確認容量:

du -sh \  /mnt/ai-models/huggingface/hub/models--Hcompany--Holo-3.1-35B-A3B-NVFP4

確認無誤後刪除:

rm -rf \  /mnt/ai-models/huggingface/hub/models--Hcompany--Holo-3.1-35B-A3B-NVFP4

安裝 llama.cpp

1. 安裝編譯工具

sudo apt update
sudo apt install -y \  git \  build-essential \  cmake \  ninja-build \  libcurl4-openssl-dev \  pkg-config

2. 確認 CUDA Toolkit

export CUDA_HOME=/usr/local/cudaexport PATH="${CUDA_HOME}/bin:${PATH}"
export LD_LIBRARY_PATH="${CUDA_HOME}/lib64:${LD_LIBRARY_PATH:-}"
nvcc --versionnvidia-smi

nvcc --version 必須能正常回傳 CUDA 版本。

3. Clone llama.cpp

mkdir -p /mnt/ai-models/srccd /mnt/ai-models/srcgit 
clone https://github.com/ggml-org/llama.cpp.gitcd 
llama.cpp

如果之前已經下載過:

cd /mnt/ai-models/src/llama.cpp
git fetch origingit switch master
git pull --ff-only origin master

4. 編譯 CUDA 版本

cd /mnt/ai-models/src/llama.cpp
rm -rf buildcmake -B build \  -DGGML_CUDA=ON \  -DCMAKE_BUILD_TYPE=Releasecmake --build build \  --config Release \  -j 4 \  --target llama-server llama-cli

確認:

./build/bin/llama-server --version
./build/bin/llama-cli --version

下載 Holo 3.1 GGUF 模型

建立模型目錄:

mkdir -p \  /mnt/ai-models/llama-models/Holo-3.1-35B-A3B-GGUF

下載主模型、視覺投影模型與 Chat Template:

hf download \  Hcompany/Holo-3.1-35B-A3B-GGUF \  q4_k_m.gguf \  mmproj.f16.gguf \  chat_template.jinja \  --local-dir \  /mnt/ai-models/llama-models/Holo-3.1-35B-A3B-GGUF

確認:

ls -lh \  /mnt/ai-models/llama-models/Holo-3.1-35B-A3B-GGUF

應該看到:

q4_k_m.ggufmmproj.f16.ggufchat_template.jinja

單模型模式啟動

先用最簡單的單模型方式確認服務能運作:

cd /mnt/ai-models/src/llama.cpp
./build/bin/llama-server \  -m /mnt/ai-models/llama-models/Holo-3.1-35B-A3B-GGUF/q4_k_m.gguf \  --mmproj /mnt/ai-models/llama-models/Holo-3.1-35B-A3B-GGUF/mmproj.f16.gguf \  --jinja \  --host 0.0.0.0 \  --port 8080 \  -c 8192 \  -np 1 \  -ngl 999

參數說明:

--mmproj     指定視覺投影模型
--jinja      使用模型附帶的 Chat Template
-c 8192      Context Length
-np 1        同時處理 1 個請求
-ngl 999     儘可能將模型層放到 GPU

測試文字 API

curl -s http://192.168.0.240:8080/v1/chat/completions \  -H "Content-Type: application/json" \  -d '{    "model": "Holo-3.1-35B-A3B-GGUF",    "messages": [      {        "role": "user",        "content": "請使用繁體中文介紹你的 UI 畫面分析能力。"      }    ],    "max_tokens": 256,    "temperature": 0.2  }' | python3 -m json.tool

在這台 DGX Spark 上,實測文字生成速度約為:

82 tokens/s

測試圖片分析 API

curl -s http://127.0.0.1:8080/v1/chat/completions \  -H "Content-Type: application/json" \  -d '{    "model": "q4_k_m.gguf",    "messages": [      {        "role": "user",        "content": [          {            "type": "text",            "text": "Describe this image in one concise English sentence."          },          {            "type": "image_url",            "image_url": {              "url": "https://cdn.britannica.com/61/93061-050-99147DCE/Statue-of-Liberty-Island-New-York-Bay.jpg"            }          }        ]      }    ],    "thinking_budget_tokens": 64,    "max_tokens": 1024,    "temperature": 0.1  }' | python3 -m json.tool

已知問題:中文多模態輸出偶爾觸發解析錯誤

圖片推論本身可以成功,但在某些中文輸出中,llama-server 可能回傳:

Failed to parse input at pos ...

例如:

自由女神像、火炬、基座、城市天際線、高樓、水面、島嶼、樹木、旗�、船。

其中 是 UTF-8 無效字元替代符號。

實務上的處理方式:

1. 降低 temperature,例如 0.12. 限制輸出為簡短句子3. 提高 max_tokens,避免輸出被截斷4. Client 端遇到 500 時自動 Retry 一次5. 優先更新至最新版 llama.cpp

Router Mode:支援多模型切換

確認單模型模式正常後,可以啟用 Router Mode:

cd /mnt/ai-models/src/llama.cpp
./build/bin/llama-server \  --models-dir /mnt/ai-models/llama-models \  --models-max 1 \  --models-autoload \  --jinja \  --host 0.0.0.0 \  --port 8080 \  -c 8192 \  -np 1 \  -ngl 999

啟動後會看到:

Loaded 1 local model presets from /mnt/ai-models/llama-modelsAvailable models (1)    Holo-3.1-35B-A3B-GGUFstarting router server, no model will be loaded in this processrouter server is listening on http://0.0.0.0:8080

Router 會在 Client 第一次呼叫時才載入模型。

查看模型清單:

curl -s \  'http://127.0.0.1:8080/models?reload=1' | \  python3 -m json.tool

指定模型:

curl -s http://127.0.0.1:8080/v1/chat/completions \  -H "Content-Type: application/json" \  -d '{    "model": "Holo-3.1-35B-A3B-GGUF",    "messages": [      {        "role": "user",        "content": "請使用繁體中文簡短介紹你的功能。"      }    ],    "max_tokens": 512,    "temperature": 0.2  }' | python3 -m json.tool

Router Mode 的記憶體策略

我使用:

--models-max 1

意思是:

可以讓 Client 選擇多個模型但同一時間只保留一個模型在記憶體中

這很適合 DGX Spark。因為 Holo 35B、KV Cache、圖片 Token 與系統服務都會共用統一記憶體。

如果要同時提供 Holo 與另一個 Tool Calling 模型,建議:

Holo 35B:Context 8192 或 16384用途:UI 截圖與視覺分析較小的文字 Tool Calling 模型:Context 65536用途:Hermes Agent 預設模型

不同模型需要不同 Context Length 時,可使用 models.ini

version = 1

[*]
jinja = true
n-gpu-layers = 999
parallel = 1

[Holo-3.1-35B-A3B-GGUF]
model = /mnt/ai-models/llama-models/Holo-3.1-35B-A3B-GGUF/q4_k_m.gguf
mmproj = /mnt/ai-models/llama-models/Holo-3.1-35B-A3B-GGUF/mmproj.f16.gguf
ctx-size = 8192

[qwen-coder]
model = /mnt/ai-models/llama-models/qwen-coder-14b-q4_k_m.gguf
ctx-size = 65536

啟動:

./build/bin/llama-server \  --models-preset /mnt/ai-models/llama-models/models.ini \  --models-max 1 \  --models-autoload \  --host 0.0.0.0 \  --port 8080

讓 llama.cpp 開機就執行

一、確認執行檔路徑

先執行:

ls -lh /mnt/ai-models/src/llama.cpp/build/bin/llama-server

再確認模型目錄:

ls -lah /mnt/ai-models/llama-models

測試版本:

/mnt/ai-models/src/llama.cpp/build/bin/llama-server --version

如果這三個指令正常,就可以建立服務。


二、建立 systemd 服務

建立服務檔:

sudo nano /etc/systemd/system/llama-router.service

貼上:

[Unit]
Description=llama.cpp Router Server
Documentation=https://github.com/ggml-org/llama.cpp
After=network-online.target local-fs.target
Wants=network-online.target
RequiresMountsFor=/mnt/ai-models

[Service]
Type=simple
User=gwoyju
Group=gwoyju
WorkingDirectory=/mnt/ai-models/src/llama.cpp

Environment="LD_LIBRARY_PATH=/usr/local/cuda/lib64"
Environment="CUDA_HOME=/usr/local/cuda"

ExecStartPre=/usr/bin/test -x /mnt/ai-models/src/llama.cpp/build/bin/llama-server
ExecStartPre=/usr/bin/test -d /mnt/ai-models/llama-models

ExecStart=/mnt/ai-models/src/llama.cpp/build/bin/llama-server \
  --models-dir /mnt/ai-models/llama-models \
  --models-max 1 \
  --models-autoload \
  --jinja \
  --host 0.0.0.0 \
  --port 8080 \
  -c 8192 \
  -np 1 \
  -ngl 999

Restart=on-failure
RestartSec=10
TimeoutStopSec=30
KillSignal=SIGTERM
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

儲存後離開:

Ctrl + O
Enter
Ctrl + X

WantedBy=multi-user.target 讓服務可以隨一般多使用者開機流程啟動;Restart=on-failure 會在程式異常退出時重新啟動服務。

為什麼需要 RequiresMountsFor

你的模型與程式都放在:

/mnt/ai-models

如果外接 SSD 尚未掛載完成,直接啟動 llama-server 會失敗。

這一行:

RequiresMountsFor=/mnt/ai-models

會要求 systemd 先準備好該掛載點,再啟動 Router。


三、啟用開機自動執行

重新讀取服務設定:

sudo systemctl daemon-reload

設定開機自動啟動,並立即啟動:

sudo systemctl enable --now llama-router

查看服務狀態:

systemctl status llama-router --no-pager

正常情況應該看到:

Active: active (running)

以及:

router server is listening on http://0.0.0.0:8080

四、查看即時日誌

查看最近 100 行日誌:

journalctl -u llama-router -n 100 --no-pager

持續追蹤日誌:

journalctl -u llama-router -f

離開即時日誌:

Ctrl + C

五、測試 Router API

確認 Router 已啟動:

curl -s http://127.0.0.1:8080/health

查看模型清單:

curl -s \  'http://127.0.0.1:8080/models?reload=1' | \  python3 -m json.tool

測試 Holo 3.1:

curl -s http://127.0.0.1:8080/v1/chat/completions \  -H "Content-Type: application/json" \  -d '{    "model": "Holo-3.1-35B-A3B-GGUF",    "messages": [      {        "role": "user",        "content": "請使用繁體中文簡短介紹你的功能。"      }    ],    "max_tokens": 256,    "temperature": 0.2  }' | python3 -m json.tool

第一次呼叫時會需要等待模型載入。後續請求會比較快。


六、常用管理指令

啟動服務

sudo systemctl start llama-router

停止服務

sudo systemctl stop llama-router

重新啟動

sudo systemctl restart llama-router

查看狀態

systemctl status llama-router --no-pager

取消開機自動啟動

sudo systemctl disable --now llama-router

七、確認開機後是否真的自動啟動

重新開機:

sudo reboot

重新 SSH 登入後執行:

systemctl status llama-router --no-pager

確認 Port:

ss -ltnp | grep :8080

測試模型清單:

curl -s http://127.0.0.1:8080/models | \  python3 -m json.tool

八、改用 models.ini

準備讓不同模型有不同 Context Length:

Holo 35B:8192Hermes 預設 Tool Calling 模型:65536

這種情況建議不要在服務中使用:

--models-dir-c 8192

而是改用:

--models-preset

假設設定檔位於:

/mnt/ai-models/llama-models/models.ini

服務中的 ExecStart 改成:

ExecStart=/mnt/ai-models/src/llama.cpp/build/bin/llama-server \
  --models-preset /mnt/ai-models/llama-models/models.ini \
  --models-max 1 \
  --models-autoload \
  --host 0.0.0.0 \
  --port 8080

改完後重新載入設定:

sudo systemctl daemon-reload
sudo systemctl restart llama-router

查看日誌:

journalctl -u llama-router -f

九、避免 Ollama 開機後搶占記憶體

你之前遇過記憶體不足。如果目前 DGX Spark 主要改用 llama.cpp,建議停用 Ollama 的開機自動啟動:

sudo systemctl disable --now ollama

確認:

systemctl status ollama --no-pager

未來需要恢復:

sudo systemctl enable --now ollama

十、限制只允許內網連線

目前使用:

--host 0.0.0.0

代表區域網路內其他裝置可以存取 API。Router Mode 目前仍屬於實驗性功能;llama.cpp 啟動日誌也提醒,不建議直接暴露在不受信任的網路環境。

假設區域網路是:

192.168.0.0/24

可以設定 UFW:

sudo ufw allow from 192.168.0.0/24 \  to any port 8080 proto tcp

查看規則:

sudo ufw status numbered

不要直接把 Port 8080 暴露到公網。


建議你現在直接執行的版本

建立 /etc/systemd/system/llama-router.service 後,執行:

sudo systemctl daemon-reload
sudo systemctl enable --now llama-router
systemctl status llama-router --no-pagerjournalctl -u llama-router -n 50 --no-pager

這樣 DGX Spark 每次重新開機後,llama.cpp Router Server 就會自動啟動,並等待 Hermes Agent 或其他 Client 指定要載入的模型。

參考資料

https://huggingface.co/collections/Hcompany/holo31

https://build.nvidia.com/spark/llama-cpp/instructions