本地模型还有意义吗：开源与端侧 AI 的工程权衡
并非所有任务都需要最大的云端模型。当数据敏感、延迟敏感、成本需要可控时，本地模型会重新变得重要。本文讲清量化的代价、引擎的分工与硬件估算。
什么时候值得本地部署
本地不是“更小就更差”，而是在用通用能力换四个确定性收益：隐私（数据不出设备，医疗/法务/企业内部文档最敏感）、延迟（无网络往返，本地 7B 模型首字延迟可低至百毫秒级）、成本（无按 token 计费，长尾高频调用摊薄后显著便宜）、离线/可控（无供应商限流、可固定版本、可审计权重）。当任务以分类、抽取、改写、本地知识问答为主，且不需要跨全网推理时，本地往往更合适。反之，需要最强推理、海量实时知识、多模态生成的任务，仍应交由云端大模型。
量化原理：用精度换显存，代价是多少
大模型权重默认是 FP16（每个参数 2 字节）。量化把权重压到更低比特以省显存：8-bit（INT8）通常几乎无损，4-bit（INT4/NF4）能塞下更大模型但精度可见下降，2-bit 基本只用于极限实验。一个 7B 模型 FP16 约需 14GB，量化到 4-bit 后约 4–5GB，可在消费级显卡甚至高端笔记本跑起来。格式上 GGUF 是 llama.cpp 生态的通用容器，支持元数据与多量化档位；imatrix（重要性矩阵）是一种量化校准技术，用一批代表性文本统计每层权重的重要性，对关键权重保留更多精度，能明显缓解 4-bit 的质量下滑。权衡口诀：能 8-bit 就不 4-bit，要 4-bit 就上 imatrix。
| 精度 | 7B 显存约 | 质量损失 | 适用 |
|---|---|---|---|
| FP16 | 14 GB | 无 | 训练/高精度推理 |
| INT8 | 7 GB | 极小 | 大多数生产推理 |
| INT4/NF4 | 4–5 GB | 可见 | 消费级/端侧 |
| INT4+imatrix | 4–5 GB | 较小 | 端侧首选 |
推理引擎：各自的定位不同
选引擎看“跑在哪、要什么”。llama.cpp 是 C/C++ 实现、零依赖、跨平台（CPU/GPU/NPU 都支持），GGUF 生态事实标准，适合端侧与极简部署。Ollama 在 llama.cpp 之上包了友好 CLI 与模型管理，本地开发体验最佳，但生产可控性弱于直接调接口。vLLM 面向服务端高并发，靠 PagedAttention 把显存碎片降到最低、吞吐极高，适合云端多用户批量推理。MLX 是 Apple 芯片原生框架，充分利用统一内存，Mac 上跑本地模型效率与体验最佳。一句话：端侧/桌面选 llama.cpp·MLX，开发玩具选 Ollama，服务端高并发选 vLLM。
# 本地一条龙：拉取 + 量化 + 启动（llama.cpp 风格）
# 1) 转 GGUF 并做 imatrix 量化
python convert_hf_to_gguf.py ./Qwen2.5-7B --outfile qwen.gguf
./llama-quantize --imatrix imatrix.dat qwen.gguf qwen-Q4_K_M.gguf Q4_K_M
# 2) 启动本地服务（兼容 OpenAI 接口）
./llama-server -m qwen-Q4_K_M.gguf -c 8192 --host 127.0.0.1 -p 8080
# 3) 调用方式与云端一致
curl http://127.0.0.1:8080/v1/chat/completions -d '{"model":"qwen","messages":[{"role":"user","content":"总结这段日志"}]}'硬件估算：模型尺寸 vs 显存
粗略公式：推理显存 ≈ 参数量 × 每参数字节数 + 上下文/KV cache 开销 + 框架占用。以 7B 为例，4-bit 权重约 3.5GB，加上 KV cache 与框架，实际需 5–6GB 空闲显存；13B/4-bit 约需 9–11GB；70B/4-bit 则需 40GB+，基本要多卡或纯 CPU 慢速跑。KV cache 随上下文长度线性增长，长文档问答要预留额外显存。Mac 的统一内存是个例外：MLX 可把权重放共享内存，48GB 内存的 Mac 能跑 30B 量级模型，只是速度不如独显。
端侧 NPU 与手机部署的现实
手机/PC 的 NPU 正在让“设备上的 AI”成真：直接处理本地笔记、截图、语音，响应即时且离线可用。但现实约束很硬——端侧通常是 1–3B 的小模型，复杂推理能力有限；权限更敏感，应用必须明确告知“数据在哪处理、保存多久、能否关闭”。部署上常用厂商工具链（如高通 AI Engine、Core ML、MediaPipe）把模型编译成端侧运行时。务实做法是：端侧只做轻量任务（摘要、改写、分类、本地检索），把重推理路由给云端。
云端 + 本地混合路由：一张选型表
二者不是二选一。按任务路由才是工程常态：本地模型承担隐私敏感与简单高频任务，云端模型承担复杂推理与多模态。路由依据可以是任务分类器、延迟预算或成本阈值。
| 任务特征 | 路由目标 | 理由 |
|---|---|---|
| 含隐私/内部数据 | 本地 | 数据不出设备 |
| 简单分类/抽取/改写 | 本地 | 小模型够用、零成本 |
| 高频长尾调用 | 本地 | 摊薄云端成本 |
| 复杂推理/规划 | 云端 | 需最强模型 |
| 多模态/实时联网 | 云端 | 端侧能力不足 |
| 延迟极低且离线 | 本地 | 无网络往返 |
模型的未来不只有“更大”，也会朝着更小、更快、更贴近设备与场景的方向发展。用精度换显存、用对引擎、算清硬件、做好混合路由，本地模型就能在隐私、延迟与成本上给出云端给不了的答案。