by Rain Chu | 9 月 20, 2026 | Agent, AI
當工作需要反覆讀取私人文件、呼叫工具,或同時執行多個任務,模型之外的資料流向、硬體安排與執行框架,也會影響實際成果。
DSH Privacy Router、NVIDIA PAIR、EXO 與 Perplexity Portable Computer,分別處理隱私分流、區網排程、模型分散運算與完整 Agent 工作流程。
本機 AI 先看三件事:資料、容量與工作流程
第一件事是資料能不能外傳。即使雲端模型能力更強,有些內容仍應留在自己的設備或信任的內部網路。
第二件事是硬體能不能容納模型,以及能否在可接受的時間內完成工作。
第三件事是模型以外的操作,像讀檔、搜尋、驗證與產出文件,有沒有完整流程。
這些問題需要分別處理。推論引擎負責執行模型,Agent 框架負責組織工具與任務,路由器則決定請求送到哪裡。
還不熟悉這些層次,可以先看 本地大模型推論框架比較,再判斷自己缺的是哪一層。
DSH Privacy Router:先判斷哪些內容能送雲端
DSH Privacy Router 是 DeepSeek Harness 的 Host 端插件。
它先用本機規則與模型檢查文字,分類為 public、sensitive 或 unknown。
只有通過公開分類的請求才送雲端,敏感或不確定的內容留在本機。
這是隱私導向的分流,不是單純把困難問題全部轉給大模型。
預設雲端上下文只包含本輪通過檢查的純文字、固定系統提示與空工具清單。
專案文件說明,私有對話與本機工具結果不會直接附帶過去,雲端回答則直接串流回目前對話,不由本機模型再次改寫,開啟特定相容事件功能後,才可納入先前已核准的雲端對話。
公開程式可看到兩個關鍵控制:雲端分支只在分類結果為 public 時啟用,真正送出時會重新組合訊息,並把工具列表設為空。這比只在提示詞寫「不要洩漏資料」多了程式層的限制。不過,這仍不代表整個應用的所有網路流量都受到同一個插件管理。核對版本見 DSH 路由程式。
導入前要知道,這個公開儲存庫不包含展示用 Web UI 或 DSH 原始碼補丁。
README 的介面展示屬於構想,不能把安裝插件理解成會立即得到完整視覺介面。
先依文件設定可信任的本機 Provider,再確認實際連到的服務確實位於可信任環境。
自動發現本機算力,不等於自動信任任何設備
配套的 Local AI Discovery Server 用 mDNS/DNS-SD 宣告區域網路中的 OpenAI 相容 API,提供主機、連接埠、模型清單位置與認證需求等資訊。
它負責讓服務被找到,本身不執行模型,也不是 API 代理。DSH 端仍需要對應的發現整合。
發現服務與信任服務是不同步驟,在家中看得到的端點,不代表公司文件就適合送過去,更不用說共享空間的陌生設備。
評估時應確認設備由誰管理、是否使用認證,以及請求最後送往哪個端點。服務名稱帶有「local」,不能取代這些確認。
NVIDIA PAIR:把獨立請求分配給區網內的電腦
NVIDIA Personal AI Router,也就是 PAIR 目前以測試版提供本機推論路由,支援相容的 Windows、Linux、macOS 系統,搭配 Ollama 與 LM Studio。它的目標是讓應用使用單一入口,把多個推論請求分配給可用設備。
PAIR 不會把多台電腦的顯示記憶體合成一個大空間,也不會把同一個推論請求拆到多台執行。每個請求會交給一個符合條件的節點,該節點負責執行到結束。
當多個 Agent 同時提出獨立請求時,其他設備才有機會分擔排隊壓力。
官方技術文件說明,排程會考慮節點是否在線、推論引擎是否可用、是否有指定模型,以及目前負載。節點經過配對後,通訊使用相互 TLS 驗證與加密。
這解決的是信任節點之間的推論傳輸,不能延伸成 Agent 使用任何搜尋或外部工具都不會外傳資料。詳見 NVIDIA PAIR 技術說明。
若工作主要是一個接著一個的長推論,或只有一台設備裝了需要的模型,多加節點的效益可能有限。評估時要看整個任務完成時間,以及 Jobs 紀錄是否真的顯示不同節點處理請求,而不只看畫面上出現幾個 Agent。
EXO:把模型拆到多台設備,與 PAIR 的用途不同
EXO 的核心包含模型分片與分散推論,會考慮裝置資源及網路拓樸,讓單一設備放不下的模型有機會跨設備執行。README 介紹了 MLX、張量平行與 Thunderbolt RDMA 等能力,這和 PAIR 分派完整請求的做法不同。
分散推論需要設備交換資料,速度取決於模型、切分方式與實際互連。
能容納更大模型,不代表每次回答一定更快,也不能直接把各台硬體的標示效能相加,想理解雙機部署的取捨,可延伸閱讀 雙機本地模型部署與實測整理,並分開看容量與速度。
截至 2026 年 9 月 14 日核對,EXO 的 平台支援文件 把 Apple Silicon macOS 列為已測試與維護的主要平台,Linux CUDA 與 DGX Spark 則仍列在規劃區。
Portable Computer:把本機模型接成完整 Agent
Perplexity Portable Computer 的定位是本機優先的 Agent 軟體,不是一款 Perplexity 品牌硬體。
官方發表資料以 DGX Spark 為首波設備,將模型、執行框架與工作紀錄放在本機,必要時再經授權使用搜尋、連接器或雲端模型。
平台支援與訂閱資格會更新,安裝前應重新確認產品入口。
比起單純啟動模型,它更重視框架如何配合本機模型的能力:
縮小核心工具集合、按需載入 Skills、整理過長上下文,以及加入結果驗證。官方研究也說明,工具執行受作業系統層的沙箱限制,沙箱不可用時不退回無隔離執行。參考 Perplexity 的本機優先 Agent 研究。
雲端顧問只接收核准的上下文並回傳文字建議,沒有直接操作本機檔案與工具的權限。是否開啟顧問,以及採手動或自動核准,由使用者設定,「本機優先」仍須搭配實際的連外與核准政策來理解。
中文導讀也可參考 AI 郵報 Portable Computer 整理。其中的硬體需求、測試分數與上市資訊,應回到對應官方文件與測試條件核對,不宜直接推論成所有任務的表現。
四個方案怎麼分?先對照自己要解的問題
| 方案 | 主要處理的問題 | 不能直接推論的能力 |
|---|
| DSH Privacy Router | 判斷文字是否可送雲端並限制上下文 | 不能保證分類永遠正確或涵蓋所有資料出口 |
| NVIDIA PAIR | 把獨立推論請求分配到可用的區網節點 | 不合併顯示記憶體,也不切分單一推論請求 |
| EXO | 跨設備切分模型與分散推論 | 不代表任意平台組合都已支援或一定加速 |
| Portable Computer | 整合本機模型、工具、沙箱與授權連外 | 本機優先不代表開啟外部服務後仍完全離線 |
這張表依前述官方文件整理的是功能範圍,不是效能排名。若想組合使用,還要核對 API、模型格式、端點與執行框架是否相容,不能假設名稱都和本機 AI 有關就能直接串接。
隱私真正難的地方,是內容看起來不敏感
沒有姓名、電話或金鑰,不代表內容可以公開。
例如尚未發表的產品構想、內部定價方法或獨特研究策略,就算去掉身分資訊,仍可能包含不應外傳的價值,這是自動隱私分類需要面對的限制,不能只用是否偵測到個資判斷。
DSH 用規則加模型檢查,Portable Computer 也描述了分類器與核准機制,但分類器仍可能漏判。
對不可外傳的工作,應有明確的本機限定設定,以及實際阻止連外的權限或網路政策。對允許求助雲端的工作,則要看清楚送出的片段、歷史上下文與工具結果。
驗收可以從幾種情境開始:一般公開問題、含機密的文件、依賴前文的「繼續」、分類失敗,以及雲端要求呼叫工具。
確認它們分別送去哪裡、留下什麼紀錄,並能追查答案由哪個模型產生。不要為了觀察系統又把完整機密複製進不受控的日誌。
開始之前,先用現有設備跑完一個真實任務
先挑一個可驗證的小工作,例如整理不含機密的測試文件,用現有設備與合適模型完成一次。若問題是模型服務與應用怎麼接,可以先參考 LibreChat 與 Ollama 的串接方式,等單機流程穩定,再處理分流與多機。
接著辨認瓶頸。獨立請求很多、都擠在同一台,才評估 PAIR。模型放不下,才研究 EXO 等分散推論路線。
需要選擇哪些內容送雲端,再檢查 DSH 的分流設計。想降低工具、沙箱與任務流程的整合工作,則可評估 Portable Computer。
本機推論能減少按量 API 費用,但仍有硬體、電力、維護與等待時間。選擇性使用雲端,也可能產生額外用量。
先量出自己的任務品質與完成時間,再決定是否擴充設備,會比從硬體規格開始更容易做出合適選擇。
本機 AI 路由常見問題
DSH Privacy Router 會把困難問題自動交給雲端嗎?
它主要依隱私分類分流,只有判定為 public 的請求才走雲端。敏感、不確定或無法分類的內容留在本機,不能視為單純依難度切換模型。
NVIDIA PAIR 能把多台電腦合成一張大顯卡嗎?
不能。PAIR 將獨立推論請求分派給符合條件的單一節點,不合併顯示記憶體,也不把一個請求切到多台電腦執行。
EXO 和 PAIR 差在哪裡?
EXO 包含跨設備模型分片與分散推論能力,PAIR 則分派完整的獨立請求。選擇前要先分清楚瓶頸是模型容量,還是同時有太多請求排隊。
Portable Computer 等於完全離線嗎?
不一定。核心工作預設在本機,搜尋、連接器與雲端顧問則可能連外。是否外傳資料,取決於開啟的功能、授權設定與實際送出的上下文。
by Rain Chu | 9 月 17, 2026 | AI, 模型
Ornith 1.5 把本地 AI 的一個老問題攤得很清楚:每秒吐出多少 token,和最後有沒有把工作做完,是兩回事,35B-A3B 版本靠 MoE 架構降低每個 token 的運算量,在公開實測中展現速度優勢,也出現思考太久、額度用完卻沒交出程式碼的案例。
如果你想找一顆接在本地程式代理後面的模型,Ornith 1.5 35B 值得列入測試,評估時要一起看量化格式、記憶體餘裕、工具相容性與任務完成率,下面先拆開「自我改進」的意思,再看官方評分、兩組不同硬體的實測,以及實際上手順序。
Ornith 1.5 更新了什麼?先分清楚三種模型
Ornith 1.5 家族包含 9B Dense、35B MoE 與 397B MoE。手機部署的主角是 9B-Mobile 量化版本,與旗艦商用模型比較的宣傳則主要圍繞 397B。本文聚焦中間的 35B-A3B,不能把另外兩款的部署條件或成績直接套過來。版本資訊可從 官方模型集合查看。
如果你看過 Ornith 1.0 的自我拆解任務方式,這次最主要的延伸是把「生成訓練任務」也納入改善流程。
自我改進發生在訓練期間,下載後不會自動改寫權重
依照 Ornith 官方技術說明,模型在訓練中依序扮演三個角色:先根據程式庫與過去解題紀錄出題,再安排工具、指令與拆解方法,最後嘗試解題。結果回饋到強化學習流程,讓題目、執行安排與解法一起改善。
出題也有條件:題目要能驗證、難度合適,而且不能一直重複,官方把目標成功率設在約 20%,讓模型練習有挑戰但仍可能解出的題目。這個百分比是訓練課程的設計目標,不是產品的答題正確率。
可以把它想成練習寫程式時,不只修答案,也回頭調整練習題與測試方式。
下載回來的則是訓練後的模型權重,日常對話、保存記憶或反覆提示,不代表權重正在持續更新。
AlphaLab 對自我改進邊界的分析也提醒,環境與評分規則仍由人設計,分數上升還要確認是否真的學會解題。
35B-A3B 的 A3B,不是記憶體只要放下 3B
MoE 每次只選部分專家參與計算,但其他專家的權重仍要有地方存放。活躍參數主要影響每一步的運算量,總權重與快取才是估算記憶體的起點。官方 35B 模型頁列出約 3B 活躍參數,BF16 權重約 70GB,原生上下文為 262,144 token,模型規格與啟動範例可作為設定依據。
以目前 官方 GGUF 檔案清單為例,Q4_K_M 單一模型檔約 21.71GB,換算約 20.22GiB,這還沒加上推論引擎、上下文快取或視覺投影檔,因此「有 24GB 顯示記憶體」只能作為測試起點,不能直接承諾長上下文與多個並行任務都放得下。
12GB 或 16GB 顯示卡若想跑這個 Q4 檔,通常還得規劃部分權重放在系統記憶體,或改用其他量化版本,能載入模型、能順利對話、能在長任務中維持速度,應分開驗收。Mac 使用統一記憶體,也要預留系統空間,可搭配 本地 AI 的記憶體與頻寬選擇理解這個差別。
官方評分顯示程式能力進步,但要連測試框架一起看
以下是官方模型卡中同尺寸模型的部分成績。
Ornith 1.5 的結果為團隊自報的五次執行平均,並非本文重跑,也不等於所有電腦都會得到相同結果。
| 測試 | Ornith 1.5 35B | Ornith 1.0 35B | Qwen3.6 35B |
|---|
| Terminal-Bench 2.1/Terminus-2 | 67.8 | 64.2 | 52.5 |
| SWE-bench Verified | 79.0 | 75.6 | 73.4 |
| SWE-bench Pro | 59.6 | 50.4 | 49.5 |
資料來源:Ornith 35B 官方模型卡。各項測試使用各自的評測設定,不能相加成通用能力分數。
Terminal-Bench 的上述結果使用 Terminus-2,SWE-bench 使用 OpenHands。工具、提示、可用時間與上下文都會影響代理表現。「追平 Claude Opus」應限於官方列出的特定 397B 比較,無法據此宣稱 35B 全面取代商用模型。
對上 Qwen3.8 27B:生成得快,整個任務卻可能更慢
DIY Smart Code 的 Benchy 本地測試使用 RX 7900 XTX 24GB、Ryzen 9、64GB 系統記憶體與 Ollama,比較兩款 Q4 模型。Ornith 測試標示 32K 上下文。這是作者自建測試集的一組案例,量化檔案與測試工具的細節限制了外部重現,不能當成通用排名。
| 同一組 Benchy 案例 | Ornith 1.5 35B | Qwen3.8 27B |
|---|
| 通過項目 | 18/21 | 20/21 |
| 生成速度 | 約 74 tok/s | 約 58 tok/s |
| 提示處理速度 | 約 850 tok/s | 約 240 tok/s |
| 整組耗時 | 約 26 分鐘 | 約 17 分鐘 |
資料來源:DIY Smart Code,2026 年 8 月 22 日公開案例。數值依逐字稿約數整理,並非本文實測。
最有參考價值的是 DAG 非同步任務排程題:Ornith 花了約 18,000 個思考 token,耗盡輸出額度後沒有交出最終 Python 程式,Qwen 則完成程式並通過該題檢查。所以每秒輸出較快,仍可能因為思考與重試較多,拖長整個工作的時間。
這也不能反推成所有 MoE 都不擅長推理,或 Qwen 永遠比較穩,模型、量化、引擎與題型都不同,架構本身不能單獨解釋全部差異,要比較自己的程式任務,可參考 Qwen3.8 27B 本地部署教學,固定測試條件再重跑。
雙 GB10 的 NVFP4 實測:減少搬運,也能讓解碼加速
CyberQ 的雙 GB10 實測是在另一套硬體與 vLLM 環境中比較 BF16 與 NVFP4。它固定解碼 800 token,暖機後取三次量測中位數,因此較適合觀察格式差異,不適合直接和前面的 Ollama 成績排高低。
| 雙 GB10/TP=2 | BF16 | NVFP4 |
|---|
| 解碼吞吐量 | 48.41 tok/s | 101.86 tok/s |
| 12,001 token 提示處理 | 2,767 tok/s | 4,141 tok/s |
解碼約為 2.10 倍。這是特定硬體與引擎的量測結果。
該測試的 NVFP4 路徑先以低位元格式搬運權重,再反量化計算。當瓶頸是記憶體頻寬,減少搬運量就可能抵銷反量化成本。這是推論效率改善,不能解讀成硬體原生算力增加。
品質抽查中,兩種格式在 AIME 2026 都完成並答對 23/30 題,各有 7 題被輸出上限截斷。兩邊共同完成的 22 題答案一致,但答案一致不代表逐 token 的思考過程相同,也不能延伸成量化完全不損失品質。
本地部署怎麼開始?先讓短任務與工具呼叫跑通
先選權重格式與執行工具。桌面試用可從 GGUF 與 Ollama、llama.cpp 相容工具開始,伺服器則參考官方 vLLM 或 SGLang 範例。還不確定差別,可先看 本地大模型推論框架比較。
下載時認明 原始模型庫、官方 GGUF與 官方 NVFP4。另有 AtomicChat 的 GGUF 轉換版本可比較,請記錄實際檔名與量化等級,同樣寫 Q4 不表示所有檔案與執行結果完全相同。
測試時先縮短上下文、一次處理一個請求,確認記憶體與基本輸出正常,再逐步拉長。官方雖提供延伸到約 1M token 的設定,卻也提醒長上下文縮放可能影響一般長度的品質,不必第一次啟動就把視窗開到最大。
接代理前,再測試工具名稱、參數、工具結果回傳,以及模型能否繼續下一步。模型能輸出 tool_calls,只代表這段格式可用,MCP 伺服器還需要由代理程式接上。純聊天成功,不能代替完整工具流程驗收。
最後設定整個任務的時間、輸出與重試上限,並檢查所用引擎是否支援獨立思考額度。只縮小總輸出上限,可能更早截斷最終答案。日常試用可先用幾個有明確驗收條件的小任務,比較完成時間、人工修正量與失敗原因,再決定是否放入長時間自動化工作。
授權與手機部署,哪些說法還要保留?
T客邦的發布報導有助於了解系列定位,但授權敘述與官方 metadata 不一致。
本文以官方模型頁標示的 MIT 為準。
同樣地,9B-Mobile 支援行動裝置的宣稱,不能保證每一款手機都有足夠可用記憶體、支援對應模型格式,或能維持長上下文。先確認使用的 App、量化檔與裝置條件,比直接照搬桌面版的速度數字有用。
常見問題
Ornith 1.5 35B-A3B 是只有 3B 參數嗎?
不是。它是 35B 級 MoE 模型,每個 token 約啟用 3B 參數。儲存與載入仍需考慮完整權重,以及快取和引擎額外用量。
Ornith 1.5 放在本地使用會自己越來越聰明嗎?
官方的自我改進是訓練流程。下載後一般執行推論,不會因為聊天次數增加就自動更新模型權重。
24GB 顯示卡一定能跑 35B 的完整上下文嗎?
不能保證。官方 Q4_K_M 檔約 20.22GiB,還需預留引擎與快取空間。應從短上下文實測,再逐步調整。
Ornith 1.5 和 Qwen3.8 27B 該選哪個?
先用自己的任務比較。公開 Benchy 案例中 Ornith 生成較快,Qwen 通過較多項目。這組結果只適用於該測試條件。
這是美國團隊所推出的模型
Ornith 支援工具呼叫,就能直接連 MCP 嗎?
還需要代理程式與 MCP 連接層。應測試參數格式、工具執行與結果回傳的整個流程。
先看能否完成你的工作,再看分數有多高
Ornith 1.5 值得研究的地方,是它把練習題、工具安排與解法放進同一條訓練流程。而對本地使用者來說,35B-A3B 的實際價值仍要靠任務驗收:能不能在現有記憶體內跑穩、工具是否接得上,以及等待之後有沒有拿到可用成果。
先挑幾個你每週真的會做的工作,讓 Ornith 與現有模型各跑一次。保留設定、耗時與失敗紀錄,往往比看一張總排名更容易做出選擇。若想了解前述測試工具的設計,可再看 Benchy 測試工具建置說明。
by Rain Chu | 9 月 11, 2026 | AI, skills
fal.ai 是一個生成式媒體 API 平台,它把多家圖片、影片、音訊與 3D 模型放在同一套介面下,開發者不必為每一家服務分別串接帳號與 SDK。再把操作規則包成 Codex Skill,就能讓 Codex 根據任務選模型、整理提示詞、上傳參考圖、送出工作、追蹤結果,最後把檔案下載到專案資料夾。
這套方式真正省下的是固定訂閱與切換工具的時間,不是讓付費模型突然變成免費。fal.ai 採預付點數與按量計費,圖片可能依張數或百萬像素計價,影片常依秒數、解析度或單次輸出計價。對偶爾生成、需要跨模型比較的人很有彈性,長期大量生成前則一定要先算成本。
先講結論,fal.ai 適合什麼人
| 做法 | 適合情況 | 優點 | 要注意什麼 |
|---|
| fal.ai Playground | 偶爾做一兩張圖或測模型 | 不用先寫程式,直接調參數 | 重複任務仍要手動操作 |
| fal.ai 加 Codex Skill | 固定工作流、批次產出、專案整合 | 能保存規則、命名、目錄與成本檢查 | 需要 API 點數與基本設定 |
| 單一平台訂閱 | 高度依賴固定工具與固定模型 | 介面完整,方案可能含較高用量 | 不用時仍可能支付月費 |
| 本地 ComfyUI | 生成量大、重視隱私、已有顯卡 | 沒有每次 API 費用,控制度高 | 需要顯存、硬碟與維護經驗 |
如果每個月只做少量成品,又想在 Nano Banana、GPT Image、Seedance、Kling、MiniMax 等模型之間切換,按量付費通常比同時維持多個訂閱直覺。若每天大量產圖,或素材不能離開本機,則可以先看 Krea2 與 ComfyUI 圖像編輯工作流,影片生成也可參考 LTX 2.3 本地部署教學。
Skill 的價值不是多一個聊天指令
Skill 可以把一套反覆使用的製作規則交給 Codex。它不只是記住「呼叫 fal.ai」,而是先判斷這次是文字生圖、圖片編輯、文字生影片或圖生影片,再選對端點與參數。不同操作通常有不同的模型 ID,文字生圖與圖片編輯即使使用同一模型,也不能假設共用同一個端點。
- 讀取
參考圖 資料夾,辨認可用素材與用途
- 先擴寫提示詞,再讓使用者確認內容與預估費用
- 依圖片、影片、編輯或動畫需求選擇端點
- 使用日期、模型與任務名稱建立可追蹤檔名
- 把結果下載到
完成檔,不要只留下暫時網址
- 保存請求 ID、模型 ID、主要參數與實際輸出
這和用 Codex 製作動畫的思路相同。工具負責執行,Skill 負責把規格、步驟與驗收條件固定下來。想再理解 Skill 如何控制視覺製作,可以延伸閱讀 7 個 AI 動畫 Skills 怎麼選與 Codex 動態圖表和短影片工作流。
建立專案與安裝 Python 套件
先在工作目錄建立 Skill、參考圖與完成檔資料夾,再建立獨立的 Python 環境。
mkdir -p .codex/skills/fal-media/scripts
mkdir -p 參考圖 完成檔
python3 -m venv .venv
source .venv/bin/activate
python -m pip install fal-client python-dotenv
到 fal.ai Dashboard 建立 API Key。只需要呼叫模型時先選 API 權限,不必一開始就給管理權限。金鑰只會完整顯示一次,取得後放進專案根目錄的 .env。
FAL_KEY=在這裡填入自己的金鑰
接著把 .env 與輸出資料夾加入 .gitignore。不要把金鑰貼進聊天內容,也不要寫在 Skill、Python 程式或 Git 儲存庫裡。
.env
.venv/
完成檔/
先用圖片完成第一個測試
模型名稱與輸入欄位會隨模型不同而改變,送出前要先看該模型的 API 頁面。下面以 Nano Banana 2 的文字生圖端點示範。第一次先產一張低風險測試圖,確認金鑰、額度與輸出格式都正常。
from pathlib import Path
from urllib.request import urlretrieve
import fal_client
from dotenv import load_dotenv
load_dotenv()
result = fal_client.subscribe(
"fal-ai/nano-banana-2",
arguments={
"prompt": "明亮自然光下的現代木質工作桌,畫面乾淨,寫實產品攝影",
"num_images": 1,
},
)
output = Path("完成檔/fal-nano-banana-2.png")
output.parent.mkdir(parents=True, exist_ok=True)
urlretrieve(result["images"][0]["url"], output)
print(output)
subscribe() 會自動進入佇列並等待結果,適合圖片與短時間測試。若要做圖片編輯,先用 fal_client.upload_file() 上傳本地參考圖,再依模型文件切換到編輯端點,例如 fal-ai/nano-banana-2/edit。輸入欄位可能是單一圖片或圖片陣列,不能直接把另一個模型的參數名稱搬過來。
影片任務改用佇列
影片生成時間較長,正式流程應使用 submit() 先取得請求 ID,再查狀態或接 webhook。這樣即使終端關閉,仍能用請求 ID 找回工作。下面使用 Seedance 2.0 文字生影片端點,參數依目前官方文件填寫。
from pathlib import Path
from urllib.request import urlretrieve
import fal_client
from dotenv import load_dotenv
load_dotenv()
handler = fal_client.submit(
"bytedance/seedance-2.0/text-to-video",
arguments={
"prompt": "清晨的城市屋頂,一架小型無人機緩慢掠過,電影感廣角鏡頭,自然環境聲",
"resolution": "720p",
"duration": "5",
"aspect_ratio": "16:9",
"generate_audio": True,
"bitrate_mode": "standard",
},
)
print(f"request_id: {handler.request_id}")
result = handler.get()
output = Path("完成檔/fal-seedance-2.mp4")
output.parent.mkdir(parents=True, exist_ok=True)
urlretrieve(result["video"]["url"], output)
print(output)
這個範例最後仍用 handler.get() 等待完成,目的是讓第一次測試保持簡單。大量任務應保存請求 ID,定期查詢狀態,或把 webhook URL 傳給 submit()。新的 fal.ai 帳號通常從較低的同時執行數開始,超出的工作會留在佇列,不需要自己不斷重送。
可以直接交給 Codex 的 Skill 提示詞
先讓 Codex 建立 .codex/skills/fal-media/SKILL.md 與必要腳本。下面這段不是一次性的生圖提示詞,而是用來定義整套工作方式。
請在目前專案建立一個 fal-media Codex Skill,使用 Python fal-client。
工作規則
1. API 金鑰只從環境變數 FAL_KEY 讀取,不得顯示、記錄或寫入程式碼
2. 先判斷任務屬於文字生圖、圖片編輯、文字生影片或圖生影片
3. 呼叫前先讀取對應模型的官方 API 文件,確認端點 ID、必要欄位、輸出格式與目前價格
4. 讀取參考圖資料夾中的素材,列出準備使用的檔名與用途
5. 先把我的簡短需求整理成完整提示詞,但在產生前必須讓我確認提示詞、模型、解析度、時長、數量與預估費用
6. 圖片測試可使用 subscribe,影片與長時間任務使用 submit 並保存 request_id
7. 生成完成後立刻下載到完成檔資料夾
8. 檔名格式為日期時間、模型短名、任務短名
9. 同時保存一份 JSON 紀錄,包含端點 ID、參數、request_id、輸出路徑與執行時間
10. 失敗時先回報錯誤與可能費用,不要自動無限重試
請先建立檔案與顯示差異,不要實際呼叫付費 API。
Skill 建好後,日常任務可以簡化成一段明確需求。
請使用 fal-media Skill,把參考圖中的咖啡機做成 5 秒 16:9 產品影片。
鏡頭從正面特寫緩慢拉遠,保留機身外型與顏色,加入清晨窗光和少量蒸氣。
先比較兩個適合的圖生影片模型,列出各自預估費用、速度與限制。
等我確認模型與完整提示詞後才開始生成。
提示詞要固定哪些資訊
- 目的與輸出類型,例如商品首圖、社群短片或角色動作測試
- 主體、場景、動作與必須保留的特徵
- 構圖、鏡頭、光線、材質與色彩
- 尺寸、比例、時長、解析度與輸出數量
- 參考圖的用途,例如保留人物、只取服裝或只參考構圖
- 避免事項,例如不要改 Logo、不要增加文字、不要改變產品比例
- 成本上限與開始前是否需要人工確認
擴寫提示詞不是把形容詞堆得越多越好。對圖片而言,主體、構圖、光線與限制比華麗文字重要。對影片而言,還要明確交代起始狀態、動作順序、鏡頭移動、時間長度與聲音。一次只測一個主要變因,才能知道品質改變來自模型、提示詞還是參數。
不是免費,只是把固定月費改成按量計費
fal.ai 使用預付點數。依官方說明,成功輸出才會依模型單位計費,排隊時間與伺服器錯誤通常不計費,但若使用者端錯誤發生前已經啟動 GPU 工作,仍可能產生費用。已購買點數目前有期限,模型價格也可能調整,所以文章裡的舊價格不能代替每次執行前的模型頁面。
- 圖片先用一張與較低解析度測試
- 影片先做 4 到 5 秒,再決定是否延長
- 送出前顯示模型單價、數量、秒數與預估總額
- 設定單次成本上限,超過就停止並要求確認
- 不要在失敗後自動切換更貴模型
- 保存 request_id,避免誤以為失敗而重複送出
對只想偶爾試一張圖的人,直接使用 Playground 會更省事。對已經每天用 Codex 管專案的人,Skill 的價值才會明顯,因為相同的命名、資料夾、模型選擇與確認規則都能重複使用。至於高頻生成,應把 fal.ai、固定訂閱與本地工作流的實際月成本放在一起比較。
API 金鑰、參考圖與成品都要保護
前端網頁或桌面 App 不能把 FAL_KEY 直接打包進程式。瀏覽器程式碼可被查看,應由自己的後端代理請求,再由伺服器附加金鑰。桌面工具也應使用系統安全儲存區或後端,而不是把金鑰放在可讀取的設定檔。
資料保留同樣不能忽略。fal.ai 文件目前指出,JSON 請求與回應預設可能保留一段時間,可透過 X-Fal-Store-IO 控制平台不要保存這部分內容。但生成的媒體網址屬於另一件事,拿到網址的人可能可以存取,且 CDN 檔案不是永久保存。敏感素材應先確認模型與平台政策,完成後立刻下載,並依需求設定媒體生命週期。
我的建議工作流
- 先在 fal.ai Playground 用同一段需求比較兩個模型
- 確認畫質、速度、授權、輸入格式與目前單價
- 把選定端點寫進 Skill 的模型對照表
- 讓 Codex 擴寫提示詞並列出預估成本
- 人工確認後只做一張圖或 5 秒影片
- 檢查主體一致性、文字、構圖、聲音與瑕疵
- 通過後才增加解析度、時長或數量
- 下載成品並保存參數與 request_id
如果最後還要把多段素材組成完整內容,可以把生成素材交給 OpenMontage 本地影片工作流或 HyperFrames。
fal.ai 比較像生成引擎與模型入口,Skill 負責製作規則,剪輯與編排工具則負責把素材變成能交付的作品。
FAQ
fal.ai 是免費的嗎
不是。它主要採預付點數與按量計費,不同模型、解析度、秒數與輸出數量會影響費用。少量使用可能比維持多個月費訂閱划算,但不代表零成本。
一定要建立 Codex Skill 嗎
不一定。只測一次模型,直接用 Playground 最快。需要反覆處理參考圖、提示詞、模型選擇、成本確認、下載與命名時,Skill 才能省下大量重複操作。
可以把 API Key 貼給 Codex 嗎
不要。把金鑰存成 FAL_KEY 環境變數,並讓程式直接讀取。對瀏覽器與公開 App,必須透過後端代理,不能把金鑰放在前端。
生成完成後可以只保存網址嗎
不建議。CDN 有保留期限,且媒體網址可能被持有網址的人存取。完成後應立即下載到自己的儲存空間,並保存請求 ID 與模型參數。
官方資源
by Rain Chu | 9 月 9, 2026 | AI, Chat
LibreChat 是把 OpenAI、Anthropic、Google、OpenAI 相容端點與本地模型,整理成一個可以自己部署、自己管理的 AI 工作台。早期把它叫做「套殼」還勉強能描述外觀,但到了現在,這個說法已經低估了它的定位。
它比較像模型與工具之間的控制層。使用者面對同一個聊天介面,管理者則能在後面決定模型來源、權限、Agents、MCP、搜尋、文件檢索與資料保存方式。對想把雲端 API 和內網 Ollama 放在一起的人,LibreChat 是很實用的開源入口。
LibreChat 是什麼
LibreChat 是可自行部署的開源 AI 平台,原始碼放在 LibreChat GitHub。它不包含自己的大型語言模型,而是把不同模型供應商、本地推理服務與工具能力接到同一個操作介面。
- 在同一段對話裡切換不同模型
- 保存 Prompt、Presets、對話分支與搜尋紀錄
- 上傳文件並使用 RAG、OCR 與檔案檢索
- 建立 Agents,串接 MCP、Skills、工具與子代理
- 使用 Code Interpreter、Artifacts、圖片生成與網頁搜尋
- 提供多使用者登入、角色、群組與存取控制
目前官方文件以 v0.8.x 為主,GitHub README 也會展示較新的候選版本功能。正式環境不要只看介面截圖判斷版本,部署前應先確認自己使用的映像標籤與官方升級說明。
它不是免費的 ChatGPT Plus 集合包
這是最容易誤會的地方。LibreChat 本身免費開源,不代表接進去的模型都免費
ChatGPT Plus、Claude Pro 與 Gemini 的消費者訂閱,通常也不能直接當成 API 額度使用。要呼叫官方模型,仍需準備對應的 API Key,費用由各供應商另外計算。
如果不想累積雲端 API 費用,可以改接 Ollama、llama.cpp、LM Studio、vLLM 或其他 OpenAI 相容服務,不同推理後端怎麼選,可以先看 本地大模型推理框架比較。LibreChat 負責操作與編排,模型成本、速度和能力仍由後端決定。
用 Docker 安裝 LibreChat
官方目前仍把 Docker Compose 列為最直接的本機安裝方式。先確認電腦已安裝 Git 與 Docker Desktop,再執行以下命令。
git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d
Windows PowerShell 或命令提示字元可把複製指令改成下面這一行。檔名之間要保留空格,不能把整段黏在一起。
copy .env.example .env
啟動完成後打開 http://localhost:3080。第一個完成註冊的帳號會成為管理員,系統沒有預設帳號與密碼,確認管理員可登入後,公開服務建議把 ALLOW_REGISTRATION 設為 false,避免陌生人自行註冊。
三層設定檔不要混在一起
| 檔案 | 用途 | 適合放什麼 |
|---|
.env | 密鑰與伺服器開關 | API Key、登入、註冊與服務環境變數 |
librechat.yaml | LibreChat 功能設定 | 自訂端點、模型清單、Agents、MCP 與介面選項 |
docker-compose.override.yml | 容器覆寫 | 掛載設定檔、改連接埠、替換映像與新增服務 |
docker-compose.yml | 官方基礎配置 | 原則上維持原樣,方便後續更新 |
API Key 建議放在 .env,再由 librechat.yaml 使用環境變數引用。不要把真正的 Key 直接寫進 YAML,也不要提交到 GitHub。修改設定後需要重新啟動容器才會生效。
個人環境可以由伺服器統一提供 Key。多人共用時,也可以在自訂端點把 apiKey 設為 user_provided,讓每位使用者在介面輸入自己的憑證,避免所有請求都共用同一把組織 Key。選哪一種方式,取決於費用要集中管理,還是由使用者各自負責。
docker compose down
docker compose up -d
串接內網 Ollama
LibreChat 可以把 Ollama 當成 OpenAI 相容端點。以下範例直接使用內網位置 192.168.0.240:11434。先在專案根目錄建立 librechat.yaml。
version: 1.3.13
cache: true
endpoints:
custom:
- name: Ollama
apiKey: ollama
baseURL: http://192.168.0.240:11434/v1/
models:
default:
- qwen3:32b
fetch: true
titleConvo: true
titleModel: current_model
接著在 docker-compose.override.yml 把 YAML 掛進 API 容器。
services:
api:
volumes:
- type: bind
source: ./librechat.yaml
target: /app/librechat.yaml
如果 Ollama 和 LibreChat 在同一台電腦,Docker Desktop 環境可以依官方範例改用 http://host.docker.internal:11434/v1/。如果 Ollama 在另一台 AI Server,就使用可從 LibreChat 主機連到的區網 IP。遠端服務的監聽、防火牆與測試方式,可接著參考 Ollama 遠端連線教學。
不要直接把 11434 對整個網際網路開放。比較穩妥的做法是限制在內網、VPN 或反向代理後方,再用防火牆控制來源。
從聊天介面升級成 Agent 工作台
LibreChat 現在的價值,已經不只在多模型切換。Agents 可以組合系統指令、模型、工具、MCP、Skills、文件與子代理,並在需要時加入人工確認。這讓同一套介面能分別建立研究助理、文件問答、程式開發、客服與內部知識助手。
若主要需求是跨文件研究與來源整理,Open Notebook 私有 AI 研究工作流會更專門。若重點是跨模型聊天、工具與 Agent 的統一入口,LibreChat 的範圍更廣。兩者也不衝突,前者可以負責知識工作流,後者負責日常模型與代理入口。
常見安裝問題
出現 librechat.yaml 錯誤
先檢查縮排與 YAML 語法,再確認 override 已把檔案掛到 /app/librechat.yaml。容器內讀不到檔案時,主機上有 YAML 也不會生效。
3080 連接埠被占用
可在 override 把外部連接埠改成 3081:3080,之後用 http://localhost:3081 開啟。
Apple Silicon 啟動 MongoDB 失敗
官方文件指出部分 M1 到 M4 環境會遇到 MongoDB 映像的 AVX 相容問題,可在 override 將 MongoDB 映像指定為 mongo:4.4.18。這是相容性處理,不代表所有 Apple Silicon 都一定會遇到。
不知道錯在哪裡
docker compose logs api
先看 API 容器最後一段紀錄,通常會直接指出缺少的環境變數、無效 YAML、資料庫連線或供應商 API 問題。
公開部署前的安全清單
- 第一個管理員建立後關閉公開註冊
- 使用 HTTPS 與可信任的反向代理
- 不要把 API Key 寫進公開 YAML 或 Git 儲存庫
- 限制 Ollama、MongoDB 與 Redis 的網路來源
- 定期備份資料庫與上傳檔案
- 依團隊角色設定 Agents、MCP、檔案與對話權限
- 升級前先查看 v0.8.x 的相容與遷移說明
LibreChat 現在已有預覽中的 Admin Panel,可管理使用者、群組、角色、系統授權與部分設定覆寫。不過預覽功能仍可能調整,正式環境不能只依賴介面上的開關,網路隔離、密鑰管理與備份仍要在基礎設施層處理。
LibreChat 適合誰
如果你只固定使用一個雲端聊天服務,官方介面通常最省事。當你開始同時使用多家模型、需要本地 Ollama、想建立不同 Agents,或要替團隊管理共用入口,LibreChat 的價值才會真正出現。
我的判斷是,LibreChat 已經從「像 ChatGPT 的開源介面」走到「自架 AI 控制台」。它不會替你省掉所有模型費用,也不會自動解決權限和維運問題,但它讓模型、工具、文件與代理不必被綁死在單一供應商。這對想建立私有 AI 工作環境的人,比單純模仿介面重要得多。
FAQ
LibreChat 可以免費使用 GPT 嗎
LibreChat 免費開源,但 GPT API 仍由 OpenAI 計費。ChatGPT Plus 訂閱通常不能直接抵用 API。想避免 API 成本,可以接本地 Ollama 或其他自架模型。
LibreChat 可以接 Ollama 嗎
可以。透過 librechat.yaml 建立 OpenAI 相容自訂端點,並把設定檔掛進容器即可。本機 Docker 可使用 host.docker.internal,內網 AI Server 則使用可連線的區網 IP。
LibreChat 適合公開給團隊使用嗎
可以,但需要 HTTPS、註冊控制、角色權限、密鑰管理、資料備份與內部服務隔離。第一個註冊帳號會成為管理員,建立後應立即檢查公開註冊設定。
by Rain Chu | 9 月 8, 2026 | Agent, AI, Apple, Mac, 程式開發
買 Mac 跑本地 AI,我會先考慮以下三件事:
模型能不能放進記憶體,送出長篇資料後要等多久,以及開始回答後每秒能生成多少 token。這三件事分別牽涉容量、運算能力與記憶體頻寬,不能只看晶片名稱裡的數字。
同一台電腦,短問短答很順,換成讀程式碼、查工具、反覆執行任務的 Agent 卻很慢,並不矛盾。
聊天介面讓你注意到的是持續輸出的速度,Agent 更容易暴露長輸入、多輪推理與工具等待的成本。
模型載入成功,只代表跨過容量門檻,還不代表這台機器適合你的工作流。
本文於 2026 年 9 月 6 日核對規格。Apple 已公布新款 Mac mini 與 Mac Studio,官方標示 9 月 22 日開始供貨。以下會把官方規格、推理原理與選購判斷分開,未取得的新機實測不會用推估值冒充。供貨資訊可查 Mac mini 公告與 Mac Studio 官網。
先分清 Prefill 與 Decode,才知道慢在哪裡
Prefill,預填充,是模型處理輸入內容、建立後續推理狀態的階段,系統提示詞、聊天記錄、工具定義、檢索文件與程式碼都可能算進輸入,並非只有你剛打的那一句話。長輸入通常有較大的矩陣運算需求。
Decode,解碼生成,則是在已有上下文狀態上逐步產生 token,單一請求、低批次的生成常受記憶體資料搬運限制,所以記憶體頻寬很重要,Token 不是固定的一個中文字,不能把 tokens/s 直接當成每秒中文字數。
觀察體感時,我會同時記錄 TTFT,也就是送出後到第一個 token 的時間,以及生成階段的 tokens/s,TTFT 還可能包含排隊、模型載入與服務端處理,不能把所有等待都歸因於 Prefill,Apple 的 MLX 與 M5 技術說明也分別討論提示詞處理與生成效能,兩個階段應分開比較。
記憶體容量,是門票而不是速度保證
Apple Silicon 的 CPU 與 GPU 共用統一記憶體,跑較大模型時不必完全受限於一張獨立顯示卡的顯存容量,在這規格表上的 32GB 或 128GB 並不等於模型可以獨占同樣的空間,macOS、瀏覽器、開發工具、KV cache 和推理暫存都需要預算。
估算可以從權重開始:參數數量乘上每個參數的位元數,再除以 8,以約 27B 參數、理想化 4-bit 權重計算,純權重約 13.5GB,這只是十進位容量的粗估,還沒加入量化分組資訊、部分高精度權重與執行時開銷。
32GB 能否跑某個 27B 模型,答案是「有機會,但要指定量化檔、上下文長度與框架」。只拿 27B 這個名字,無法保證長上下文與多 Agent 都順暢。先核對實際模型檔大小,再測一個完整任務,會比只看成功載入的畫面更有用。
如果想先理解不同推理工具的定位,可以參考 MLX、llama.cpp、Ollama 與其他本地推理框架比較,格式、核心實作與快取策略都會影響同一台硬體的表現。
記憶體頻寬,影響持續輸出但不是萬用答案
可以把容量想成能放多少資料,頻寬則是每秒能把多少資料送到運算單元。當低批次生成需要反覆讀取大量權重,而硬體運算能力足夠時,頻寬往往成為主要限制。
但「頻寬加倍,速度就一定加倍」只適合當理想化的直覺,實際還有量化解碼、注意力、KV cache 存取、核心效率、批次大小與模型架構,MoE 也不是每個 token 都動用全部專家權重,所以不能把所有模型都套進同一條簡單公式。
M5、M6 規格怎麼看,先看配置再看名稱
以下整理 Mac mini 技術規格與 Mac Studio 技術規格中,和本地模型最直接相關的容量與頻寬。這是規格對照,不是速度排名,也不是實測 tokens/s。
| 機型與配置 | 統一記憶體 | 記憶體頻寬 |
|---|
| Mac mini M6 基本配置 | 16GB | 153GB/s |
| Mac mini M6 較高記憶體配置 | 24GB 或 32GB | 170GB/s |
| Mac mini M5 Pro | 24GB,可選 48GB 或 64GB | 307GB/s |
| Mac Studio M5 Max 32 核心 GPU | 36GB | 460GB/s |
| Mac Studio M5 Max 40 核心 GPU | 可選至 128GB | 614GB/s |
| Mac Studio M5 Ultra | 96GB,特定配置可選至 512GB | 1.2TB/s |
2026 年 9 月 6 日核對,容量與頻寬不等同實測生成速度
M5 Max 的 32 核心與 40 核心 GPU 版本不只差核心數,頻寬與可選記憶體也不同,M5 Ultra 的 256GB、512GB 選項綁定更高階晶片配置,升級容量的成本可能同時包含晶片升級。選購時應核對最後的完整配置,不要把某個系列的最高值套到入門款。
供貨時間也要分開看。依 Apple 台灣的新款 Mac Studio 公告,一般配置自 9 月 22 日起供貨,512GB 統一記憶體配置則預計 10 月底推出,需要立即交付工作的團隊,應再確認實際可下單配置與交貨日期。
跑 Agent 為什麼更容易卡在等待
一個程式碼 Agent 可能先讀專案規則,再讀檔案,接著呼叫工具,最後把工具輸出帶回模型繼續判斷,每一輪都可能增加輸入,輸出卻只有一小段指令,讓「先讀懂,再動作」的成本更加明顯。
「每開一個子代理,就一定完整重算一次全部上下文」並不精確,是否能重用相同前綴,取決於服務端的 prompt cache、請求路由、模型支援與上下文是否一致,MLX LM 官方專案就提供 prompt caching 功能,實際 Agent 框架有沒有用到,仍要另外確認。
- 把長期不變的規則放在穩定前綴,減少每輪重新排列內容
- 只提供當前任務需要的檔案與工具,避免把整個專案一次塞進提示詞
- 先測單 Agent,再逐步增加並行數,觀察排隊與記憶體壓力
- 同時記錄模型等待、工具執行與重試時間,避免把外部服務延遲算到 GPU 頭上
如果任務需要很長的推理輸出,Decode 仍可能占大部分時間,真正值得比較的是完成同一項工作要多久、成功率如何,而不只是某個階段的峰值數字。選擇 Agent 模型與本機部署方式時,也應把工具呼叫品質一起放進評估。
M5 的加速器,要配合軟體才能發揮
M5 GPU 的 Neural Accelerators 是 GPU 內的矩陣運算加速能力,不應和晶片上另一個 Neural Engine 混為一談,對長輸入這類運算密集的工作,支援相應路徑的框架與核心可以帶來收益。
買到新晶片不代表任何模型、量化格式和舊版工具都會自動得到相同比例的加速,我會連同 macOS、MLX 或 llama.cpp 的版本一起記錄,並查看執行時使用的後端。Apple 早期公布的 M5 測試可以用來理解方向,但不能直接當成新款 M6 或 M5 Ultra 的實測成績。
MoE 為什麼值得看,但不能只看啟用參數
Mixture of Experts,混合專家模型,會依 token 選用部分專家,降低每步需要參與計算的參數量,它讓「保存很多知識容量」和「每一步動用多少運算」有機會分開,這和大容量統一記憶體的特性很搭。
以 Qwen 官方的 Qwen3-30B-A3B為例,30B 指總參數量,3B 指啟用參數量,不能因為看到 A3B,就用一個 3B 稠密模型的記憶體需求來估算,通常仍要保存更大的整體權重。這是用來解釋命名與架構的例子,不代表它是目前唯一或最適合的選擇。
MoE 的速度還受專家路由、量化、核心最佳化與批次大小影響,也不保證同樣容量下的工具使用品質一定勝過稠密模型,我的做法是準備一組真實任務,用完成品質與總耗時一起決定。
三種使用情境,我會這樣安排預算
主要使用雲端 AI,優先顧好日常工作
如果主要運算都在雲端,Mac 更多是在跑瀏覽器、編輯器與本地工具,無須只為遠端模型購買超大記憶體。16GB 到 32GB 可以作為一般工作起點,但大型專案編譯、虛擬機與剪輯仍可能需要更多。這是用途判斷,不是所有人的最低規格。
本地聊天、寫程式與剪輯混用,先看 48GB 到 128GB 的實際需求
先列出最常用的兩三個模型,再加上平常同時開啟的軟體。M5 Pro 和 M5 Max 各有不同容量與頻寬選項,能否容納模型加上真實工作環境,比只追求最大 GPU 核心數更重要。若以 Agent 為主,要優先找長提示詞與連續工具呼叫測試,而不是只看短聊天跑分。
目標是超大模型,再考慮 Ultra 與多機
當權重、長上下文或多請求確實超出較小容量,才有充分理由看 256GB、512GB 或分散式部署。先問自己是否需要那個模型能力,以及它能否在可接受時間內完成任務,不要為了「裝得下最大模型」而買一台長期等待的電腦。
AI 生圖與生影片,要另做一份評估
剪輯影片和用生成模型產生影片,是不同的運算工作,ProRes 編解碼能力強,不能直接推論擴散模型也會很快。ComfyUI 官方支援 Apple Silicon,但你的模型、量化與自訂節點是否支援 Mac,以及完整生成一段內容要多久,仍需逐項確認。
若主要目的是高頻率生影片,我會拿實際工作流比較 NVIDIA GPU、本地 Mac 與雲端方案,再把等待時間與每次產出的成本算進去。可從 LTX 2.3 的 ComfyUI 影音工作流理解需要核對哪些模型與節點,不應只拿文字模型的速度替影音生成下結論。
不過可以肯定的是現在要生圖還是首選 Nvidia 畢竟 pyTouch 還沒有完整支援 MAC
DGX Spark 加 Mac Studio,是分工不是魔法加總
EXO 的異質推理示範把 Prefill 放在 DGX Spark,再把 KV cache 傳給 Mac Studio 進行 Decode,並透過逐層傳輸,讓通訊與運算時間部分重疊。這說明不同硬體可以各做擅長的階段。
但 EXO 示範的是特定模型、輸入長度、硬體與網路,不能外推成任何組合都會同倍率變快。兩台 256GB 也不必然優於一台 512GB,模型如何分片、互連頻寬、框架支援與並行方式都會改變結果。多機還增加設定與維護成本,應以整個任務的實測決定。
對多機部署有興趣,可以接著看 雙機 EdgeXpert 與大模型工作負載,把單機容量、網路傳輸和軟體支援一起考慮。
購買前怎麼測,至少分開短提示詞與長提示詞
請測試者提供完整模型名稱、量化檔、框架版本、系統版本、上下文長度與 GPU 配置,相同模型換一種量化,或把長輸入改成一句問候,都足以改變結果。
已有 llama.cpp 與本地 GGUF 模型時,可參照 llama-bench 官方說明使用下列命令。把路徑改成自己已下載的模型,這裡的參數是測試設定,不是我在新機上測出的數字。
llama-bench -m /absolute/path/model.gguf -p 512,8192 -n 128 -r 3 -o json
這會分別測試不同長度的 prompt processing 與文字生成,輸出中的 pp 與 tg 對應不同階段。合成測試適合比較核心效能,不能直接當成真實 Agent 的 TTFT 或任務總耗時。還要補一輪實際工具呼叫流程,並分別記錄冷啟動、快取命中和未命中的狀態。
- 同一份短問答,觀察穩定生成速度
- 同一份長文件,觀察首個 token 等待時間
- 同一個修改程式任務,觀察工具呼叫與完成率
- 同樣的並行數,觀察尖峰記憶體、swap 與排隊
- 若要生圖或生影片,使用完全相同的模型、尺寸、步數與節點
FAQ
32GB Mac 可以跑 27B 模型嗎
部分量化版本有機會,但要加上 KV cache、推理暫存、macOS 與其他程式的需求。能載入不等於長上下文或多 Agent 都能流暢使用。
M6 一定比 M5 Max 適合本地 AI 嗎
不一定。要比較完整配置的容量、頻寬、運算後端與實際工作負載,不能只用世代數字排序。
為什麼聊天很快,Agent 卻很慢
Agent 可能反覆處理長上下文並等待工具,瓶頸不只在生成速度。應同時檢查 Prefill、快取、排隊、工具時間與任務重試。
MoE 的啟用參數少,記憶體也只要那麼少嗎
不是。啟用參數主要描述每步參與計算的部分,通常仍要保存全部專家權重,容量估算不能只看 A 後面的數字。
我的選購順序:先定工作,再定模型,最後選配置
先確定主要工作是在雲端還是本地,再決定模型與上下文需求。容量不足先解決容量,等待第一個字太久就看輸入處理與快取,開始輸出後仍然慢才進一步比較頻寬與生成核心。用這個順序選 M5、M6 或 Ultra,比追規格表上最大的數字更能把錢花在真正的瓶頸上。
近期留言