ik_llama.cpp 中 DeepSeek MLA 注意力优化的演进从 PR #180 到可选的-mla实现【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp导读本文基于 ik_llama.cpp 仓库中 PR #180「Deepseek MLA Optimizations」 的完整讨论记录梳理该仓库对 DeepSeek 系列模型 MLAMulti-head Latent Attention注意力机制的优化全过程从直接移植上游实现的性能得失分析到最终演变为默认关闭、可按需开启的-mla/--mla-use运行时选项。读完本文你将理解 MLA 优化的技术原理为什么它能提升长上下文解码速度却拖慢预填充、-mla各档位的含义与选择策略以及如何在当前仓库的源码中定位对应实现。一、背景为什么 DeepSeek 模型需要专门的 MLA 优化DeepSeek 系列大模型DeepSeek-V2/V3/R1 等在注意力层采用了 MLAMulti-head Latent Attention多头潜在注意力架构其核心思路是不直接缓存每个注意力头的 K、V 向量而是先通过低秩压缩矩阵把 K、V 压缩成一份共享的潜在表示latent representation再写入 KV 缓存。这样 KV 缓存的内存占用可以大幅缩减——这也是该架构名称中 Latent 的含义。然而这份压缩是有代价的推理时每次都要做额外的解压计算把潜在表示恢复成参与注意力分数计算所需的 K、V。正如 PR 讨论中 fairydreaming 的总结整个 DeepSeek MLA 的意义在于通过存储 KV 向量的压缩潜在表示来减少 KV 缓存内存但我们仍然必须执行额外的计算来解压并利用它们计算注意力分数和注意力输出。这个压缩-解压的往返正是 ik_llama.cpp 中 MLA 优化工作的出发点如何在保留 MLA 低内存优势的同时让解压和注意力计算的矩阵乘形态更高效。上游 llama.cpp 的 PR #11446 对此提出了一套实现方案而 ik_llama.cpp 的 PR #180 就是对该方案的一次非常直接的移植作者 saood06 原话。二、PR #180一次直接移植及其初步收益PR #180 由saood06于 2025-01-29 提交状态为已关闭Closed其描述明确写道Very direct port of https://github.com/ggerganov/llama.cpp/pull/11446作者在双路 Xeon E5-2690 v3无独立 GPU纯 CPU 推理上用Q4_K_S量化版本对deepseek2 671B模型做了 llama.cpp 与 ik_llama.cpp 的直接对比模型大小参数测试llama.cpp t/sik_llama.cpp t/sdeepseek2 671B Q4_K - Small355.33 GiB672.05 Bpp5127.638.53deepseek2 671B Q4_K - Small355.33 GiB672.05 Btg1282.743.11即预填充pp512提升约 12%单 token 生成tg128提升约 13.5%。作者被这个 PR 吸引的原因正是 TGtoken generation解码端的收益——DeepSeek-R1 作为推理模型生成阶段往往占据绝大部分运行时间。同时该 PR 还包含作者上一个 PR 中遗漏的convert_hf_to_gguf.py改动并提出了一个实际问题旧版 imatrix 文件如 DeepSeek-R1 的imatrix.dat如何补上从kv_b拆分出的attn_k_b.weight/attn_v_b.weight对应分量——因为当时运行会打印 did not find weights for attn_k_b.weight/attn_v_b.weight 的警告而重新生成 imatrix 文件资源开销很大。三、性能剖析为什么预填充速度反而大幅回退PR #180 的关键价值不在于它自身的性能数据而在于维护者 ikawrakow 对它做的逐算子op级别的性能剖析。这份剖析揭示了 MLA 朴素移植方案的深层问题直接决定了后续的实现方向。3.1 注意力部分耗时对比在 8192 token 的 prompt 上主分支main即原始注意力实现的注意力部分各矩阵乘法耗时如下结果张量耗时 (s)kq4.116kqv2.372kqv_out0.458kv0.253kv_pe_compresseed0.219q0.687total8.107而应用 PR #180 后结果张量耗时 (s)kq_nope8.343kq_pe2.495kqv0.401kqv_compressed7.120kqv_out0.473kv_pe_compresseed0.224q0.693q_nope20.240total19.989注意力部分整体慢了约2.5 倍。进一步看整图开销主分支在GGML_OP_ADD上耗时 0.114 秒、GGML_OP_CONT连续性拷贝0.194 秒而 PR #180 中GGML_OP_ADD高达 3.320 秒、GGML_OP_CONT达 2.701 秒。整体处理时间从主分支的 27.73 秒恶化到 45.47 秒。3.2 根因3 倍乘加运算量maddsikawrakow 给出了精确的数学分析PR #180 的注意力实现在矩阵乘法中产生了约 3 倍更多的乘加运算multiply-addsmadds。预填充阶段PR 需要2 × 512 × 16 × n_token²次 madds而原始实现只需(192 128) × 16 × n_token²次解码阶段PR 需要2 × 512 × n_prompt次主分支为(192 128) × 16 × n_prompt次。也就是说 PR 在解码阶段同样多算了 3 倍运算量但它却更快——原因是张量形状的差异主分支16 个矩阵乘法每个都是192 × n_prompt * 192 × 1K×Q或n_prompt × 128 * n_prompt × 1V×softmax(K×Q)本质上是16 个 GEMV矩阵-向量乘在现代 CPU 上 100% 受内存带宽限制PR #180形状变成512 × n_prompt * 512 × 16和n_prompt × 512 * n_prompt × 16是真正的 GEMM矩阵-矩阵乘FLOPs 高得多但计算密度也高得多反而用更少时间完成了更多工作。ikawrakow 的结论非常直白按照目前这种方式实现预填充性能没有恢复的可能。同时他也指出这些数字针对的是 Deepseek2-Lite 模型——对更大的模型rank-512 的分解可能真正算得上低秩结论可能不同。3.3 关于矩阵吸收方案的尝试与否定fairydreaming 曾提出可以用 DeepSeek-V2 论文中提到的吸收矩阵absorbing matrices技巧来修复预填充性能但随后在跟踪上游讨论后确认此路不通——吸收技巧在该场景下并不成立。讨论中 fairydreaming 还提出一个实现层面的诉求希望 ggml 的ggml_mul_mat()支持转置矩阵的乘法因为其实现既需要直接使用 KV 缓存、又需要以转置形式使用它当时他通过同时保存常规与转置两种形态的 KV 缓存绕开问题但代价是内存翻倍。四、TG 与 PP 的取舍长上下文下的实测数据PR 作者 saood06 用batched-benchbatch size 1解码 32 token在不同预填充长度下做了系列实测数据直观展示了 MLA 移植的收益与代价分布。4.1 IQ4_K_R4 量化PR #180 版本PPTGBN_KVT_PP sS_PP t/sT_TG sS_TG t/s12832116022.5695.6710.2373.1351232154476.4476.7010.7932.9610243211056144.1007.1110.7882.9720483212080312.3066.5612.6242.5340963214128745.7605.4912.9292.48819232182242023.8594.0516.0172.004.2 同量化主分支无 MLAPPTGBN_KVT_PP sS_PP t/sT_TG sS_TG t/s12832116020.9586.1110.9992.9151232154463.5748.0512.4742.5710243211056118.6308.6314.4622.2120483212080258.9997.9118.2411.7540963214128574.5937.1326.0231.23819232182241391.7225.8943.0560.74对比两组数据可以清晰看到趋势预填充PPPR 版本普遍更慢8K 上下文时从 5.89 t/s 掉到 4.05 t/sq8_0 下从 6.06 掉到 4.03解码TGPR 版本普遍更快且上下文越长优势越明显——8K 上下文时从 0.74 t/s 跳到 2.00 t/s接近 3 倍后续补充测试q6_0 / q8_0 K 缓存、无 K 缓存量化结论一致PP 稳定回退、TG 稳定提升。作者还测了 q8_0 K 缓存下 8K 上下文的 KV 缓存占用为 40,233.55 MiB并指出如果想测更长上下文需要更小的量化或用 RPC 扩展。4.3 环境侧证Epyc 服务器上的对比fairydreaming 在双路 Epyc32 线程、--numa distribute上对 671B Q4_K_S 模型的测试同样印证了主分支即无 MLA 的 ik_llama.cpp本身的竞争力llama.cpppp512 26.08 t/stg128 9.57 t/sik_llama.cpppp512 49.47 t/stg128 10.01 t/s。即 ik_llama.cpp 当时解码快约 4.6%预填充快约 90%。ikawrakow 也在 Deepseek-Lite 上观察到 CUDA 后端对 MLA 模型的预填充存在严重瓶颈RTX-4080 上 PP-512 仅 3500 t/s、TG-128 仅 142 t/s而其 Ryzen-7950X CPU 上 PP-512 达 525 t/s、TG-128 达 36 t/s并推断在部分 GPU 卸载 DeepSeek-R1 的场景下高内存带宽的多路 CPU 平台甚至可能胜过 GPU 方案。五、最终方案PR #188「Add optional MLA」——把选择权交给用户PR #180 的核心教训是MLA 优化的利弊高度依赖使用场景——解码为主的推理负载长上下文 长生成收益显著而预填充为主的负载则明显受损。因此 ikawrakow 在 2025-01-29 就提出或许前进的好办法是增加一个额外的架构如deepseek-mla同时保留原始的deepseek2/3。这样根据用例用户可以在长 prompt 后的 TG 速度与长 prompt 处理后的短生成 PP 速度之间做选择。这一思路最终落地为 PR #188「Add optional MLA」MLA 改为可选默认关闭通过新增的-mla或--use-mla命令行选项开启。其设计要点运行时切换PR #180 在模型中同时保留了原始wkv_b张量及其拆分出的wk_b、wv_b虽然略显浪费但这些张量不大恰好让两种注意力实现可以随时切换兼容旧模型若模型转换时未包含wk_b/wk_v张量即使命令行请求 MLA也会自动禁用 MLA 而不报错消除冗余拷贝移除了部分不必要的ggml_cont拷贝——该仓库已支持非连续 RoPECUDA 上的非连续 RMS norm 也已支持CPU 一直支持。PR #188 随后被合并成为当前仓库 MLA 支持的基础。六、当前仓库中的 MLA 实现mla_attn的四档设计从当前仓库源码看MLA 支持已经历多轮迭代最终形成mla_attn这一上下文参数。其定义见 common/common.hint mla_attn 3; // MLA 0: standard, 1: MLA with K and V^T cache, 2: MLA with just K cache, 3: the best of both worlds对应含义取值含义0标准注意力不使用 MLA1MLA缓存 K 与 V 的转置V^T cache2MLA仅缓存 K不缓存 V 转置3两者之优best of both worlds默认值在 common/common.cpp 中对应命令行选项-mla, --mla-use enable MLA (default: %d)同时在 include/llama.h 中mla_attn被标注为实验性参数int mla_attn; // whether to use MLA attention [EXPERIMENTAL]llama-bench基准工具也支持该选项见 examples/llama-bench/llama-bench.cpp-mla, --mla-use 0|1|2默认 3。6.1 运行时校验与回退逻辑从 src/llama.cpp 的上下文构建逻辑可以推断出以下行为对应llama_new_context_with_model路径模型不是MLA 架构is_mla_model()为假时mla_attn会被强制置 0MLA 模型配合非全部层卸载n_gpu_layers大于 0 且小于总层数且 split mode 为 graph 时非 3 的取值可能不工作会自动回退到mla_attn 3需要 V 缓存needs_v_cache的条件是mla_attn 1且未启用 Flash Attention——这正对应mla1的 K 与 V^T 缓存语义见 src/llama.cpp。6.2 张量层面的实现wk_b、wv_b与wk_b_ppMLA 的解压计算在张量层面体现为原始wkv_b被拆分为wk_bK 投影与wv_bV 投影两个张量。模型加载后llm_prepare_mla见 src/llama.cpp会在distribute_mla_tensors之后运行负责准备 MLA 所需的预处理张量——其中就包括预先生成wk_b的转置wk_b_pp供预填充路径直接使用。6.3 图构建build_deepseek2.cpp中的注意路径MLA 的图构建集中在 src/graphs/build_deepseek2.cpp其核心是build_deepseek2_tp_attention按 rank 拆分的注意力配合-sm graph使用。从文件头注释与代码可确认该路径要求 Flash Attention 开启且mla_attn 1否则直接GGML_ABORT见 src/graphs/build_deepseek2.cpp支持-sm graph/-sm attn模式下的张量并行切分wo按行切分、wk_b/wv_b按 head 切分split_dim2每 rank 只持有自己的 head 切片预填充优化路径pp_opt当mla_attn 1且 token 数 ≥ 128、KV 数 ≥ 1024 时见 src/graphs/build_deepseek2.cpp不采用 FlashMLA-3 的吸收路径而是从潜在缓存中物化出每 rank 的 K/V走标准 flash attention——这正是mla2/3能兼顾预填充性能的机制吸收路径FlashMLA-3解码时通过wv_b在压缩潜在缓存上直接投影absorb path见 src/graphs/build_deepseek2.cpp。此外该文件还体现了后续迭代的细节K 缓存支持 Hadamard 变换k_cache_hadamard与去 Hadamard 的融合 kernel以及khad_pretransformed标志此时 H 矩阵在初始化时已折叠进wv_b/wk_b_pp。6.4 MLA 支持的后续演进PR #180 之后MLA 相关优化在仓库中持续演进相关记录包括PR #246 Faster FlashMLA prompt processing加速 FlashMLA 预填充PR #260 FlashMLA-2: reduce compute buffer size (CUDA and CPU)PR #386 FlashMLA-3 for DeepSeek models on CUDAPR #409 Enable faster prompt processing with mainline llama.cpp GGUFs 等。讨论中 saood06 还提到一个关于 Flash Attention 与 V 缓存量化的洞见非 FA 路径下 V 会被转置从而破坏量化块FA 路径下 V 不转置才允许对 V 做量化。因此让 Flash Attention 支持不同的 K/V head 尺寸是解锁 V 缓存量化MLA 模型当前实现按 MHA 的空间布局使用真正的 MLA 实现本应占用更少空间的前提。七、实战指南如何按场景选择 MLA 档位7.1 命令行使用在llama-server、llama-climain等工具中通过-mla或--mla-use指定档位# 使用 MLA取默认值 3即 best of both worlds ./llama-server -m deepseek-v3-Q4_K_S.gguf -mla 3 -fa on # 显式关闭 MLA走标准注意力 ./llama-server -m deepseek-v3-Q4_K_S.gguf -mla 0 # 基准测试中对比各档位 ./llama-bench -m deepseek-v3-Q4_K_S.gguf -mla 0 -mla 1 -mla 37.2 场景选择建议基于 PR #180/#188 的实测结论使用场景推荐档位理由长 prompt 一次性生成少量 token-mla 0保留标准注意力的预填充速度长上下文 长生成如 DeepSeek-R1 推理链-mla 3解码阶段 TG 提升最明显上下文越长收益越大内存敏感、希望最小化 KV 缓存-mla 2/-mla 3仅缓存潜在表示大幅降低 KV 内存需要注意的前提MLA 档位是实验性参数见 include/llama.h不同版本的默认值与行为可能变化若模型 GGUF 未包含wk_b/wk_v张量即使指定-mla也会被自动降级为标准注意力-sm graph配合 MLA 架构要求同时开启-faFlash Attention与-mla 1CPU 上 MLA 各档位的表现与是否使用量化 K 缓存如--cache-type-k的 q6_0/q8_0相关PR #180 的补充测试显示这些组合会影响 PP/TG 的绝对数值但不改变PP 慢、TG 快的整体格局。八、结语PR #180 及其后续演进是 ik_llama.cpp 在 MLA 优化上的一段完整技术历程一次直接的移植带来了可观的解码加速却也因 3 倍乘加量让预填充性能回退维护者通过逐算子剖析与 madds 数学分析定位了根因最终没有选择一刀切而是把 MLA 做成可选的-mla参数让用户在 PP 与 TG 之间按需取舍。这一过程在仓库源码中留下了清晰痕迹——从 src/graphs/build_deepseek2.cpp 的pp_opt与 FlashMLA-3 吸收路径到 common/common.h 中mla_attn的四档设计再到后续 FlashMLA-2/3 的持续优化构成了理解 DeepSeek 系列模型在 ggml 生态中高性能推理实现的完整图景。【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考