硬體分工與記憶體管理策略

Qwen3.8 Flash Next 是一個擁有 48 層、每層 512 個專家的混合專家模型，即使量化至 3-bit 仍遠超單台 M4 Pro MacBook 的 24GB 記憶體容量。開發者將模型權重分散至五台裝置：第一台配備 RTX 2060 Super 的遊戲電腦負責第 0-9 層、輸出層及多 token 預測草稿頭；M4 Pro MacBook 負責第 10-29 層；第二台配備 RX 9060 XT 的遊戲電腦負責第 30-47 層。

兩支 iPhone 17 Pro Max 透過 USB-C 連接至 MacBook，協助處理第 10-18 層的專家選擇任務。MacBook 將選中的專家指令透過 USB-C 發送給手機 GPU 執行，回應時間約為 1 毫秒，而 MacBook 本身則保留並執行最常被使用的專家權重。

所有模型權重均駐留在 VRAM、固定記憶體或統一記憶體中，確保沒有資料從磁碟串流讀取或發生記憶體交換。電腦與 MacBook 之間透過乙太網路通訊，手機則透過 10 Gb/s USB-C 連接。

管線化推測解碼提升生成效率

為解決五台裝置串聯可能導致的等待時間問題，系統採用管線化推測解碼技術。位於第一台 PC 的草稿頭預測接下來的幾個 token，整個鏈路在一次通過中驗證這些預測。當該批次資料仍在 MacBook、手機和第二台 PC 間傳輸時，第一台 PC 已經開始預測下一個批次。

這種並行處理機制使得每個步驟平均產生約 2.2 個 token。測試環境模擬實際代理應用場景，設定溫度為 0.6、top-p 為 0.95、top-k 為 20，並使用中等思考強度的真實程式碼提示詞，而非貪婪解碼。

在 16k 上下文下，生成速度為每秒 42 個 token，讀取提示詞速度為每秒 728-744 個 token；32k 上下文下生成速度為每秒 39-41 個 token，讀取速度為每秒 844-852 個 token；60k 上下文下生成速度為每秒 37-39 個 token，讀取速度為每秒 856-895 個 token。

實際代理應用中的延遲與吞吐量

在影片展示的代理會話中，若提示詞已快取，短後續回合的啟動時間約為半秒。包含新工具輸出的回合則需要約 2.9 秒的固定開銷，加上每秒 768 個 token 的新增處理速度。

整個會話的平均生成速度為每秒 35 個 token，因為實際速度會隨文本的可預測性波動，開發者觀察到瞬間峰值可超過每秒 40 個 token。

需要注意的是，儀表板上的預填充速率計數將快取的提示詞 token 視為重新讀取，因此顯示數值偏高；字幕與文中數據反映的是伺服器端的真實端到端效能，解碼數據則為正確值。

上下文長度限制與未來優化方向

當前配置的最大上下文長度受限於第二台 PC 的 16GB VRAM，僅能服務約 69.6k tokens。另一種實驗性配置將兩層模型移至第一台 PC，並在 MacBook 和手機上保持 8-bit KV 快取，該配置曾成功讀取單一超過 164k tokens 的提示詞，但在 60k 上下文下的生成速度降至每秒 31-33 個 token。

要達到完整的 262k 上下文支援，需要每支手機持有一個注意力層的快取，這正是兩台 A19 Pro 分工的方式。由於其中一支 iPhone 今日必須離線，該測試尚未完成。開發者認為透過更多優化可以進一步提升速度。

長提示詞的快速讀取受限於第二台 PC 的 PCIe 頻寬，因為其主機記憶體中的專家權重每 512-token 批次需跨越 PCIe 傳輸一次，導致讀取上限約為每秒 980 個 token。

模型品質驗證與程式碼發布

開發者聲稱所有修改在構造上或分佈上是精確的，除了 MacBook 上的專家快取會以不同順序累加部分和。針對今日變更的 KL 散度檢查尚未執行，因此最終品質驗證結果待確認。

該專案程式碼即將發布至 GitHub 倉庫 StayLameBro/backburner。開發者鼓勵使用者嘗試使用自己的手機或 iPad 進行測試，並指出若使用其他量化方式，理論上可以獲得更快的速度。