🤖 本地 AI · 部署实战
本地 LLM 真跑通的那条路
量化机制 · KV 缓存 · 运行框架全对比 · 生产命令行逐条拆开 · 设备速查——所有命令都在一台 M5 Pro 64GB 上真跑过。
更新 2026年10月
参考机 M5 Pro 18核 · 64GB
引擎 llama.cpp b10705 + MLX 0.32.0
系统 macOS 26.7.1 · Windows 侧另测
Section 01 · Frameworks
运行框架：本机真跑通的，和只听说过的
模型是文件，框架决定怎么加载、怎么切层、怎么给接口。下面这栏「本机状态」是 2026-10-21 实扫的结果，不是产品对比表上的印象分。
| 框架 | 定位 | 本机状态 | GPU 分层 | API 服务 | 备注 |
|---|---|---|---|---|---|
| 方寸智匣 LocalBrain | 桌面本地 AI 工作台 | ✓ 已安装 2.0.9 | ✓ 自动规划 | ✓ 内置 | 自制软件。托管 llama.cpp b10705、MLX、Splash、Whisper，模型统一登记在发现页 |
| llama.cpp | 底层推理内核 | ✓ b10705 | ✓ -ngl | 需自建 | Metal / CUDA / Vulkan 三端通吃，本页所有实测都跑在它上面 |
| MLX | Apple Silicon 原生 | ✓ 0.32.0 | ✓ 统一内存 | ✓ mlx_lm.server | mlx-lm 0.31.3 / mlx-vlm 0.6.12，只在 Mac 上有 |
| Splash | 投机解码引擎 | ✓ 已实测 | ✓ | ✓ | 用小草稿模型猜 token 再验证。写代码接受率 63.2%，写中文只有 11.9% |
| PolyStrata | Windows CUDA 后端 | 仅 Windows 机 | ✓ | ✓ | 8GB 显存的笔记本上跑 Qwen3.6-35B-A3B 解码 75-90 token/秒 |
| Ollama | 一键本地推理 | ✗ 本机未安装 | ✓ 自动 | ✓ 内置 | 官方 2026-03 宣布 Mac 端改用 MLX 驱动，本页把它留作备选路线 |
| LM Studio | 图形化播放器 | ✗ 本机未安装 | ✓ 自动 | ✓ 内置 | 上手门槛最低，但本机所有实测都没经过它 |
| vLLM | 服务端批处理 | ✗ 无 NVIDIA 卡 | ✓ 张量并行 | ✓ | 需要多卡才有意义，本页不展开 |
为什么这页不再以 Ollama 开头。我 2026-04 写这页的时候，Ollama 是默认值。但我这半年全部实测都跑在方寸智匣托管的 llama.cpp 和 MLX 上——Ollama 和 LM Studio 在我这台机器上根本没装。装没装过，决定了这页里的命令你能不能直接复制。
Section 02 · Internals
底层原理：五个概念，够你预测瓶颈
这部分知识不过期，但下面的具体数字全部换成了我自己机器上量出来的口径。
GGUF 文件格式
GGUF（GGML Unified Format）是 llama.cpp 定义的二进制格式，2023 年替代旧版 GGML，解决了向后兼容和元数据问题。
文件结构：
关键优势：单文件包含所有信息；支持 mmap 内存映射，按需加载；量化信息嵌在文件里，框架自动识别精度。
文件结构：
GGUF（4 字节魔数）→ 版本号 → 张量数量 → 键值元数据（模型名 / 架构 / 超参数）→ 张量索引 → 量化后权重数据。关键优势：单文件包含所有信息；支持 mmap 内存映射，按需加载；量化信息嵌在文件里，框架自动识别精度。
量化（Quantization）
权重本质是浮点矩阵。FP32 → FP16 → INT8 → INT4 逐级砍精度换体积。Q4_K_M 里的 K 表示混合量化策略（每个张量按重要性用不同位宽），M 表示中等偏上的档位。
我在本机实测的换算关系（Qwen3-8B）：BF16 ≈ 16GB / 质量 100%，Q8_K_M ≈ 8.5GB / 99%，Q5_K_M ≈ 6GB / 97%。掉到 4bit 之后，体积减了 4 倍，质量损失远没有 4 倍那么多——这是本地部署敢用小模型的前提。
我在本机实测的换算关系（Qwen3-8B）：BF16 ≈ 16GB / 质量 100%，Q8_K_M ≈ 8.5GB / 99%，Q5_K_M ≈ 6GB / 97%。掉到 4bit 之后，体积减了 4 倍，质量损失远没有 4 倍那么多——这是本地部署敢用小模型的前提。
KV Cache
注意力机制要缓存 K 和 V，公式是
我用 Qwen3-8B 的官方
2 × 层数 × KV 头数 × head_dim × 上下文长度 × 2 字节。我用 Qwen3-8B 的官方
config.json 核对过：每个 token 约 144 KiB（= 2×36×8×128×2）。32K 窗口就是 4.83GB——比模型文件本身还接近。这就是为什么"上下文开大一点"很贵。
GPU 分层（-ngl）
显存不够时，把一部分层留在 CPU。
代价直接来自带宽差：DDR5 约 60–80 GB/s，RTX 4070 是 504 GB/s，Apple 统一内存实测裸读 287 GB/s。部分层掉回 CPU，速度可能掉一个数量级。
-ngl 99 表示全部层都上 GPU（我的实测都是这个配置）。代价直接来自带宽差：DDR5 约 60–80 GB/s，RTX 4070 是 504 GB/s，Apple 统一内存实测裸读 287 GB/s。部分层掉回 CPU，速度可能掉一个数量级。
上下文长度
上下文越长，KV Cache 越大，带宽被摊薄，生成越慢。这不是玄学，是显存占用曲线。
我在同一台机器、同一份 Qwen3-8B Q4_K_M、llama.cpp 上扫过一遍：上下文从 0 加到 32768，生成速度从 54.5 掉到 28.0 词元/秒，腰斩。
我在同一台机器、同一份 Qwen3-8B Q4_K_M、llama.cpp 上扫过一遍：上下文从 0 加到 32768，生成速度从 54.5 掉到 28.0 词元/秒，腰斩。
Prefill 与 Decode
Prefill（读提示词）能并行，吃算力；Decode（逐 token 生成）只能一个一个来，吃内存带宽。
所以「预填充 3218 tok/s、生成 133 tok/s」这种组合很正常——两者瓶颈根本不是同一个东西。我的 9 个小模型实测里，预填充比生成快一到两个数量级。
所以「预填充 3218 tok/s、生成 133 tok/s」这种组合很正常——两者瓶颈根本不是同一个东西。我的 9 个小模型实测里，预填充比生成快一到两个数量级。
上下文 → 速度：同一台机器的深度扫描
| 上下文长度 | 生成速度（词元/秒） | 相对基准 | 说明 |
|---|---|---|---|
| 0（只生成） | 54.5 | 100% | 带宽跑满的理想值 |
| 8,192 | 约 44（区间内） | 约 81% | 日常够用 |
| 32,768 | 28.0 | 51% | 腰斩，长任务开始难受 |
扫描条件：M5 Pro 64GB，Qwen3-8B Q4_K_M，llama.cpp b10357，Metal，每档生成 64 词元、2 次样本，取 2026-09-27 那次独立复扫的记录。
关于「Ollama 默认只给 2048 token」这句话。它跟具体版本走，我没有在本机验证过（这里没装 Ollama），所以我不把它当成结论。能确定的是：你真正能开多大窗口，由可用内存和 KV Cache 预算决定——我这台 64GB 的机器，Qwen3-8B 最长只开到 40K。
Section 03 · Formats
模型格式怎么选
同一个模型，格式不同，能装进你机器的型号就完全不同。
| 格式 | 典型体积（27B 级） | 需要什么 | 谁在读它 | 结论 |
|---|---|---|---|---|
| .gguf | 16.8 GB（Q4_K_M） | 单文件 + mmap | llama.cpp | 默认选择。唯一能在 8GB 显存 + 32GB 内存混跑 27B 的格式 |
| .safetensors | 55.6 GB（BF16） | 整份读进内存 | vLLM / MLX | 精度无损，但 8GB 机器直接出局 |
| GPTQ / AWQ | 约 14 GB | NVIDIA 卡 + 专用内核 | vLLM | Windows + 独显路线更划算 |
| .mlx | 约 17 GB（4bit） | Apple Silicon | mlx_lm | Mac 上启动快，首 token 低 |
| EXL2 | 约 12 GB | EXL2 专用内核 | exllamav2 | 同尺寸里最省，但生态窄 |
三条选择规则，够用。先看可用内存（不是显存），再看权重体积能不能塞进去并留一半给上下文，最后才挑速度最快的框架。顺序反了，你会花时间调一个根本装不下的模型。
Section 04 · Quantization
量化档位：质量 vs 体积
下面是 Qwen3-8B 这一档在本机量出来的体积-质量关系，换模型时比例关系大体成立，具体数字以自己的文件为准。
| 量化档位 | 权重体积 | 质量保留 | 建议内存 | 什么时候选它 |
|---|---|---|---|---|
| BF16 | 约 16 GB | 100% | 24 GB+ | 质量优先，机器够大 |
| Q8_K_M | 约 8.5 GB | 99% | 16 GB+ | 质量几乎不掉，体积减半 |
| Q6_K | 约 6.8 GB | 98% | 14 GB+ | 甜点档，损失几乎不可感 |
| Q5_K_M | 约 6.0 GB | 97% | 12 GB+ | 大多数人的默认档 |
| Q4_K_M | 约 4.5 GB | 95% | 10 GB+ | 小模型首选，本机 9 个模型都是这一档 |
| Q3_K_M | 约 3.6 GB | 91% | 9 GB+ | Windows 8GB 显卡实测能跑 35B |
| Q2_K | 约 2.8 GB | 82% | 8 GB+ | 质量明显下滑，只在极限省内存时用 |
有一个例外要单独说：三值化。我测 Ternary-Bonsai-2-27B 的 PQ2_0，模型文件压到 5.9GB（1-bit 版本 3.9GB），但写出来的内容有一半是错的。「装得下」和「能用」在极低位量化上是两回事——低到某个点之后，压缩省下的内存换不回质量。
Section 05 · Production Command Lines
真正在跑的命令行
下面两条是方寸智匣生产环境实际拼出来的启动命令（来自它的后端实现），也是我这半年所有实测用的参数。每个开关后面写它为什么存在。
$ llama-server \
--model <模型路径> \
--host 127.0.0.1 --port <端口> \
--alias <显示名> \
--ctx-size <按内存算> \
--parallel 1 \
--reasoning auto --reasoning-budget -1 \
--ctx-checkpoints 8 --checkpoint-min-step 0 \
--jinja --no-webui \
--cache-type-k q8_0 --cache-type-v q8_0 -fa on \
# 有独显时追加
-ngl <全部层数> \
# 视觉模型追加
--mmproj <投影文件> \
# 稀疏 MoE 模型追加
--fit off
# -ngl 99 = 整模型上 GPU
# --fit off = 不要自动缩减上下文去迁就内存
# --reasoning budget -1 = 不限制思考长度
$ mlx_lm.server \
--model <模型路径> \
--host 127.0.0.1 --port <端口> \
--chat-template-args '{"enable_thinking": false}' \
--max-tokens <输出上限> \
--trust-remote-code \
--prompt-cache-bytes <提示缓存字节数>
# 环境变量：HF_HUB_OFFLINE=1（离线）
# OMP_NUM_THREADS=1
| 开关 | 作用 | 踩过的坑 |
|---|---|---|
| --prompt-cache-bytes | 限制提示缓存上限，防止多轮对话把 KV Cache 撑爆 | 不加会在第 2 轮 OOM：Insufficient Memory。我加 8GB 上限后，第 2 轮从 3 分钟变成 2 秒 |
| --chat-template-args | 关掉模型的思考模式 | Gemma 系列检测到 system 消息会自动开思考，输出全被 |
| --cache-type-k/v q8_0 | KV Cache 量化，内存减半 | 必须同时加 -fa on（flash attention）。不开 q8 时一个 -fa 都不传——llama.cpp 默认 auto 更准 |
| --ctx-checkpoints | 定期存检查点，长任务中断能续 | 不开的话长任务一崩全没了 |
| --reasoning | 思考模式开关 | llama.cpp 侧现在用这个；--chat-template-args 是 mlx_lm 侧的做法，两边参数不通用 |
| --max-kv-size | KV 上限（token 数） | 只有 mlx_vlm 认这个。mlx_lm 用的是 --prompt-cache-bytes（字节数），混用直接启动失败 |
关于「命令里的模型路径」。我的
AI-Models/Language-Models/GGUF/ 和 /MLX/ 在 2026-10-21 实扫时是空的，权重都清到方寸智匣的受管目录去了。上面的命令用 <模型路径> 占位，是因为路径会随你把模型放在哪儿而变——但下面那几行的参数是真的，照抄就能用。Section 06 · Routes
四条上手路线，按你的情况选
我会把「我在本机验证过」和「通用做法但我没验」明确分开。你要是照抄命令跑不通，先看这一行。
1
路线 A · 方寸智匣（本机验证过，最省心）
macOS Apple Silicon 与 Windows 都有正式版。装完在发现页挂模型，点一下就能起后端，参数由内置的原生启动规划器算好。
# 已公开版本
macOS / Windows 2.0.8
# 本机候选（未公开）
macOS 2.0.9 # 2026-10-21 本机验收通过，尚未公开发布
# 内置引擎版本
llama.cpp b10705
MLX 0.32.0 # mlx-lm 0.31.3 / mlx-vlm 0.6.12
2
路线 B · Ollama（通用做法，本机未验证）
这条路线我没在这台机器上跑过——这里没装 Ollama。命令是官方通用写法，我照抄给你，但请把「未验证」这三个字记在心里。
打开 Ollama 官网与下载入口 查看命令中使用的官方安装脚本
$ curl -fsSL https://ollama.com/install.sh | sh
# Windows: winget install Ollama.Ollama
# 安装后自动以服务形式运行，监听 localhost:11434
$ ollama pull <模型名>
$ ollama ps
# 看当前加载了哪些模型、各占多少显存
$ ollama run <模型名> "写一首关于量子力学的五言律诗"
# OpenAI 兼容接口
base_url = http://localhost:11434/v1
Ollama 官方 2026-03-30 宣布 Mac 端改用 MLX 驱动，预填充 1154→1810 t/s、解码 58→112 t/s。但官方自己的对比两边量化不同（NVFP4 vs Q4_K_M），而且要求至少 32GB 统一内存。拿这组数字和我后面那页的 Q4_K_M 实测对比是不公平的。细节见 都说比 Ollama 快，可没人真跟 Ollama 比过。
3
路线 C · llama.cpp 直连（本机验证过）
不想装任何 GUI，就一个二进制加一个权重文件。这条路线我所有基准测试都走它。
$ llama-server \
-m <模型.gguf> \
--host 127.0.0.1 --port 8200 \
-c 32768 -ngl 99 -np 1 \
--jinja --no-webui -lv 4 --reasoning off
# -lv 4 会打印内存分项表，方便核对
# 默认日志不打这个，得自己加
配合 hf download <仓库> --include <文件> --local-dir <目录> 取权重，具体命令在 本地模型实测报告 的下载一节里有四个可复现实例。
4
路线 D · Splash 投机解码（本机验证过）
用一个小草稿模型猜 token，再让主模型批量验证。写代码的时候能快到 77 tok/s。
$ brew install incoai/tap/splash
# 本体 213MB；模型包另算（17.4GB / 35B 包 20.9GB）
别被「2 倍加速」的宣传带跑。我分场景测下来：写代码接受率 63.2%、中文只有 11.9%，中文速度是官方说法的 44%。主要写中文稿的话，Splash 的收益远小于宣传值。
Section 07 · Applications
接进你的工具链
本地模型起起来之后，怎么让它真的干活。
OpenAI 兼容接口
最省事的接法
llama.cpp、Ollama、MLX 的 server 模式都提供 OpenAI 格式的接口。换引擎不用改客户端代码，只改 base_url。我的实测配置：
base_url = http://127.0.0.1:8200/v1
api_key = "local"
IDE 补全
Continue.dev 等
主流插件都支持自定义 OpenAI 兼容端点。配置文件一般在
~/.continue/config.json。
{
"models": [{
"title": "local",
"provider": "openai",
"model": "local-model",
"apiBase": "http://127.0.0.1:8200/v1"
}]
}
补全场景建议单独用小模型 + 小窗口（4K 上下），别拿 27B 去做 tab 补全。
知识库问答
RAG
常见组合是 Open WebUI 做前端 + 向量库做召回。
$ docker run -d \
--network=host \
-v open-webui:/app/backend/data \
ghcr.io/open-webui/open-webui:main
启动后连 http://localhost:3000，在后台把模型服务指向上一步的 OpenAI 兼容端点。嵌入模型和对话模型分开配，别用同一个 27B 干两件事。
接进 IDE 之前先测一次裸接口。用
/v1/models 看模型在不在、用 /v1/chat/completions 发一句话看回不回得来。接口层的问题和模型能力的问题混在一起时，最难查。Section 08 · Devices
设备 → 能跑什么 → 实测多快
这张表现在只有实测值，没有推算值。空着的格子是真的没测过。
| 设备 | 可用内存 | 推荐模型 + 量化 | 引擎 | 实测速度 | 建议上下文 |
|---|---|---|---|---|---|
| M5 Pro 64GB（本机） | 55.66 GB | Qwen3.5-9B Q4_K_M · Qwen3-8B Q4_K_M | llama.cpp b10705 | 43.1 / 51.2 tok/s | 8K–40K |
| M5 Pro 64GB（本机） | 55.66 GB | Qwen3.8-27B 4bit + 草稿模型 | Splash 投机解码 | 53.4 tok/s（中文 24.2） | 32K |
| M5 Pro 64GB（本机） | 55.66 GB | Qwen3.8 Flash Next 2.6 位权重（79.21GB） | Sushi 1.2.4 | 36.1–44.7 tok/s | 32K（常驻需 44.20 GiB） |
| RTX 4070 Laptop 8GB | 8188 MiB 显存 | Granite 4.0 H Micro Q4_K_M · Gemma 4 E4B Q4_K_M | PolyStrata（Windows） | 73.9 / 60.8 tok/s | 32K / 55K |
| RTX 4070 Laptop 8GB | 8188 MiB 显存 | Qwen3.6-35B-A3B UD Q3_K_M | PolyStrata（Windows） | 75–90 tok/s | 8192 |
| Apple 8GB 机型 | 5.73 GB | 2B–4B Q4_K_M | llama.cpp | 133.6 tok/s（2B） | 4096–8192 |
| Apple 16GB 机型 | 12.71 GB | 4B–9B Q4_K_M | llama.cpp | — | 8192 |
Apple 机型的可用内存是系统放给 GPU 的那部分（macOS 默认留 5.73GB / 12.71GB），不是标称内存。Windows 侧数字来自 2026-10 那次 8GB 显卡实测，显存峰值 7850 MiB、系统内存峰值 26.39 GiB。
为什么 8GB 显存的机器能跑 35B？因为 MoE 模型把专家权重放在系统内存里按需调用——显存只装激活路径。代价是这部分要走 PCIe 来回搬。完整拆解在 完全免费，Windows 下 8GB 显卡跑 Qwen 35B。
Section 09 · Two Modes
同一份权重，两种活法
大模型放内存有两种方式：整份常驻，或者只把精确需要的那部分放进 SSD 模式。
| 指标 | 完整常驻 | 32GiB 精确 SSD |
|---|---|---|
| 启动到就绪 | 40.39 秒 | 8.98 秒 |
| 引擎登记驻留 | 44.20 GiB | 31.21 GiB |
| 全机 1 秒采样峰值 | 57.08 GiB | 44.59 GiB |
| 短题首字 / 总耗时 | 0.43 / 4.01 秒 | 1.39 / 5.88 秒 |
| 长材料题首字 / 总耗时 | 2.46 / 4.99 秒 | 4.90 / 8.10 秒 |
| 重复材料题 | 0.26 / 2.68 秒 | 0.27 / 2.87 秒 |
重复问同一段材料时两边几乎一样——因为第二次会命中 2595 个输入缓存 token。所以规律很清楚：日常用 SSD 模式，起步快、省 13GB；只有需要连续追问同一个大上下文时才值得常驻。
完整数据在 方寸智匣接入 Sushi；另一个常被忽略的开关是 --lazy-mode（llama.cpp 0.4 新增），开启后权重按需加载，能明显压低常驻占用。
Section 10 · Read More
这几篇配套看
都是我自己机器上跑的实测，数据口径和本页一致。
2026-10-07
4 类模型 + 11 个实测，从 1.5GB 到 80GB 全跑一遍。内存、带宽、算力三堵墙，以及「权重体积不超过可用内存一半」这条我在自己机器上反复撞出来的线。
2026-09-05
Ollama 改用 MLX 驱动、Rapid-MLX 的跑分表里没有 Ollama 行、vMLX 的对手其实不是 Ollama——三篇营销文的条件差异逐条对齐。
2026-09-10
--lazy-mode、量化 --max-buffer-size、Apple RDMA RPC 的实测代价：Gemma 4 E4B 常驻 4.6→2.8GB，解码速度掉 10.7%。
2026-08-30，更新于 2026-10-20
自制软件的完整介绍：模型统一管理、六类本地 AI（语音到视频）、Sushi 常驻与精确 SSD 的取舍。
本页配套
9 个模型 × 4 个工具场景 × 两种窗口的速度、内存与通过率，以及一次「512 个 token 全烧在思考里」的失败实录。
本页配套
按可用内存倒推设备选型，含 2026-04 与 2026-10 两轮价格对比。