本地大模型：从跑起来到跑得好

0. 太长不读

很多人玩本地大模型，卡住的地方不是模型太复杂，而是不知道自己卡在哪一层。

你以为是在跑一个模型，其实是在同时做五个决定：硬件、内存、Runtime、模型选择、量化。每一层都有坑，每一层都可以单独优化，但它们又互相约束。后面所有问题，基本都能归到这五层里。

两条读法：如果你只是想跑起来，读到第 1 节就可以动手。如果你已经在调速度、上下文和量化，第 3 到第 6 节会更有用。

1. 先跑起来

别一上来就研究 70B、Q4、GGUF。先让一个模型在你机器上说话。

Apple Silicon Mac (Mac Studio or Macbook Pro) 是目前最简单的起步平台。三行命令，10 分钟内搞定：

bash brew install ollama # 没有 Homebrew 的，去 ollama.com 直接下载安装包 ollama pull qwen3:8b # 如果 tag 不存在，去 ollama.com/library 查当前可用 tag ollama run qwen3:8b

选 qwen3:8b 的原因：够小（Q4 量化约 5GB），够聪明，8GB 内存也能跑，中英文都行。第一次不需要在模型选择上花时间。

模型下载完跑起来，会看到 >>> 提示符。随便问它一个问题，等它开始回答。装完之后顺手看两个命令：

ollama list # 已安装模型：名称、量化版本、文件大小 ollama show qwen3:8b # 模型详情：量化级别、chat template、层数、context length

读懂这些数字：

• tokens/s（TPS）：生成速度。Apple M 系列，8B 模型通常在 20-60 TPS，体感流畅。低于 5 TPS 说明内存或量化有问题。

• prompt eval：首字延迟。和模型大小、上下文长度有关。

• 内存占用：占比超过 80% 就要开始小心——系统开销会推高延迟，甚至触发 swap。

跑起来了。现在开始拆层。

2. 硬件：内存带宽才是核心指标

很多人选硬件时盯着 GPU 算力（FLOPS）。对本地大模型来说，这个直觉是错的。

本地推理很多时候不是算不动，是读不快。每生成一个 token，模型权重要被搬一遍。带宽就是上限。

这解释了为什么 Apple Silicon 在本地 LLM 上的表现经常超过预期。

Apple Silicon 路径

M 系列芯片用的是统一内存架构（Unified Memory）：CPU 和 GPU 共享同一块内存池，没有独立显存，权重从内存到 GPU 核心的路径极短，带宽效率远高于 PCIe 连接的独立显卡。

• MacBook Pro M4 Max：有 410 / 546 GB/s 两档，128GB 配置通常对应高配 16-core CPU / 40-core GPU，带宽 546 GB/s

• Mac Studio M3 Ultra：内存带宽 819 GB/s，可选大内存配置，是本地跑大模型最顺手的 Apple desktop 路径

NVIDIA 路径

• RTX 4090（24GB VRAM）：内存带宽约 1008 GB/s，单卡消费级天花板

• RTX 3090（24GB VRAM）：带宽约 936 GB/s，价格更低，支持 NVLink 多卡

• 多卡方案：3090 可以走 NVLink 池化显存；4090 多卡通常是模型切分/并行，不能简单理解成 2×4090 = 48GB 可用显存，复杂度高

• 数据中心卡（A100、H100）：带宽显著更高，价格差距更大，不是消费场景的选项

3. 算清楚需要多少内存

硬件只是上限。真正决定能不能跑起来的，是内存账。

本地跑模型的内存需求可以拆成两部分：

总内存需求 ≈ 权重内存 + KV Cache + 运行时开销

权重内存很好算：

权重内存 = 参数量 × 每参数字节数

FP16 / BF16 ≈ 2 bytes/参数 → 8B FP16 ≈ 16 GB Q8 ≈ 1 byte/参数 → 8B Q8 ≈ 8 GB Q4 ≈ 0.5 byte/参数 → 8B Q4 ≈ 4 GB（+20% 开销约 5 GB） Q3 ≈ 0.375 byte/参数 → 8B Q3 ≈ 3 GB

8B FP16 ≈ 16GB，Q8 ≈ 8GB，Q4 ≈ 4-5GB。这就是为什么 Q4 是甜点。

KV Cache 是第二个变量，也是很多人忽略的那个：

KV Cache ≈ 2 × num_layers × num_kv_heads × head_dim × seq_len × batch_size × bytes/element

注：现代模型普遍使用 GQA（Grouped Query Attention）或 MQA（Multi-Query Attention），KV heads 数量少于 attention heads，所以公式里用 num_kv_heads，不是全部的 num_heads。对单人聊天来说 batch_size 通常接近 1。

KV Cache 按 ctx_size 线性增长。128K vs 4K 是 32× KV Cache；但总内存增长多少，要看权重和 KV Cache 各占多大比例。

ctx_size 是内存刺客

这是新手最容易踩的坑。很多人以为加载完模型就定了，其实 context window 大小才是真正的内存变量。

bash

bash

通过 API 参数控制 context size（不同版本 Ollama 参数写法会变，核心是把 num_ctx 调到目标值）

curl http://localhost:11434/api/generate
-d ‘{ “model”: “qwen3:8b”, “prompt”: “解释 KV Cache”, “options”: { “num_ctx”: 32768 }, “stream”: false }’

qwen3:8b 默认的 ctx 是 4096。开到 32K，内存占用差距主要来自 KV Cache 这一项。这不是 bug，是设计——更长的上下文需要更多 KV Cache 来存已经计算过的 token。

这张图不要看绝对数，先看比例：同一个模型，4K 和 32K 配置的差距主要来自 KV Cache 那一段。

实用速查表：按模型大小（Q4）

4. Runtime：选对工具，不用多想

你以为自己在用 qwen3:8b，其实先接触到的是 Ollama。模型怎么加载、template 怎么套、GPU 卸几层，都是 runtime 先替你决定的。在你真正懂模型之前，runtime 就已经做了一堆选择。

Runtime适合谁核心特点Ollama新手首选一键安装，自动处理 prompt template，内置本地 APIllama.cpp进阶用户Ollama 的底层引擎，参数控制最细，可独立使用MLXApple Silicon + 愿意调参Apple 原生框架，部分场景速度最快LM Studio不想碰命令行GUI，模型库集成，拖拽式操作

进阶用户想精细控制，可以跳过 Ollama，直接用 llama.cpp。Ollama 替你处理的那些参数，这里全部手动指定：

bash

bash ./llama-cli
–model ./models/Qwen3-30B-A3B-Q4_K_M.gguf
–ctx-size 32768 \ # context 大小 –n-gpu-layers 99 \ # 卸到 GPU 的层数，99 = 全部 –flash-attn on \ # Flash Attention –jinja # 使用模型自带 chat template，能减少 prompt format 踩坑

–jinja 这个 flag 值得单独说一句：让 llama.cpp 读取模型自带的 chat template，而不是依赖默认格式。加上它，很多莫名其妙的质量问题会消失。

本地模型不只是聊天 UI。跑起来之后，它可以通过 API 接进你的 agent、脚本和工具链：

bash

Ollama 本地原生 API（/api/generate）

curl http://localhost:11434/api/generate
-d ‘{ “model”: “qwen3:8b”, “prompt”: “用三句话解释什么是 KV Cache”, “stream”: false }’

如果要接 OpenAI-compatible client，用 /v1/chat/completions 路径

你的代码只要改一个 base_url，就能从云端模型切到本地

最后一个边界要说清楚：这篇文章讲的是本地单机推理，不是生产级多用户 serving。如果你需要跑一个多人共用的推理服务，那是 vLLM、SGLang 的领域，逻辑和本文完全不同。

5. 模型选择：先读懂模型名字

HuggingFace 上一个模型的文件名可能长这样：

Qwen3-30B-A3B-Q4_K_M.gguf

每一段都有意义。读懂它，你就知道自己在下载什么。

片段含义

• Qwen3模型家族（Alibaba 出品，第三代）

• 30B总参数量：300 亿

• A3B: Activated 3B：MoE 架构，每次推理只激活约 30 亿参数

• Q4_K_M4-bit K-means 量化，Medium 变体.gguf文件格式：llama.cpp 生态，权重 + 元数据一体

5a. Base / Instruct / Chat

同样叫 Qwen 或 Llama，Base 和 Instruct 不是一个使用场景。Base 会续写你，Instruct 才会听你。Chat 是在 Instruct 基础上再做了对话格式优化。本地跑几乎都要 Instruct 或 Chat 版本。Base 是给继续训练用的。

Prompt format 的坑

Instruct 模型对 prompt 格式高度敏感。不同模型家族有不同的 chat template，Qwen3 和 Llama 3 的格式不一样：

错误做法（直接把问题丢给模型）： “请解释一下 KV Cache”

正确格式（Qwen3 的 chat template，示意，优先让 runtime 读取模型自带 template）：

<|im_start|>system You are a helpful assistant. <|im_end|> <|im_start|>user 请解释一下 KV Cache <|im_end|> <|im_start|>assistant

Ollama 会自动应用正确的 template，–jinja 的 llama.cpp 也会。格式用错，模型质量会莫名其妙地差——这是真实踩坑，经常被误诊为“这个模型不行“。

5b. 量化：内存和质量的取舍

量化就是把 16GB 的 8B FP16，压到大约 5GB 的 Q4。你损失一点精度，换来它真的能塞进机器。

FP16/BF16 → Q8 → Q6 → Q4 → Q3 → Q2 精度：高 ←————————————————→ 低 体积：大 ←————————————————→ 小

K-quants：Q4_K_M 里的 K 是 K-means 聚类，_M/_S/_L 是 Medium/Small/Large，指量化粒度。同 bit 位数下，K-quants 的质量通常优于普通均匀量化。

选量化的实用规则：

• 内存够 → Q8

• 质量优先、内存有限 → Q5_K_M 或 Q6_K_M

• 日常主力 → Q4_K_M（甜点）

• 内存逼着你 → Q3（谨慎），Q2 基本不推荐

一个反直觉的结论：很多日常任务里，一个 Q4 的 8B 往往比 FP16 的 3B 更值。不是因为量化没有损失，而是模型规模带来的收益通常大过 Q4 的损失。选大一点的模型做 Q4，通常比选小模型跑 FP16 更值。

量化内存节省质量风险最适合场景避免当Q8低（vs FP16 约 -50%）极低内存够、质量优先内存紧张Q6_K中很低质量敏感但内存有限—Q5_K_M中低平衡选择—Q4_K_M高可接受**日常主力（甜点）**对质量极度敏感Q3_K_M很高中内存逼得你没选择代码/推理任务Q2_K极高高基本不推荐几乎所有认真任务

5c. MoE：total parameters 和 active parameters 不是一回事

MoE 最容易误解的地方，就在这里。A3B 这个后缀，是在告诉你：它总共有 30B，但每次推理只激活约 3B。

• 内存需求看总参数：权重全部要加载进内存

• 计算量看激活参数：只有这部分参与当次推理运算

所以 30B-A3B：内存要装得下 30B 的权重（约 18GB @ Q4），计算量更接近 3B——但实际推理速度还受总权重读取速度、runtime 实现和硬件带宽影响，不是纯粹的 3B 速度，但明显比 Dense 30B 快。

MoE 让你在同样内存里尝试更高总参数量的模型，但质量仍然取决于训练、数据、路由和量化，不是 MoE 天然更聪明。32GB 跑不了 Dense 70B，但能跑 MoE 30B-A3B，值不值得试，要看具体任务。

模型不是越大越好：跑本地 agent 做工具调用，延迟和指令遵循稳定性可能比 benchmark 排名更关键。一个响应快、能稳定 follow 指令的 14B，可能比慢吞吞的 70B 更好用。任务匹配比参数量更重要。

6. 优化：从跑起来到跑得好

模型已经跑得够快，这节可以先跳过。这里讲的是不够快时该动哪几个旋钮。

6a. 基础参数

bash

Ollama 主要运行参数（通过 API options 传入更稳定）

curl http://localhost:11434/api/generate
-d ‘{ “model”: “qwen3:8b”, “prompt”: “你的问题”, “options”: { “num_ctx”: 8192,
“num_gpu”: 99,
“num_batch”: 512
}, “stream”: false }’

• num_ctx 上下文窗口大小，直接影响 KV Cache 内存；

• num_gpu 卸到 GPU 的层数；

• num_batch 影响 prompt 处理速度。

• temperature、top-p、top-k 控制生成随机性，不是性能调参点，新手默认值就好。

6b. Attention 优化

Flash Attention：标准 Attention 计算中，注意力矩阵要在内存里完整展开。Flash Attention 把计算分块做，大幅降低内存访问次数，相同 ctx_size 下速度更快、内存占用更低。部分 runtime 和配置默认启用，建议查自己版本的文档确认。llama.cpp 里用 –flash-attn on 显式开启。

KV Cache 量化：把 KV Cache 本身也量化（通常到 Q8 或 Q4），进一步压缩长上下文的内存占用。在跑 32K+ ctx 时效果明显。

6c. 智能量化：imatrix

普通量化对所有权重一视同仁地降精度。imatrix（Importance Matrix）量化先跑一批校准数据，测量每组权重对输出的重要程度，然后对“重要“权重保留更高精度，对“不重要“的激进压缩。

同样是 Q4，imatrix Q4 的实际质量通常明显高于普通 Q4。在 HuggingFace 上，imat 或 imatrix 出现在文件名里是个好兆头。

Turbo Quant 是类似思路的变体，不同工具链叫法不同，本质是重要性引导的非均匀量化。

6d. 新兴推理加速

Speculative Decoding（投机解码）：用一个小的“草稿模型“先快速生成候选 token，主模型批量验证。验证通过直接用，不通过才重新算。在草稿模型和主模型匹配得好的场景下，TPS 可能有明显提升。通常最好用同一模型家族的草稿模型，但不是强制要求。

MTP（Multi-Token Prediction）：传统推理每次预测一个 token，MTP 让模型在训练或推理设计里预测多个。一些新模型会在训练层面内置这个能力，不需要额外的草稿模型。这两条路线都在往同一个方向走：让单次前向传播产生更多输出。

6e. 不要只看 TPS

TPS 是速度，不是质量。一个模型跑得快但瞎说，没有意义。

别只看 benchmark。拿你真的会用的任务测四个东西：能不能按 JSON 格式输出，能不能记住长材料最后一段，能不能写一段能跑的函数，能不能在你知道答案的问题上不胡编。10 分钟测下来，比 benchmark 更直接——因为是在你自己的任务上跑的。

7. 术语速查表

8. 收尾：五层决策，一次讲清

以后看到一个模型跑不动，就别先怪模型。先问：是内存不够、ctx 开太大、量化选错，还是 runtime 没配好？

每一层可以单独优化，但它们互相约束：

• Runtime 再快，带宽不够，TPS 就有天花板

• 量化压得再低，内存省出来了，质量也跟着掉

• 模型选得再好，内存装不下，跑不起来

理解这个栈，就是理解本地模型。

如果你在某个设备和模型组合上跑出了不错的配置，欢迎分享。

参考资料

• Ollama 文档及 API

• llama.cpp GitHub

• MLX

• Apple M4 Max Tech Specs

• Apple Mac Studio Tech Specs

• DeepSeek / 华为昇腾内存计算 Slide（公开版）

• GGUF 格式规范