Misc. bug: UMA detection incorrectly limits available memory on AMD APUs with large TTM allocations

快速结论：该问题发生在 AMD APU（如 Strix Halo、Ryzen AI Max+ 系列）上，llama.cpp 的 UMA 检测逻辑误将“集成显卡”识别为共享内存系统，导致可用显存被错误地限制为系统内存的 MemAvailable，而忽略了驱动实际报告的 TTM/专用 VRAM 分配。优先检查 llama-cli --list-devices 报告的 free memory 是否远低于驱动实际可用显存。

适用环境：已确认受影响的硬件为 AMD Strix Halo APU（gfx1151）和 Ryzen AI Max+ 395（Radeon 8060S）；操作系统为 Linux（Ubuntu、Fedora 等）；ROCm 版本涉及 7.9.0 和 7.2.4；llama.cpp 版本涉及 master 分支（commit 0a0bba05e、555881e）。未确认其他操作系统或显卡环境。

最快修复方案：暂无官方合并的修复版本，但社区确认有效的补丁是修改 ggml/src/ggml-cuda/ggml-cuda.cu 中 ggml_backend_cuda_device_get_memory() 函数，将 UMA 内存检测从“覆盖（overwrite）”改为“取最大值（max）”——即仅当 /proc/meminfo 报告的可用内存大于 hipMemGetInfo 返回的显存时才采用前者，否则保留驱动报告值。

注意事项：该补丁为社区提案，尚未合并到主线（截至 Issue 关闭时）。修改源码后需要重新编译 llama.cpp。对于真正的共享内存 APU（小型显存划分的核显），该补丁保留了原有行为，不会破坏现有功能。设置 GGML_CUDA_ENABLE_UNIFIED_MEMORY 环境变量无法解决此问题，因为 UMA 路径已通过 prop.integrated 自动激活。

问题场景

在 AMD APU 平台上运行 llama-server 或 llama-cli 加载大模型（如 120B 参数 GGUF）时，使用 --n-gpu-layers 999 和较大的上下文长度（如 131072）。即使驱动（ROCm）报告有 96GB 可用显存（通过 TTM 或 BIOS VRAM 划分），llama.cpp 的 llama_params_fit 自动适配逻辑仍误判显存不足，导致上下文长度被强制缩小到 4096、模型层被卸载到 CPU，性能大幅下降。

报错原文

Misc. bug: UMA detection incorrectly limits available memory on AMD APUs with large TTM allocations

llama_params_fit_impl: projected to use 64909 MiB of device memory vs. 98304 MiB of free device memory
llama_params_fit_impl: cannot fulfill margin of 1024 MiB, need to reduce device memory by 37767 MiB
llama_params_fit_impl: context size reduced from 131072 to 4096
llama_params_fit_impl: ROCm0 (AMD Radeon Graphics): 36 layers (21 overflowing), 27049 MiB used

原因分析

根本原因在于 PR #17368 引入的 UMA 检测逻辑。在 ggml_backend_cuda_device_get_memory() 函数中，只要 prop.integrated > 0（即被识别为集成显卡），就会改用 /proc/meminfo 的 MemAvailable 作为可用显存，而忽略 cudaMemGetInfo()/hipMemGetInfo() 返回的驱动真实可用显存。

AMD APU（如 Strix Halo）虽然被驱动标记为 integrated = true，但在配置了较大 TTM 分配或 BIOS VRAM 划分时，实际可用的 GPU 显存远大于系统内存。例如：系统 RAM 可用约 27-31GB，而驱动报告的真实可用显存为 96-98GB。UMA 检测逻辑错误地使用了较小的系统内存值，导致 llama_params_fit 误判显存不足，触发不必要的降级。

社区讨论中还提到，设置 GGML_CUDA_ENABLE_UNIFIED_MEMORY 环境变量并不能绕开此问题，因为 prop.integrated 已经自动激活了 UMA 路径，环境变量不改变内存报告行为。

环境排查

确认是否为 AMD APU（gfx1151 或类似集成显卡架构），可运行 rocminfo 或 llama-cli --list-devices 查看。
检查 BIOS 中 VRAM 划分大小或内核启动参数（amdgpu.gttsize、ttm.pages_limit 等）。
对比 hipMemGetInfo（或 rocm-smi）报告的显存与 /proc/meminfo 中 MemAvailable 的差异。
确认 llama.cpp 版本是否为包含 PR #17368 的近期 master 分支（2025 年 8 月之后）。
确认 ROCm 版本（Issue 中涉及 7.9.0 和 7.2.4，其他版本未验证）。
Linux 内核版本：Issue 中涉及 6.14.0 和 7.0.0-28-generic，不同内核版本对 TTM/GTT 行为可能有差异。

解决步骤

确认问题：运行 llama-cli --list-devices，查看报告的 free memory 是否远低于驱动实际可用显存。例如：驱动报告 98,148 MiB，而 llama.cpp 只报告 28,239 MiB。

编译补丁（可优先尝试）：修改 ggml/src/ggml-cuda/ggml-cuda.cu 中 ggml_backend_cuda_device_get_memory() 函数，将 UMA 内存赋值逻辑改为取最大值：

if (ggml_backend_cuda_get_available_uma_memory(&available_memory_kb, &free_swap_kb) && available_memory_kb > 0) {
    const size_t uma_free = (size_t)available_memory_kb * 1024;
    if (uma_free > *free) {   // only raise to system RAM, never clobber real VRAM
        *free = uma_free;
    }
}

重新编译 llama.cpp（使用与你当前环境匹配的构建参数，如 -DGGML_HIP=ON -DAMDGPU_TARGETS=gfx1151）。

验证补丁：重新运行 llama-cli --list-devices，确认报告的 free memory 恢复为驱动值（约 98,148 MiB）。
如需使用环境变量：注意 GGML_CUDA_ENABLE_UNIFIED_MEMORY 无法解决此问题，因为 UMA 路径已被自动激活。设置该变量不会改变内存报告行为。
备选方案（针对特定场景）：如果不想修改源码，可尝试调整内核参数或 BIOS 设置，但 Issue 讨论认为这并非正确做法，且对较新的内核（>6.10/6.11）可能无效。此方案未在 Issue 中充分验证，谨慎使用。

验证方法

运行 llama-cli --list-devices，确认报告的 free memory 与 hipMemGetInfo（或 rocm-smi）显示的数值一致。然后重新运行原来的 llama-server 命令，检查日志中是否出现 context size reduced from 131072 to 4096 之类的降级提示。补丁生效后，llama_params_fit_impl 应报告类似于 will leave 33092 >= 1024 MiB of free device memory, no changes needed 的信息，模型应完整加载到 GPU 且上下文长度保持设定值。