尧图网站建设 ` 崩溃到修复与性能验证)
ik_llama.cpp 运行时重打包-rtr实战从GGML_ASSERT(nrc_x%8 0)崩溃到修复与性能验证【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp运行时重打包run-time repacking命令行参数-rtr/--run-time-repack是 ik_llama.cpp 在模型加载阶段把常规量化张量原位转换为交错interleaved布局变体、从而解锁 IQK 加速内核的关键机制。本文以仓库 issue #230 记录的 Weird assert when using online repacking 故障为线索完整梳理该功能的实现原理、崩溃根因、修复验证过程以及复现基准测试的正确姿势帮助读者理解为什么-rtr既能带来明显的提示处理加速、又对张量行数有严格的整除约束。一、背景issue #230 到底发生了什么2025 年 2 月 24 日用户pt13762104在版本 3571commitac1d259b下使用运行时重打包加载 DeepSeek-Coder-V2-Lite-Instruct Q4_K_M 模型约 15.7B 参数Q4_K Medium9.65 GiB模型加载流程一路正常llama_model_loader成功解析 GGUF V3 元数据架构deepseek2、27 层、kv_lora_rank512、64 个专家expert_count、expert_used_count6等张量加载完成后打印 Repacked 268 tensors说明运行时重打包已生效268 个张量被原位转换为交错变体上下文初始化n_ctx512、n_batch512、n_ubatch512全部成功graph nodes 1474。但在首次真正执行矩阵乘法时进程立即崩溃且断言信息如雪崩般重复刷屏/root/ik_llama.cpp/ggml/src/iqk/iqk_mul_mat.cpp:4065: GGML_ASSERT(nrc_x%8 0) failed ... Aborted (core dumped)从调用栈可以清楚看到崩溃链路iqk_mul_mat_moe→ 内部 GEMM 路径 →ggml_abort。也就是说问题发生在 MoE 专家混合矩阵乘法iqk_mul_mat_moe进入按 8 行分块的交错量化内核时传入的行数nrc_x不满足 8 的整除约束。该 issue 当天即被修复维护者 ikawrakow 在评论区询问 Dose #231 fix it?用户升级到修复版本build 3572 / commit4f2cfd6e后确认 Its working now, thank you!并附上了修复前后的完整基准测试对比。二、-rtr运行时重打包它究竟在做什么2.1 什么是重打包ik_llama.cpp 在 ggml/src/iqk/iqk_quantize.cpp 中维护了一张从常规量化类型到交错变体类型的映射表原始类型重打包类型分块行数说明Q4_0Q4_0_R88按 8 行分块Q8_0Q8_0_R88按 8 行分块Q8_KQ8_K_R88按 8 行分块Q4_KQ4_K_R44按 4 行分块Q5_KQ5_K_R44按 4 行分块Q6_KQ6_K_R44按 4 行分块IQ4_XSIQ4_XS_R88按 8 行分块IQ2_K/IQ3_K/IQ4_K等对应_R4变体4按 4 行分块MXFP4MXFP4_R88按 8 行分块BF16/F16BF16_R1616仅__AVX512BF16__构建下启用重打包的本质是在不改变量化精度的前提下把原本按单行连续存储的量化数据重新排列成以 4、8 或 16 行为一组block的交错布局。这种布局让 SIMD 内核在加载数据时可以一次取得多行、跨行的量化块配合 AVX2/AVX-512 指令实现更高的内存吞吐与向量化效率——这正是 ik_llama.cpp 相对主线上游在 CPU 推理速度上形成差异的核心优化点之一。从源码结构看整个 ggml/src/iqk 目录下的iqk_gemm_*quants.cpp系列文件都围绕这种交错布局实现专用 GEMM 内核。2.2 两种重打包方式离线与运行时离线重打包使用llama-quantize工具的--only-repack选项见 src/llama-quantize.cpp 与repacked_ftype逻辑把模型文件直接改写成带_R4/_R8后缀类型的 GGUF。这种文件一次转换、永久使用但需要额外的磁盘空间与转换时间。运行时重打包-rtr在模型加载进内存后、首次推理前由llama_model_load遍历所有张量对位于 host 内存中的张量原位执行重打包见 src/llama.cpp。加载完成后打印的 Repacked 268 tensors正是这段代码的输出if (n_repacked 0) LLAMA_LOG_INFO( Repacked %d tensors\n, n_repacked);。-rtr是零成本试水手段不需要预先转换模型文件加载时自动判断每个张量是否有可用的交错变体iqk_repacked_type有就原位重打包没有就保持原样。正因为是原位in-place修改内存中的张量-rtr强制关闭 mmap——参数解析代码在 common/common.cpp 中明确if (arg -rtr || arg --run-time-repack) { params.repack_tensors true; params.use_mmap false; // 原位重打包需要可写的内存不能只读映射文件 return true; }这与 llama.cpp 其余可执行文件的入口llama_model_load通过params.repack_tensors传递给llama_model_loader见 src/llama.cpp形成完整调用链-rtr→repack_tensorstrue→ 非 mmap 加载 →iqk_repack_tensor原位转换。2.3 重打包的三个前置条件ggml/src/iqk/iqk_quantize.cpp 中iqk_repack_tensor的执行逻辑揭示了重打包的门槛void iqk_repack_tensor(struct ggml_tensor * tensor) { constexpr int kChunk 8; if (!tensor) return; if (!ggml_is_contiguous(tensor)) return; // 1. 必须连续 if (is_forbidden_tensor(tensor-name)) return; // 2. 禁止重打包 token_embd.weight 等 if (tensor-ne[1] % 4) return; // 3. 行数至少能被 4 整除 auto rptr get_repack_info(tensor-type); if (!rptr) return; if (tensor-ne[1] % rptr-num_rows) return; // 3. 行数必须能被分块行数整除 ... }也就是说只有当张量的行数ne[1]能被其对应交错变体的分块行数4/8/16整除时重打包才会真正发生。iqk_repacked_type见 ggml/src/iqk/iqk_quantize.cpp在决定是否重打包时也执行同样的整除检查。这里的关键在于同一个模型里不同张量的行数并不一致例如注意力权重通常按n_head或n_head_kv分块MoE 专家权重按n_expert分块因此重打包通常是部分张量——issue 日志里 268 个张量被重打包其余如仅 14 个q5_0、13 个q6_K张量等保持原类型正是这个原因。2.4 为什么不重打包的部分也需要兼容交错变体内核与常规内核在 SIMD 分块策略上的差异导致行数约束不一致常规量化类型的内核通常以 4 行为最小分块单位而_R8变体Q4_0_R8、Q8_0_R8等的 GEMM 路径要求行数能被 8 整除。这正是 issue #230 的崩溃现场修复前的iqk_mul_mat_moe在部分 MoE 专家张量保持未重打包原始类型时错误地沿用了按 8 行分块的代码路径导致nrc_x % 8 ! 0触发断言。修复对应 #231的本质就是让 MoE 混合矩阵乘法内核正确区分已重打包为_R8变体与仍为原始类型的张量对后者回退到按 4 行分块的兼容路径。今天我们在 ggml/src/iqk/iqk_mul_mat.cpp 与 ggml/src/iqk/iqk_mul_mat.h 中看到iqk_mul_mat_moe的公开接口它内部对每种量化类型分别选择匹配的 GEMM 实现正是这套类型感知分派机制的体现。顺带一提重打包后张量的类型从原始类型变为交错变体类型这意味着某些依赖原始布局的后续操作需要特殊处理。例如 src/llama-reload.cpp 在热切换hotswap时明确警告启用-rtr后被重打包的张量无法通过保存的状态精确还原恢复的张量可能与预期不一致F16 - BF16_R16甚至是有损的。因此-rtr更适合加载即用的推理场景而不是需要保存/恢复 KV 状态或做严格数值复现的实验场景。三、issue #230 的完整现场还原3.1 崩溃前模型元数据与重打包日志用户日志完整展示了 DeepSeek-Coder-V2-Lite-Instruct 的加载过程其中与本次崩溃直接相关的元数据包括deepseek2.expert_count 64、deepseek2.expert_used_count 6MoE 架构每 token 激活 6 个专家deepseek2.expert_feed_forward_length 1408、deepseek2.expert_shared_count 2专家 FFN 规模deepseek2.leading_dense_block_count 1前 1 层为稠密层张量类型分布f32108 个、q5_014 个、q8_013 个、q4_K229 个、q6_K13 个。注意q4_K有 229 个张量但重打包日志显示Repacked 268 tensors——这包含了q4_K → Q4_K_R4以及部分其他类型如f32的 MoE 相关权重等的转换。MoE 模型的专家权重张量行数通常等于专家数64乘以某系数而稠密层权重行数等于层内维度两类张量的行数差异正是部分重打包 混合路径分派成为必需的原因。3.2 崩溃点与调用栈解读/root/ik_llama.cpp/ggml/src/iqk/iqk_mul_mat.cpp:4065: GGML_ASSERT(nrc_x%8 0) failed ... /root/ik_llama.cpp/build/ggml/src/libggml.so(iqk_mul_mat_moe0x55a) /libgomp.so.1(0x227ce) ← OpenMP 线程池 /libc.so.6(__clone0x40) ← 线程创建 Aborted (core dumped)崩溃发生在OpenMP 并行线程内部栈底是libgomp与__clone说明iqk_mul_mat_moe已经把 MoE 专家计算分发到多个线程并行执行随后某个线程进入 GEMM 内核时发现行数不满足 8 整除。由于断言在GGML_ASSERT中直接调用ggml_abort对应libggml.so中的ggml_abort帧进程立即Aborted (core dumped)无任何恢复机会。3.3 修复后的验证用户升级到 3572 后问题消失随后给出了两组关键基准机器为 Kaggle 上的 2× Xeon 24 核共 48 线程配置测试结果未启用-rtrbuild 4f2cfd6epp512303.36 ± 29.58 t/s未启用-rtrtg12819.92 ± 0.07 t/s启用-rtrpp512393.53 ± 52.69 t/s启用-rtrtg12821.71 ± 0.16 t/s同样的 build、同样的机器仅增加-rtr开关提示处理pp512从约 303 t/s 提升到约 393 t/s约 30%token 生成tg128从 19.92 t/s 提升到 21.71 t/s约 9%。这组数据来自 issue 中用户实测它直观地说明运行时重打包对提示处理prompt processing受 GEMM 吞吐主导的收益远大于 token 生成受带宽与单 token 延迟主导——因为 pp 阶段的矩阵乘法密集程度远高于自回归解码阶段。维护者随后追问 CPU 型号并建议试试用更少线程跑 TG暗示在 48 线程这类高并发配置下token 生成的线程调度开销可能掩盖部分收益。需要说明的是这组数字是单个用户、单个模型、单台 Kaggle 机器上的实测不代表通用结论不同架构如 llama、qwen2、bitnet、不同量化类型、不同 CPU 上的收益差异可能很大建议读者在自己的硬件上以llama-bench实测为准见下文第四节。四、如何复现与验证4.1 正确复现崩溃现场历史版本若要复现 issue #230 的原始崩溃需要满足检出修复前的版本如 3571 /ac1d259b且构建时启用了 IQK 矩阵乘法路径使用 MoE 架构模型且模型中存在行数不被 8 整除、又会被送入iqk_mul_mat_moe的张量——DeepSeek-Coder-V2-Lite-Instruct Q4_K_M 即为一例以-rtr加载模型并触发首次推理。由于当前仓库已包含修复直接使用最新代码不会复现崩溃上述步骤仅用于历史版本对照。4.2 在当前版本上体验-rtr并验证性能构建参照 docs/install.md以 CMake 构建 CPU 版IQK 路径默认随构建启用cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j推理以llama-cli源码见 examples/main/main.cpp为例build/bin/llama-cli -m /path/to/model-Q4_K_M.gguf -rtr -p Hello, world -n 64也可以使用服务器examples/server/server.cpp或基准工具examples/llama-bench/llama-bench.cppbuild/bin/llama-bench -m /path/to/model-Q4_K_M.gguf -rtr -t 48加载日志中若出现 Repacked N tensors即表示重打包生效。用-rtr与不带-rtr各跑一轮llama-bench对比 pp 与 tg 的 t/s即可量化收益。4.3 常用相关参数速查与-rtr同属加载期内存优化家族的参数均可在llama-cli --help帮助文本见 common/common.cpp中查到参数说明备注-rtr, --run-time-repack有交错变体时原位重打包张量自动关闭 mmap--no-mmap不内存映射模型-rtr隐含开启-cmoe, --cpu-moe所有 MoE 权重保留在 CPU 内存与 GPU 卸载配合-ncmoe, --n-cpu-moe N前 N 层的 MoE 权重保留在 CPU部分卸载场景-thp, --transparent-huge-pagesLinux 下启用透明大页减少 TLB 缺失--defer-expertsLinux 下延迟专家 mmap 驻留缩短模型加载时间4.4 离线重打包--only-repack作为替代如果希望把重打包固化到模型文件、避免每次加载的开销可用 examples/quantize/quantize.cppbuild/bin/llama-quantize --only-repack input.gguf output.gguf逻辑见 src/llama-quantize.cpp遍历每个张量凡存在可用交错变体iqk_repacked_type返回新类型的逐一转换并写回新文件n_to_repack 0 n_to_modify 0时提示 nothing to do for only_repack option。与-rtr不同离线重打包后的文件可以直接 mmap 加载类型已固化在 GGUF 中代价是需要额外磁盘空间与一次性的转换时间。两种方式的取舍离线重打包适合确定要长期使用、追求 mmap 加载速度的生产场景-rtr适合快速试水、对比性能、不想占用额外磁盘的实验场景。五、经验总结与踩坑清单-rtr不等于无损魔法对大多数量化类型Q4_K → Q4_K_R4、Q8_0 → Q8_0_R8等重打包是数学等价的纯布局变换但F16 → BF16_R16是有损的且只在__AVX512BF16__构建下可用。行数整除约束是硬边界iqk_repack_tensor与iqk_repacked_type都要求ne[1]能被分块行数整除MoE 模型尤其容易出现部分张量重打包、部分保持原样的混合状态任何路径分派不当都会触发GGML_ASSERT(nrc_x%8 0)这类崩溃。issue #230 正是 MoE GEMM 路径在混合状态下分派错误的典型案例。-rtr与保存/恢复状态不兼容src/llama-reload.cpp 明确警告热切换恢复的张量无法复现重打包状态结果可能不一致涉及状态保存的实验请关闭-rtr。收益重点在提示处理从 issue 实测看pp 吞吐提升显著该案例约 30%tg 提升相对温和约 9%具体数字随模型、量化、CPU 而异务必用llama-bench自行基准。用Repacked N tensors判断生效加载日志出现该行才代表有张量被转换若未出现请检查模型量化类型是否在映射表见 ggml/src/iqk/iqk_quantize.cpp中、张量行数是否满足整除条件。六、延伸阅读运行时重打包的入口与参数解析common/common.cpp重打包执行与计数日志src/llama.cpp重打包类型映射表与实现ggml/src/iqk/iqk_quantize.cppMoE 混合矩阵乘法入口ggml/src/iqk/iqk_mul_mat.cpp热切换与-rtr的兼容性警告src/llama-reload.cpp离线重打包工具examples/quantize/quantize.cpp 与 src/llama-quantize.cpp相关 issue 原文github-data/issues/230 - Weird assert when using online repacking.md【免费下载链接】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 运行时重打包（-rtr）实战：从 `GGML_ASSERT(nrc_x%8 == 0)` 崩溃到修复与性能验证
ik_llama.cpp 运行时重打包-rtr实战从GGML_ASSERT(nrc_x%8 0)崩溃到修复与性能验证【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp运行时重打包run-time repacking命令行参数-rtr/--run-time-repack是 ik_llama.cpp 在模型加载阶段把常规量化张量原位转换为交错interleaved布局变体、从而解锁 IQK 加速内核的关键机制。本文以仓库 issue #230 记录的 Weird assert when using online repacking 故障为线索完整梳理该功能的实现原理、崩溃根因、修复验证过程以及复现基准测试的正确姿势帮助读者理解为什么-rtr既能带来明显的提示处理加速、又对张量行数有严格的整除约束。一、背景issue #230 到底发生了什么2025 年 2 月 24 日用户pt13762104在版本 3571commitac1d259b下使用运行时重打包加载 DeepSeek-Coder-V2-Lite-Instruct Q4_K_M 模型约 15.7B 参数Q4_K Medium9.65 GiB模型加载流程一路正常llama_model_loader成功解析 GGUF V3 元数据架构deepseek2、27 层、kv_lora_rank512、64 个专家expert_count、expert_used_count6等张量加载完成后打印 Repacked 268 tensors说明运行时重打包已生效268 个张量被原位转换为交错变体上下文初始化n_ctx512、n_batch512、n_ubatch512全部成功graph nodes 1474。但在首次真正执行矩阵乘法时进程立即崩溃且断言信息如雪崩般重复刷屏/root/ik_llama.cpp/ggml/src/iqk/iqk_mul_mat.cpp:4065: GGML_ASSERT(nrc_x%8 0) failed ... Aborted (core dumped)从调用栈可以清楚看到崩溃链路iqk_mul_mat_moe→ 内部 GEMM 路径 →ggml_abort。也就是说问题发生在 MoE 专家混合矩阵乘法iqk_mul_mat_moe进入按 8 行分块的交错量化内核时传入的行数nrc_x不满足 8 的整除约束。该 issue 当天即被修复维护者 ikawrakow 在评论区询问 Dose #231 fix it?用户升级到修复版本build 3572 / commit4f2cfd6e后确认 Its working now, thank you!并附上了修复前后的完整基准测试对比。二、-rtr运行时重打包它究竟在做什么2.1 什么是重打包ik_llama.cpp 在 ggml/src/iqk/iqk_quantize.cpp 中维护了一张从常规量化类型到交错变体类型的映射表原始类型重打包类型分块行数说明Q4_0Q4_0_R88按 8 行分块Q8_0Q8_0_R88按 8 行分块Q8_KQ8_K_R88按 8 行分块Q4_KQ4_K_R44按 4 行分块Q5_KQ5_K_R44按 4 行分块Q6_KQ6_K_R44按 4 行分块IQ4_XSIQ4_XS_R88按 8 行分块IQ2_K/IQ3_K/IQ4_K等对应_R4变体4按 4 行分块MXFP4MXFP4_R88按 8 行分块BF16/F16BF16_R1616仅__AVX512BF16__构建下启用重打包的本质是在不改变量化精度的前提下把原本按单行连续存储的量化数据重新排列成以 4、8 或 16 行为一组block的交错布局。这种布局让 SIMD 内核在加载数据时可以一次取得多行、跨行的量化块配合 AVX2/AVX-512 指令实现更高的内存吞吐与向量化效率——这正是 ik_llama.cpp 相对主线上游在 CPU 推理速度上形成差异的核心优化点之一。从源码结构看整个 ggml/src/iqk 目录下的iqk_gemm_*quants.cpp系列文件都围绕这种交错布局实现专用 GEMM 内核。2.2 两种重打包方式离线与运行时离线重打包使用llama-quantize工具的--only-repack选项见 src/llama-quantize.cpp 与repacked_ftype逻辑把模型文件直接改写成带_R4/_R8后缀类型的 GGUF。这种文件一次转换、永久使用但需要额外的磁盘空间与转换时间。运行时重打包-rtr在模型加载进内存后、首次推理前由llama_model_load遍历所有张量对位于 host 内存中的张量原位执行重打包见 src/llama.cpp。加载完成后打印的 Repacked 268 tensors正是这段代码的输出if (n_repacked 0) LLAMA_LOG_INFO( Repacked %d tensors\n, n_repacked);。-rtr是零成本试水手段不需要预先转换模型文件加载时自动判断每个张量是否有可用的交错变体iqk_repacked_type有就原位重打包没有就保持原样。正因为是原位in-place修改内存中的张量-rtr强制关闭 mmap——参数解析代码在 common/common.cpp 中明确if (arg -rtr || arg --run-time-repack) { params.repack_tensors true; params.use_mmap false; // 原位重打包需要可写的内存不能只读映射文件 return true; }这与 llama.cpp 其余可执行文件的入口llama_model_load通过params.repack_tensors传递给llama_model_loader见 src/llama.cpp形成完整调用链-rtr→repack_tensorstrue→ 非 mmap 加载 →iqk_repack_tensor原位转换。2.3 重打包的三个前置条件ggml/src/iqk/iqk_quantize.cpp 中iqk_repack_tensor的执行逻辑揭示了重打包的门槛void iqk_repack_tensor(struct ggml_tensor * tensor) { constexpr int kChunk 8; if (!tensor) return; if (!ggml_is_contiguous(tensor)) return; // 1. 必须连续 if (is_forbidden_tensor(tensor-name)) return; // 2. 禁止重打包 token_embd.weight 等 if (tensor-ne[1] % 4) return; // 3. 行数至少能被 4 整除 auto rptr get_repack_info(tensor-type); if (!rptr) return; if (tensor-ne[1] % rptr-num_rows) return; // 3. 行数必须能被分块行数整除 ... }也就是说只有当张量的行数ne[1]能被其对应交错变体的分块行数4/8/16整除时重打包才会真正发生。iqk_repacked_type见 ggml/src/iqk/iqk_quantize.cpp在决定是否重打包时也执行同样的整除检查。这里的关键在于同一个模型里不同张量的行数并不一致例如注意力权重通常按n_head或n_head_kv分块MoE 专家权重按n_expert分块因此重打包通常是部分张量——issue 日志里 268 个张量被重打包其余如仅 14 个q5_0、13 个q6_K张量等保持原类型正是这个原因。2.4 为什么不重打包的部分也需要兼容交错变体内核与常规内核在 SIMD 分块策略上的差异导致行数约束不一致常规量化类型的内核通常以 4 行为最小分块单位而_R8变体Q4_0_R8、Q8_0_R8等的 GEMM 路径要求行数能被 8 整除。这正是 issue #230 的崩溃现场修复前的iqk_mul_mat_moe在部分 MoE 专家张量保持未重打包原始类型时错误地沿用了按 8 行分块的代码路径导致nrc_x % 8 ! 0触发断言。修复对应 #231的本质就是让 MoE 混合矩阵乘法内核正确区分已重打包为_R8变体与仍为原始类型的张量对后者回退到按 4 行分块的兼容路径。今天我们在 ggml/src/iqk/iqk_mul_mat.cpp 与 ggml/src/iqk/iqk_mul_mat.h 中看到iqk_mul_mat_moe的公开接口它内部对每种量化类型分别选择匹配的 GEMM 实现正是这套类型感知分派机制的体现。顺带一提重打包后张量的类型从原始类型变为交错变体类型这意味着某些依赖原始布局的后续操作需要特殊处理。例如 src/llama-reload.cpp 在热切换hotswap时明确警告启用-rtr后被重打包的张量无法通过保存的状态精确还原恢复的张量可能与预期不一致F16 - BF16_R16甚至是有损的。因此-rtr更适合加载即用的推理场景而不是需要保存/恢复 KV 状态或做严格数值复现的实验场景。三、issue #230 的完整现场还原3.1 崩溃前模型元数据与重打包日志用户日志完整展示了 DeepSeek-Coder-V2-Lite-Instruct 的加载过程其中与本次崩溃直接相关的元数据包括deepseek2.expert_count 64、deepseek2.expert_used_count 6MoE 架构每 token 激活 6 个专家deepseek2.expert_feed_forward_length 1408、deepseek2.expert_shared_count 2专家 FFN 规模deepseek2.leading_dense_block_count 1前 1 层为稠密层张量类型分布f32108 个、q5_014 个、q8_013 个、q4_K229 个、q6_K13 个。注意q4_K有 229 个张量但重打包日志显示Repacked 268 tensors——这包含了q4_K → Q4_K_R4以及部分其他类型如f32的 MoE 相关权重等的转换。MoE 模型的专家权重张量行数通常等于专家数64乘以某系数而稠密层权重行数等于层内维度两类张量的行数差异正是部分重打包 混合路径分派成为必需的原因。3.2 崩溃点与调用栈解读/root/ik_llama.cpp/ggml/src/iqk/iqk_mul_mat.cpp:4065: GGML_ASSERT(nrc_x%8 0) failed ... /root/ik_llama.cpp/build/ggml/src/libggml.so(iqk_mul_mat_moe0x55a) /libgomp.so.1(0x227ce) ← OpenMP 线程池 /libc.so.6(__clone0x40) ← 线程创建 Aborted (core dumped)崩溃发生在OpenMP 并行线程内部栈底是libgomp与__clone说明iqk_mul_mat_moe已经把 MoE 专家计算分发到多个线程并行执行随后某个线程进入 GEMM 内核时发现行数不满足 8 整除。由于断言在GGML_ASSERT中直接调用ggml_abort对应libggml.so中的ggml_abort帧进程立即Aborted (core dumped)无任何恢复机会。3.3 修复后的验证用户升级到 3572 后问题消失随后给出了两组关键基准机器为 Kaggle 上的 2× Xeon 24 核共 48 线程配置测试结果未启用-rtrbuild 4f2cfd6epp512303.36 ± 29.58 t/s未启用-rtrtg12819.92 ± 0.07 t/s启用-rtrpp512393.53 ± 52.69 t/s启用-rtrtg12821.71 ± 0.16 t/s同样的 build、同样的机器仅增加-rtr开关提示处理pp512从约 303 t/s 提升到约 393 t/s约 30%token 生成tg128从 19.92 t/s 提升到 21.71 t/s约 9%。这组数据来自 issue 中用户实测它直观地说明运行时重打包对提示处理prompt processing受 GEMM 吞吐主导的收益远大于 token 生成受带宽与单 token 延迟主导——因为 pp 阶段的矩阵乘法密集程度远高于自回归解码阶段。维护者随后追问 CPU 型号并建议试试用更少线程跑 TG暗示在 48 线程这类高并发配置下token 生成的线程调度开销可能掩盖部分收益。需要说明的是这组数字是单个用户、单个模型、单台 Kaggle 机器上的实测不代表通用结论不同架构如 llama、qwen2、bitnet、不同量化类型、不同 CPU 上的收益差异可能很大建议读者在自己的硬件上以llama-bench实测为准见下文第四节。四、如何复现与验证4.1 正确复现崩溃现场历史版本若要复现 issue #230 的原始崩溃需要满足检出修复前的版本如 3571 /ac1d259b且构建时启用了 IQK 矩阵乘法路径使用 MoE 架构模型且模型中存在行数不被 8 整除、又会被送入iqk_mul_mat_moe的张量——DeepSeek-Coder-V2-Lite-Instruct Q4_K_M 即为一例以-rtr加载模型并触发首次推理。由于当前仓库已包含修复直接使用最新代码不会复现崩溃上述步骤仅用于历史版本对照。4.2 在当前版本上体验-rtr并验证性能构建参照 docs/install.md以 CMake 构建 CPU 版IQK 路径默认随构建启用cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j推理以llama-cli源码见 examples/main/main.cpp为例build/bin/llama-cli -m /path/to/model-Q4_K_M.gguf -rtr -p Hello, world -n 64也可以使用服务器examples/server/server.cpp或基准工具examples/llama-bench/llama-bench.cppbuild/bin/llama-bench -m /path/to/model-Q4_K_M.gguf -rtr -t 48加载日志中若出现 Repacked N tensors即表示重打包生效。用-rtr与不带-rtr各跑一轮llama-bench对比 pp 与 tg 的 t/s即可量化收益。4.3 常用相关参数速查与-rtr同属加载期内存优化家族的参数均可在llama-cli --help帮助文本见 common/common.cpp中查到参数说明备注-rtr, --run-time-repack有交错变体时原位重打包张量自动关闭 mmap--no-mmap不内存映射模型-rtr隐含开启-cmoe, --cpu-moe所有 MoE 权重保留在 CPU 内存与 GPU 卸载配合-ncmoe, --n-cpu-moe N前 N 层的 MoE 权重保留在 CPU部分卸载场景-thp, --transparent-huge-pagesLinux 下启用透明大页减少 TLB 缺失--defer-expertsLinux 下延迟专家 mmap 驻留缩短模型加载时间4.4 离线重打包--only-repack作为替代如果希望把重打包固化到模型文件、避免每次加载的开销可用 examples/quantize/quantize.cppbuild/bin/llama-quantize --only-repack input.gguf output.gguf逻辑见 src/llama-quantize.cpp遍历每个张量凡存在可用交错变体iqk_repacked_type返回新类型的逐一转换并写回新文件n_to_repack 0 n_to_modify 0时提示 nothing to do for only_repack option。与-rtr不同离线重打包后的文件可以直接 mmap 加载类型已固化在 GGUF 中代价是需要额外磁盘空间与一次性的转换时间。两种方式的取舍离线重打包适合确定要长期使用、追求 mmap 加载速度的生产场景-rtr适合快速试水、对比性能、不想占用额外磁盘的实验场景。五、经验总结与踩坑清单-rtr不等于无损魔法对大多数量化类型Q4_K → Q4_K_R4、Q8_0 → Q8_0_R8等重打包是数学等价的纯布局变换但F16 → BF16_R16是有损的且只在__AVX512BF16__构建下可用。行数整除约束是硬边界iqk_repack_tensor与iqk_repacked_type都要求ne[1]能被分块行数整除MoE 模型尤其容易出现部分张量重打包、部分保持原样的混合状态任何路径分派不当都会触发GGML_ASSERT(nrc_x%8 0)这类崩溃。issue #230 正是 MoE GEMM 路径在混合状态下分派错误的典型案例。-rtr与保存/恢复状态不兼容src/llama-reload.cpp 明确警告热切换恢复的张量无法复现重打包状态结果可能不一致涉及状态保存的实验请关闭-rtr。收益重点在提示处理从 issue 实测看pp 吞吐提升显著该案例约 30%tg 提升相对温和约 9%具体数字随模型、量化、CPU 而异务必用llama-bench自行基准。用Repacked N tensors判断生效加载日志出现该行才代表有张量被转换若未出现请检查模型量化类型是否在映射表见 ggml/src/iqk/iqk_quantize.cpp中、张量行数是否满足整除条件。六、延伸阅读运行时重打包的入口与参数解析common/common.cpp重打包执行与计数日志src/llama.cpp重打包类型映射表与实现ggml/src/iqk/iqk_quantize.cppMoE 混合矩阵乘法入口ggml/src/iqk/iqk_mul_mat.cpp热切换与-rtr的兼容性警告src/llama-reload.cpp离线重打包工具examples/quantize/quantize.cpp 与 src/llama-quantize.cpp相关 issue 原文github-data/issues/230 - Weird assert when using online repacking.md【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考