Qwen3.8-Flash-Next SSD 串流聲稱在 24GB MacBook Air 上達到 49 t/s

根據一項社群實驗，Qwen3.8-Flash-Next SSD 串流在配備 24GB 記憶體的 M5 MacBook Air 上，據報平均可達每秒 48.8 個 token。這個數字衡量的是 decode，即系統處理完輸入後生成答案的階段。該結果亦來自經修改的推論引擎，包括一項會改變哪些模型元件參與運作的路由變更。

這份 10 月 25 日的報告結合了壓縮模型、推測式草稿模型，以及帶有小型 fork 的 Splash 1.4.0。推測式解碼會由較小的模型先提出文字，再由主模型核對。當中的核心張力很直接：把較少模型保留在記憶體中會帶來儲存裝置延遲，而避開這些延遲可能涉及改變模型行為。

Splash 的官方版本確認了底層串流能力確實存在，但並未獨立驗證這部手提電腦的速度或該 fork 的品質。與 llama.cpp 和 Kapitsa 等替代方案相比，真正值得問的是，這種做法能否以較少等待時間交付可媲美的答案。

Qwen3.8-Flash-Next SSD 串流令記憶體界線承受壓力

這項聲稱的結果挑戰了有多少模型資料必須留在記憶體中的看法，但答案品質及可重現性仍未有定論。

在作者的 MacBook Air 實驗中，24,576 個 expert slot 中有 6,800 個約佔 8.8GB。Experts 是會針對特定輸入被選用的專門模型元件。其餘 experts 會在需要時從儲存裝置串流載入，同時使用據報為 256K 的 context 設定。

基準測試在程式碼、工具及解說工作負載中平均每秒 28.8 個 token。具快取感知能力的路由把速度提升至 43.1；再加入重疊執行後，則提升至 48.8。最終三類工作負載的結果分別為 48.9、57.3 及 40.3。

作者表示，在使用 Pi coding agent 時，速度約為每秒 45 個 token，且沒有 prompt cache 損失。Prompt cache 會保留先前的處理結果以供重用。處理 32,620 個 token 的冷啟動耗時 62.4 秒，而處理 63,201 個 token 則耗時 130.4 秒。

作者亦報告路由造成的輸出變化、小規模的程式碼品質比較，以及在固定路由下由重疊執行產生的相符輸出。這些均屬自行報告的觀察，尚未獲獨立重現。

這些細節界定了該主張的範圍。它們描述的是硬件、模型檔案、軟件修改及工作負載的特定組合，而非證明同一手提電腦系列上每一個安裝環境均具備普遍的效能水平。

這個區別很重要，因為一個標題式吞吐量數字壓縮了多種不同的使用體驗。程式碼助手可在花費大量時間讀取全新請求後快速生成文字；由於先前處理結果仍可用，它亦可能在重複往返時感覺反應迅速。

買家或開發者需要了解這兩方面。答案生成速度決定回應展開所需時間；初始處理時間則決定回應開始前用戶要等多久。

不同工作負載之間的差距亦是另一個重要界線。結構化工具輸出、原始碼和解說文字並不能產生可互換的測量結果。它們的平均值可概括這項實驗，卻不能預測未知工作負載的表現。

記憶體數字也不代表整個應用程式。常駐 experts 還要與其他模型元件、快取的對話狀態、作業系統及一般應用程式共用同一部電腦。實際部署必須為這些彼此競爭的需求預留空間。

因此，這項值得報道的改變比「大型模型現已能舒適地放進小型手提電腦」的說法更為狹窄。這項實驗報告的是，在大部分 expert slot 仍不在常駐池內時，系統仍可達到有用的生成速度。

這是有意義的系統層面主張。它值得關注，因為它針對本機推論中常見的障礙，即執行已訓練模型的過程。它亦值得審慎措辭，因為最大的加速包含了行為層面的修改。

Splash 的版本令這不只是孤立的載入技巧

官方串流支援強化了技術前提，但並不會令該 fork 的基準測試變成產品保證。

Splash 1.4.0 的 expert streaming 版本加入 Flash-Next 支援、expert 儲存串流及自動草稿選擇。其說明亦記錄了 Q2_0 載入及記憶體管理變更。Q2_0 指的是低位元權重格式，會把模型參數儲存在壓縮的數值表示中。

這為社群報告提供了一個可獨立核查的基礎。作者是在延伸已發布的能力，而非單純聲稱某個不受支援的模型不知何故能夠運行。

版本文件亦包含一項與自適應驗證有關的限制說明。Splash 警告，其自動驗證設定可能隨執行條件改變而改變輸出，並指出另有一個設定可在指定條件下保持可重現性。

這項警告令設定本身成為證據的一部分。比較時除了路由、模型壓縮及記憶體分配外，也需要識別驗證行為；否則速度及輸出差異便難以歸因。

時間點亦說明了為何這項實驗現在具有意義。已發布的引擎提供必要機制，而社群開發者可以圍繞它探索更狹窄的最佳化。這些實驗能揭示通用版本尚未採用的機會。

對推論引擎維護者而言，壓力相當具體。用戶愈來愈希望軟件能管理有限記憶體，而毋須自行推理每一次儲存裝置資料搬移。成功的實作需要易於理解的預設值、清晰可見的診斷資訊，以及可預期的品質設定。

能夠載入模型的程式只是開始。當對話變長、另一個應用程式佔用記憶體，或下一項任務啟用不同 experts 時，它亦必須保持反應迅速。

這正是社群 forks 能提供有用證據之處。它們透過特定工作負載及硬件限制揭示取捨，讓維護者評估某項最佳化是否可普及、應否置於選項之後，還是需要進一步驗證。

同一過程亦帶來報道風險。即使 fork 的行為存在重大差異，它仍可能與其母引擎名稱產生聯想。讀者應把已發布版本與修改後設定分開看待。

對 Qwen3.8-Flash-Next SSD 串流而言，這種區分尤其重要。官方支援確認了相容性及記憶體管理路徑；手提電腦測試結果則為該路徑的特定延伸加入了一項效能主張。

底層模型亦需要有其自身定位。Qwen 的 模型架構描述了一種稀疏 mixture-of-experts 設計，其中被選出的元件會為每個 token 執行工作。其已發布的 context 容量涉及模型架構，而非保證每個本機部署均能達到相同效果。

一部電腦可以接受某個 context 設定，卻未必能在該範圍內持續提供同樣有用的效能。記憶體可用性、處理時間及任務準確度仍是不同的實際問題。

常駐優先執行與路由偏向解決不同問題

把儲存讀取與運算重疊會改變排程；偏好已快取 experts 則會改變被排程的運算。

該 fork 的核心區別，在於以不同方式完成相同工作，還是選擇不同工作。兩者都可提升吞吐量，但需要不同類型的證據。

常駐優先執行會在缺少的 experts 被載入時，先處理已在記憶體可用的 experts。理論上，這可透過讓儲存活動與有用運算重疊，減少閒置時間。

這個機制不會令儲存裝置變得與記憶體一樣快。它只是減少仍直接暴露給用戶的儲存延遲，其效益取決於讀取完成前可進行多少工作。

若有足夠的常駐運算，部分擷取時間可被隱藏在其後。若儲存讀取需時較長，或常駐工作較早完成，引擎仍然要等待。因此，不同 prompts 可能帶來不同增益。

這正是排程改善需要在多樣化輸入中進行測試的原因。有利的基準測試可顯示重疊在某種存取模式下有幫助，但無法證明每段對話都會產生同樣機會。

具快取感知能力的路由採取不同做法。Router 是 mixture-of-experts 模型中選擇哪些 experts 處理輸入的部分。偏好已在記憶體中的 experts，可降低對缺失元件的需求。

其潛在速度優勢順理成章。缺失元件愈少，儲存依賴也愈少。然而，所得運算可能有別於模型原本的選擇。

保護最強的選擇，同時更改其他選擇，或許能保留有用行為，但這仍屬實證問題。單憑選擇排名，無法證明經修改的貢獻對每個後續答案都無關緊要。

看似細微的變更可在不同任務上產生不同影響。一般格式化請求或許可以容忍；困難的程式碼修復，或涉及罕見細節的答案，則可能暴露弱點。

因此，合適的評估應把這些最佳化分開。排程變更需要正確性、時間及資源使用的證據；路由變更還需要任務結果的證據。

推測式解碼增加了另一項依賴。其速度效益部分取決於提出的文字有多常能通過驗證。容易預測的工作負載可能與開放式解說有不同表現。

這些互動令單一標題數字變得複雜。路由影響 expert 存取，排程影響等待時間，而草稿模型影響有多少建議文字最終成為有用輸出。最終吞吐量反映的是三者組合。

模型檔案亦是這個組合的一部分。量化模型集合提供了這項實驗背後指定的 artifact family。它的存在證明了可用模型來源，並不證明使用它的每一種執行時設定都有相同品質。

因此，討論時應把壓縮與路由偏向分開。壓縮改變權重的數值表示；路由偏向則改變執行期間的元件選擇。

把壓縮基準版本與其修改版本比較，可以隔離部分執行時效應。把任何一個版本與另一個壓縮級別比較，則會引入額外變數。兩種比較都不應在未說明情況下替代另一種。

即使尚未重現，實際意涵仍然有用。本機模型效能愈來愈取決於儲存、記憶體、選擇及驗證之間的協調。單看原始記憶體容量，無法描述這種協調。

對這項實驗而言，最具影響力的技術問題是：當輸出行為保持不變時，哪些速度增益仍能保留。回答這個問題，將有助釐清有多少提升來自更佳執行，又有多少來自近似處理。

競爭問題是在相同限制下完成有用工作

公平的比較應量度在可比配置下完成任務的表現，而不是為互不相關的 token 速率排名。

這份報告對某種部署方式帶來的壓力，多於針對某一間公司。將所有內容常駐於記憶體可簡化存取，但需要足夠的記憶體。串流可降低常駐需求，但會增加排程及儲存方面的挑戰。

兩種方式都不會自動勝出。常駐配置可避免重複擷取，並提供可預測的存取延遲。串流配置則可讓較大型模型在無法同時容納相關權重的機器上運行。

對開發者而言，選擇取決於實際工作負載。較小的常駐模型或可憑較低的啟動延遲更快完成任務。串流模型雖然需要較長的初始等待時間，卻可能提供較佳答案。

同樣的取捨亦適用於編程代理。這些系統會反覆生成文字、呼叫工具及整合結果。生成速度會影響任務所需時間，但工具執行及重複處理亦同樣重要。

快速輸出錯誤修改，並不會提升工程生產力。高質素答案若來得太遲，未能配合預期互動，亦沒有意義。有用的效能應結合完成時間與可接受的結果。

Apple silicon 上已有活躍的替代方案。Apple silicon engine Kapitsa 針對 Qwen 及 Nemotron 工作負載，並提供與常見代理客戶端兼容的介面。它的存在說明，Splash 的結果應置於更廣泛的軟件比較之中。

不過，來自另一個模型、記憶體容量或提示詞集合的數字，無法在此確立勝者。比較必須保持重要條件一致，或說明其差異。

同樣的審慎態度亦適用於 llama.cpp。它在本機推理中的角色使其成為相關參考，但單憑熟悉程度不足以構成配對基準測試。引擎名稱並非量度。

有意義的比較應在支援的情況下使用相同的模型成品。亦應說明上下文長度、草稿配置、路由行為，以及先前處理結果能否重用。

機器狀態同樣重要。剛啟動的應用程式與已暖機的工作階段不同。只運行推理伺服器的手提電腦，與同時支援正常開發環境的手提電腦亦不同。

這些差異對報告中的代理情境尤其相關。重複回合可受惠於共享歷史紀錄。全新的儲存庫分析，則可能需要在生成開始前進行大量新處理。

知識工作亦有相似模式。閱讀新的文件集合，與就已處理材料提出後續問題並不相同。可見的答案輸出速率只能反映當中的一部分體驗。

對於建立可搜尋知識庫的開發者而言，文件選取亦會影響延遲及實用性。無論使用哪種推理引擎，提供相關材料都可減少不必要的輸入。

這是應用層面的考量，並非證明特定產品採用此設定。它說明本機模型基準測試為何需要連結至實際資訊工作流程。

因此，Qwen3.8-Flash-Next SSD 串流帶來了有用的競爭挑戰。引擎應說明如何管理記憶體限制，並報告用戶換來甚麼。證據應同時包括任務成功率與速度。

質素證據尚未釐清這項取捨

現有報告支持進一步測試，而非斷定加速能在各種工作負載下保持質素。

作者承認，具快取感知能力的路由會改變輸出。這項披露是評估結果的核心。它避免了更快的配置被視為毫無代價的執行改善。

小規模編程比較提供了初步檢驗，但無法確立等效性。有限的問題集合，令任務涵蓋範圍及可重複性仍存在很大不確定性。

小幅分數差異亦不足以確立可信的下跌趨勢。若沒有重複測試及更廣泛涵蓋，隨機變異及任務選取仍是合理解釋。正面及負面結論同樣需要克制。

更強的評估應區分答案相似度與任務正確性。在受控條件下，比對文字可有助測試實作變更，但單憑這點無法確立廣泛的編程或推理能力。

反過來說，措辭不同亦不必然代表質素較差。一項任務可接受多個有效解決方案。重要問題是，這項修改是否改變了對用戶重要的結果。

對編程而言，這些結果包括成功執行及恰當修改。對工具使用而言，則包括有效參數及正確行動選擇。對文件分析而言，則包括忠實運用所提供的證據。

路由偏差值得進行改變主題的測試。在某個持續工作流程中有用的專家模型，可能在任務突然轉換後較不適用。圍繞近期存取模式而優化的配置，需要在這些轉換點接受評估。

記憶體行為亦需要隨時間觀察。一次短暫而成功的運行，無法證明整段長時間工作期間的可靠性。背景應用程式及變化中的對話狀態都可改變可用餘裕。

在其所述使用情況下，未見提示詞快取損失是令人鼓舞的。這並不能證明淘汰、重新啟動或復原問題永不發生。這些行為需要獨立的壓力測試案例。

長上下文聲稱亦需同樣謹慎。接受長輸入只證明一項能力；找出相關細節並產出忠實答案，則證明另一項能力。

全面測試應改變重要證據出現的位置，亦應包括干擾資訊，以及答案依賴多段相距甚遠內容的問題。這將評估超越單純接受輸入的實用性。

冷處理仍是實際限制。從陌生材料開始的用戶，會承受完整的輸入成本。延續既有工作階段的用戶，則可能面對不同的平衡。

現有數字沒有回答電池續航、持續散熱表現或對一般應用程式干擾的問題。這些是評估缺口，並非故障證據。

儲存活動亦應量度，而非猜測。串流意味着讀取，而其他快取操作可能有不同的存取模式。吞吐量標題數字無法確立其長期營運影響。

審慎的結論是，多項聲稱仍應保持區分。該引擎支援串流、作者報告速度較高，而質素維持情況仍未獲完整測試。將它們合併成單一結論，會誇大現有證據。

留意重現性、質素分離及較長的代理工作階段

下一批有用證據應說明哪些增益可重現、哪些可保持行為，以及哪些能改善已完成的工作。

首個訊號是具可識別分支及完整配置的獨立重現。另一位測試者應能重現模型檔案、記憶體配置、驗證設定及工作負載條件。

該重現測試應區分原生 Splash 與每項新增優化。否則，即使最終運行成功，個別變更的貢獻仍會不清楚。

一致的結果將加強這種方法可推廣至作者機器以外的說法。大幅變異則會令配置依賴性比概括的速度標題更重要。

第二個訊號是啟用及停用路由偏差的更廣泛質素評估。保持其餘設定穩定，有助識別偏向常駐專家模型的行為代價。

這項比較應報告失敗情況，而不只是整體分數。穩定的平均值可能掩蓋某個可靠性下降的類別。開發者需要知道，這些失敗是否與其目標工作負載相符。

若單靠排程已能保留顯著增益，廣泛有用的執行改善論點便會更強。若路由提供大部分加速，讀者便需要更清楚的質素取捨說明。

第三個訊號是量度完整任務的持續代理測試。這類測試應包括全新輸入、延續對話、工具執行，以及中斷後的復原。

成功的長時間工作階段將加強報告的實際價值。頻繁停滯、失去可重用狀態或需要額外重試，則會削弱 token 吞吐量與生產力之間的關連。

這些觀察亦應為任何上游採用提供參考。行為清晰、具文件說明的選項，比一系列未解釋的實驗性預設值更容易評估。

對考慮本機 AI 的讀者而言，合理做法是評估自己實際執行的工作負載。使用具代表性的編程任務或文件集合，保留配置，並記錄等待時間及正確性。比較全新工作階段與延續對話，因為兩者會呈現不同成本。判斷結果時，應將路由變更與排程變更分開。Qwen3.8-Flash-Next SSD 串流現時提出了一項值得研究的具體社群聲稱，並有已發布的串流能力支持。當獨立測試把這些生成速率與可靠完成任務連結起來，其價值將更為清晰。在把標題數字視為部署決策之前，應先問同一配置能否在整個日常工作階段中提供可接受的答案。