開源推論執行期
llama.cpp 每日建置為舊 GPU 回退至 F32，並攔截 Nemotron MTP 權重的除零崩潰
9 月 13 至 14 日的 llama.cpp 預發布建置補上 BF16 不可用時的 CUDA F32 路徑，避免部分舊 GPU 直接失敗。另一項修補會在 Nemotron‑H 的 NextN／MTP 中繼資料不完整時回報錯誤，而非於載入模型時觸發 SIGFPE。
llama.cpp 在 9 月 13 至 14 日連續發布多個預發布建置，重點不是新模型功能，而是異質硬體和新式推測解碼權重的失敗處理。b10950 修改 `ggml-cuda`：只有具備硬體 BF16 加速的裝置才走 BF16，包括 NVIDIA Ampere 以上，以及 AMD RDNA3 或 CDNA；其他 CUDA／HIP 裝置改以 F32 執行相關路徑。這能把原本可能無法執行的配置轉為較慢但可工作的回退模式，但發布說明未提供速度或顯存增幅。
b10947 則處理 Nemotron‑H 的 NextN／MTP 尾端層。載入器在每層沒有提供 `expert_feed_forward_length` 時，會用 `n_ff / n_expert_used` 推導專家 FFN 大小；然而非 MoE 層的兩個欄位都可能合法地是零，舊程式因此會除以零並在載入期間以 SIGFPE 終止，而且沒有可診斷訊息。新版加入防護，遇到這類 checkpoint 中繼資料時明確回報格式問題。
同一窗口的 b10952 也修正 oneDNN scratchpad 破壞 SYCL 記憶體池釋放順序的問題；b10951 則把 `llama_n_rs_seq` 檢查移至 `llama_decode` 前，讓不需要解碼的序列提前返回。這些變更分屬不同後端，卻共同反映 llama.cpp 現在要同時承擔新模型架構、推測頭與多家 GPU 執行路徑的相容性成本。
工程團隊不宜把每日建置當穩定版直接全面升級。F32 回退可能改變吞吐、記憶體占用及數值結果；Nemotron 修補只把崩潰轉成可理解的錯誤，不能修復有缺陷的 GGUF。較安全的做法是在固定模型與提示上比較升級前後輸出，另以代表性長上下文和 MTP 配置量測顯存、prefill 與 decode，再決定是否推進生產環境。