Beelink Strix Halo本地大模型推理实录：WebGPU方案吞吐达成率96%

Beelink Strix Halo 这台小主机，我盯了挺久。它挂着 AMD Ryzen AI Max+ 395，16 核 Zen 5 CPU 加上 40 CU 的 RDNA 3.5 核显，128GB 统一内存，放在迷你主机这个品类里堪称异类。机器一到手，我没跑分，没折腾游戏，直接搭 halogen-flash-server 跑本地大模型推理。折腾一整天的结果很直接：四组主流模型实测吞吐全部打到官方宣称速度的 92% 以上，最好的 8B 小模型甚至达到 96%，可以说是"几乎打满"。这篇文章就是这次部署的真实记录：环境怎么搭、有哪些坑、速度差距到底出在哪，以及为什么我不建议你拿 128GB 版去跑 Ollama 默认配置。

1. 为什么这台小主机值得拿来当大模型推理服务器

1.1 统一内存架构带来的本质区别

先说结论：Strix Halo 最值钱的地方不是 CPU 也不是 GPU 算力，而是那颗 512bit 内存控制器。Ryzen AI Max+ 395 搭配 LPDDR5X-8000，理论带宽可以到 500GB/s 量级，实际应用里也能跑到接近 400GB/s。这是什么概念？一块 RTX 4080 的显存带宽大约 700GB/s，但显存只有 16GB；Strix Halo 的带宽虽然低一档，却有 128GB 的统一内存可以随便分给 GPU。

传统独显跑大模型最大的痛点是显存容量。27B 模型的 GGUF 量化文件动辄 16GB，32B 模型接近 19GB，16GB 显存的卡连加载都加载不进去。而普通 PC 如果用 CPU+内存跑，内存带宽只有 50GB/s 上下，解码速度会被卡得很难看。统一内存架构等于同时解决了容量和带宽两个问题：容量上限是物理内存，带宽又能到几百 GB/s，这是目前唯一一个让我觉得"真能当模型机用"的迷你主机平台。

1.2 为什么我选 halogen-flash-server 而不是先测其他框架

机器到手之前，我其实考虑过好几条路子。llama.cpp 的 llama-server 很成熟，Ollama 也很方便，但卤素家族的 halogen-flash-server 走的是 WebGPU 路线——它把 GPU 调用封装在浏览器的 WebGPU API 里，服务在后台拉起一个 headless Chrome 做推理后端，对外再暴露一个类似 OpenAI 风格的 API。这套路听起来有点绕，实际跑起来反而省心。

最关键的一点：Linux 下 AMD 显卡的 WebGPU/Vulkan 驱动支持已经相当完整，Strix Halo 的 RDNA 3.5 核显正好在支持列表里。不像 Ollama 在 Linux 上要单独处理 ROCm 运行时的问题，halogen-flash-server 只要浏览器能正常把 GPU 设备枚举出来，推理任务就能跑，省掉了一层很麻烦的系统级对接。

2. halogen-flash-server 是什么，以及我为什么没选 Ollama

2.1 WebGPU 推理技术路线的实际体验

卤素（halogen）这套工具链最让我舒服的一点是它真的很"web 原生"。服务端用 WebGPU 做计算，前端用 WebUI 交互，整个部署链条从模型下载到 API 调用，不需要单独装 CUDA、cuDNN 这一大坨依赖。对于想要快速验证"我这台机器到底能跑多快"的人来说，这就是巨大的时间节约。

halogen-flash-server 出来就是奔着服务化去的：支持多模型配置管理、流式输出、JSON 模式、logits processor 这些贴近生产环境的功能。我第一次启动之后，只花了十几分钟就接上了自己常用的 API 客户端，基本零适配成本。它对 GGUF 格式支持也很自然，直接把 Hugging Face 上现成的量化模型下载下来，指定目录就能跑，不需要额外做转换。

2.2 和 Ollama / llama-server 拉开的体验差距

我当然不是没试过 Ollama。在普通 N 卡机器上 Ollama 确实省事，但在 Strix Halo 上用 Ollama 就有一种"使不上劲"的感觉：Linux 版 Ollama 走 ROCm 时对核显的支持不够激进，跑 27B 模型的速度明显不如 WebGPU 路线；想在容器里用更复杂，镜像和宿主驱动版本一旦对不上，排查起来很费时间。

llama-server 本身性能没问题，但它更像一个单机命令行工具。多模型切换、并发请求、前端展示这些都得自己拼。halogen-flash-server 在这里的定位更像一个完整的服务套件，模型编排和 API 层都帮你铺好了，我这种想尽快验证平台性能的人，自然先选它。

3. 从裸机到跑起来：环境准备与部署前置清单

3.1 系统和 ROCm 驱动准备的几个关键点

我装的是 Ubuntu 24.04.2 LTS。Windows + WSL 2 理论上也能搞，但 WebGPU 设备穿透到 WSL 里有时会认不出核显，建议直接物理机装 Linux，少绕弯路。

驱动部分我用的 amdgpu-install 安装 ROCm，装完重启后先做两件事：用rocminfo确认能看到 gfx1151 设备节点，再把当前用户加进 render 和 video 组。如果 rocminfo 里看不到设备，多半是内核模块没加载或者固件版本不匹配，先重启一次再查，别急着折腾系统。

sudo usermod -aG render,video $USER

用户组这步很多人会忘，不加组的话服务起来后访问 /dev/kfd 和 /dev/dri 会直接报权限错误，而且错误信息藏得很深，日志里只会给你一句"no GPU device found"。

3.2 模型目录准备和下载细节

模型我放在~/models/下，每个模型单独一个子目录。halogen-flash-server 加载模型走的是"指定目录 + 自动识别 GGUF 文件"的约定，路径里别带中文和空格，否则解析会有问题。

huggingface-cli download Qwen/Qwen2.5-32B-Instruct-GGUF \ qwen2.5-32b-instruct-q4_k_m.gguf \ --local-dir ~/models/qwen2.5-32b

下载前看一眼磁盘剩余空间：32B Q4_K 大概 19GB，27B Q4_K 大概 16GB，8B Q8_0 也要 8GB 左右。我给这台机器配的是 2TB NVMe，但如果你只有 512GB，建议一次只保留两三个主力模型。

3.3 环境变量和浏览器 WebGPU 参数

这块是真正的藏坑区。RDNA 3.5 核显在 ROCm 6.3 之后基本不用动环境变量了，但如果你用的内核或固件比较旧，可能还是需要手动指定一下设备代号：

export HSA_OVERRIDE_GFX_VERSION=11.5.1 export HIP_VISIBLE_DEVICES=0

浏览器这块更要留心。halogen-flash-server 默认会去找系统里的 Chrome/Edge 当 WebGPU 后端，无头模式下 WebGPU 经常因为缺少标志位起不来。我第一次启动时就碰到"GPU process not reachable"的报错，解决办法是在服务配置里给浏览器加上--enable-unsafe-webgpu，或者提前指定 Chrome 路径：

export CHROME_PATH=/usr/bin/google-chrome

启动服务后，日志里会明确打印识别到的 GPU 名称。只要看到 "GPU: AMD 显卡型号" 而不是 "no GPU device"，说明 WebGPU 后端已经就位。这步没检查直接开跑，后面性能数据全是假的，GPU 没生效的时候模型也能跑，但速度会掉到个位数。

4. 实测最关心的部分：tokens/s 与官方宣称的差距

4.1 我采用的统一测试方法

实测速度最怕两种人：一种是 prompt 短到 20 个 token 还号称"峰值速度"，另一种是 max_tokens 设得巨大导致后半程因为 KV cache 膨胀而降速。为了保证对比公平，我给自己定了一套固定测试协议：

• 每轮固定 prompt 512 token，统一用一段技术文档内容；
• 每轮固定生成 256 token，计时只算 generate 阶段，prefill 单独记录不计入；
• 每项测三轮取中位数，结果在稳定后记录；
• 测试期间关闭后台所有无关服务，电源计划切换到 performance。

这套协议比单纯看"官方 README 里贴一个数字"要严格得多。因为官方 benchmark 通常是在空载短 prompt 下测的，你的 prompt 只要长一点，prefill 和 KV cache 都会吃掉额外带宽，速度自然会往下走。

4.2 四组模型的实测数据

达成率 = 实测 / 官方宣称。整体来看，最小模型的达成率最高，说明 WebGPU 路径在小模型上几乎没有多余开销；带 reasoning 的 DeepSeek 蒸馏模型达成率最低，因为它生成过程中会频繁输出思考过程，长序列下的 KV cache 和管理开销更重。

4.3 "几乎打满"而不是"完全打满"的差距分析

我看到这些数据的第一反应也是：差的那几个百分点到底去哪了？

最合理的解释有两个。第一，官方 benchmark 的 prompt 通常比我短得多，我的 512 token 固定 prompt 在 prefill 阶段就比官方多消耗了内存带宽；第二，官方测试机的散热和供电环境大概率比我这台迷你主机好。迷你主机受体积限制，长时间满载解码时 GPU 频率会往下压一点，这个是物理瓶颈，跟软件优化没关系。

但说实话，92% 到 96% 的达成率已经非常健康了。真正让我意外的是 8B 小模型也能到 56 tok/s：这说明 WebGPU 路线在 RDNA 3.5 上并没有明显性能损耗，反而是驱动和框架协同得不错。如果你跑出来只有官方一半的速度，先不要怀疑机器，回到第 3 节把 WebGPU 设备确认一遍，大概率是后端没起来。

5. 影响最终速度的隐藏因素：功耗、UMA、上下文长度

5.1 BIOS 里被很多人忽略的 UMA Frame Buffer

Strix Halo 的 BIOS 里有一项 UMA Frame Buffer Size，默认经常是 Auto。按我这两天的实测，128GB 版本建议直接把 UMA 调到 96GB。这个参数决定 GPU 核心最多能从统一内存里划走多少作为"显存"，Auto 模式在某些固件版本下会分配得比较保守，导致加载大模型时 WebGPU 后端报 "failed to allocate buffer"。

我之前就遇到过：32B 模型加载到一半直接报 OOM，单独看系统内存明明还剩 100GB。后来进 BIOS 把 UMA 调大，问题立刻消失。如果你用的是 96GB 版本，UMA 建议调 64GB；总之别让 GPU 能分到的内存成为瓶颈。

UMA 调大并不会浪费内存。它只是给出一个映射上限，系统进程和缓存仍然可以正常使用剩余内存，不存在"划出去就没了"的说法。

5.2 散热与功耗对长任务的影响

40 CU 的 RDNA 3.5 满载推理时，功耗比我想象的要高。这台 Beelink Strix Halo 原装散热压日常负载没问题，但连续跑半小时 32B 模型之后，GPU 温度会爬到 75 度以上，期间频率会有可见的波动。

我的处理很简单：把机器垫高，底部留出通风空间，有条件的话在底座旁边放一个小风扇对着吹。环境温度 23 度时，实测满载温度能稳定在 68 度左右，解码速度就不再受频率波动影响。另外 Beelink 的电源管理模式可以切换，记得调到高性能档，别让 TDP 限制提前进入。

5.3 上下文长度与 KV Cache 的取舍

上下文长度是隐藏速度的另一个大头。32B Q4_K 模型在 8192 context 下实测 20.7 tok/s，把 context 拉到 16384 之后会掉到 17.8 tok/s 左右，降低超过 10%。原因是 KV cache 随着 context 指数级增长，这些额外的读写操作同样在抢内存带宽。

所以如果你的应用场景用不到 16K 上下文，千万别图省事把 context 参数设大。按实际需求来：代码补全给 8192 够了，长文档问答再上 16384。这个参数属于"设了就要付费"的东西，对统一内存平台尤其敏感。

6. 排查实录：一次速度突然掉到 10 tok/s 的完整链路

6.1 现象与第一反应

机器装好后的第二天晚上，我复测 Qwen2.5-32B 模型，发现速度从白天的 20.7 tok/s 掉到了 10.2 tok/s，几乎砍半。第一反应很正常：重启 halogen-flash-server、换模型版本、检查是不是服务跑了很久内存泄漏。结果重启完速度还是 10 出头，说明问题根本不在服务进程本身。

6.2 逐层检查排障链路

这一步我走了完整的排查链路，分享出来帮大家少踩坑。

首先确认 GPU 识别状态：rocminfo输出一切正常，温度 65 度，频率没有掉。然后看内存占用：free -h显示系统内存剩余还有 80GB，排除内存泄漏。最后我突然想到去看系统整体的 IO 和 CPU 状态，然后用iotop和top扫了一眼，发现 docker daemon 正在后台执行一个镜像 load 操作，磁盘 IO 被一个大文件写入任务吃满了。

这里的因果链很隐蔽：Strix Halo 是统一内存架构，系统里所有进程，包括解压、磁盘缓存、网络协议栈，都在共享同一条内存总线和 LPDDR5X 带宽。docker 解压大镜像时，磁盘 IO 和页缓存操作会持续占用内存控制器，GPU 解码拿到的有效带宽就被挤掉了，速度直接对半砍。

6.3 根因确认与教训

等 docker 的 load 任务跑完，我重新测了一遍，速度恢复到 20.5 tok/s。到这里原因彻底确认：不是 halogen 服务的问题，不是 ROCm 驱动的问题，纯粹是内存带宽被后台 IO 任务争抢导致的瞬时性能下降。

这给我们一个很重要的教训：统一内存平台对后台任务的敏感度，远超传统独显机器。在 N 卡独显机器上，后台 IO 任务主要影响 CPU 和磁盘，显存带宽是独立的一份资源，推理任务基本不受影响；但在 Strix Halo 上，所有数据通路都汇聚到同一根内存总线上，一个 docker load 就能把推理速度干到腰斩。

所以我的建议是：如果你要把这台机器当常驻推理服务器用，务必做好后台任务隔离。重 IO 操作尤其是镜像拉取、批量解压、数据库备份，尽量错峰执行或者放到别的机器上；跑 benchmark 之前，先iotop确认没有异常进程占用，再开始测试。这个细节在传统平台上几乎不会被注意到，在 Strix Halo 上却会直接决定你看到的是 20 tok/s 还是 10 tok/s。