企业官网建设流程全解析

如果你最近在关注本地跑大模型这件事，大概率绕不开“AMD Ryzen AI Max+ 395”这个名字。这颗来自 Strix Halo 平台的旗舰 APU，用一块芯片集成了 16 个 Zen 5 CPU 核心、40 个 RDNA 3.5 架构 GPU 计算单元，以及最大 128GB 的统一内存，被不少本地大模型玩家称为“x86 平台最接近 Mac Studio 体验的方案”。这篇内容把我这段时间用它在本地跑大模型推理的完整过程、实测数据和踩坑记录一次性整理出来，包括从 Ollama 到 llama.cpp 的软件栈选型、7B 到 72B 多个模型的推理性能测试对比，以及把本地模型接进 VS Code 和 Claude Code 工作流的具体操作，给准备入手或者正在折腾这台设备的朋友一个参考。

1. 起点：为什么我盯上了这颗 Strix Halo

1.1 先看定位：这芯片到底想干掉谁

AMD Ryzen AI Max+ 395 是 2025 年 AMD 放出来的移动端王牌，本质上是一颗代号 Strix Halo 的 APU 旗舰型号。所谓 APU，就是把 CPU 和 GPU 打包在同一块芯片上。395 这一档是满血配置：16 个 Zen 5 CPU 核心、40 个 RDNA 3.5 GPU 计算单元、32 个 RDNA 3.5 核显单元，加上 50 TOPS 的 XDNA 2 NPU。只看这些数字，好像跟桌面独显比差得很远，但它真正的杀手锏是封装了 128GB 的 LPDDR5X 统一内存，内存带宽做到了 256GB/s。这在 x86 平台上是从未有过的规格。

为什么要强调“统一内存”？普通 PC 上 CPU 有自己的内存，显卡有自己的显存，彼此独立。模型权重放在系统内存里，跑起来要先拷贝到显存，显存放不下就换到内存，来回搬运的损耗非常大。统一内存则是 CPU、GPU 共享同一片物理内存，GPU 可以直接去内存里读模型权重，中间没有拷贝这一步。这正是 Mac 能顺畅本地跑大模型的核心原因，也是 Ryzen AI Max+ 395 敢叫板 Mac 方案的底气所在。

1.2 内存带宽决定论：算力反而没那么重要

很多新手看到核显就下意识觉得“性能不行”，这个判断恰恰搞反了。大模型推理其实分两个阶段：prefill（预填充）和 decode（逐 token 生成）。decode 阶段，每生成一个新 token，都要把整个模型权重从头到尾读一遍，所以解码速度几乎只由内存带宽决定。公式很好算：理论速度（tokens/s）约等于内存带宽（GB/s）除以模型权重大小（GB）。

以 Ryzen AI Max+ 395 的 256GB/s 带宽为例，跑一个占用约 20GB 的 32B Q4 量化模型，理论极限就是 256 / 20 ≈ 12.8 token/s，再快也突破不了这个物理天花板。而算力，也就是 GPU 的 TFLOPS，主要影响的是 prefill 阶段的速度，以及处理长上下文时的计算开销。所以本地大模型跑得顺不顺，第一看内存容量够不够装下模型，第二看带宽够不够快。Ryzen AI Max+ 395 的 128GB 容量加 256GB/s 带宽，正好卡在“大容量、中高速”这个甜点区。

1.3 适用人群：谁值得为它买单

这台设备适合三类人。第一类是经常移动办公、又离不开大模型辅助的开发者，需要在笔记本上跑 32B 甚至 72B 量级的模型，同时不想背着一台厚重的游戏本到处跑。第二类是注重数据隐私的用户，代码、文档、聊天记录都不想上传到云端，本地模型是刚需。第三类是尝鲜型玩家，想体验“把以前云端才能跑的模型塞进本地”的快感，也愿意在 Linux 环境里折腾驱动和推理栈。

如果你已经有 RTX 4090 台式机，那 395 的纯速度优势并不明显，它的核心价值还是能把大显存和移动形态结合起来。这点想清楚，后面看数据才不会失望。

2. 测试平台与方案选型

2.1 测试机配置与系统环境

这次测试的机器配置如下：CPU 是 Ryzen AI Max+ 395，16 核 32 线程，最高加速频率 5.1GHz，TDP 设置在 120W 到 130W 区间；GPU 是 Radeon 8060S 集成显卡，40 CU，RDNA 3.5 架构；NPU 是 XDNA 2，50 TOPS；内存为 128GB LPDDR5X-8000，256-bit 总线，理论带宽 256GB/s。

系统方面我装的是双系统：Windows 11 24H2 用于日常办公，Ubuntu 24.04 用于大模型推理测试。为什么非要装 Linux？因为 Ollama 在 Windows 下默认走 DirectML 后端，速度打折比较明显；而在 Linux 下走 ROCm 后端，可以把 Radeon 8060S 这颗 iGPU 的大部分算力真正调度起来。想完整体验这台机器的推理能力，Ubuntu 24.04 以上版本几乎是必需品。

2.2 软件栈选型：Ollama、llama.cpp、LM Studio 怎么选

目前本地跑大模型的主流方案有三个：Ollama、llama.cpp 和 LM Studio，底层引擎其实都是 llama.cpp，区别在于使用方式。

Ollama 是开箱即用的代表，命令行里一条ollama run qwen2.5:32b就能把模型跑起来，还能通过 OpenAI 兼容 API 对接各种客户端，对日常使用来说最省心。llama.cpp 直接编译则胜在可控性最强，可以精确控制 GPU 层数、线程数、上下文长度，还能用自带的llama-bench做标准化性能测试，是评测场景下的首选。LM Studio 则是图形界面友好的方案，适合完全不想碰命令行的朋友。

我日常主力是 Ollama，但所有性能测试都用 llama.cpp 复验一遍。原因很简单，Ollama 跑出来的速度受后台并发、模型驻留、上下文长度等因素影响，数据不够“干净”；llama.cpp 的 benchmark 模式则可以固定 prompt 长度和生成长度，多次取均值，比较结果更有参考价值。

2.3 测试用模型清单与量化策略

模型选择上，我重点跑了 Qwen2.5 系列的 7B、14B、32B、72B 四个参数量档位，外加 DeepSeek-R1-Distill-Qwen-32B 和 Phi-4 14B 做补充对比。量化格式统一采用 Q4_K_M，这是目前体积和精度最均衡的量化档位，也是社区最常用的对比基准。大致的权重文件大小如下：

选择 Qwen2.5 作为主力测试模型，是因为它在中文和代码场景下的表现比较稳定，社区生态也成熟，后续接入 VS Code 和 Claude Code 时更有参考意义。

3. 实测数据：从 7B 到 72B 一条龙跑完

3.1 模型跑分原始数据

测试环境是 Ubuntu 24.04 + ROCm 6.3.2 + Ollama 0.7.x，上下文长度设为 4096，尽量排除长上下文对速度的干扰。下面这组数据是我多轮测试后取的平均值，包括了 decode 速度（每秒生成 token 数）、prefill 速度（每秒处理输入 token 数）和首 token 延迟：

这套数据跟我预估的带宽模型基本吻合。32B Q4 模型权重约 19.5GB，解码理论上限约 256 / 19.5 ≈ 13 token/s，实测 14 token/s 说明 GPU 利用率和内存控制器效率已经接近理想状态。7B 模型则明显受制于 GPU 算力，光靠带宽上限算可以到 50 多 token/s，实测也就在这个区间附近。

需要提醒的是，不同驱动版本、不同 BIOS 设置、不同后台负载下，这些数字会有 10% 到 15% 的浮动。大家参考量级即可，不必对具体数值过度较真。

3.2 与主流平台的横向对比

只看绝对值可能不够直观，我把 Ryzen AI Max+ 395 和几个常见平台的参考成绩放在一起。以下数据是综合公开测试和个人复测后的参考区间，统一以 Q4_K_M 量化、4K 上下文为前提：

这份对比能看出几个问题：M4 Max 因为带宽优势明显，整体速度比 Ryzen AI Max+ 395 高一倍左右，但价格也贵出一大截；RTX 4090 在能装进显存的小模型上依然是王者，但 32B 以上就捉襟见肘，72B 直接没法完整跑；Ryzen AI Max+ 395 的优势是 72B 级别的大模型能完整塞进内存里流畅运行，这在 x86 平台上以前是很难想象的。

3.3 数据背后的三个关键结论

第一，容量优先于速度。对本地大模型来说，能跑比跑得快重要得多。72B 模型哪怕只有 6 token/s，也能用来做文档摘要、代码审查、数据分析这类对实时性要求不高的任务；而 16GB 显存的机器连加载都加载不进去，速度再快也白搭。

第二，Ryzen AI Max+ 395 的速度定位在 M4 Pro 和 M4 Max 之间。256GB/s 的带宽决定了它的上限，比 M4 Pro 略低一点，跟 M4 Max 有明显差距，但考虑到 x86 平台的软件生态和性价比，这个妥协是合理的。

第三，推理和训练是两个完全不同的思路。训练拼的是算力和大规模并行，推理拼的是带宽、延迟和显存容量。所以这台设备的 NPU 虽然有 50 TOPS，但 Ollama 和 llama.cpp 默认都不会去调它，NPU 目前更多是给 Windows 的 AI 特效和视频处理功能服务。想靠 NPU 加速大模型推理，还需要等推理栈的进一步适配。

4. 进阶玩法：把本地模型接入日常工具链

4.1 Ollama 优化参数：把吞吐和并发吃满

Ollama 默认配置比较保守，想让它更适合日常工作流，建议调整几个环境变量。首先是OLLAMA_NUM_PARALLEL，控制同时处理的请求数，默认是 1，改成 4 之后可以让多个请求排队处理而不互相阻塞。其次是OLLAMA_KEEP_ALIVE，控制模型在内存中的驻留时间，默认是 5 分钟，改成 30m 或 24h 可以避免频繁重新加载模型。还有OLLAMA_MAX_LOADED_MODELS，限制同时加载的模型数量，建议设为 1，避免内存被多个模型瓜分。

在 Windows 和 Linux 下设置环境变量的方式不同，以 Linux 为例：

export OLLAMA_KEEP_ALIVE=30m export OLLAMA_NUM_PARALLEL=4 export OLLAMA_MAX_LOADED_MODELS=1

启动 Ollama 之后，可以用ollama ps查看当前加载的模型、显存占用和上下文长度。如果发现PROCESSOR一栏显示的是GPU，说明模型已经完全 offload 到核显上了；如果显示CPU/GPU，说明部分层还在 CPU 上跑，速度会有损失。

4.2 VS Code + Claude Code 接入本地 Ollama 模型

这是最近社区里问得很多的一个需求。Claude Code 本来是面向云端 Claude 模型的命令行工具，但它支持通过ANTHROPIC_BASE_URL环境变量切换 API 端点，于是就有了一条“用 VS Code 写代码，但底层模型换成本地 Ollama”的玩法。

实际操作上，我建议先装一个转发层，比如 claude-code-router，把 Anthropic 格式的请求转换成 Ollama 能识别的格式。直接让 Claude Code 请求 OpenAI 兼容端点是不行的，因为协议不一样。大致流程是：先配置 router 里的模型名指向 Ollama 的模型，比如qwen2.5-coder:32b，然后启动 router 服务，最后在 VS Code 终端里设置环境变量指向 router 地址：

export ANTHROPIC_BASE_URL=http://localhost:8080 export ANTHROPIC_AUTH_TOKEN=ollama claude

用本地模型跑 Claude Code 有一个很实际的体验：代码补全和简单重构的响应速度完全够用，但复杂多步骤的指令遵循能力明显不如云端大模型，偶尔会出现理解偏差。它的优势在于数据完全不出本机，离线也能干活，而且没有额度焦虑。如果你同时有云端和本地两套模型，可以配合 cc-switch 这类工具做端点快速切换，想用哪个就用哪个。

4.3 极限场景验证：128GB 内存的底在哪

把 72B 模型完整塞进显存之后，我以为这颗 APU 的潜力已经见底了，但 128GB 统一内存给了我没预料到的余量。我试着同时加载 Qwen2.5-Coder-32B 和一个 7B 的 embedding 模型，内存占用到 50GB 左右，系统依然流畅，多模型并发响应也没有明显冲突。

更进一步，还可以试试 100B 级别的超大模型。Ollama 支持通过 mmap 方式映射模型文件，部分层驻留在内存里，按需换入换出。实测加载 100B 以上模型时，decode 速度会掉到 2 token/s 以下，但生成短文本、做文档分类这类任务依然能完成。这个场景比较极限，日常使用意义不大，但至少说明这台机器的天花板比想象中高。

对于想长期使用 Ollama 的朋友，我的建议是把内存预算分为三块：第一块给系统，20GB 左右就足够；第二块给开发工具链，VS Code、浏览器、数据库这些大概 10GB 到 20GB；剩下的 80GB 到 90GB 都留给大模型。这样日常用 32B 模型时毫无压力，遇到 72B 任务也能直接切换。

5. 实操中遇到的那些坑

5.1 Windows 下识别不到核显，怎么处理

这个问题出现的频率最高。Ollama 在 Windows 下默认走 DirectML 后端，虽然能识别到 Radeon 8060S，但速度比 Linux 下的 ROCm 后端差了不少，而且早期版本经常出现模型全部加载在 CPU 上、GPU 完全不动的情况。

排查思路很简单。第一步，打开设备管理器，确认显示适配器里能看到 Radeon 8060S；第二步，检查驱动版本，建议去 AMD 官网下载 Adrenalin 驱动的最新版本，Windows Update 推送的驱动不一定带 ROCm 支持；第三步，在 Ollama 里设置OLLAMA_LLM_LIBRARY=rocm并重启服务，确认日志里有没有加载 ROCm 相关库。

如果还是识别不到，最省事的方案就是直接切换到 Ubuntu 24.04。我自己的测试表明，Linux 下 Ollama 可以稳定识别核显并全量 offload 模型，Windows 下的折腾性价比远低于装个双系统。

5.2 上下文拉长后速度骤降，正常吗

非常正常。大模型推理时，上下文越长，KV cache 占用的内存越多，attention 计算的开销也越大，decode 速度会随之下降。我在 4K 上下文下测出的 14 token/s，如果拉到 32K 上下文，通常在 11 到 12 token/s 左右，下降幅度大约 10% 到 20%，这属于正常范围。

如果发现速度下降超过 30%，优先检查模型是否因为内存不足被部分换回 CPU。用ollama ps看一眼PROCESSOR一栏，如果从GPU变成CPU/GPU，说明 KV cache 超出了显存分配，模型层开始回退到 CPU，这时要么缩短上下文，要么换成更小的量化档位。

还有一种情况是速度没有下降，但创建新会话时等待时间很长。这是因为OLLAMA_KEEP_ALIVE设置得太短，模型反复被卸载重载。把驻留时间调长到 30 分钟以上，这个问题基本就消失了。

5.3 多任务并行时，内存和并发怎么分配

128GB 看起来很多，但并不是全部都能给 Ollama。系统、浏览器、VS Code、数据库、容器服务都会吃内存，一旦模型加载过多，系统会开始使用 swap，速度直接崩塌。我的经验是：日常常驻一个 32B 模型，预留 40GB 左右内存，再配合OLLAMA_NUM_PARALLEL=4处理并发请求；需要跑 72B 模型时，先卸载 32B，给大模型腾出 60GB 到 70GB 空间，而不是让多个大模型同时驻留。

在 Linux 下，我用free -h和rocm-smi实时监控内存和 GPU 利用率；Windows 下则用任务管理器观察“共享 GPU 内存”一栏。如果发现内存占用接近物理上限，优先停掉不常用的容器和后台服务，别指望操作系统自动帮你优化好一切。

另外还有一个容易被忽略的坑：BIOS 里的 UMA Frame Buffer 设置。如果设得太小，Windows 下 GPU 可用内存会受限，Ollama 可能连 32B 模型都加载不了。建议设为 Auto 或者尽量大的档位，Linux 下影响不大，但对 Windows 用户来说这个设置直接决定模型的加载上限。

整套体验下来，我最深的感受是：Ryzen AI Max+ 395 最大的价值不是和 RTX 4090 比谁快，而是让“128GB 统一内存 + 完整本地大模型”这个以前基本属于 Mac 独占的体验，在 x86 平台上真正落了地。它跑 7B 模型的速度也许谈不上惊艳，但 72B 模型能全量加载、稳定输出，这个能力本身就改变了本地工作的可能性边界。至于 NPU 的 50 TOPS，当下在 Ollama 这类工具里更多是锦上添花，未来如果推理栈能真正把 NPU 用起来，这颗芯片的潜力还有得挖。装好双系统、设好模型常驻、把 VS Code 接上本地模型之后，这台机器已经成了我每天写代码和查资料的固定工作站。