消費級顯示卡跑出三倍速，為什麼還是撐不起一個部門？
小資源的極限：Strata 讓 16 GB 顯示卡跑得動大模型，然後呢？
摘要
前一篇〈小資源能跑 Agent，但撐得起一個部門嗎？〉的結論是：16 GB 的顯示卡跑得完 agent 任務，但很吃力；DGX Spark 調校後可以同時服務 3 個人。這一次，我們測試了一個主打「讓小顯示卡跑大模型」的開源推論引擎 Strata，用同一個 TCO 長文件任務，看它在速度、品質與人數上，能不能符合企業的需求。
| 面向 | 實測結果 |
|---|---|
| 速度（一個人用） | RTX 5070 Ti 搭配 Strata，每秒生成約 100～150 個 token，是 DGX Spark 上 vLLM 的 3～4 倍 |
| 人數 | 兩個人同時使用，就有訊息的等待時間超過單人時的 2 倍；在 16 GB 的卡上開啟同時處理，反而更慢 |
| 品質 | 8 輪測試的核心 TCO 數字全部正確，但每一輪都有推論或格式上的錯誤，仍需人工複查 |
| 硬體條件 | 顯示卡只要 16 GB，但系統記憶體依模型大小至少要 48～60 GB；本次測試把主機的系統記憶體擴充到 128 GB |
結論是：Strata 讓一張消費級顯示卡，成為一個人用起來很快的 agent 工具；但企業需要的是多人同時使用、穩定可管理的服務，這一點它做不到。
為什麼測 Strata
前一篇在 16 GB 的顯示卡上，只能跑 27B 的模型，context 也只能開到 64K，agent 的背景作業很容易撞牆。Strata 用了不同的思路：它把 MoE 模型中最常用的 expert 放在顯示記憶體，其餘放在系統記憶體，讓 16 GB 的顯示卡也能執行總參數約 176B 的 Qwen3.8-Flash-Next，context 可以開到 262K。
如果這個做法可行，企業是不是用一般的工作站，就能讓員工使用 agent？這是本次要回答的問題。
測試方式
- 任務：沿用前一篇的 TCO 長文件任務。四則訊息，讓 agent 讀報價單、計算 TCO、套用公司範本產出文件，再經過兩輪修訂
- 平台：RTX 5070 Ti（16 GB）使用 Strata 官方版；DGX Spark 使用社群移植的 Arm 版本，並以 Spark 上原本的 vLLM 作為對照
- 量化方式：在 5070 Ti 上比較三種：IQ2_XS（約 2-bit）、IQ3_XXS（約 3-bit）、UD-IQ4_XS（約 4-bit）
- 多人使用：重播一位使用者完整的模型請求，同時送出 1 份、2 份，比較等待時間；另外測試 Strata 的「同時處理 2 個請求」選項
第一輪遇到的三個問題，以及調整方式
第一輪在 DGX Spark 上，照安裝程式與移植版實測過的設定執行，四則訊息花了 53.6 分鐘。追查紀錄後，發現三個問題，各自對應一項設定：
| 問題 | 現象 | 調整 | 調整後 |
|---|---|---|---|
| 沒有設定取樣參數 | Strata 在請求沒有指定取樣方式時，會改用「每次都選機率最高的字」的貪婪解碼。有一次模型在思考中陷入重複，一路輸出到 65,536 個 token 的上限，花了 13 分鐘，回覆卻是空的 | 在 Strata 的設定中加上取樣參數（temperature 1.0、top_p 0.95、top_k 20），和模型官方建議值、Spark 上 vLLM 實際使用的參數相同 | 之後的輪次都沒有再發生 |
| 一次只保留一段對話的快取 | agent 的背景檢討和主任務是兩段不同的對話，交替送出請求時，會互相把對方的快取擠掉，每次都要重新讀取數萬個 token | 開啟 Strata 的多段對話快取，最多保留 4 段對話 | 重疊期間的快取命中率維持在 87～100% |
| context 只開 131K | hermes 的壓縮門檻跟著變低；hermes 粗估的 context 比實際高出約 7 倍，誤觸發了一次 5 分鐘的壓縮 | context 改為 262K，和前一篇的設定相同 | 門檻提高後，大多數輪次不再誤觸發 |
以下的結果，除非特別說明，都是調整後的數據。另外要說明：hermes 粗估 context 的方式本身會高估，在 262K 的設定下，仍有兩輪被誤觸發了壓縮（粗估約為實際的 2 倍）。這是 hermes 端的問題，和推論引擎無關。
測試條件說明
一、每種設定只跑一至兩輪，agent 每一輪走的路徑、產出的內容量差異很大，單輪數字只代表一次結果。
二、Spark 上的 Strata 是社群移植版，版本和 5070 Ti 上的官方版不同。
三、Strata 不支援強制輸出長度，所以多人重播時每份的輸出量不完全相同，方法和前一篇 Spark 的並發測試不同，數字不能直接比較。
四、文件中的金額與報價資訊一律不揭露。
速度：一個人用時，消費級顯示卡最快
各平台、各量化方式的單一請求生成速度（橫線為實測範圍）
5070 Ti 搭配 Strata，用 IQ3_XXS 時每秒約生成 100～128 個 token，用 IQ2_XS 時約 130～160 個，是 DGX Spark 上 vLLM（約 35 個）的 3～4 倍。同樣的 Strata 和 IQ3_XXS，放在 Spark 上只有約 52～60 個。
為什麼 16 GB 的卡比 128 GB 的 Spark 快
每次生成時，expert 由誰計算（取自各平台一次大量輸出的引擎紀錄）
從引擎的紀錄看，同樣使用 IQ3_XXS 時，兩個平台都有約 97% 的 expert 是由 GPU 計算的，由 CPU 計算的只有約 3%。差別在於 GPU 讀取權重的速度：5070 Ti 的記憶體頻寬約 896 GB/s，DGX Spark 是 273 GB/s，相差約 3.3 倍，實際生成速度相差約 2.1 倍（推論）。
量化方式也有影響：量化越精細，每個 expert 越大，顯示記憶體放得下的比例越低。UD-IQ4_XS 只有約 80% 的 expert 能在顯示記憶體中計算，速度只剩 IQ3_XXS 的一半左右。
記憶體大不等於快，頻寬才是關鍵。Spark 有 128 GB 的統一記憶體，但受限於頻寬；5070 Ti 只有 16 GB 的顯示記憶體，但把最常用的 expert 放在高頻寬的顯示記憶體中，速度就拉開了。
總耗時不能直接比快慢
各輪的工作量與四則訊息合計耗時（不含使用預設設定的第一輪）
同一個任務、同一組設定，agent 每一輪產出的內容量可以相差好幾倍。5070 Ti 上兩輪 IQ3_XXS 的測試，四則合計分別是 40.4 分鐘和 21.4 分鐘，前者的輸出量是後者的 1.6 倍，又剛好遇到背景作業與訊息重疊。比較平台和引擎的快慢，應該看生成速度，而不是單輪的總耗時。
人數：一次只能好好服務一個人
即使只有一個人使用，agent 的背景檢討也會和主任務同時送出請求。Strata 預設一次只處理一個請求，其他請求要排隊；在單人測試中，就已經看到背景檢討和下一則訊息互相等待的情況。
兩個人同時使用
重播一位使用者的完整請求：1 人與 2 人同時使用時，各則訊息的耗時（虛線為單人的 2 倍）
只有一個人時，同一份工作約 7.6 分鐘就完成（重播時的輸出量約為原始任務的 82%）。兩個人同時使用時，第 2 位使用者的訊息 2 等了 256.6 秒，是單人時的 2.22 倍，超過「不超過單人 2 倍」的標準。這一則的輸出量和單人時只差 6%，多出來的時間幾乎都是在等另一個人的請求。
要說明的是，即使是這一則最慢的訊息，也比 DGX Spark 上 vLLM 單人時的同一則訊息（374.9 秒）快。這個標準是相對於自己的單人速度：單人越快，越容易被判定未通過。但對使用者來說，「別人一用，我就要等」的體驗是一樣的。
開啟同時處理，反而更慢
Strata 開啟「同時處理 2 個請求」前後的生成速度（RTX 5070 Ti，IQ3_XXS）
Strata 提供同時處理多個請求的選項，但在 16 GB 的卡上，結果是負面的：
- 只有一個請求時也變慢約 25～30%：同時處理需要預留顯示記憶體，能放的 expert 變少了
- 兩個請求重疊時，每個只剩約 30 個 token／秒，兩個合計約 65 個，比一次一個、讓單一請求全速執行（約 120 個）還慢
這和 Strata 官方文件在 RTX 5070（12 GB）上的實測一致：同時處理兩個請求時，每個請求約 32.6 個 token／秒，合計比一次一個慢 15%。官方文件的說法是，這個選項換到的是「等待時間」，不是速度。
一張消費級顯示卡加上 Strata，是一個人的工具，不是一個部門的服務。前一篇的 DGX Spark 用 vLLM，可以同時服務 3 個人；這次的 5070 Ti，在第 2 個人加入時就開始互相排隊。
品質：能完成，但仍需人工複查
我們逐項驗算了 8 輪測試的最終版文件：
| 項目 | 結果 |
|---|---|
| 核心 TCO 數字 | 8 輪全部正確 |
| 敏感性分析與推論 | 多數輪次都有錯誤，例如正負號弄反、推論方向寫反（把「使用率越低越不利租用」寫成相反）、最不利情境選錯 |
| 文件格式 | 差異很大：有的輪次版面完整，有的輪次目錄損壞、表格欄寬錯亂；部分輪次混入簡體字 |
- 格式的好壞，和平台、引擎、量化方式都看不出關係：同樣是 5070 Ti 加 IQ3_XXS 的三輪，有一輪版面最好，有一輪目錄損壞。格式主要取決於 agent 每一輪自己寫的填寫程式（推論）
- 量化精度和品質的關係無法判斷：每種量化只跑一至兩輪，看不出 4-bit 是否比 2-bit 更可靠
- 錯誤的類型不固定：這一輪對的地方，下一輪可能出錯，無法靠一次驗證就放心
和前一篇的結論相同：這類任務的產出可以作為初稿，但交給客戶之前，仍需要人工複查。
DGX Spark 上的 Strata
Strata 在 Spark 上，每個 token 比 vLLM 快（約 57 對 35 個／秒），但兩輪調整後的測試，四則合計約 31～32 分鐘，和 vLLM 的 25～37 分鐘在同一個範圍內。Spark 上的 Strata 也是一次只處理一個請求，而前一篇實測 vLLM 可以同時服務 3 個人。所以 Spark 的長期服務，我們維持使用 vLLM。
對企業的意義
小資源適合做什麼
一張 16 GB 的顯示卡，加上 64 GB 以上的系統記憶體和 Strata，可以讓一個人流暢地使用 agent，速度甚至比 DGX Spark 快。這很適合個人的工作流程驗證與 POC：確認 skill 寫得對不對、任務拆解是否合理、哪些地方需要人工把關。
企業需要的，是另一回事
- 多人同時使用：agent 的負載本來就會因背景作業而重疊，部門裡多人同時使用時，需要能同時處理大量請求、而且合計速度隨人數提升的推論服務。一次只處理一個請求的架構，從第 2 個人就開始排隊
- 頻寬與容量：速度取決於記憶體頻寬，能同時服務的人數取決於顯示記憶體容量。兩者都要足夠，才能讓每個人都用得順
- 穩定與可管理：Strata 仍在快速演進中，預設設定在 agent 任務中會出問題；Spark 版本還要仰賴社群移植。正式環境需要的是成熟、可長期維護的推論平台，以及存取控制與資源調度
不同規模的平台各能同時服務多少人，請參考前一篇〈小資源能跑 Agent，但撐得起一個部門嗎？〉的推估；GPU 資源的分配與治理，可以參考我們的 Run:ai 實測。
規劃 AI agent 平台時，建議先在小資源上把工作流程驗證清楚，再依「同時使用的人數」來規劃正式環境，而不是只看單人時的速度。
後記-1：同場加映——NVIDIA Nemotron 3.5 Super VL
Strata 測完不久，NVIDIA 釋出了 Nemotron 3.5 Super VL。它是總參數 120B、每個 token 啟用約 12B 的視覺語言模型，採用 Mamba 與 MoE 混合的架構，可以輸入影像與影片。vLLM 的官方部署範例也列出了單台 DGX Spark 的設定，可以搭配 LiLiCorr 草稿模型做推測解碼，每次推測 7 個 token。我們用同一個 TCO 長文件任務，在 DGX Spark 上把它和原本的 Flash-Next（vLLM）比較，各跑兩輪。
生成速度快了兩成多，任務卻沒有變快，產出的文件也無法交付。
Flash-Next 與 Nemotron 3.5 Super VL 各兩輪的生成速度（左）與四則訊息合計耗時（右）
| 項目 | Flash-Next（兩輪） | Nemotron 3.5 Super VL（兩輪） |
|---|---|---|
| 生成速度 | 每秒 37.7、36.2 個 token | 每秒 46.5、46.2 個 token |
| 推測解碼：每一步平均產生 | 約 2.3 個 token（最多 3 個） | 約 5.0 個 token（最多 8 個） |
| 四則訊息合計 | 37.0、24.7 分鐘 | 28.1、36.5 分鐘 |
| 主任務的輸出量 | 約 4.7 萬個 token（一輪的統計） | 約 6.4 萬、7.2 萬個 token |
| hermes 的指令核准判斷 | 7 次（一輪的統計） | 25、31 次 |
| 最終文件 | 內容完整，錯誤集中在說明文字的計算與推論 | 兩輪都無法交付 |
表中的生成速度，是任務期間推論引擎紀錄的平均值，背景作業與主任務重疊時會被墊高，所以 Flash-Next 的數字略高於前文單一請求時的約 35 個。
為什麼速度快了，任務卻沒有變快
- 輸出量多了 36～53%：主任務的輸出量比 Flash-Next 多出這麼多，但每則回覆的文字都很短，多出來的應該大多是思考內容和程式碼（推論）
- 核准判斷是 Flash-Next 的 3.6～4.4 倍：hermes 執行部分指令前，會先呼叫模型做一次核准判斷，agent 要等判斷完成才能繼續。這次 agent 反覆執行會刪除、覆寫檔案的腳本，核准判斷因此大增（推論）
- 同一設定的兩輪也相差 8 分鐘：和 Flash-Next 兩輪相差 12 分鐘的情況類似。以兩輪的結果來看，兩個模型的總耗時看不出明顯差別
文件的問題
- 只交出範本：要求依公司範本產出文件時，兩輪都只改了封面或日期就交件，正文還是範本的範例文字。其中一輪還反問要放在哪一章，違反了「不要提出澄清問題」的指示
- 範例內容沒有清掉：兩輪的最終版都保留了範本的範例內容，TCO 的內容只是接在後面
- 結論和自己的表格矛盾：表中「租金降 20%、3 年、不含 AIE」時，租用已經比自建便宜；一輪的結論卻寫自建在所有情境下都比較省，另一輪則寫「差距會縮小」
- 回報與事實不符：一輪交出 Word 無法開啟的檔案，回覆卻說「已驗證 ZIP 完整性正常，可直接開啟檢視」
- 檔名沿用範本：一輪直接用範本的檔名作為輸出的檔名
算術本身都正確。中文方面沒有混入簡體字，但第一輪的回覆中常出現「用戶」「模板」「字符」等中國大陸用語。相較之下，Flash-Next 的兩輪都交出了完整的文件，錯誤集中在說明文字的計算與推論。
測試條件說明
一、只測了文件型的 agent 任務，沒有測視覺能力，而視覺正是這個模型的主要特色。本次唯一用到視覺的地方，是我們回報錯誤截圖時，hermes 先請它把截圖轉成文字描述。
二、各只跑了兩輪；agent 框架是 hermes，換用其他框架，結果可能不同。
三、推論引擎使用 vLLM 的 nightly 映像檔，設定以 NVIDIA 提供的 DGX Spark 設定為基礎，只調整同時處理的請求數（1 改為 4，讓背景作業不必排隊）和 context 長度（262,144，與前文一致）。vLLM 官方部署範例中的 Spark 設定，則是 v0.31.0 映像檔、純文字模式、context 114,688。我們判斷同時處理的請求數與 context 上限，不會改變模型輸出的內容；映像檔版本的差異是否有影響，則無法判斷（推論）。
四、測試時模型才釋出幾天，推論引擎與工具呼叫的支援可能仍在調整。
以我們的文件型 agent 任務來看，DGX Spark 維持使用 Flash-Next。和本文的 Strata 一樣，速度只是其中一環：評估模型時，還是要用自己的實際任務，看最後交出來的東西。
測試日期：2026 年 10 月 18 日
資料來源
- Niko1221，Strata（官方版）README、docs/DETAILS.md（expert 命中率的定義）、docs/BATCHING.md（同時處理多個請求的設定與 RTX 5070 上的實測）：https://github.com/Niko1221/Strata
- shi3z，Strata-DGX-Spark（Arm 移植版）：https://github.com/shi3z/Strata-DGX-Spark
- NVIDIA，DGX Spark Hardware Overview（273 GB/s）：https://docs.nvidia.com/dgx/dgx-spark/hardware.html
- Guru3D，GALAX GeForce RTX 5070 Ti 1-click OC White 評測（RTX 5070 Ti 記憶體頻寬 896 GB/s；評測媒體資料，非 NVIDIA 官方文件）：https://www.guru3d.com/review/galax-geforce-rtx-5070-ti-1click-oc-white-review/
- vLLM Recipes，NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-NVFP4（模型規格與各平台的部署設定，含 DGX Spark）：https://recipes.vllm.ai/nvidia/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-NVFP4
- NVIDIA，NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-NVFP4 模型頁面（Hugging Face）：https://huggingface.co/nvidia/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-NVFP4
- 其餘數據皆來自本次測試的 hermes、LiteLLM、Strata、vLLM 紀錄與重播結果