1. 本机硬件 / 软件配置（实测）
| 项目 | 实测值 |
|---|---|
| CPU | Intel Core Ultra 7 265K（Arrow Lake，20 核 20 线程，最高 5.5 GHz，单 NUMA） |
| 内存 | 64 GB（62 GiB 可用），8 GB swap |
| GPU | AMD Radeon AI PRO R9700（gfx1201，RDNA4 / Navi 48，64 CU，300 W 功耗墙） |
| 显存 | 32 GB（34208743424 B ≈ 31.9 GiB） |
| 硬盘 | Kingston NV2 915 GB NVMe（剩余 721 GB） |
| 操作系统 | Ubuntu 24.04.4 LTS，内核 7.0.0-31-generic |
| ROCm | 7.2.4（HIP 7.2.5 / hipcc 22.0），amdgpu 驱动 7.1.3 |
| Python | 3.12.3（/usr/bin/python3），pip 24.0 |
| 其它 | 无 conda、无 Docker、无 uv；有 git 2.43 / cmake 3.28 / gcc 13.3 / make 4.3 |
| GPU 状态 | 已就绪：rocm-smi 正常识别 R9700，/dev/kfd 存在，当前用户在 render、video 组 |
| 网络 | HuggingFace / PyPI / GitHub / repo.radeon.com 全部可达（200） |
| 已有模型 | ~/.cache/huggingface 含 mattbucci/Qwen3.8-27B-AWQ、Qwen/Qwen3.5-0.8B；另有 llama.cpp 的 Qwen3.8-27B-Uncensored-Q5_K_M.gguf |
2. 核心结论：SGLang 对 gfx1201 的支持现状
- 官方 ROCm 支持只覆盖数据中心卡：
gfx942（MI300/MI325）、gfx950（MI350）。官方 AMD 文档几乎只以 MI300X 为例。 - 消费级 RDNA 未被官方支持：SGLang 官方 tracking issue #30599 明确把 RDNA4
gfx1201列为「blocked /
不支持」，并指出 sgl-kernel 的 setup_rocm.py白名单会直接sys.exit(1)。 - 最新稳定版不含 gfx1201：截至整理时最新稳定版为 v0.5.19（2026-09-05）；实测
main分支sgl-kernel/setup_rocm.py白名单为gfx942 / gfx950 / gfx1250，不含 gfx1201。 - 可行路径 = PR #32092：开源 PR #32092 [AMD] Add experimental gfx1201 inference support 处于未合并（open）状态，但恰好是在「Radeon AI PRO R9700 + ROCm 7.2」上验证通过的（与本机显卡完全一致）。它自带完整构建/启动文档。
- 对比：vLLM 已把
gfx1200/gfx1201列入其 ROCm 构建（PYTORCH_ROCM_ARCH），对 RDNA4 的官方支持更成熟，可作为备选（见 §9）。
一句话：在本机这块 R9700 上跑 SGLang，今天只能走「从源码 + PR #32092」这条路；这是功能可用、但属实验性、单卡限定的方案。
3. gfx1201 实验支持的范围（PR #32092 实测边界）
支持（单卡、--tp 1）：
- BF16 / FP16 稠密模型
- 在线 FP8 量化（稠密模型，
--quantization fp8） - BF16 / FP8 的 Triton 融合 MoE
- GPT-OSS 原生 MXFP4 检查点（
triton_kernelMoE runner）
不支持 / 未验证：
- 多卡（张量并行 TP / 专家并行 EP）、custom all-reduce
- AITER（必须关闭：
SGLANG_USE_AITER=0） - AWQ / GPTQ / Marlin / gguf / modelopt / Quark MXFP4 等其它量化（官方标注「未支持」；AWQ 在 AMD 上走 Triton 反量化，理论上可能能跑，但不在 gfx1201 验证范围内，需自行试）
- 注意力后端只能用 Triton（FlashInfer / FA3 等不可用）
4. 最优部署步骤（从源码构建，gfx1201）
4.0 系统级调优（AMD 官方建议，单卡消费级可选但推荐）
# 1) 关闭 NUMA 自动平衡（AMD 官方 AMD GPU 文档建议；本机单 NUMA，影响较小）
sudo sh -c 'echo 0 > /proc/sys/kernel/numa_balancing'
# 2) 可选：/etc/default/grub 的 GRUB_CMDLINE_LINUX 追加（AMD MI300X 文档建议，单卡可跳过）
# pci=realloc=off iommu=pt
# 然后 sudo update-grub && reboot
关键点：ROCm 7.2 原生支持 gfx1201（自 ROCm 6.4.1 起），无需
HSA_OVERRIDE_GFX_VERSION之类的兼容变量。
4.1 创建独立虚拟环境（避免污染系统 Python）
sudo apt install -y python3-venv python3-dev
python3 -m venv ~/sglang-gfx1201
source ~/sglang-gfx1201/bin/activate
pip install -U pip setuptools wheel
4.2 安装 ROCm 版 PyTorch（先装，避免被覆盖）
ROCm 7.2.4 对应的官方 pin 是 torch 2.11.0（SGLang pyproject_other.toml 的 srt_hip_rocm724 extra 明确 torch==2.11.0）：
# 只跑文本 LLM，装 torch 即可；torchvision/torchaudio 仅多模态需要
pip install torch==2.11.0+rocm7.2 --index-url https://download.pytorch.org/whl/rocm7.2
# 需要多模态再加（版本号以 index 实际为准）：
# pip install torchvision==0.26.0+rocm7.2 torchaudio==2.11.0+rocm7.2 --index-url https://download.pytorch.org/whl/rocm7.2
验证 GPU 可见：
python -c "import torch; print(torch.__version__); print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"
# 期望: 2.11.0+rocm7.2 / True / AMD Radeon AI PRO R9700
4.3 克隆 SGLang 并检出 PR #32092（gfx1201 支持）
git clone https://github.com/sgl-project/sglang.git ~/sglang
cd ~/sglang
git fetch origin pull/32092/head:gfx1201
git checkout gfx1201
4.4 为 gfx1201 编译 sgl-kernel（单架构）
cd ~/sglang
export AMDGPU_TARGET=gfx1201
export PYTORCH_ROCM_ARCH=gfx1201
export GPU_ARCHS=gfx1201
export SGLANG_USE_AITER=0 # RDNA4 上必须关闭 AITER
cd sgl-kernel
python setup_rocm.py install
cd ..
️ 不要在同一份 sgl-kernel 构建里混入 CDNA 目标（gfx942/gfx950）；gfx1201 必须单独构建（wave32 vs wave64 差异）。
4.5 安装 SGLang 所依赖的 triton_kernels 固定版本
PR #32092 依赖特定 revision 的 matmul_ogs API：
pip install --no-deps \
"git+https://github.com/triton-lang/triton.git@4a24bf0b19a027ec0833b31cbc9ac29add7b17af#subdirectory=python/triton_kernels"
4.6 安装 SGLang Python 包（HIP 版）
cd ~/sglang
# 切到 ROCm 版 pyproject（AMD 官方文档的标准步骤）
rm -rf python/pyproject.toml && mv python/pyproject_other.toml python/pyproject.toml
pip install -e "python[all_hip_rocm724]"
# 若安装过程把 torch 覆盖成 CUDA 版，强制装回 ROCm 版：
# pip install --force-reinstall --no-deps torch==2.11.0+rocm7.2 --index-url https://download.pytorch.org/whl/rocm7.2
all_hip_rocm724= 面向 ROCm 7.2.4 / torch 2.11 的依赖集（pyproject_other.toml中已定义，pintorch==2.11.0）。
5. 启动服务器（32 GB 显存的最优参数）
5.1 推荐方案：Qwen3.8-27B 在线 FP8（gfx1201 已验证的稠密量化路径）
source ~/sglang-gfx1201/bin/activate
cd ~/sglang
export SGLANG_USE_AITER=0
python3 -m sglang.launch_server \
--model-path Qwen/Qwen3.8-27B \
--quantization fp8 \
--dtype bfloat16 \
--attention-backend triton \
--sampling-backend pytorch \
--model-loader-extra-config '{"enable_multithread_load": false}' \
--tp 1 \
--mem-fraction-static 0.90 \
--chunked-prefill-size 2048 \
--host 0.0.0.0 \
--port 30000
参数说明：
--quantization fp8：在线 FP8 量化，把 BF16 权重动态量化为 FP8（~28.5 GB），是 gfx1201 上已验证的稠密模型量化方式。--dtype bfloat16：计算 dtype。--attention-backend triton：gfx1201 只能走 Triton 注意力。--sampling-backend pytorch：配合 Triton 使用（AMD 常见组合）。--model-loader-extra-config '{"enable_multithread_load": false}'：PR 文档明确要求——单线程加载，规避 RDNA4 上并行 checkpoint 加载时的 host→device 拷贝卡顿（不影响推理速度）。--tp 1：gfx1201 只支持单卡。--mem-fraction-static 0.90：给 32 GB 显存留 ~2.9 GB 余量，27B-FP8 能放进且不会 OOM。--chunked-prefill-size 2048：小分块 prefill，兼顾 TTFT 与 decode 延迟（27B 混合 GDN 模型上尤其实用）。
5.2 备选：直接跑本机缓存的 AWQ 模型（需自行验证）
python3 -m sglang.launch_server \
--model-path mattbucci/Qwen3.8-27B-AWQ \
--quantization awq \
--dtype bfloat16 \
--attention-backend triton \
--sampling-backend pytorch \
--model-loader-extra-config '{"enable_multithread_load": false}' \
--tp 1 --host 0.0.0.0 --port 30000
- AWQ 4-bit 权重 ~15 GB，显存压力小很多、并发更高。
- 但 AWQ 不在 gfx1201 官方验证范围内（官方文档明说「其它量化格式未支持」）。AMD 上 AWQ 走 Triton 反量化，理论上可行，建议实测；报错就回退到 §5.1 的 FP8。
5.3 更稳的小模型（首次跑通验证环境用）
# Qwen3.5-0.8B（你已缓存）——先验证整条链路能跑通
python3 -m sglang.launch_server \
--model-path Qwen/Qwen3.5-0.8B \
--dtype bfloat16 \
--attention-backend triton \
--sampling-backend pytorch \
--model-loader-extra-config '{"enable_multithread_load": false}' \
--tp 1 --host 127.0.0.1 --port 30000
看到日志输出 The server is fired up and ready to roll! 即启动成功。然后用 OpenAI 兼容接口测试：
curl http://127.0.0.1:30000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"Qwen/Qwen3.5-0.8B","messages":[{"role":"user","content":"你好"}]}'
6. 32 GB 显存能装什么（模型选型建议）
| 模型 | 精度 | 显存占用 | 可行性 |
|---|---|---|---|
| Qwen3.8-27B | BF16 | ~54 GB | 放不下 |
| Qwen3.8-27B | 在线 FP8 | ~28.5 GB | ️ 紧，仅低并发（已验证路径） |
| Qwen3.8-27B | AWQ 4bit | ~15 GB | ️ 需实测（AWQ 未验证） |
| Qwen3-30B-A3B / Qwen3.8-35B-A3B（MoE） | BF16/FP8 | ~18–22 GB | Triton MoE 已支持，性价比高 |
| Qwen3-14B / Qwen2.5-14B | BF16 | ~28 GB | 稳 |
| Qwen3-8B / Qwen2.5-7B | BF16 | ~16 GB | 稳、并发高 |
| GPT-OSS-20B | 原生 MXFP4 | ~13 GB | 已验证（MoE 路径） |
7. 性能 / 调优要点
- 只跑单卡：gfx1201 不支持 TP/EP，
--tp 1是唯一选择。 SGLANG_USE_AITER=0必须设置：AITER 是 CDNA 专用，RDNA4 上会报错。- 注意力后端锁死
triton，采样后端配pytorch。 --mem-fraction-static：32 GB 卡上给 0.85–0.90，留余量避免 OOM。--chunked-prefill-size 2048：长输入/混合负载下让 decode 不被长 prefill 卡住。- KV cache 量化：
--kv-cache-dtype fp8_e4m3可进一步省显存（若模型/后端支持）。 - 大检查点加载慢：ROCm 下 host 内存注册可能耗时数分钟，属正常；PR 要求单线程加载。
- 若追求吞吐，优先选 MoE 小参数（Qwen3-30B-A3B 类）而非硬塞 27B 稠密。
8. 风险与注意事项
- PR #32092 未合并：属实验代码，可能不跟随最新 main；建议锁定其分支 commit 后不要再
git pull main。 - 无预编译 wheel / 官方 Docker 镜像支持 gfx1201：本机也没装 Docker，因此源码构建是唯一现实路径。
- 量化限制：不要用
awq_marlin / gptq_marlin / gguf / modelopt_fp8 / modelopt_fp4（Marlin/gguf 是 CUDA 专用）。 - 构建时间长：sgl-kernel 全量 HIP 编译可能需 20–60 分钟，
MAX_JOBS可调（CPU 20 线程可设MAX_JOBS=16）。 - gfx1201 与 CDNA 不可混编：一份构建只对一个架构。
9. 备选方案（若 SGLang 实验路径不稳）
- vLLM：已官方支持
gfx1200/gfx1201（其Dockerfile.rocm_base的PYTORCH_ROCM_ARCH含这两个目标），对 RDNA4 更成熟，同样有 ROCm 版安装/Docker 路径，是「想要稳定 OpenAI 兼容推理服务」时最直接的替代。 - llama.cpp / Ollama：你机器上已装 llama.cpp 且有
Qwen3.8-27B-Uncensored-Q5_K_M.gguf，现在就能跑，无需任何额外构建；适合本地对话/低门槛场景，但没有 SGLang 的连续批处理/radix cache 等高级特性。 - 若必须用 SGLang 的全套特性（radix cache、speculative decoding、结构化输出等），则按本方案 §4–§5 走 PR #32092。
10. 参考链接 （感兴趣可以自查）
- SGLang 官方 AMD GPU 文档
- SGLang 官方安装文档
- SGLang 量化兼容矩阵
- GitHub issue #30599：官方 RDNA3/RDNA4 支持追踪
- GitHub PR #32092：Add experimental gfx1201 inference support（本方案核心）
- PyTorch ROCm 轮子索引
- AMD Radeon/Ryzen PyTorch 安装指南
11.后续查资料继续实验及恢复
本机硬件 / 软件配置（实测）
| 项目 | 值 |
|---|---|
| CPU | Intel Core Ultra 7 265K（Arrow Lake，20 核 20 线程，最高 5.5 GHz，单 NUMA） |
| 内存 | 64 GB，8 GB swap |
| GPU | AMD Radeon AI PRO R9700（gfx1201 / RDNA4 / Navi 48，64 CU，300W） |
| 显存 | 32 GB |
| 硬盘 | Kingston NV2 915 GB NVMe |
| 系统 | Ubuntu 24.04.4 LTS，内核 7.0.0-31-generic |
| ROCm | 7.2.4（HIP 7.2.5），amdgpu 驱动 7.1.3 |
| Python | 3.12.3 |
12、SGLang 调研结论
- SGLang 官方 ROCm 支持只覆盖数据中心卡
gfx942（MI300）、gfx950（MI350）；消费级 RDNA4gfx1201属实验性、未合并（官方 tracking issue #30599，PR #32092）。 - 最新稳定版 v0.5.19 的 sgl-kernel 白名单不含 gfx1201，需从源码 + 社区补丁构建。
- 已在本机从源码（release/v0.5.18 + gfx1201 补丁）构建并部署，模型 Qwen3.8-27B-AWQ。
13、SGLang 部署结果（已被清理，此处留档）
- 部署形式：systemd 用户服务
sglang，端点http://127.0.0.1:30001。 - 配置：AWQ 4-bit + float16 + triton 注意力 + CUDA graph 解码，显存 ~29.9/32 GB。
- 实测速度：~4.3 tok/s（27B AWQ 在 RDNA4 上走未优化 Triton 反量化，偏慢）。
- 结论：27B 在 R9700 上物理上限约 16.6 tok/s（社区 70 补丁 + FP8 极限），达不到 50 tok/s。
14、快速方案研究结论
- 要 ≥50 tok/s 只能换 7–8B 小模型，实测 ~98 tok/s（llama.cpp/Ollama 原生 gfx1201）。
- 本机 llama.cpp（HIP 后端）实测 27B 可达 ~38–57 tok/s，远快于 SGLang 的 4.3 tok/s。
15、最终清理（按用户要求）
已删除：
- SGLang 运行服务（systemd 用户单元
sglang.service+ 软链） ~/sglang-test/整个目录（含 25GB venv、227MB 源码、全部脚本与日志，共约 45GB）~/.cache/sglang编译缓存loginctl enable-linger（已还原为 disable）- 桌面 5 个 SGLang 相关文档（.md / .pdf）
已保留（模型文件）：
~/models/Qwen3.8-27B-AWQ（18GB，HF 格式 AWQ 模型）~/models/Qwen3.5-0.8B（1.7GB）~/models/qwen3.8/（38GB：Qwen3.8-27B-Uncensored-Q5_K_M.gguf、Qwen3.8-27B-Q5_K_M.gguf、mmproj-f16.gguf）
16、llama.cpp 恢复与测试（当前状态）
- 服务：systemd
qwen38.service（active运行中 +enabled开机自启） - 启动命令：
/home/magicz890/llama.cpp/build/bin/llama-server- 模型
-m Qwen3.8-27B-Uncensored-Q5_K_M.gguf+--mmproj mmproj-f16.gguf - 别名
--alias qwen3.8，上下文-c 131072（128K），KV 量化q8_0 - 推测解码
--spec-type draft-mtp --spec-draft-n-max 2，flash attention-fa on -ngl all（全 GPU）、--host 0.0.0.0 --port 8080
- 模型
- 健康检查：
/health→{"status":"ok"}；/v1/models正常（含多模态能力） - 推理测试：中文输出正确、3 路并发全 200、无错误日志
- 实测解码速度：长生成 ~50 tok/s，短回答 90–105 tok/s（MTP 命中时）
17、最终状态一览
| 项 | 状态 |
|---|---|
| SGLang 服务/软件/缓存/文档 | 已全部删除（零残留） |
| 模型文件 | 保留在 ~/models/（共 ~57GB） |
| llama.cpp（qwen38.service） | 运行中、自启、端口 8080、稳定 |
| 桌面文件 | AMD_AI_Pro_R9700_SGLang_部署研究报告、ceshi/、llama_cpp服务端待机诊断报告.pdf、本文件 |
常用管理命令
# llama.cpp 服务
systemctl status qwen38.service # 查看状态
sudo systemctl restart qwen38.service # 重启
journalctl -u qwen38.service -f # 看日志
# 测试接口
curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"qwen3.8","messages":[{"role":"user","content":"你好"}]}'
