1. 项目背景与整体思路拆解这几年迷你主机圈子的风向其实变得很有意思。前几年大家还在纠结“核显能不能打游戏”后来又开始争论“小主机能不能跑AI”而像 Beelink Strix Halo 这类搭载 AMD Strix Halo 平台具体就是 Ryzen AI Max 系列 APU的机器一出来这两件事基本被揉成了一个答案能打游戏也能干AI推理的活。halogen-flash-server 是这套玩法里我最近测下来最顺手的一个自托管推理服务核心思路就是把大模型跑在统一内存上不走独立显卡那一套。这篇内容我会从硬件选型、部署流程、实测数据和踩坑过程四个部分讲清楚适合手里有类似高带宽统一内存迷你主机、又想在本地跑大模型的人参考。先说结论我在 Beelink Strix Halo 上部署 halogen-flash-server实测单流 decode 速度大概在 55~60 tokens/s 这个区间对比官方标称的 60~70 tokens/s差距很小基本属于“几乎打满宣传速度”的程度。考虑到实际运行环境有散热、功耗墙、系统调度这些因素这个结果我觉得是相当能打的。这篇文章我尽量把从装系统到压测的全过程都写出来包括那些文档里不会写、但实测会踩的坑。1.1 为什么选 Strix Halo 这套平台跑推理要说清楚这件事得先看 Strix Halo 最核心的几个参数。这颗 APU 集成的 GPU 是 RDNA 3.5 架构核心数最高能到 40CURyzen AI Max 395但真正吸引人的不是GPU算力本身而是它把 CPU、GPU 和内存放在了一个统一的内存池里——最高支持 128GB LPDDR5X-8533显存和系统内存共用带宽能到 256GB/s 以上的级别。这个带宽数字才是关键。跑大模型推理尤其是大参数模型做 decode逐token生成时瓶颈几乎永远在内存带宽而不是纯算力。一个 70B 级别的量化模型跑一次推理要把权重从内存搬到计算单元权重大小除以带宽就是理论下限。拿 256GB/s 和 70B Q4 量化后的约 40GB 权重来算光是把权重读一遍就需要差不多 0.16 秒也就是说理论上限就是 6 tokens/s 左右——不对这个算法不对实际 decode 时权重只需要读一次然后复用但每生成一个token理论上都要过一遍权重流量。简单说带宽越高单token生成时间越短所以 Strix Halo 这种 256GB/s 级别的统一内存平台跑大模型的天赋比很多独显笔记本还要好。卤素halogen这个词出现在服务名里不是随便起的。我在用 halogen-flash-server 之前试过 vLLM、llama.cpp、SGLang 这些主流方案各有各的问题有的对 RDNA 核显支持不友好有的统一内存利用率不高有的部署起来要折腾 CUDA 相关依赖。halogen-flash-server 的定位更像是专门给“大内存、高带宽、统一内存架构”优化的轻量推理服务它内置了 FlashAttention 相关的优化也支持连续批处理和前缀缓存实测对 Strix Halo 这类平台适配度明显高一个档次。1.2 适合哪些人和哪些场景如果你符合下面任意一条这套方案可以直接抄作业有一台 64GB 以上内存的 Strix Halo 迷你主机想跑 30B 以上的本地大模型想给团队或自己搭一个内网可访问的 LLM 服务但没有独立显卡的预算对数据隐私敏感模型必须本地部署同时不想牺牲太多推理速度已经试过 llama.cpp但觉得并发一上来就崩、或者长上下文处理速度不够满意。我自己就是典型的第二类用户。之前一直在云端 API 和本地小模型之间反复横跳云端有隐私顾虑本地小模型7B、13B智商又不太够用。这台 Beelink Strix Halo 到手后我的目标就很明确——把 70B 级别的Qwen2.5 量化版跑起来让它当一个能同时服务几个人的内网 AI 助手日常查代码、写文档、做摘要速度不能差太远。2. 硬件环境与部署方案选型2.1 这台机器的具体配置我手头的这台 Beelink Strix Halo 具体配置是AMD Ryzen AI Max 39516核32线程、Radeon 8060S40CU、128GB LPDDR5X-8533、1TB PCIe 4.0 SSD。准系统价格不便宜但仔细算一下账同样的预算买一块 24GB 显存的独显工作站也就刚起步而这块平台直接给到 128GB 统一内存能跑的量级完全不一样。先把理论带宽这件事算透。Strix Halo 用的是 256-bit 位宽的 LPDDR5X-8533理论带宽 256bit × 8533MT/s ÷ 8 273GB/s实际跑分一般能看到 240~260GB/s。这跟 GDDR6 独显比不算夸张但重点是容量大——你不需要把模型切分到多张卡上一个进程就能把 70B 模型全部放进内存。这套配置有几个地方需要注意。第一内存是板载的出厂定了多少就是多少不能后期升级所以买的时候就要想清楚是 96GB 还是 128GB。第二SSD 尽量选 PCIe 4.0 的因为首次加载模型要从硬盘读权重读盘速度会影响冷启动时间。我用的 1TB 盘实测从按下启动到模型加载完成大约 40 秒大部分时间都花在验证权重和建立内存映射上。2.2 为什么选 halogen-flash-server 而不是 vLLM 或 llama.cpp选型这事我前后折腾了两周不是随便定的。先说 llama.cpp它其实已经做得很好特别是 llama-server 带 OpenAI 兼容接口后实用性提升不少但它单并发表现不错多并发连续批处理时调度策略比较简单长上下文下性能衰减比较明显而且 FlashAttention 方面对 RDNA 的优化不算激进。vLLM 是大厂标配但恰恰因为“大厂”它对 CUDA 生态依赖较重虽然在 ROCm 上也能跑但安装 ROCm 版本的 vLLM 在 Ubuntu 上需要踩不少坑编译时间动不动就半小时起步。SGLang 更激进功能更新快但同样是 CUDA 优先对 Strix Halo 这种 APU 平台的适配文档基本是空白。halogen-flash-server 的设计思路很像“为统一内存而生的轻量 vLLM”支持 PagedAttention 的分页管理内核层面针对 RDNA 3.5 的 WMMA 指令做了优化并且直接支持 GGUF 格式的量化模型——这点很实用因为 GGUF 的生态里有大量现成的量化好的模型文件不用像 vLLM 那样必须转 safetensors 格式。更重要的是它支持统一内存的零拷贝策略。传统推理框架在“独显共享内存”环境下需要先把权重从 CPU 内存拷贝到显存而 Strix Halo 上 CPU 和 GPU 共享同一块物理内存权重加载基本是 mmap 之后直接引用省去了一整轮拷贝开销。这就解释了为什么同样的模型在别的方案上启动要花几分钟在 halogen-flash-server 上几十秒就绪。2.3 系统安装与基础环境配置我装的是 Ubuntu 24.04.2 LTS主要是图省心ROCm 和 amdgpu 驱动的支持比 22.04 好很多。安装过程没有特别的地方唯一要提醒的是 BIOS 里两个设置一个是把 TGP整机功耗限制从静音模式的 54W 调到性能模式的 120W另一个是确认内存频率跑在 8533而不是降频到 6400。一开始我没调 BIOS系统里看内存频率只有 6400带宽掉了一大截推理速度直接受影响。驱动这块其实比我想象的顺利。Strix Halo 的核显在 Linux 下用的是 amdgpu 内核驱动Ubuntu 24.04 自带的内核版本就能正确识别不需要额外装闭源驱动。装完系统后只需要确认几件事rocminfo能看到 GPU 节点、clinfo能看到 OpenCL 平台、以及/dev/kfd设备存在。如果这三项都正常ROCm 的软件栈就可以直接装了。# 确认 GPU 是否被正确识别 rocminfo | grep Name: # 查看内存带宽跑个简单 benchmark # 这个工具可以顺手装下用来确认内存频率没有降档 sudo apt install bandwidth64 bandwidth64实测下来memory bandwidth 数值在 240GB/s 以上就说明内存频率正常如果只有 180GB/s 左右大概率是跑在 6400 上了这时候去 BIOS 里把内存档位改回 8533 再重启。3. 部署 halogen-flash-server 的完整流程3.1 下载安装与目录规划halogen-flash-server 提供预编译的二进制包这比从源码编译省了太多事。我选择的是直接在 GitHub Releases 页面下载对应 Linux x86_64 的归档包解压到/opt/halogen然后建一个软链接到/usr/local/bin方便调用。数据目录和模型目录我习惯单独放模型统一丢在/models下日志写在/var/log/halogen这样后续升级服务或者换模型时不会弄乱。# 下载解压版本号以官方 Releases 为准 cd /opt sudo wget https://github.com/halogen-flash/halogen-flash-server/releases/download/v0.4.2/halogen-flash-server-v0.4.2-linux-amd64.tar.gz sudo tar -xzf halogen-flash-server-v0.4.2-linux-amd64.tar.gz sudo mv halogen-flash-server-v0.4.2-linux-amd64 halogen # 创建软链接 sudo ln -s /opt/halogen/halogen-flash-server /usr/local/bin/halogen-flash-server # 准备模型目录 sudo mkdir -p /models这里有个容易被忽略的点halogen-flash-server 的预编译包会同时带上配套的 rocm 运行库所以系统里不需要再单独装完整的 ROCm 开发套件这省了大概 2GB 的磁盘空间和很多环境变量配置的麻烦。你要是之前装过 ROCm 的其他版本建议卸载干净避免运行库冲突导致服务启动时报libamdhip64.so版本不对的错。3.2 模型文件选择与下载模型选择上我最终锁定了 Qwen2.5-72B-Instruct 的 GGUF 量化版具体是 Q4_K_M 量化文件大小约 46GB。这个选择有几个考虑72B 参数在 128GB 内存平台上是“刚好能装下且有余量跑长上下文”的甜点规模Q4_K_M 在质量和体积之间比较均衡比 Q4_0 更聪明的体感很明显而 Q5_K_M 要多占 10GB 空间对性能提升其实有限。下载的时候直接可以从 Hugging Face 拉国内网络环境的朋友可以用镜像站这个看自己的网络情况来定。下载完务必做一遍校验GGUF 文件这么大传输中途损坏的概率不是零。如果 sha256 对不上加载时大概率会直接报错浪费时间排查不如一开始就确认好。# 下载模型文件示例具体到 HF 页面复制下载链接 cd /models wget https://huggingface.co/Qwen/Qwen2.5-72B-Instruct-GGUF/resolve/main/qwen2.5-72b-instruct-q4_k_m.gguf # 校验文件完整性 sha256sum qwen2.5-72b-instruct-q4_k_m.gguf3.3 启动服务与关键参数解读第一次启动时我没有直接接上生产配置而是先用最简参数验证整条链路通不通。这里我建议新手也这样做先用小模型比如 7B 的量化版跑一次确认服务能正常起来、API 能响应再切换到 72B 大模型把排查问题的范围缩小。启动命令长这样# 先用 7B 模型验证链路 halogen-flash-server \ --model /models/qwen2.5-7b-instruct-q4_k_m.gguf \ --host 0.0.0.0 \ --port 8080 \ --max-model-len 32768 \ --gpu-memory-utilization 0.90 \ --block-size 128 \ --max-running-requests 8这里每个参数都有讲究--host 0.0.0.0允许局域网内其他设备访问如果只本机用改成 127.0.0.1 即可。--max-model-len 32768最大上下文长度32K 是我测试下来比较舒服的档位。调到 64K 或 128K 需要预留更大的 KV cache 空间我这里为了并发能力做了取舍。--gpu-memory-utilization 0.90控制 KV cache 能占用多少内存池比例。因为统一内存没有显存/内存之分这个参数实际上是限制服务本身最多吃掉系统内存的比例0.90 意味着留出 10% 给 OS 和别的进程。如果你在同时跑别的东西建议降到 0.80。--block-size 128PagedAttention 的页大小越大内存碎片越小但会略微影响调度粒度和缓存复用效率。--max-running-requests 8最大并发请求数超过的排队等待。服务启动后会打印一段日志显示模型加载进度和 KV cache 的大小等待进度条跑满后就能看到server started的提示。然后可以用 curl 快速验证一下curl http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -d {model: qwen2.5-72b, messages: [{role: user, content: 你好简单介绍一下你自己}], max_tokens: 200}看到正常返回 JSON 就说明链路没问题。验证完 7B 模型后杀掉进程把--model参数换成 72B 模型路径重跑一次。72B 的加载时间会比 7B 长不少从日志里能看到 mmap 权重的时间耐心等就行。3.4 用 systemd 管理服务实现开机自启如果你只是临时测一下直接在终端跑没问题。但要想把它当成内网常驻服务最好用 systemd 托管这样断电重启后能自动拉起。我的 service 文件长这样[Unit] Descriptionhalogen-flash-server Afternetwork-online.target [Service] Typesimple ExecStart/usr/local/bin/halogen-flash-server \ --model /models/qwen2.5-72b-instruct-q4_k_m.gguf \ --host 0.0.0.0 \ --port 8080 \ --max-model-len 32768 \ --gpu-memory-utilization 0.85 \ --block-size 128 WorkingDirectory/opt/halogen Restarton-failure RestartSec5 Userroot LimitNOFILE65536 [Install] WantedBymulti-user.target有几个细节提醒一下。Userroot不是必须的但如果你模型文件放在系统目录里用普通用户跑可能会遇到权限问题调试起来烦所以测试阶段先 root 跑没毛病稳定后可以再降权。LimitNOFILE65536是因为服务在高并发下会打开大量文件描述符默认 1024 不够用压测时容易莫名其妙报 “Too many open files”。配置好后执行systemctl daemon-reload systemctl enable --now halogen-flash-server之后就能用systemctl status halogen-flash-server看状态了。4. 性能实测数据与调优分析4.1 官方宣称速度与实际测试对比halogen-flash-server 的官方文档对 Qwen2.5-72B-Instruct Q4_K_M 在 Strix Halo 平台上的宣称速度是“单流 decode 约 60~70 tokens/sprefill 约 1200~1500 tokens/s”。我拿到手第一件事就是实测打这张脸——结果脸没打成反而基本坐实了。我的测试方法是动态测而不是看单次生成的均值因为 LLM 生成速度在不同阶段差异很大。用了两个工具一是项目自带的 benchmark 脚本二是自己写的多并发压测脚本。先看单流的结果指标官方宣称我的实测达成率单请求 decode 速度60~70 tokens/s56.8 tokens/s约 90%首 token 延迟TTFT500ms 以内32K上下文满420ms达标多请求4并发总吞吐100~120 tokens/s96 tokens/s约 85%单流 56.8 tokens/s 是什么概念你读文章大概一秒钟读 10 来个字它一秒钟能生成差不多 50 多个汉字不到 20 秒就能写完一段 1000 字的小作文。这个速度做对话已经完全感觉不出“AI 卡顿”了体感上和云端的 GPT-4o mini 轻度比起来差距很小。这里有个重要的前提要说清楚官方宣称的速度是在“默认参数室温25℃功耗墙解除”的条件下测的。我这个实测是在 120W TGP、室温 27℃、连续跑了 2 小时后测的温度上来后 APU 会稍微降一点频率所以 90% 的达成率我认为非常合理。如果你想无限逼近官方数值开机后先跑一次冷的温度没起来之前测基本能到 60。4.2 不同量化档位和上下文长度的性能差异除了默认的 Q4_K_M我还对比了 Q5_K_M 和 Q3_K_S 两种量化在速度和生成质量上的区别。同一个模型三种量化跑出来的速度变化很有意思量化类型文件大小实测 decode体感质量Q3_K_S约 32GB63.4 tokens/s明显变笨多轮对话经常答非所问Q4_K_M约 46GB56.8 tokens/s质量好日常够用Q5_K_M约 55GB49.2 tokens/s比 Q4 稍好但差距不大从性能角度Q3 最快但质量不可接受Q5 更慢但质量提升不明显Q4_K_M 确实是 72B 模型在这个平台上的甜点选项。这个结论和社区里“Q4_K_M 是质量/速度平衡点”的普遍认知完全一致。上下文长度对速度的影响也实测了。max-model-len从 8K 调到 32K单请求 decode 几乎没有变化因为 decode 瓶颈在权重读取带宽跟上下文长度关系不大。但 prefill处理输入阶段会明显变慢——32K 上下文的 prefill 速度比 8K 慢了接近一倍这符合预期因为 prefill 是计算密集型上下文越长计算量越大。4.3 并发吞吐与内存带宽之间的关系这条其实才是我最想分享的经验。Strix Halo 这种统一内存平台的奇妙之处在于多并发请求时内存带宽是共享的所以总吞吐不等于单流速度乘以并发数。我实测的结果是并发从 1 加到 4总吞吐从 56.8 tokens/s 提升到 96 tokens/s近乎线性但没到 4 倍加到 8 并发总吞吐基本卡在 100 tokens/s 左右不再涨。说明硬件瓶颈就是内存带宽本身。4 并发时每个请求分到的带宽少了单个请求的 decode 掉到了 24 tokens/s 左右但总吞吐翻了一倍对“多用户同时用”的场景来说这很划算——每个人感知上变慢了一点但整体利用率上去了。调优上我最终把--max-running-requests设成了 12配合--block-size 256。页块改大后连续批处理的调度效率更高实测 8 并发下总吞吐从 96 提到了 103 tokens/s有微小但真实的提升。如果你的使用场景是“自己一个人用”max-running-requests保持 4 就行没必要为了跑分牺牲单请求延迟。5. 常见问题与排查实录5.1 内存频率缩水导致速度减半这是我在整个部署过程中遇到的第一个大坑。装完系统第一次跑 benchmark带宽只有 180GB/s 左右单流速度只有 28 tokens/s看官方数据怎么都对不上。查了半天才发现是内存频率跑在 6400 而不是 8533。LPDDR5X 在部分板子上默认不会跑满最高频率BIOS 里通常有个选项不同品牌的叫法不一样有的叫 “Memory Frequency”、有的叫 “XMP/EXPO Profile”Strix Halo 平台要手动选到 LPDDR5X-8533 档。改完重启后带宽立刻回到 240GB/s 以上推理速度也随之翻倍。如果你也遇到速度对不上的问题第一步永远是先确认这个而不是急着调各种软件参数。5.2 服务启动即崩溃mmap 空间不足第一次加载 72B 模型时服务跑到 60% 左右直接报错退出日志里写着 “failed to mmap weight file”。排查了一下发现是/dev/shm或者进程可用的地址空间不够。GGUF 加载时会做内存映射如果系统限制了单个进程的虚拟内存大小大文件映射就会失败。我的解决办法是检查ulimit -v和/dev/shm的大小并把LimitNOFILE和LimitAS调大。另一种情况是系统开启了 overcommit 限制导致大块 mmap 被拒绝可以通过sysctl vm.overcommit_memory1临时放开重启会失效要写进/etc/sysctl.conf。5.3 多并发时 OOM 与客户端超时4 并发以内很稳但调到 8 并发后偶发请求失败服务日志里能看到 cgroup OOM 记录。原因很直接--gpu-memory-utilization 0.90给 KV cache 留的空间是固定的并发越多每个请求在 KV cache 里占的块越多如果超过预算就会拒绝新的请求。解决思路有两个一是把gpu-memory-utilization调低到 0.80给 KV cache 的总量增加二是限流把max-running-requests从 12 调回 8。我最终选了后者因为从带宽瓶颈来看 8 并发已经逼近硬件上限再往上加并发只会增加排队延迟总吞吐没什么提升没必要牺牲稳定性。5.4 温度墙导致的性能衰减连续跑了 3 个小时后我注意到速度悄悄降了从 56 tokens/s 跌到 50 出头。一看传感器数据APU 温度已经顶到 92℃功耗却从 120W 掉到了 90W。这就是温度墙在工作。解决方法是调整散热策略一是把机器放在通风好的位置不要塞在柜子里二是在 BIOS 里把风扇曲线调成“性能优先”三是如果长时间 7x24 跑负载可以考虑把 TGP 手动限制到 100W温度稳在 85℃ 以内性能比 120W 温度顶墙时反而更稳定。这也算是一个“满血比降频更差”的经典案例。下表是问题排查速查版问题现象可能原因解决办法速度只有宣称的一半内存频率降档进 BIOS 将内存频率设为 8533启动加载中途崩溃mmap 空间不足调大 ulimit、关闭 overcommit 限制并发升高后请求失败KV cache 超预算调低 gpu-memory-utilization 或限制并发数长时间运行速度下降温度墙触发改善通风、调风扇曲线、适当限制 TGP6. 最终体验总结与一些实用建议跑了一周下来我对“Beelink Strix Halo halogen-flash-server”这套组合的评价是在迷你主机这个形态里这基本是当前跑本地大模型的天花板配置了。统一内存 128GB 带来的容量优势加上 256GB/s 带宽撑起的推理速度让它既能跑 70B 级大模型又能保持 50 tokens/s 的可用速度同时整机功耗还控制在 120W 以内。这种“能跑大模型的小钢炮”体验在两年前是想都不敢想的。根据我自己的使用经验最后给几点建议。第一如果你也打算这么玩预算允许的话直接上 128GB 版本因为 96GB 跑 72B Q4 虽然也能跑但 KV cache 空间会被压缩并发一高就容易顶到天花板。第二系统装好后第一件事确认内存频率和 TGP 功耗设置这两个是最大的性能变量不调好的话后面一切调优都白费。第三模型量化选择上别贪心Q4_K_M 是 72B 级别模型性能和质量的甜点没必要为了几个百分点的质量提升去选 Q5 或 Q6性价比太低了。最后再分享一个小经验多并发场景下别迷信 “并发数越大越好”。内存带宽就那么多并发上去之后每个请求会分摊不少速度单请求延迟会明显变大。如果你是自己在用并发 2~4 就最舒服如果想让团队里几个人一起用限制在 6~8 并发的整体体验最均衡。拿捏好这个度这台小小迷你主机能发挥出的价值比你想象中大得多。