知识点深化 · LLM 推理部署
LLM 推理服务部署：vLLM、Ollama、TGI、模型加载、并发与显存
本地能 python 跑通模型 不等于能对外提供服务。真上线要回答：模型怎么放进显存？多个用户同时请求怎么排队？为什么一并发就 OOM？这一页把 vLLM/Ollama/TGI 三大推理引擎讲清楚，教你估算显存、看懂吞吐和并发。
① 小白第一课怎么学（4 步走，约 90 分钟）
先建立"推理=把权重搬进显存，逐个 token 算"的直觉。
1搞懂显存账（20 分钟）
读②③：模型权重占多少、KV cache 占多少，是部署的命门。
2选引擎（15 分钟）
读④：Ollama 本地玩，vLLM/TGI 上生产。
3起一个 vLLM 服务（30 分钟）
跟着⑤用一条命令起 OpenAI 兼容接口。
4排错+刷题（25 分钟）
读⑥ OOM/慢/并发坑，做⑦⑩。
本课小目标学完你要能：① 估算一个模型需要多少显存；② 说清 vLLM 比朴素 transformers 快在哪；③ 起一个 OpenAI 兼容的推理服务；④ 解释 KV cache 和并发的关系。
② 一图看懂：推理服务架构
读法：显存被两块吃掉——固定的模型权重 + 随并发数增长的 KV cache。推理引擎的核心工作就是高效管理 KV cache、把多个请求拼批算，榨干 GPU。
③ 本质直觉：GPU 宝贵，要让它别闲着
大模型推理是自回归：一个字一个字往外蹦。每生成一个 token，都要把整个模型跑一遍前向。
第一个直觉——权重是固定开销：模型权重（比如 7B 参数 FP16 约 14GB）必须常驻显存，不管 1 个人用还是 100 个人用，这 14GB 都在那。这就是为什么"单机跑大模型"的门槛是显存。
第二个直觉——KV cache 是并发开销：为了不重复算前面的 token，模型会把每层的 Key/Value 缓存下来（KV cache）。每多一个并发请求，就多一份 KV cache。并发越高，KV cache 越爆显存——这就是"人一多就 OOM"的根因。
第三个直觉——朴素推理的浪费：如果一个请求一个请求地串行算，GPU 大部分时间在等下一个请求、算力闲置。vLLM 这类引擎的杀手锏是连续批处理（continuous batching）：每生成一个 token 就把新请求塞进来、把已完成的踢出去，让 GPU 永远满载。
显存粗估公式权重显存 ≈ 参数量 × 每参数字节数。FP16=2 字节，INT8=1，INT4≈0.5。7B 模型 FP16 ≈ 70亿×2B ≈ 14GB。再给 KV cache 和激活留 30%~50% 余量。
④ 完整体系：三大引擎、显存估算、启动命令
三大推理引擎对比
| 引擎 | 定位 | 优点 | 缺点 |
|---|
| Ollama | 本地/开发机玩模型 | 一行命令起，自动拉模型，封装好 | 吞吐一般，不适合高并发生产 |
| vLLM | 生产高并发首选 | PagedAttention 连续批处理，吞吐极高，OpenAI 兼容 | 装起来稍重，主要面向 NVIDIA |
| TGI | HuggingFace 系生产 | HF 生态好，支持广 | 吞吐通常略低于 vLLM |
显存估算表（FP16）
| 模型规模 | 权重显存 | 建议起步显卡 |
|---|
| 1.5B | ~3 GB | 4~8GB 消费卡 |
| 7B | ~14 GB | 16GB（如 4080/4090） |
| 13B | ~26 GB | 24GB（3090/4090）紧，量化后可 |
| 70B | ~140 GB | 多卡 A100/H100 或 INT4 量化 |
量化（GPTQ/AWQ/INT4）能把权重显存砍到 1/4，代价是微小精度损失，是消费卡跑大模型的关键。
Ollama：本地一行起
brew install ollama # macOS
ollama run qwen2.5:7b # 自动拉模型并对话
# 它自带 OpenAI 兼容接口 http://localhost:11434/v1
vLLM：生产级启动
pip install vllm
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-7B-Instruct \
--served-model-name qwen2.5 \
--gpu-memory-utilization 0.90 \
--max-model-len 8192 \
--port 8000
# 起在 http://localhost:8000/v1，OpenAI SDK 直接换 base_url 就能用
关键参数说明
| 参数 | 作用 | 怎么调 |
|---|
--gpu-memory-utilization | vLLM 用满显存的比例 | OOM 就调小，默认 0.9 |
--max-model-len | 最大上下文长度 | 越大 KV cache 越吃显存，按需设 |
--max-num-seqs | 最大并发序列数 | 限制并发，防 OOM |
--quantization awq | 量化加载 | 显存不够时用 |
调用（OpenAI 兼容）
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="x")
r = client.chat.completions.create(
model="qwen2.5",
messages=[{"role":"user","content":"用一句话解释容器"}]
)
print(r.choices[0].message.content)
⑤ 用法场景与典型例题
例1（显存估算）要在单张 24GB 卡上 FP16 跑一个 7B 模型，够吗？
权重 14GB，还要留 KV cache。
① 权重：7B×2B ≈ 14GB。
② 24GB 减去 14GB = 约 10GB 给 KV cache + 激活。
③ 结论：能跑，但并发不能高，max-model-len 别开太大。若要高并发或长上下文，上 INT4 量化或换更大显存。
答案：勉强够单用户/低并发；高并发建议量化或多卡。
例2（为什么 vLLM 快）为什么朴素 transformers 逐请求推理吞吐很低？
GPU 在请求之间空转。
① 朴素做法：请求 A 生成完整回答，期间 GPU 算它一个；A 结束才开始 B。
② 多个请求时，GPU 算力利用率低。
③ vLLM 连续批处理：每步都把多个请求的 token 凑成一个 batch 一起算，完成一个补一个。
答案：vLLM 靠连续批处理 + PagedAttention（KV cache 分页管理减少碎片）把 GPU 利用率拉满，吞吐可达朴素推理的十几倍。
例3（选引擎）团队要对内 50 人同时用一个问答机器人，选 Ollama 还是 vLLM？
看并发和生产要求。
① 50 人同时用 = 有并发，需要服务化。
② Ollama 适合个人本地玩，高并发吞吐不足。
③ 选 vLLM（或 TGI），开 OpenAI 兼容接口，前面挂网关做限流和鉴权。
答案：生产多人并发用 vLLM；Ollama 留给本地开发调试。
两个关键指标TTFT（首 token 时间）——用户等多久看到第一个字；TPOT/吞吐——之后每秒生成多少 token。批量越大吞吐越高，但单请求 TTFT 可能变长，要权衡。
⑥ 高频错误诊断（4 条）
错误 1：启动即 CUDA out of memory权重 + KV cache 超了。对策：调小 --gpu-memory-utilization、--max-model-len、--max-num-seqs，或换量化模型（AWQ/GPTQ）。先 nvidia-smi 看实际显存。
错误 2：首 token 很慢、生成卡顿可能是没开连续批处理、用了朴素 transformers，或上下文太长导致 prefill 慢。换 vLLM，限制 max-model-len，长输入做 RAG 截断。
错误 3：模型下载一半断了/权限错HuggingFace 在国内拉不动。配镜像源（HF_ENDPOINT）或用 ModelScope； gated 模型要登 token。
错误 4：并发一高就 503/排队vLLM 默认有最大并发序列数，超了会排队或拒绝。调大 --max-num-seqs（前提是显存够），前面加队列/限流层，别让请求打满 OOM。
⑦ 考点真题演练（4 题）
考点分布
| 考法 | 出题形式 | 应对 |
|---|
| 显存估算 | 问某模型够不够 | 参数量×字节数+KV 余量 |
| KV cache | 并发为什么吃显存 | 每路请求一份 KV |
| 引擎选型 | 本地 vs 生产 | Ollama 本地，vLLM 生产 |
| 吞吐 | vLLM 为什么快 | 连续批处理让 GPU 满载 |
真题基础1. 7B 参数模型用 FP16 加载，模型权重大约占多少显存？
真题中档2. LLM 推理时并发请求越多越容易 OOM，主要因为？
真题中档3. 团队要在生产环境对外提供高并发 LLM 服务，首选？
真题拔高4. 显存不够跑 13B 模型，最实用的省钱办法是？
⑧ 必背命令/知识点卡
显存账：权重 = 参数量 × 字节数（FP16=2）7B≈14GB
两块开销：权重固定 + KV cache 随并发涨 OOM 根因
本地玩：ollama run 模型名 一行起
生产：vLLM api_server --model --gpu-memory-utilization OpenAI 兼容
vLLM 快：连续批处理 + PagedAttention GPU 满载
省显存：AWQ/GPTQ 量化、限 max-model-len 消费卡跑大模型
铁律：先 nvidia-smi 看显存，再调并发和上下文 别盲调
⑨ 应用输出：把一个开源模型部署成可用 API
场景：一张 24GB 卡，把 Qwen2.5-7B 部署成团队内部问答 API
① 估显存：FP16 权重约 14GB，24GB 卡剩约 10GB 给 KV cache，够低并发。
② 装 vLLM：pip install vllm，nvidia-smi 确认卡可见。
③ 起服务：vllm.entrypoints.openai.api_server，--gpu-memory-utilization 0.9、--max-model-len 8192、port 8000。
④ 验证：curl http://localhost:8000/v1/chat/completions，或用 OpenAI SDK 换 base_url 调通。
⑤ 压测：逐步加并发，观察 nvidia-smi 显存和 TTFT；接近上限就调小 --max-num-seqs。
⑥ 交付：把 base_url + 模型名给前端/应用，套上网关做鉴权限流。
口述部署思路"先算显存够不够，用 vLLM 起 OpenAI 兼容服务，权重常驻、KV cache 随并发涨；OOM 就限上下文或量化，压测找到并发上限。"
⑩ 分层练习 15 题（基础 5 + 中档 5 + 拔高 5）
▍基础 5 题
基础1FP16 一个参数占几个字节？
2 字节；INT8 是 1，INT4 约 0.5。
基础2Ollama 主要用来干嘛？
本地快速拉取并运行模型，适合开发调试，不是高并发生产首选。
基础3vLLM 默认暴露什么协议？
OpenAI 兼容协议（/v1/chat/completions）。
基础4TTFT 指什么？
Time To First Token，首 token 时间，用户等多久看到第一个字。
基础5看 GPU 显存占用用什么命令？
nvidia-smi。
▍中档 5 题
中档6为什么 KV cache 随并发增长？
每个请求有自己的对话历史，每层 K/V 都要单独缓存，不能跨请求共享。
中档7--max-model-len 开太大有什么后果？
KV cache 随上下文长度线性增长，容易撑爆显存 OOM。
中档8vLLM 相比朴素 transformers 为什么吞吐高？
连续批处理把多个请求凑一起算，GPU 不空转；PagedAttention 减少 KV cache 碎片。
中档9显存不够时除了量化还有什么办法？
减小 max-model-len、限制 max-num-seqs、多卡张量并行、换更小模型。
中档10怎么让现有用 OpenAI SDK 的代码改指向自建 vLLM？
只改 base_url 指向自建服务，api_key 随便填，model 名用 --served-model-name。
▍拔高 5 题
拔高11压测发现并发上去后 TTFT 明显变长，怎么调？
prefill 阶段算不过来。可限制输入长度、增大并行 prefill、或加副本水平扩展；平衡吞吐和首字延迟。
拔高1270B 模型单卡装不下怎么办？
多卡张量并行（vLLM 多卡自动支持），或 INT4 量化后单卡/少卡跑。
拔高13为什么不建议把模型放 CPU 内存里跑对外服务？
CPU 算力远低于 GPU，生成速度可能每秒几个 token，无法服务并发用户；只适合极小模型离线跑。
拔高14AWQ 量化相比 FP16 损失在哪？
显存/吞吐大幅改善，但有微小精度损失；对多数问答场景影响可接受，对数学/代码敏感任务要评估。
拔高15如何防止恶意长 prompt 把服务打 OOM？
网关层限制最大输入 token、设置并发上限和超时、监控显存自动限流，配合 --max-num-seqs。
⑪ 记忆口诀 + 7 天复习计划
三句口诀
① 权重常驻显存，KV cache 跟着并发涨。
② 本地玩 Ollama，生产上 vLLM。
③ OOM 先看 nvidia-smi，再限长度和并发，不够就量化。
| 天 | 任务 | 自检 |
|---|
| 第 1 天 | 读②③，跑通 ollama run | 能对话 |
| 第 2 天 | 背知识点卡 + 做基础 1-5 | 基础全对 |
| 第 3 天 | 起一个 vLLM 服务并用 SDK 调通 | 返回正常 |
| 第 4 天 | 做中档 6-10，观察 nvidia-smi 显存 | 会估算 |
| 第 5 天 | 做拔高 11-15 + 真题 4 题 | 会排错会调优 |
| 第 6-7 天 | 压测找并发上限，口述部署链路 | 不看资料全默对 |
← 返回 FDE 培养总览