本地部署与量化：把模型跑在自己机器上

一句话定位：数据不出门、离线可用、省 API 钱——本地跑模型的三个理由，对应两条部署路线（Ollama 快速路线、vLLM 服务化）与一份量化谱系（GPTQ / AWQ / GGUF）。前置：推理优化——键值缓存与分页机制在那篇拆过，本文直接用它的账；调用篇——动手段直接复用它的 chat() 与「事实标准」接口约定。

先从下好的权重说起

微调好的模型、开源榜单模型，拖下来就能跑——model.safetensors 躺在硬盘里，一切看起来就绪。

真跑起来才发现，权重只是入场券：14 GB 的 7B 权重先吃掉半张卡；第二个请求一进来，响应速度腰斩；第十个并发直接超时；换成 CPU 跑，一个字一个字往外蹦。本地跑模型的门槛不在「跑通」，在「跑得同时伺候好并发与显存」。

那本地部署到底有几条路？模型那么大，塞不进显存怎么办？

两条主路线 + 一份量化谱系：要省心选 Ollama 快速路线，要伺候并发选 vLLM 服务化；塞不下就量化——GPTQ、AWQ、GGUF 三种主流格式各有脾气。本文把两条路线、三派量化、引擎层选型与一套显存估算一次讲清。

全景图：本地部署的三层栈

本地部署拆开是三层：最底层是①模型文件（什么量化格式），中间是②推理引擎（谁来做批处理与显存管理），最上层是③服务接口（程序怎么调）。选型在三层的每一层独立发生，互不绑定：

图 1：本地部署三层栈——①模型文件（量化格式）②推理引擎（路线分野）③服务接口（OpenAI 兼容）；底条是显存估算公式

渐进拆解：两条路线与三派量化

Ollama：一行命令的快速路线

ollama run qwen2.5 一条命令，模型库自动拉取量化好的 GGUF 文件，装完即聊——个人开发、原型验证、离线演示，这条路的省心无可替代。模型库的 tag 就是档位菜单：qwen2.5:7b 的 7b 指参数规模，同一模型还挂着不同量化档的副本，按显存挑。自己微调的模型也能进这条线：把微调篇产出的适配器合并导出后转成 GGUF 导入，个人模型立刻获得同款开箱体验。

它的边界也清楚：默认配置下请求排队处理（新版有静态并行开关，但并行时显存按路数放大、超出仍排队），没有 vLLM 式的动态连续批处理，多用户高并发下吞吐起不来——它是「给自己用的」，不是「给一群用户用的」。把它当本地模型的应用商店理解最准。

vLLM：伺候并发的服务化路线

引擎层的两件核心装备——PagedAttention 分页显存管理与连续批处理——机制在推理优化篇拆过（碎片率从六到八成压到 4% 以下、吞吐 2～4 倍），这里只接工程面。连续批处理对并发的意义用白话说：老式引擎像班车，凑满一整车才发车，后到的请求干等；连续批处理像地铁，随到随上、到站即下——GPU 几乎不留空转的缝隙。

vLLM 起的是常驻服务，自带 OpenAI 兼容端点，云厂商兼容模式怎么调它就怎么调。上一路 Ollama 排队的请求，在这里被动态拼批、显存按页精分——同一张卡，能伺候的并发数差出一个量级。代价是要自己管进程、管显存、管版本，运维重量上去了。

量化三派：同一目标，三种脾气

量化的目的都是把权重从 16 位压到 4 位上下，分歧在「怎么决定压谁」：

三派不是互斥选项，是「跟着引擎走」的选择：vLLM 在 GPU 上优先 GPTQ/AWQ，Ollama 与 llama.cpp 系吃 GGUF。选法收敛成一句话：用 vLLM 部署就 GPTQ/AWQ 二选一（一般 AWQ 优先），用 Ollama 或 Mac 就 GGUF；选 SGLang 沿用 GPTQ/AWQ，TensorRT-LLM 则另有自家量化路线。精度档位从 Q4 起步，任务评估掉点超预期再逐级上调。精度粒度上 GGUF 还提供 Q4_K_M 这类混合精度变体，用分层位宽换质量——同一个模型下载页会列出整套菜单。

量化到 4-bit 到底掉多少点

分两头说。大头是好消息：QLoRA 篇引过的口径——NF4 四比特在微调场景效果追平 16-bit 全量微调（QLoRA 论文口径），推理侧 4-bit 权重量化对大多数任务的影响也在小数点后。

坏消息在小处：模型越小、任务越精细（数学末位、代码精确性、长链推理），量化越容易露馅，4-bit 不行就上 8-bit 或混合精度档。另有一笔账别漏：键值缓存不跟权重一起量化——权重压到 4-bit，并发下的缓存开销仍是精度的，显存估算要分开算。

引擎层格局：vLLM / SGLang / TensorRT-LLM

同在引擎层，另有几件常被一起提的家伙什。先收两件旧的：NVIDIA 的 Triton 推理服务器是企业级通用件——多后端多模型统一伺候，LLM 只是它支持的一类；TGI 是 Hugging Face 出品的 LLM 专用服务引擎——但注意，它自 2025 年末起进入维护模式、仓库已归档，官方推荐新项目流向 vLLM 与 SGLang。当下开源 LLM 服务的头部，是三家各扛一件看家本领（对照综合自 Red Hat 选型文 2026-10 与 H100 实测 2026-04，见参考段；H100 是 NVIDIA 的旗舰数据中心卡）：

• vLLM：事实默认——LLM 专精、通用负载吞吐领先，2025 年加入中立的 PyTorch 基金会托管；靠分页显存管理把单位显卡的并发容量做到最大（这件后来成了三家的公共地基，见下），模型与硬件支持面也最广。真正的独门件是 2025 年重写的 V1 架构：前缀缓存默认开启——输入开头若与此前请求算过的内容相同（同一段系统提示词、同一份历史对话），对应的缓存块直接复用不重算；零命中率时吞吐损失不到 1%，命中时收益巨大，等于给 Agent 类负载免费加外挂。
• SGLang：与 vLLM 同出伯克利班底，看家本领 RadixAttention——把用过的键值缓存放进一棵按前缀组织的树里（结构类似输入法联想词的索引），新请求的开头与树上某条路径相同就直接复用，不重算。多轮对话、共享系统提示词的负载吞吐优势明显（H100 实测口径领先约三成）；边界同样清楚——请求彼此毫无重叠时这套优势归零，退回与 vLLM 同台比拼。
• TensorRT-LLM：NVIDIA 官方出品，编译执行路径在自家卡上持续高负载吞吐最强（H100 口径领先 vLLM 一到三成）；代价是部署重——模型先编译优化一次、换权重重来，生态闭，绑定 NVIDIA 一家。

选型收敛成三句：通用自建服务无脑 vLLM；重多轮、重共享上下文的 Agent 负载实测 SGLang；全 NVIDIA 机房追极限吞吐且养得起运维才上 TensorRT-LLM。另有多模型异构统一服务的需求，才请 Triton 出场。还要看清一层：三家的地基（分页显存管理、连续批处理）已经互相趋同，竞争上移到「缓存复用谁更聪明」——vLLM 前缀缓存默认开与 SGLang 的前缀树，正是同一道题的两种解法。

并发与显存的量级估算

公式就一条：显存 ≈ 量化后权重 + 键值缓存（并发数 × 每请求 token 数 × 每 token 缓存）。拿 7B 模型算一笔：4-bit 权重约 4 GB；每 token 键值缓存按 Qwen2-7B 的 56 KiB 口径（承推理优化篇），100 个并发各带 4K 上下文，缓存就是 100 × 4096 × 56 KiB ≈ 22 GB——缓存是权重的好几倍，这就是「权重塞得下、并发上不去」的根因。

反着用就是容量规划：显存减权重，除以「并发 × 上下文 × 56 KiB」，就是这台机器能扛的并发上限。以一张 80 GB 卡跑 4-bit 7B 为例：

1. 扣权重与系统占用：扣掉实盘 AWQ 副本（约 5.6 GB）与系统占用，按 70 GiB 预算给缓存（与 56 KiB 同源的二进制口径）。
2. 算单路缓存：每请求缓存 = 上下文 × 每 token 缓存，4096 上下文按 56 KiB 口径乘出来。
3. 除出并发：缓存预算除以单路缓存，4096 上下文下理论能扛 320 路上下。
4. 打八折：留突发余量，规划值二百五十路上下。

还有一条要记：上下文长度是缓存的乘数，请求平均上下文从 4K 涨到 32K，同样显存能扛的并发直接除以八，比换模型的影响大得多。

这笔账画出来更直观（见图 2）——同一张卡上，权重与缓存的显存占比完全倒挂：

图 2：7B 部署显存对比——量化压权重，并发的账在缓存上

大白话：本地部署 = 把模型这个「巨无霸」装箱（量化格式）、选一台叉车（推理引擎）、开一个标准窗口（OpenAI 兼容接口）。箱子选小号能塞进小仓库，叉车选好的能同时搬多件，窗口是通用的。

技术定义：量化（quantization）把模型权重从 16 位浮点压到更低比特（4/8 位）表示，分训练后量化（GPTQ/AWQ 的事后校准路线）与量化感知训练两类，本文覆盖的是前者；部署侧 Ollama 封装 llama.cpp 引擎面向单机，vLLM 以分页注意力与连续批处理面向服务化，两者都提供 OpenAI 兼容接口。

动手：两条路线的启动命令

同一个模型、两种起法（都出 OpenAI 兼容端点，业务代码与调用篇完全同构）：

# 路线一：Ollama 快速路线（个人 / 原型 / Mac；路线二需要 CUDA GPU）
ollama run qwen2.5:7b        # 拉取并对话，GGUF 量化件自动下载（Q4 档）
ollama serve                 # Linux 服务器用；桌面版已后台常驻，端口占用即已在跑

# 路线二：vLLM 服务化（高并发 / 生产）
pip install vllm
vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ \
  --max-model-len 8192       # AWQ 预量化副本，引擎自动选 GPU 反量化内核；端口 8000

对着命令核对三层栈：

启动后拿调用篇的 chat() 函数改两个环境变量，谁在后面服务业务代码感知不到——这就是三层解耦的回报。并发压测建议从 vLLM 官方基准脚本（benchmark_serving.py）入手，把「能扛多少并发」从感觉变成数字；压测时另开一个终端盯 nvidia-smi——显存曲线比任何日志都诚实，算式算出来的数要跟它对上。

边界与取舍

什么时候根本不用本地部署

流量弹性大（白天高峰半夜空置）、多地域覆盖、不想碰 GPU 运维——云 API 按量付费更划算。本地部署的价值三件套：

• 数据主权
• 离线可用
• 边际成本趋零

三件都不沾就别自建。自建还有隐性账：模型升级、漏洞补丁、容量规划都是长期人力成本；一张闲置率过半的显卡，电费与折旧加起来，未必真比 API 便宜——自建前拿真实流量曲线算一遍利用率。

量化的次序与下限

降档顺序：

1. 先试 4-bit 权重量化——几乎白拿的显存。
2. 不够再砍上下文长度或并发（缓存账见上）。
3. 最后才换小模型——模型能力砍半是质的损失，量化掉的是零头。

反向提醒：量化不是免费的，发布前拿你的任务评估集跑一遍量化前后对比（微调篇的评估纪律在这里同样适用），精细任务掉点超预期就上 8-bit。

Ollama 与 vLLM 的判据

问两个问题：

• 给谁用：自己 → Ollama；一群用户 → vLLM。
• 有没有运维预算：没有 → Ollama；有专人 → vLLM。

两者依据的不是「哪个更快」而是「并发形态」——单机排队与集群拼批是两种服务形态，选错形态，调参救不回来。

自测

合上文章先自己答，再展开对照：

参考与延伸

• vLLM 论文「Efficient Memory Management for Large Language Model Serving with PagedAttention」（2023-09，SOSP 2023）：分页显存管理与吞吐口径的出处 — arxiv.org/abs/2309.06180
• Red Hat Developers「vLLM vs. SGLang: Choosing the right inference engine」（2026-10-14）：三强架构对照与选型判据出处 — developers.redhat.com
• Red Hat Developers「vLLM V1 Alpha」（2025-01-28）：V1 前缀缓存默认开与「零命中损失不到 1%」口径出处 — developers.redhat.com
• The AI Engineer「vLLM vs Ollama vs SGLang vs TensorRT-LLM」（2026-04，H100 实测）：三强吞吐实测口径（SGLang 共享上下文领先约三成、TensorRT-LLM 领先 vLLM 一到三成）出处 — theaiengineer.substack.com
• TGI 仓库（Hugging Face）：维护模式与归档状态的一手出处 — github.com/huggingface/text-generation-inference
• vLLM 官方博客：V1 架构落地与版本动态一手 — vllm.ai/blog
• AWQ 论文（2023-06）：激活感知量化的机制出处 — arxiv.org/abs/2306.00978
• GPTQ 论文（2022-10）：训练后逐层量化的奠基出处 — arxiv.org/abs/2210.17323
• vLLM 官方文档：OpenAI 兼容服务与量化支持 — docs.vllm.ai/en/latest/
• Ollama 官方仓库：快速路线的安装与模型库 — github.com/ollama/ollama
• llama.cpp（GGUF 格式的引擎生态） — github.com/ggml-org/llama.cpp

下一站：旗舰项目：从零搭一个 RAG 问答系统——把前面所有积木（调用、检索、微调、部署）拼成一个完整系统。