推論系統
llama.cpp b10472 修正 AMD APU 記憶體判定，避免 Strix Halo 被錯配不存在的可用容量
新版在 Linux HIP 建置中停止以系統 `MemAvailable` 覆寫 GPU 記憶體資訊，改為信任 `hipMemGetInfo`。修正針對可調 UMA carveout 的 AMD APU，可降低模型載入器高估容量後才失敗的風險。
llama.cpp 於 8 月 17 日發布 b10472，修正 Linux 上 AMD APU 的統一記憶體判定。先前為支援 NVIDIA DGX Spark 而加入的 UMA 邏輯，會把作業系統的 `MemAvailable` 視為加速器可用容量；這個近似值套到 Strix Halo 等 AMD APU 時並不可靠，因為 BIOS 可把統一記憶體切成不同的系統 RAM／VRAM carveout，Linux 的可用主記憶體不等於 HIP 執行期實際可配置的顯示記憶體。
b10472 對 HIP 建置跳過這項覆寫，讓 AMD APU 繼續使用 `hipMemGetInfo` 回報的 free／total 值。差異不是跑分優化，而是資源排程的正確性：llama.cpp 會依可用容量決定張量卸載、模型是否能放入 GPU，以及 KV cache 與批次配置。若數字被高估，服務可能先接受過大的模型或上下文，之後才在配置階段 OOM；小 carveout、容器化部署及共用記憶體壓力較高的系統尤其容易遇到。
合併討論指出，Strix Halo 可因 BIOS 設定而只留下約 32GB 系統 RAM、其餘配置給 GPU；單看 `/proc/meminfo` 無法重建這個邊界。工程團隊升級後應重新記錄啟動時的 HIP free／total、實際可卸載層數與最大 KV cache，不能把修正解讀為可用記憶體突然增加。此變更只明確涵蓋 Linux HIP 路徑；維護者確認 Windows 的 ROCm 記憶體回報機制不同。版本也未提供吞吐或 OOM 發生率的對照數據，後續仍需在不同 BIOS carveout、核心與 ROCm 版本上驗證。