跳转到主要内容
不建议使用的硬件。Tokios 不建议将 AMD Strix Halo（Ryzen AI Max+ 395）作为主要的推理平台。该硬件目前仍处于社区探索阶段：驱动程序支持情况不稳定，ROCm 的稳定性受内核与固件版本的制约，目前唯一可靠的后端技术为 Vulkan。若用于生产环境或日常推理任务，我们推荐选用 Mac Studio、DGX Spark 或 RTX 工作站。本页面专为已购置 Strix Halo 硬件并希望充分发挥其性能的用户而设。
AMD Ryzen AI Max+ 395（即 Strix Halo）平台最多可提供 128GB 的统一内存供中央处理器与 Radeon 8060S 集成显卡共享使用。这一内存容量足以承载那些通常需要价值 $2,000 以上的独立显卡才能运行的模型。不过 215 GB/s 的内存带宽水平以及混合专家架构与密集架构的差异，将直接决定您最终获得的令牌生成速度究竟是 2 个/秒还是 30 个/秒。本页面将详细说明哪些模型可顺利运行以及预期的性能表现。

​
简要结论：混合专家架构模型更具优势

MoE (mixture-of-experts) models are 3–14× faster than dense models of the same total parameter count on Strix Halo. The reason is bandwidth: only the active parameters in an MoE model are read from memory per token, so a 122B MoE model with 10B active parameters generates tokens at nearly the speed of a 10B dense model — not a 122B one. 若您打算挑选一款日常使用的模型，建议从参数范围处于 35B 至 122B 之间的混合专家模型入手。

​
128GB unified memory explained

Strix Halo 并未配备独立的显存。其集成式图形处理器与中央处理器共享同一块 DDR5 内存池。出厂状态下，BIOS 与操作系统会预先占用部分 128 GB 内存：

​
在 Linux 系统中配置 BIOS 内存

在 Linux 系统中，内核会自动完成内存分配。系统启动后通常会有 95至110GB 内存可供 GPU 运算使用。多数情况下无需手动调整 BIOS 设置。

​
在 Windows 系统中配置内存

在 Windows 系统中，需要完成 2项设置：
  1. BIOS → UMA Frame Buffer — 请将其设置为可用的最大值（通常是“自动”或某个固定数值）。
  2. AMD Adrenalin → VRAM allocation — 打开 AMD Software: Adrenalin Edition，进入 Settings → Graphics → Advanced，随后将显存滑块调整至 96GB。
若未在 Windows 系统中配置 Adrenalin 显存分配，您的集成显卡可能仅能识别 15.5 吉字节的显存，这一数值对于大型模型而言严重不足。在尝试加载参数规模超过 30B 的模型前，请务必同时设置 BIOS 与 Adrenalin 显存滑块。

​
密集型模型的兼容性说明

密集型模型在处理每个令牌时均需调用全部参数，因此每一轮计算都必须从内存中读取完整的权重张量。在 215 吉字节/秒的传输速率下，令牌生成速度便会被限制在某一固定上限。
在 Strix Halo 平台上，Qwen3-Coder-30B 搭配 Q4_K_M 配置是众多编程辅助工具（如 Cline、Aider、OpenCode）所青睐的密集型模型。该模型能够轻松适配系统环境，且生成速度可达 10 至 15 令牌/秒。

​
混合专家架构模型的兼容性

此类模型虽然整体参数数量庞大，但每个令牌生成时仅激活其中一部分参数。如此一来，每个步骤所需的内存带宽大幅降低，从而显著提升生成效率。 拥有 3 至 12B 个活跃参数的混合专家模型最为理想。这类模型能在聊天或编程过程中提供前沿级别的质量表现，同时保证流畅的响应速度。
GLM-4.6 模型（总参数量 357B，活跃参数量 32B）无法在 Strix Halo 上运行。在 Q4_K_M 量化等级下，其所需显存容量约为 178 GB，这一数值远超 128 GB 的统一显存池上限，即便借助 2 节点的 RDMA 集群技术也仅能提供 256 GB 显存。建议在 Strix Halo 上使用 GLM-4.5-Air 模型。关于各版本对比详情，请参阅 GLM 系列介绍。

​
Strix Halo 平台上的 Kimi K3 模型

Kimi K3 does not fit Strix Halo. The model’s 2.8T total parameters (~50B active per token through Stable LatentMoE) need about 1.4 TB at the native MXFP4 precision. Strix Halo’s full 128 GB pool — roughly 90–110 GB after OS overhead — is about 1.27 TB short of the raw weight floor. Moonshot recommends serving K3 on a supernode with 64 or more accelerators. For the full memory calculation, see the Kimi K3 hardware deep dive. For Strix Halo today, the models that fit are in the tables above — up to ~122B MoE at Q4 on a single node. See what to run instead of Kimi K3 for the best pick at 128 GB.

​
Qwen3.8 on Strix Halo

The Qwen3.8 flagship shipped in August 2026 as Qwen3.8-2.4T-A95B: a Mixture-of-Experts model with 2.4 trillion total parameters and 95B active per token, text-only, released under Qwen’s custom qwen3.8-max license. The generation also includes Qwen3.8-27B (released 2026-08-14, Apache-2.0), a dense vision-language model that does fit Strix Halo — see below.

​
各量化等级下的纯权重存储需求

Even at the most aggressive quantization, Strix Halo cannot run Qwen3.8-2.4T-A95B. This is a multi-node cluster model that requires at least 5 DGX Sparks (or equivalent) at Q2 — and realistically 10+ nodes at Q4 for reasonable KV cache headroom. For full cluster sizing, see the Qwen3.8 model page.
MoE models load all expert weights into memory even though only a subset activates per token. Qwen3.8-2.4T-A95B activates 95B of its 2.4T, but the 1.2 TB at Q4 is a hard floor regardless. The MoE advantage is in compute (fewer FLOPs per token), not in memory.

​
适用于 Strix Halo 的 Qwen3.8 模型

Qwen3.8-27B 属于该系列中的单机版模型：这是一款密集型的 27B 视觉语言模型，于 2026 年 08 月 14 日依据 Apache-2.0 许可证发布。官方提供的 30.9 GB FP8 版本仅需 96 GB 的显存空间即可顺畅运行；即便是 55.6 GB BF16 版本也完全适用。不过对于此类硬件而言，实际可行的 llama.cpp/Vulkan 部署方案还是使用 Q4_K_M 格式的 GGUF 文件（大小约为 17 GB，目前尚未发布）。关于各类版本的显存需求详情可查阅 Qwen3.8 模型页面；待验证后，所有经过测试的配置信息也会在此处更新。

​
ROCm 与 Vulkan 后端对比

Strix Halo 搭载的 Radeon 8060S 集成显卡（gfx1151）可借助 2 各类后端执行推理运算，各方案均存在各自的优劣之处。 请使用 Vulkan，除非你有特殊需求必须选用 ROCm（例如需要利用 BF16 精度来执行微调评估）。
关于包括 llama.cpp Vulkan 与 Ollama 在内的各类运行环境选项，可参阅 Strix Halo 平台上的 vLLM 及其他方案。

​
带宽限制因素

Strix Halo 搭载的 DDR5 内存可提供 215 GB/s 的理论带宽值。这一数值是评估系统性能的核心指标：
  • 令牌生成过程受内存带宽制约。生成每个令牌时都需要从内存中读取模型的相关权重参数。
  • A 70B dense model at Q4 (~40GB) needs 40GB ÷ 215 GB/s ≈ 186ms per token → ~5 tok/s.
  • A 122B MoE model with 10B active at Q4 (~7GB active weights) needs 7GB ÷ 215 GB/s ≈ 33ms per token → ~30 tok/s.
提示词处理（预填充阶段）主要受计算能力制约，其执行速度较令牌生成环节更快。实际使用中可发现长提示词的处理过程十分迅速，随后生成速度便会降至受带宽限制的水平。

​
不同应用场景下的性能预期

​
基于 RDMA 技术的实验性 2 节点集群方案

2 Strix Halo nodes can provide 256 GB of aggregate unified memory through llama.cpp RPC, but this is a proof-of-concept path, not a production configuration.
llama.cpp 官方指出该远程调用协议稳定性欠佳且安全性不足，仅适用于概念验证。切勿将相关服务暴露在不可信网络环境中，亦不可将其作为正式生产环境端点使用。网络配置、模型兼容性、上下文容量及实际性能均需在本地环境验证。
仅当单个节点无法承载模型时才可考虑此方案。DeepSeek V4 Flash 本地硬件配置一文详细说明了为何其无损 GGUF 格式模型可适配该集群，但该部署方式仍属实验性 Strix Halo 方案。

​
请检查内存使用情况

加载模型前，请先确认 GPU 内存的可用容量：
Subtract OS overhead (~4GB) and leave 2–4GB for KV cache at your target context length. A 70GB model in Q4 leaves roughly 20GB for KV cache on a 96GB allocation — enough for 8K–16K context on most models.

​
后续操作指引

Strix Halo 的使用场景

在您的 Strix Halo 设备上设置 Tokios 连接器以实现远程访问。

在 Strix Halo 上运行 vLLM 及其他同类工具

各类运行选项，包括 llama.cpp Vulkan 与 Ollama。

量化操作指南

了解 GGUF 量化等级及其对输出质量的影响。