Ollama 社群追查 rnj-1 載入失敗，滑動視窗注意力中繼資料可能觸發斷言

Ollama 社群於 10 月 10 日收到 rnj-1 載入失敗回報，協作者在 11 日補充技術診斷：模型檔案宣告滑動視窗注意力（SWA）相關設定，實際上卻沒有使用 SWA 的層，新版底層執行器因此觸發斷言。這讓原本可用的模型在生成答案前便中止。公開回報與協作者分析

案例使用 Linux、Intel CPU 與 Ollama 0.40.0。日誌顯示，請求進入 llama-server 後，在模型記憶體初始化路徑出現 GGML_ASSERT(hparams.is_swa_any()) failed，隨後程序退出，/api/generate 回傳 HTTP 500。回報者表示，刪除並重新下載模型仍無法解決；協作者則指出問題從 0.34.4 出現，可能與一次 llama.cpp 升級有關。該升級已於 9 月 22 日合併，近兩天的新進展是故障回報與原因分析。底層版本更新紀錄

依協作者說明，舊邏輯會捨棄全為零的 SWA 層清單，新邏輯保留清單，並在找不到 SWA 層時報錯。rnj-1 的檔案同時帶有視窗設定與全為 false 的層模式，恰好落入這個條件。Unsloth 模型卡也說明，rnj-1 架構近似 Gemma 3，但只採全域注意力，並使用 YaRN 延伸上下文；這與回報中的層設定相符。模型架構說明

目前協作者提出的替代方式，是使用未宣告 SWA 設定的 Unsloth GGUF，並表示該檔案可成功載入。Hugging Face 頁面提供 ollama run hf.co/unsloth/rnj-1-instruct-GGUF:UD-Q4_K_XL 的執行方式，但替換量化檔案後，仍應重新驗證輸出與效能，不能直接視為原模型的等價修補。替代模型與操作說明

對維護本機推論服務的工程團隊，這個案例顯示：升級驗證需要涵蓋既有 GGUF 的中繼資料相容性，以及實際載入與生成流程。截至查核時，議題仍開啟，尚無已交付的正式修補；後續應關注上游是否調整全零 SWA 清單處理，以及其他類似檔案是否受影響。