在 ik_llama.cpp 中使用 Falcon3 10B 1.58bit BitNet 模型I2_S 重新量化与三元量化实战解析【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cppFalcon3-10B-Instruct-1.58bit 是 TII 发布的 1.58-bit 三元权重模型但它最初只提供 Microsoft BitNet 专有的I2_S量化格式无法被标准 llama.cpp 工具链直接量化或加载这正是 Issue #167 中llama-quantize崩溃ggml_calloc: failed to allocate的根源。本文以该 Issue 为线索结合 ik_llama.cpp 中的修复PR #168、#169与相关源码讲解如何将I2_S模型重新量化为本仓库的三元量化类型IQ1_BN、IQ2_BN、IQ2_BN_R4并剖析 Falcon3 预分词器支持与Q8_K16整数求和等底层实现帮助读者完整掌握 BitNet 系三元模型在本项目中的落地方法。一、问题复现Issue #167 中的量化崩溃1.1 现象描述用户raymond-infinitecode在 2025-01-09 提交的 Issue #167 中报告当使用llama-quantize将tiiuae/Falcon3-10B-Instruct-1.58bit转换出的ggml-model-f32.gguf量化为IQ1_BN时程序立即崩溃main: build 3525 (3e685162) main: built with MSVC 19.37.32825.0 for x64 main: quantizing d:\llamafile-0.9.0\ggml-model-f32.gguf to output.gguf as IQ1_BN ggml_calloc: failed to allocate 0.00 MB D:\ik_llama.cpp\ggml\src\ggml.c:378: fatal error崩溃发生在ggml/src/ggml.c的ggml_calloc处且分配大小为0.00 MB说明在量化流程中拿到了异常的张量形状或零尺寸参数。同时用户提问如何把这个模型转换成能用于 ik_llama.cpp 的 GGUF1.2 根因BitNet 专有的 I2_S 格式在 Issue 的讨论中项目作者 ikawrakow 很快定位了问题本质该 Falcon3 10B 模型仅以 Microsoft BitNet 专有的I2_S量化格式发布仓库中不存在f16、f32或q8_0的标准 GGUF 版本主流的llama.cpp主线版本无法直接加载它只有 Microsoft BitNet 仓库及其衍生 fork如 Eddie-Wang1120 的merge-dev分支能运行I2_S类型在其他任何 llama.cpp 系实现中都不存在属于“孤岛格式”。从当前仓库源码可以确认这一点在 ggml/src/ggml.c 中GGML_TYPE_I2_S的类型描述被注册为type_name i2_s但其from_float NULL、from_float_ref NULL——即它只能作为输入被反量化读取而不能由浮点张量直接量化生成。这就解释了为什么“手动转出 f32 GGUF 再量化”这条路走不通中间产物本身就不是该模型真实结构对应的标准格式。1.3 补充BitNet b1.58 是什么为便于理解这里补充背景BitNet b1.58 是一类三元权重ternary weight模型权重被约束为{-1, 0, 1}三个值每个权重仅需约 1.58 bit因此模型文件极小、推理时以加法为主。ik_llama.cpp 为此设计了一系列专用量化类型见下文。二、解决方案I2_S 重新量化支持PR #1692.1 修复思路作者先给出了两种思路的权衡上游推动请 TII 以标准格式f16/f32/q8_0重新发布模型这是最干净的方案自写转换器为I2_S编写I2_S - IQ2_BN / IQ1_BN / F16/32的转换逻辑。最终作者选择了后者并在 PR #169 - Be able to re-quantize MS BitNet I2_S models 中实现该 PR 声明Closes #167。其核心是为I2_S张量提供反量化路径dequantize_row_ms_i2s见 ggml/src/iqk/iqk_quantize.cpp从而允许llama-quantize以--allow-requantize模式将已量化的I2_S张量重新量化为本项目支持的三元量化类型。2.2 完整操作步骤PR #169 给出了两条命令的完整流程第一步下载 I2_S 格式的 GGUF 模型huggingface-cli download tiiuae/Falcon3-10B-Instruct-1.58bit-GGUF需预先安装huggingface_hubCLI并注意该仓库路径以-GGUF结尾与 Issue 中提到的原始仓库tiiuae/Falcon3-10B-Instruct-1.58bit不同。第二步重新量化为三元量化类型./bin/llama-quantize --allow-requantize path_to_model/ggml-model-i2_s.gguf output.gguf iq2_bn其中--allow-requantize允许对已经量化过的张量再次量化。llama-quantize的 usage 中明确警告该选项“会严重降低质量相比从 16bit/32bit 量化severely reduce quality”见 examples/quantize/quantize.cpp。但对I2_S这类只有量化版本可用的模型这是唯一路径ggml-model-i2_s.ggufBitNet 仓库产出的 I2_S GGUFoutput.gguf输出的目标文件iq2_bn目标量化类型也可换为iq1_bn、iq2_bn_r4等。作者注明转换后的模型在 CPU 与 GPUCUDA 或 Metal上均可运行。同时作者也提醒该 10B 三元模型的困惑度perplexity比 Falcon3-7B-Instruct 三元模型更高实际可用性需自行评估。三、三元量化类型族IQ1_BN / IQ2_BN / IQ2_BN_R4重新量化时可选的目标类型在 examples/quantize/quantize.cpp 中定义类型标识GGUF 内部类型描述IQ1_BNLLAMA_FTYPE_MOSTLY_IQ1_BN1.62 bpw 量化BitnetIQ2_BNLLAMA_FTYPE_MOSTLY_IQ2_BN2.00 bpw 量化BitnetIQ2_BN_R4LLAMA_FTYPE_MOSTLY_IQ2_BN_R42.00 bpw 量化Bitnet4 行交织变体在底层 ggml/src/ggml.c 中三种类型分别由quantize_iq1_bn、quantize_iq2_bn、quantize_iq2_bn_r4实现其定义位于 ggml/src/iqk/iqk_quantize.cpp 与同文件iq2_bn_r4一节L5935 起。IQ2_BN_R4的实现会先调用quantize_iq2_bn完成基础量化再按 4 行一组做行交织row-interleaved重排以提升缓存与 SIMD 效率。选择建议基于 PR #169 与 #168 的表述IQ2_BN默认推荐2.00 bpw质量与性能均衡IQ1_BN更激进的压缩1.62 bpw文件更小但精度损失更大IQ2_BN_R4性能取向配合-rtr 1加载时做 4 行交织在 CPU 上效果更好同时依赖下文介绍的Q8_K16整数求和修复来保证数值一致性。四、配套修复Falcon3 预分词器与 Q8_K16 整数求和PR #168PR #168 - Falcon3 changes 包含两项修改是 I2_S 模型能正确加载与运行的前提4.1 Falcon3 预分词器Falcon3 使用与 Llama-3 相同的 byte-level BPE 预分词器。在 src/llama-vocab.cpp 中tokenizer_pre falcon3与llama3、llama-bpe、laguna等一同被映射到LLAMA_VOCAB_PRE_TYPE_LLAMA3并设置ignore_merges true、add_bos true。这意味着包含tokenizer.ggml.pre falcon3元数据的 GGUF 模型加载时会被正确分派到 Llama-3 风格的分词流程无需用户手动指定模板。4.2 Q8_K16 行求和改为整数算术第二项修改将Q8_K16的一行激活求和从“累加 f32 值”改为整数算术。该修改的必要性在于IQ2_BN_R4在 Falcon3 三元模型上原有实现导致 GPU 与 CPU 的困惑度结果差异过大改用整数求和后差异大幅缩小且作者测得IQ2_BN_R4的 PPL 甚至略低于号称 “lossless” 的 Microsoft BitNet 实现该对比在 PR #168 讨论中给出。五、性能对比IQ2_BN vs Microsoft BitNet I2_SPR #168 讨论中作者在Ryzen-7950X CPU上对 Falcon3-7B-Instruct-1.58bit7.46B 参数做了直接对比此处转述其原始数据实际表现因硬件与配置而异模型文件大小threads测试t/sI2_SBitNet3.05 GiB16pp512187.90IQ2_BN-rtr 12.07 GiB16pp512465.85I2_SBitNet3.05 GiB8tg12823.39IQ2_BN-rtr 12.07 GiB8tg12828.03I2_SBitNet3.05 GiB1tg1289.64IQ2_BN-rtr 12.07 GiB1tg12812.83IQ2_BN-rtr 12.07 GiB2tg12822.46IQ2_BN-rtr 12.07 GiB4tg12827.62结论要点均为 PR 原始陈述非本文推断Prompt 处理pp512快约 2.5 倍465.85 vs 187.90 t/sToken 生成tg128快约 20%28.03 vs 23.39 t/s8 线程且两者都在 8 线程达到峰值能效优势IQ2_BN在 2 线程下22.46 t/s即接近 BitNet 在 8 线程下的峰值23.39 t/s作者据此提出IQ2_BN的能效约为 BitNet 的 4 倍文件更小2.07 GiB vs 3.05 GiB得益于IQ2_BN无需I2_S那样的独立 scale 开销。六、实战注意事项与限制必须使用--allow-requantizeI2_S张量无法从浮点直接量化from_float为空只能走“反量化→再量化”路径该选项会带来二次量化质量损失属于格式受限下的必要妥协。原模型仅 10B 版本为纯 I2_SIssue 讨论中作者指出7B 版本在 BitNet 的setup_env.py流程下实际会拉取到 f32 版本可直接量化而 10B 版本只有I2_S量化文件必须用 PR #169 的流程。加载时可用-rtr 1运行llama-cli/llama-server等工具时-rtrrow-to-row 交织参数可对IQ2_BN等类型启用 4 行交织加载配合IQ2_BN_R4在 CPU 上获得更好性能。模型质量需自行评估PR #169 中作者观察到该 10B 三元模型困惑度偏高建议实际测试后再决定是否用于生产。目标平台重新量化后的模型在 CPU 与 GPUCUDA/Metal均可运行相关 CUDA 实例见 ggml/src/ggml-cuda/template-instances/mmvq-instance-iq1_bn.cu 与 mmvq-instance-iq2_bn.cu。七、总结Issue #167 看似是一次ggml_calloc崩溃实质是Microsoft BitNet 专有I2_S格式与标准 llama.cpp 工具链之间的格式壁垒。ik_llama.cpp 通过 PR #168Falcon3 预分词器 Q8_K16整数求和与 PR #169I2_S反量化与重新量化完整打通了“下载 I2_S GGUF →llama-quantize --allow-requantize转为IQ1_BN/IQ2_BN/IQ2_BN_R4→ CPU/GPU 推理”的整条链路并在 CPU 上相对官方 BitNet 实现取得了显著性能提升。对于希望在本项目中使用 BitNet 系三元模型的开发者这条路径至今仍是标准做法。延伸阅读仓库内资料Issue #365 - Updated BitNet arch bitnet-b1.58BitNet b1.58 架构更新相关讨论Issue #387 - bitnet 1.58 on termux segmentation fault移动端运行 BitNet 模型的问题记录PR #44 - Adding IQ1_TN - 1.6875 bpw for TriLM ternary models另一条三元模型TriLM量化路线讨论 #95 - Bitnet社区对 BitNet 支持的总体讨论。【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考