ik_llama.cpp 多 GPU 混部实战如何在 2×10GB 显存 512GB 内存上运行 Qwen3-235B 级超大 MoE 模型【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp导读本文围绕 ik_llama.cpp 社区讨论《multy gpu》展开用户拥有 2 张 10GB 显存的 GPU 与 512GB 系统内存询问能否运行 Qwen3-235B 这类超大 MoE 模型。项目作者 ikawrakow 的答复是可以但性能高度依赖 CPU因为大量计算将在 CPU 上完成。本文以此为核心结合仓库中的 docs/parameters.md 参数手册、README.md 以及相关讨论如 #397 KV split while using -sm row系统讲解 ik_llama.cpp 的多 GPU 拆分模式、CPU/GPU 混合推理、MoE 专家张量调度等关键技术让读者掌握在小显存 大内存环境下运行超大模型的完整方案。一、讨论背景问题本身与作者的答复讨论 #372 提出的原始问题非常典型我有一台 512GB 内存的机器配了 2 张 10GB 显存的 GPU原文 cmp90 应指同规格消费级显卡能否运行 Qwen3-235B作者 ikawrakow 于 2025-05-06 的答复是我认为可以。但你能获得什么样的性能还取决于你的 CPU——因为计算中的很大一部分将在 CPU 上完成。这句话点出了 ik_llama.cpp 在超大模型推理上的核心设计取向它不是简单地用多张 GPU 平分模型而是把GPU 加速 CPU 兜底的混合推理做到极致。Qwen3-235B 是典型的 MoEMixture-of-Experts模型总参数量约 235B但单次前向只激活少量专家。这意味着模型全部权重放不进 20GB 显存必须驻留一部分在 512GB 的系统内存中MoE 的专家expert权重在单次推理中只有 2%5% 会被实际使用见 docs/parameters.md 的说明非常适合放在 CPU 内存按需调度注意力等密集层计算若放 GPU能显著加速而专家矩阵乘法大量发生在 CPU因此CPU 的单核性能、内存带宽、PCIe 通道数直接决定实际体验。下面我们将从如何把模型拆到多张 GPU和如何让 CPU 参与计算两个维度把答案展开成可落地的操作指南。二、多 GPU 拆分三种 split-mode 及其取舍2.1 参数总览在 ik_llama.cpp 中控制多 GPU 拆分的核心参数集中在 docs/parameters.md 的 GPU 配置表中| 参数 | 说明 | 默认 | 备注/示例 | | - | - | - | - | |-sm, --split-mode SPLIT_MODE| 如何在多张 GPU 间拆分模型 | none |none仅用一张 GPUgraph按张量与计算图拆分密集与 MoE 模型均极为高效layer按层与 KV 拆分。示例-sm graph| |-ts, --tensor-split SPLIT| 每张 GPU 承担的模型比例逗号分隔 | - | 手动微调利器。示例-ts 3,1| |-dev, --device dev1,dev2| 参与卸载的设备列表 | none | 机器 GPU 很多但只想用其中几张时。示例-dev CUDA0,CUDA1| |-mg, --main-gpu i| 主 GPUsplit-mode none时使用 | - | - | |-smf16/-smf32| GPU 间数据交换使用 f16 / f32 | 1 / 0 | 见 [PR 1087] | |-grt, --graph-reduce-type| GPU 间交换数据的归约类型 | f16 | 可选 q8_0 / bf16 / f16 / f32用于降低 GPU 间数据传输量 | |--max-gpu N| split mode graph 下单层最多使用的 GPU 数 | - | GPU 超过 2 张时有时只用 2 张反而更快 | |-smgs, --split-mode-graph-scheduling| 强制使用 Graph 模式调度 | 0 | - |2.2layer模式按层拆分经典方案-sm layer是传统 llama.cpp 的默认思路把模型的 Transformer 层按顺序分到各 GPUKV cache 也随之按层拆分。它的优点是实现简单、各 GPU 职责清晰缺点是层间存在串行依赖GPU 间需要频繁传递中间激活值扩展性有限。值得注意的是讨论 #397 揭示了一个实际差异用户发现 ik_llama.cpp 在-sm row下不拆分 KV cache日志中只见CUDA0 KV buffer size而 where is CUDA1?作者回复这是他 fork 时沿用了上游行为并未专门实现row模式的 KV 拆分同时该用户反馈-sm row相比-sm layer有约1.5 倍的性能优势——这正是选择拆分模式时值得实测对比的原因。2.3graph模式按张量与计算图拆分本项目特色-sm graph是 ik_llama.cpp 引入的独家拆分模式README.md 记录为 New split mode graph for multi GPU setups它把模型张量与整张计算图同时拆分到多张 GPU而不是简单按层切分。从源码与文档描述看对密集模型与MoE 模型都extremely effectivedocs/parameters.md配合--max-gpu N可以限制单层参与计算的 GPU 数量——当 GPU 数量较多但全用反而性能下降时可以回退到只用 2 张docs/parameters.md-smf16/-grt等参数专门用于调节 GPU 间数据交换的精度与体量说明 graph 模式下 GPU 间通信量是影响性能的关键因素。使用提示README 明确警告graph模式与部分卸载--cpu-moe、--n-cpu-moe、tensor overrides组合时个别用户报告过乱码/语无伦次的问题若遇到可在命令行追加-cuda graphs0关闭 CUDA graph 重试README.md。三、显存不够怎么办CPU/GPU 混合推理的参数矩阵回到讨论的核心场景2×10GB 显存无论如何装不下 235B 模型必须让 CPU 承担大部分权重存储与部分计算。ik_llama.cpp 为此提供了一整套递进式的卸载控制参数见 docs/parameters.md 的 Offload less to the GPU 一节。3.1 从自动到手动--fit与-ngl第一步先试自动分配--fit--fit会根据各 GPU 实际可用显存自动决定哪些张量卸载到 GPUREADME.md 记录为 Auto-fit offloaded tensors to available VRAM (MoE and dense models)。配套参数--fit-margin N安全余量MiB默认 1024CUDA OOM 时增大觉得浪费显存时减小--gpu-fit-margin GPU1,M1,...逐 GPU 设置余量若对--fit的分配结果不满意用-ts 3,1之类的比例手动调整各 GPU 的负载docs/parameters.md。手动控制层数用-ngl, --gpu-layers N默认 999即尽量全卸载。对 MoE 模型建议直接给一个大数如-ngl 999让分配逻辑自行决定显存不足导致加载失败时再逐步减小如-ngl 20。想提前观察内存占用而不真正加载权重可用--dry-run它仍会报告 OOM 与内存占用非常适合大模型手动调参docs/parameters.md。3.2 MoE 专属--cpu-moe与--n-cpu-moe N对于 Qwen3-235B 这类 MoE 模型ik_llama.cpp 提供了专门的混合推理开关--cpu-moe把所有 MoE 权重留在 CPU 内存GPU 只放注意力等密集层。这是最省显存的简单模式--n-cpu-moe N前 N 层的 MoE 权重放 CPU其余放 GPU——当有些显存但不够全放时使用。其原理在 docs/parameters.md 有清晰的说明MoE 的ffn_*_exps专家张量是稀疏使用的通常只激活 2%5%放在慢速内存影响最小而注意力层是全激活的必须优先保证在最快内存中。3.3 专家张量级控制-ot正则覆盖与-ooae若前两者仍不满足需求-ot, --override-tensor允许用正则表达式逐张量指定存放位置CPU 或 GPU# 把 blk.0 ~ blk.87 各层的所有专家权重强制放回 CPU 内存 -ot blk.(?:[0-9]|[1-7][0-9]|[8][0-7]).ffn._exps.CPU以 Qwen3-VL-235B 为例共 93 层这条规则把第 087 层的专家放 RAM第 8893 层专家留显存docs/parameters.md。实战经验还包括up/gate投影不应分到不同 GPU 设备可能引发轻微死锁共享专家如 GPT-OSS 的shexp始终激活应放 GPU密集层无专家的blk.n非常适合放显存能显著加速混合推理。-ooae, --offload-only-active-experts默认开启则是另一维度当部分 MoE 专家权重在 CPU 上、而批处理调度器决定拷贝到 GPU 计算时只拷贝本次被激活的专家大幅减少 RAM→VRAM 传输量对 GPT-OSS-120B 这类激活专家占比小的模型收益显著当大批量下几乎所有专家都会被激活时该选项可能无收益甚至略降速可用-no-ooae关闭docs/parameters.md。3.4 运算级控制-op与张量驻留策略配合如果希望更精细地决定哪些算子允许在 GPU 上执行即使其权重在 RAM可使用-op, --offload-policy例如-op 27,0 # 禁止 MoE 专家的 indirect 矩阵乘法卸载到 GPU -op 26,0 # 禁止普通矩阵乘法卸载到 GPU -op -1,0 # 一键关闭所有 GPU 卸载其中第一个整数是ggml_op枚举值第二个整数 0/1 表示禁止/允许卸载docs/parameters.md。3.5 混合推理的环境变量与陷阱GGML_CUDA_NO_PINNED_WEIGHTS让驻留 CPU 的权重保持 mmap 而非 pinned 内存降低混合推理时的 RAM 占用docs/parameters.md-rtr陷阱README 醒目警告混合推理专家留在 CPU时不要使用-rtr——它会把 RAM 中的张量重打包为行交错格式而 k-quantsK2_K, Q3_K, Q4_K, Q5_K, Q6_K没有 CUDA 行交错实现会导致这些矩阵乘法永远在 CPU 上执行明显拉低 prompt 处理速度README.md。四、围绕 2×10GB 场景的实战组合建议综合上述参数针对2×10GB GPU 512GB RAM Qwen3-235B的典型配置可以按以下路径逐级尝试命令以llama-server/llama-cli为例路径按实际编译产物调整第一步自动分配 双 GPU graph 拆分llama-server -m Qwen3-235B.gguf \ -sm graph \ -dev CUDA0,CUDA1 \ --fit \ -ngl 999 \ -c 8192第二步显存吃紧时把 MoE 权重压回 CPUllama-server -m Qwen3-235B.gguf \ -sm layer \ --n-cpu-moe 999 \ -ooae \ --no-mmap第三步张量级微调参考 Qwen3-VL-235B 的 93 层示例llama-server -m Qwen3-235B.gguf \ -sm graph -dev CUDA0,CUDA1 -ngl 999 --fit \ -ot blk.(?:[0-9]|[1-7][0-9]|[8][0-7]).ffn._exps.CPU \ -ooae每一步都应先用--dry-run观察内存占用--dry-run仍会正确报告 OOM 与显存用量确认后再实际加载。此外还有两个能显著降低显存压力的配套手段详见 docs/parameters.mdKV cache 量化--cache-type-k q8_0 --cache-type-v q8_0或-ctk q8_KV可大幅压缩 KV 显存对超长上下文还可搭配--k-cache-hadamard/--v-cache-hadamard提升低比特精度调小上下文-cKV cache 体积与n_ctx成正比把-c降到应用所需的最小值是省显存最直接的手段。五、关于 CPU 的决定性作用与性能预期回到作者的原话——性能取决于你的 CPU因为很大一部分计算在 CPU 上完成。结合本章参数可知在 2×10GB 显存的配置下Qwen3-235B 的专家权重绝大多数驻留系统内存每次前向都有相当比例的矩阵乘法在 CPU 上执行因此 CPU 的核心数、AVX-512/AVX2 指令集支持、内存通道带宽直接决定吞吐启动日志中system_infoAVX 1 | ... AVX512 1 ...见 #397 中的示例输出可用于确认 CPU 的向量指令能力多 GPU 拓扑同样重要文档建议用nvidia-smi topo -p2p r检查 GPU 间 P2P 连接用CUDA_VISIBLE_DEVICES调整设备顺序让最快的 GPU 承担主计算并关注主板/BIOS 的 ReBAR/Resizable BAR 支持docs/parameters.md。六、总结讨论 #372 的问答虽然简短却浓缩了 ik_llama.cpp 混合推理的核心思想小显存环境运行超大模型完全可行成败取决于 CPU 与内存子系统以及卸载策略的精细程度。本文给出的完整工具链——-sm graph/layer双 GPU 拆分、--fit自动分配、--cpu-moe/--n-cpu-moe/-ot逐级下放 MoE 专家、-ooae按激活专家传输、--dry-run预检、KV cache 量化——正是把作者那句我认为可以落地的全部手段。对于每一位计划在有限显存上挑战超大 MoE 模型的用户建议从--fit-sm graph起步用--dry-run验证再逐步用-ot与-ts调优最终找到属于自己硬件组合的最优配置。延伸阅读多 GPU 讨论原文KV 拆分与 -sm row 性能对比讨论参数手册GPU 配置与卸载策略项目 READMEMoE 与 CUDA 注意事项按需张量热重载文档含 -sm graph/attn 等拆分细节【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考