打破显存焦虑：Strix Halo 上的 Ollama 部署实录

刚拿到这台搭载 AMD Strix Halo 架构的笔记本时，我最期待的不是它的游戏帧数，而是终于能在移动设备上流畅运行本地大模型了。对于开发者而言，云端 API 虽然方便，但隐私顾虑和按量计费始终是个心结；而传统的本地部署又往往受限于显存带宽，跑起来卡顿如 PPT。Strix Halo 的出现，似乎正是为了解决这个痛点。

这次我不谈虚无缥缈的理论参数，只记录在 Windows 环境下，如何用最主流的 Ollama 工具链，把这台机器的 Radeon GPU 算力真正释放出来。如果你也刚入手类似设备，或者正被显存不足困扰，这份避坑指南或许能帮你少走弯路。

统一内存架构：轻薄本跑大模型的底气

Strix Halo 之所以能让端侧 AI 成为可能，核心在于其独特的统一内存架构。在传统笔记本中，CPU 内存和 GPU 显存是物理隔离的，8GB 显存可能连 7B 参数的模型都跑得勉强。但在 Strix Halo 平台上，系统内存可以直接被 GPU 高效调用。

这意味着什么？意味着只要你配备了 32GB 甚至 64GB 的大内存，就能轻松加载参数量更大的模型。大模型推理对内存带宽极其敏感，带宽越高，Token 生成速度越快。Strix Halo 集成的 Radeon 显卡拥有远超普通核显的计算单元和内存通道，这使得它在处理矩阵乘法等 AI 核心运算时，效率直逼入门级独立显卡。简单来说，它打破了“轻薄本不能跑大模型”的刻板印象。

Ollama 部署实战：从安装到环境变量调优

工欲善其事，必先利其器。在 Windows 上部署 Ollama 非常简单，下载安装包后一路默认选项即可完成。但在 Strix Halo 设备上，想要让 Ollama 正确识别并利用 Radeon GPU，有一个关键步骤容易被忽略：设置环境变量。

在新版 Ollama 中，虽然对后端的支持正在完善，但为了确保万无一失，建议手动指定 GPU 架构版本。打开 PowerShell（管理员模式），执行以下命令来设置环境变量并启动服务：

$env:HSA_OVERRIDE_GFX_VERSION = "11.0.3"
ollama serve

这一步至关重要。HSA_OVERRIDE_GFX_VERSION 强制指定了架构版本，解决了部分驱动识别问题，确保 Radeon GPU 被正确调用。如果不设置这个变量，你可能会发现 Ollama 虽然在运行，但实际计算全靠 CPU 扛着，速度惨不忍睹。

配置好环境后，部署模型就很简单了。例如拉取并运行 Qwen2.5 模型：

ollama run qwen2.5:7b

Ollama 会自动拉取模型并启动服务。值得一提的是，一旦环境变量配置正确，新版 Ollama 能够自动识别 Strix Halo 的 GPU 资源，无需再手动配置复杂的后端参数。

性能实测：CPU 与 GPU 加速的直观差异

环境搭好后，最激动人心的环节来了：性能对比。我选取了 7B 参数模型，分别在纯 CPU 模式和开启 Radeon GPU 加速模式下进行了测试，结果差异巨大。

在纯 CPU 模式下，首字延迟（Time to First Token）大约在 1.5 秒左右，生成速度仅为 8-10 tokens/s。这种速度在日常对话中会有明显的停顿感，阅读体验并不流畅。

而当开启 GPU 加速后，效果立竿见影：

• 首字延迟：从 1.5 秒降低到了 0.3 秒以内，几乎是瞬间响应。
• 生成速度：稳定在 45-50 tokens/s。

这个速度已经完全满足了日常对话、代码辅助甚至长文档总结的需求，几乎感觉不到等待。对于 14B 甚至 32B 的大参数模型，GPU 加速的意义更加重大。在 CPU 模式下，32B 模型的生成速度可能跌至 2-3 tokens/s，近乎不可用；而在 GPU 全速运转下，依然能维持在 12-15 tokens/s，具备了实用的可用性。

结语：让 AI 真正融入工作流

经过这一周的深度使用，我将本地模型融入了日常工作流：早晨用它浏览行业资讯生成摘要，写代码时让它解释复杂逻辑或生成单元测试，撰写文章时协助梳理大纲。这种无缝衔接的体验，让我意识到本地 AI 不再是玩具，而是实实在在的生产力工具。

Strix Halo 架构为端侧 AI 打开了一扇新大门。只要你合理选择模型、优化配置（特别是那个关键的环境变量），它就能成为你最得力的智能助手，让 AI 真正融入每一天的工作与创作之中，且所有数据都在本地闭环，安全无忧。