硬體配置與自製推理引擎背景

測試平台由兩台 Lenovo IdeaCentre Mini 組成，每台搭載 Snapdragon X X1-26-100 處理器（8 個 Oryon 核心、Hexagon NPU）、32 GB LPDDR5 記憶體及 512 GB NVMe SSD。

開發者最初使用 llama.cpp，後轉用 Janas 並貢獻 ARM 移植與修復，最終因需求差異而自行開發名為 ToRc 的推理引擎。

兩台機器透過一條 USB4 線纜連接，全程未使用 Adreno GPU，僅依靠 CPU 核心與 NPU 進行密集數學運算。

Qwen3.6 35B A3B 模型測試結果

針對 Qwen3.6 35B A3B (19.4 GB) 模型，ToRc 在單機配置下讀取速度達每秒 228 token，生成速度為每秒 43.4 token。

雙機串聯時，ToRc 的讀取速度提升至每秒 315 token（含 HTTP 請求開銷），但生成速度維持在每秒 43.3 token，與單機幾乎相同。

這是因為 ToRc 在雙機模式下僅利用第二台機器加速提示詞處理（Read），生成階段仍由第一台機器單獨執行，以避免跨線纜傳輸狀態帶來的延遲超過並行計算的收益。

突破記憶體限制運行 Flash Next 大模型

Qwen3.8 Flash Next IQ4_NL (95 GB) 與 UD-Q4_K_XL (104 GB) 遠超單機或雙機的 RAM 總量，必須依賴 NVMe SSD 進行專家權重的串流載入。

llama.cpp 在此場景下表現受限，單機讀取速度僅每秒 7.3 token，雙機 RPC 模式為每秒 10.9 token，因其無法從磁碟串流權重且需將部分層駐留於 RAM。

ToRc 透過管線化多詞元預測（Pipelined MTP）技術，讓第一台機器在第二台機器處理當前詞元時預先生成後續詞元，從而隱藏線纜等待時間。

雙機 ToRc 對 IQ4_NL 模型的讀取速度達到每秒 46.2 token，生成速度為每秒 20.3 token；使用較大的 UD-Q4_K_XL 量化版本時，速度約降低 10% 但 perplexity 較低。

多詞元預測（MTP）的效能依賴性

測試顯示 MTP 技術的效果並非恆定，而是取決於生成內容的結構與可預測性。

在散文生成任務中，llama.cpp 啟用 MTP 後速度反而從每秒 25.8 token 降至 20.6 token，因草稿大多被拒絕；ToRc 單機則提升 14%，雙機無增益。

在程式碼生成任務中，所有引擎啟用 MTP 均獲得顯著加速：llama.cpp 從每秒 27.7 提升至 39.3 token，ToRc 雙機從每秒 42.6 提升至 59.6 token。

這表明對於結構化輸出（如程式碼），MTP 能有效利用並行性；而對於自由形式文本，草稿拒絕率可能抵消計算收益。

程式碼生成準確度與測試表現

開發者使用包含輸入驗證與 docstring 的 ISO 8601 持續時間解析函數作為標準測試，並執行 5 個 pytest 測試案例及 6 項參考檢查。

ToRc 雙機在 Qwen3.6 模型上通過所有測試與檢查；但在 Flash Next IQ4_NL 雙機測試中，模型生成了正確的函數但未生成測試案例（Tests none written）。

llama.cpp 在 Qwen3.6 測試中有一項失敗，原因是模型自身的算術錯誤（將 P3DT4H12M5S 計算為 300725 秒，正確值為 274325 秒），但函數邏輯本身正確。

ToRc 在 Qwen3.6 單機測試中有一項檢查失敗，因生成的程式碼不接受週（P1W）作為有效輸入，儘管 P1W 符合 ISO 8601 標準。

成本效益與未來開發方向

整套系統硬體成本約 600 英鎊，負載時每台機器功耗約 35W，相較於需要大量 VRAM 的 GPU 方案具有顯著的成本與能耗優勢。

ToRc 引擎尚未公開發布，作者表示需進一步整理與測試後才會釋出。

未來改進方向包括為 Qwen3.6 雙機配置引入管線化預測技術，以及嘗試使用第二個 NVMe 驅動器分割專家權重讀取以突破單磁碟頻寬限制。