极致压榨 96G 显存：Qwen3.5 122B (MoE) 大模型本地部署优化指南
极致压榨 96G 显存：Qwen3.5 122B (MoE) 大模型本地部署优化指南
在本地运行超大规模模型（如 Qwen3.5 122B A10B）时，硬件性能的充分发挥往往取决于细微的参数配置。本文将针对 AMD 395max（128G 内存，其中 96G 分配为显存）这一典型硬件环境，分享如何解决主机内存溢出（OOM）、显存利用率不足以及模型崩溃等核心痛点。
一、 环境挑战：为什么我的显存“吃不满”？
在初始配置下，许多用户发现 GPU 显存仅占用不到 70GB，而主机内存却瞬间飙升至 95% 以上甚至导致系统挂掉。对于 Qwen3.5 122B 这种 MoE（混合专家）架构模型，其核心难点在于：
- 参数量巨大： 总参数 122B，但每 token 仅激活 10B。
- 专家权重分配： 默认情况下，llama.cpp 可能会将海量的专家权重留在主机内存中以防止显存溢出。
- 加载逻辑： 若配置不当，系统会先尝试将模型全部塞入 RAM，导致加载过程中断。
二、 核心优化步骤：从内存向显存的“大搬家”
1. 彻底解决加载时的 RAM 满载问题
如果你发现加载模型时内存先冲向 100% 然后才开始加载 GPU，请务必修改以下两项：
- 开启
尝试 mmap()(Memory Mapping)： 允许模型从硬盘直接映射，避免一次性挤占主机内存。 - 关闭
保持模型在内存中(mlock)： 必须取消勾选！否则系统会强行将模型“锁死”在物理内存里，导致 32G 级别的主机内存直接打满。
2. 强制提升 GPU 卸载率
- GPU 卸载 (GPU Offload)： 将层数设置为该模型支持的最大值。对于 Qwen3.5 122B 而言，总层数为 48 层，因此请直接填入 48。
- 将 KV 缓存加载到 GPU： 必须打勾。KV Cache 是随着对话长度增长而迅速消耗资源的部分，将其移至 GPU 是降低主机内存压力最有效的一招。
3. MoE 架构的特殊配置：避开“专家数量”陷阱
在 Advanced 设置中，可能会看到“专家数量”或 expert_used_count 的选项：
- 千万不要填 256： 虽然模型总共有 256 个专家，但每一步仅激活 8 个路由专家 + 1 个共享专家。
- 正确做法： 保持为空或填入 8。强行填入 256 会导致计算图爆炸，触发
GGML_ASSERT崩溃。
三、 深度调优：平衡稳定性与性能
1. 后端选择：Vulkan vs ROCm
对于 AMD 硬件，ROCm 通常对统一内存架构的专家卸载支持更激进，能更好地利用 96G 显存。如果 Vulkan 表现保守（显存卡在 70G），建议切换至 ROCm v2.8.0 进行测试。
2. 上下文长度限制
不要盲目追求超长上下文。在测试阶段，建议将上下文长度 (Context Length) 先设定为 8192 或 16384。在确认稳定后，再根据显存剩余空间逐步向上调优。如果初始值设为 524,288 等极大值，会直接导致内存池空间不足而崩溃。
3. 辅助参数微调
- CPU 线程池大小： 调小至 8~16，减少 CPU 侧不必要的内存开销。
- Unified KV Cache： 如果遇到不稳定的情况，可以尝试取消勾选，有时这能释放更多空间给专家权重。
四、 总结：70GB 显存是正常的吗？
从日志分析看，Q4_K_M 量化版本的 Qwen3.5 122B 完整权重大小约为 70.35GB。当你看到 GPU 占用稳定在 70GB+ 且显示 “offloaded 49/49 layers” 时，意味着模型权重已经完全载入显存。
此时，剩下的 20GB+ 显存空间将由 KV Cache（取决于上下文长度）和计算缓冲区占用。通过上述优化，你可以在 32G 主机内存的机器上平稳运行这一百亿级参数的巨兽，并获得流畅的推理体验。
技术提示： 如果 UI 界面依然无法满足你的需求，建议使用纯命令行版的 llama.cpp，配合 -ngl 999 --n-cpu-moe 0 参数强制所有专家权重上云（GPU）。