尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

如何用 llama-bench 测试 BitNet-embedding I2_S 相对 F16 的 prefill 加速比?

如何用 llama-bench 测试 BitNet-embedding I2_S 相对 F16 的 prefill 加速比? 如何用 llama-bench 测试 BitNet-embedding I2_S 相对 F16 的 prefill 加速比【免费下载链接】BitNetOfficial inference framework for 1-bit LLMs项目地址: https://gitcode.com/GitHub_Trending/bitne/BitNet本文解决一个具体问题在 CPU 上用 BitNet 仓库自带的llama-bench量化测量 BitNet-Embeddings 模型bitnet-embeddings-0.6b / 270m转换后的 I2_S GGUF 相对于 F16 基线 GGUF 在 prefillprompt processing阶段的吞吐加速比。整个流程基于 I2_S 转换与推理优化指南包括构建llama-bench二进制、转换出对比双方所用的 GGUF 文件、运行基准脚本以及从输出中计算加速比。文档给出的参考测试环境是 Intel Xeon Platinum 8573C、8 线程、Clang/Clang无 OpenMP、GGML_NATIVEON结果单位为 tokens/s为 3 次运行的均值。你在其他 CPU 上跑出的数值会不同但操作步骤和加速比的读法一致。准备构建环境并编译 llama-bench测试对象是llama-bench二进制它随 bitnet.cpp 仓库一起构建。指南中推荐的直接 CMake 路径如下setup_env.py路径也可以完成构建但对 embedding 模型指南的基准脚本默认使用下面这一流程的产物git clone --recursive https://github.com/microsoft/BitNet.git cd BitNet cd 3rdparty/llama.cpp git checkout release-bitnet-embedding-0.6b-270m cd ../.. cmake -S . -B build \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_C_COMPILERclang \ -DCMAKE_CXX_COMPILERclang \ -DGGML_NATIVEON \ -DGGML_OPENMPOFF \ -DLLAMA_BUILD_COMMONON \ -DLLAMA_BUILD_TOOLSON \ -DLLAMA_BUILD_EXAMPLESON cmake --build build --target llama-embedding llama-bench -j$(nproc)其中需要留意的两个构建选项-DGGML_NATIVEON会自动探测并启用宿主 CPU 支持的最佳指令集AVX、AVX2、AVX-VNNI、FMA、F16C 等指南建议用于获得最优性能。若要构建仅依赖 AVX2 的可移植二进制指南给出替代参数-DGGML_NATIVEOFF加上-DGGML_AVXON -DGGML_AVX2ON -DGGML_FMAON -DGGML_F16CON -DGGML_AVX512OFF -DGGML_AVX512_VBMIOFF -DGGML_AVX512_VNNIOFF -DGGML_AVX512_BF16OFF。指令集会影响测得的吞吐对比 F16 与 I2_S 时应保持同一套构建选项。-DGGML_OPENMPOFF与指南中的基准条件一致测试时由-t参数显式控制线程数。构建成功后llama-bench位于./build/bin/llama-bench。准备对比双方的 GGUF 文件llama-bench需要两个模型文件I2_S 格式的被测模型以及作为 F16 性能参照的基线模型。指南明确说明二者的角色bitnet-embeddings-*是带三值权重的 1-bit 学生模型转换到 I2_S 用于 CPU 推理multilingual-e5-*是标准浮点权重的 teacher/baseline 模型用作 F16 性能参照。I2_S 转换要求模型是 BitNet 原生生成的具有三值权重F16 转换不要求可直接使用标准 FP16/BF16 模型。转换脚本是 utils/convert-bitnet-embedding-to-gguf.py它会从config.json的model_type自动识别架构qwen3或gemma3_text并支持f32、f16、i2_s三种输出类型。脚本源码中导入了numpy和torch运行前需保证这两个依赖可用。以 0.6B 为例# I2_S 转换bitnet-embeddings-0.6b需要 BitNet 原生训练的三值权重模型 # 输出约 699 MiB约为 F16 体积的 50% python3 utils/convert-bitnet-embedding-to-gguf.py \ /path/to/bitnet-embeddings-0.6b \ --outtype i2_s \ --outfile bitnet-embeddings-0.6b-i2_s.gguf # F16 转换multilingual-e5-0.6b-260311 为 F16 基线 # 输出约 1.11 GiB595.78M 参数 python3 utils/convert-bitnet-embedding-to-gguf.py \ /path/to/multilingual-e5-0.6b-260311 \ --outtype f16 \ --outfile multilingual-e5-0.6b-f16.gguf/path/to/...是脚本参数中留给你的占位替换为本地已下载的模型目录。模型来源见指南 Model Sources 一节Hugging Face 仓库名microsoft/bitnet-embedding-0.6b、microsoft/bitnet-embedding-270m基线为multilingual-e5-0.6b-260311、multilingual-e5-270m-260311。270M 模型的转换命令同形只替换输入目录和输出文件名python3 utils/convert-bitnet-embedding-to-gguf.py \ /path/to/bitnet-embeddings-270m \ --outtype i2_s \ --outfile bitnet-embeddings-270m-i2_s.gguf python3 utils/convert-bitnet-embedding-to-gguf.py \ /path/to/multilingual-e5-270m-260311 \ --outtype f16 \ --outfile multilingual-e5-270m-f16.gguf转换产物中I2_S 模式下只有 2D 线性投影权重是三值打包2-bit packed float32 scaleembedding 权重和各类 norm 权重仍为 float16F16 模式下 2D 权重与 embedding 为 float16。这决定了 I2_S 的加速只来自矩阵乘路径attention 部分并不受益这也是后文加速比随序列变长而缩小的原因。运行 llama-bench 基准指南提供了现成的基准脚本对 F16 和 I2_S 各跑一次llama-bench#!/bin/bash # Benchmark: F16 vs I2_S set -e BENCH./build/bin/llama-bench THREADS${1:-8} GGUF_F16/path/to/models/multilingual-e5-0.6b/embeddings-0.6b-f16.gguf GGUF_I2S/path/to/models/bitnet-embeddings-0.6b/bitnet-embeddings-0.6b-i2_s.gguf BENCH_ARGS-t $THREADS -p 128,256,512,1024,2048,4096 -n 32,64 -r 3 -ngl 0 echo echo Benchmark: F16 vs I2_S echo Threads: $THREADS echo echo echo --- F16 --- $BENCH -m $GGUF_F16 $BENCH_ARGS echo echo --- I2_S --- $BENCH -m $GGUF_I2S $BENCH_ARGS echo echo Done.脚本参数与执行条件说明脚本第一个可选参数是线程数默认 8与指南参考数据一致换线程数时F16 与 I2_S 必须用同一线程数。-p 128,256,512,1024,2048,4096指定要测的 prefill 序列长度列表输出中对应pp128到pp4096各档结果。-n 32,64会同时测对应长度的 decode本场景只看 prefill即pp各档。-r 3表示每个测试点运行 3 次指南报告的就是 3 次运行的均值。-ngl 0表示不使用 GPU offload全程 CPU与指南基准条件一致。GGUF_F16和GGUF_I2S两个路径指向你上一步生成的 GGUF 文件指南脚本中的/path/to/models/...是占位路径替换为你的实际目录。若测 270M改为对应的 270m 两个文件即可。脚本只做基准测量无副作用可直接执行。从输出中计算 prefill 加速比对同一个序列长度加速比 I2_S 的 tokens/s ÷ F16 的 tokens/s取pp档的结果逐档相除即可。指南在 Xeon Platinum 8573C、8 线程条件下给出的参考结果如下这是文档实测数据不是你在任意硬件上应得到的固定值bitnet-embedding-0.6BTestF16.gguf (t/s)I2_S.gguf (t/s)Speeduppp128382.15870.902.28xpp256373.95827.752.21xpp512371.86716.271.93xpp1024341.55620.581.82xpp2048298.21481.141.61xpp4096236.76336.321.42xbitnet-embedding-270mTestF16.gguf (t/s)I2_S.gguf (t/s)Speeduppp1281212.682019.591.67xpp2561221.282119.501.74xpp5121394.992181.231.56xpp10241265.222086.461.65xpp20481024.471471.601.44xpp4096785.541033.461.32x按指南对这批结果的解读0.6B 模型加速比区间为 1.42x–2.28x270M 为 1.32x–1.74x。加速比最大出现在短序列如 pp128随序列变长而下降——长序列下未量化的 attention 计算占比增大稀释了线性层三值化带来的收益。270M 的加速比整体小于 0.6B是因为 270M 的线性投影参数相对其他操作占比更小三值权重量化的收益在比例上更小。如果你的硬件上某个pp档 I2_S 与 F16 的比值明显偏离上述区间优先核对两点两个 GGUF 是否用同一套构建选项编译的二进制测量以及-t线程数是否与指南条件可比。限制与适用边界本流程测量的是 CPU prefill 吞吐对比依赖release-bitnet-embedding-0.6b-270m分支下的llama-bench与 I2_S 内核属于 CPU 场景仓库的 GPU 推理路径gpu/目录不在本文范围。F16 基线必须用真实存在的对照模型指南指定multilingual-e5-*teacher 系列作为 0.6B/270m 对应的 F16 参照且 F16 转换支持标准 FP16/BF16 权重模型。I2_S 转换只接受 BitNet 原生训练的三值权重模型multilingual-e5-*这类标准浮点模型只能走--outtype f16不能转成 I2_S。转换脚本按model_type仅支持qwen3与gemma3_text两种架构对应 bitnet-embeddings-0.6b 与 bitnet-embeddings-270m。除吞吐外指南另给出精度侧的验证方式MTEB v2 多语评测见 docs/bitnet-embeddings-i2s-guide.md 第 3.4 节如果你要同时核对 I2_S 转换是否引入精度损失可参考该节的对比脚本思路但它服务于精度验证而非性能测量不属于本文主路径。【免费下载链接】BitNetOfficial inference framework for 1-bit LLMs项目地址: https://gitcode.com/GitHub_Trending/bitne/BitNet创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表