第 1 章 · 推理框架选型与服务化
考点梳理
2.1 推理框架对比（“4 个主流”）
| 框架 | 定位 | 强项 | 弱项 | 适合 |
|---|---|---|---|---|
| Ollama | 本地一键跑模型 | 极简（一条命令）、模型生态好 | 吞吐/并发弱、调优空间小 | 开发/Demo/小团队 |
| vLLM | 高性能生产推理 | PagedAttention + Continuous Batching（吞吐高） | 上手稍陡、资源占用高 | 生产级服务（吞吐优先） |
| llama.cpp | CPU/轻量端侧 | 无 GPU 可跑、多平台（手机/嵌入式） | 性能上限低 | 端侧/无 GPU |
| TGI（HF） | 生产推理 | HF 生态集成、量化/流式成熟 | 社区活跃度略降 | HF 生态生产 |
选型口诀：“Demo 用 Ollama，生产用 vLLM，端侧用 llama.cpp，HF 生态看 TGI”（“4 选 1”）。
选型 3 问（“高频追问”）：
① 吞吐还是延迟优先？ → 高并发吞吐选 vLLM；低延迟单请求看硬件
② 有没有 GPU？ → 没有 → llama.cpp；有 → vLLM/Ollama
③ 团队栈是什么？ → HF 栈选 TGI；通用栈选 vLLM
2.2 显存账 4 项（“最高频计算”）
显存 ≈ 模型权重 + KV Cache + 激活 + 框架开销
| 项 | 性质 | 估算（示例） |
|---|---|---|
| 模型权重 | 静态（加载即占） | 参数量 × 字节（7B FP16 ≈ 14GB） |
| KV Cache | 动态（随并发 × 上下文涨） | 并发越大、上下文越长，占得越多（大头） |
| 激活 | 临时（前向计算） | 较小（GB 量级内） |
| 框架开销 | 常驻（CUDA/框架） | 1~2GB 量级 |
例题：7B 模型 FP16，单卡 24GB（如 4090）够不够跑 8 并发 × 4K 上下文？ → 权重 14GB + KV Cache（8 并发 × 4K 估算 4~8GB）+ 激活/开销 2GB ≈ 20~24GB——“压线，建议 INT8 量化或降并发/上下文”。
记忆锚：“权重静态 KV 动态；先算权重，再估 KV，留 20% 余量”。
2.3 服务化三件套（“能跑 → 能用”）
| 件 | 内容 | 要点 |
|---|---|---|
| OpenAI 兼容 API | /v1/chat/completions（流式/非流式） | 应用侧零改造（现有 OpenAI SDK 直接换 base_url） |
| 鉴权 | API Key / Token | 生产必开（防滥用） |
| 限流 | QPS / 并发 / token 配额 | 防打爆（按容量定阈值） |
记忆锚：“兼容 API 让应用不改代码，鉴权限流让服务不打爆”。
🧠 记忆工具箱
口诀速记
- 选型：“Demo Ollama，生产 vLLM，端侧 llama.cpp，HF 看 TGI”；
- 显存：“权重静态 KV 动态，先算权重再估 KV，留 20% 余量”；
- 7B：“FP16 十四 G，INT8 七 G，INT4 三点五”；
- 服务：“兼容 API 零改造，鉴权限流防打爆”。
场景锚点
- 推理框架想象"“开店”"：你不是顾客（不需要点菜），你是"开餐厅的"（“选设备 + 定产能”）——“Ollama = 家用小灶（快、省、但做不了大单）；vLLM = 中央厨房（高吞吐、大并发、设备贵）；llama.cpp = 移动餐车（没后厨也能出餐，就是慢）”——“选型 = 按单量选设备”（“10 单/天用小灶，1000 单/天开中央厨房”）。
⚠️ 易错提醒
- 显存账"只算权重" = 重大失误：“KV Cache 随并发 × 上下文动态增长，常是爆显存的元凶”——“先算权重，再估 KV”；
- Ollama ≠ 生产：“Ollama 是开发利器，不是生产方案”（“吞吐/并发/可观测都弱”）——“Demo 用它，上线换 vLLM”；
- 量化"不测就上线" = 赌博：“INT4 掉点必须建测试集验证”（“别人说够用 ≠ 你的业务够用”）；
- 服务"裸奔上线" = 事故：“没有鉴权/限流 = 被白嫖到打爆”（“三件套齐了才上线”）。