本地模型能撐起 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