by Rain Chu | 8 月 28, 2026 | AI , GGUF , Stable Diffusion , 圖型處理 , 影片製作 , 繪圖
LTX 2.3 把畫面、聲音、人物動作與鏡頭運動放進同一套生成流程,還能透過 ComfyUI 在本機執行,對只有 8GB 顯存的使用者來說,社群 GGUF 量化工作流確實打開了一扇門,但「能跑」不等於完整模型全放進顯存,也不代表每台電腦都能在不到一分鐘內完成。
我會把 LTX 2.3 定位成一個適合實驗同步影音、角色短片與圖生影片的本地模型,它可以成為 OpenMontage 本地 AI 影片工作流 裡的生成引擎,也可以獨立放在 ComfyUI 裡反覆調整。真正要先弄清楚的,是權重版本、顯存、系統記憶體與工作流之間的關係。
LTX 2.3 改進了什麼
LTX 2.3 官方頁面 把這次更新整理成幾個核心方向。新的 VAE 改善髮絲、材質與邊緣細節,較大的文字連接器能理解多主體、空間關係、動作與鏡頭指令,圖生影片減少了畫面凍結與只做平移縮放的情況,音訊也換上新的 vocoder,降低雜音、靜音缺口與突然中斷。
支援文生影片與圖生影片
能在同一個流程生成畫面與同步音訊
改善人物微表情、動作與鏡頭運動
原生支援最高 1080×1920 的直式影片
提供完整權重、Distilled、FP8 與社群量化方案
官方也提醒,LTX 2.3 採用新的 latent space,舊版 LoRA 不能直接當成完全相容的資產,通常需要重新訓練。這點比單純更新模型檔更重要,已經累積大量 LTX 2 工作流的人要先做相容性測試。
8GB 顯卡能跑,但要先拆掉一句話裡的誤會
官方 ComfyUI 文件 把標準本地工作流的前置條件列為 32GB 以上顯存與 100GB 以上可用磁碟空間。8GB 顯卡路線使用的是社群 GGUF 量化權重、模型卸載與系統記憶體,不是把 BF16 完整權重硬塞進 8GB 顯存。
版本 適合用途 主要取捨 BF16 Dev 品質驗證與正式輸出 硬體需求最高 Distilled 快速迭代與工作流測試 速度優先 FP8 較低顯存的官方量化路線 品質與資源需求折衷 GGUF Q4 或 Q5 8GB 到 16GB 顯存的社群工作流 依賴 CPU offload、系統記憶體與相容節點
以 QuantStack 的 LTX 2.3 GGUF 為例,Q5_K_S 檔案約 18.5GB,已經大於 8GB 顯存。能在 8GB 顯卡執行的關鍵,是工作流不要求所有資料同時留在 GPU。代價是更吃系統記憶體與資料搬移時間。想進一步理解 GGUF 與量化的角色,也可以對照站內的本地模型推理框架比較 。
GGUF 檔案大小不等於最低顯存需求,但能直接看出為什麼 8GB 路線必須依賴卸載與系統記憶體
我的硬體建議很簡單。,GB 顯存可以從 Q4 或經驗證的低顯存工作流開始,系統記憶體最好準備 32GB 以上,12GB 到 16GB 顯存會比較有調整空間。若要使用 BF16、較高解析度、長片段或多階段放大,32GB 以上顯存才接近官方設定,實際速度還會受 GPU 架構、RAM、磁碟、解析度、影格數與節點版本影響。
最省事的安裝方法是官方模板
第一次安裝不要急著手動搬十幾個檔案,先把 ComfyUI 更新到支援 LTX 2.3 的版本,再用模板庫建立一條能正常執行的基準工作流,這和我整理 Ideogram 4 的 ComfyUI 本機部署 時採用的思路一樣,先跑通官方基線,再加入量化與自訂節點。
開啟 ComfyUI Desktop 或現有 ComfyUI
完成程式與前端更新後重新啟動
進入 Templates 並切換到 Video
搜尋 LTX-2.3
先安裝 Image to Video 與 Text to Video 模板
按下 Download all 取得必要模型
重新啟動後先用低解析度與少量影格測試
官方建議先用 480×720 與 41 到 81 個影格確認流程,工作流穩定後,再提高解析度、片長與品質。這一步看起來保守,卻能很快分辨問題來自模型、節點、顯存,還是提示詞。
手動安裝時,模型應該放在哪裡
ComfyUI Desktop、Portable 與自行安裝版的根目錄可能不同,最穩的方法是從 ComfyUI 介面打開模型資料夾,再依下面的相對路徑放置。不要直接照抄別人的 Windows 使用者名稱。
檔案類型 建議路徑 用途 官方主模型 models/checkpoints/LTX-Video BF16、Distilled 或官方檢查點 社群 GGUF models/unet 交給 GGUF Loader 載入 文字編碼器 models/text_encoders Gemma 3 與 LTX 文字投影 視訊與音訊 VAE models/vae 解碼影像、聲音與預覽 LTX 2.3 LoRA models/loras/LTX-2.3 Distilled、風格或控制能力
原始權重可從 LTX 2.3 Hugging Face 取得。官方推理程式與訓練工具位於 Lightricks LTX-2 GitHub ,ComfyUI 節點與範例工作流則在 ComfyUI-LTXVideo 。
匯入工作流後出現紅色節點怎麼辦
紅色節點通常不是模型壞掉,而是工作流引用了本機尚未安裝的自訂節點。先在錯誤視窗選擇 Install Missing Custom Nodes,完成後按 Apply Changes 並重新啟動,若仍缺少 Fast Groups Bypasser 類節點,可在 Manager 搜尋並安裝 rgthree-comfy 。
GGUF 權重還需要 ComfyUI-GGUF 。安裝後重新啟動,在畫布空白處搜尋 GGUF Loader,把原本模型載入器的輸出改接到工作流的 model 輸入,再重新整理節點並選擇 Q4 或 Q5 檔案。
一個可以直接改寫的繁中提示詞
LTX 2.3 的提示詞不要只寫「讓照片動起來」。把人物動作、對白、聲音、鏡頭、畫質與禁止項目分開,模型比較容易理解時間順序與同步關係。
場景與動作
一名年輕女子站在安靜的室內,先看向鏡頭,再輕輕吸一口氣,以略帶緊張但自然的神情說話。嘴唇清楚說出指定的中文台詞,嘴型與發音準確同步。
聲音
自然的年輕華語女聲,語氣柔和、真實、略帶緊張,像日常交談,不要誇張。保留輕微呼吸聲與安靜室內環境音,不要配樂。
鏡頭
鏡頭緩慢推近臉部,只有很輕微的手持感。淺景深,焦點穩定,自然室內光線。
畫面品質
寫實電影感,皮膚紋理自然,眼神與微表情細膩,髮絲運動合理,動作流暢,人物身份保持一致。
避免項目
不要字幕,不要畫面文字,不要額外人物,不要旁白,不要機械聲,不要誇張表情,不要臉部變形,不要嘴唇變形,不要突然移動鏡頭。
實際使用時,把第一段換成你的角色、場景、動作與台詞即可。先固定一個鏡頭與一個主要動作,再逐步增加人物、轉場與複雜聲場。一次要求太多事件,往往比模型能力不足更容易造成身份漂移。
中文對白可用,但字幕最好留給後製
實測裡最值得記下來的缺點,是中文畫面文字仍可能出現亂碼,即使官方表示文字渲染已改善,這不代表長句中文字幕已經可靠,若提示詞要求中文對白,模型有時還會自行生成錯誤字幕。
提示詞明確加入「不要字幕、不要畫面文字」
先生成乾淨畫面與聲音
輸出後再用剪輯軟體或字幕工具加入繁中字幕
若聲音品質不穩,可把畫面生成與語音生成拆成兩條工作流
需要更細的角色音色控制時,可以搭配Qwen3-TTS 音色設計工作流 ,讓 LTX 2.3 專注畫面,再由語音模型與後製負責台詞品質,這通常比強迫單一模型同時把中文聲音與中文字都做到完美更務實。
本地還是雲端,差別不只在費用
本地工作流的優點是素材不必上傳第三方、模型與節點可自行調整,而且安裝完成後沒有逐秒 API 費用,缺點是模型檔很大,節點版本容易衝突,還要自己處理顯存與輸出速度。若你比較在意快速試模板與交付,也可以對照RunningHub 的雲端 ComfyUI 工作流 ,再決定控制權與便利性哪個重要。
解除限制版本不是品質保證
社群常用「無審查」或「解除限制」描述修改版權重。這只代表輸入限制可能不同,不代表畫質、授權、安全性或商用條件比官方版本更好。下載前要確認模型來源、授權條款與檔案雜湊,人物照片與聲音也必須取得同意。
尤其是換臉、移除人物、替換台詞與生成擬真人物時,更要避免冒用身份、未經同意的私密內容與誤導性成品。LTX 官方也有商業授權條件,企業使用前應直接閱讀最新授權,而不是只看模型能不能下載。
下載與參考資源
我的結論
如果目標是直式角色短片、圖生影片、帶環境音的短場景,LTX 2.3 很值得測,若目標是穩定中文字、長篇敘事或大量商業輸出,仍要把字幕、語音、剪輯與品質檢查拆成獨立步驟。模型負責生成,工作流負責把結果變成可以交付的作品。
FAQ
LTX 2.3 真的能在 8GB 顯卡執行嗎
可以,但通常要使用 GGUF 量化權重、CPU offload 與足夠的系統記憶體。8GB 指的是可嘗試的顯存門檻,不代表完整模型全放在 GPU,也不保證固定生成速度。
新手應該選 BF16、FP8 還是 GGUF
先用官方 Distilled 或 FP8 模板確認工作流。顯存不足再改用 GGUF。BF16 適合硬體充足並且重視品質的人,GGUF 適合願意接受卸載、速度與相容性取捨的低顯存使用者。
為什麼匯入工作流後有紅色節點
多半是缺少自訂節點或節點版本太舊。先執行 Install Missing Custom Nodes,再更新 ComfyUI、ComfyUI-LTXVideo、rgthree-comfy 與 ComfyUI-GGUF,完成後重新啟動。
中文對白為什麼會出現亂碼字幕
模型可能把對白理解成需要同步生成的畫面文字,而中文長句仍不穩定。提示詞加入不要字幕與不要畫面文字,先生成乾淨影音,再於後製加入繁中字幕最可靠。
LTX 2.3 可以離線使用嗎
模型、節點與依賴下載完成後可以在本機執行。首次安裝、更新模型或補齊節點仍需要網路,並且要預留足夠磁碟空間。
by Rain Chu | 8 月 19, 2026 | AI , GGUF , QWEN , 模型
Qwen3.8-27B 把文字、圖片、影片、程式設計與 Agent 工作流放進同一個稠密模型,對想把 AI 留在本機的人來說,這是一個能力和硬體成本相對平衡的新選擇。
16GB 顯卡不要直接選 Q4_K_M,因為 15.9 GiB 只是主模型檔案,還沒有算約 0.86 GiB 的視覺投影模型、KV Cache 與執行環境。比較實際的選擇是 Q3_K_M 或 UD-Q3_K_XL,再從 8K 上下文開始測試。8GB 顯卡雖然可以用極低位元量化搭配系統記憶體卸載,但不等於 27B 多模態模型能完整放進 8GB 顯示記憶體。
Qwen3.8-27B 是什麼
Qwen3.8-27B 官方模型 採用 Apache 2.0 授權,是一個 27B 參數的稠密視覺語言模型,它不是只會聊天的純文字模型,而是原生理解圖片與影片,也把程式設計、專業工作、研究和長時間 Agent 任務列為主要能力。
27B 稠密模型,64 層,Hidden Dimension 為 5120
原生支援圖片與影片理解
原生上下文長度 262,144 tokens,可透過 YaRN 延伸到 1,000,000 tokens
支援思考與非思考模式,也能用 reasoning_effort 調整推理深度
訓練時加入多步 MTP,執行環境支援時可用於推測解碼
如果你正在比較本地模型,建議先看站內的Qwen 3.6 的 27B、35B、MXFP8 與 NVFP4 比較 ,Qwen3.8-27B 延續 27B 稠密模型的定位,但多模態、Agent 執行和思考控制都更完整。
MTP 和 noMTP 差在哪裡
MTP 是 Multi-Token Prediction,一般自迴歸模型每次產生一個 token,MTP 會另外預測後續多個候選 token,再由主模型驗證,推理框架支援推測解碼時,可以減少逐 token 等待的成本,提升生成速度。
Qwen3.8-27B 的官方架構包含 MTP,Unsloth 的 Qwen3.8 指南 也提供 MTP 量化版本,noMTP 通常是社群為了相容性或降低額外負擔而移除 MTP 預測頭的版本,你的 llama.cpp 太舊、載入失敗,或記憶體非常緊時,可以把 noMTP 當作相容性選項。新版推理環境能正常使用 MTP 時,則優先保留。
16GB 顯卡該下載哪一個 GGUF
可用記憶體 建議量化 主模型大小 實際建議 8GB UD-IQ2_XXS 約 8.4 GiB 仍需系統記憶體卸載,不建議當作完整多模態體驗 12GB UD-IQ2_M 或 Q3_K_S 約 9.6 到 11.7 GiB 使用短上下文,接受較明顯的量化損失 16GB Q3_K_M 或 UD-Q3_K_XL 約 12.9 或 12.5 GiB 最實際的平衡,先用 8K 上下文 24GB Q4_K_M 或 Q5_K_M 約 15.9 或 18.5 GiB 能保留較好的品質,也有空間給視覺與 KV Cache 32GB Q6_K 或 Q8_0 約 21.3 或 27.1 GiB 適合重視品質與較長上下文的使用者
檔案大小依 Unsloth Hugging Face 儲存庫計算,實際記憶體還要加上視覺投影模型、KV Cache 與執行環境
主模型從 8.4 GiB 的 2-bit 到 27.1 GiB 的 Q8_0,數字不包含額外執行記憶體
Q4_K_M 的檔案約 15.9 GiB,看起來很接近 16GB,但視覺功能還需要 mmproj-F16.gguf,檔案約 0.86 GiB,再加上 KV Cache 後,16GB 顯卡通常沒有足夠餘裕。若只跑文字、上下文很短,而且願意部分卸載到系統記憶體,IQ4_XS 可能可以啟動,但這不是我會給一般使用者的預設建議。
量化位元越低,檔案越小,但指令遵循、長文本穩定性、程式正確率和視覺判斷都可能下降。16GB 使用者如果重視穩定性,有時候選較小參數模型的 4-bit 或 8-bit,會比硬塞 27B 的 2-bit 更實用。
用 llama.cpp 在本機啟動
個人電腦要跑 GGUF,llama.cpp 仍然是很直接的底座。Windows 使用者可以從 llama.cpp Releases 下載對應版本,NVIDIA 顯卡選 CUDA,AMD 顯卡可用 Vulkan,沒有獨立顯卡則選 CPU 版本,框架定位和差異可以延伸閱讀vLLM、SGLang、llama.cpp、MLX 與 Ollama 比較 。
一 下載主模型與視覺投影模型
pip install -U "huggingface_hub[cli]"
hf download unsloth/Qwen3.8-27B-GGUF \
Qwen3.8-27B-Q3_K_M.gguf \
mmproj-F16.gguf \
--local-dir Qwen3.8-27B-GGUF
24GB 顯卡可以把 Q3_K_M 換成 Q4_K_M。只處理文字時可以先不載入 mmproj,等基本對話穩定後再加入視覺功能。
二 啟動 OpenAI 相容端點
llama-server \
--model Qwen3.8-27B-GGUF/Qwen3.8-27B-Q3_K_M.gguf \
--mmproj Qwen3.8-27B-GGUF/mmproj-F16.gguf \
--host 127.0.0.1 \
--port 8080 \
--ctx-size 8192 \
--n-gpu-layers 99 \
--jinja \
--chat-template-kwargs '{"reasoning_effort":"medium"}'
Windows 請把執行檔改成 llama-server.exe。若出現記憶體不足,先把上下文從 8192 降到 4096,再考慮換更小的量化。不要一開始就把 262K 全開,長上下文的 KV Cache 會快速增加記憶體需求。
三 測試 API
curl http://127.0.0.1:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"Qwen3.8-27B","messages":[{"role":"user","content":"請用繁體中文列出三個本地部署注意事項"}]}'
能收到 JSON 回應,就代表本地端點已經可以交給其他工具使用,想把開發環境完全留在本機,也可以參考Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本環境 。
接到 Hermes Agent
llama-server 啟動後,可以在 Hermes Agent 的模型提供方加入本地自訂端點,Base URL 填入 http://127.0.0.1:8080/v1,如果介面要求 API Key,可以填一個只供本機識別的非空字串,模型清單出現 Qwen3.8-27B 後,就能把它用在網站製作、檔案處理、程式生成與瀏覽器檢查等 Agent 任務。
本地模型接 Agent 的價值在於資料不用先送到外部 API,也能降低大量反覆呼叫的成本。不過模型一旦拿到終端機、瀏覽器和檔案權限,風險也會跟著放大。Hermes 的代理層與 LINE 整合可以延伸閱讀Hermes Proxy 與 Hermes Agent 支援 LINE 。
程式、視覺與 Agent 能力怎麼看
一個單檔 HTML 飛行遊戲可以同時產生畫面、操作、儀表與聲音,代表 27B 模型已經能完成有一定複雜度的前端原型,圖片計數測試也能辨識出 25 根筷子,並區分 6 根彩色與 19 根銀色,接到 Agent 後,還能建立帶搜尋、排序與模型卡片的網站,再開啟瀏覽器檢查介面。
這些結果適合當作能力檢查,不適合直接當成通用 benchmark,單一提示、單一圖片與單一硬體都可能讓結果偏高或偏低。真正要採用前,應該用自己的程式庫、文件、圖片和 Agent 權限做一組固定測試,記錄成功率、速度與記憶體峰值。
無審查版本不是官方安全模式
所謂無審查或 Uncensored 版本通常是社群修改、微調或去除拒答傾向的衍生模型,不是 Qwen 官方提供的安全開關,它比較少拒絕,不代表答案更正確,也不代表可以放心交給有系統權限的 Agent。
先在沒有正式帳密與重要檔案的環境測試
工具採用允許清單,不要直接給完整終端機與管理員權限
寫檔、執行命令、付款與對外發布都要保留人工確認
本地 API 預設只綁定 127.0.0.1,不要直接暴露到網際網路
保存工具呼叫紀錄,發生異常時能回溯
如果用途只是寫作或私人角色扮演,可以把衍生模型放在沒有工具權限的聊天環境。需要操作檔案、瀏覽器或伺服器時,優先使用官方模型並限制權限,通常會更穩妥。
我的選擇建議
16GB 顯卡從 Q3_K_M、8K 上下文和官方版本開始。24GB 顯卡可選 Q4_K_M,並保留足夠空間給 mmproj 與 KV Cache。50 系列 Blackwell 顯卡如果要做正式服務,可以研究 NVFP4 與 vLLM。一般個人使用者則先用 GGUF 和 llama.cpp,把模型穩定跑起來,再決定是否需要 Hermes Agent、長上下文或 MTP。
Qwen3.8-27B 的重點不是單純追求更大模型,而是把多模態、程式能力和 Agent 執行放進個人可負擔的硬體範圍。選對量化、控制上下文、限制工具權限,才是本地部署真正能長期使用的關鍵。
FAQ
MTP 一定比較快嗎
只有推理框架正確支援推測解碼時才會發揮效果。框架版本、硬體與批次大小都會影響實際速度,不能只看檔名判斷。
可以用 Ollama 或 LM Studio 嗎
可以,只要版本已支援 Qwen3.8 架構與對應 GGUF。想控制 MTP、mmproj、KV Cache 與細部參數時,llama.cpp 通常更透明。
本地模型接 Hermes Agent 安全嗎
模型資料可以留在本機,但工具權限仍然需要管理。使用 127.0.0.1、工具允許清單、人工確認與執行紀錄,可以大幅降低風險。
參考資料
by Rain Chu | 6 月 13, 2026 | Agent , AI , GGUF , Hermes , OpenClaw
原本我在 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
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 上,實測文字生成速度約為:
測試圖片分析 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 的記憶體策略
我使用:
意思是:
可以讓 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
儲存後離開:
WantedBy=multi-user.target 讓服務可以隨一般多使用者開機流程啟動;Restart=on-failure 會在程式異常退出時重新啟動服務。
為什麼需要 RequiresMountsFor
你的模型與程式都放在:
如果外接 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
正常情況應該看到:
以及:
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
離開即時日誌:
五、測試 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
七、確認開機後是否真的自動啟動
重新開機:
重新 SSH 登入後執行:
systemctl status llama-router --no-pager
確認 Port:
測試模型清單:
curl -s http://127.0.0.1:8080/models | \ python3 -m json.tool
八、改用 models.ini
準備讓不同模型有不同 Context Length:
Holo 35B:8192Hermes 預設 Tool Calling 模型:65536
這種情況建議不要在服務中使用:
而是改用:
假設設定檔位於:
/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
十、限制只允許內網連線
目前使用:
代表區域網路內其他裝置可以存取 API。Router Mode 目前仍屬於實驗性功能;llama.cpp 啟動日誌也提醒,不建議直接暴露在不受信任的網路環境。
假設區域網路是:
可以設定 UFW:
sudo ufw allow from 192.168.0.0/24 \ to any port 8080 proto tcp
查看規則:
不要直接把 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
近期留言