测试SGLang 部署方案后最终恢复llama.cpp方案 —— 单卡AMD Radeon AI PRO R9700(gfx1201 / RDNA4)
-
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 wheel4.2 安装 ROCm 版 PyTorch(先装,避免被覆盖)
ROCm 7.2.4 对应的官方 pin 是 torch 2.11.0(SGLang
pyproject_other.toml的srt_hip_rocm724extra 明确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 R97004.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 gfx12014.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_ogsAPI: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.2all_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 模型上尤其实用)。
️ 在线 FP8 需要先完整下载 BF16 版 Qwen3.8-27B(~54 GB),再量化进显存。下载量大但显存占用只有 ~28.5 GB,32 GB 卡上只能低并发(bs ≤ 2)。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":"你好"}]}' - 官方 ROCm 支持只覆盖数据中心卡: