BitNet CPU 推理：2B4T 的实际内存需求与 100B 说法

返回

Kevin Riedl

13 分钟 阅读 · 2026年10月12日
最近审核 2026年10月12日

下一篇

本文基于原始研究、模型文件和固定版本源码的核对。Wavect 尚未执行文中的 BitNet 推理命令，也未独立复现所引用的基准结果。

微软 BitNet 让你通过 bitnet.cpp，在 CPU 上评估一个经过训练、拥有 24 亿参数（2.4B）的语言模型。广为传播的 100B（1000 亿参数）说法，来自框架对合成模型配置的基准测试。实际评估可以从已发布的 BitNet b1.58 2B4T 模型权重、兼容的运行时，以及一个能够评分的短任务开始。

假设你想在现有电脑上对客服工单进行分类，BitNet 提供了一个先评估本地推理、再决定是否购买硬件的机会。决定它是否适用，需要看完整的内存占用、响应时间和任务准确率。

本次核对的微软仓库列出了 2.4B 生成模型和较新的嵌入模型。其公布的支持列表中，没有经过训练的 100B 生成模型权重。框架最早发布于 2024 年 10 月，2B4T 则发布于 2025 年 4 月。

资料核对日期：2026 年 10 月 12 日。本文核对了原始研究、模型文件，以及提交 0b341e5 对应的运行时源码。Wavect 尚未执行文中的推理命令，也未独立复现论文的基准测试。下文提供的是建议采用的评估方案。

BitNet 能用一颗 CPU 运行 100B 模型吗？

原论文报告：在配备 M2 Ultra 和 64 GB 内存的 Mac Studio 上，合成 100B 配置的速度达到每秒 6.58 个 token。2024 年 10 月的 CPU 推理论文在附录 A 中明确说明，这些基准配置使用的是模拟模型。这个结果说明了该配置的吞吐量；论文没有因此提供一个可下载的、经过训练的 100B 助手模型。

不限线程数的两行结果没有披露最终采用了多少线程。提示词长度、生成长度和缓存条件也没有说明。一颗 CPU 可以使用多个线程。这些数据无法证明任意笔记本电脑，或单个 CPU 核心，都能达到每秒 5 至 7 个 token。

经常被引用的 x86 平台 2.37 至 6.17 倍、ARM 平台 1.37 至 5.07 倍加速，比较对象是能够装入内存的 llama.cpp FP16 权重方案。在 100B 这一档，两台设备都没有可用的 FP16 基准结果。报告中 x86 平台最大的能耗降幅为 82.2%，来自 7B 模型的比较，不能当作 2B4T 或 100B 配置的实测节能幅度。

用 CPU 推理，应该下载哪个 BitNet 模型？

使用官方 2B4T GGUF 文件，并采用 bitnet.cpp 支持的 CPU 推理方式。模型卡区分了三种发布形式。选对具体文件，与选对模型名称同样重要。

这三个名称都属于同一模型系列，其训练数据量为 4 万亿 token。名称中的 4T 指的就是这个训练规模。后来发布的 0.6B 和 270M 嵌入模型负责将内容转成检索用的向量，用途不同，不属于本文的文本生成评估。

2B4T 从头训练时就采用三值权重和 8 位激活。这个训练过程是理解结果的关键。把任意 FP16 模型的权重转换成三个取值，并不会自动获得 2B4T 的质量。关于二值模型和手机部署，可参阅我们另行讨论这些问题的 Bonsai 低位模型评述。

BitNet 2B4T 实际需要多少内存？

论文公布的 0.4 GB 不含嵌入层权重。本次核对的 GGUF 文件约为 1.19 GB，运行时的总内存需求需要实测。固定版本的官方 GGUF 文件给出的是具体下载体积，不能直接当作完整的硬件要求。

对于实际发布的 2B4T 模型，还可以估算上下文内存的一部分。它的公开配置包含 30 层、5 个键值头，每个头的维度为 128。按本次核对的 F16 键值缓存默认设置，完整的 4,096-token 序列，其缓存数据的理想大小为 300 MiB：2 × 30 × 4096 × 5 × 128 × 2 bytes。这个计算不含内存分配器开销，也不含其他内存组成部分。它解释了为什么模型文件大小不变，增加上下文仍然会占用更多内存。

b1.58 中的“1.58”来自 log2(3)：三个可能的权重值，理论上约需 1.585 位表示。实际存储格式还涉及打包方式和其他张量。I2_S 内核使用两位权重打包，其中的乘加执行方式也说明，“整个推理过程没有任何乘法”并不准确。CPU 推理论文还解释了查找表内核采用的不同运算方式。

为了直观理解量级，可以对 100B 权重做一个刻意简化的计算：每个权重按 log2(3) 位计，约为 19.81 GB；按两位打包计，为 25 GB；按 FP16 计，则为 200 GB。这里使用十进制 GB，且假设所有权重采用统一格式，仅计算权重本身：parameters × bits ÷ 8。不同格式存储的嵌入层、缓存和运行时开销都没有包括在内。

根据上述理想权重数据量，相对 FP16 的缩小倍数约为 10.1，相对 FP32 约为 20.2。这个计算不支持“总内存普遍缩小 16 至 32 倍”的结论，也无法证明一台 8 GB 或 16 GB 内存的笔记本电脑能满足你的延迟要求。

可以先用我们的 llmfit 硬件选型指南检查电脑配置、整理候选模型，再直接验证这里指定的 BitNet 文件和运行时。仅凭模型清单中的估算，无法确认它们的实际兼容性或内存占用。

2B4T 的质量评测能说明什么？

2B4T 在多项小模型基准中有竞争力，但不同任务之间存在明显差异。2B4T 技术报告比较了经过指令微调的模型。下面选取的结果，同时包含它优于和弱于 Qwen2.5 1.5B 的项目。

报告在附录 B 中列出了评估设置。这些是原作者对不同训练模型的测试结果，不能当作同一模型量化前后的对照，也不能证明每个答案都能保留原有质量。这些结果同样没有验证合成 100B 配置的语言能力。

同一报告中的 29 ms，指的是在 i7-13800H 上使用 8 个线程、生成 128 个 token 时，每个输出 token 的平均解码时间。它与首个 token 延迟是两项指标。其中的 0.028 J 能耗数据，是按建模的 7 nm 工艺进行的算术估计，并非对笔记本电脑用电量的实测。

模型卡给出的上下文长度为 4,096 个 token，并注明对英语以外语言的支持有限。系统提示词、输入和输出都要计入上下文预算。如果工作流程需要德语、西班牙语或中文，就应分别测试。本文提供四种语言版本，并不能证明模型在这四种语言上的表现相同。

简短的英语分类任务适合作为第一项候选评估任务。长文档综合分析、多语言客服和自主编程，都需要各自的验证依据。MIT 许可证允许广泛复用，但模型卡仍建议在真实业务或商业使用前，开展进一步测试和开发。

BitNet 2B4T CPU 安装步骤：已核对源码

以下命令适用于 Linux 或 macOS Shell，并假设已经安装 Git、Python 3.10 或更高版本、CMake 3.22 或更高版本，以及 Clang 18 或更高版本。请先按仓库说明满足对应平台的前置条件。Windows 需要遵循其 Visual Studio 2022 Developer PowerShell 和环境激活步骤。

CPU 推理支持使用兼容内核的 x86 与 ARM 平台。仅支持某种 CPU 架构，尚不足以证明它可以在手机或物联网设备上成功部署。规划这类部署前，需要核对目标操作系统、编译依赖和可用内存。

固定运行时和模型文件的版本，才能让其他开发者明确你测试了什么。本次核对的安装脚本实现会根据模型目录名选择内核生成方式。请保留下方 BitNet-b1.58-2B-4T 目录名中的大小写。

git clone https://github.com/microsoft/BitNet.git
cd BitNet
git checkout 0b341e582afbf9e1011f24744b554c96a3477eb5
git submodule update --init --recursive
python3 -m venv .venv
. .venv/bin/activate
python -m pip install -r requirements.txt

hf download microsoft/bitnet-b1.58-2B-4T-gguf \
  ggml-model-i2_s.gguf \
  --revision a1f2f1c765812aa8af3f6eda4a313707064bba15 \
  --local-dir models/BitNet-b1.58-2B-4T

python setup_env.py \
  -md models/BitNet-b1.58-2B-4T -q i2_s

先使用两个线程、2,048-token 上下文，并限制输出长度：

python run_inference.py \
  -m models/BitNet-b1.58-2B-4T/ggml-model-i2_s.gguf \
  -p "You are a helpful assistant." \
  -cnv -t 2 -c 2048 -n 128

本次核对的推理封装脚本将 GPU 层数设为零，使用 CPU 执行。启用 -cnv 后，-p 用于提供系统提示词，实际问题需要在交互过程中输入。这里的线程数只是起始配置，尚未确定它是否是你的电脑上最快的设置。

下载和安装依赖需要联网。完成设置后，应断网测试推理。如果再接入桌面应用、日志服务或云端后备服务，也要将这些组件纳入测试。模型本地运行，只能说明模型的执行位置，不能代表整个应用的数据流向。

分别测量提示词处理、生成速度与内存

即使答案很短，运行时处理提示词也可能让用户等很久。应分别测量提示词处理、首个 token 等待时间、输出 token 速度和完整响应时间，并同时记录 CPU 型号、线程数、电源模式、模型版本和上下文设置。

若要进行可重复的推理基准测试，基准封装脚本源码指出了底层使用的 llama-bench 可执行文件。直接调用它，还可以避开该版本封装脚本在基准子进程返回后，无条件以错误状态退出的问题。

./build/bin/llama-bench \
  -m models/BitNet-b1.58-2B-4T/ggml-model-i2_s.gguf \
  -p 512 -n 128 -t 2 -ngl 0 \
  -b 512 -ub 128 -ctk f16 -ctv f16 -r 5

固定版本的基准实现会分别执行 pp512 提示词处理测试和 tg128 token 生成测试，重复 5 次，并采用默认预热。它不测量“512-token 问题加 128-token 答案”这一完整请求，也不测量首个 token 延迟。真实请求需要单独计时。这组命令无法复现论文中条件说明不完整的 100B 测试。

用具有代表性的输入，测量实际推理进程的峰值驻留内存。按计划使用的上下文和预期并发负载重复测量，同时关注交换活动和系统可用内存。模型虽然能加载，但如果导致大量内存换页，仍可能无法满足响应时间要求。

第一次评估：一个简短的工单分流任务

先准备经过批准、固定不变的 100 条英语客服工单，并为每条工单标注参考类别：billing、technical、other 或 review。含义不明确、需要人工判断的工单，使用 review。要求模型返回一个类别和一段简短说明。这是一项建议测试的任务，本文没有宣称任何实测结果。

开始比较前，先确定可接受的错误率和延迟。让当前使用的模型或简单的规则分类器处理同一组任务，记录各自在内存与响应时间预算内，产出了多少正确、可用的结果。相比宣传中的参数量，一次成功的小规模试点能为是否采用模型提供更直接的依据。

请求留在本地时，CPU 推理可以省去按 token 收取的云端推理费用。但硬件、电力和维护仍应计入决策。我们的本地模型与 API 成本比较框架涵盖了这些更完整的预算项。关于应用架构，可以参阅技术栈选择指南。