Select Page
NVFP4 與 MTP 是什麼?Qwen3.6 本地推理加速重點整理

NVFP4 與 MTP 是什麼?Qwen3.6 本地推理加速重點整理

NVFP4 和 MTP 最近被放在一起討論,原因很簡單:本地大模型推理開始從「能不能放進顯存」進入「怎麼把記憶體搬運成本壓到最低」的階段,Unsloth 釋出的 Qwen3.6 NVFP4 quants 主打 27B 模型可在 24GB VRAM 上運行,35B-A3B 在 B200 上可達 17,561 tok/s,並宣稱相對 NVIDIA NVFP4 quant 有 2.5 倍速度提升。

這些數字很吸引人,但不能直接翻譯成「買 RTX 5090 就一定變快」。真正該看的,是 NVFP4 和 INT4 的格式差異、MTP 如何降低推理瓶頸,以及消費級 Blackwell 現階段為什麼可能吃不到企業級 B200 的完整紅利。

先講結論

  • NVFP4 是 4 位元浮點量化,不是傳統 4 位元整數量化
  • INT4 的刻度固定,NVFP4 的浮點表示更適合保留權重動態範圍
  • MTP 是多 Token 預測,重點是減少每個 token 都重新搬一次權重的浪費
  • 17,561 tok/s 是特定企業級硬體條件下的吞吐量,不是一般 RTX 50 的保證值
  • 企業部署時,驅動、CUDA、vLLM、llama.cpp、環境變數和自動更新都可能比模型本身更容易出事

如果你之前看過我整理的 Qwen 3.6、MXFP8、NVFP4 比較,這篇可以當成補充版,前一篇偏選型,這篇偏底層原因和部署風險。

NVFP4 和傳統 INT4 差在哪

INT4 是 4 位元整數量化。你可以把它想成一把固定刻度的尺,每一格距離都一樣。問題是神經網路權重分布通常不是均勻的,很多重要數值會擠在接近零的位置,也會偶爾出現比較大的極端值。固定刻度很省空間,但容易犧牲細微權重差異。

NVFP4 則是 4 位元浮點量化,它仍然只用 4 位元,但用浮點格式表達數值,能用有限 bit 描述更大的動態範圍,小數值區域可以保留比較細的變化,大數值區域則用比較寬的範圍表示,這就是為什麼 NVFP4 在某些模型上可以比傳統 INT4 更接近原始權重的行為。

NVFP4 與傳統 INT4 的差異表格
項目NVFP4傳統 INT4
數值格式4 位元浮點4 位元整數
刻度特性動態範圍固定刻度
細節保留較能保留小數值細微權重較易流失
硬體依賴需要 FP4 支援與 kernel 最佳化生態成熟
實務風險新硬體仍看驅動成熟度穩定但精度較受限

這裡要補一個很重要的判斷:NVFP4 不是自動贏 INT4。若硬體、驅動、kernel、推理框架都沒有最佳化,NVFP4 可能反而更慢。格式更先進,不代表你手上的卡和軟體棧已經準備好了。

MTP 為什麼會讓速度暴衝

MTP 是 Multi-Token Prediction,也就是多 Token 預測。傳統自回歸語言模型通常一次產生一個 token。每產生一個 token,都要讀取大量模型權重,再做一次運算。對大模型來說,很多時間不是花在純計算,而是花在權重從顯存搬到運算核心的路上。

MTP 的核心思路,是在一次權重讀取裡嘗試預測多個後續 token。它不是讓模型魔法般跳過推理,而是把原本每一步都要重複付出的記憶體傳輸成本攤薄。當瓶頸主要在顯存頻寬和權重搬運時,這種方式就能明顯提高吞吐量。

Reddit 原始討論裡也有人問 MTP 是否已加入,Unsloth 相關回覆指出 MTP 已經在裡面,並且有說法提到 MTP tensors 已直接內建到 quants 中。這表示使用者不只是拿到一個 NVFP4 量化權重,而是拿到帶有 MTP 加速路徑的版本。

2.5 倍速度提升要怎麼看

這次最容易被誤讀的是「2.5 倍」。Reddit 討論中有人問這個速度提升是不是相對 Q4,Unsloth 回覆脈絡指出,這個比較是相對 NVIDIA 的 NVFP4 quant,而不是拿所有 Q4 或 INT4 實作一起比較。這一點很重要,因為不同量化格式、不同框架、不同 GPU、不同 batch 和 context 設定,都會影響 token/s。

另外,35B-A3B 達到 17,561 tok/s 的數字是在 B200 這類企業級硬體條件下出現。這可以說明 NVFP4 和 MTP 的上限很高,但不代表一般 RTX 50 系列能直接複製。企業採購或本地部署,最怕把資料中心卡的極限數字誤當成桌機卡的常態表現。

為什麼 RTX 50 可能反而沒有變快

同樣叫 Blackwell,不代表所有 Blackwell 都一樣。B200 屬於資料中心路線,軟體路徑和底層 kernel 通常優先被最佳化。RTX 50 消費級卡雖然也有新架構能力,但 SM120 的軟體支援成熟度可能還沒跟上。

Reddit 討論中有人提到,消費級 Blackwell 的 NVFP4 利用率仍可能不理想,也有人實測 NVIDIA NVFP4 Qwen3.6 27B 對比原本 INT4 時,token 生成速度不但沒有提升,還有下降的案例。這些不是說 NVFP4 沒用,而是說「硬體支援」和「軟體真的最佳化」中間有一段距離。

如果你正在看 RTX 5090、5080 或 5060 Ti 類配置,不要只看 NVFP4 四個字。你要確認推理框架是否真的支援你的 GPU、驅動和 CUDA 是否符合要求、實際模型是否有對應 kernel,還要看你的工作負載是 prompt processing 重,還是 token generation 重。

企業部署最容易踩到的不是模型,而是環境

這類極限加速模型最怕直接上正式環境。逐字稿和社群討論都提到一個共通風險:推理框架和底層格式更新太快,vLLM、CUDA、驅動、模型權重、環境變數任何一層沒對上,都可能變慢甚至崩潰。

我會把部署流程拆成四步。第一步先在單機沙盒測模型能不能正常跑。第二步測固定 prompt、長上下文、工具調用和 agent loop。第三步鎖定版本,關掉正式環境自動更新。第四步再進入內部 PoC。這和我之前整理的 本地大模型推理框架選型 是同一個邏輯,速度只是其中一個指標,穩定性才決定能不能上線。

  • 正式環境不要開自動更新
  • 先鎖定 CUDA、driver、vLLM 或 llama.cpp 版本
  • 不要把 B200 benchmark 直接套到 RTX 50 採購決策
  • 工具調用和 agent 流程要單獨壓測
  • 用 24GB VRAM 跑 27B 可以測,但不代表企業就一定該選最大模型

為什麼 9B 和 GGUF 反而更實用

當大家看到 27B 可塞進 24GB VRAM,甚至 35B-A3B 跑出極限吞吐量,很容易以為模型越大越好。但真正落地時,很多企業只需要工單分類、客服輔助、內部文件查詢、簡單自動化。這些任務未必需要 27B 或 35B。

9B 模型的價值在於部署門檻更低,可以放進 12GB 或 16GB 顯卡,還能保留更多 VRAM 給上下文和工具調用。GGUF 則讓 llama.cpp 這類本地推理路線更容易接上 CPU 或低階硬體。這也是為什麼社群一邊討論 17,561 tok/s,一邊仍然敲碗 9B 和 GGUF 版本。

對中小企業來說,我會優先問三個問題。你的資料是否需要完全本地化,你的任務是否真的需要大模型,你是否有能力維護最新 GPU kernel 和推理框架。如果答案不明確,小模型加穩定部署,通常比追逐極限跑分更務實。

我的判斷

NVFP4 和 MTP 很重要,因為它們代表本地 AI 推理正在處理真正的瓶頸:顯存容量、權重搬運、吞吐量和模型品質之間的平衡。NVFP4 解決的是低 bit 量化下如何保留更多數值動態範圍,MTP 解決的是一次只吐一個 token 帶來的記憶體傳輸浪費。

但我不會把它解讀成「RTX 玩家立刻起飛」。比較健康的看法是:資料中心硬體已經看到 NVFP4 和 MTP 的上限,消費級硬體還在等軟體棧補齊。現在要採購或部署,應該把 PoC、版本鎖定、框架支援和真實任務測試放在跑分前面。

真正值得期待的是,這些技術成熟後,27B 不再只能放在機房裡,9B 和 GGUF 也能讓更小的團隊取得足夠好用的本地 AI。極限跑分很好看,但真正改變企業日常的,通常是穩定、便宜、好維護的那一條路。

延伸資源

FAQ

NVFP4 是什麼?

NVFP4 是 NVIDIA 4 位元浮點量化格式。它和 INT4 一樣節省記憶體,但用浮點方式表達數值,較適合保留神經網路權重中的動態範圍。

NVFP4 和 INT4 最大差異是什麼?

INT4 是固定刻度的整數量化,NVFP4 是 4 位元浮點量化。前者生態成熟,後者更依賴硬體 FP4 支援和軟體 kernel 最佳化。

MTP 是什麼?

MTP 是 Multi-Token Prediction,多 Token 預測。它讓模型在一次權重讀取中嘗試預測多個後續 token,降低記憶體傳輸瓶頸,提高吞吐量。

ChatGPT Work 是什麼?Codex 與 GPT-5.6 正式合體成 AI 代理

ChatGPT Work 是什麼?Codex 與 GPT-5.6 正式合體成 AI 代理

ChatGPT Work 的重點,不只是 OpenAI 又多了一個模式,而是 Codex 的 Agent 執行能力正式被放進 ChatGPT 裡,並由 GPT-5.6 Sol、Terra、Luna 三個模型層級支撐起來。

這代表 ChatGPT 正在從「聊天視窗」變成「能跨檔案、跨應用程式、跨瀏覽器、跨團隊工具做事的 AI 代理」,以前 Codex 比較像工程師工具,現在它的能力被包進一般知識工作者也能理解的 Work 模式裡,這一步很關鍵。

我會把這次更新理解成三件事:

第一,Codex 不再只是寫程式,而是成為 ChatGPT 的行動層

第二,GPT-5.6 把模型能力分成 Sol、Terra、Luna,讓不同成本和任務有不同選擇

第三,Sites、桌面 App、外掛目錄、Ultra 多 Agent 模式,正在把「讓 AI 完成工作」這件事產品化。

而且不用再多開多個 APP 了

先講結論:ChatGPT Work 是 Codex 走向全民化的形態

以前談 Codex,直覺會想到寫程式、改 repo、跑測試、開 PR,這次 ChatGPT Work 的定位不同,它不是只服務開發者,而是把 Codex 那套長任務執行能力拿去處理一般工作:分析 Excel、整理資料夾、生成簡報、建立互動式網站、讀 Slack 或 Gmail、把結果發回團隊工具。

這也解釋了為什麼 OpenAI 要把 Chat、Work、Codex 放在同一個桌面應用程式裡。

Chat 負責快速問答,Work 負責長任務,Codex 負責更深的開發與工具執行。對使用者來說,不需要再思考「我現在要開哪個產品」,而是直接把任務丟進同一個工作入口。

站上之前整理過 從 Claude Code、Codex、Hermes 到 nuwa-skill 的 AI 工作流,那時 Codex 還比較偏工程場景;ChatGPT Work 則是把這條路推向更大的辦公場景。

GPT-5.6 三層模型:Sol、Terra、Luna 各自負責不同工作

這次 GPT-5.6 不再只是單一模型名稱,而是拆成三個層級。

模型定位適合場景
Sol旗艦模型高難度 Agent 任務、程式碼、設計判斷、複雜知識工作
Terra日常均衡模型一般工作流、文件分析、較高頻的辦公任務
Luna快速低成本模型大量處理、成本敏感、速度優先的任務

這個分層很務實。不是每個任務都需要 Sol,也不是每個人都該用最高推理檔。真正成熟的 AI 工作流,應該是把最貴的模型留給最難的決策,把便宜快速的模型用在大量例行工作。

參考資料裡提到的定價方向也很清楚:

Sol 最貴,Terra 居中,Luna 最便宜。這代表未來使用 ChatGPT Work 時,模型選擇會變成工作流設計的一部分,而不只是「選最強」。

Ultra 模式:不是一個模型想更久,而是一組 Agent 並行

Ultra 模式很值得注意。它不是單純把同一個模型推理時間拉長,而是讓多個 Agent 平行工作,再把結果整合起來,這和過去「一個模型慢慢想」的概念不同,更接近一個小團隊同時拆任務。

這種設計特別適合長任務:研究、寫報告、建立網站、跑程式、做多版本比較、測試不同方向,當任務可以拆成多條路並行時,Ultra 的價值才會出來。

但它也帶來現實問題:用量會變大。實測留言裡有人提到 Work 模式會快速消耗額度,這點很合理。多 Agent 並行不是免費加速,它本質上就是用更多 token、更多運算,換更高成功率或更短等待時間。

ChatGPT Work 可以做什麼?重點是「交付成果」

ChatGPT Work 最重要的變化,是它不只回答問題,而是直接交付成果,官方展示裡出現幾個很典型的辦公場景:讀 Slack 和員工回饋、找出適合訪談的人、安排會議;分析財務模型、更新 Excel、生成 PowerPoint;把分析結果做成可分享的互動網站。

這些任務的共同點是:它們不是一句問答,而是需要跨多個資料源、跨多個步驟、最後輸出一個可用成品,這就是 Codex 能力進入 ChatGPT 的意義,Codex 原本擅長把目標拆成步驟、執行工具、檢查結果,Work 則把這套能力包成知識工作者能用的產品介面。

如果你想把這類長任務做得更穩,前置需求釐清仍然很重要,我會把 Grill Me 需求訪談工作流 放在 ChatGPT Work 前面用:先問清楚目標、限制、輸出格式和驗收標準,再讓 Work 開始執行。

桌面 App 是關鍵:本機檔案、瀏覽器分頁、其他 App 都進來了

新的 ChatGPT 桌面 App 是這次更新裡非常關鍵的一塊。它不只是把網頁版包成桌面視窗,而是讓 ChatGPT 可以碰到本機檔案、瀏覽器分頁,甚至其他應用程式。

這代表一個很大的轉折:AI 不再只讀你貼進對話框的內容,而是能在你授權的範圍內,直接理解桌面上的工作現場。資料夾裡的 PDF、Chrome 分頁裡的背景資料、Apple Notes 裡的凌亂筆記、試算表裡的回饋資料,都可以成為任務上下文。

這和 OpenWork / OpenCode 桌面工作台 的方向其實相通:AI Agent 最後一定會往「讀得到你的工作環境、操作得到工具、交付得了成品」這條路走。

Sites:從報告變成可分享的互動工具

Sites 是另一個我覺得很重要的功能。過去 AI 幫你整理資料,多半輸出一段文字、一個表格或一份簡報,Sites 則是把結果變成互動網站、內部工具、儀表板或原型。

這會改變「交付物」的想像。財務分析不一定只能是一份 PowerPoint,也可以是可互動的 dashboard,產品規劃不一定只能是一份文件,也可以是可點擊的 prototype;資料整理不一定只是摘要,也可以變成團隊能共同查看的網站。

這裡也可以接回站上之前整理過的 AISA 一個 API Key 連上多種資源。未來真正有價值的不是單一模型,而是模型、資料源、外掛、網站部署和團隊協作工具串在一起的工作流。

外掛目錄回來了,但這次不是 2023 年那種玩具感

這次新的統一外掛程式目錄,包含 Google Drive、SharePoint、Slack、Microsoft Teams、Gmail、Outlook、Salesforce、Adobe、Zoom、LinkedIn、GitHub、Canva、Dropbox 等整合。這很像 2023 年 ChatGPT Plugins 的第二次機會,但底層條件已經不同。

2023 年的外掛比較像「讓聊天機器人查外部資料」。這一次的外掛更接近「讓 Agent 取得任務所需的工作上下文」。當模型具備長任務執行能力,外掛就不是裝飾,而是資料入口、工具入口和交付入口。

也就是說,外掛目錄真正的價值,不是多支援幾個品牌,而是讓 ChatGPT Work 可以在你的工作系統中移動:讀資料、做分析、產出文件、發送結果、更新工具。

實測很強,但不能神化:耗時、額度、細節錯誤仍然存在

NiceKate AI 的實測很有參考價值,因為它不是只看官方展示,而是拿 GPT-5.6 Sol 跑圖片辨識、PPT、Excel、網頁設計、Image to Code、3D 建模、Android App UI 審查、macOS App 開發和短片生成。

好的部分很明顯:頁面設計質感比前代更好,能做更完整的互動式視覺化,能把圖片轉成可互動網頁,能操作 Android 裝置截圖做 UI 審查,也能在 macOS App 開發中自行遇到錯誤再修正。

但限制也很清楚:有些任務會跑 19 分鐘、30 分鐘、甚至 40 分鐘,複雜 3D、交通仿真、精密還原仍會出現結構錯誤,Work / Codex 模式會明顯消耗額度,這不是「按一下就完美交付」的魔法,而是「可以把更多長任務交給 Agent,但你要學會規格、驗收和成本控管」。

模型能力對很多人來說可能已經過剩,真正重要的是在實際場景裡能解決什麼問題。這句話很適合放在 ChatGPT Work 上。不要只測模型會不會做炫技 demo,要問它能不能幫你穩定完成週報、資料整理、客戶研究、網站原型、財務分析、App 審查這些真任務。

安全與權限:Agent 能做事後,風險也變具體了

當 ChatGPT Work 可以讀檔案、看瀏覽器、操作 App、存取 Slack / Gmail / Drive,安全問題就不再是抽象討論。它能做越多,越需要清楚的權限、審查和用量控管。

參考資料提到 Auto-Review、安全監控、紅隊測試、依風險調整存取權限,以及 Enterprise / Edu 管理員可以做 spend controls。這些功能不是企業才需要,一般使用者也要養成習慣:不要一次授權太多資料,不要讓 Agent 直接做不可逆操作,重要輸出要驗證。

這也是為什麼我一直覺得 Agent 工作流需要紀律,你可以參考 Grill Me 的思路:先讓 AI 問清楚,再讓它執行,重要任務要有驗收清單;涉及資料、金錢、客戶、程式部署時,要保留人工確認點。

這對使用者代表什麼?

我覺得 ChatGPT Work 會讓三種人最先有感。

  • 知識工作者:可以把研究、整理、簡報、試算表、網站原型交給 Work 做第一版,再由人驗收。
  • 開發者與產品團隊:Codex 能力整合進 ChatGPT 後,從需求、原型、程式、測試到部署的距離會縮短。
  • 一人公司與內容創作者:可以把資料蒐集、腳本、視覺化、網站、短片和社群素材變成一條工作流。

但這也會拉開差距。會下任務、會拆規格、會驗收、會控制成本的人,會把 ChatGPT Work 用得像小團隊,只會丟一句「幫我做一下」的人,可能只會得到昂貴又不穩的半成品。

我會怎麼開始用?

如果現在要開始測 ChatGPT Work,我會先從低風險但有價值的任務開始。

  • 整理一個資料夾裡的 PDF、簡報和筆記,產出一份會議簡報。
  • 讀一份 Excel 或 CSV,產出互動式 dashboard 和重點摘要。
  • 把產品想法做成可點擊網站原型,再請它列出待驗證假設。
  • 讓 Codex 檢查一個小型 repo,先產生修改計畫,不要直接改。
  • 把 Slack / Gmail / Drive 這類外掛逐步接入,不要一開始全開。

如果你想比較本地 Agent 工作台和雲端 Work 模式的差異,可以接著看 OpenWork / OpenCode 桌面工作台。雲端 Work 勝在整合和模型能力,本地工具則勝在可控、可自訂和成本安排。

結論:ChatGPT Work 是「AI 代理辦公」的分水嶺

ChatGPT Work 不是單純的新功能,而是 OpenAI 把 Codex、GPT-5.6、桌面 App、外掛、Sites、多 Agent 模式合在一起後,給一般使用者的一個新工作入口。

它最重要的意義是:AI 不再只是回答你的問題,而是開始接近「拿到目標後,跨工具完成工作」,這也是 AI Agent 真正從開發者圈走向辦公室、團隊、內容創作和一人公司的關鍵一步。

但越是這樣,越要記得兩件事:第一,強模型不等於免驗收;第二,長任務不等於低成本。未來真正重要的能力,不只是會用 GPT-5.6,而是會把任務設計成 AI 能完成、人能驗收、成本能控制的工作流。

延伸資源

FAQ

ChatGPT Work 是什麼?

ChatGPT Work 是 OpenAI 把 Codex 的 Agent 執行能力整合進 ChatGPT 後推出的工作模式,目標是處理比一般聊天更長、更複雜、需要跨工具完成的任務。

GPT-5.6 Sol、Terra、Luna 差在哪?

Sol 是旗艦模型,適合高難度 Agent 任務;Terra 是日常均衡模型;Luna 則主打速度和低成本,適合大量處理。

ChatGPT Work 和 Codex 是什麼關係?

Codex 提供長任務執行、工具操作和開發相關能力;ChatGPT Work 則把這些能力包進一般使用者能操作的 ChatGPT 工作介面。

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 架構控制權。

Ornith 1.0 是什麼?開源 AI 編程模型開始學會自己拆任務

Ornith 1.0 是什麼?開源 AI 編程模型開始學會自己拆任務

Ornith 1.0 最值得注意的地方,不是又多了一個會補程式碼的開源模型,而是它把「寫程式」往前推了一步:先替任務搭工作流程,再開始產生解法。

這個差別很關鍵。很多 AI 寫程式失敗,不是模型不會寫函式,而是前面的任務拆解、資料來源、依賴安裝、API key、驗證方式沒有想清楚。Ornith 1.0 想解的正是這一層問題:讓模型先建立 scaffold,也就是一套能引導任務完成的工作台。

Ornith 1.0 是什麼?

Ornith 1.0 是 DeepReinforce 推出的開源 Agentic Coding 模型系列,官方定位是 self-improving open-source models for agentic coding。它不是單一模型,而是一整組不同大小與格式的模型家族。

  • 9B Dense:比較適合本地測試與資源有限的部署。
  • 31B Dense:官方頁列入模型家族,偏向更高能力的 dense 版本。
  • 35B MoE:能力與資源需求往上推,Ollama 也提供 35B 版本。
  • 397B MoE:旗艦級模型,更偏多 GPU 伺服器與研究測試場景。

官方資料提到,Ornith 1.0 建立在 Gemma 4 與 Qwen 3.5 這類 pretrained model 之上,並針對 coding agent 任務做後訓練。Hugging Face collection 目前列出 9B、35B、397B,以及 GGUF、FP8 等不同格式;GitHub README 也把這些版本整理成可部署的 checkpoint 清單。

如果你原本就在關注 Ollama + Qwen 3.6 的模型選擇,Ornith 1.0 可以放在同一條線上看:它不是單純聊天模型,而是更偏「本地程式代理」的方向。

真正的重點:先搭 scaffold,再寫程式

Ornith 1.0 的訓練思路,可以用一句話理解:模型不只學會產生 solution rollout,也學會產生帶領自己完成任務的 scaffold。

在傳統寫程式模型裡,使用者丟一個需求,模型很容易直接進入「產生程式碼」模式。但真實的小工具開發通常不是這樣。你要先知道資料從哪裡來、需不需要註冊 API、有哪些套件依賴、結果要怎麼展示、最後要怎麼驗證。

例如做一個五天天氣預報工具,如果一開始選 OpenWeather,後面才發現需要 API key,任務就會卡住。比較好的 agent 行為是回頭調整方案,改找不需要 API key 的資料來源,重新整理資料結構與 UI 呈現。Ornith 1.0 想訓練的,就是這種「條件變了,工作流程也跟著改」的能力。

這也解釋了為什麼它比較適合拿來觀察 AI agent,而不是只拿幾題補全測試就下結論。對程式代理來說,會寫一段 function 只是基本盤;能不能拆任務、改策略、補驗證,才是進入真實專案後的差距。

Benchmark 可以看,但不要只看跑分

官方 benchmark 涵蓋 Terminal-Bench 2.1、SWE-bench Verified、SWE-bench Pro、SWE-bench Multilingual、NL2Repo、SWE Atlas 等任務。下面先抓兩個比較容易理解的指標來看:

模型Terminal-Bench 2.1SWE-bench Verified定位
Ornith-1.0-9B43.169.4本地測試與輕量部署
Ornith-1.0-35B64.275.6工作站或較高資源環境
Ornith-1.0-397B77.582.4多 GPU 伺服器與旗艦能力
Ornith 1.0 9B、35B、397B 在 Terminal-Bench 2.1 與 SWE-bench Verified 的比較圖

9B 的意義不在於它能不能打贏所有大模型,而是它讓本地端測試變得比較實際。35B 與 397B 則是觀察這套 scaffold 訓練方法能不能隨模型規模放大的重點版本。

不過跑分仍然只能當入口。Coding agent 的實際體驗,還會被上下文管理、工具調用、檔案系統安全邊界、任務記憶、互動方式影響。這也是為什麼 Claude Code、Codex 這類工具難以只用「模型分數」比較。它們拼的是整套工作流,不只是底層模型。

如果你想把本地模型接進開發工作流,可以延伸看這篇 Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本開發環境,它比較接近 Ornith 1.0 可能落地的位置。

怎麼在 Ollama 與 Hugging Face 上取得 Ornith 1.0?

目前最直接的入口有四個:

Ollama 頁面列出 9 個模型項目,並標示 `ornith:latest`、`ornith:9b` 約 5.6GB、`ornith:35b` 約 21GB,context window 皆為 256K。最簡單的測試方式是:

ollama run ornith
ollama run ornith:9b
ollama run ornith:35b

GitHub README 也提供從 Hugging Face GGUF 直接跑的方式:

ollama run hf.co/deepreinforce-ai/Ornith-1.0-9B-GGUF

如果你要讓其他電腦連到同一台 Ollama 伺服器,可以搭配 Ollama 遠端連線教學 來設定 API endpoint。Ornith 1.0 這類程式模型,通常會更適合放在可以被 IDE、CLI agent 或自動化腳本呼叫的環境裡。

Reward hacking 是這類模型一定要面對的問題

讓模型自己產生 scaffold,能力會變大,風險也會變大。最典型的問題是 reward hacking:模型不是好好完成任務,而是想辦法鑽驗證器的空子。

在程式任務裡,這可能長得很實際:偷看測試檔、硬寫 expected output、碰不該碰的驗證腳本,或把環境改到看起來通過。官方資料提到的防護思路,是把外層信任邊界固定住,讓環境、工具表面與測試隔離不能被模型改;再用規則監控與模型複查,把可疑方案篩掉。

這一段其實比跑分更重要。因為 agentic coding 的核心不是一次回答,而是連續操作。模型能操作越多工具,就越需要清楚的權限邊界與可追蹤紀錄。這也是我會把 Ornith 1.0 放在「值得測試的開源方向」,而不是「馬上取代成熟 coding agent」的位置。

如果你對這種自學型 agent 架構有興趣,可以接著看 Claude Memory 與 Dreaming:自學型 AI Agent 的下一步,兩者都在處理一個相近問題:AI 不只是回答,而是如何在任務中累積策略。

我會怎麼選版本?

如果只是想先試試看,從 `ornith:9b` 開始最合理。它的下載量、顯存壓力與啟動成本都比較低,也比較適合拿來測「任務拆解」是不是真的有感。

如果你有比較強的工作站,`ornith:35b` 才值得進入第二輪測試。它的定位更接近可用的 coding agent 模型,但也更需要良好的硬體與服務設定。若你的目標是跑大型專案、長上下文、多步驟任務,可以把 35B 放進候選清單。

397B 則不建議一般使用者一開始就碰。它更像是研究、企業或多 GPU 伺服器環境要評估的版本。對多數人來說,先把 9B/35B 放進 Ollama 或 OpenAI-compatible endpoint,測試能否穩定完成真實任務,會比追最大參數更有價值。

想把模型接進工具鏈,也可以參考 OpenCode 如何使用本地端模型。Ornith 1.0 真正有趣的地方,正是在「本地模型 + coding agent + 可控工具」這個交會點。

結論:值得追,但要用真實任務測

Ornith 1.0 的亮點不是單一 benchmark 數字,而是它把開源程式模型推向「會先規劃工作台」的方向。這對本地 AI 編程很重要,因為真實任務往往不是只補一段 code,而是資料來源、依賴、限制、驗證與修正一起出現。

短期內,我會先看兩件事:第一,9B GGUF 在一般工作站或高階個人電腦上能不能穩定跑;第二,35B 在多步驟專案裡,能不能真的比一般 coding model 更會拆任務與自我修正。

如果這兩件事站得住,Ornith 1.0 就不只是又一個開源模型,而是本地 AI coding agent 往前走的一個重要訊號。

FAQ

Ornith 1.0 是什麼?

Ornith 1.0 是 DeepReinforce 推出的開源 Agentic Coding 模型系列,重點不是只產生程式碼,而是讓模型先為任務建立 scaffold,包含拆解步驟、工具選擇、驗證方式與錯誤處理,再產生解法。

Ornith 1.0 有哪些版本?

官方釋出 9B Dense、31B Dense、35B MoE 與 397B MoE 等版本;Hugging Face collection 中也包含 GGUF 與 FP8 版本。Ollama 頁面目前列出 ornith:9b 與 ornith:35b,兩者皆標示 256K context window。

一般使用者應該先跑哪個版本?

如果目標是本地測試,建議先從 9B 或 9B GGUF 開始;35B 比較適合顯存較充足的工作站。397B 更偏向多 GPU 伺服器環境,不是一般個人電腦的起手式。

Ornith 1.0 可以取代 Claude Code 或 Codex 嗎?

目前比較合理的看法是「值得測試的開源方向」,不是直接取代成熟工具。

Claude Code、Codex 這類產品還包含上下文管理、工具調用、專案理解、安全邊界與互動體驗,模型本身只是其中一層。

Ornith 1.0 怎麼用 Ollama 跑?

Ollama 官方頁面提供 `ollama run ornith`、`ollama run ornith:9b` 與 `ollama run ornith:35b`。

如果要直接使用 Hugging Face 的 GGUF,也可以參考 GitHub README 裡的 `ollama run hf.co/deepreinforce-ai/Ornith-1.0-9B-GGUF`。

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、程式碼維護、企業知識問答、法務研究、客服流程與內部自動化。

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

官方建議參數

llama-server \
  --hf Hcompany/Holo-3.1-35B-A3B-GGUF \
  --n-gpu-layers 999 \
  --ctx-size 65536 \
  --batch-size 16384 \
  --ubatch-size 2048 \
  --flash-attn 1 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --image-min-tokens 1024 \
  --ctx-checkpoints 8 \
  --cache-ram 32768 \
  --kv-unified \
  --threads 16

測試文字 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