GitHub Repo
Ollama 社群回報 Clef 載入記憶體缺陷，預設上下文可能放大運算緩衝區
10 月 8 日的 Ollama 社群回報指出，Clef 決策模型的微批次大小可能被設為完整上下文長度，導致預設設定下的記憶體配置失敗。案例提供多種後端日誌與縮短上下文的迴避方式，但尚待維護者確認及修補。
Ollama 社群於 10 月 8 日提出一項 Clef／Clef Flash 載入問題：在回報者的 Windows 11、Radeon 890M 環境中，模型使用預設 16,384 token 上下文時，CPU、ROCm 與 Vulkan 後端均出現記憶體配置失敗。問題附有啟動參數、緩衝區大小及錯誤日誌，提供了可核對的診斷線索。社群回報
日誌中的關鍵落差是，Ollama 啟動底層 llama-server 時傳入 -b 512 -ub 512，實際初始化結果卻將 n_batch 與 n_ubatch 設為 16,384，與 n_ctx 相同。回報者觀察到運算緩衝區隨上下文增大；ROCm 的容量預估先顯示仍有約 18.7 GB 可用，後續配置約 3.3 GB 緩衝區仍然失敗。這指出容量預估與實際配置之間可能存在缺口，但根因尚未經維護者確認。診斷日誌
暫時迴避方式是建立衍生模型，將 PARAMETER num_ctx 改為 4096。官方 Modelfile 文件確認，FROM 可沿用既有模型，PARAMETER num_ctx 可指定上下文大小；此調整也會縮小可處理的輸入範圍，部署前須核對任務需求。官方另提醒，加大上下文本來就會增加模型執行所需記憶體。Modelfile 文件、上下文文件
從工程角度推論，這個案例值得檢查的是微批次設定、上下文設定與記憶體估算是否一致。開發者可比對啟動命令、初始化日誌及實際緩衝區配置，避免只依權重大小判斷能否載入。目前證據集中於單一回報者的硬體與測試組合，不能延伸為所有平台皆受影響。後續應關注上游是否確認批次設定行為，以及修補是否同時涵蓋容量估算與自動降低上下文；截至查核時，議題仍開啟，未列出關聯修補。議題狀態