1. 为什么一块APU的内存带宽能决定本地大模型的生死
1.1 从一次失败的模型加载说起
去年年底我拿到一颗AMD Ryzen AI Max+ 395的工程样品，第一反应跟大多数人一样：这玩意儿核显规模都堆到40个计算单元了，跑个本地大模型应该很轻松吧？结果第一次尝试加载一个70亿参数、4-bit量化的模型，推理速度直接给我泼了一盆冷水——每秒出字速度不到8个token，比我手头一台搭载独立显卡的老机器还慢。当时我以为是驱动没装好，折腾了一下午ROCm环境，最后用rocm-smi一看显存占用和内存占用，才意识到问题根本不在算力上。
这颗APU的算力其实相当可观，NPU加核显加起来理论算力能到50 TOPS级别，但它的内存带宽被卡死在256 GB/s左右（具体取决于你用的内存类型和通道配置）。而本地大模型推理这件事，本质上是一个“内存带宽饥饿型”任务——每生成一个token，模型都需要把全部权重从内存里读一遍。70亿参数的4-bit模型，权重大约3.5 GB，按256 GB/s的带宽算，理论极限也就每秒73个token，实际因为各种开销打个对折，30-40 token/s是正常水平。但如果你的内存配置没拉满，带宽掉到128 GB/s甚至更低，那速度直接腰斩再腰斩。
这就是为什么我说“内存带宽决定本地大模型推理上限”——不是CPU不行，不是GPU不行，是数据喂不进去。
1.2 本地推理的瓶颈到底在哪
很多人一提到本地跑大模型，第一反应是“显卡够不够强”。这个思路在独立显卡上是对的，因为独显有自己的显存，GDDR6或者HBM的带宽动辄500 GB/s到1 TB/s以上，算力反而是瓶颈。但APU不一样，它的核显没有独立显存，用的是系统内存。系统内存的带宽跟显存完全不是一个量级，DDR5双通道撑死也就100-130 GB/s，LPDDR5X四通道能到200-256 GB/s，再往上就得看封装工艺和内存控制器了。
Ryzen AI Max+ 395用的是LPDDR5X-8000四通道配置，理论带宽256 GB/s。这个数字在APU里算顶级了，但跟独显比还是差一大截。所以你在它上面跑大模型，瓶颈几乎永远在内存带宽上，而不是在计算单元上。我实测过，把同一个模型分别放在CPU推理和核显推理下跑，核显推理的速度大概是CPU的3-5倍，但两者都受同一个内存带宽天花板限制。换句话说，你换再强的计算单元，只要内存带宽不变，速度提升就有上限。
1.3 哪些人需要关心这个事
如果你只是偶尔用在线API跑跑对话，那这篇文章跟你关系不大。但如果你属于以下几类人，那内存带宽这个参数你必须吃透：
- 本地部署党：想把模型跑在自己机器上，不依赖网络，数据不出本地。
- 边缘计算开发者：要在功耗受限的设备上跑推理，APU是首选方案。
- AI PC尝鲜者：买了或者准备买AI PC，想知道它到底能跑多大的模型。
- 成本敏感型玩家：不想花大价钱买独显，想用APU凑合跑推理。
我写这篇东西的目的很简单：把“内存带宽怎么算、怎么影响推理速度、怎么配置才能跑满”这件事讲清楚，让你在掏钱之前就知道自己能得到什么。
2. 内存带宽与推理速度的数学关系
2.1 一个公式算清你的理论上限
本地大模型推理的速度上限可以用一个非常简单的公式估算：
理论最大token/s = 内存带宽 ÷ 模型权重体积
注意这里说的是“权重体积”，不是“参数量”。一个70亿参数的模型，如果用FP16精度存储，权重体积是14 GB；如果用4-bit量化，权重体积大约是3.5 GB。精度越低，权重体积越小，同样带宽下能跑出的token/s就越高。
拿Ryzen AI Max+ 395的256 GB/s带宽来算：
| 模型规模 | 精度 | 权重体积 | 理论最大token/s | 实测典型值 |
|---|---|---|---|---|
| 7B | FP16 | 14 GB | 18 | 12-15 |
| 7B | 4-bit | 3.5 GB | 73 | 35-45 |
| 13B | 4-bit | 6.5 GB | 39 | 20-28 |
| 30B | 4-bit | 15 GB | 17 | 10-14 |
| 70B | 4-bit | 35 GB | 7 | 4-6 |
实测值之所以比理论值低不少，是因为推理过程中除了读权重，还要读KV Cache、做注意力计算、写输出结果，这些都会占用带宽。而且内存控制器的效率不可能100%，实际有效带宽通常只有理论值的70%-80%。
2.2 为什么量化对APU特别重要
从上面的表格能看出来，量化精度直接决定了你能跑多快的模型。FP16的7B模型只能跑12-15 token/s，但4-bit量化后直接翻三倍到35-45 token/s。这个差距在APU上比在独显上更明显，因为APU的带宽本来就紧张，每一GB/s都要省着用。
我自己的经验是，在Ryzen AI Max+ 395上跑模型，4-bit量化是甜点，5-bit或6-bit量化是画质和速度的平衡点，8-bit以上基本就是自虐。除非你做的是需要高精度的任务（比如代码生成或者数学推理），否则4-bit的损失在对话场景下几乎感知不到。
2.3 内存通道数和频率哪个更重要
这个问题我被问过无数次。答案是：通道数优先，频率其次。
原因很简单，带宽 = 频率 × 位宽 × 通道数。通道数翻倍，带宽直接翻倍；频率提升20%，带宽只提升20%。Ryzen AI Max+ 395支持四通道LPDDR5X，如果你只插了两根内存条（双通道），带宽直接砍半到128 GB/s，推理速度也跟着砍半。所以买这台机器的时候，一定要确认是四通道满配，别为了省钱选双通道版本。
频率方面，LPDDR5X-7500和LPDDR5X-8000的差距大概在6%左右，实际推理速度差距可能只有3-5 token/s。但通道数从双通道变四通道，差距是翻倍的。所以优先级很明确：先保通道数，再追频率。
3. Ryzen AI Max+ 395的实测表现与配置调优
3.1 测试平台与软件环境
我的测试平台配置如下：
- APU：AMD Ryzen AI Max+ 395（工程样品，最终零售版可能有微调）
- 内存：LPDDR5X-8000，四通道，64 GB
- 系统：Ubuntu 24.04 LTS，内核6.8
- 推理框架：llama.cpp（ROCm后端）、Ollama 0.3.x
- 模型：Llama 3.1 8B 4-bit、Qwen2.5 14B 4-bit、Mistral Small 24B 4-bit
驱动方面，ROCm 6.2是必须的，低版本对Ryzen AI Max+ 395的核显支持不完整，会出现推理过程中掉驱动或者速度异常的情况。安装ROCm的过程这里不展开，官方文档写得很清楚，但有一个坑要注意：安装完ROCm后一定要把用户加入render和video组，否则核显推理会报权限错误。
3.2 不同模型规模的实际推理速度
我跑了三组测试，每组跑三次取平均值，结果如下：
| 模型 | 量化 | 权重体积 | 平均token/s | 峰值token/s | 内存占用 |
|---|---|---|---|---|---|
| Llama 3.1 8B | Q4_K_M | 4.9 GB | 38.2 | 42.1 | 6.8 GB |
| Qwen2.5 14B | Q4_K_M | 8.9 GB | 22.5 | 25.3 | 11.2 GB |
| Mistral Small 24B | Q4_K_M | 14.2 GB | 13.8 | 15.6 | 17.5 GB |
这个成绩跟理论计算基本吻合。8B模型的理论上限是52 token/s（256÷4.9），实测38.2，效率73%；14B模型理论上限28.7，实测22.5，效率78%；24B模型理论上限18，实测13.8，效率77%。效率损失主要来自KV Cache读写和注意力计算。
3.3 关键调优参数与实操步骤
想让Ryzen AI Max+ 395跑出最佳性能，有几个参数必须调：
第一，显存分配（UMA Frame Buffer Size）。在BIOS里把核显的专用显存调到最大（通常是16 GB或32 GB，取决于厂商实现）。这个设置决定了核显能直接访问多少内存作为“显存”使用。如果设得太小，模型权重会被迫放在系统内存里，核显访问时延迟更高。
第二，llama.cpp的编译参数。用ROCm后端编译时，加上-DGGML_HIPBLAS=ON -DAMDGPU_TARGETS=gfx1100（gfx1100是Ryzen AI Max+ 395的核显架构代号）。编译完成后用./llama-cli -m model.gguf -ngl 99 -c 4096启动，-ngl 99表示把所有层都放到核显上跑。
第三，Ollama的环境变量。如果用的是Ollama，在~/.ollama/config.json里加上"OLLAMA_GPU_OVERHEAD": "0"和"OLLAMA_NUM_PARALLEL": "1"。前者避免Ollama预留过多显存，后者避免并行请求争抢带宽。
我实测下来，调完这三个参数后，8B模型的速度从32 token/s提升到了38 token/s，提升接近20%。
3.4 内存带宽的实际测量方法
想知道你的机器实际能跑出多少带宽，可以用mbw或者stream这两个工具。我习惯用mbw，安装简单，结果直观：
sudo apt install mbw mbw -n 10 1024这个命令会分配1 GB内存做读写测试，跑10轮。在Ryzen AI Max+ 395四通道LPDDR5X-8000上，我测到的实际带宽是198-205 GB/s，大约是理论值的78%。这个效率在APU里算正常水平，内存控制器和物理层都有开销。
如果你测出来的带宽明显低于180 GB/s，那就要检查是不是内存没跑满四通道，或者BIOS里的内存频率没设对。
4. 常见问题与排查技巧实录
4.1 推理速度突然掉一半是怎么回事
这个问题我遇到过两次，一次是系统更新后ROCm驱动版本不匹配，另一次是BIOS里内存频率被重置了。排查思路很简单：
- 先用
rocm-smi看核显是否正常工作，频率是否在合理范围。 - 再用
mbw测内存带宽，如果带宽正常但推理慢，那就是驱动或框架问题。 - 如果带宽掉到120 GB/s左右，那基本可以确定是内存通道数或者频率出了问题，进BIOS检查。
还有一个隐蔽的坑：某些Linux发行版默认启用了内存加密（SME），这个功能会占用额外带宽。在GRUB里加上mem_encrypt=off可以关掉，实测能恢复5%-8%的带宽。
4.2 模型加载失败或推理中途崩溃
Ryzen AI Max+ 395的核显在ROCm下的稳定性已经比前代好很多了，但还是有几个常见崩溃场景：
- 显存不足：虽然BIOS里设了32 GB显存，但系统实际可用可能只有28 GB左右。跑24B以上的模型时，如果KV Cache设得太大（比如
-c 8192），很容易OOM。解决办法是降低上下文长度，或者用--no-kv-offload把KV Cache放到CPU内存里。 - 驱动超时：长时间推理（超过30分钟）后，核显驱动可能触发超时重置。在
/etc/modprobe.d/amdgpu.conf里加上options amdgpu lockup_timeout=60000可以延长超时阈值。 - 内存碎片：Linux的透明大页（THP）在某些情况下会导致内存碎片，影响大模型加载。用
echo never > /sys/kernel/mm/transparent_hugepage/enabled关掉THP，加载成功率会高很多。
4.3 常见问题速查表
| 现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 推理速度低于20 token/s（8B模型） | 内存未跑满四通道 | mbw测带宽 | 检查BIOS内存配置 |
| 模型加载到一半报错 | 显存不足 | rocm-smi看显存占用 | 降低上下文长度或量化精度 |
| 推理过程中驱动崩溃 | 驱动超时 | dmesg看amdgpu报错 | 延长lockup_timeout |
| 速度波动大 | 后台进程抢带宽 | htop看CPU占用 | 关掉不必要的后台服务 |
| 核显频率上不去 | 功耗墙限制 | rocm-smi看频率 | 在BIOS里解锁功耗墙 |
4.4 几个我踩过的坑
坑一：用错量化格式。GGUF的Q4_K_M和Q4_0看起来都是4-bit，但Q4_K_M的推理速度比Q4_0慢10%左右，因为它的反量化计算更复杂。如果你追求极致速度，Q4_0是更好的选择，但精度损失稍大。
坑二：忽略内存温度。LPDDR5X在高温下会降频，带宽直接掉。我夏天跑长时间推理时，内存温度能到85度以上，带宽从200 GB/s掉到160 GB/s。后来加了个小风扇对着内存吹，问题解决。
坑三：用USB外接硬盘跑模型。模型文件放在USB硬盘上，加载时带宽被USB接口卡死（撑死10 Gbps），推理速度直接崩。模型一定要放在NVMe SSD上，加载快，推理时也不会成为瓶颈。
5. 这套配置适合跑什么、不适合跑什么
5.1 适合的场景
Ryzen AI Max+ 395在本地推理上的定位很明确：中低参数模型的日常对话和轻量任务。具体来说：
- 8B级别的对话模型：38 token/s的速度完全够用，跟在线API的体验差距不大。
- 14B级别的代码助手：22 token/s的速度稍慢，但代码生成对速度不敏感，可以接受。
- 24B级别的知识问答：13 token/s的速度偏慢，适合不赶时间的场景。
- 多模态小模型：比如LLaVA 7B，跑图片描述和简单视觉问答没问题。
5.2 不适合的场景
- 70B以上的大模型：4-bit量化后35 GB权重，速度只有4-6 token/s，体验极差。
- 长上下文推理：32K上下文下，KV Cache占用大量带宽，速度会掉到个位数。
- 高并发服务：APU的带宽是共享的，同时跑两个请求速度直接减半。
- 训练和微调：别想了，APU不是干这个的。
5.3 跟其他方案的对比
| 方案 | 内存带宽 | 8B模型速度 | 功耗 | 价格 |
|---|---|---|---|---|
| Ryzen AI Max+ 395 | 256 GB/s | 38 token/s | 45-65W | 中高 |
| RTX 4060 Laptop | 256 GB/s | 45 token/s | 80-115W | 中 |
| RTX 4070 Desktop | 504 GB/s | 85 token/s | 150-200W | 高 |
| Apple M3 Pro | 150 GB/s | 22 token/s | 30-50W | 高 |
从表格能看出来，Ryzen AI Max+ 395的能效比相当不错，每瓦性能跟Apple M3 Pro接近，但绝对性能更强。跟独显比，它的优势在功耗和体积，劣势在绝对速度和显存容量。
6. 给不同预算用户的配置建议
6.1 预算充足：直接上四通道64GB
如果你准备买一台Ryzen AI Max+ 395的机器，内存配置只有一个建议：四通道LPDDR5X-8000，64 GB起步。32 GB版本跑14B模型就捉襟见肘了，24B模型根本加载不了。64 GB能让你舒服地跑24B模型，还能留出足够内存给系统和KV Cache。
6.2 预算有限：优先保通道数
如果预算卡得紧，宁可选频率低一点的四通道版本，也不要选频率高的双通道版本。四通道LPDDR5X-7500的带宽是192 GB/s，双通道LPDDR5X-8000只有128 GB/s，差距50%。这个差距在推理速度上是实打实的。
6.3 已经买了双通道版本怎么办
如果你已经入手了双通道版本，也不是完全没救。可以尝试以下优化：
- 把模型量化精度降到4-bit甚至3-bit，减小权重体积。
- 用
llama.cpp的--no-kv-offload把KV Cache放到CPU内存，释放核显带宽。 - 关掉所有不必要的后台服务，减少内存带宽争抢。
- 如果支持内存超频，尝试把频率拉到最高。
但说实话，这些优化最多能挽回20%-30%的性能，跟原生四通道还是有本质差距。
7. 我个人在实际操作中的几点体会
折腾这颗APU跑本地大模型大概有两个月了，最大的体会是：别跟带宽较劲，顺着它来。什么意思呢？就是不要试图在APU上跑超出它带宽能力的模型。8B模型跑38 token/s，体验很流畅；14B模型跑22 token/s，勉强能用；24B模型跑13 token/s，就得有点耐心了。如果你非要跑70B模型，那不是在用APU，是在折磨自己。
另一个体会是，量化格式的选择比想象中重要。我一开始图省事，所有模型都用Q4_K_M，后来发现Q4_0在APU上速度更快，精度损失在对话场景下几乎感知不到。现在我的策略是：对话模型用Q4_0，代码模型用Q4_K_M，知识问答用Q5_K_M。这个组合在速度和精度之间找到了不错的平衡。
最后分享一个小技巧：把模型文件放在tmpfs里。如果你内存够大（64 GB），可以划出16 GB做tmpfs，把常用的8B模型放进去。加载速度从秒级降到毫秒级，而且推理时读取权重完全不占磁盘IO。这个操作对推理速度本身没影响，但启动体验会好很多。
还有一点，如果你用的是Ollama，记得定期清理不再使用的模型。Ollama会把模型缓存在~/.ollama/models下，时间长了能占几十GB。用ollama list看有哪些模型，用ollama rm删掉不用的。内存和磁盘空间在APU上都是稀缺资源，别浪费。
