Qwen3.8 Flash Next 地端實測：一台 GX10 跑大型 MoE，長文件生成速度穩定

本次受測的是站長在第二台 GX10 上長期運作的 llama.cpp llama-server 服務，本站沒有更動任何設定，模型全部放在 GPU，並開四個並行槽、共用 KV 快取。模型檔為 unsloth 發布的量化版本，依官方規格屬於 MoE 架構，每個 token 只啟用總參數中的一小部分，並採用混合注意力設計。量測時送原始提示詞、不開思考、關閉提示詞快取，並在每個請求前加上不重複的前綴，避免快取讓數字失真。

重點

• 本站實測深度0 生成速度 26.5 tok/s，到 32,768 深度仍有 24.4 tok/s，降幅只有 8%。
• 提示詞處理在長輸入時約 728 至 764 tok/s，和參考組的倍數是 1.0，長文件的首字延遲主要卡在這一段。
• 輸入 33,279 token 時首字延遲 46.3 秒，長文件問答要預期近一分鐘的等待。
• 四人並行時合計吞吐 24.4 tok/s，是單人的 1.6 倍；超過四個並行槽就開始排隊。
• 生成速度約為參考組的 1.2 至 1.4 倍，但參考組是不同推論引擎、不是同條件對照。
• 測試期間 GPU 最高溫度 89 °C，長時間服務需留意散熱。

測試平台

原廠規格出處：NVIDIA DGX Spark／GB10；模型規格：Qwen3.8 Flash Next 模型頁。

測試方法

• 受測的是站長在第二台 GX10 上長期運作中的 llama.cpp llama-server 服務，本站沒有改動它的任何設定：模型全部放在 GPU（-ngl 999）、上下文 131072、4 個並行槽（--parallel 4，KV 快取共用）。
• 模型檔為 unsloth 發布的 UD-IQ4_XS 量化（約 88 GB，分三個檔案）。Qwen3.8 Flash Next 官方規格：總參數 125B、每個 token 啟用 6B，另有 51B 的 n-gram 嵌入；混合注意力（Gated DeltaNet 與 Qwen Sparse Attention 交錯），原生上下文 262144。
• 量測透過 llama-server 的 /completion 端點送原始提示詞（不套聊天模板、不開思考），關閉提示詞快取，並在每個請求前加不重複的前綴；生成速度與提示詞處理速度取伺服器回報的計時。每個測項前先確認 4 個槽都閒置，避免和正式使用者的請求重疊。
• 參考組是第一台 GB10 上以 Ollama 0.32.13 跑的 qwen3.8:27b（Q4_K_M，27.3B 全參數啟用），推論引擎不同，不是同條件對照，只用來說明模型架構造成的量級差異。
• Ollama 0.32.13 對 qwen3.8:27b 的架構不支援並行請求，同時送多個請求只會排隊；llama.cpp 這台設了 4 個並行槽，可以同時處理 4 個請求，第 5 個以後排隊。

結果

生成速度與上下文深度

本站實測深度0 的生成速度為 26.5 tok/s，深度 2,048 為 26.1 tok/s，深度 8,192 為 25.5 tok/s，深度 16,384 為 25.2 tok/s，到 32,768 仍有 24.4 tok/s。從深度0 到 32,768 生成速度只下降 8%，曲線相當平緩。對一般對話與長文件摘要來說，輸出階段的體感在不同文件長度下差異不大。

讀入長文件的速度

提示詞處理在深度0 只有 218 tok/s，這是因為實際輸入僅 46 token，計時中固定開銷占比偏高，不代表真實處理能力。輸入拉長後數字回到穩定區間：2,109 token 為 734 tok/s、8,358 token 為 764 tok/s、16,665 token 為 757 tok/s、33,279 token 為 728 tok/s。各深度和參考組的提示詞處理倍數都是 1.0，代表兩者在讀入長文的效率上屬於同一量級。

首字延遲

首字延遲隨輸入長度大致線性增加：深度0 為 0.3 秒，2,109 token 為 3.0 秒，8,358 token 為 11.2 秒，16,665 token 為 22.4 秒，33,279 token 則來到 46.3 秒。也就是說，丟進一份三萬多 token 的文件，使用者要先等將近一分鐘才看到第一個字。實務上若同一份文件會被反覆提問，開啟提示詞快取可減少重算，本次為了量測而刻意關閉。

多人同時使用

本站實測單人時合計吞吐 15.3 tok/s、單請求生成 26.1 tok/s，首字延遲中位 3.5 秒；兩人並行時合計吞吐 21.3 tok/s，單請求降到 21.1 tok/s。四人並行時合計吞吐 24.4 tok/s，是單人的 1.6 倍，單請求 15.2 tok/s，首字延遲中位 12.5 秒。到八人並行，合計吞吐停在 24.1 tok/s，單請求只剩 11.1 tok/s、首字延遲中位升到 21.5 秒，因為這台只設四個並行槽，超出的請求只能排隊。

和 27B 模型比

參考組是第一台 GB10 上以 Ollama 跑的 qwen3.8:27b，全參數啟用，屬於不同推論引擎、不是同條件對照，只用來說明架構造成的量級差異。生成速度方面，Flash Next 在深度0 是參考組的 1.2 倍，深度 2,048 與 8,192 為 1.4 倍，深度 16,384 與 32,768 為 1.3 倍，參考組從深度0 到 32,768 下降 18%，Flash Next 只降 8%。生成階段每產生一個 token 都要讀取一次啟用中的權重，MoE 每個 token 只啟用少量專家，記憶體頻寬負擔較輕，因此雖然總參數大得多，輸出反而較快；提示詞處理倍數都是 1.0，顯示讀入階段沒有同樣的優勢。另外參考組所用的引擎不支援這個架構的並行請求，多人時只會排隊，八人並行首字延遲中位達 37.2 秒，並行數字不宜直接相比。

穩定性與散熱

本站實測期間 GPU 最高溫度為 89 °C。這台主機同時承擔正式服務，長時間高負載下溫度偏高，建議部署時確認機身通風與周邊散熱空間，並持續監看溫度紀錄。

結論

結論是可以用：這個含嵌入在內的大型 MoE 模型能完整放進一台 GX10 的 GPU，生成速度在 24.4 至 26.5 tok/s 之間，從短提示到 32,768 深度只降 8%。長文件的瓶頸在首字延遲，三萬多 token 要等 46.3 秒，適合可接受先等待、再穩定輸出的文件摘要與問答；多人使用時四人並行合計吞吐是單人的 1.6 倍，適合小團隊共用，但超過四個並行槽就會排隊，八人時首字延遲中位達 21.5 秒。設定上建議讓模型全部放在 GPU、依團隊人數調整並行槽數量、正式使用時開啟提示詞快取以減少重複讀入，並留意 89 °C 的高溫表現。

附錄：完整數據

測試與撰寫：本站程式（量測 aiwv.bench_llamacpp；數據表與圖表由資料庫填值；分析段落由 Claude 依實測數據撰寫並經程式核對數字）。未經人工審閱，發現錯誤請回報。