前言
之前写过一篇关于HP战99 Ultra（搭载AMD AI Max+ 395）的使用体验，今天聊聊这台笔记本在AI推理场景下的表现。作为这台机器宣传的主要场景，AI推理的实际使用情况却优点一言难尽。
硬件配置回顾
| 配置 | 详情 |
|---|---|
| CPU | AMD Ryzen AI Max+ 395 16C32T Zen5 |
| 内存 | 64G LPDDR5 8000MT 4通道可划分显存 |
| 显卡 | Radeon 8060S 40CU RDNA3.5 |
| 显存 | 可在BIOS里将几个固定挡位的内存分配给显存 |
关键概念：可划分显存 vs 统一内存
在深入分析数据之前，需要理解几个重要概念：
- 传统显存：传统独立显卡的固定显存，容量固定，如RTX 4090的24G
- 可划分显存：静态分配机制，将内存的一部分固定划给GPU作为显存使用，如AI Max+ 395
- 统一内存：内存和显存统一寻址，整个内存空间CPU和GPU都可以访问，无需显式分配（主要见于Apple M系列芯片）
重要区别：AI Max+ 395使用可划分显存架构，需要静态分配部分内存给GPU使用；而统一内存无需显式分配，灵活性更高。
AI推理测试数据
为了方便，以及因为我至今没能在WSL下成功运行rocminfo也就没办法跑vllm等主流推理引擎方案（就离谱），本次测试均在Windows下使用LM Studio运行。
GLM 4.7 Flash
这是个MoE模型，总参数量30B激活3B的规模，主要测试Q4_K_M量化的情况。在这个量化等级下，在模型大小为18.13GB。
以下的给出Prompt为：
编写一个科技公司的官网的HTML
另外值得一提的是，LM Studio中对AMD显卡有两种Runtime：Vulkan和ROCm。我本以为两种Runtime不会有什么很大的区别，但是实际测试下来却axm并非如此。
在16K上下文下：
| 专用显存 | 512M | 32G |
|---|---|---|
| 显存占用 | 20.8G | 21.3G |
| Vulkan速度、总数(token/s) | 17.26 (6970) | 42.89 (6107) |
| Vulkan 首token (s) | 0.8 | 0.8 |
| ROCm速度、总数（token/s） | 15.28 (5262) | 14.42 (6351) |
| ROCm 首token (s) | 0.04 | 0.34 |
Vulkan在32G专用显存下的速度实在是过于逆天，于是我重新跑了数次，结果均非常接近。后面我们还能拿到如此让人匪夷所思的成绩。
16K的上下文只能说勉强够用。既然还有这么多显存可用，不妨试试更多的长度上下文。根据LM Studio估计，不同长度上下文的显存使用估计值：
- 16K上下文：18.59G
- 64K上下文：19.57G
- 最大支持（198K）：22.3G
看起来MoE模型的一大好处就是可以把上下文拉大！于是我选择GLM 4.7 Flash最大支持的长上下文 198K下，虽然LM Studio的估计显存占用也仅有22.3G，但是512M专用显存的无法正常加载：
只有在32G下可以正常使用，在Vulkan下获得了**37.28 token/s（7857 token，首token 0.15s）**的成绩。
同时我还测试了Q6_K的量化模型，在16K上下文、32G专用显存下：
- 模型大小：24.61GB
- 预计显存占用：25.12GB
- 推理性能：
- ROCm：13.79 token/s（6419 token，首token 0.33s）
- Vulkan：25.51 token/s（5717 token，首token 0.20s）
再次看到了不知道该说是Vulkan逆天还是ROCm的成绩！ROCm作为AMD官方的方案，居然被Vulkan拉开了如此大的差距。
在不开启思考的情况下，10 token/s的速度还是可以应付日常使用的。
Qwen3 VL 32B
稠密模型的情况就不一样了。这一部分我选择了Qwen 3 VL 32B来测试。
这是个支持图像输入的模型，于是我去stackoverflow上截了如下这一张图，
并给出prompt：
使用html和css重现这个HTML页面
以下为结果：
| 专用显存 | 512M 16K | 512M 24K | 32G 16K |
|---|---|---|---|
| 显存占用 | 25.8G | 28.3G | 27.5G |
| Vulkan速度、总数(token/s) | 3.74 (4059) | 3.51 (3676) | 9.41 (6801) |
| Vulkan 首token (s) | 36.67 | 39.29 | 18.32 |
| ROCm速度、总数（token/s） | 4.15 (3723) | 3.10 (3713) | 9.42 (4198) |
| ROCm 首token (s) | 24.59 | 26.56 | 9.46s |
可以看到，在24K上下文已经到32G显存的极限了（28G）。但不管有没有独立显存，这个推理速度用起来已经是比较难受的级别了。
分配48G给显存？
395的另一个宣传点是可以将75%的内存划给显存，在64G的型号上，BIOS中最高可以将48G的内存划给显存。
听起来很美？48G显存甚至可以高量化跑32B模型了！
Qwen 3 VL 32B的Q6_K量化模型大小为28.08G，在32G显存下可以加载，但是推理的时候因为显存不够了，速度比可以完全在显存中的Q4版本慢很多。经过测试，Q5_K_M是最大的32G显存可以充分的量化规格。
而这时候你想到，48G显存岂不是就可以接近这个问题了？
可是事实却是：16G的系统内存不仅使得正常的系统操作会开始缓慢甚至卡顿，甚至模型都无法正常加载！而我已经LM Studio中有三个选项和显存和内存全部调整为不给内存太多压力了：
- KV缓存卸载到GPU内存中：打开，显存够大！
- 保持模型在内存中：关闭
- 尝试mmap()：将磁盘上映射到内存中空间中，关闭
内存可划分为显存 != 共享内存
395的主要的宣传口号，就是内存可以当作显存用。这话当然不假，BIOS里确实可以将内存划分给显存，但是，它和我们预期的共享内存完全是两码事：
- 被划分给显存部分不可以再作为内存使用
- 每次切换显存需要重启，不可无缝切换
那，如果我们不划分显存，直接把内存当显存用呢？其实现在的推理框架都支持把内存当显存用，但是以下两个问题让用内存当显存的方案下的推理速度惨不忍睹：
- 内存与显存的速度之间有巨大差距
- 内存中的数据仅能由CPU计算，而CPU在AI计算场景下速度非常缓慢，且CPU和显卡的计算数据需频繁相互拷贝
理论上来说，395的内存和显存均为同一款芯片，问题1不存在，但实际上问题2的问题仍然无法避免：即使是在同一块芯片上，显存仍然不能直接用内存部分的部分，内存和显存之间拷贝仍然非常频繁。
以下为使用512M专用显存（上）和32G专用显存（下）使用Vulkan运行GLM 4.7 Flash Q4_K_M时的任务管理器的图片，可以看出，512M的专用显存下GPU利用率只有70%左右，而32G下可以到达90%以上。而右上角的Copy也可以看出512M专用显存下显存一直在进行复制的操作。
同一现象也出现在512M专用显存下运行Qwen 3 VL 32B Q4_K_M的情况，GPU利用率更是只有50%，而Copy图中也能一直看到复制的过程，而整个过程中CPU也在（艰难地）参与运算。而CPU参与计算在笔记本场景下有抢功耗的问题，更影响了GPU的性能发挥。
更进一步地，如果把上下文拉到24K，进一步加大显存的需求量，在512M专用显存下情况更加恶化了：GPU有接近一半的时间都闲着。要知道，这个时候显存需求甚至才26G！
总结
我用两个字总结395的优点：能用
- 大显存确实可以跑一些正常显卡无法跑的模型，虽然慢，但是能跑比不能跑好！
- 成本相对较低（相比高端显卡）（也只是相对了）
- 4060移动端的绝对算力，不算高，但是愿意等等的话，它能跑的模型还是能给出结果的
可是这台笔记本形态、64G的总内存的设备却有点尴尬：
- 为了兼顾日常使用，实际上最多只能32G给显存
- 80W的最高功耗，无法充分发挥CPU的性能
- 手动划分显存操作失去了灵活性
所以395确实非常适合小主机场景：
- 这类主机在分配96G显存的情况下还有32G可以用于日常场景，比64G=48G+16G实用太多
- 这类主机的性能释放普遍超过100W，也有更完善的散热方案，可以更完美地发挥CPU和GPU的性能
- 和395刚出来的时候AMD更羸弱的AI生态相比，至少现在主流的推理场景（LM Studio，Ollama、ComfyUI）都已经可以用了（至少我在搜索了包括AMD官网的无数地方后，终于还是找到了AMD官方支持的
pytorch）
甚至小主机的价格也比笔记本形态的设备（64G 19999）便宜太多（128G普遍15000，希望还没开始涨）。在这个内存价格疯涨的年代，能以这个价格有一台可以跑大模型的机器已经很不容易了。