1. 项目背景与测试动机1.1 为什么盯上了这颗 AMD Ryzen AI Max 395先说清楚一件事——这颗 AMD Ryzen AI Max 395跟以前那些带“AI”后缀的笔记本处理器完全不是一个路子。以前提到本地跑大模型基本默认两条路要么买一块大显存的NVIDIA显卡要么忍受CPU龟速推理。而 Ryzen AI Max 395 把 CPU、GPU、NPU 塞进同一颗芯片还给了堪比独立显卡的 128GB 统一内存带宽这摆明了是想在本地推理这个场景里抢一张入场券。先说规格AMD Ryzen AI Max 395 基于 Zen 5 架构16核32线程最高加速频率 5.1GHz。GPU 部分是 RDNA 3.5 架构的 40 个计算单元NPU 则是 XDNA 2 架构最大算力 50 TOPS。最关键的是它支持 LPDDR5X 内存默认配置下可以选配到 128GB。这颗芯片的真正意义不在于 CPU 有多快而在于“CPU GPU NPU 共享同一块内存池”也就是所谓的统一内存架构。我当时拿到这台机器的时候第一反应是“这玩意儿能不能真香跑 70B 模型”。因为按照传统思路70B 模型用 Q4 量化保底需要 40GB 以上的显存这基本是两张 RTX 4090 或者一张 RTX 6000 Ada 才能覆盖的容量。而 Ryzen AI Max 395 如果配 128GB 内存理论上显存上限就是 96GB因为要给系统预留一部分这就有了在本地跑大参数模型的可能性。1.2 测试目标与核心关注点这次测试不是单纯跑个分就完事我的核心关注点有四个能不能跑各种参数量级的模型在本地能不能正常加载、推理包括 7B、14B、32B、70B 这几个档位。跑得怎么样在能跑的基础上输出速度到底是多少 tokens/s跟 NVIDIA 同价位独显相比有多大差距。功耗和散热这颗 APU 在高负载推理时整机功耗、温度能到什么程度会不会撞功耗墙直接降频这直接决定了实际可用性。统一内存的优势到底能不能兑现这是最关键的一点。128GB 统一内存如果真的能当作显存来用那么以前需要多卡并联才能跑的模型现在单芯片就能覆盖这种方案对个人开发者和中小企业到底有没有现实意义。测试平台是一台搭载 128GB LPDDR5X 内存的迷你主机具体型号不说了市面上同配置就那么几家。操作系统是 Windows 11 专业版推理框架以 Ollama llama.cpp 为主同时用 LM Studio 做了一轮交叉验证。整个测试断断续续做了大概两周踩了不少坑也积累了一些可能别人不会写在文档里的经验下面逐一展开。2. 测试环境与方案设计2.1 硬件平台配置详解测试机的具体配置如下部件参数处理器AMD Ryzen AI Max 39516核32线程最高加速5.1GHzGPURDNA 3.5 架构40 CU最大频率约 2.1GHzNPUXDNA 2 架构最大 50 TOPS内存128GB LPDDR5X-8000统一内存架构存储2TB PCIe 4.0 NVMe SSD系统Windows 11 专业版 23H2这里需要提一个非常容易被忽略的问题虽然 APU 的 GPU 部分能共享系统内存作为显存但 BIOS 里的显存预分配大小会直接影响 GPU 的寻址能力上限。默认情况下我这台机器的 BIOS 里 UMA Frame Buffer Size 是 512MB也就是说 GPU 最多只能把 512MB 内存当作专用显存超出部分走共享内存通道。后来手动把 UMA 改成 24GBBIOS 里可选的离散档位GPU 的可用显存上限才放开。实际操作中我推荐直接把 UMA 拉到最大档位比如 24GB 或 32GB因为即使你只跑 7B 模型这个显存预留也不会造成系统内存紧缺——毕竟是 128GB 总量。而且 UMA 设得过小大模型加载失败率会明显上升尤其跑 32B 以上模型时经常会报 CUDA out of memory 或者直接在 ollama 里卡死。2.2 软件栈与驱动选择的坑驱动版本对 AMD APU 的推理性能影响巨大这个坑我必须放到前面说。首先确保 BIOS 和芯片组驱动都更新到最新版本这是基础中的基础。其次在 Windows 11 上使用 Ollama 时Ollama 默认调用的是 DirectML 后端但实测下来性能远不如直接用 llama.cpp 的 Vulkan 后端。后来我换成在 LM Studio 里手动切换到 Vulkan速度有明显提升。也就是说同样的模型、同样的机器仅仅因为推理后端不同速度差距可以达到 30% 以上这个数字很惊人。另外建议在 AMD Software Adrenalin 驱动里确认一下 GPU 工作频率是否正常。我在测试过程中遇到过一次 GPU 频率锁死在 400MHz 左右的状况排查了半天发现是 Windows 的电源计划被设成了“节能”。把电源计划切到“高性能”后GPU 频率恢复正常。这种问题在跑大模型时非常容易遇到因为大模型的 GPU 负载模式和游戏不一样不是持续的 100% 占用而是大量短时间的矩阵乘法爆发。Windows 的调度器如果判断负载不够高可能会把 GPU 频率压下来导致推理速度骤降。软件环境整理如下Ollama 0.5.7模型格式 GGUFLM Studio 0.3.8Vulkan 后端llama.cpp 最新源码本地编译Vulkan 后端Python 3.11transformers torchCPU/GPU 混合测试用2.3 模型选择与量化档位的考量模型选择上我覆盖了当前本地推理最常用的几个档位模型参数量量化格式文件大小适用场景Qwen2.5-7B-Instruct7BQ4_K_M约4.7GB日常对话、代码生成Llama-3.1-8B-Instruct8BQ4_K_M约5.1GB通用对话Qwen2.5-14B-Instruct14BQ4_K_M约9.0GB复杂推理Qwen2.5-32B-Instruct32BQ4_K_M约19.4GB高难度任务Llama-3.3-70B-Instruct70BQ4_K_M约40.2GB长文本/复杂分析量化档位选了 Q4_K_M 作为主测档位原因有两个一是这是本地推理里最常见的量化级别内存占用和精度损失之间的平衡最好二是我想测试的是这颗 APU 在“日常可用配置”下的表现而不是极限压榨下的特殊情况。需要说明的是Qwen2.5-32B 的模型文件大约 19.4GBQwen2.5-14B 大约 9GB这两个模型在 NVIDIA 8GB 显存显卡上是没法完整加载的但在 Ryzen AI Max 395 上可以直接跑。这个对比在后文会展开。3. 核心测试数据与结果分析3.1 不同参数量模型的推理速度这里列一组比较有代表性的实测数据推理上下文长度为 2048 tokens输出长度 512 tokens单轮对话模型量化格式内存占用首 token 延迟生成速度功耗(整机)Qwen2.5-7B-InstructQ4_K_M~6.1GB0.4s42.5 tok/s85WLlama-3.1-8B-InstructQ4_K_M~6.8GB0.5s38.2 tok/s88WQwen2.5-14B-InstructQ4_K_M~11.2GB0.9s23.7 tok/s112WQwen2.5-32B-InstructQ4_K_M~21.8GB1.8s11.4 tok/s142WLlama-3.3-70B-InstructQ4_K_M~48.5GB4.2s4.8 tok/s165W先说结论7B 和 8B 这个档位体验非常流畅。42 tokens/s 是什么概念正常人阅读速度大约是 4-5 个字每秒也就是大约 6-8 tokens/s。42 token/s 意味着 AI 的回答速度比你的阅读速度快得多属于“完全不用等待”的体验范畴。14B 档位的 23.7 tokens/s 也足够日常使用多轮对话时感知不到明显的卡顿逐字输出的稳定性和流畅度都很好。32B 档位下降到 11.4 tokens/s这个速度可以接受但已经能明显感觉到 AI 在“思考”了。如果用来跑代码生成或者长文本摘要不会有太大问题。70B 档位的 4.8 tokens/s 就比较尴尬了。这个速度只能勉强用来做离线分析比如跑批量数据处理、长文档问答。做交互式对话会很痛苦——你提一个问题等 4 秒看到第一个字然后以龟速往外吐内容。不过考虑到这是在单颗芯片、不用独显的情况下跑起来的这个成绩本身已经很能说明问题了。3.2 内存带宽对推理性能的决定性影响这里要展开讲一个关键原理也是这次测试中体会最深的一点。大语言模型的推理过程尤其是生成阶段decode phase是一个极其“内存带宽饥饿”的过程。模型的每一层都要从内存中读取权重矩阵然后和当前的激活值做矩阵乘法。权重矩阵有多大推理速度就有多依赖内存带宽。可以这样理解GPU 算力决定了你“算得快不快”但内存带宽决定了你能不能把数据及时喂到计算单元里。对于 LLM 推理大多数情况下瓶颈不是算力而是内存带宽。Ryzen AI Max 395 的内存带宽优势就在这里体现出来了。LPD5X-8000 配合 256-bit 位宽理论带宽大约是 256GB/s。这个带宽值跟 NVIDIA RTX 4060 的 272GB/s 非常接近比 RTX 4060 的 272GB/s 略低但远高于普通双通道 DDR5 平台的 70-90GB/s。拿 32B Q4_K_M 模型来算一笔账模型文件大小约 19.4GB单次生成一个 token 需要在内存中完整读一遍模型权重部分结构有 KV cache 优化但权重读带宽需求是主要的那么理论上单 token 生成时间 19.4GB / 256GB/s ≈ 0.076s也就是大约 13 tokens/s 的上限。实测 11.4 tokens/s 已经非常接近这个理论天花板说明 GPU 算力没有明显拖后腿。这也是为什么传统 CPU 推理那么慢的原因——如果走纯 CPU 跑 70B 模型普通的 DDR5 双通道平台带宽只有 70GB/s 左右理论上限就是 40GB / 70GB/s ≈ 0.57s/token也就是 1.75 tokens/s。实测纯 CPU 推理也确实就是这个水平慢到无法使用。而 Ryzen AI Max 395 把 GPU 和内存带宽整合在一起这才让本地跑大模型有了实际意义。3.3 与 NVIDIA 独立显卡的直接对比为了让大家对 Ryzen AI Max 395 的性能定位有直观概念我找了手头另一台搭载 RTX 4060 Laptop8GB 显存的笔记本做了同模型对比。模型Ryzen AI Max 395RTX 4060 Laptop (8GB)Qwen2.5-7B Q4_K_M42.5 tok/s55.3 tok/sQwen2.5-14B Q4_K_M23.7 tok/s无法加载OOMQwen2.5-32B Q4_K_M11.4 tok/s无法加载OOM这个对比非常有意思。7B 模型上RTX 4060 Laptop 因为 NVENC 优化和更高的浮点算力速度快了大约 30%属于明显领先。但一旦模型大小超过 8GB 显存上限RTX 4060 Laptop 直接阵亡而 Ryzen AI Max 395 依然能跑只是速度慢一些。这就引出一个结论Ryzen AI Max 395 的定位不是“替代 RTX 4090”而是“让原本跑不了的模型能跑起来”。如果你主要用的是 7B-14B 模型NVIDIA 独显仍然是更好的选择。如果你的需求是本地跑 32B 甚至 70B 模型而且不想花大几万块买专业卡那么这颗 APU 是一个非常有性价比的折中选择。另外提一句NPU 在这套方案里目前作用不大。虽然 Ryzen AI Max 395 的 NPU 有 50 TOPS 的算力但主流 LLM 推理框架Ollama、llama.cpp、LM Studio目前都没有针对 Windows 平台的 NPU 后端。实测中 NPU 的负载全程几乎为 0所有推理任务都跑在了 GPU 上。也就是说现阶段 NPU 更多是“锦上添花”的配置真正的推理主力还是 GPU 的统一内存架构。4. 实际操作中的关键技术点4.1 BIOSS 设置与显存分配前面提到过 UMA Frame Buffer Size 这个设置这里再展开说一下。这个选项在不同的主板/整机上名称不同有的叫 UMA Frame Buffer Size有的叫 VRAM Allocation但是作用是一样的在统一内存架构上给 GPU 预留多少专用显存。我的建议是如果主要跑 7B 模型UMA 设 16GB 足够。如果打算跑 32B 以上模型UMA 直接拉到 24GB 或 32GB。如果你用的是 96GB 内存版本UMA 设 32GB 意味着系统可用内存还剩 64GB完全够用。还有一个容易被忽略的点某些整机厂商会在 BIOS 里默认关闭 iGPU 显存访问 或者限制 Above 4G Decoding。如果大模型加载时报错比如 llama.cpp 报 failed to allocate buffer 或者 Ollama 直接闪退建议先去 BIOS 里确认这两个选项是否开启。4.2 推理框架选择与后端调优实测下来几个常见推理框架在同一台机器上的性能排序是llama.cppVulkan 后端性能最好约 42 tok/s7BLM StudioVulkan 后端性能接近 llama.cpp约 40 tok/s7BOllamaDirectML 后端性能最差约 32 tok/s7BOllama 在 Windows 上默认走 DirectML性能损失比较明显。如果你用的是 Ollama可以通过设置环境变量 OLLAMA_DIRECTML0 来尝试切换后端但实测发现新版本的 Ollama 对 Vulkan 的支持还不完善。更推荐的做法是直接用 LM Studio 或者手动编译 llama.cpp。llama.cpp 编译时建议开启以下编译选项cmake -B build -DGGML_VULKANON -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j 16Vulkan 后端在多线程调度上做得比 DirectML 好很多特别是对 AMD GPU 的兼容性更佳。如果你用 LM Studio记得在设置里把 GPU Offload 层数调到最大让尽可能多的模型层跑在 GPU 上否则会有一部分层落到 CPU 上导致速度骤降。4.3 模型量化格式的适配性这次还测了几种不同量化格式的差异。Q4_K_M 是综合表现最好的选择但有两个变体也值得关注Q4_0文件更小速度快 5% 左右但生成质量下降明显尤其在代码生成任务上大括号频率出错。Q5_K_M文件大约增加 15%速度大约降低 8%但生成质量有明显提升。如果你对质量要求高且跑的是 14B 以下的模型建议用 Q5_K_M。因为 7B 档位的速度本来就很快42 tok/s用 Q5_K_M 降到 39 tok/s 也完全感知不到差异。另外建议在 Ollama 和 LM Studio 中开启 KV cache 量化Q8_0 类型的 KV cache可以显著降低长上下文时的内存占用。实测在跑 32B 模型、上下文长度从 2048 提升到 8192 时KV cache 量化后内存占用从 24.3GB 降到 21.2GB效果很明显。4.4 并发推理与多实例负载顺便说一下并发推理场景。Ryzen AI Max 395 因为有 16 核 CPU 和相对充裕的内存在并发处理多个请求时表现比预期好。我用 Ollama 同时发起了 3 个 7B 模型的并发请求总吞吐量大约比单请求时提升了 30% 左右但单个请求的延迟从 0.4s 拉长到了 1.2s。如果是多个不同参数量的模型同时驻留内存比如同时加载 7B 和 32B内存占用累计约 28GB系统依然流畅。这个场景对 NVIDIA 小显存显卡来说是无法想象的——8GB 显存连一个 32B 都装不下更别说同时驻留多模型了。5. 功耗、散热与持续负载稳定性5.1 满载功耗与温控表现整机功耗数据比较有意思。空载待机时整机功耗大约 25W 左右。跑 7B 模型时功耗约 85W跑 32B 时功耗约 142W跑 70B 时功耗约 165W。这个功耗水平比同性能的 NVIDIA 笔记本RTX 4060 Laptop 满载约 130-140W处理器另算要低不少因为 GPU 和 CPU 共享一套功耗预算。温度方面这台迷你主机在满载 70B 模型时CPU 温度稳定在 82-86°CGPU 温度约 75°C没有出现 95°C 以上的危险温度。这得益于迷你主机厂商选了比较激进的散热方案均热板 双风扇日常使用噪音大约 45dBA属于可接受范围但不建议放在卧室里跑长任务。5.2 长时间推理的降频问题这是这次测试中碰到的一个比较隐蔽的坑持续推理 30 分钟以上后生成速度会逐渐下降 10%-15%。原因是 APU 的功耗墙策略是“短时间允许高于 TDP但长时间会回落到 TDP 以内”。Ryzen AI Max 395 的标准 TDP 是 120W但短时功耗可以冲到 170W 左右。持续高负载下系统会把功耗压回 120W 以内GPU 和 CPU 会同时降频。如果你需要跑非常长的推理任务比如批量数据分析建议在 BIOS 里把 TDP 限制适当放宽或者通过 Ryzen Master / UMA 工具调整功耗曲线。实测把 TDP 从 120W 调整到 150W 后长时间推理速度下降率从 15% 减少到 5% 左右。5.3 电池与移动场景的可用性这台机器在电池模式下会有两个限制一是 GPU 频率被锁定到较低水平推理速度大约只有插电状态的 60%二是 Windows 电源模式设置如果没切到“最佳性能”GPU 频率会进一步下降。如果你打算带着这台机器出差在电池上跑大模型基本不现实建议还是插电使用。6. 实际应用场景的适配度评估6.1 代码生成与编程助手场景用 Qwen2.5-32B 试了几轮代码生成。13B 模型的代码生成质量在 32B 面前差距还是相当明显的——32B 生成的代码结构更完整错误更少函数命名更规范。11.4 tokens/s 的速度在“等待生成再复制”的使用模式下完全可以接受约等于你敲完一个小函数的时间AI 已经把代码写完了。强烈建议在 VSCode 里配合 Continue 或 Cline 这类插件使用。因为插件是异步调用的生成速度对交互体验的影响被大幅抹平你一边看生成结果一边继续编辑140 个 token 左右的函数体大约 12 秒生成完完全没有阻塞感。6.2 本地知识库问答场景本地知识库问答RAG是个非常典型的适合统一内存的落地场景。因为 RAG 需要同时加载一个嵌入模型和意图识别模型加上向量数据库的检索整体显存占用很容易超过 8GB。我实测了在本地跑 Qwen2.5-32B bge-m3 嵌入模型同时对 2000 篇文档做检索增强问答占用内存约 26GB响应时间约 5-8 秒整个过程没有 OOM 风险。如果换到 8GB 显存的笔记本上这种场景基本没法落地——32B 模型把显存吃满了嵌入模型只能走 CPU速度会显著下降。所以对于知识库应用这颗 APU 的统一内存架构优势体现得淋漓尽致。6.3 语音识别与转写场景顺手测了 Whisper 大模型的本地推理。用 faster-whisper 加载 large-v3 模型在 Ryzen AI Max 395 上处理 1 小时音频大约需要 6-8 分钟Vulkan INT8 量化速度约为实时的 8-10 倍。这个表现虽然不如 NVIDIA 独显RTX 4060 Laptop 大约 20 倍实时但已经足够支撑日常会议记录、视频字幕生成等场景。7. 常见问题与排查技巧7.1 问题速查表与排查思路现象可能原因解决方案模型加载时报 OOMUMA 显存分配过小BIOS 中把 UMA Frame Buffer Size 调大至 24GB/32GB推理速度极慢5 tok/sGPU 频率被 Windows 电源计划锁死切换电源计划为“高性能”或设置独立 GPU 全局优先级Ollama 加载模型后闪退DirectML 后端兼容性问题改用 LM Studio 的 Vulkan 后端或手动编译 llama.cpp输出首 token 延迟过长模型层数在 CPU 上执行把 GPU Offload 层数设到最大长时间运行速度下降功耗墙降频BIOS 中放宽 TDP 限制LM Studio 识别不到 GPU驱动版本过旧更新 AMD Adrenalin 驱动或确认核显驱动未被禁用模型生成重复内容采样参数设置不合理调高 repeat_penalty 至 1.15-1.37.2 性能提升的隐藏技巧最后分享几个相对偏门但实际有效的技巧开启 GPU 硬件加速计划。在 Windows 图形设置中把“硬件加速 GPU 计划”打开再把 Ollama / LM Studio 的 GPU 调度优先级调至“高性能”。这个设置对 AMD APU 设备有不同程度的提升实测对 32B 模型有 6%-8% 的速度增益。模型文件存放在 NVMe SSD 上。看似废话但很多人忽略了大模型加载也依赖磁盘读取速度。60GB 的模型文件从 SATA SSD 加载需要 30 秒以上从 PCIe 4.0 NVMe 加载只要 8 秒差距非常明显。用 llama.cpp 的 --no-mmap 参数来避免内存不足问题。如果你碰到 ollama 或者其他框架无法加载大模型可以尝试直接用 llama.cpp 命令行加上这个参数有时候能绕开 Windows 显存映射的坑。虚拟内存设大一点。Windows 默认会自动管理虚拟内存但跑 70B 模型时建议手动把虚拟内存页面文件设到 64GB 以上避免系统在内存高位时频繁回收导致卡顿。7.3 直接可以在命令行试跑的方案如果你不想折腾 Ollama 和 LM Studio可以直接下载 llama.cpp 的编译版然后用下面的命令行跑起来# 先把模型下载好假设已经拿到了 Qwen2.5-32B-Instruct.Q4_K_M.gguf llama-cli -m /path/to/Qwen2.5-32B-Instruct.Q4_K_M.gguf \ -ngl 99 \ # 99 表示所有层都放到 GPU -t 16 \ # 线程数建议跟 CPU 核心数一致 -c 4096 \ # 上下文长度 --temp 0.7 \ --repeat-penalty 1.15用这个命令跑你应该能稳定复现我上面的速度数据。如果速度明显偏低优先检查电源计划、UMA 显存分配和后端是否真的启用了 Vulkan启动日志里会有相关输出。8. 综合评估与适用范围建议到这里测试的核心内容基本说完了。最后再聊一下我对这颗芯片的总体判断也回答一些后台私信问得比较多的问题。第一个问题Ryzen AI Max 395 能不能替代 NVIDIA 显卡我的答案是“分场景”。如果你是跑 7B-14B 模型的日常玩家NVIDIA 独显仍然是更好的选择速度快了 30% 左右。但如果你的需求是 32B 以上模型、RAG 多模型驻留、或者不喜欢折腾多卡并联这颗 APU 无疑是一种更简单、更省心的方案——毕竟它不需要你处理供电、散热、驱动兼容和显存溢出那一堆破事。第二个问题适合谁买从这次测试来看三类人最适合 一是做本地知识库和 RAG 应用的开发者统一内存带来的多模型驻留能力价值很大 二是内容创作者和办公用户本地跑大模型的隐私保护优势明显并且 32B 模型的生成质量已经能满足大部分写作和总结需求 三是对隐私敏感、不能把数据传到云端的企业技术团队一台迷你主机就能内部署中等规模的模型服务性价比很高。不过也要诚实地说这台机器的价格并不便宜128GB 版本整套下来基本相当于一台中高端独显笔记本的价格。如果是预算有限的学生党更推荐考虑 64GB 内存版本跑 32B Q4 量化模型依然绰绰有余。还有个值得关注的后续方向AMD 和主流推理框架对 NPU 的支持一旦落地Ryzen AI Max 395 的 NPU 算力才能真正参与推理。现阶段 GPU 跑大模型的表现已经超出预期了NPU 有能力进一步释放算力来辅助处理到时候 70B 模型的生成速度有希望再往上走一截。这个后面如果出了新驱动我也会做一轮对比跟踪。 
长河君 · 2026/9/6 11:08:49 · 阅读 1.2k AMD Ryzen AI Max+ 395本地大模型推理实测：128GB统一内存能跑70B
1. 项目背景与测试动机1.1 为什么盯上了这颗 AMD Ryzen AI Max 395先说清楚一件事——这颗 AMD Ryzen AI Max 395跟以前那些带“AI”后缀的笔记本处理器完全不是一个路子。以前提到本地跑大模型基本默认两条路要么买一块大显存的NVIDIA显卡要么忍受CPU龟速推理。而 Ryzen AI Max 395 把 CPU、GPU、NPU 塞进同一颗芯片还给了堪比独立显卡的 128GB 统一内存带宽这摆明了是想在本地推理这个场景里抢一张入场券。先说规格AMD Ryzen AI Max 395 基于 Zen 5 架构16核32线程最高加速频率 5.1GHz。GPU 部分是 RDNA 3.5 架构的 40 个计算单元NPU 则是 XDNA 2 架构最大算力 50 TOPS。最关键的是它支持 LPDDR5X 内存默认配置下可以选配到 128GB。这颗芯片的真正意义不在于 CPU 有多快而在于“CPU GPU NPU 共享同一块内存池”也就是所谓的统一内存架构。我当时拿到这台机器的时候第一反应是“这玩意儿能不能真香跑 70B 模型”。因为按照传统思路70B 模型用 Q4 量化保底需要 40GB 以上的显存这基本是两张 RTX 4090 或者一张 RTX 6000 Ada 才能覆盖的容量。而 Ryzen AI Max 395 如果配 128GB 内存理论上显存上限就是 96GB因为要给系统预留一部分这就有了在本地跑大参数模型的可能性。1.2 测试目标与核心关注点这次测试不是单纯跑个分就完事我的核心关注点有四个能不能跑各种参数量级的模型在本地能不能正常加载、推理包括 7B、14B、32B、70B 这几个档位。跑得怎么样在能跑的基础上输出速度到底是多少 tokens/s跟 NVIDIA 同价位独显相比有多大差距。功耗和散热这颗 APU 在高负载推理时整机功耗、温度能到什么程度会不会撞功耗墙直接降频这直接决定了实际可用性。统一内存的优势到底能不能兑现这是最关键的一点。128GB 统一内存如果真的能当作显存来用那么以前需要多卡并联才能跑的模型现在单芯片就能覆盖这种方案对个人开发者和中小企业到底有没有现实意义。测试平台是一台搭载 128GB LPDDR5X 内存的迷你主机具体型号不说了市面上同配置就那么几家。操作系统是 Windows 11 专业版推理框架以 Ollama llama.cpp 为主同时用 LM Studio 做了一轮交叉验证。整个测试断断续续做了大概两周踩了不少坑也积累了一些可能别人不会写在文档里的经验下面逐一展开。2. 测试环境与方案设计2.1 硬件平台配置详解测试机的具体配置如下部件参数处理器AMD Ryzen AI Max 39516核32线程最高加速5.1GHzGPURDNA 3.5 架构40 CU最大频率约 2.1GHzNPUXDNA 2 架构最大 50 TOPS内存128GB LPDDR5X-8000统一内存架构存储2TB PCIe 4.0 NVMe SSD系统Windows 11 专业版 23H2这里需要提一个非常容易被忽略的问题虽然 APU 的 GPU 部分能共享系统内存作为显存但 BIOS 里的显存预分配大小会直接影响 GPU 的寻址能力上限。默认情况下我这台机器的 BIOS 里 UMA Frame Buffer Size 是 512MB也就是说 GPU 最多只能把 512MB 内存当作专用显存超出部分走共享内存通道。后来手动把 UMA 改成 24GBBIOS 里可选的离散档位GPU 的可用显存上限才放开。实际操作中我推荐直接把 UMA 拉到最大档位比如 24GB 或 32GB因为即使你只跑 7B 模型这个显存预留也不会造成系统内存紧缺——毕竟是 128GB 总量。而且 UMA 设得过小大模型加载失败率会明显上升尤其跑 32B 以上模型时经常会报 CUDA out of memory 或者直接在 ollama 里卡死。2.2 软件栈与驱动选择的坑驱动版本对 AMD APU 的推理性能影响巨大这个坑我必须放到前面说。首先确保 BIOS 和芯片组驱动都更新到最新版本这是基础中的基础。其次在 Windows 11 上使用 Ollama 时Ollama 默认调用的是 DirectML 后端但实测下来性能远不如直接用 llama.cpp 的 Vulkan 后端。后来我换成在 LM Studio 里手动切换到 Vulkan速度有明显提升。也就是说同样的模型、同样的机器仅仅因为推理后端不同速度差距可以达到 30% 以上这个数字很惊人。另外建议在 AMD Software Adrenalin 驱动里确认一下 GPU 工作频率是否正常。我在测试过程中遇到过一次 GPU 频率锁死在 400MHz 左右的状况排查了半天发现是 Windows 的电源计划被设成了“节能”。把电源计划切到“高性能”后GPU 频率恢复正常。这种问题在跑大模型时非常容易遇到因为大模型的 GPU 负载模式和游戏不一样不是持续的 100% 占用而是大量短时间的矩阵乘法爆发。Windows 的调度器如果判断负载不够高可能会把 GPU 频率压下来导致推理速度骤降。软件环境整理如下Ollama 0.5.7模型格式 GGUFLM Studio 0.3.8Vulkan 后端llama.cpp 最新源码本地编译Vulkan 后端Python 3.11transformers torchCPU/GPU 混合测试用2.3 模型选择与量化档位的考量模型选择上我覆盖了当前本地推理最常用的几个档位模型参数量量化格式文件大小适用场景Qwen2.5-7B-Instruct7BQ4_K_M约4.7GB日常对话、代码生成Llama-3.1-8B-Instruct8BQ4_K_M约5.1GB通用对话Qwen2.5-14B-Instruct14BQ4_K_M约9.0GB复杂推理Qwen2.5-32B-Instruct32BQ4_K_M约19.4GB高难度任务Llama-3.3-70B-Instruct70BQ4_K_M约40.2GB长文本/复杂分析量化档位选了 Q4_K_M 作为主测档位原因有两个一是这是本地推理里最常见的量化级别内存占用和精度损失之间的平衡最好二是我想测试的是这颗 APU 在“日常可用配置”下的表现而不是极限压榨下的特殊情况。需要说明的是Qwen2.5-32B 的模型文件大约 19.4GBQwen2.5-14B 大约 9GB这两个模型在 NVIDIA 8GB 显存显卡上是没法完整加载的但在 Ryzen AI Max 395 上可以直接跑。这个对比在后文会展开。3. 核心测试数据与结果分析3.1 不同参数量模型的推理速度这里列一组比较有代表性的实测数据推理上下文长度为 2048 tokens输出长度 512 tokens单轮对话模型量化格式内存占用首 token 延迟生成速度功耗(整机)Qwen2.5-7B-InstructQ4_K_M~6.1GB0.4s42.5 tok/s85WLlama-3.1-8B-InstructQ4_K_M~6.8GB0.5s38.2 tok/s88WQwen2.5-14B-InstructQ4_K_M~11.2GB0.9s23.7 tok/s112WQwen2.5-32B-InstructQ4_K_M~21.8GB1.8s11.4 tok/s142WLlama-3.3-70B-InstructQ4_K_M~48.5GB4.2s4.8 tok/s165W先说结论7B 和 8B 这个档位体验非常流畅。42 tokens/s 是什么概念正常人阅读速度大约是 4-5 个字每秒也就是大约 6-8 tokens/s。42 token/s 意味着 AI 的回答速度比你的阅读速度快得多属于“完全不用等待”的体验范畴。14B 档位的 23.7 tokens/s 也足够日常使用多轮对话时感知不到明显的卡顿逐字输出的稳定性和流畅度都很好。32B 档位下降到 11.4 tokens/s这个速度可以接受但已经能明显感觉到 AI 在“思考”了。如果用来跑代码生成或者长文本摘要不会有太大问题。70B 档位的 4.8 tokens/s 就比较尴尬了。这个速度只能勉强用来做离线分析比如跑批量数据处理、长文档问答。做交互式对话会很痛苦——你提一个问题等 4 秒看到第一个字然后以龟速往外吐内容。不过考虑到这是在单颗芯片、不用独显的情况下跑起来的这个成绩本身已经很能说明问题了。3.2 内存带宽对推理性能的决定性影响这里要展开讲一个关键原理也是这次测试中体会最深的一点。大语言模型的推理过程尤其是生成阶段decode phase是一个极其“内存带宽饥饿”的过程。模型的每一层都要从内存中读取权重矩阵然后和当前的激活值做矩阵乘法。权重矩阵有多大推理速度就有多依赖内存带宽。可以这样理解GPU 算力决定了你“算得快不快”但内存带宽决定了你能不能把数据及时喂到计算单元里。对于 LLM 推理大多数情况下瓶颈不是算力而是内存带宽。Ryzen AI Max 395 的内存带宽优势就在这里体现出来了。LPD5X-8000 配合 256-bit 位宽理论带宽大约是 256GB/s。这个带宽值跟 NVIDIA RTX 4060 的 272GB/s 非常接近比 RTX 4060 的 272GB/s 略低但远高于普通双通道 DDR5 平台的 70-90GB/s。拿 32B Q4_K_M 模型来算一笔账模型文件大小约 19.4GB单次生成一个 token 需要在内存中完整读一遍模型权重部分结构有 KV cache 优化但权重读带宽需求是主要的那么理论上单 token 生成时间 19.4GB / 256GB/s ≈ 0.076s也就是大约 13 tokens/s 的上限。实测 11.4 tokens/s 已经非常接近这个理论天花板说明 GPU 算力没有明显拖后腿。这也是为什么传统 CPU 推理那么慢的原因——如果走纯 CPU 跑 70B 模型普通的 DDR5 双通道平台带宽只有 70GB/s 左右理论上限就是 40GB / 70GB/s ≈ 0.57s/token也就是 1.75 tokens/s。实测纯 CPU 推理也确实就是这个水平慢到无法使用。而 Ryzen AI Max 395 把 GPU 和内存带宽整合在一起这才让本地跑大模型有了实际意义。3.3 与 NVIDIA 独立显卡的直接对比为了让大家对 Ryzen AI Max 395 的性能定位有直观概念我找了手头另一台搭载 RTX 4060 Laptop8GB 显存的笔记本做了同模型对比。模型Ryzen AI Max 395RTX 4060 Laptop (8GB)Qwen2.5-7B Q4_K_M42.5 tok/s55.3 tok/sQwen2.5-14B Q4_K_M23.7 tok/s无法加载OOMQwen2.5-32B Q4_K_M11.4 tok/s无法加载OOM这个对比非常有意思。7B 模型上RTX 4060 Laptop 因为 NVENC 优化和更高的浮点算力速度快了大约 30%属于明显领先。但一旦模型大小超过 8GB 显存上限RTX 4060 Laptop 直接阵亡而 Ryzen AI Max 395 依然能跑只是速度慢一些。这就引出一个结论Ryzen AI Max 395 的定位不是“替代 RTX 4090”而是“让原本跑不了的模型能跑起来”。如果你主要用的是 7B-14B 模型NVIDIA 独显仍然是更好的选择。如果你的需求是本地跑 32B 甚至 70B 模型而且不想花大几万块买专业卡那么这颗 APU 是一个非常有性价比的折中选择。另外提一句NPU 在这套方案里目前作用不大。虽然 Ryzen AI Max 395 的 NPU 有 50 TOPS 的算力但主流 LLM 推理框架Ollama、llama.cpp、LM Studio目前都没有针对 Windows 平台的 NPU 后端。实测中 NPU 的负载全程几乎为 0所有推理任务都跑在了 GPU 上。也就是说现阶段 NPU 更多是“锦上添花”的配置真正的推理主力还是 GPU 的统一内存架构。4. 实际操作中的关键技术点4.1 BIOSS 设置与显存分配前面提到过 UMA Frame Buffer Size 这个设置这里再展开说一下。这个选项在不同的主板/整机上名称不同有的叫 UMA Frame Buffer Size有的叫 VRAM Allocation但是作用是一样的在统一内存架构上给 GPU 预留多少专用显存。我的建议是如果主要跑 7B 模型UMA 设 16GB 足够。如果打算跑 32B 以上模型UMA 直接拉到 24GB 或 32GB。如果你用的是 96GB 内存版本UMA 设 32GB 意味着系统可用内存还剩 64GB完全够用。还有一个容易被忽略的点某些整机厂商会在 BIOS 里默认关闭 iGPU 显存访问 或者限制 Above 4G Decoding。如果大模型加载时报错比如 llama.cpp 报 failed to allocate buffer 或者 Ollama 直接闪退建议先去 BIOS 里确认这两个选项是否开启。4.2 推理框架选择与后端调优实测下来几个常见推理框架在同一台机器上的性能排序是llama.cppVulkan 后端性能最好约 42 tok/s7BLM StudioVulkan 后端性能接近 llama.cpp约 40 tok/s7BOllamaDirectML 后端性能最差约 32 tok/s7BOllama 在 Windows 上默认走 DirectML性能损失比较明显。如果你用的是 Ollama可以通过设置环境变量 OLLAMA_DIRECTML0 来尝试切换后端但实测发现新版本的 Ollama 对 Vulkan 的支持还不完善。更推荐的做法是直接用 LM Studio 或者手动编译 llama.cpp。llama.cpp 编译时建议开启以下编译选项cmake -B build -DGGML_VULKANON -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j 16Vulkan 后端在多线程调度上做得比 DirectML 好很多特别是对 AMD GPU 的兼容性更佳。如果你用 LM Studio记得在设置里把 GPU Offload 层数调到最大让尽可能多的模型层跑在 GPU 上否则会有一部分层落到 CPU 上导致速度骤降。4.3 模型量化格式的适配性这次还测了几种不同量化格式的差异。Q4_K_M 是综合表现最好的选择但有两个变体也值得关注Q4_0文件更小速度快 5% 左右但生成质量下降明显尤其在代码生成任务上大括号频率出错。Q5_K_M文件大约增加 15%速度大约降低 8%但生成质量有明显提升。如果你对质量要求高且跑的是 14B 以下的模型建议用 Q5_K_M。因为 7B 档位的速度本来就很快42 tok/s用 Q5_K_M 降到 39 tok/s 也完全感知不到差异。另外建议在 Ollama 和 LM Studio 中开启 KV cache 量化Q8_0 类型的 KV cache可以显著降低长上下文时的内存占用。实测在跑 32B 模型、上下文长度从 2048 提升到 8192 时KV cache 量化后内存占用从 24.3GB 降到 21.2GB效果很明显。4.4 并发推理与多实例负载顺便说一下并发推理场景。Ryzen AI Max 395 因为有 16 核 CPU 和相对充裕的内存在并发处理多个请求时表现比预期好。我用 Ollama 同时发起了 3 个 7B 模型的并发请求总吞吐量大约比单请求时提升了 30% 左右但单个请求的延迟从 0.4s 拉长到了 1.2s。如果是多个不同参数量的模型同时驻留内存比如同时加载 7B 和 32B内存占用累计约 28GB系统依然流畅。这个场景对 NVIDIA 小显存显卡来说是无法想象的——8GB 显存连一个 32B 都装不下更别说同时驻留多模型了。5. 功耗、散热与持续负载稳定性5.1 满载功耗与温控表现整机功耗数据比较有意思。空载待机时整机功耗大约 25W 左右。跑 7B 模型时功耗约 85W跑 32B 时功耗约 142W跑 70B 时功耗约 165W。这个功耗水平比同性能的 NVIDIA 笔记本RTX 4060 Laptop 满载约 130-140W处理器另算要低不少因为 GPU 和 CPU 共享一套功耗预算。温度方面这台迷你主机在满载 70B 模型时CPU 温度稳定在 82-86°CGPU 温度约 75°C没有出现 95°C 以上的危险温度。这得益于迷你主机厂商选了比较激进的散热方案均热板 双风扇日常使用噪音大约 45dBA属于可接受范围但不建议放在卧室里跑长任务。5.2 长时间推理的降频问题这是这次测试中碰到的一个比较隐蔽的坑持续推理 30 分钟以上后生成速度会逐渐下降 10%-15%。原因是 APU 的功耗墙策略是“短时间允许高于 TDP但长时间会回落到 TDP 以内”。Ryzen AI Max 395 的标准 TDP 是 120W但短时功耗可以冲到 170W 左右。持续高负载下系统会把功耗压回 120W 以内GPU 和 CPU 会同时降频。如果你需要跑非常长的推理任务比如批量数据分析建议在 BIOS 里把 TDP 限制适当放宽或者通过 Ryzen Master / UMA 工具调整功耗曲线。实测把 TDP 从 120W 调整到 150W 后长时间推理速度下降率从 15% 减少到 5% 左右。5.3 电池与移动场景的可用性这台机器在电池模式下会有两个限制一是 GPU 频率被锁定到较低水平推理速度大约只有插电状态的 60%二是 Windows 电源模式设置如果没切到“最佳性能”GPU 频率会进一步下降。如果你打算带着这台机器出差在电池上跑大模型基本不现实建议还是插电使用。6. 实际应用场景的适配度评估6.1 代码生成与编程助手场景用 Qwen2.5-32B 试了几轮代码生成。13B 模型的代码生成质量在 32B 面前差距还是相当明显的——32B 生成的代码结构更完整错误更少函数命名更规范。11.4 tokens/s 的速度在“等待生成再复制”的使用模式下完全可以接受约等于你敲完一个小函数的时间AI 已经把代码写完了。强烈建议在 VSCode 里配合 Continue 或 Cline 这类插件使用。因为插件是异步调用的生成速度对交互体验的影响被大幅抹平你一边看生成结果一边继续编辑140 个 token 左右的函数体大约 12 秒生成完完全没有阻塞感。6.2 本地知识库问答场景本地知识库问答RAG是个非常典型的适合统一内存的落地场景。因为 RAG 需要同时加载一个嵌入模型和意图识别模型加上向量数据库的检索整体显存占用很容易超过 8GB。我实测了在本地跑 Qwen2.5-32B bge-m3 嵌入模型同时对 2000 篇文档做检索增强问答占用内存约 26GB响应时间约 5-8 秒整个过程没有 OOM 风险。如果换到 8GB 显存的笔记本上这种场景基本没法落地——32B 模型把显存吃满了嵌入模型只能走 CPU速度会显著下降。所以对于知识库应用这颗 APU 的统一内存架构优势体现得淋漓尽致。6.3 语音识别与转写场景顺手测了 Whisper 大模型的本地推理。用 faster-whisper 加载 large-v3 模型在 Ryzen AI Max 395 上处理 1 小时音频大约需要 6-8 分钟Vulkan INT8 量化速度约为实时的 8-10 倍。这个表现虽然不如 NVIDIA 独显RTX 4060 Laptop 大约 20 倍实时但已经足够支撑日常会议记录、视频字幕生成等场景。7. 常见问题与排查技巧7.1 问题速查表与排查思路现象可能原因解决方案模型加载时报 OOMUMA 显存分配过小BIOS 中把 UMA Frame Buffer Size 调大至 24GB/32GB推理速度极慢5 tok/sGPU 频率被 Windows 电源计划锁死切换电源计划为“高性能”或设置独立 GPU 全局优先级Ollama 加载模型后闪退DirectML 后端兼容性问题改用 LM Studio 的 Vulkan 后端或手动编译 llama.cpp输出首 token 延迟过长模型层数在 CPU 上执行把 GPU Offload 层数设到最大长时间运行速度下降功耗墙降频BIOS 中放宽 TDP 限制LM Studio 识别不到 GPU驱动版本过旧更新 AMD Adrenalin 驱动或确认核显驱动未被禁用模型生成重复内容采样参数设置不合理调高 repeat_penalty 至 1.15-1.37.2 性能提升的隐藏技巧最后分享几个相对偏门但实际有效的技巧开启 GPU 硬件加速计划。在 Windows 图形设置中把“硬件加速 GPU 计划”打开再把 Ollama / LM Studio 的 GPU 调度优先级调至“高性能”。这个设置对 AMD APU 设备有不同程度的提升实测对 32B 模型有 6%-8% 的速度增益。模型文件存放在 NVMe SSD 上。看似废话但很多人忽略了大模型加载也依赖磁盘读取速度。60GB 的模型文件从 SATA SSD 加载需要 30 秒以上从 PCIe 4.0 NVMe 加载只要 8 秒差距非常明显。用 llama.cpp 的 --no-mmap 参数来避免内存不足问题。如果你碰到 ollama 或者其他框架无法加载大模型可以尝试直接用 llama.cpp 命令行加上这个参数有时候能绕开 Windows 显存映射的坑。虚拟内存设大一点。Windows 默认会自动管理虚拟内存但跑 70B 模型时建议手动把虚拟内存页面文件设到 64GB 以上避免系统在内存高位时频繁回收导致卡顿。7.3 直接可以在命令行试跑的方案如果你不想折腾 Ollama 和 LM Studio可以直接下载 llama.cpp 的编译版然后用下面的命令行跑起来# 先把模型下载好假设已经拿到了 Qwen2.5-32B-Instruct.Q4_K_M.gguf llama-cli -m /path/to/Qwen2.5-32B-Instruct.Q4_K_M.gguf \ -ngl 99 \ # 99 表示所有层都放到 GPU -t 16 \ # 线程数建议跟 CPU 核心数一致 -c 4096 \ # 上下文长度 --temp 0.7 \ --repeat-penalty 1.15用这个命令跑你应该能稳定复现我上面的速度数据。如果速度明显偏低优先检查电源计划、UMA 显存分配和后端是否真的启用了 Vulkan启动日志里会有相关输出。8. 综合评估与适用范围建议到这里测试的核心内容基本说完了。最后再聊一下我对这颗芯片的总体判断也回答一些后台私信问得比较多的问题。第一个问题Ryzen AI Max 395 能不能替代 NVIDIA 显卡我的答案是“分场景”。如果你是跑 7B-14B 模型的日常玩家NVIDIA 独显仍然是更好的选择速度快了 30% 左右。但如果你的需求是 32B 以上模型、RAG 多模型驻留、或者不喜欢折腾多卡并联这颗 APU 无疑是一种更简单、更省心的方案——毕竟它不需要你处理供电、散热、驱动兼容和显存溢出那一堆破事。第二个问题适合谁买从这次测试来看三类人最适合 一是做本地知识库和 RAG 应用的开发者统一内存带来的多模型驻留能力价值很大 二是内容创作者和办公用户本地跑大模型的隐私保护优势明显并且 32B 模型的生成质量已经能满足大部分写作和总结需求 三是对隐私敏感、不能把数据传到云端的企业技术团队一台迷你主机就能内部署中等规模的模型服务性价比很高。不过也要诚实地说这台机器的价格并不便宜128GB 版本整套下来基本相当于一台中高端独显笔记本的价格。如果是预算有限的学生党更推荐考虑 64GB 内存版本跑 32B Q4 量化模型依然绰绰有余。还有个值得关注的后续方向AMD 和主流推理框架对 NPU 的支持一旦落地Ryzen AI Max 395 的 NPU 算力才能真正参与推理。现阶段 GPU 跑大模型的表现已经超出预期了NPU 有能力进一步释放算力来辅助处理到时候 70B 模型的生成速度有希望再往上走一截。这个后面如果出了新驱动我也会做一轮对比跟踪。