1B–3B 小模型端侧量化实测：llama.cpp+Ollama（2026）

1B--3B 小模型端侧量化实测：llama.cpp+Ollama（2026）

摘要：本文面向想在笔记本、mini 主机或工控机上本地跑大模型的开发者与运维，解决"小参数模型如何量化、如何用 Ollama 封装、端侧 NPU 到底有没有用"三个问题。基于 llama.cpp b3640、Ollama 0.5.9、Python 3.12 实测环境，给出量化命令、Modelfile、benchmark 脚本与延迟/功耗对比表。附完整踩坑清单。

文章目录

[1B--3B 小模型端侧量化实测：llama.cpp+Ollama（2026）](#1B–3B 小模型端侧量化实测：llama.cpp+Ollama（2026）)
- 一、问题背景
- - [1.1 端侧推理为什么值得做](#1.1 端侧推理为什么值得做)
  - [1.2 本文要解决什么](#1.2 本文要解决什么)
- [二、EDGE-BENCH 四维评估框架](#二、EDGE-BENCH 四维评估框架)
- - [2.1 为什么需要一个框架](#2.1 为什么需要一个框架)
  - [2.2 四维如何指导本文](#2.2 四维如何指导本文)
- 三、环境准备
- - [3.1 硬件与系统](#3.1 硬件与系统)
  - [3.2 软件版本清单](#3.2 软件版本清单)
- 四、核心实现
- - [4.1 第一步：取得原始 FP16 权重](#4.1 第一步：取得原始 FP16 权重)
  - [4.2 第二步：用 Ollama 封装成可调用模型](#4.2 第二步：用 Ollama 封装成可调用模型)
  - [4.3 第三步：起本地推理服务做压测](#4.3 第三步：起本地推理服务做压测)
- 五、踩坑记录与避坑指南
- - [5.1 常见问题 Q&A](#5.1 常见问题 Q&A)
  - [5.2 可复用避坑清单](#5.2 可复用避坑清单)
- 六、性能验证与对比
- - [6.1 测试环境](#6.1 测试环境)
  - [6.2 实测对比数据](#6.2 实测对比数据)
  - [6.3 端侧部署方案综合评分](#6.3 端侧部署方案综合评分)
- 七、适用边界与风险提示
- - [7.1 适用场景](#7.1 适用场景)
  - [7.2 不适用场景](#7.2 不适用场景)
  - [7.3 生产环境注意事项](#7.3 生产环境注意事项)
- 八、总结
- FAQ

一、问题背景

1.1 端侧推理为什么值得做

开放权重模型（如 Qwen2.5、Llama 3.2 系列）可以合法下载到本地，让"云端训练、端侧推理"成为隐私和成本都更优的落地形态。尤其是 1B--3B 参数区间的小模型，在 NPU、Apple Silicon、甚至 Intel N 系列这类低功耗芯片上就能跑出可用的对话速度。

但很多团队卡在第一步：下载到的是 FP16（16 位浮点）原始权重，体积大、占内存、在端侧设备上直接 OOM（内存溢出）。真正能落地的是量化（quantization，把权重从高精度压成低精度）之后的版本。

1.2 本文要解决什么

本文不堆概念，而是用一套可复跑的流程把 1B--3B 模型从原始权重变成端侧可用的推理服务：先量化、再用 Ollama 封装、最后压测对比 CPU 与 NPU 的真实表现。所有命令都带版本号和预期输出，照着敲就能跑通。

二、EDGE-BENCH 四维评估框架

2.1 为什么需要一个框架

端侧量化不是"量化一次就完事"，它横跨工具链、硬件、场景三件事。为了不凭感觉选型，本文定义一个可复用的评估框架：EDGE-BENCH 四维------

量化方案（Quant）：选 GGUF 的哪档 k-quant（k-quant 是 llama.cpp 的量化族，按精度/体积权衡分级，如 Q4_K_M、Q5_K_M）。
硬件（Hardware）：纯 CPU、集成 NPU、还是独立显卡，决定了上限。
NPU vs CPU：同一模型在两类执行单元上的吞吐与功耗差异。
场景适配（Fit）：对话、摘要、分类、工具调用各自对延迟的容忍度不同。

2.2 四维如何指导本文

下文的环境准备、核心实现、性能验证三章，分别对应"量化方案"和"硬件"两个维度的落地；第六章的对比表则是"NPU vs CPU"和"场景适配"的实测支撑。这个框架也可直接套到你自己的模型上，不必重读论文。

三、环境准备

3.1 硬件与系统

实测机为 Intel N100 迷你主机（6W TDP，4 核，无独显，核显可走 OpenVINO 后端），内存 16GB，系统 Ubuntu 24.04 LTS。NPU 部分用同机型的 Intel NPU（通过 llama.cpp 的 OpenVINO 后端调用）做对照。

3.2 软件版本清单

所有版本都锁定，避免"在我机器上能跑"的玄学问题：

llama.cpp: b3640（commit 约 2026-06）
Ollama: 0.5.9
Python: 3.12.3
模型: Qwen2.5-1.5B-Instruct、Qwen2.5-3B-Instruct（GGUF 源文件）

四、核心实现

4.1 第一步：取得原始 FP16 权重

从 Hugging Face 拉取 Qwen2.5-1.5B 的未量化版（safetensors），随后用 llama-quantize 转 GGUF。下面这条命令把 FP16 转成 Q4_K_M：

bash 复制代码

# llama.cpp b3640 提供的量化工具，把 FP16 压成 Q4_K_M（约 4-bit 中档量化）
# 用法：llama-quantize <输入FP16> <输出GGUF> <量化档位>
./llama-quantize \
  ./Qwen2.5-1.5B-Instruct-f16.gguf \
  ./Qwen2.5-1.5B-Instruct-Q4_K_M.gguf \
  Q4_K_M

# 预期输出（关键行）：
# loading model from ./Qwen2.5-1.5B-Instruct-f16.gguf
# model size = 3093.41 MB
# quantizing ... q4_k_m
# output path = ./Qwen2.5-1.5B-Instruct-Q4_K_M.gguf
# final size = 1081.20 MB

量化后体积从约 3.1GB 降到 1.1GB，这是 1B--3B 模型能塞进端侧设备的关键一步。

4.2 第二步：用 Ollama 封装成可调用模型

Ollama 用 Modelfile 描述模型来源与参数。下面是一份可复用的 Modelfile：

yaml 复制代码

# Modelfile（Ollama 0.5.9 语法）
FROM ./Qwen2.5-1.5B-Instruct-Q4_K_M.gguf

# 对话模板，复用原模型的 chat 模板
TEMPLATE """{{ if .System }}<|im_start|>system
{{ .System }}<|im_end|>
{{ end }}{{ if .Prompt }}<|im_start|>user
{{ .Prompt }}<|im_end|>
{{ end }}<|im_start|>assistant
"""

# 推理参数
PARAMETER num_ctx 4096
PARAMETER num_gpu 0      # 0 = 纯 CPU；NPU 走 OpenVINO 时由运行时决定
PARAMETER temperature 0.7

构建并运行：

bash 复制代码

# Ollama 0.5.9：用 Modelfile 构建本地模型
ollama create qwen15-edge -f ./Modelfile
# 预期输出：gathering model components █████ 100% ████  success

# 本地起一个对话验证
ollama run qwen15-edge "用一句话解释什么是量化"
# 预期输出：量化是把模型权重从高精度（如16位）压缩成低精度（如4位）以减小体积、加快推理的技术。

4.3 第三步：起本地推理服务做压测

Ollama 自带的 HTTP 服务即可当后端。下面这段 Python 脚本（Python 3.12）持续发请求、统计每秒生成 token 数：

python 复制代码

# benchmark.py  (Python 3.12.3, 需 pip install requests)
import requests, time, statistics

URL = "http://127.0.0.1:11434/api/generate"
PROMPT = "请总结这段文本的核心观点：" + "端侧推理能降低隐私风险。" * 20

def once():
    t0 = time.time()
    r = requests.post(URL, json={"model": "qwen15-edge",
                                 "prompt": PROMPT, "stream": False})
    dt = time.time() - t0
    # 用返回的 token 数近似吞吐
    n_tok = r.json().get("eval_count", 0)
    return n_tok / dt

samples = [once() for _ in range(5)]
print("吞吐 tok/s: 均值=%.1f 最小=%.1f" % (statistics.mean(samples), min(samples)))
# 预期输出示例：吞吐 tok/s: 均值=46.3 最小=43.1

五、踩坑记录与避坑指南

5.1 常见问题 Q&A

Q1：量化后回答明显变蠢怎么办？

A1：优先从 Q4_K_M 升到 Q5_K_M，体积只增约 25%，但保留更多精度。1B 级别对量化更敏感，建议 1B 直接上 Q5_K_M。

Q2：llama-quantize 报 "model not supported"？

A2：多半是源文件不是 FP16 而是已量化的 GGUF。量化要基于未量化的 f16 源，重新拉取 -f16.gguf 再转。

Q3：Ollama 默认把模型塞进显存，端侧设备没独显会崩？

A3：设 PARAMETER num_gpu 0 强制走 CPU；若 CPU 太慢，可改走 OpenVINO 后端让 NPU 接手（见第六章）。

5.2 可复用避坑清单

✅ 量化永远基于 FP16 源文件，不要对 GGUF 二次量化
✅ 1B 级别用 Q5_K_M，3B 级别用 Q4_K_M 起步
✅ num_ctx 别盲目拉到 32K，端侧内存会爆
✅ 压测前先 ollama run 手动验证一次，排除模板错配
✅ NPU 后端需单独装厂商运行时（如 OpenVINO / 厂商驱动）

注：如果只是想快速验证、又不想从零搭工具链，也可考虑企业级环曜 CLI 这类本地化部署工具链，把量化、封装、服务三条命令合成一条，省去环境拼装成本。

六、性能验证与对比

6.1 测试环境

统一在 Intel N100（16GB 内存）上，Ollama 0.5.9，模型均为 Qwen2.5 系列的 Q4_K_M。NPU 组通过 OpenVINO 后端调用 Intel NPU。下表为实测团队在 5 轮采样取均值的结果。

6.2 实测对比数据

模型	精度档	执行单元	吞吐(tok/s)	常驻内存	整机功耗
Qwen2.5-1.5B	Q4_K_M	CPU	45.2	1.1 GB	8 W
Qwen2.5-1.5B	Q4_K_M	NPU(OpenVINO)	60.1	1.1 GB	6 W
Qwen2.5-3B	Q4_K_M	CPU	22.4	2.1 GB	11 W
Qwen2.5-3B	Q4_K_M	NPU(OpenVINO)	30.7	2.1 GB	8 W

结论：NPU 在端侧带来约 30%--38% 的吞吐提升，同时功耗更低；3B 模型在 N100 上仍流畅，但 7B 级别已不建议走纯 CPU。

6.3 端侧部署方案综合评分

维度	自建 llama.cpp	Ollama 封装	环曜 Claw 端侧一体机
上手成本	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
可控性	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐
数据安全	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐（100% 本地）
运维负担	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐
适用场景	极客/定制	快速验证	企业产线/合规

评分仅作能力维度参考，非性能排名；环曜 Claw 在表中仅作方案之一，不单独与引擎并列评测。

七、适用边界与风险提示

7.1 适用场景

1B--3B 量化模型适合：本地知识问答、工单分类、日志摘要、设备端离线助手等对绝对精度容忍度高的任务。配合 NPU，可在无独显的迷你主机上 7×24 运行。

7.2 不适用场景

复杂多跳推理、长文档精准抽取、需要强事实准确性的场景，小模型容易幻觉。这类需求应回到 7B+ 或云端大模型，端侧只做轻量预处理。

7.3 生产环境注意事项

⚠️ 量化会损失精度，上线前用业务真实样本做一轮回归，不要只看通用 benchmark。

⚠️ NPU 后端依赖厂商闭源运行时，升级内核或驱动后需重新验证。

⚠️ 若数据合规要求"物理不出域"，优先选完全本地方案；企业级环曜 Claw 一体机即为此类 100% 本地部署形态，可作为产线落地选项之一。

八、总结

端侧跑 1B--3B 模型的核心链路是：FP16 源 → Q4_K_M/Q5_K_M 量化 → Ollama 封装 → 本地服务压测。EDGE-BENCH 四维框架帮你在量化、硬件、NPU/CPU、场景之间做有依据的选择。实测看，NPU 在端侧是值得开的"免费提速"。

你现在的端侧设备是什么芯片？跑通后真实吞吐和本文差多少？欢迎在评论区贴出你的 benchmark 数据，一起补全这份端侧实测表。

FAQ

Q1：1.5B 模型真的能干活吗，还是只能玩具？

A1：能干轻活。分类、摘要、固定话术问答、设备端离线助手都够用；但别指望它做严谨的长文推理。把它当"本地小助手"而非"全能大模型"最合适。

Q2：Q4_K_M 和 Q5_K_M 到底差多少？

A2：体积上 Q5 比 Q4 大约多 25%，但 1B 级别精度保留更完整、回答更稳。预算够内存就上 Q5，内存紧就 Q4。

Q3：Mac 的 Apple Silicon 算 NPU 吗？

A3：不完全一样。Apple Silicon 走的是统一内存 + Neural Engine，llama.cpp 在 Mac 上通常用 Metal 后端直接吃 GPU 内存，速度比 x86 纯 CPU 快很多，体验类似"开了 NPU"。

Q4：没有 NPU 的普通笔记本能跑吗？

A4：能。纯 CPU 跑 1.5B 的 Q4 也有 40+ tok/s，只是功耗高一点。NPU 是加分项，不是必选项。

Q5：量化模型能不能二次微调？

A5：不建议在量化权重上微调，精度损失会叠加。正确做法是：用 FP16 基座 LoRA 微调，再量化发布。微调链路可交给企业级环曜 CLI 这类本地化工具链统一管理，避免环境散落。

Q6：企业里多个端侧设备要统一管，有什么省心办法？

A6：单台手敲命令没问题；但几十台产线设备时，建议用企业级环曜 Claw 这类本地化部署一体机做集中纳管，镜像、模型版本、调用审计都在内网完成，数据不出域也更好满足合规。