引擎優化機制如何影響模型輸出
推論引擎為了提升解碼或預填充效能，常會自動啟用有損（lossy）旗標。本次實驗針對 Qwen 3.8 Flash Next 模型與 Basalt 引擎進行測試，重點檢視兩種常見優化：「路由偏誤」（Routing bias）與「尾端跳過」（Tail skip）。
路由偏誤機制會將模型推向已載入 GPU 的專家模組，導致模型有時選擇了方便存取但非最佳預測的專家。尾端跳過則是在模型需要的低排名專家未於 GPU 上時，直接略過該專家的計算而非從 RAM 抓取。
這兩種機制因減少從記憶體傳輸數據的需求而提升速度，但會改變模型的實際輸出結果。實驗將這些功能設為可選旗標，以便在固定其他條件下單獨測量其影響。
量化品質與 KL 散度的關聯
實驗使用 100 個 wikitext 區塊進行 KL 散度（KLD）測試，以 llama.cpp 的 Q8_0 參考值為基準。數據顯示，當啟用引擎預設的優化設定時，各量化包（pack）的 KLD 均值均顯著上升。
具體而言，啟用預設設定後，Q8_0 模型的 KLD 從 0.031 升至 0.401，同頂一預測率（Same top-1）從 94.1% 降至 79.4%。這使得高品質的 Q8_0 模型表現劣化至接近低品質 Q2_0 模型的水準。
值得注意的是，即使是未啟用優化的精確 Q8_0 模型，其 KLD 仍與參考值有 0.031 的差距。這主要歸因於參考值本身的噪音以及 llama.cpp 與 Basalt 在捨入處理上的微小差異，並非引擎優化造成的損害。
數據表明，量化包越大（如 Q8_0），受影響程度越深，因為更多權重位於 VRAM 之外而被重新路由或跳過。相比之下，較小的 NVFP4 包因大部分已在 VRAM 內，受影響相對較小但仍顯著。
實際任務表現與速度權衡
為驗證 KLD 差異是否反映在實際應用中，實驗執行了多步推理（Ladders）與事實問答（Facts）測試。在多步推理任務中，啟用預設優化導致 Q8_0 模型的通過率從 45.4% 降至 43.8%，事實問答準確率從 38.1% 降至 36.6%。
在模擬小記憶體環境（僅使用 RTX 5090 並將專家快取限制為 5 GB）下，啟用優化帶來的速度提升更為明顯，文字生成速度增加約 56%。然而，代價是多步推理準確率下降 5.2%，事實問答準確率下降 2.3%，且這些差異在統計上顯著（95% 信賴區間排除零）。
相反地，在記憶體充足的情況下，啟用預設優化對 NVFP4 模型的速度幾乎無幫助（272 tok/s 降至 271 tok/s），卻仍造成品質損失。這顯示在 VRAM 足夠時，這些優化的效益極低甚至為負。
極端設定下的模型崩潰與幻覺
當使用極端優化設定（路由偏誤 16，尾端跳過排名 ≥ 1）時，模型表現出現嚴重崩潰。事實問答準確率從 38% 暴跌至 2.7%，多步推理通過率降至 26.6%。
在此設定下，模型產生大量自信但錯誤的答案，例如將「大作曲家」作為答案，或在撰寫《奧德賽》文章時出現事實錯誤，如將菲米烏斯（Phemius）描述為女性、海倫潛入特洛伊等。專有名詞與罕見詞彙最先失效。
部分測試對這些變化較不敏感，例如「同時保持規則」任務在極端設定下僅下降 3.8%。這表明損害主要出現在需要多步推理與事實回憶的任務中，這正是被重新路由或跳過的專家模組所負責的功能。
模型自身迴圈問題與引擎處理
實驗發現一個與引擎優化無關的現象：Qwen 3.8 Flash Next 在特定編程提示下會陷入無限輸出「0」的推理迴圈。此現象在 Basalt 引擎的不同量化包、llama.cpp 以及官方 API 中均有出現，機率在各配置間相似。
官方 API 會在約 500 個零後截斷並讓模型繼續回答，因此用戶較少看到完整迴圈。Basalt 引擎隨後更新了類似機制：在推理區塊連續出現 256 個相同 token 後關閉思考區塊並記錄事件，但不改變模型選擇的 token。
這顯示某些不良輸出可能源於模型本身的生成特性，而非推論引擎的優化所致。開發者強調，此迴圈問題在所有測試環境中均存在，且與溫度參數或 top_p 設定無直接因果關係。
