如果你最近在关注本地跑大模型这件事大概率绕不开“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 Halo1.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 39516 核 32 线程最高加速频率 5.1GHzTDP 设置在 120W 到 130W 区间GPU 是 Radeon 8060S 集成显卡40 CURDNA 3.5 架构NPU 是 XDNA 250 TOPS内存为 128GB LPDDR5X-8000256-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-7B-InstructQ4_K_M约 4.7GB约 8GBQwen2.5-14B-InstructQ4_K_M约 9.0GB约 12GBQwen2.5-32B-InstructQ4_K_M约 19.5GB约 22GBQwen2.5-72B-InstructQ4_K_M约 42.9GB约 46GBDeepSeek-R1-Distill-Qwen-32BQ4_K_M约 19.9GB约 23GB选择 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 延迟模型decode 速度prefill 速度首 token 延迟Qwen2.5-7B-Instruct Q4_K_M约 50 token/s约 800 token/s约 0.3 秒Qwen2.5-14B-Instruct Q4_K_M约 30 token/s约 420 token/s约 0.6 秒Qwen2.5-32B-Instruct Q4_K_M约 14 token/s约 230 token/s约 0.9 秒Qwen2.5-72B-Instruct Q4_K_M约 6.2 token/s约 95 token/s约 2.1 秒DeepSeek-R1-Distill-Qwen-32B Q4_K_M约 13.5 token/s约 210 token/s约 1.0 秒这套数据跟我预估的带宽模型基本吻合。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 上下文为前提平台内存带宽7B14B32B72BRyzen AI Max 395256 GB/s约 50约 30约 14约 6.2MacBook Pro M4 Pro48GB273 GB/s约 70约 38约 14显存不足跑不了MacBook Pro M4 Max128GB546 GB/s约 110约 60约 28约 13RTX 4090 台式机24GB1008 GB/s约 130约 70约 35显存无法全量加载性能骤降这份对比能看出几个问题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_ALIVE30m export OLLAMA_NUM_PARALLEL4 export OLLAMA_MAX_LOADED_MODELS1启动 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_URLhttp://localhost:8080 export ANTHROPIC_AUTH_TOKENollama 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_LIBRARYrocm并重启服务确认日志里有没有加载 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_PARALLEL4处理并发请求需要跑 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 接上本地模型之后这台机器已经成了我每天写代码和查资料的固定工作站。
AMD Ryzen AI Max+ 395 本地大模型实测：从 Ollama 到 72B 模型全量运行
如果你最近在关注本地跑大模型这件事大概率绕不开“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 Halo1.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 39516 核 32 线程最高加速频率 5.1GHzTDP 设置在 120W 到 130W 区间GPU 是 Radeon 8060S 集成显卡40 CURDNA 3.5 架构NPU 是 XDNA 250 TOPS内存为 128GB LPDDR5X-8000256-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-7B-InstructQ4_K_M约 4.7GB约 8GBQwen2.5-14B-InstructQ4_K_M约 9.0GB约 12GBQwen2.5-32B-InstructQ4_K_M约 19.5GB约 22GBQwen2.5-72B-InstructQ4_K_M约 42.9GB约 46GBDeepSeek-R1-Distill-Qwen-32BQ4_K_M约 19.9GB约 23GB选择 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 延迟模型decode 速度prefill 速度首 token 延迟Qwen2.5-7B-Instruct Q4_K_M约 50 token/s约 800 token/s约 0.3 秒Qwen2.5-14B-Instruct Q4_K_M约 30 token/s约 420 token/s约 0.6 秒Qwen2.5-32B-Instruct Q4_K_M约 14 token/s约 230 token/s约 0.9 秒Qwen2.5-72B-Instruct Q4_K_M约 6.2 token/s约 95 token/s约 2.1 秒DeepSeek-R1-Distill-Qwen-32B Q4_K_M约 13.5 token/s约 210 token/s约 1.0 秒这套数据跟我预估的带宽模型基本吻合。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 上下文为前提平台内存带宽7B14B32B72BRyzen AI Max 395256 GB/s约 50约 30约 14约 6.2MacBook Pro M4 Pro48GB273 GB/s约 70约 38约 14显存不足跑不了MacBook Pro M4 Max128GB546 GB/s约 110约 60约 28约 13RTX 4090 台式机24GB1008 GB/s约 130约 70约 35显存无法全量加载性能骤降这份对比能看出几个问题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_ALIVE30m export OLLAMA_NUM_PARALLEL4 export OLLAMA_MAX_LOADED_MODELS1启动 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_URLhttp://localhost:8080 export ANTHROPIC_AUTH_TOKENollama 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_LIBRARYrocm并重启服务确认日志里有没有加载 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_PARALLEL4处理并发请求需要跑 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 接上本地模型之后这台机器已经成了我每天写代码和查资料的固定工作站。
