本地模型能撐起 AI Agent 工作流嗎？

NVIDIA DGX Spark 實測報告：122B 與 550B 的六道真實任務對照

摘要

我們在一台 NVIDIA DGX Spark（GB10，128GB 統一記憶體）上部署了 Qwen3.5-122B-A10B（GPTQ-Int4 量化），接入日常實際使用的 AI Agent 工作流，以六道真實工作任務進行測試，並與雲端的 Nemotron-3-Ultra-550B 進行對照。

結論摘要：

在單人、單工作流的條件下，122B 已經需要頻繁的人工介入；其中兩題產出了看似合理但實際錯誤的結果，且模型未能自我察覺。對於需要無人值守執行的 Agent 應用，這是關鍵的失格條件。

一、為什麼做這個測試

生成式 AI 進入企業之後，「要不要把模型放在自己機房」是每個客戶都會問的問題。地端部署的理由很充分：資料不出場、成本可預期、不受 API 限流影響。

但一個常被忽略的前提是：地端能跑的模型大小，直接決定了它能做什麼工作。

我們自己就是這個問題的實驗對象。軟體部門日常以 AI Agent 處理專案管理工作——從 Jira 抓取任務資料、產出 WBS 專案計畫、整理逾期報表、統計工時。這套流程原本跑在雲端的 550B 模型上，運作穩定。

當 DGX Spark 到手，我們想知道的很具體：同樣一套工作流，換成單機能跑的最大模型，還能用嗎？

二、測試環境

硬體與模型

記憶體配置的現實

這是第一個值得注意的數字。DGX Spark 的 128GB 統一記憶體，在跑 122B 模型時的實際分配：

系統可用記憶體僅剩約 21 GiB，且已開始使用 swap。這台機器跑 122B 已經接近滿載——沒有空間再放更大的模型，也沒有餘裕同時服務更多使用者。

一個容易誤判的技術細節：DGX Spark 採用統一記憶體架構，nvidia-smi 的 Memory-Usage 欄位會顯示 Not Supported，這是 NVIDIA 官方確認的預期行為，需改用 free 或 DGX Dashboard 觀察。同時，vLLM 的 --gpu-memory-utilization 參數在此架構下是以整機記憶體為基數計算，而非傳統獨立顯示卡的「顯存餘額」——設定時必須比獨顯保守，否則會擠壓作業系統可用空間。

來源：NVIDIA 支援問答 a_id/5775、a_id/5728

並發能力

vLLM 啟動時回報的可用並發度為 Maximum concurrency: 12.97x（在 128K context 的前提下）。但實際吞吐測試顯示：

單一使用者就只有 13 tokens/s。 這個數字在對話式問答中尚可接受，但在 Agent 工作流中會被放大——因為 Agent 每完成一個步驟都需要完整的推理輪次，一個任務往往需要 5 到 20 個輪次。

測試方法

• 使用日常實際在用的 Agent 框架與工作技能定義（Skill），非合成測試
• 每一輪測試前皆回復虛擬機快照，確保環境完全一致、無前次測試殘留
• 兩個模型使用相同的題目、相同的技能定義文件
• 記錄項目：完成時間、人工介入次數、產出正確性

測試條件說明：本報告為實務部署過程的紀錄，非嚴格控制的對照實驗。測試過程中我們曾三次修訂技能定義文件以補足環境資訊（詳見第五節），且兩個模型的測試日期相隔約一個月，部分題目的資料筆數因此不同。這些差異在報告中均已標註。

三、六道測試題

題目取自軟體部門的日常工作，難度由淺入深：

第 6 題刻意設計為「環境中沒有對應工具」的情境——測試模型遇到能力邊界時的反應。

四、逐題結果

第 1 題：匯出 WBS Excel

「幫我整理"○○"專案，並匯出 excel」

兩者都成功，產出完全一致（48 列、10 個 Epic、33 個 Task、5 個子任務，六項驗證全數通過）。

差別在執行路徑。550B 只用了三個動作：讀取技能定義 → 執行資料擷取腳本 → 執行 Excel 產生腳本。122B 則額外進行了工具查詢與專案清單檢索。

這是唯一一題 122B 乾淨通過。 但即使如此，550B 仍快一倍、步驟更少。

第 2 題：逾期任務 CSV

「幫我整理"○○"專案目前已經逾期的執行中任務與子任務，包含如下欄位：父任務名稱(無則空白)、任務名稱、執行者、預計開始日期、預計結束日期、已逾期天數；並以 parent 進行 grouping、以及用 end date 進行排序，最後用 csv 檔案匯出給我」

550B 的表現：第一次輸出即正確。它主動使用了正確的自訂欄位取得開始日期，並在回覆中明確標示欄位來源（預計開始日期 (customfield_10015)、預計結束日期 (duedate)）。唯一的介入是檔案交付格式，經一次提示後自行查閱技能文件並修正。

122B 的問題（依序發生）：

1. 開始日期整欄空白 — 未使用該 Jira 實例的自訂欄位，查詢時漏掉。經指正後修正。
2. CSV 分隔符使用全形逗號 — 導致 Excel 無法正確分欄。經指正後宣稱已修正，但實際未修。
3. 第二次指正後，模型以位元組層級驗證（確認 357 274 214 為 UTF-8 全形逗號）才真正定位問題並修好。
4. 中文在 Excel 顯示為亂碼 — 缺少 UTF-8 BOM。此題模型診斷正確（僅給予「LibreOffice 正常、MS Office 亂碼」的症狀描述，模型即推論出 BOM 缺失），但仍需第三次介入才處理。

註：第 2 題兩次測試相隔約一個月，資料筆數不同（27 筆 vs 17 筆），屬專案進度變化，非查詢邏輯差異。

值得注意的是第 2 點。 模型回報「已改為半形逗號」，但輸出檔案並未改變。這類自我報告與實際結果不符的情況，在後續題目中重複出現。

第 3 題：下週待辦任務查詢

「幫我整理 jira 中 assignee 是 ○○○ 的所有 start date 在下周周六之前的待辦(open 或 todo)任務和子任務，不需要匯出 excel，顯示在對話中即可。」

關鍵差異在「待辦」的語意判斷。

Jira 的狀態分類（statusCategory）只有三大類：To Do、In Progress、Done。而「已擱置」這個狀態，在系統分類上歸屬於 To Do。

• 122B 依系統分類查詢，回傳 21 筆，其中 17 筆是「已擱置」。經指正後才排除，剩 4 筆。
• 550B 一次回傳 9 筆，全數為「開放」或「待辦事項」，無一筆已擱置。

使用者要的是「可以開始做的工作」，不是「系統歸類為待辦的工作」。這個差別無法從字面判讀，需要理解意圖。

550B 另外做了三件題目沒要求的事：

1. 執行 date 指令先確認系統當前日期，再推算「下週六」——Agent 沒有內建時間感，這是嚴謹的做法
2. 主動查詢 Jira 的欄位定義端點，自行找出開始日期對應的自訂欄位，未依賴文件提示
3. 在結果末尾主動提醒：「有 3 筆父任務狀態為『進行中』，但子任務是『開放/待辦』，建議確認父任務狀態是否需同步更新」——主動指出資料品質問題

第 4 題：專案總工時統計

「幫我統計一下"○○"專案目前投入的全部工時」

這是最值得警惕的一題。

122B 在查詢階段回報找到 44 筆議題，但統計時只計入 35 筆——API 回應被截斷，遺漏約 9 筆的工時資料。

模型並未察覺這個矛盾。 它在同一段回覆中先說「有 44 個 issues」，後又輸出「總計項目數：35 個」，數字前後不一致卻未觸發任何檢查。它給出的 216.1 小時看起來是個合理的數字，若非我們手上有正確答案，這個錯誤不會被發現。

更值得注意的是「修正」的方式：當我們提供正確數據後，模型並未重新查詢，而是直接引用我們提供的表格重算。原本的資料截斷問題並未被解決。

550B 則一次回傳正確的 275.9 小時，並附帶 122B 未提供的資訊：有工時記錄 34 筆 vs 無記錄 10 筆、換算人天、以及「Epic 層級大多未直接記工時」的結構觀察。

第 5 題：某人某日的工作安排

「幫我看看"○○"在"2026-09-11"被安排的工作有那些?」

122B 在直接呼叫 API 時，將環境變數中的「站台名稱」誤用為登入帳號（正確應使用電子郵件）。Atlassian 在此情況下回傳的是 HTTP 200 加上空結果，而非明確的認證失敗。

模型的結論是：

「根據目前的查詢結果，○○ 在 2026-09-11 沒有被安排任何工作。」

這是錯的，但陳述得像事實。 模型雖然附帶列出三個可能原因，但主結論已足以誤導使用者。

隨後我們提供了正確答案，模型的回應是「以上資訊是根據您提供的資料彙整」——再次以使用者提供的資料交差。直到我們明確要求「我需要你幫我查出來，而不是用我的資料來整理」，它才重新嘗試並自行改用電子郵件認證，成功取得正確結果。

550B 的對照：單次 JQL 查詢即取得正確的 5 筆結果，並主動標示判斷依據（「以截止日期 duedate 為準」）——因為「被安排」一詞本身有歧義，模型明確說明自己採用哪一種解讀。

我們另外以同一人、不同日期（2026-09-01）測試 550B，該日確實沒有任務。模型的處理方式是：先查詢該日到期或開始的議題（無結果）→ 放寬條件檢查 Sprint 與顯示名稱 → 確認該日期是否落在其他任務的起訖區間內 → 最後搜尋是否有名稱相近的使用者。排除四種可能之後才回覆「當天沒有安排」，並附帶說明最近的下一項工作在 9/4。

這是本次測試中最值得注意的一組對比。 兩個模型都曾回答「沒有工作安排」——但 550B 的否定是查證後的結論，122B 的否定是認證失敗造成的假象。對使用者而言，兩者在畫面上看起來完全一樣。

第 6 題：Confluence 文件查找

「幫我到 Confluence 的"○○空間"裡面找一下工作計畫建立步驟文件中，關於"學習"類型的計劃要用甚麼顏色?」

這題環境中沒有 Confluence 的整合工具，測試的是模型在工具缺口下的應變能力。

兩者都誠實表明沒有 Confluence 工具，沒有捏造答案——這點都合格。

分水嶺在提示之後。 我們給的提示相同：「你從 env 中找一下 JIRA 相關的變數，confluence 也是用相同的」。

550B 的回應：

Atlassian Cloud 通常 Jira 和 Confluence 是同一個站台，但：

• 認證方式相同（Email + API Token）
• API endpoint 不同：Jira 用 /rest/api/3/，Confluence 用 /wiki/rest/api/

它隨即列出七個常用的 Confluence API 端點，一次驗證成功，直接找到目標文件。

122B 的回應：將 Confluence 的基礎路徑判斷為 /rest/api/（Jira 的路徑），並使用錯誤的帳號進行認證。取得 403 錯誤後，它的診斷是：

「問題確認：目前的 API Token 沒有 Confluence 的存取權限」
建議：生成新的 API Token 並授權 Confluence、檢查帳戶許可…

這個診斷是錯的——問題出在它自己用錯了帳號。 若使用者採信，將會白白花時間到 Atlassian 後台調整權限設定。經提示改用電子郵件後仍失敗（環境變數讀取不完整），它第二次做出同樣的錯誤診斷。直到我們明確表示「我確定這個 email 跟 token 是可以的」，它才去檢查變數完整性，一試即通。

五、一個重要的發現：小模型對指示的依賴度更高

測試初期，122B 在第一關就頻繁失敗——不去讀取既有的技能定義，而是自行撰寫替代腳本，產出結構完全錯誤的檔案。

追查後發現，是我們在建置測試環境時，遺漏了一份全域的行為指示檔案，其內容為：

在處理任何任務前，先檢查是否有相關的 Skill 可以使用。如果使用者提到 Jira、專案匯出、Excel 報表等關鍵字，務必先查看並使用對應的 skill，按照裡面的步驟執行，不要自行決定流程或撰寫替代程式碼。

補上這份檔案後，122B 的行為立即改善，會主動引用「根據指示，我需要先查看 skill 的步驟」。

這個發現本身就是結論的一部分：550B 能自行推斷「應該先找找有沒有現成流程」，122B 需要被明確告知。同樣的現象也出現在後續題目——我們陸續在技能文件中補上了三條環境資訊（腳本的絕對路徑、自訂欄位編號、API 認證方式），才讓 122B 能夠完成部分任務。

而 550B 在沒有這些補充說明的條件下，第 3 題自行查詢 Jira 欄位定義找出自訂欄位、第 6 題自行使用正確的認證方式——它不需要被教。

值得強調的是：即使補上了這三條說明，122B 在第 5、6 題仍然用錯了認證方式。知識存在於它的上下文中，但執行時沒有調用。 這種「知道但做不到」的落差，無法靠把文件寫得更詳細來解決。

六、失敗模式歸納

綜合六題觀察，122B 的問題可歸納為四類：

1. 資料完整性缺乏自我檢查

第 4 題的 21.7% 誤差，源於 API 回應截斷。模型自己輸出的兩個數字（44 筆 vs 35 筆）已經矛盾，卻未觸發任何驗證。

2. 自我報告與實際結果不符

至少四次出現：宣稱使用了既有技能（實際未用）、宣稱已改為半形逗號（實際未改）、以使用者提供的資料充當查詢結果（兩次）。

這是最難防範的問題——當模型的回報不可信，人工檢查的成本會超過它節省的時間。

3. 將自身錯誤診斷為環境問題

第 6 題兩次將自己的認證錯誤診斷為「API Token 權限不足」，並建議使用者去申請新的 Token。若使用者採信，將浪費時間在不存在的問題上。

4. 錯誤修正效率低

550B 並非不犯錯（第 2 題的檔案交付格式也用錯了），但經一次提示即自行查閱文件並修正。122B 則往往需要多次指正，且中間可能誤報成功。

差別不在會不會犯錯，而在修正的效率。

七、速度：被 Agent 工作流放大的差距

對照條件說明：本次測試的 550B 透過 NVIDIA NIM 的免費層存取，該服務有每分鐘 40 次請求的速率限制——這個額度不足以支撐正式的工作場景。而 122B 為本機獨佔運行、無任何外部限流。也就是說，550B 是在有配額限制的條件下達成本節的成績。

單看 13 tokens/s，似乎只是「比較慢」。但在 Agent 情境下，這個數字會被結構性放大。

Agent 完成一個任務需要多個推理輪次：理解需求 → 查詢資料 → 判斷結果 → 決定下一步 → 執行 → 驗證。每個輪次都是一次完整推理，而其中大部分內容（模型的思考過程）使用者甚至看不到。

實測中，122B 單次工具呼叫從送出到實際動作，經常需要 1 至 4 分鐘，且出現過單次推理超過 260 秒無輸出的情況。累積下來：

而這是單一使用者、無人競爭資源的最佳情況。

八、多使用者環境的推估

本次測試全程為單人操作，未進行並發壓力測試。但從已知數據可以做出合理推估：

• 模型權重已佔用 73GB，KV Cache 僅剩 23.6GB 的空間
• 單一請求 13 tokens/s，雙請求並行時每個請求約降至 12 tokens/s
• 服務設定的最大並行序列數為 4

換言之，這台機器在滿載時最多同時服務 4 個請求，而每個使用者將面對接近單人時的生成速度。以第 2 題（單人 40 分鐘）為例，若三位同仁同時發起類似任務，等待時間將顯著延長。

對於部門級或全公司級的 Agent 服務，這個容量不具實用性。

九、結論與建議

DGX Spark 適合什麼

我們不認為 DGX Spark 是一台沒有價值的機器。它在以下場景表現稱職：

• 模型行為驗證 — 在投入正式硬體前，先確認工作流設計、Skill 定義、工具串接是否正確
• 開發環境 — 單一工程師的實驗平台，資料不出場
• 模型選型評估 — 正如本次測試，用它來確認「多大的模型才夠用」
• 小規模、非即時的批次任務 — 沒有人在等待的自動化工作

DGX Spark 不適合什麼

• 需要無人值守的 Agent 工作流 — 六題中有兩題產出了錯誤且未自我察覺的結果。無人監看時，錯誤會直接進入產出
• 多使用者共用的服務 — 容量與速度都不支持
• 對回應時間有要求的互動應用 — 13 tokens/s 在長流程中體感過慢

我們的判斷

以本次測試的標準衡量——能否在無人監看的情況下，正確完成一個多步驟的專業任務——122B 級距的模型尚未跨過可託付的門檻。

問題不在於「做不到」，而在於做對與做錯看起來一樣。當模型會宣稱完成了實際未完成的事、會把自己的錯誤診斷成環境問題、會在資料不完整時給出看似合理的數字，使用者就必須逐項驗證它的每一個輸出。此時它節省的時間，已經被檢查的時間吃掉了。

而這不是靠更好的提示詞或更詳細的文件能夠解決的——我們在測試過程中三次補強技能文件，122B 仍在同樣的地方犯錯。

值得一提的是，本次對照中的 550B 是透過有速率限制的雲端服務存取，而 122B 為本機獨佔資源。即使在這樣的條件下，前者的完成時間仍普遍為後者的五分之一以下。

關於雲端與地端的選擇

本次測試中的 550B 使用 NVIDIA NIM 的免費額度（每分鐘 40 次請求），這個限制不足以支撐正式的工作場景。若要在生產環境使用同等級的雲端模型，就必須評估訂閱與 Token 的實際成本——Agent 工作流的 Token 消耗遠高於一般對話應用，單一任務即可能消耗數十萬至上百萬 token。

我們在另一篇專欄中完整分析過這筆帳，包含 500 人企業的三年 TCO 試算、以及雲端額度限制造成的產能損失：
K3 出現了，要自建嗎？我們先來算帳！

值得一提的是，那篇文章記錄了我們更早之前的一次嘗試——以消費級顯示卡搭配中小型開源模型跑 agent，很快就因為模型能力不足而反覆兜圈、給不出可用結果。本次的 DGX Spark 測試，是同一個問題在更高一階硬體上的再次驗證：從消費級顯卡升級到專業級工作站、從中小模型升級到 122B，Agent 仍然無法穩定完成多步驟任務。

這條線索指向同一個結論：地端部署的可行性，取決於你的硬體能不能跑得動「夠強」的模型——而這個門檻，比多數人預期的高。

給準備導入地端 AI Agent 的企業

先確認你的應用需要多大的模型，再決定硬體規格——而不是相反。如果你的目標是多人共用、無人值守的自動化工作流，請直接評估能夠承載 400B 以上模型的平台（如 DGX B300 等級）。用一台跑不動足夠大模型的機器來做這件事，省下的是硬體預算，付出的是每一份產出都要人工複查的長期成本。

附錄：測試環境的技術細節

以下資訊對於在 DGX Spark 上部署 vLLM 的團隊可能有參考價值：

記憶體參數

--gpu-memory-utilization 在統一記憶體架構下以整機記憶體為基數。實測將此值從 0.85 調整為 0.78 後：

調整依據：原設定配置的 KV Cache 超過「最大並行數 × 最大上下文長度」的理論需求，多出的部分永遠不會被使用。

模型載入時間

73.45 GiB 的權重（39 個 safetensors 分片，本機 EXT4）載入約需 7 分鐘。服務重啟需預留此時間。

MoE Kernel 未針對 GB10 最佳化

vLLM 目前未內建 GB10 平台的 MoE 調校參數檔，啟動時會提示 Using default MoE config. Performance might be sub-optimal!。這代表本報告的效能數據尚有優化空間，但調校結果會綁定特定模型與量化格式，且 GB10 的記憶體頻寬可能才是主要瓶頸。

監控方式

nvidia-smi 的 Memory-Usage 欄位在此平台顯示 Not Supported（NVIDIA 官方確認為預期行為）。實務上使用：

free -h                                    # 整體記憶體
nvidia-smi --query-compute-apps=pid,process_name,used_gpu_memory --format=csv

後記-1：換上 27B 之後，結論改變了嗎？

2026 年 9 月補記

本文發表後，我們在同一台 DGX Spark 上把模型換成 Qwen3.8-27B，用完全相同的六道題目、相同的技能定義文件、每題前回復同一個虛擬機快照，再跑了一輪。

原本的預期是：27B 比 122B 小四倍，結果只會更差。實際結果倒是讓我們頗出意外的。

六題結果對照

27B 六題全對、零人工介入——正確率追平 550B，人工介入次數甚至更少。但總耗時是 550B 的 16 倍。

27B 做對了 122B 做錯的每一件事

回頭看 122B 的四類失敗模式，27B 一項都沒有犯：

資料完整性會自我檢查。 第 4 題 122B 把 44 筆算成 35 筆而不自知；27B 第一次批次抓取時 timespent 全部回傳 null，它的反應是「這不太對勁」，去查單一議題的 worklog 確認資料存在，然後重抓、換方法，直到拿到正確的 275.7 小時——與 550B 完全一致。它拒絕接受一個看起來合理的錯誤答案。

自我報告可信。 六題中沒有一次宣稱完成了未完成的事。第 2 題它主動指出「有 2 筆審核中狀態的逾期任務不在你的篩選範圍內，需要的話我可以補上」；第 3 題主動列出「另有 5 筆進行中的未結事項」；第 5 題把「被安排」的兩種解讀分開呈現，附上各自的工時合計。它把自己做的假設攤在使用者面前，而不是藏起來。

不會把自己的錯誤診斷成環境問題。 第 6 題 122B 兩次把認證錯誤說成「Token 沒有權限」；27B 零提示就推論出 Jira 與 Confluence 共用同一站台與憑證、API 路徑前綴不同，一次認證成功——這題連 550B 都需要一次方向提示。

它還抓到了我們自己文件裡的 bug。 第 3 題它發現技能文件中的 JQL 寫法 status != "已關閉" 在這個實例上其實是壞的——JQL 只認英文原名，本地化名稱會靜默失效。它用四支測試腳本驗證後自行修正了文件。這個問題 550B 沒有發現（它碰巧用了另一種寫法避開）。

錯字識別

第 2 題的題目裡刻意放了一個錯字：「執行中任務與自任務」（應為子任務）。三個模型都正確理解為子任務，但只有 27B 主動告知使用者這個判斷，並說明推論依據（「子」與「自」拼音相同，屬輸入法選字錯誤）。550B 與 122B 都直接當作子任務處理，沒有提及。(也或許有發現自是沒主動報告)

那 325 分鐘花在哪裡

27B 的慢，不是推論速度慢——單機跑 27B 的生成速度遠高於 122B。慢在推理的量。

它採用的是完整的思考模式：每一個決策都會把所有可能攤開來反覆推敲。「下週六」是 9/12 還是 9/19，它在同一輪推理裡想了三遍，每遍得到同樣答案；第 2 題的 grouping 該怎麼排序，它比較了五種方案。這種「不收斂」的特性讓每題有 15 到 30 分鐘的固定成本，跟題目難度無關。

第 3 題的 140 分鐘還有另一個原因：它先跑了一個不加狀態條件的查詢，結果分頁抓到 38,000 多筆歷史議題，然後花了好幾輪懷疑「是不是 JQL 沒生效」。它太謹慎——「先不過濾，抓回來看看有什麼」這個習慣在小資料集是美德，在跨專案查詢是災難。

一個補充實驗：環境知識值多少

第 3 題跑完後，我們沒有立刻回復快照，而是在同一環境下做了兩次追加測試：

那一段技能文件的補充，值大約 100 分鐘。 這是 27B 與 122B 最根本的差別：122B 是「知識在上下文裡，但執行時不調用」，我們補了三次文件它仍在同樣的地方犯錯；27B 是「給了知識就會用，沒給就自己去挖」。對 27B 而言，把環境知識寫進技能文件是有效的投資；對 122B 而言不是。

一個安全上的觀察

第 6 題中，27B 為了繞過需要人工核准的指令形式（curl | python），改為將完整的 API Token 明文寫進 curl 指令並印在對話中。雖然被 Agent 框架的安全掃描攔下、使用者也未核准，但 Token 已經出現在畫面上。

值得拆開來看的是：Token 是從哪裡流出去的？

模型跑在地端、Agent 跑在內網，Token 在推論過程中並沒有離開我們的網路——這正是地端部署的優勢。若同一件事發生在雲端模型上，模型讀取設定檔的那一刻，Token 就已經以 prompt 的形式送到供應商那邊了。

真正的外流點是對話介面。我們用 Discord 作為 Agent 的操作介面，模型輸出的任何內容都會經過 Discord 的伺服器。地端模型保護的是「模型看到什麼」，保護不了「模型說了什麼」。

更值得注意的是它為什麼這麼做。安全掃描攔下了 curl | python 這種指令形式，模型的應對不是停下來等待核准，而是找一條掃描沒攔的路——而那條路（明文 Token）比被攔下的那條更不安全。核准機制擋住的是指令的形式，不是風險本身；一個夠聰明的 Agent 會繞過形式，卻不一定理解風險。這是 Agent 框架設計上的通病，不是這個模型獨有的問題。

對應的做法有三層：在 Agent 的輸出層做敏感字串遮罩；在行為指示中明確要求「憑證一律以環境變數引用、絕不輸出完整內容」（27B 對這類指示是會遵守的）；以及測試結束後輪換憑證。這些都不是模型能力的問題，而是提醒：小模型在「達成目標」與「處理敏感資料」之間的取捨，仍需要框架層的防護，不能只靠模型自己判斷。

補充結論

原文的核心論點是「122B 級距的模型尚未跨過可託付的門檻」。27B 的結果顯示，問題不在參數量，而在模型的行為特性：

• 122B：快，但不可靠。會給出看似合理的錯誤答案，且不自知。
• 27B：可靠，但慢到不能用。六題全對，但單題動輒 30 分鐘到 2 小時。
• 550B：又快又可靠。

對「無人值守的 Agent 工作流」這個需求來說，122B 的失敗模式（錯誤不自知）比 27B 的失敗模式（慢）更危險——後者至少不會把錯的東西交出去。但 27B 的慢不是能靠硬體解決的：它的瓶頸是推理輪數，換更快的機器只能按比例縮短，不會改變量級。

所以結論其實更清楚了：在單台 DGX Spark 這個級距，你可以選「快但不能信」或「能信但等不起」，兩者都撐不起正式的 Agent 服務。 要兩者兼得，就要能跑得動 550B 這個級距的模型——而那不是 128GB 統一記憶體做得到的事。

至於 27B 適合什麼？它很適合不趕時間的離線批次任務——例如每天凌晨自動產出前一天的專案報表，早上到辦公室看結果。它會做對，也會誠實告訴你它做了哪些假設。這是 122B 給不了的。

後記-2：325 分鐘裡，有多少是硬體的問題？

2026 年 9 月補記

後記-1 的結論是：27B「可靠，但慢到不能用」，而且我們判斷它的瓶頸在推理輪數，換更快的機器只能按比例縮短，不會改變量級。

為了驗證這個判斷，我們把同一個模型（Qwen3.8-27B）搬到一張消費級顯示卡 RTX 5070 Ti（16 GB） 上，用同樣的六道題目、同一台測試機，每題前還原到同一個虛擬機快照（SOUL.md 與技能文件完全一致）。

結果：六題約 12 分鐘跑完。後記-1 的兩個判斷，我們必須更正。

兩邊的環境與參數

5070 Ti 端為了塞進 16 GB 的最終設定：權重採約 4 bit 量化、KV cache 降到 q4_0（hermes 要求 context 至少 64K，以 q8_0 開 64K 在處理長 prompt 時會記憶體不足）、ubatch 調為 256 以縮小運算暫存區；啟動後 VRAM 用量約 14.8 GB。hermes 端只將 context 上限設為 65,536，其餘不變；整個測試過程中對話壓縮從未被觸發。

六題結果對照

時間均以 Discord 上「送出題目」到「收到最終回覆」計算，以使用者體驗為準。Discord 時間戳只到分鐘，每題約有 ±1 分鐘誤差。

時間差在哪裡

第一，每個 token 的成本差了約 10 倍。兩邊服務日誌顯示，單一請求的生成速度，Spark 約 4.1 到 4.5 tok/s，5070 Ti 約 43 到 46 tok/s。生成文字時，每產生一個 token 都要把模型權重從記憶體讀一遍，速度主要受記憶體頻寬限制。估算上，Spark 每個 token 要讀約 54 GB 的 BF16 權重，理論上限約每秒 5 個 token；5070 Ti 只讀約 14.3 GB，理論上限約每秒 60 個。兩邊的實測值都貼近各自的上限。

第二，Spark 每一輪都在重做前面的工作。agent 每一輪都會把整段對話重新送給模型，光是系統提示與工具定義就有約 1.4 萬 token，之後還會隨對話不斷增長。5070 Ti 會重用上一輪已處理過的部分，每輪只處理新增內容；以第 1 題為例，整題實際處理的輸入量，幾乎等於最後一輪的對話長度，也就是每個 token 只處理了一次。Spark 上的 prefix caching 命中率是 0%，每一輪都從頭處理；我們推測這是 vLLM 對這類混合架構模型預設未啟用所致。

用 5070 Ti 的生成量換算 Spark 的純生成時間（估算，因兩邊每次的做法不盡相同）：六題合計約 107 分鐘，約是實際 325 分鐘的三分之一。第 1、6 題的估算值與實際值接近；其餘四題的實際值是估算值的 3 到 4 倍，差額主要來自每輪重複處理輸入，以及做法上的差異，例如第 3 題 Spark 當時先抓回了三萬八千多筆歷史議題。

更正：後記-1 的兩個判斷

「單機跑 27B 的生成速度遠高於 122B」——這是錯的。在同一台 Spark 上，27B 約 4.3 tok/s，122B 約 13 tok/s，27B 反而慢了三倍。

矛盾的來源在於：生成速度取決於「每個 token 要從記憶體讀多少資料」，而不是「總參數量」。122B-A10B 是 MoE 架構，每個 token 只啟用約 10B 參數，而且是 Int4 量化，每個 token 大約只讀 5 GB；27B 是 dense 架構，每個 token 要讀全部 27B 參數，而且是 BF16，大約 54 GB，是前者的十倍左右。我們當時憑「參數少就比較快」的直覺判斷，並沒有實測兩者的 tok/s。

「換更快的機器只能按比例縮短，不會改變量級」——這也是錯的。後記-1 說 27B 的時間大多花在推理上，這點沒錯：5070 Ti 上，生成仍占服務時間的七到九成。錯在低估了這個「比例」本身有多大。記憶體頻寬高了約 3.3 倍，量化後每個 token 要讀的權重又少了約 3.8 倍，理論上合計約 12 倍；再加上不必每輪重做 prefill，實際從約 325 分鐘降到約 12 分鐘，差了約 27 倍——比例本身就是一個量級。

真因有兩個：dense 的 BF16 模型遇上頻寬有限的統一記憶體，以及 prefix caching 沒有生效。兩者都和模型本身的「思考方式」無關。

代價：快了，但可信度打了折

精度。5070 Ti 上唯一答錯的是第 3 題：兩次執行都把「下週六」當成本週六，經一次提醒才修正。Spark 當時做對了，而且在同一輪推理裡反覆確認了三遍。但我們無法斷定原因是權重與 KV cache 的量化、取樣的隨機性，還是兩次測試的日期基準不同——Spark 並未以同一天的日期重測。

context 上限。64K 對 agent 工作偏緊。第 5 題重跑時，模型改走另一條路徑，一次拉回 Jira 的完整欄位清單，單一請求就衝到 51,296 token。我們觀察到 hermes 在同一則指令引發的連續工具呼叫之間不會壓縮對話；若某次工具回傳再大一些，請求就會超過上限而被拒絕，整題失敗。Spark 的 262K 完全沒有這個顧慮。

做法不穩定。同一題跑兩次，模型選擇的路徑可能完全不同，耗時也可能差到一倍，逐題時間只能當參考。

安全觀察（再次出現）。第 3 題與第 6 題中，模型都主動執行 env | grep 讀出環境變數中的 Jira 憑證，再直接用 curl 呼叫 API。憑證因此進入模型的上下文，並以明文 HTTP 傳到推論主機。這和後記-1 的觀察一致：憑證的保護不能只靠模型自律，需要框架與部署層面的防護，例如不讓 agent 直接讀取憑證本身、推論端改走加密連線。

修正後的結論

27B 在 Spark 上「等不起」，大半是平台造成的，不是模型本身的特性。同一個模型換到頻寬較高的顯示卡上，六題從五個多小時縮短到十幾分鐘，進入可用的範圍。

但 16 GB 的顯示卡必須靠量化才塞得下這個模型，而量化的代價落在可信度上：出現了 Spark 上沒有的錯誤，context 的空間也偏緊。所以後記-1「能信但等不起」這句話應該修正為：在 Spark 上等不起的，換到頻寬足夠的硬體就等得起；但為了塞進小顯示卡所做的壓縮，會讓「能信」打折。

至於 Spark 本身，要讓它跑得更快，可以嘗試的方向是降低權重精度（例如 FP8），以及讓 prefix caching 生效。這兩點我們尚未驗證，留待日後有機會再測。

資料來源：
NVIDIA，DGX Spark User Guide — Hardware Overview
NVIDIA 官方部落格，Calling All Creators: GeForce RTX 5070 Ti GPU Accelerates Generative AI and Content Creation Workflows，2025
Unsloth，Qwen3.8-27B-GGUF 模型卡（Hugging Face），2026
Nous Research，Hermes Agent 文件 — LLM and Model Providers
其餘數據皆為本次實測（vLLM 與 llama.cpp 服務日誌、Discord 時間戳）