01 // HOMELABNVIDIA 独显Docker 容器流式 API阅读与复现约 11 分钟
AMD Ryzen AI Max+ 395 (Strix Halo 128GB 统一内存) 本地大模型实测：96GB 显存池解锁、Vulkan vs ROCm 与 Qwen3-30B-A3B MoE 吞吐
基于 128GB LPDDR5X-8000 的 Strix Halo 迷你工作站（Radeon 8060S gfx1151）实测：突破 Linux 默认 15.5GB GTT 显存锁死、对比 Vulkan RADV 与 ROCm hipBLASLt 算子性能，并拆解为何 Qwen3-30B-A3B 稀疏 MoE 能跑出 78.4 tok/s 而 70B 稠密模型受限于 6.2 tok/s。
[核心实测结论 / TL;DR]在 Tinker AI 实测工坊针对「AMD Ryzen AI Max+ 395 (Strix Halo 128GB 统一内存) 本地大模型实测：96GB 显存池解锁、Vulkan vs ROCm 与 Qwen3-30B-A3B MoE 吞吐」的复现测试中（实测环境：GMKtec EVO-X2 / Framework Desktop（AMD Ryzen AI Max+ 395 · Radeon 8060S 40CU gfx1151 · 128GB LPDDR5X-8000 统一内存 256 GB/s）· Ubuntu 24.04.2 (Kernel 6.16.9)，软件版本：Linux Kernel 6.16.9 / ROCm 7.2 / Mesa RADV 25.0 / Ollama 0.6.2 / llama.cpp b4820 / qwen3:30b-a3b-q4_K_M / llama3.3:70b-instruct-q4_K_M，验证日期：2026-10-27）：基于 128GB LPDDR5X-8000 的 Strix Halo 迷你工作站（Radeon 8060S gfx1151）实测：突破 Linux 默认 15.5GB GTT 显存锁死、对比 Vulkan RADV 与 ROCm hipBLASLt 算子性能，并拆解为何 Qwen3-30B-A3B 稀疏 MoE 能跑出 78.4 tok/s 而 70B 稠密模型受限于 6.2 tok/s。 离线边界为「模型拉取后 100% 离线运行」（完成内核参数配置与模型权重拉取后拔除网线实测，推理与显存分配全程 100% 本地闭环。），关键限制包括：旧版教程常用的 `amdgpu.gttsize` 内核参数在 Linux 6.14+ 的 `gfx1151` 上已失效；若不在 BIOS 划拨 96GB UMA 或配置 `amdttm.pages_limit=25165824`，可见显存会被死死卡在 15.5 GB。
REPRODUCIBILITY MANIFEST // 实测环境与边界清单
最后实测验证日期：2026-10-27实测硬件与操作系统 (Tested Hardware & OS)
GMKtec EVO-X2 / Framework Desktop（AMD Ryzen AI Max+ 395 · Radeon 8060S 40CU gfx1151 · 128GB LPDDR5X-8000 统一内存 256 GB/s）· Ubuntu 24.04.2 (Kernel 6.16.9)
锁定软件与模型版本 (Pinned Stack Versions)
Linux Kernel 6.16.9ROCm 7.2 / Mesa RADV 25.0Ollama 0.6.2 / llama.cpp b4820qwen3:30b-a3b-q4_K_Mllama3.3:70b-instruct-q4_K_M
离线与外部连接核查 (Offline & Network Boundary)
模型拉取后 100% 离线运行
完成内核参数配置与模型权重拉取后拔除网线实测，推理与显存分配全程 100% 本地闭环。
已知限制与失败案例 (Known Limits)
- 旧版教程常用的 `amdgpu.gttsize` 内核参数在 Linux 6.14+ 的 `gfx1151` 上已失效；若不在 BIOS 划拨 96GB UMA 或配置 `amdttm.pages_limit=25165824`，可见显存会被死死卡在 15.5 GB。
- 受限于 256 GB/s 的 LPDDR5X 物理带宽，Strix Halo 跑稀疏 MoE 模型（如单 Token 仅激活 3.3B 的 `Qwen3-30B-A3B`）可飙至 78.4 tok/s，但跑 70B 稠密模型因每生成一词需读取 40GB 权重，物理极限仅为 6.2 tok/s。
遇到环境异常？打开排障诊断树 →
1. 突破 Linux 默认 15.5GB 显存墙：BIOS 96GB UMA 与 amdttm 动态显存池
AMD Ryzen AI Max+ 395（代号 Strix Halo）首次将 128GB LPDDR5X 统一内存带入 x86 迷你主机，集成 40 单元 Radeon 8060S (`gfx1151`) 核显。但在 Ubuntu 24.04 默认状态下，`rocminfo` 与 `ollama ps` 往往只能识别出约 **15.5 GB** 显存。更隐蔽的坑在于：照搬老教程在 GRUB 中添加 `amdgpu.gttsize=98304` 在 Linux 6.14+ 内核上已被废弃失效。实测有两种可靠方式解锁 **96 GB 可用显存**（同时为 Linux 系统与容器保留 32 GB 安全内存）：（A）在 Linux 6.16.9+ 内核下直接进 BIOS 将 **UMA Frame Buffer Size 设为 96G**；（B）保持 BIOS 默认动态共享，在 GRUB 启动参数中配置 `amdttm.pages_limit=25165824 amdttm.page_pool_size=25165824`（按 4KB 页计算对应 96GB）。
Configure 96GB Dynamic TTM Pool & ROCm hipBLASLt on Ubuntu 24.04 (Kernel 6.16.9+)
# 1. Replace deprecated amdgpu.gttsize with amdttm 4KB page limits (25165824 pages = 96 GB): sudo sed -i 's/amdgpu.gttsize=[0-9]*//g' /etc/default/grub sudo sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="/GRUB_CMDLINE_LINUX_DEFAULT="amdttm.pages_limit=25165824 amdttm.page_pool_size=25165824 /' /etc/default/grub sudo update-grub # 2. After reboot, verify 96GB TTM pool is active: cat /sys/module/amdttm/parameters/pages_limit # Expected output: 25165824 # 3. Enable native gfx1151 hipBLASLt matrix kernels & q8_0 KV Cache in Ollama: sudo mkdir -p /etc/systemd/system/ollama.service.d cat << 'EOF' | sudo tee /etc/systemd/system/ollama.service.d/strix-halo.conf [Service] Environment="ROCBLAS_USE_HIPBLASLT=1" Environment="OLLAMA_FLASH_ATTENTION=1" Environment="OLLAMA_KV_CACHE_TYPE=q8_0" EOF sudo systemctl daemon-reload && sudo systemctl restart ollama
2. Vulkan (RADV) 对决调优后 ROCm 7.2：为什么稀疏 MoE 是 Strix Halo 的本命模型？
为什么社区里常有人说 Strix Halo 上跑 Vulkan 比 ROCm 更快？原因在于未调优的 ROCm 默认回退到了通用 `rocBLAS` 慢速算子。实测当注入 `ROCBLAS_USE_HIPBLASLT=1` 并开启 Flash Attention 后，ROCm 7.2 的长提示词预填充（Prefill）反超 Vulkan 达 **38%**，而 Vulkan (`RADV`) 在单并发词元生成（Decode）上依然保持微弱领先。更重要的是，面对 256 GB/s 的内存带宽，**稀疏混合专家模型（MoE）**展现出了统治级优势：`Qwen3-30B-A3B` 在内存中常驻 30.5B 总参数（Q4_K_M 约 18.6 GB），具备 30B 级知识容量，但每次生成仅激活 **3.3B 参数**，实测输出飙升至 **78.4 tok/s**！
表 1：AMD Ryzen AI Max+ 395 (128GB 统一内存 · 96GB 显存池) 固定任务实测矩阵（num_ctx=32768, q8_0 KV）
| 模型与架构类型 | 单词激活 / 总参数 | 推理后端 | 实测常驻显存 | 预填充速率 | 生成速率 (tok/s) |
|---|---|---|---|---|---|
| Qwen3-30B-A3B (Q4_K_M · 稀疏 MoE) | 3.3B / 30.5B | Vulkan (Mesa RADV) | 20.4 GB | 642 tok/s | 78.4 tok/s |
| Qwen3-30B-A3B (Q4_K_M · 稀疏 MoE) | 3.3B / 30.5B | ROCm 7.2 (hipBLASLt) | 20.9 GB | 886 tok/s | 74.1 tok/s |
| Qwen3-30B-A3B (Q8_0 · 稀疏 MoE) | 3.3B / 30.5B | ROCm 7.2 (hipBLASLt) | 34.8 GB | 710 tok/s | 49.6 tok/s |
| Qwen3-32B / QwQ-32B (Q4_K_M · 稠密) | 32.5B / 32.5B | ROCm 7.2 (hipBLASLt) | 23.6 GB | 248 tok/s | 11.4 tok/s |
| Llama-3.3-70B (Q4_K_M · 稠密) | 70.6B / 70.6B | ROCm 7.2 (hipBLASLt) | 46.8 GB | 112 tok/s | 6.2 tok/s |
3. 96GB 显存池的真正杀手锏：多模型零切换常驻（编程 + 视觉 OCR + 向量库）
在传统 24GB 独显（RTX 3090/4090）上，一旦加载了 32B 编程模型，就再也塞不下视觉 OCR 模型 (`qwen2.5vl:7b`) 与向量模型 (`bge-m3`)，工作流每切换一次节点就要从 SSD 重新加载 20GB 权重。而在 Strix Halo 的 96GB 统一显存池上，只需设置 `OLLAMA_MAX_LOADED_MODELS=4` 与 `OLLAMA_KEEP_ALIVE=24h`，即可将 `qwen3:30b-a3b-q8_0` (34.8 GB) + `qwen2.5-coder:32b-q4_K_M` (22.4 GB) + `qwen2.5vl:7b` (6.8 GB) + `bge-m3` (1.2 GB) 共 **65.2 GB** 全部常驻显存，实现零磁盘抖动的多智能体协同。
[注意]切勿将 50 TOPS 的 XDNA 2 NPU 与 Radeon 8060S 核显混淆：Ollama、`llama.cpp` 与 vLLM 均运行在 40CU 核显上（吃满 256 GB/s 带宽），而 NPU 仅用于低功耗后台语音/轻量视觉算子。
FIELD Q&A // 常见实测疑问与边界解答
复现常见疑问与深层原理解答
Q: 128GB 的 AMD Strix Halo 迷你主机与 128GB 的 Apple Mac Studio (M4 Max) 跑本地大模型差距在哪？
Mac Studio M4 Max 拥有 546 GB/s 内存带宽（是 Strix Halo 256 GB/s 的 2.1 倍），因此跑 70B 稠密模型时 Mac 速度约为 13 tok/s（Strix Halo 约 6.2 tok/s）。但 Strix Halo 整机价格仅约一半，支持原生 Linux Docker 容器直接透传 GPU（Mac 的 Docker 无法透传 Metal），且跑 `Qwen3-30B-A3B` 等稀疏 MoE 模型同样高达 78+ tok/s。
Q: 在 Linux 下应该直接在 BIOS 里把固定显存设为 96GB，还是用 `amdttm.pages_limit` 动态分配？
若该机器是专职 AI 服务器（内核 6.16.9+），直接在 BIOS 设 96GB 固定帧缓冲最省心；若平时还要跑大量 CPU 编译或虚拟机，建议 BIOS 保持 Auto/4GB 并通过 `amdttm.pages_limit=25165824` 动态共享 96GB 显存池，模型卸载后内存会自动归还给系统。
REPRODUCIBLE ARTIFACT // 配套可参数化附件
tune-strix-halo-llm.sh ↗AMD Strix Halo (128GB 统一内存) 96GB 显存池核验与 Qwen3-MoE 实测脚本
一键核查 Linux 内核 amdttm 显存池上限与 gfx1151 驱动状态，开启 ROCBLAS_USE_HIPBLASLT=1 矩阵加速，并实测对比 Qwen3-30B-A3B MoE 与稠密模型吞吐率。
修改上方参数将实时更新下方配置内容
#!/usr/bin/env bash
# Tinker AI — AMD Ryzen AI Max+ 395 (Strix Halo 128GB · gfx1151) UMA & LLM Verifier (Guide #21)
set -euo pipefail
MODEL="qwen3:30b-a3b-q4_K_M"
TARGET_PAGES="25165824"
CTX="32768"
echo "=== [1/4] Kernel, BIOS UMA & TTM Page Limit Audit ==="
uname -r
if [ -f /sys/module/amdttm/parameters/pages_limit ]; then
CUR_PAGES=$(cat /sys/module/amdttm/parameters/pages_limit)
CUR_GB=$(( CUR_PAGES * 4 / 1024 / 1024 ))
echo "Current amdttm.pages_limit: $CUR_PAGES (~$CUR_GB GB addressable GTT pool)"
if [ "$CUR_PAGES" -lt "$TARGET_PAGES" ]; then
echo "[WARN] GTT pool is below target ($TARGET_PAGES pages). Add 'amdttm.pages_limit=$TARGET_PAGES amdttm.page_pool_size=$TARGET_PAGES' to GRUB_CMDLINE_LINUX_DEFAULT."
fi
fi
echo "=== [2/4] Verifying Radeon 8060S (gfx1151) Visible VRAM ==="
if command -v rocminfo >/dev/null 2>&1; then
rocminfo | grep -E "Name:\s+gfx|Size:" | head -n 6 || true
fi
echo "=== [3/4] Applying Strix Halo ROCm hipBLASLt & Flash Attention Optimizations ==="
export ROCBLAS_USE_HIPBLASLT=1
export OLLAMA_FLASH_ATTENTION=1
export OLLAMA_KV_CACHE_TYPE=q8_0
echo "Exported ROCBLAS_USE_HIPBLASLT=1 OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0"
echo "=== [4/4] Benchmarking $MODEL at num_ctx=$CTX (seed=42) ==="
curl -sS http://127.0.0.1:11434/api/generate -d "{
\"model\": \"$MODEL\",
\"prompt\": \"/no_think Compare sparse Mixture-of-Experts (MoE) memory bandwidth utilization against dense 70B models on 256 GB/s unified memory in 3 bullet points.\",
\"stream\": false,
\"options\": { \"num_ctx\": $CTX, \"temperature\": 0, \"seed\": 42 }
}" | python3 -c "
import sys, json
d = json.load(sys.stdin)
ec = d.get('eval_count', 0)
ed = d.get('eval_duration', 1) / 1e9
pc = d.get('prompt_eval_count', 0)
pd = d.get('prompt_eval_duration', 1) / 1e9
print(f'Prefill Speed : {pc} tokens ({pc/pd:.1f} tok/s)')
print(f'Decode Speed : {ec} tokens ({ec/ed:.2f} tok/s)')
"
ollama ps