ik_llama.cpp 的 IQ4_XS_R4 提速实录AVX2 上的交错行量化优化与 8 行实验【免费下载链接】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 #143「Slightly faster IQ4_XS_R4 on AVX2」。它记录了 i/k 类量化super-block block 两级结构、两级 scale在 AVX2 上通过交错行interleaved rows策略获得约 5.6% 提示处理prefill提速的过程并详细讨论了交错 4 行 vs 交错 8 行在不同指令集AVX2 / Zen4 / ARM_NEON之间的性能与实现复杂度权衡。读完本文你将理解IQ4_XS_R8原名IQ4_XS_R4这类交错行量化类型的来龙去脉、它与普通IQ4_XS的性能差距、以及当前仓库中该类型对应的源码位置与量化路径。一、背景R4 量化家族与交错行策略ik_llama.cpp 是一份以附加 SOTA 量化类型与更高性能为特色的 llama.cpp 分支。其量化生态中存在一批以_R4结尾的类型Q4_0_R4、Q8_0_R4、IQ4_NL_X4、IQ4_XS_R4、Q4_K_R4、Q5_K_R4、Q6_K_R4等统称R4 量化。_R4后缀的含义是在矩阵乘法尤其是 prompt processing 阶段的矩阵乘中一次交错处理4 行数据从而提升 SIMD 向量化的数据复用效率。为什么对 i-quants / k-quants 做交错行尤其有挑战正如 PR #123 所描述的IQ4_XS这类类型具有super-block 与 block 两级结构、两级 scale交错处理 4 行时为 4 行同时洗牌 scale 位是一件非常繁琐的工作shuffling scale bits for 4 rows at once is tricky。PR #143 正是在这一系列尝试的中间节点上针对 AVX2 的又一次小步优化。二、PR #143 核心内容AVX2 上的小幅提速PR #143 的改动目标非常明确让IQ4_XS_R4在 AVX2 上再快一点点。作者 ikawrakow 给出的实测结果是PPL-512LLaMA-3.1-8B在 Ryzen-5975WX 上从248.2 t/s 提升到 262.2 t/s。这是一个约5.6%的提示处理吞吐提升512 token 提示长度下的 perplexity 基准。注意这里的背景是在此之前 PR #123 已经让 AVX2 上的IQ4_XS_R4相比普通IQ4_XS拿到了约 1.272× 的提速195.20 → 248.25 t/sPR #128 / #131 又在 Zen4 上分别把数值推到 254 t/s 并再提速 1-2%。因此 PR #143 是在已经很高的基数上继续挤压 SIMD 流水线的收益。三、关键实验交错 8 行R8vs 交错 4 行R4PR #143 文档中记录了作者在同一时期对交错 8 行方案的实验对应实验分支ik/iq4_xs_r8结果很有信息量平台交错 4 行R4交错 8 行R8 实验分支Zen4Ryzen-7950X约 254 t/s284 t/sAVX2Ryzen-5975WX262.2 t/s275 t/s结论是在 AVX2/Zen4 上交错 8 行明显更好Zen4 上比 4 行再快约 12%AVX2 上再快约 5%。但作者最终选择暂不切换到 8 行理由有二ARM_NEON 实现会变得极其混乱extremely messy在 ARM_NEON 上性能反而下降约 1-2%。这正是 SIMD 优化中典型的平台权衡x86 的 AVX2/AVX-512 与 ARM 的 NEON 在寄存器宽度、lane 布局、可用指令如vzip/vuzp类的向量交织指令上差异巨大一个平台友好的数据布局在另一个平台上可能是灾难。作者当时的决定是暂时坚持 4 行交错。后记8 行方案最终落地与重命名值得注意的是这个 8 行方向并没有被放弃。后续 PR #178「Interleave 8 rows (Q8_0, IQ4_XS)」中作者找到了一个ARM_NEON 上不比 4 行慢、甚至略快的 8 行实现并在 Ryzen-7950X 上让IQ4_XS的提示处理突破300 t/sprompt 小于 1000 token 时。随后 PR #189 将q4_0_r4、q8_0_r4、iq4_xs_r4正式重命名为_r8以反映其实际交错行数。因此当前仓库中已经没有IQ4_XS_R4取而代之的是IQ4_XS_R8——这就是 PR #143 中那套 4 行交错实现经过系列演进后的最终形态。四、源码级验证当前仓库中的 IQ4_XS_R8在今天的仓库中IQ4_XS_R8已作为正式量化类型全面接入。以下是可直接查阅的关键落点GGML 张量类型GGML_TYPE_IQ4_XS_R8定义于 ggml/include/ggml.h是 GGUF 张量层面对应的原始类型。GGUF 文件类型映射在 src/llama-model-loader.cpp 中GGML_TYPE_IQ4_XS_R8被映射为LLAMA_FTYPE_MOSTLY_IQ4_XS_R8值为 230见 include/llama.h。人类可读名称与 bpw在 src/llama-model.cpp 中该文件类型显示为IQ4_XS_R8 - 4.25 bpw即每权重 4.25 bit与普通IQ4_XS保持一致。量化 / 重量化路径src/llama-quantize.cpp 记录了IQ4_XS → IQ4_XS_R8的量化映射src/llama-quantize.cpp 则记录了文件类型层面的转换规则LLAMA_FTYPE_MOSTLY_IQ4_XS → LLAMA_FTYPE_MOSTLY_IQ4_XS_R8说明模型可以按需在线转换或重新打包。从源码结构可以推断IQ4_XS_R8与普通IQ4_XS共享相同的位宽与精度设计4.25 bpw、同样的 super-block/block 两级 scale差异完全在于内存中的行交错布局与对应的矩阵乘内核——这正是性能收益的来源也是 PR #123 / #143 / #178 一系列内核工作的核心。五、提速路线图从 IQ4_XS 到 IQ4_XS_R8 的关键节点把 PR #143 放回完整演进序列中可以更清楚地看到每一步的增量。以下数据均出自各 PR 当时的实测模型为 LLaMA-3.1-8BPP-512节点平台数值说明普通IQ4_XSAVX2Ryzen-5975WX, 32 线程195.20 t/sPR #123 基准普通IQ4_XSZen4Ryzen-7950X, 16 线程183.43 t/sPR #123 基准普通IQ4_XSARM_NEONM2-Max, 8 线程68.23 t/sPR #123 基准IQ4_XS_R4首版AVX2248.25 t/s1.272×PR #123IQ4_XS_R4首版Zen4223.98 t/s1.221×PR #123IQ4_XS_R4首版ARM_NEON115.43 t/s1.692×PR #123NEON 收益最大Zen4 优化Zen4224 → 254 t/sPR #128小幅再优化Zen41-2%PR #131AVX2 小幅优化AVX2248.2 → 262.2 t/s5.6%PR #143本文主题8 行实验分支Zen4 / AVX2284 / 275 t/sPR #143 提及、PR #178 落地值得注意的两个规律ARM_NEON 从 R4 布局中获益最大首版即 1.692×而 x86 平台收益相对温和约 1.2-1.3×提示处理PP的收益远大于 token 生成TG——PR #135 的数据显示TG 场景提速普遍只有 2-12%且线程数越高收益越小最终被内存带宽完全束缚。六、底层原理两个关键的加速技巧贯穿这一系列 PR 的是两个可复用的 SIMD 优化思想6.1 整数累加器避免 int → float 转换PR #135ARM_NEON与 PR #139Zen4先后引入了同一技巧在 super-block 内部用int32_t累加点积结果从而避开昂贵的int → float转换指令。有趣的是PR #139 提到作者最初犹豫不决因为 Intel 指令集手册显示_mm256_mullo_epi32()的延迟极高但实测证明尽管整数乘法延迟高整体反而更快。这正是 ARM 上已验证、x86 上再验证的跨平台经验迁移。6.2 数据布局层面的行交错交错行的本质是改变矩阵在内存中的排列方式使一次向量化访存能同时服务多行的点积计算提高寄存器复用率、降低内存指令开销。这个收益与 SIMD 宽度、L1 cache 行大小强相关因此呈现出明显的平台差异——x86 偏好 8 行、ARM 在 4 行与 8 行间需要精心设计才能不倒退这正是 PR #143 决策的核心。七、实用建议如何在自己的模型上使用如果你希望复现或使用这套优化确认量化类型存在当前仓库支持IQ4_XS_R84.25 bpw可通过llama-quantize或llama-gguf相关工具将IQ4_XS模型转换为交错行布局转换映射见 src/llama-quantize.cpp。评估平台收益预期收益按平台排序约为 ARM_NEON Zen4/AVX2且主要体现在长 prompt 的提示处理阶段token 生成阶段TG收益有限线程数高时几乎无差。性能基准使用llama-bench见 examples/llama-bench分别测普通IQ4_XS与IQ4_XS_R8的pp512/tg128对照本系列 PR 中PP 显著、TG 轻微的规律。注意兼容性从 PR #178 的讨论可以确认交错行布局是类型级的差异——IQ4_XS_R8模型只能被支持该内核的构建加载运行期重打包repack可以从Q8_0/IQ4_XS在线生成但旧版_R4命名的模型文件在新构建中不再适用。八、总结PR #143 是 ik_llama.cpp 交错行量化演进史中的一个缩影它不引入新概念而是在既有 4 行交错基础上为 AVX2 再挤出 5.6% 的提示处理性能同时忠实记录了8 行交错在 x86 上更优、在 ARM 上实现代价过高的平台权衡过程。这条线索最终演化为今天仓库中的IQ4_XS_R8类型——一个 4.25 bpw、为矩阵乘向量化而生的交错行量化格式。理解这段历史有助于开发者判断在什么平台上、什么任务PP vs TG下交错行量化值得启用。【免费下载链接】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 的 IQ4_XS_R4 提速实录：AVX2 上的交错行量化优化与 8 行实验
ik_llama.cpp 的 IQ4_XS_R4 提速实录AVX2 上的交错行量化优化与 8 行实验【免费下载链接】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 #143「Slightly faster IQ4_XS_R4 on AVX2」。它记录了 i/k 类量化super-block block 两级结构、两级 scale在 AVX2 上通过交错行interleaved rows策略获得约 5.6% 提示处理prefill提速的过程并详细讨论了交错 4 行 vs 交错 8 行在不同指令集AVX2 / Zen4 / ARM_NEON之间的性能与实现复杂度权衡。读完本文你将理解IQ4_XS_R8原名IQ4_XS_R4这类交错行量化类型的来龙去脉、它与普通IQ4_XS的性能差距、以及当前仓库中该类型对应的源码位置与量化路径。一、背景R4 量化家族与交错行策略ik_llama.cpp 是一份以附加 SOTA 量化类型与更高性能为特色的 llama.cpp 分支。其量化生态中存在一批以_R4结尾的类型Q4_0_R4、Q8_0_R4、IQ4_NL_X4、IQ4_XS_R4、Q4_K_R4、Q5_K_R4、Q6_K_R4等统称R4 量化。_R4后缀的含义是在矩阵乘法尤其是 prompt processing 阶段的矩阵乘中一次交错处理4 行数据从而提升 SIMD 向量化的数据复用效率。为什么对 i-quants / k-quants 做交错行尤其有挑战正如 PR #123 所描述的IQ4_XS这类类型具有super-block 与 block 两级结构、两级 scale交错处理 4 行时为 4 行同时洗牌 scale 位是一件非常繁琐的工作shuffling scale bits for 4 rows at once is tricky。PR #143 正是在这一系列尝试的中间节点上针对 AVX2 的又一次小步优化。二、PR #143 核心内容AVX2 上的小幅提速PR #143 的改动目标非常明确让IQ4_XS_R4在 AVX2 上再快一点点。作者 ikawrakow 给出的实测结果是PPL-512LLaMA-3.1-8B在 Ryzen-5975WX 上从248.2 t/s 提升到 262.2 t/s。这是一个约5.6%的提示处理吞吐提升512 token 提示长度下的 perplexity 基准。注意这里的背景是在此之前 PR #123 已经让 AVX2 上的IQ4_XS_R4相比普通IQ4_XS拿到了约 1.272× 的提速195.20 → 248.25 t/sPR #128 / #131 又在 Zen4 上分别把数值推到 254 t/s 并再提速 1-2%。因此 PR #143 是在已经很高的基数上继续挤压 SIMD 流水线的收益。三、关键实验交错 8 行R8vs 交错 4 行R4PR #143 文档中记录了作者在同一时期对交错 8 行方案的实验对应实验分支ik/iq4_xs_r8结果很有信息量平台交错 4 行R4交错 8 行R8 实验分支Zen4Ryzen-7950X约 254 t/s284 t/sAVX2Ryzen-5975WX262.2 t/s275 t/s结论是在 AVX2/Zen4 上交错 8 行明显更好Zen4 上比 4 行再快约 12%AVX2 上再快约 5%。但作者最终选择暂不切换到 8 行理由有二ARM_NEON 实现会变得极其混乱extremely messy在 ARM_NEON 上性能反而下降约 1-2%。这正是 SIMD 优化中典型的平台权衡x86 的 AVX2/AVX-512 与 ARM 的 NEON 在寄存器宽度、lane 布局、可用指令如vzip/vuzp类的向量交织指令上差异巨大一个平台友好的数据布局在另一个平台上可能是灾难。作者当时的决定是暂时坚持 4 行交错。后记8 行方案最终落地与重命名值得注意的是这个 8 行方向并没有被放弃。后续 PR #178「Interleave 8 rows (Q8_0, IQ4_XS)」中作者找到了一个ARM_NEON 上不比 4 行慢、甚至略快的 8 行实现并在 Ryzen-7950X 上让IQ4_XS的提示处理突破300 t/sprompt 小于 1000 token 时。随后 PR #189 将q4_0_r4、q8_0_r4、iq4_xs_r4正式重命名为_r8以反映其实际交错行数。因此当前仓库中已经没有IQ4_XS_R4取而代之的是IQ4_XS_R8——这就是 PR #143 中那套 4 行交错实现经过系列演进后的最终形态。四、源码级验证当前仓库中的 IQ4_XS_R8在今天的仓库中IQ4_XS_R8已作为正式量化类型全面接入。以下是可直接查阅的关键落点GGML 张量类型GGML_TYPE_IQ4_XS_R8定义于 ggml/include/ggml.h是 GGUF 张量层面对应的原始类型。GGUF 文件类型映射在 src/llama-model-loader.cpp 中GGML_TYPE_IQ4_XS_R8被映射为LLAMA_FTYPE_MOSTLY_IQ4_XS_R8值为 230见 include/llama.h。人类可读名称与 bpw在 src/llama-model.cpp 中该文件类型显示为IQ4_XS_R8 - 4.25 bpw即每权重 4.25 bit与普通IQ4_XS保持一致。量化 / 重量化路径src/llama-quantize.cpp 记录了IQ4_XS → IQ4_XS_R8的量化映射src/llama-quantize.cpp 则记录了文件类型层面的转换规则LLAMA_FTYPE_MOSTLY_IQ4_XS → LLAMA_FTYPE_MOSTLY_IQ4_XS_R8说明模型可以按需在线转换或重新打包。从源码结构可以推断IQ4_XS_R8与普通IQ4_XS共享相同的位宽与精度设计4.25 bpw、同样的 super-block/block 两级 scale差异完全在于内存中的行交错布局与对应的矩阵乘内核——这正是性能收益的来源也是 PR #123 / #143 / #178 一系列内核工作的核心。五、提速路线图从 IQ4_XS 到 IQ4_XS_R8 的关键节点把 PR #143 放回完整演进序列中可以更清楚地看到每一步的增量。以下数据均出自各 PR 当时的实测模型为 LLaMA-3.1-8BPP-512节点平台数值说明普通IQ4_XSAVX2Ryzen-5975WX, 32 线程195.20 t/sPR #123 基准普通IQ4_XSZen4Ryzen-7950X, 16 线程183.43 t/sPR #123 基准普通IQ4_XSARM_NEONM2-Max, 8 线程68.23 t/sPR #123 基准IQ4_XS_R4首版AVX2248.25 t/s1.272×PR #123IQ4_XS_R4首版Zen4223.98 t/s1.221×PR #123IQ4_XS_R4首版ARM_NEON115.43 t/s1.692×PR #123NEON 收益最大Zen4 优化Zen4224 → 254 t/sPR #128小幅再优化Zen41-2%PR #131AVX2 小幅优化AVX2248.2 → 262.2 t/s5.6%PR #143本文主题8 行实验分支Zen4 / AVX2284 / 275 t/sPR #143 提及、PR #178 落地值得注意的两个规律ARM_NEON 从 R4 布局中获益最大首版即 1.692×而 x86 平台收益相对温和约 1.2-1.3×提示处理PP的收益远大于 token 生成TG——PR #135 的数据显示TG 场景提速普遍只有 2-12%且线程数越高收益越小最终被内存带宽完全束缚。六、底层原理两个关键的加速技巧贯穿这一系列 PR 的是两个可复用的 SIMD 优化思想6.1 整数累加器避免 int → float 转换PR #135ARM_NEON与 PR #139Zen4先后引入了同一技巧在 super-block 内部用int32_t累加点积结果从而避开昂贵的int → float转换指令。有趣的是PR #139 提到作者最初犹豫不决因为 Intel 指令集手册显示_mm256_mullo_epi32()的延迟极高但实测证明尽管整数乘法延迟高整体反而更快。这正是 ARM 上已验证、x86 上再验证的跨平台经验迁移。6.2 数据布局层面的行交错交错行的本质是改变矩阵在内存中的排列方式使一次向量化访存能同时服务多行的点积计算提高寄存器复用率、降低内存指令开销。这个收益与 SIMD 宽度、L1 cache 行大小强相关因此呈现出明显的平台差异——x86 偏好 8 行、ARM 在 4 行与 8 行间需要精心设计才能不倒退这正是 PR #143 决策的核心。七、实用建议如何在自己的模型上使用如果你希望复现或使用这套优化确认量化类型存在当前仓库支持IQ4_XS_R84.25 bpw可通过llama-quantize或llama-gguf相关工具将IQ4_XS模型转换为交错行布局转换映射见 src/llama-quantize.cpp。评估平台收益预期收益按平台排序约为 ARM_NEON Zen4/AVX2且主要体现在长 prompt 的提示处理阶段token 生成阶段TG收益有限线程数高时几乎无差。性能基准使用llama-bench见 examples/llama-bench分别测普通IQ4_XS与IQ4_XS_R8的pp512/tg128对照本系列 PR 中PP 显著、TG 轻微的规律。注意兼容性从 PR #178 的讨论可以确认交错行布局是类型级的差异——IQ4_XS_R8模型只能被支持该内核的构建加载运行期重打包repack可以从Q8_0/IQ4_XS在线生成但旧版_R4命名的模型文件在新构建中不再适用。八、总结PR #143 是 ik_llama.cpp 交错行量化演进史中的一个缩影它不引入新概念而是在既有 4 行交错基础上为 AVX2 再挤出 5.6% 的提示处理性能同时忠实记录了8 行交错在 x86 上更优、在 ARM 上实现代价过高的平台权衡过程。这条线索最终演化为今天仓库中的IQ4_XS_R8类型——一个 4.25 bpw、为矩阵乘向量化而生的交错行量化格式。理解这段历史有助于开发者判断在什么平台上、什么任务PP vs TG下交错行量化值得启用。【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
