为什么在 Strix Halo 上折腾 SGLang最近拿到一台搭载 AMD Strix Halo 芯片的工程机这颗 APU 集成了强大的 Radeon GPU 和 Ryzen AI NPU理论上端侧推理能力相当可观。以往在 AMD 平台上跑大模型大家首选往往是 Ollama 或者 LM Studio毕竟它们对 ROCm 的适配相对成熟开箱即用。但这次我想挑战点不一样的在 Strix Halo 上部署SGLang并实测其核心的结构化输出能力。选择 SGLang 并非为了“能跑”而是看中它在处理重复前缀和强制 JSON 输出时的独特优势。官方文档里提到的 RadixAttention 机制和比传统方案快 10 倍的 JSON 解码在 NVIDIA 显卡上已经验证过多次但在 AMD 最新的 Strix Halo 架构上表现如何是否存在算子不支持的坑这篇博文就记录我从环境配置到实际压测的全过程给想在 AMD 端侧设备搞高性能推理的朋友做个参考。跨越架构鸿沟Strix Halo 上的环境搭建在 Strix Halo 上运行 SGLang最大的拦路虎不是模型本身而是软件栈。SGLang 深度依赖 Flash Attention 和 Triton 后端而这两者在 AMD ROCm 生态中的支持一直处于“追赶”状态。目前的 SGLang 主分支对 ROCm 的支持还在快速迭代中直接pip install大概率会失败或运行时报错。我的实践路径是采用WSL2 (Windows Subsystem for Linux)配合原生 ROCm 驱动或者直接在使用 Ubuntu 22.04/24.04 的原生环境下操作。这里强烈建议原生环境因为 WSL2 透传 GPU 给 ROCm 容器偶尔会出现显存映射问题影响 RadixAttention 的缓存效率。核心依赖安装首先确保你的系统已经正确安装了 AMD ROCm 6.0 驱动。Strix Halo 作为最新架构需要较新的驱动版本才能完整释放算力。# 检查 ROCm 版本建议 6.0 以上rocminfo|grep-iversion接下来是 Python 环境的准备。SGLang 目前对 PyTorch 的 ROCm 版本有特定要求建议使用 PyTorch 官方提供的 ROCm 预编译包而不是通过 pip 默认安装。# 创建虚拟环境python3-mvenv sglang-rocmsourcesglang-rocm/bin/activate# 安装带有 ROCm 支持的 PyTorch (以 2.4 为例具体视 ROCm 版本而定)pip3installtorch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.0# 安装 Triton (AMD 分支)# 注意标准 triton 包可能不兼容需寻找 amd-triton 或兼容版本pip3installtriton-amd最关键的步骤是安装 SGLang。由于主分支对 ROCm 支持尚在完善我推荐从源码编译安装并开启相应的后端标志。如果直接 pip 安装失败可以尝试指定 extra 索引或手动编译 flash attention。# 克隆源码gitclone https://github.com/sgl-project/sglang.gitcdsglang/python# 安装依赖并编译# 这里的 FLASH_ATTENTION_FORCE_BUILD1 很重要确保针对当前硬件重新编译FLASH_ATTENTION_FORCE_BUILD1pip3install-e.[all]在安装过程中如果遇到hipblaslt相关的链接错误通常需要设置环境变量指向 ROCm 库路径exportLD_LIBRARY_PATH/opt/rocm/lib:$LD_LIBRARY_PATHexportPATH/opt/rocm/bin:$PATH完成安装后运行一个简单的测试脚本确认 GPU 是否被识别。如果能看到 Radeon GPU 的设备 ID 且显存正常加载说明底层环境已打通。实战结构化输出JSON 提取任务演示环境跑通只是第一步SGLang 的真正威力在于其编程模型对结构化生成的原生支持。在 Strix Halo 上我们用一个经典的信息抽取场景来测试从一段非结构化的产品评论中提取品牌、型号和情感倾向并强制输出为合法的 JSON 格式。传统做法是让模型自由生成然后用正则表达式去解析这在端侧设备上风险很大——一旦模型多输出了一个句号或少了一个引号整个程序就会崩溃。而 SGLang 允许我们在代码层面定义 Schema模型生成时会严格遵循约束。下面是一个基于 SGLang DSL 的示例代码importsglangassglfromsglangimportfunction,system,user,assistant,gen,set_default_backendfromsglang.backends.runtime_endpointimportRuntimeEndpoint# 启动本地服务 (假设模型已下载到本地)# 使用 Qwen2.5-7B-Instruct 为例该模型在 Strix Halo 上量化后运行流畅backendRuntimeEndpoint(http://localhost:30000)set_default_backend(backend)functiondefextract_product_info(s,text):ssystem(你是一个精准的数据提取助手。请严格按照 JSON 格式输出不要包含任何多余的解释。)suser(f分析以下评论{text})sassistant(gen(json_output,max_tokens256,# 关键定义结构化约束schema{type:object,properties:{brand:{type:string},model:{type:string},sentiment:{type:string,enum:[positive,negative,neutral]}},required:[brand,model,sentiment]}))# 模拟输入数据comments[这台 Strix Halo 笔记本性能太强了AMD 这次真的翻身了特别是 Radeon 显卡玩游戏很流畅。,电池续航有点崩虽然处理器很快但发热控制一般有点失望。,屏幕素质不错但是风扇噪音在满载时比较明显整体中规中矩。]forcommentincomments:stateextract_product_info.run(textcomment)print(f输入{comment})print(f提取结果{state[json_output]})print(-*30)在 Strix Halo 上运行这段代码你会发现模型几乎不会输出“废话”。它会在生成第一个字符时就锁定 JSON 的起始花括号并在枚举值如 sentiment处严格限制候选词。这种“引导式生成”不仅提高了后续解析的稳定性更重要的是它显著减少了无效 Token 的计算从而降低了端到端延迟。RadixAttention 实测缓存命中率与延迟对比SGLang 的另一大杀手锏是RadixAttention。它的原理是将 Prompt 的前缀部分Prefix进行缓存复用。在我们的场景中System Prompt“你是一个精准的数据提取助手…对于每一条请求都是完全相同的。传统推理框架每次都会重新计算这部分 KV Cache而 SGLang 会将这部分结果保留在显存中后续请求直接复用。为了量化这一效果我在 Strix Halo 上设计了一组对比实验连续发送 100 条具有相同 System Prompt 但不同 User Content 的请求。测试配置模型Qwen2.5-7B-Instruct (INT4 量化)硬件AMD Strix Halo (Radeon 890M 集成显卡)指标首字延迟 (TTFT) 和 总吞吐量 (Tokens/s)实验结果分析在关闭 RadixAttention 优化或模拟传统框架行为时每条请求的 TTFT 波动较大平均在 120ms 左右因为每次都要重新计算 System Prompt 的上下文。而在开启 SGLang 默认优化后从第二条请求开始TTFT 迅速下降至 40ms 以内降幅超过 60%。更直观的是显存带宽的节省。Strix Halo 虽然是 APU共享系统内存带宽相比独立显存仍有瓶颈。通过nvidia-smi的替代品rocm-smi或 SGLang 自带的监控日志观察发现 KV Cache 的命中率在稳定阶段达到了 75% 以上。这意味着四分之三的显存读写操作被省去了这对于带宽敏感的端侧设备至关重要。在吞吐量方面处理 100 条短文本的总耗时从传统方式的 15 秒缩短到了 9 秒左右。虽然绝对数值受限于 APU 的算力上限无法与企业级 H100 相比但在端侧设备上这种相对提升意味着用户体验的质变——响应更快设备发热更低。AMD 硬件上的已知限制与应对策略尽管在 Strix Halo 上成功跑通了 SGLang但必须诚实地指出目前 AMD 生态在运行此类前沿推理框架时仍存在一些局限性这也是进阶用户必须面对的現實。首先是算子支持度。SGLang 强依赖的 Flash Attention 2 在 ROCm 上的支持不如 CUDA 完善。在某些特定的 Attention 头数或序列长度下可能会触发 fallback 机制退回到效率较低的普通 Attention 实现导致性能不如预期。遇到这种情况建议尝试调整模型的max_model_len或使用特定版本的 flash-attention-rocm 补丁。其次是量化兼容性。虽然 INT4 量化在 Strix Halo 上运行良好但 SGLang 的一些高级量化格式如 FP8在 AMD 硬件上的支持尚不稳定。目前在 Strix Halo 上推荐使用 GGUF 格式配合 llama.cpp 后端或者使用标准的 INT4/INT8 AWQ 格式避免盲目追求最新量化技术导致推理崩溃。最后是关于多卡并行。Strix Halo 目前是单芯片方案不存在多卡通信问题但如果未来在 AMD 服务器集群上部署 SGLangNCCL 的替代方案 RCCL 的配置复杂度会显著高于 NVIDIA 环境。对于端侧用户而言这一点暂时无需担心专注于单卡优化即可。Workaround 建议如果在启动服务时遇到HIP error或内核编译失败尝试显式指定 GPU 架构目标exportHSA_OVERRIDE_GFX_VERSION11.5.0# 根据 Strix Halo 的具体 GFX 版本调整此外保持 ROCm 驱动和内核处于最新稳定版是解决大多数兼容性问题的万能钥匙。写在最后在 Strix Halo 上部署 SGLang 是一次充满挑战但也收获颇丰的探索。它证明了 AMD 的端侧平台不再仅仅是“能跑大模型”而是有能力支撑起结构化、高并发、低延迟的复杂推理任务。RadixAttention 带来的缓存红利在共享内存架构的 APU 上显得尤为珍贵让有限的带宽发挥了最大价值。当然目前的体验还达不到“一键完美”的程度编译过程中的报错和算子适配问题依然需要手动干预。但随着 ROCm 生态的成熟和 SGLang 社区对 AMD 支持的加强相信未来在 Ryzen AI Radeon 的组合上我们能获得更接近甚至超越同级别 NVIDIA 设备的推理体验。对于关注边缘计算和隐私敏感应用的开发者来说现在正是深入调研这条技术路线的最佳时机。
Strix Halo 芯片实测，端侧运行 SGLang 结构化输出
发布时间：2026/6/17 4:25:28
为什么在 Strix Halo 上折腾 SGLang最近拿到一台搭载 AMD Strix Halo 芯片的工程机这颗 APU 集成了强大的 Radeon GPU 和 Ryzen AI NPU理论上端侧推理能力相当可观。以往在 AMD 平台上跑大模型大家首选往往是 Ollama 或者 LM Studio毕竟它们对 ROCm 的适配相对成熟开箱即用。但这次我想挑战点不一样的在 Strix Halo 上部署SGLang并实测其核心的结构化输出能力。选择 SGLang 并非为了“能跑”而是看中它在处理重复前缀和强制 JSON 输出时的独特优势。官方文档里提到的 RadixAttention 机制和比传统方案快 10 倍的 JSON 解码在 NVIDIA 显卡上已经验证过多次但在 AMD 最新的 Strix Halo 架构上表现如何是否存在算子不支持的坑这篇博文就记录我从环境配置到实际压测的全过程给想在 AMD 端侧设备搞高性能推理的朋友做个参考。跨越架构鸿沟Strix Halo 上的环境搭建在 Strix Halo 上运行 SGLang最大的拦路虎不是模型本身而是软件栈。SGLang 深度依赖 Flash Attention 和 Triton 后端而这两者在 AMD ROCm 生态中的支持一直处于“追赶”状态。目前的 SGLang 主分支对 ROCm 的支持还在快速迭代中直接pip install大概率会失败或运行时报错。我的实践路径是采用WSL2 (Windows Subsystem for Linux)配合原生 ROCm 驱动或者直接在使用 Ubuntu 22.04/24.04 的原生环境下操作。这里强烈建议原生环境因为 WSL2 透传 GPU 给 ROCm 容器偶尔会出现显存映射问题影响 RadixAttention 的缓存效率。核心依赖安装首先确保你的系统已经正确安装了 AMD ROCm 6.0 驱动。Strix Halo 作为最新架构需要较新的驱动版本才能完整释放算力。# 检查 ROCm 版本建议 6.0 以上rocminfo|grep-iversion接下来是 Python 环境的准备。SGLang 目前对 PyTorch 的 ROCm 版本有特定要求建议使用 PyTorch 官方提供的 ROCm 预编译包而不是通过 pip 默认安装。# 创建虚拟环境python3-mvenv sglang-rocmsourcesglang-rocm/bin/activate# 安装带有 ROCm 支持的 PyTorch (以 2.4 为例具体视 ROCm 版本而定)pip3installtorch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.0# 安装 Triton (AMD 分支)# 注意标准 triton 包可能不兼容需寻找 amd-triton 或兼容版本pip3installtriton-amd最关键的步骤是安装 SGLang。由于主分支对 ROCm 支持尚在完善我推荐从源码编译安装并开启相应的后端标志。如果直接 pip 安装失败可以尝试指定 extra 索引或手动编译 flash attention。# 克隆源码gitclone https://github.com/sgl-project/sglang.gitcdsglang/python# 安装依赖并编译# 这里的 FLASH_ATTENTION_FORCE_BUILD1 很重要确保针对当前硬件重新编译FLASH_ATTENTION_FORCE_BUILD1pip3install-e.[all]在安装过程中如果遇到hipblaslt相关的链接错误通常需要设置环境变量指向 ROCm 库路径exportLD_LIBRARY_PATH/opt/rocm/lib:$LD_LIBRARY_PATHexportPATH/opt/rocm/bin:$PATH完成安装后运行一个简单的测试脚本确认 GPU 是否被识别。如果能看到 Radeon GPU 的设备 ID 且显存正常加载说明底层环境已打通。实战结构化输出JSON 提取任务演示环境跑通只是第一步SGLang 的真正威力在于其编程模型对结构化生成的原生支持。在 Strix Halo 上我们用一个经典的信息抽取场景来测试从一段非结构化的产品评论中提取品牌、型号和情感倾向并强制输出为合法的 JSON 格式。传统做法是让模型自由生成然后用正则表达式去解析这在端侧设备上风险很大——一旦模型多输出了一个句号或少了一个引号整个程序就会崩溃。而 SGLang 允许我们在代码层面定义 Schema模型生成时会严格遵循约束。下面是一个基于 SGLang DSL 的示例代码importsglangassglfromsglangimportfunction,system,user,assistant,gen,set_default_backendfromsglang.backends.runtime_endpointimportRuntimeEndpoint# 启动本地服务 (假设模型已下载到本地)# 使用 Qwen2.5-7B-Instruct 为例该模型在 Strix Halo 上量化后运行流畅backendRuntimeEndpoint(http://localhost:30000)set_default_backend(backend)functiondefextract_product_info(s,text):ssystem(你是一个精准的数据提取助手。请严格按照 JSON 格式输出不要包含任何多余的解释。)suser(f分析以下评论{text})sassistant(gen(json_output,max_tokens256,# 关键定义结构化约束schema{type:object,properties:{brand:{type:string},model:{type:string},sentiment:{type:string,enum:[positive,negative,neutral]}},required:[brand,model,sentiment]}))# 模拟输入数据comments[这台 Strix Halo 笔记本性能太强了AMD 这次真的翻身了特别是 Radeon 显卡玩游戏很流畅。,电池续航有点崩虽然处理器很快但发热控制一般有点失望。,屏幕素质不错但是风扇噪音在满载时比较明显整体中规中矩。]forcommentincomments:stateextract_product_info.run(textcomment)print(f输入{comment})print(f提取结果{state[json_output]})print(-*30)在 Strix Halo 上运行这段代码你会发现模型几乎不会输出“废话”。它会在生成第一个字符时就锁定 JSON 的起始花括号并在枚举值如 sentiment处严格限制候选词。这种“引导式生成”不仅提高了后续解析的稳定性更重要的是它显著减少了无效 Token 的计算从而降低了端到端延迟。RadixAttention 实测缓存命中率与延迟对比SGLang 的另一大杀手锏是RadixAttention。它的原理是将 Prompt 的前缀部分Prefix进行缓存复用。在我们的场景中System Prompt“你是一个精准的数据提取助手…对于每一条请求都是完全相同的。传统推理框架每次都会重新计算这部分 KV Cache而 SGLang 会将这部分结果保留在显存中后续请求直接复用。为了量化这一效果我在 Strix Halo 上设计了一组对比实验连续发送 100 条具有相同 System Prompt 但不同 User Content 的请求。测试配置模型Qwen2.5-7B-Instruct (INT4 量化)硬件AMD Strix Halo (Radeon 890M 集成显卡)指标首字延迟 (TTFT) 和 总吞吐量 (Tokens/s)实验结果分析在关闭 RadixAttention 优化或模拟传统框架行为时每条请求的 TTFT 波动较大平均在 120ms 左右因为每次都要重新计算 System Prompt 的上下文。而在开启 SGLang 默认优化后从第二条请求开始TTFT 迅速下降至 40ms 以内降幅超过 60%。更直观的是显存带宽的节省。Strix Halo 虽然是 APU共享系统内存带宽相比独立显存仍有瓶颈。通过nvidia-smi的替代品rocm-smi或 SGLang 自带的监控日志观察发现 KV Cache 的命中率在稳定阶段达到了 75% 以上。这意味着四分之三的显存读写操作被省去了这对于带宽敏感的端侧设备至关重要。在吞吐量方面处理 100 条短文本的总耗时从传统方式的 15 秒缩短到了 9 秒左右。虽然绝对数值受限于 APU 的算力上限无法与企业级 H100 相比但在端侧设备上这种相对提升意味着用户体验的质变——响应更快设备发热更低。AMD 硬件上的已知限制与应对策略尽管在 Strix Halo 上成功跑通了 SGLang但必须诚实地指出目前 AMD 生态在运行此类前沿推理框架时仍存在一些局限性这也是进阶用户必须面对的現實。首先是算子支持度。SGLang 强依赖的 Flash Attention 2 在 ROCm 上的支持不如 CUDA 完善。在某些特定的 Attention 头数或序列长度下可能会触发 fallback 机制退回到效率较低的普通 Attention 实现导致性能不如预期。遇到这种情况建议尝试调整模型的max_model_len或使用特定版本的 flash-attention-rocm 补丁。其次是量化兼容性。虽然 INT4 量化在 Strix Halo 上运行良好但 SGLang 的一些高级量化格式如 FP8在 AMD 硬件上的支持尚不稳定。目前在 Strix Halo 上推荐使用 GGUF 格式配合 llama.cpp 后端或者使用标准的 INT4/INT8 AWQ 格式避免盲目追求最新量化技术导致推理崩溃。最后是关于多卡并行。Strix Halo 目前是单芯片方案不存在多卡通信问题但如果未来在 AMD 服务器集群上部署 SGLangNCCL 的替代方案 RCCL 的配置复杂度会显著高于 NVIDIA 环境。对于端侧用户而言这一点暂时无需担心专注于单卡优化即可。Workaround 建议如果在启动服务时遇到HIP error或内核编译失败尝试显式指定 GPU 架构目标exportHSA_OVERRIDE_GFX_VERSION11.5.0# 根据 Strix Halo 的具体 GFX 版本调整此外保持 ROCm 驱动和内核处于最新稳定版是解决大多数兼容性问题的万能钥匙。写在最后在 Strix Halo 上部署 SGLang 是一次充满挑战但也收获颇丰的探索。它证明了 AMD 的端侧平台不再仅仅是“能跑大模型”而是有能力支撑起结构化、高并发、低延迟的复杂推理任务。RadixAttention 带来的缓存红利在共享内存架构的 APU 上显得尤为珍贵让有限的带宽发挥了最大价值。当然目前的体验还达不到“一键完美”的程度编译过程中的报错和算子适配问题依然需要手动干预。但随着 ROCm 生态的成熟和 SGLang 社区对 AMD 支持的加强相信未来在 Ryzen AI Radeon 的组合上我们能获得更接近甚至超越同级别 NVIDIA 设备的推理体验。对于关注边缘计算和隐私敏感应用的开发者来说现在正是深入调研这条技术路线的最佳时机。
