ik_llama.cpp CPU Flash Attention 中 Q8_0 KV Cache 重打包的取舍PR #315 实验复盘【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp导读本文以 ik_llama.cpp 仓库中编号 #315 的拉取请求Try not repacking q8_0 for FA computations为核心线索系统梳理 CPU 后端 Flash Attention 计算前将Q8_0K Cache 重打包为行交错格式Q8_0_R8的动机、触发条件、实现细节与性能代价。读完本文你将理解重打包在 prompt processingPP与 token generationTG两个阶段的不同影响、为什么大上下文场景下额外内存分配会成为瓶颈以及如何在多路 CPU / 大模型场景下复现并评估这一优化开关的收益。背景Q8_0 KV Cache 与行交错 Q8_0_R8在 ik_llama.cpp 中KV Cache 的量化类型由 参数-ctk/-ctv控制例如-ctk q8_0 -ctv q8_0。其中Q8_0是标准的 8-bit 块量化每 32 个元素共享一个 fp16 scale而Q8_0_R8是 ik_llama.cpp 引入的行交错row-interleaved变体它将连续 8 行row的量化数据交错排布并把 8 行的 scale 打包在一起从而让 SIMD 计算尤其是 AVX2/AVX-512 下的矩阵乘与 Flash Attention在读取数据时拥有更好的内存访问模式。从源码中的重打包映射表可以清楚看到这一对应关系ggml/src/iqk/iqk_quantize.cppconst Repack * get_repack_info(ggml_type type) { static const std::unordered_mapggml_type, Repack k_map { ... { GGML_TYPE_Q8_0, { GGML_TYPE_Q8_0_R8, 8, (Repack::repack_func)repack_q8_0} }, { GGML_TYPE_Q8_K, { GGML_TYPE_Q8_K_R8, 8, (Repack::repack_func)repack_q8_k} }, { GGML_TYPE_Q8_KV, { GGML_TYPE_Q8_KV_R8, 8, (Repack::repack_func)repack_q8_KV} }, ... }; }该表中num_rows 8表示每 8 行一组进行交错。Q8_0_R8与Q8_0的行大小一致见下文源码中row_size ggml_row_size(GGML_TYPE_Q8_0, nek0)因此重打包不会改变缓存占用的总体字节数只是改变了内存中的数据排布。重打包的触发条件与实现细节在 CPU 后端 Flash Attention 的实现中重打包并非无条件执行。关键代码位于 ggml/src/iqk/iqk_flash_attn.cppint int_type_k int_type_k_in; auto work_buffer work_buffer_in; if (neq1 8) { uint64_t row_size 0; work_buffer iqk_repack_k(int_type_k, Dk, nek1, nek2, nek3, stride_k, nbk2, nbk3, k, work_buffer_in, ith, nth, int_type_k, row_size); if (int_type_k ! int_type_k_in) { stride_k row_size; nbk2 stride_k*nek1; nbk3 nbk2*nek2; k work_buffer_in; barrier(barrier_data); } } //uint64_t row_size 0; //auto work_buffer iqk_repack_k(int_type_k, Dk, nek1, nek2, nek3, stride_k, nbk2, nbk3, k, work_buffer_in, ith, nth, int_type_k, row_size); //if (int_type_k ! int_type_k_in) { // stride_k row_size; // ... //}这段代码揭示了三个重要事实只对 PPprompt processing生效重打包外层条件是neq1 8即当前 batch 的 token 数不少于 8。TG 阶段 batch 通常为 1因此永远不会触发重打包——PR 文档中作者也明确说明 the repacking is not done for TG。PR #315 的改动本质下方被注释掉的代码就是该 PR 的改动内容——无条件调用iqk_repack_k而上方保留的是仅当neq1 8时才重打包的 master 行为。也就是说PR #315 试图通过直接注释掉该调用来观察完全跳过重打包的效果。重打包在计算工作缓冲区内进行work_buffer同时充当重打包的输出目标重打包后的 K 数据会被后续 Flash Attention 计算线程消费。iqk_repack_k的具体实现在 ggml/src/iqk/iqk_mul_mat.cpp声明见 ggml/src/iqk/iqk_flash_impl.h。其内部逻辑为仅当type_k GGML_TYPE_Q8_0且nek0 % QK8_0 0时才做转换否则原样返回要求 K 的总行数nrows nek1*nek2*nek3能被 8 整除以 8 行为一个处理单元将 8 行的量化系数d收集到block_q8_0_r8的d[8]中并用 AVX2 指令_mm256_unpacklo/hi_epi32/64等对 8 行的qs数据做跨行交织多线程并行每个线程处理8*((nrows/8 nth - 1)/nth)行的一个分片。从源码结构可以推断Q8_0_R8的加速本质在于Flash Attention 需要对同一位置的 8 行 K 数据做点积交错后一次 SIMD load 即可拿到多行所需的数据减少了缓存未命中与 shuffle 开销。PR #315 的核心动机大 K Cache 下的内存代价PR 描述中指出master 分支在 K Cache 为Q8_0时会在 Flash Attention 计算前将其重打包为Q8_0_R8。这一策略在 K Cache 规模不大时通常能提升 PP 性能但存在一个隐性代价重打包需要一块与 K Cache 规模相当的工作内存作为输出目标当上下文很长例如 32k 甚至更长时K Cache 本身可能高达数百 MiB 甚至数 GiB额外分配这块内存会带来显著的内存分配/页面故障开销这种开销可能抵消甚至反超重打包带来的计算加速导致 PP 性能下降。该 PR 的标题 Try not repacking q8_0 for FA computations 正是对这一问题的直接回应——关闭 CPU Flash Attention 中的 K Cache 重打包将其作为一个实验性分支供社区在Q8_0 KV cache 大上下文场景下测试。值得强调的是正如作者在描述中所言由于 TG 阶段从不重打包TG 性能的变化纯粹来自 PP 阶段那次较大的内存分配的副作用——这解释了为何一个看似只影响 PP 的改动实测中 TG 吞吐也会随之波动。实测结果不同硬件上结论并不一致作者的 DeepSeek-Lite 实验作者在 PR 描述中给出了两组自测结论模型为 DeepSeek-Lite上下文 32k tokens平台PP 性能变化TG 性能变化Ryzen-5975WX基本持平约 15%Ryzen-7950X约-15%明显变差基本持平两组结论几乎相反作者因此评价为 inconclusive结论不明确。另一项附带观察是在 Ryzen-7950X 上离线重打包与运行时重打包模型权重没有差别而在 Ryzen-5975WX 上使用离线重打包的模型在 32k 上下文下 TG 与 PP 均约有 10% 的提升。这表明重打包的性能收益与 CPU 微架构内存带宽、SIMD 指令吞吐、NUMA 拓扑强相关无法一概而论。社区的 Xeon 6980P DeepSeek-V3-0324 验证社区成员 ubergarm 在单路 Intel Xeon 6980P88 物理核上用 DeepSeek-V3-0324 的 IQ3_K_R4 量化模型做了对照实验变量仅为是否重打包 K Cache。其结论是至少在 V3-0324 这个量化模型上重打包对 PP 和 TG 在 32k 上下文以内整体上都是更优的。作者对此回应 So this does not explain it either说明社区数据仍无法解释此前观察到的性能低谷现象。该实验中还有一个耐人寻味的细节TG 吞吐在相同的上下文位置出现尖峰/低谷通过减少线程数可以移动这些峰的位置。结合 Xeon 6980P 单 socket 由 3 个物理 compute die434342 核配置为单一 NUMA 节点的特殊拓扑可以推断这些性能波动与线程调度、内存带宽竞争有关而非重打包本身。复现方法llama-sweep-bench 完整命令与参数解析PR 文档中给出了完整的复现命令这也是 examples/sweep-bench/sweep-bench.cpp 的典型用法。sweep-bench 会固定 PP batch 与 TG batch逐步增大已有 KV Cache 长度N_KV 从 0 扫到接近 n_ctx从而得到性能随上下文增长的曲线numactl -N 0 -m 0 \ ./build/bin/llama-sweep-bench \ --model /path/to/DeepSeek-V3-0324-CPU-IQ3_K_R4.gguf \ --no-mmap \ -ctk q8_0 \ -mla 3 -fa \ -amb 1024 \ -fmoe \ -c 32768 \ -ub 512 \ --threads 88 \ --threads-batch 128 \ --numa numactl各关键参数的作用如下与运行日志中的llama_new_context_with_model输出一一对应参数含义该实验中取值-ctk q8_0K Cache 量化类型详见 docs/parameters.mdq8_0实验的核心变量-mla 3MLAMulti-head Latent Attention优化级别3日志mla_attn 3-fa启用 Flash Attention1-amb 1024attention 的最大 batch 大小1024日志attn_max_b 1024-fmoe启用融合的 MoE专家混合计算1-c 32768上下文长度32768-ub 512单次 ubatch 大小512日志n_ubatch 512--threads 88 / --threads-batch 128计算线程数 / batch 计算线程数88 / 128--numa numactl使用 numactl 绑定 NUMA 节点-N 0 -m 0该测试使用的模型元数据来自日志也值得关注DeepSeek-V3-032461 层128 头kv_lora_rank 512context_length 163840模型文件为 IQ3_K_R4 量化约 4.14 BPW324 GiB。在此配置下32k 上下文的 K Cache 大小为 1166.62 MiB日志KV self size 1166.62 MiB, c^KV (q8_0): 1166.62 MiBcompute buffer 为 2662.01 MiB。重打包所需的工作缓冲区与 K Cache 同量级——这正是作者担心的相当可观的内存分配。sweep-bench 的输出表格结构如下节选自 Xeon 6980P 实验PP batch 512、TG batch 128PPTGN_KVT_PP sS_PP t/sT_TG sS_TG t/s51212804.785107.0112.24110.4651212840967.97364.2214.4038.895121281638416.07331.8522.1575.785121283225626.57919.2629.2004.38可以看到随着 N_KV 从 0 增长到 32kPP 吞吐从 107 t/s 平滑衰减到约 19 t/sTG 从 10.46 t/s 衰减到约 4.4 t/s——这与 Flash Attention 计算量随 KV 长度线性增长的理论一致。而是否重打包造成的差异约 5%15% 量级远小于上下文长度带来的数量级差异因此评估时必须以同一条 N_KV 曲线做对照这正是 sweep-bench 的价值所在。结论与工程启示PR #315 最终于 2025-05-04 被作者关闭理由是 Doesnt look like it is useful看起来没有用。这一结论本身极具参考价值它告诉我们重打包不是纯粹的负担至少在 Xeon 6980P DeepSeek-V3-0324 的实测中重打包在 32k 上下文内对 PP 与 TG 均更优在部分 AMD 平台如 Ryzen-5975WX上关闭重打包也能获得 TG 收益说明结论高度依赖硬件。大上下文的内存代价是真实存在的重打包需要与 K Cache 同量级的额外工作内存超大模型 超长上下文的组合下这一分配可能成为 PP 性能的主要瓶颈——这也是作者最初发起该实验的动机。PP 与 TG 的性能并非独立一个仅作用于 PP 阶段的改动会通过内存分配副作用传导到 TG 吞吐评估任何 KV Cache 相关优化时都应将两个阶段一起测量。多平台验证的必要性同一个优化在 Ryzen-5975WX、Ryzen-7950X、Xeon 6980P 上给出了不同的结论任何关于 KV Cache 格式或重打包策略的推广都必须以目标硬件的实测为准。后续仓库中的相关演进例如 PR #391 Fix DeepSeek q8_0 cache、PR #364 Fix FA bug on AVX2、PR #291 Disable Zen4 optimizations for Q8_0_Q8_0_R8表明围绕Q8_0_R8与 CPU Flash Attention 的调优仍在持续。对于想要在自己的机器上验证取舍的读者推荐使用本文给出的llama-sweep-bench命令在目标模型、目标上下文长度下分别测量开启/关闭重打包的两条性能曲线再决定是否采用行交错 KV Cache 配置。【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ik_llama.cpp CPU Flash Attention 中 Q8_0 KV Cache 重打包的取舍PR #315 实验复盘【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp导读本文以 ik_llama.cpp 仓库中编号 #315 的拉取请求Try not repacking q8_0 for FA computations为核心线索系统梳理 CPU 后端 Flash Attention 计算前将Q8_0K Cache 重打包为行交错格式Q8_0_R8的动机、触发条件、实现细节与性能代价。读完本文你将理解重打包在 prompt processingPP与 token generationTG两个阶段的不同影响、为什么大上下文场景下额外内存分配会成为瓶颈以及如何在多路 CPU / 大模型场景下复现并评估这一优化开关的收益。背景Q8_0 KV Cache 与行交错 Q8_0_R8在 ik_llama.cpp 中KV Cache 的量化类型由 参数-ctk/-ctv控制例如-ctk q8_0 -ctv q8_0。其中Q8_0是标准的 8-bit 块量化每 32 个元素共享一个 fp16 scale而Q8_0_R8是 ik_llama.cpp 引入的行交错row-interleaved变体它将连续 8 行row的量化数据交错排布并把 8 行的 scale 打包在一起从而让 SIMD 计算尤其是 AVX2/AVX-512 下的矩阵乘与 Flash Attention在读取数据时拥有更好的内存访问模式。从源码中的重打包映射表可以清楚看到这一对应关系ggml/src/iqk/iqk_quantize.cppconst Repack * get_repack_info(ggml_type type) { static const std::unordered_mapggml_type, Repack k_map { ... { GGML_TYPE_Q8_0, { GGML_TYPE_Q8_0_R8, 8, (Repack::repack_func)repack_q8_0} }, { GGML_TYPE_Q8_K, { GGML_TYPE_Q8_K_R8, 8, (Repack::repack_func)repack_q8_k} }, { GGML_TYPE_Q8_KV, { GGML_TYPE_Q8_KV_R8, 8, (Repack::repack_func)repack_q8_KV} }, ... }; }该表中num_rows 8表示每 8 行一组进行交错。Q8_0_R8与Q8_0的行大小一致见下文源码中row_size ggml_row_size(GGML_TYPE_Q8_0, nek0)因此重打包不会改变缓存占用的总体字节数只是改变了内存中的数据排布。重打包的触发条件与实现细节在 CPU 后端 Flash Attention 的实现中重打包并非无条件执行。关键代码位于 ggml/src/iqk/iqk_flash_attn.cppint int_type_k int_type_k_in; auto work_buffer work_buffer_in; if (neq1 8) { uint64_t row_size 0; work_buffer iqk_repack_k(int_type_k, Dk, nek1, nek2, nek3, stride_k, nbk2, nbk3, k, work_buffer_in, ith, nth, int_type_k, row_size); if (int_type_k ! int_type_k_in) { stride_k row_size; nbk2 stride_k*nek1; nbk3 nbk2*nek2; k work_buffer_in; barrier(barrier_data); } } //uint64_t row_size 0; //auto work_buffer iqk_repack_k(int_type_k, Dk, nek1, nek2, nek3, stride_k, nbk2, nbk3, k, work_buffer_in, ith, nth, int_type_k, row_size); //if (int_type_k ! int_type_k_in) { // stride_k row_size; // ... //}这段代码揭示了三个重要事实只对 PPprompt processing生效重打包外层条件是neq1 8即当前 batch 的 token 数不少于 8。TG 阶段 batch 通常为 1因此永远不会触发重打包——PR 文档中作者也明确说明 the repacking is not done for TG。PR #315 的改动本质下方被注释掉的代码就是该 PR 的改动内容——无条件调用iqk_repack_k而上方保留的是仅当neq1 8时才重打包的 master 行为。也就是说PR #315 试图通过直接注释掉该调用来观察完全跳过重打包的效果。重打包在计算工作缓冲区内进行work_buffer同时充当重打包的输出目标重打包后的 K 数据会被后续 Flash Attention 计算线程消费。iqk_repack_k的具体实现在 ggml/src/iqk/iqk_mul_mat.cpp声明见 ggml/src/iqk/iqk_flash_impl.h。其内部逻辑为仅当type_k GGML_TYPE_Q8_0且nek0 % QK8_0 0时才做转换否则原样返回要求 K 的总行数nrows nek1*nek2*nek3能被 8 整除以 8 行为一个处理单元将 8 行的量化系数d收集到block_q8_0_r8的d[8]中并用 AVX2 指令_mm256_unpacklo/hi_epi32/64等对 8 行的qs数据做跨行交织多线程并行每个线程处理8*((nrows/8 nth - 1)/nth)行的一个分片。从源码结构可以推断Q8_0_R8的加速本质在于Flash Attention 需要对同一位置的 8 行 K 数据做点积交错后一次 SIMD load 即可拿到多行所需的数据减少了缓存未命中与 shuffle 开销。PR #315 的核心动机大 K Cache 下的内存代价PR 描述中指出master 分支在 K Cache 为Q8_0时会在 Flash Attention 计算前将其重打包为Q8_0_R8。这一策略在 K Cache 规模不大时通常能提升 PP 性能但存在一个隐性代价重打包需要一块与 K Cache 规模相当的工作内存作为输出目标当上下文很长例如 32k 甚至更长时K Cache 本身可能高达数百 MiB 甚至数 GiB额外分配这块内存会带来显著的内存分配/页面故障开销这种开销可能抵消甚至反超重打包带来的计算加速导致 PP 性能下降。该 PR 的标题 Try not repacking q8_0 for FA computations 正是对这一问题的直接回应——关闭 CPU Flash Attention 中的 K Cache 重打包将其作为一个实验性分支供社区在Q8_0 KV cache 大上下文场景下测试。值得强调的是正如作者在描述中所言由于 TG 阶段从不重打包TG 性能的变化纯粹来自 PP 阶段那次较大的内存分配的副作用——这解释了为何一个看似只影响 PP 的改动实测中 TG 吞吐也会随之波动。实测结果不同硬件上结论并不一致作者的 DeepSeek-Lite 实验作者在 PR 描述中给出了两组自测结论模型为 DeepSeek-Lite上下文 32k tokens平台PP 性能变化TG 性能变化Ryzen-5975WX基本持平约 15%Ryzen-7950X约-15%明显变差基本持平两组结论几乎相反作者因此评价为 inconclusive结论不明确。另一项附带观察是在 Ryzen-7950X 上离线重打包与运行时重打包模型权重没有差别而在 Ryzen-5975WX 上使用离线重打包的模型在 32k 上下文下 TG 与 PP 均约有 10% 的提升。这表明重打包的性能收益与 CPU 微架构内存带宽、SIMD 指令吞吐、NUMA 拓扑强相关无法一概而论。社区的 Xeon 6980P DeepSeek-V3-0324 验证社区成员 ubergarm 在单路 Intel Xeon 6980P88 物理核上用 DeepSeek-V3-0324 的 IQ3_K_R4 量化模型做了对照实验变量仅为是否重打包 K Cache。其结论是至少在 V3-0324 这个量化模型上重打包对 PP 和 TG 在 32k 上下文以内整体上都是更优的。作者对此回应 So this does not explain it either说明社区数据仍无法解释此前观察到的性能低谷现象。该实验中还有一个耐人寻味的细节TG 吞吐在相同的上下文位置出现尖峰/低谷通过减少线程数可以移动这些峰的位置。结合 Xeon 6980P 单 socket 由 3 个物理 compute die434342 核配置为单一 NUMA 节点的特殊拓扑可以推断这些性能波动与线程调度、内存带宽竞争有关而非重打包本身。复现方法llama-sweep-bench 完整命令与参数解析PR 文档中给出了完整的复现命令这也是 examples/sweep-bench/sweep-bench.cpp 的典型用法。sweep-bench 会固定 PP batch 与 TG batch逐步增大已有 KV Cache 长度N_KV 从 0 扫到接近 n_ctx从而得到性能随上下文增长的曲线numactl -N 0 -m 0 \ ./build/bin/llama-sweep-bench \ --model /path/to/DeepSeek-V3-0324-CPU-IQ3_K_R4.gguf \ --no-mmap \ -ctk q8_0 \ -mla 3 -fa \ -amb 1024 \ -fmoe \ -c 32768 \ -ub 512 \ --threads 88 \ --threads-batch 128 \ --numa numactl各关键参数的作用如下与运行日志中的llama_new_context_with_model输出一一对应参数含义该实验中取值-ctk q8_0K Cache 量化类型详见 docs/parameters.mdq8_0实验的核心变量-mla 3MLAMulti-head Latent Attention优化级别3日志mla_attn 3-fa启用 Flash Attention1-amb 1024attention 的最大 batch 大小1024日志attn_max_b 1024-fmoe启用融合的 MoE专家混合计算1-c 32768上下文长度32768-ub 512单次 ubatch 大小512日志n_ubatch 512--threads 88 / --threads-batch 128计算线程数 / batch 计算线程数88 / 128--numa numactl使用 numactl 绑定 NUMA 节点-N 0 -m 0该测试使用的模型元数据来自日志也值得关注DeepSeek-V3-032461 层128 头kv_lora_rank 512context_length 163840模型文件为 IQ3_K_R4 量化约 4.14 BPW324 GiB。在此配置下32k 上下文的 K Cache 大小为 1166.62 MiB日志KV self size 1166.62 MiB, c^KV (q8_0): 1166.62 MiBcompute buffer 为 2662.01 MiB。重打包所需的工作缓冲区与 K Cache 同量级——这正是作者担心的相当可观的内存分配。sweep-bench 的输出表格结构如下节选自 Xeon 6980P 实验PP batch 512、TG batch 128PPTGN_KVT_PP sS_PP t/sT_TG sS_TG t/s51212804.785107.0112.24110.4651212840967.97364.2214.4038.895121281638416.07331.8522.1575.785121283225626.57919.2629.2004.38可以看到随着 N_KV 从 0 增长到 32kPP 吞吐从 107 t/s 平滑衰减到约 19 t/sTG 从 10.46 t/s 衰减到约 4.4 t/s——这与 Flash Attention 计算量随 KV 长度线性增长的理论一致。而是否重打包造成的差异约 5%15% 量级远小于上下文长度带来的数量级差异因此评估时必须以同一条 N_KV 曲线做对照这正是 sweep-bench 的价值所在。结论与工程启示PR #315 最终于 2025-05-04 被作者关闭理由是 Doesnt look like it is useful看起来没有用。这一结论本身极具参考价值它告诉我们重打包不是纯粹的负担至少在 Xeon 6980P DeepSeek-V3-0324 的实测中重打包在 32k 上下文内对 PP 与 TG 均更优在部分 AMD 平台如 Ryzen-5975WX上关闭重打包也能获得 TG 收益说明结论高度依赖硬件。大上下文的内存代价是真实存在的重打包需要与 K Cache 同量级的额外工作内存超大模型 超长上下文的组合下这一分配可能成为 PP 性能的主要瓶颈——这也是作者最初发起该实验的动机。PP 与 TG 的性能并非独立一个仅作用于 PP 阶段的改动会通过内存分配副作用传导到 TG 吞吐评估任何 KV Cache 相关优化时都应将两个阶段一起测量。多平台验证的必要性同一个优化在 Ryzen-5975WX、Ryzen-7950X、Xeon 6980P 上给出了不同的结论任何关于 KV Cache 格式或重打包策略的推广都必须以目标硬件的实测为准。后续仓库中的相关演进例如 PR #391 Fix DeepSeek q8_0 cache、PR #364 Fix FA bug on AVX2、PR #291 Disable Zen4 optimizations for Q8_0_Q8_0_R8表明围绕Q8_0_R8与 CPU Flash Attention 的调优仍在持续。对于想要在自己的机器上验证取舍的读者推荐使用本文给出的llama-sweep-bench命令在目标模型、目标上下文长度下分别测量开启/关闭重打包的两条性能曲线再决定是否采用行交错 KV Cache 配置。【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
