Qwen3.8 Basalt 基準測試報告：16GB VRAM 下達每秒 153 個 Token
10 月 25 日發布的 Qwen3.8 Basalt 基準測試結果顯示，儘管 RTX 5080 的顯示記憶體上限為 16GB，仍錄得每秒 153 個 Token。該工作站亦使用了 54.1GB 系統記憶體。貼文標題強調生成速度超過每秒 250 個 Token，但這個數字反映的是短暫峰值，而非持續輸出。
對正考慮本地程式編碼助理的開發者而言，這項分別相當重要。發帖者表示，該工作階段處理了 103 個請求；另一次測試則以不同內容長度處理全新提示詞。這些工作負載為回應速度提供了有用證據，但兩者均不能證明程式編碼準確性，亦未經獨立驗證。
核心矛盾在於，如何將大型模型放入工作站，同時保留實用速度與可接受的輸出品質。專門的推理引擎 Basalt，正與 Strata 及 llama.cpp 等更廣泛的替代方案競爭這類工作負載。這份報告支持進一步研究此一方法，而不是概括地宣稱顯示記憶體容量已不再重要。
Qwen3.8 Basalt 基準測試區分峰值與持續速度
最有參考價值的生成數字是報告中的平均值：編碼期間每秒 153.0 個 Token，內容掃描期間則為每秒 154.9 個 Token。
Token 是語言模型處理或產生的文字單位。每秒 Token 數量衡量吞吐量，但並不直接衡量生成的程式碼是否可正常運作。發帖者區分平均輸出與峰值輸出的做法，應保留在所有對這些結果的摘要之中。
RTX 5080 基準測試將模型配置列為 Qwen3.8-Flash-Next IQ3_S。IQ3_S 是一種量化格式，即以較低數值精度表示模型權重。這項配置是結果身分的一部分，而非可隨意互換的細節。
報告中的工作站將 RTX 5080 配搭 Core Ultra 9 285K 處理器及 62GB DDR5-6800 記憶體。顯示記憶體使用量達 15.7GB。據報，引擎佔用了 54.1GB 系統記憶體，編碼期間剩餘 5.2GB，掃描期間則剩餘 5.1GB。
編碼工作階段透過程式編碼代理介面 opencode 處理 103 個請求，內容長度約達 130,000 個 Token。內容是模型產生回應時可用的資訊。消息來源報告的設定容量約為 262,000 個 Token，高於編碼工作階段觀察到的深度。
根據發帖者資料，按生成 Token 與解碼時間計算，生成速度平均為每秒 153.0 個 Token。解碼時間是產生輸出 Token 所花的時間。報告中每秒 262 個 Token 的峰值，反映的是單一最佳秒數，而非完整請求或工作階段。
另一項掃描使用約 15,000 至 207,000 個 Token 的全新提示詞。其生成平均速度達每秒 154.9 個 Token，峰值為 186.6。發帖者稱，這些數據以請求平均值計算，使用 384-Token 回應、0.7 採樣溫度，並在每個深度測試兩次。
這些定義可避免誤導性的解讀。單秒最高值與請求層級平均值描述的是不同觀察結果。兩者雖同樣以每秒 Token 數量表示，卻不應因而互相取代。
持續速度數字亦令報告比單看標題更值得留意。程式編碼工作流程需要在重複互動中維持一致回應。短暫爆發可協助描述系統特性，但開發者最終面對的是完整請求、中斷、工具執行及修正。
這些仍屬自行報告的測量結果。現有證據確認了發帖者所報告的內容，並解釋了測量類別；但並不能證明另一部工作站可重現結果，亦不能證明每個請求均維持整體平均速度。
快取重用改變回應時間的意義
報告中 0.2 秒的回應開始時間中位數，來自提示詞 Token 快取重用率達 99.5% 的工作階段。
提示詞快取會重用先前輸入已計算的資訊，而不是再次處理相同內容。這種行為對程式編碼工作階段尤其重要，因為連續請求往往共享對話記錄、儲存庫資料及指令。重用這些運算成果，可令持續進行的工作階段感覺明顯更靈敏。
發帖者報告，99.5% 的提示詞 Token 來自提示詞快取。首個 Token 的中位時間為 0.2 秒。首個 Token 時間衡量的是輸出開始前的延遲，而不是完成答案所需時間。
綜合來看，這些數據描述了一種有利於重複互動的工作負載。它們並不顯示引擎能讀取一個完全陌生、很長的儲存庫提示詞，並在相同延遲內開始作答。全新請求必須另行評估。
消息來源透過其未快取處理數據，部分回應了這項分別。對編碼工作階段而言，提示詞處理平均為每秒 5,011 個 Token，峰值為 5,118。發帖者表示，這些數據代表兩次大量未快取讀取，分別包含約 10,700 及 8,000 個新 Token。
提示詞處理是生成答案前吸收輸入所需的運算。由於模型在這些階段執行不同工作，其吞吐量與生成吞吐量並不相同。將兩者合併為單一速度說法，會掩蓋讀者所需資訊。
全新提示詞掃描報告的提示詞處理吞吐量平均為每秒 5,475 個 Token，峰值為 5,662。這為輸入處理提供了另一項觀察。每當有人描述引擎回應速度時，這些數據都應與高度依賴快取的編碼結果一併呈現。
對開發者而言，影響取決於工作如何累積內容。反覆處理同一項目的助理可受惠於保留的運算成果；而經常替換文件或轉換儲存庫的工作流程，則是另一種工作負載。
試想一個代理讀取項目、提出修改建議、收到編譯器錯誤後再修訂補丁。大量周邊資訊在這些回合之間仍然相關。因此，即使模型本身的生成速度不變，快取行為仍可影響使用體驗。
再考慮一名分析師每天開啟互不相關的文件集合。可重複使用的內容可能較少。若把編碼工作階段的中位回應延遲套用至這種工作流程，便需要貼文未有提供的證據。
因此，快取是報告結果中的實質部分。它說明了為何用戶應先檢視自己的請求模式，才將基準測試視為預測。關鍵問題是其應用程式實際能重用多少運算。
系統記憶體承擔工作站的取捨
16GB 顯示卡是此配置的核心，但報告中的工作負載同時依賴 54.1GB 系統記憶體。
VRAM 是連接到圖形處理器的記憶體，而系統 RAM 則服務整部電腦。這份報告同時使用兩者。若只透過顯示卡來描述結果，便會低估涉及的機器資源，亦會掩蓋潛在使用者面對的實際限制。
專家記憶體設計將 Basalt 描述為針對 NVIDIA Blackwell 硬件的 Strata 分支。它運行混合專家模型，會選擇專門的模型組件進行運算。超出顯示記憶體容量的專家組件可置於系統 RAM 中。
這項設計解釋了整體方法，但並未獨立驗證這項特定基準測試。項目文件確認使用系統記憶體是有意為之；Reddit 的測量結果則提供了指定工作站的報告速度及記憶體使用量。
實際壓力落在決定現有機器能否支援本地助理的開發者身上。單看顯示記憶體容量並不足夠。可用系統記憶體、其他應用程式及工作負載的內容需求，都應納入同一評估。
報告中的可用記憶體數字尤其值得注意。編碼時保留 5.2GB 可用記憶體並不代表系統不穩定，但確實反映該測試機器的備用容量有限。編輯器、瀏覽器、建置程序或其他本地服務都會帶來額外需求。
這並不意味每部相近工作站在一般開發情況下都會失敗。它意味著該基準測試不能保證舒適的多工體驗。用戶需要在實際開發環境運行時進行測量，而非只在推理引擎獨立運作時測試。
同樣的推理亦適用於顯示記憶體讀數。報告中 15.7GB 的使用量接近該顯示卡標示的 16GB 容量。這項觀察應避免人們假設仍有大量空間可供無關的圖形工作負載或不同引擎設定使用。
這正是標題吸引力與實際操作取捨相遇之處。報告描述的是一種將工作負載分配到可用資源、令其得以容納的策略；它並不是描述模型完全在有限顯示記憶體預算中運行。
採購決策因此應從整部工作站開始。為原本資源受限的機器加裝相容顯示卡，並不能重現報告中的環境。即使記憶體容量相同，亦未必能重現處理器行為、軟件設定或持續吞吐量。
知識密集型應用程式還有另一項考慮：整理來源資料與運行模型是兩回事。可搜尋知識庫處理的是文件存取，而此基準測試關注的是輸入送達引擎後的運算。
實用的結論很具體。評估這項配置的開發者，應同時為推理與周邊工具預留記憶體。報告中的速度令這項評估值得進行，但系統記憶體需求仍是結果的核心。
Strata 與 llama.cpp 需要在相同條件下比較
這份工作站報告並未建立 Basalt、Strata 及 llama.cpp 之間受控的效能排名。
標題同時提及 Strata 與 Basalt，但所提供的工作負載描述確認使用的引擎是 Basalt。讀者應保留這項分別。分支項目的結果不應自動變成其母項目的效能聲稱。
Strata 為 Basalt 提供技術脈絡，而 llama.cpp 則提供另一個相關的本地推理參考點。它們的存在構成競爭背景，但若沒有配對的模型檔案、設定、硬件及請求序列，便不足以宣稱誰勝誰負。
推理基準測試文件區分提示詞處理與文字生成，並支援在指定內容深度下進行測試。它亦會記錄重複測量。這些類別說明，進行比較不能只把標題中的吞吐量數字並排放置。
一項對照測試應讓不同引擎處理可辨識的相同工作負載。測試應以相同的提示詞、回應長度、模型表示方式及上下文條件為基準。否則，表面上的軟件優勢可能包含了設定中其他環節的差異。
快取條件也應獲得同等處理。將一個已預熱的編碼工作階段與陌生提示詞相比，會在生成開始前已令後者處於劣勢。兩種情況都具參考價值，但回答的是不同的營運問題，應分開呈現結果。
若要將差異歸因於某個引擎，硬件配置亦必須保持固定。其他使用者較快的顯示卡或較大的記憶體預算，會引入額外變數。這些資料可指引進一步探索，卻不能證明軟件本身帶來了甚麼貢獻。
輸出行為帶來另一個複雜因素。推測式解碼會使用草稿 token，由模型在接受輸出前進行核對。任何涉及這類加速的比較，都應披露其設定，並驗證被量度的配置保留了哪種行為。
相關標準是對確切測試過程保持透明。讀者應能識別模型產物、軟件修訂版本、配置及量度方法。熟悉的模型名稱並不保證數值表示方式或輸出完全相同。
對於取代託管編碼服務的說法，也應採取同樣審慎的態度。本報告量度的是編碼工作階段中的本地推理行為，並未提供已完成任務、開發者介入、服務可靠性或整合成本相對於託管替代方案的對照評估。
對引擎維護者而言，競爭壓力在較狹義的層面上依然存在。一份前景可觀的工作站報告，會讓使用者有理由研究專門化實作。真正重要的回應，是可重現的證據，說明各引擎在哪些方面表現出色。
對開發者而言，候選清單比排名更有理據。Basalt 值得在相容硬件上測試，因為報告所述的持續速率與互動式工作有關。Strata 和 llama.cpp 仍是比較候選者，其行為需要在相同條件下量度。
快速生成並不代表編碼品質已獲證實
缺失的一環是任務表現：報告量度了輸出速度，卻未證明生成的程式碼能否可靠地解決問題。
相較於孤立的文字生成，編碼工作階段提供了更易辨識的工作負載。它顯示代理介面曾發出重複請求。然而，單靠請求次數無法反映編輯是否成功、測試是否通過、有否不必要的重試，或人手修正。
這項區別在量化情況下尤其重要。降低數值精度會改變實際執行的模型表示方式。即使配置更快或更小，仍須針對使用者擬分派的任務進行評估。
已發布的 量化模型評估 使用文字片段及較高精度的參考模型，提供了有限的品質證據。這項比較有助描述模型行為，但不足以證明修復儲存庫的準確度、可靠的工具使用能力，或長上下文編碼的成功率。
長上下文帶來相關的驗證缺口。系統可以接受很長的提示詞，卻未必能可靠地套用每項相關細節。即使兩者都影響同一使用者體驗，處理容量與該輸入中的檢索準確度仍是不同特性。
因此，上下文掃描支持的是有限度的解讀。它報告了不同長度的新提示詞下的吞吐量，卻未證明模型能否持續找出深藏的要求、調和互相衝突的指示，或在編輯程式碼時保留專案限制。
整體生成速率也令體驗分布不夠清晰。平均值可以概括一個工作階段，卻可能掩蓋較慢的請求。等待困難編輯的開發者，或許更在意這些延遲，而非最佳的短暫峰值。
同樣的限制亦適用於回應開始時間的中位數。中位數描述的是中間觀測值，並不能說明最長等待時間、快取未命中後的行為，或收到完整可用修補程式所需時間。
並行性，即同時發出的請求，增加了另一個界限。簡報指出並行度為一。這使結果與個別串流相關，但沒有提供估算團隊共用容量或代理請求重疊時效能的依據。
這些缺口應塑造解讀方式，但不應抹殺已報告的成果。來源提供了明確的量度定義，並區分不同工作負載類型。這些細節令其說法比一張只顯示最高速度、未作解釋的截圖更易評估。
獨立重現應在現有吞吐量類別以外加入任務結果。實用的編碼評估會記錄測試是否通過、變更是否符合要求，以及人手介入的頻率。它亦應保留失敗案例，而非只報告成功運行。
對 Qwen3.8 Basalt 基準測試而言，尚待解答的問題是，所報告的反應速度是否伴隨可靠的工作成果。在出現對照任務證據前，速度仍只是關於執行的證據，而非證明該配置提供了更佳的編碼助理。
三項訊號將決定結果能推展多遠
下一步證據應依次證明可重現性、編碼可靠性，以及在較不利運作條件下的效能。
第一項訊號，是在可比較的 RTX 5080 工作站上進行獨立重現。具參考價值的發布內容應包括確切模型產物、引擎修訂版本、配置、請求序列及原始計時記錄。重複運行應區分快取密集的工作階段與全新輸入。
接近的重現結果會加強論點，表明這個配置為個別開發者提供可重複的選項。若差距明顯，則須在將其歸因於硬件、軟件或工作負載前進一步調查。無論結果如何，都能改善使用者可獲得的證據。
重現測試應保留原有的量度區分。工作階段平均生成速率、請求平均生成速率及單秒峰值應分開呈現。只對照最高觀測到的短暫峰值，會令最重要的持續效能說法仍未獲解答。
第二項訊號，是使用相同量化配置進行編碼評估。其價值應來自已完成的任務及記錄在案的修正，而非另一張生成速度圖表。評估應包含代理實際所需的專案上下文。
強勁的任務結果會令吞吐量報告對軟件開發更具意義。即使生成速度維持快速，頻繁失敗亦會縮窄其吸引力。更快地產出無法使用的修補程式，並不會減少完成任務所需的工作。
第三項訊號，是在更廣泛的運作條件下檢視效能。相關證據包括陌生的長提示詞、較長輸出、推理同時運行一般開發應用程式，以及重疊請求。每種條件都測試所報告的體驗能否在工作負載改變後維持。
穩定的行為會加強在經仔細觀察的個別工作階段以外使用此配置的理由。記憶體壓力、更長等待時間或輸出退化，則會識別其實際界限。這些界限有助使用者選擇合適工作負載，而非直接否定該引擎。
這些訊號都不需要杜撰發布日期，或預測必然的勝出者。它們是維護者及獨立使用者可於未來數月發布的具體證據形式。現時帖子為這項工作提供了有用起點。
更廣泛的含意仍然具體：據報，一台配備 16GB 圖形記憶體的工作站，透過同時投入大量系統記憶體，維持了互動式生成。這使完整系統評估比單憑圖形記憶體容量判斷本地推理更具意義。
在更改設定前，請將 Qwen3.8 Basalt 基準測試與取自你自身工作的工作階段作比較。保留提示詞，記錄快取重用了甚麼，並記錄所得編輯能否通過你的檢查。加入你平日通常會保持開啟的應用程式，因為報告中的機器可用系統記憶體有限。將回應開始延遲與完成時間分開，並以持續輸出對照持續輸出。決定應取決於在你的條件下完成了多少有用工作。一次可重現的運行能否帶來正確變更、可接受的等待時間，以及足夠剩餘記憶體供其餘開發環境使用？
