LLM 本地部署核心概念图解

想在自己电脑上跑大模型，你会频繁遇到几个名词：GGUF、量化、推理引擎、llama.cpp、Q4_K_M、tok/s、VRAM……它们分别是什么？之间什么关系？本文用最直白的方式讲清楚。

一次本地推理的全流程

你写一段代码调用本地 API，到收到模型回复，整个过程可以切成 6 步：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

你的代码发来 HTTP 请求
    │
    ▼
[1. API 服务器]       llama-server / vLLM 接收请求，解析 prompt
    │
    ▼
[2. 推理引擎加载]     把 GGUF 模型文件加载到显存/内存
    │
    ▼
[3. Tokenizer 分词]   把"今天天气真好"切成 ["今", "天", "天气", "真", "好"]
    │
    ▼
[4. 模型推理]         Transformer 神经网络逐 token 生成下一个词
    │
    ▼
[5. 输出拼接]         把生成的 token 拼回人类可读的文字
    │
    ▼
[6. API 返回]         以 OpenAI 兼容格式返回 JSON 响应
    │
    ▼
  你的代码得到回复 ✅

分层架构总览

所有本地部署方案可以按层级来理解：

1
2
3
4
5
6
7
8
9
10
11

┌─────────────────────────────────────────┐
│  你的代码 (OpenAI SDK / HTTP Client)      │  ← 应用层
├─────────────────────────────────────────┤
│  API 服务器 (llama-server / vLLM)        │  ← 服务层
├─────────────────────────────────────────┤
│  推理引擎 (llama.cpp / MLX / vLLM core)  │  ← 引擎层
├─────────────────────────────────────────┤
│  模型文件 (GGUF / safetensors)            │  ← 数据层
├─────────────────────────────────────────┤
│  硬件后端 (CUDA / Metal / Vulkan / CPU)   │  ← 硬件层
└─────────────────────────────────────────┘

引擎和模型文件是两层不同的东西——这个区分最重要。用类比来记：

1
2

推理引擎 = 游戏引擎（基础设施，负责加载和运行）
模型文件 = 游戏 ROM（数据，真正的"智能"所在）

同一个推理引擎可以加载不同的模型文件，就像同一个模拟器可以跑不同的游戏 ROM。

核心概念：模型文件格式

什么是模型文件

LLM 本质上是一大堆数字（参数）。训练完成后，这些数字需要保存到硬盘上，于是就有了”格式”问题。不同格式决定了怎么存、怎么读、用什么工具跑。

GGUF（通用格式，llama.cpp 生态）

全称：GPT-Generated Unified Format。可以把它理解成一个”自给自足”的模型打包方案：

• 单文件：一个 .gguf 文件包含模型参数 + 分词器 + 元数据（架构名、上下文长度、chat template），拷到 U 盘就能跑
• 内置量化：GGUF 文件本身就是在保存时已经压缩（量化）过的，不需要额外工具
• 兼容性最广：llama.cpp、Ollama、LM Studio 都直接识别

1
2
3
4
5
6
7
8

一个 GGUF 文件里装了：
┌──────────────────────────┐
│  元数据 (metadata)        │  ← 模型名、架构、参数数量、量化方式...
├──────────────────────────┤
│  分词器 (tokenizer)       │  ← 把文字转成数字序列
├──────────────────────────┤
│  模型权重 (weights)       │  ← 数十亿个压缩后的浮点数
└──────────────────────────┘

怎么找 GGUF 文件：去 HuggingFace 搜索 <模型名>-GGUF，比如 Qwen/Qwen3-14B-GGUF，在 Files 页面下载你需要的量化版本。

safetensors（HuggingFace 原生格式，vLLM 生态）

这是 HuggingFace 模型仓库的”标准格式”：

• 安全：不会执行任意代码，比 PyTorch 的 pickle 格式安全
• 分离存储：参数通常分片成多个文件（model-00001-of-00003.safetensors），需要配合 config.json、tokenizer.json 等配置文件
• 等效于原始精度：通常保存的是 FP16 精度，体积大，vLLM 在加载时自己做量化

MLX（Apple Silicon 专属格式）

Apple 为 M 系列芯片设计的原生格式：

• 仅 M1+ Mac 可用：不兼容 Intel Mac 或任何其他平台
• 体积更小、速度更快：比同模型 GGUF 版本小约 5-10%，推理速度略快
• 通过 mlx-lm 命令行工具或 Ollama/LM Studio 加载

核心概念：量化

量化是用低精度数字代替高精度数字来存储模型参数，从而大幅减少显存占用，同时尽量保持模型质量。

为什么需要量化

70B 参数模型在不同精度下的体积：

常见量化级别速查

量化是怎么做到的

大模型的参数有大量冗余——70 亿个 16 位浮点数里，很多精度位对最终输出影响微乎其微。量化就像一个”智能压缩”：

1
2
3

原始权重（FP16）:  [0.123456789...]  2 字节
量化后（Q4）:      [0.1235]           0.5 字节
                   ↑ 精度降低，但"足够接近"

GGUF 的量化还用了分块量化（block-wise）：不是整个模型用一个缩放因子，而是每 32 个权重一组、每组独立缩放。这比简单的”四舍五入”更精确。

量化只发生在保存时

量化是离线操作——用 llama-quantize 工具把 FP16 模型转成 GGUF，然后推理引擎加载这个压缩后的文件。推理时不需要再做量化，直接加载、直接推理。

1
2
3
4
5
6
7
8
9
10

训练好的 FP16 模型
    │
    ▼
llama-quantize --type q4_k_m    ← 量化在这里，离线完成
    │
    ▼
model-q4_k_m.gguf               ← 压缩后的文件
    │
    ▼
llama-server -m model-q4_k_m.gguf  ← 推理时直接用

核心概念：推理引擎

推理引擎是真正”跑”模型的软件——它负责把模型文件加载到显存、接收输入 token、驱动神经网络逐层计算、输出下一个 token。

llama.cpp（全能基石，119K ⭐）

• 语言：纯 C/C++，零运行时依赖
• 文件：单二进制，下载就能用
• 后端覆盖：Metal（Mac） / CUDA（NVIDIA） / ROCm（AMD） / Vulkan / SYCL / CPU
• 模型格式：GGUF（也只认 GGUF）
• 工具链：llama-server（API 服务器）、llama-cli（命令行聊天）、llama-quantize（模型量化）

llama.cpp 是整个本地 LLM 生态的”地基”——Ollama 和 LM Studio 底层都是它。

vLLM（生产级服务器，80K ⭐）

• 语言：Python，需要 Docker 或 pip 安装
• 后端：NVIDIA GPU 为主（CUDA），AMD/TPU 实验性
• 模型格式：HuggingFace 原生（safetensors）+ GGUF + FP8
• 核心特性：PagedAttention + Continuous Batching，多用户并发时吞吐量远超 llama.cpp
• API：OpenAI 兼容 + Anthropic Messages API 兼容 + gRPC
• 多 LoRA：几百个微调适配器共享一个基座模型，按请求热切换

MLX / mlx-lm（Apple Silicon 专属）

• Apple 自研的数组计算框架，专为 M1+ 芯片优化
• Mac 上最快的推理和微调路径
• 没有内置 HTTP 服务器，通常被 Ollama 或 LM Studio 包装后提供 API

Ollama（新手首选，175K ⭐）

• llmama.cpp 的”一键安装”封装版，Go 语言编写
• 一条命令拉取模型、一条命令启动服务
• Mac 上已切换为 MLX 后端，比原生 llama.cpp 更快

核心概念：性能指标

tok/s（每秒生成的 token 数量）

token 是模型处理的”最小意义单元”——大约相当于 0.75 个英文单词或 1.5 个中文字。

1
2
3
4
5
6

你的 GPU 刚跑 Llama 3.1-8B → 显示 "45 tok/s"
这意味着模型每秒生成约 68 个英文字或 30 个中文字

130 tok/s → 几乎感觉不到延迟，像打字一样快
 45 tok/s → 可以接受，像正常阅读速度
 10 tok/s → 明显等待，像等对方慢慢打字

首 token 延迟（TTFT）

Time To First Token——从发送请求到收到第一个回复 token 的时间。大模型需要”读完”整个 prompt 才能开始生成，所以：

• 短 prompt（”你好”）→ TTFT < 0.5 秒
• 长 prompt（几千 token 的上下文）→ TTFT 可能 5-15 秒
• Mac M5 相比 M4 在 TTFT 上提升了 4 倍（Apple 官方数据，得益于 Neural Accelerator）

并发吞吐

单用户时，llama.cpp 和 vLLM 速度几乎一样（~130 tok/s）。差距只在多用户时体现：

数据来源：Red Hat 2025 年基准测试（A100 + Llama 3.1-8B）

结论：个人用不需要纠结这个——装上能跑就够快。

其他重要概念

Token / Tokenizer（分词器）

模型不认字，只认数。Tokenizer 把你输入的文字切成 token 序列：

1
2
3
4
5

"今天天气真好"
  → ["今天", "天气", "真", "好"]  (中文 ≈ 1 字 / token)

"Hello, how are you?"
  → ["Hello", ",", " how", " are", " you", "?"]  (英文 ≈ 0.75 词 / token)

每个 GGUF 文件内置了自己的 tokenizer，加载模型时自动匹配。

VRAM（显存）

GPU 上专用的高速内存。模型参数 + 运行时计算中间结果 + KV Cache（上下文缓存）都要占显存。

7B 模型 Q4 量化后约 4.2 GB，13B 约 7.8 GB，70B 约 42 GB。这还不算 KV Cache——聊得越久、上下文越长，额外占用越大。

KV Cache

Transformer 在生成每个新 token 时都要”回顾”前面所有 token。KV Cache 缓存这些中间结果以避免重复计算。代价是吃显存：

• 2K 对话上下文 → 7B 模型 KV Cache ≈ 0.4 GB
• 128K 对话上下文 → 70B 模型 KV Cache ≈ 42+ GB（和模型权重本身差不多大）

OpenAI 兼容 API

几乎所有推理引擎都提供与 OpenAI 格式兼容的 HTTP 接口，这意味着你可以：

1
2
3
4
5
6
7
8
9
10
11

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8080/v1",  # 改一行指向本地
    api_key="not-needed"
)

response = client.chat.completions.create(
    model="qwen3",
    messages=[{"role": "user", "content": "你好"}]
)

代码不需要改，换个 URL 就从云端切到本地。

引擎、格式、模型的对应关系

1
2
3
4
5
6
7
8

┌────────────────────────────────────────────────────────────────┐
│  推理引擎                    模型格式             典型用法        │
├────────────────────────────────────────────────────────────────┤
│  llama.cpp            →  GGUF（仅此一种）        命令行 / 嵌入式    │
│  Ollama               →  GGUF + MLX            一条命令启动 API   │
│  vLLM                 →  safetensors + GGUF    生产级多用户 API   │
│  mlx-lm               →  MLX                   Mac 最快推理/微调  │
└────────────────────────────────────────────────────────────────┘

三个关键认知

1. 量化发生在保存时，推理时直接加载

你下载的 qwen3-14b-q4_k_m.gguf 已经是压缩好的——不需要任何配置，引擎加载后直接跑。

2. 引擎和模型是解耦的

同一个 qwen3-14b-q4_k_m.gguf 文件，可以被 llama.cpp 跑，也可以被 Ollama 跑、LM Studio 跑。换引擎不换模型。

3. 单用户场景下，选最方便的工具就好

llama.cpp、Ollama、vLLM 在单用户下速度几乎一样。选哪个取决于你的安装偏好和硬件，而不是性能。

想动手搭建本地 API 服务的话，参考 基于 llama.cpp 搭建本地 LLM API 服务。