AMD 于 2025 年底推出的 Strix Halo（Ryzen AI Max 系列）APU 首次将 RDNA 3.5 架构集成显卡带入高性能移动计算平台，其统一内存架构与 128GB 共享内存的设计为本地大模型推理提供了全新的硬件可能性。随着 ROCm 7.2 正式支持 GFX1151 图形核心，开发者终于可以在这款 APU 上运行完整的 PyTorch 工作流与 LLM 推理服务。本文从工程视角出发，梳理从系统配置到生产部署的关键调优参数与踩坑记录，供计划在 Strix Halo 上构建 AI 开发环境的工程师参考。
系统准备：BIOS 与 Ubuntu 24.04 基础配置
Strix Halo 的 ROCm 支持对固件版本有严格要求。根据实测经验，安装 ROCm 驱动前必须完成 BIOS 更新，否则 PyTorch 将无法识别 GPU 设备。主流厂商（如华硕、联想）的 Strix Halo 笔记本已推送兼容版本，更新过程通常可通过 BIOS 设置中的网络功能直接下载，无需制作 U 盘引导。更新完成后建议进入 BIOS 检查以下两项关键设置：
显存预留策略：将 Reserved Video Memory 设置为最小值（可低至 512MB），其余内存通过 GTT（Graphics Address Remapping Table）由操作系统动态分配。这一设计的核心逻辑在于 Strix Halo 采用 CPU/GPU 统一内存架构，显存并非独立硬件而是系统内存的映射池。Reserved 越低意味着可供 GTT 使用的连续内存块越大，但部分 legacy 软件可能仅读取预留显存值并因容量不足而拒绝运行，实际部署时需根据目标工作负载权衡。
操作系统选择：ROCm 官方对 Ubuntu 24.04 LTS 提供原生支持，推荐使用官方安装脚本完成驱动部署。Ubuntu 24.04 在内核版本与 GCC 工具链方面与 ROCm 7.2 兼容最佳，可避免因内核符号缺失导致的驱动加载失败。安装完成后可通过 rocm-smi 验证驱动状态，正常情况下应显示 GFX1151 设备信息。
Grub 参数调优：ttm.pages_limit 与 amdgpu.gttsize
统一内存架构的性能发挥高度依赖于 Linux 内核的显存分配策略。Strix Halo 的 iGPU 需要足够的 GTT 区域来映射显存页面，若分配不足将导致大模型推理时频繁出现 OOM（显存不足）错误。在 /etc/default/grub 中添加以下内核参数可显著改善显存可用性：
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash ttm.pages_limit=32768000 amdgpu.gttsize=114688"
参数含义如下：ttm.pages_limit 控制 TTM（Translation Table Manager）管理的页面数量上限，32768000 页约对应 128GB 内存空间的页面映射；amdgpu.gttsize 以 MB 为单位指定 GTT 区域大小，114688MB 约为 112GB。实际配置时需注意 保留 4GB 至 12GB 内存专供 CPU 使用，避免内核因内存不足而触发 OOM Killer。计算公式为：总内存减去 Reserved 再减去 GTT 应等于保留给 CPU 的安全阈值。对于 128GB 内存的系统，若 Reserved 设为 512MB、GTT 设为 112GB，则保留内存约为 15.5GB，已处于安全范围内。
此配置的核心风险在于：同时启用 Reserved 与 GTT 可能因内存碎片化导致效率略低于单一的大容量 GTT 池。若主要运行 PyTorch 训练或大批量推理任务，可尝试将 Reserved 设为 0 并将 GTT 调整为略低于总内存减去 CPU 保留量的值，通常能获得更稳定的显存分配性能。
PyTorch 环境：用 UV 安装 ROCm 7.2 版本
ROCm 生态的 Python 包依赖管理历来是部署难点，Strix Halo 搭配 PyTorch 2.11.0 以上版本可通过 UV（Astral 出品的 Python 包管理器）实现一键部署。关键在于正确配置自定义索引源以获取 ROCm 预编译 wheel：
[project]
name = "strix-halo-pytorch"
version = "0.1.0"
requires-python = ">=3.13"
dependencies = [
"torch==2.11.0+rocm7.2",
"triton-rocm",
]
[tool.uv]
environments = ["sys_platform == 'linux'"]
[[tool.uv.index]]
name = "pytorch-rocm"
url = "https://download.pytorch.org/whl/rocm7.2"
explicit = true
[tool.uv.sources]
torch = { index = "pytorch-rocm" }
triton-rocm = { index = "pytorch-rocm" }
执行 uv sync 后，通过以下命令验证 ROCm 识别状态：
python -c "import torch; print(f'ROCm: {torch.version.hip}'); print(f'GPU Available: {torch.cuda.is_available()}')"
若输出显示 GPU Available: False，首要检查 BIOS 是否完成更新 —— 这 是 Strix Halo 部署中最常见的卡点。确认 BIOS 版本无误后，检查 /dev/kfd 与 /dev/dri/* 设备节点权限，确保当前用户属于 video 或 render 组。
LLM 推理部署：Llama.cpp + Podman 容器化
在 Strix Halo 上运行大模型推理，Llama.cpp 是目前效率最高的运行时选择。通过 Podman 容器化部署可简化 ROCm 运行时依赖管理，同时保证宿主机环境整洁。以下命令启动基于 ROCm 的 llama.cpp server：
podman run --rm -it --name qwen-strix \
--device /dev/kfd --device /dev/dri \
--security-opt label=disable --group-add keep-groups \
-e HSA_OVERRIDE_GFX_VERSION=11.5.0 \
-p 8080:8080 \
-v /models:/models:z \
ghcr.io/ggml-org/llama.cpp:server-rocm \
-m /models/qwen3.6-35b-a3b.gguf \
-ngl 99 \
-c 32768 \
--host 0.0.0.0 --port 8080 \
--flash-attn on \
--no-mmap
参数要点解析：HSA_OVERRIDE_GFX_VERSION=11.5.0 强制 ROCm 运行时将 Strix Halo 识别为 GFX1150 兼容设备，确保着色器编译管线正常工作；-ngl 99 将模型层全部加载至 GPU 执行；-c 32768 设定 32K 上下文窗口；--flash-attn on 启用 Flash Attention 加速（需 ROCm 6.0 以上）。实测 Qwen3.6-35B-A3B 在 Strix Halo 上可获得约 12-15 tokens/s 的生成速度，足以支撑交互式代码辅助场景。
模型获取与格式转换流程如下：使用 uvx hf download 下载 HuggingFace 格式权重，再通过 llama.cpp 仓库中的 convert_hf_to_gguf.py 转换为 GGUF 格式。注意转换时需指定 --outtype f16 或 --outtype q4_0 以适配不同量化策略，Q4 量化可在 16GB 显存内运行 70B 参数模型。
兼容性现状与工程建议
Strix Halo 搭配 ROCm 7.2 的组合仍处于生态成熟早期阶段。工程部署层面需关注以下限制：部分仅检查物理显存容量的 legacy 应用可能无法正常运行（表现为显存不足报错），此时可通过调整 BIOS 中的 Reserved Memory 参数缓解；GTT 区域过大可能导致内核启动时间延长，建议在调试完成后固化配置；PyTorch 的 ROCm 后端在某些自定义层实现上存在行为差异，迁移 CUDA 代码时需留意 tensor layout 与 memory format。
总体而言，Strix Halo 的统一内存架构为单卡运行大模型提供了极具竞争力的硬件基础 —— 无需额外显卡即可在移动设备上完成 30B-70B 参数模型的本地部署。随着 ROCm 生态的持续完善，其在 AI 开发与边缘推理领域的潜力值得持续关注。
资料来源
- Marco Inacio, "My first impressions on ROCm and Strix Halo", 2026-04-18
- AMD ROCm 官方文档，ROCm Installation Guide for Linux