私有化 LLM 服务架构：从 GPU 选型到生产高可用
场景：企业要在内网部署自己的大模型问答/写作/代码服务——数据不出域、可定制、成本可控。从"买几张卡"到"稳定服务几千人"，中间隔着一条完整的工程链路。本文给出一条可落地的私有化 LLM 服务架构路径，衔接 12 章 · 推理引擎 的机制原理与 知识库问答全栈 的应用侧。
1. 场景与决策框架
私有化部署的三个典型约束：
| 约束 | 问题 | 决策影响 |
|---|---|---|
| 数据合规 | 数据不能出域 | 必须私有化推理，禁止调公网 API |
| 性能体验 | 内部员工/客户要流畅 | 吞吐与延迟有 SLA |
| 成本边界 | 算力预算有限 | 模型规模、并发、硬件三者要平衡 |
核心决策顺序：先定"服务多少人、什么响应要求"，再定"模型规模"，最后才定"买什么卡"——反过来做必踩坑。
2. GPU 选型：先算显存，再谈算力
2.1 显存估算（推理侧）
推理显存 ≈ 模型权重 + KV Cache + 激活/临时缓冲。快速估算公式：
权重显存 ≈ 参数量 × 字节数
FP16/BF16: 参数量 × 2 字节
INT8: 参数量 × 1 字节
INT4: 参数量 × 0.5 字节
KV Cache ≈ 2 × 层数 × KV头数 × 头维度 × 序列长度 × 批大小 × 2 字节示例（7B 模型，FP16，4096 上下文）：
| 项目 | 计算 | 显存 |
|---|---|---|
| 权重 | 7B × 2B | ~14 GB |
| KV Cache（单并发） | 随序列与并发增长 | ~0.5~2 GB |
| 合计单卡底线 | ~16 GB（4090 可跑，但并发受限） |
快速结论：7B 单卡 24G（如 4090/A10）能跑但并发有限；70B 起步要 4×A100-80G（FP16）或 2×A100（INT8/量化）；百 B 级必须多卡 TP（张量并行，机制见 11 章 · 张量并行）。
2.2 推理卡 vs 训练卡
| 场景 | 推荐 | 理由 |
|---|---|---|
| 纯推理、高并发 | 推理卡（L20/L40S/4090/专用推理卡） | 显存带宽性价比高 |
| 训练+推理混用 | A100/H100 | 训练要 NVLink 与高算力 |
| 预算敏感 | 消费级大显存卡 + 量化 | 牺牲吞吐换成本 |
工程要点：私有化场景常用"训练卡做训练、推理卡做服务"分离；混用会互相挤占，调度参考 07 章 · Slurm 异构调度。
3. vLLM 部署：三个核心机制
vLLM 是私有化推理的事实标准引擎（原理详解见 12 章 · vLLM 原理解析）。生产部署吃透三个机制：
3.1 PagedAttention：显存按需分页
传统推理预分配最大 KV Cache 显存（浪费 60~80%）；vLLM 像操作系统分页一样按需分配 KV 块，显存利用率大幅提升 → 同样的卡能服务更多并发。这是"卡不变、并发翻倍"的关键。
3.2 连续批处理（Continuous Batching）
每完成一个请求立即插入新请求，而不是等整批结束——吞吐（token/s）直接翻倍级提升。部署时注意：
- 批大小上限（max_num_seqs）按显存与延迟要求调；
- 大模型（70B+）连续批处理下显存波动大，用
gpu_memory_utilization预留余量。
3.3 量化：用精度换并发
| 方案 | 显存 | 质量影响 | 适用 |
|---|---|---|---|
| FP16/BF16 | 2B/参数 | 无损 | 质量优先 |
| INT8 (W8A8) | 1B/参数 | 轻微 | 均衡 |
| INT4 (AWQ/GPTQ) | 0.5B/参数 | 可接受 | 并发优先 |
经验：7B 模型 INT4 可在 24G 卡上服务数十并发；质量敏感场景先跑评测集对比量化前后效果（复用 知识库问答全栈 的评测思路）。
4. 生产高可用架构
单实例 demo → 生产服务，加四层：
┌── GPU Node 1 (vLLM 副本 A)
用户 ──> LB/网关 ────┼── GPU Node 2 (vLLM 副本 B)
(鉴权/限流/路由) ├── GPU Node 3 (vLLM 副本 C)
└── (滚动扩容/缩容)- 多副本 + 负载均衡：至少 2 副本，网关按权重分发；副本间无状态（KV Cache 在卡内，会话粘滞可选）；
- 灰度发布：新模型/新引擎先切 10% 流量，观测指标达标再全量——模型升级也当发版管；
- 容灾：单卡故障 → 健康检查摘除 → 副本自愈拉起；关键服务要 GPU 节点跨物理机；
- 队列与限流：峰值超容量时排队而非直接失败，返回预期等待时间。
5. 可观测与容量规划
5.1 核心指标
| 层级 | 指标 | 告警阈值参考 |
|---|---|---|
| 服务 | QPS、首 token 延迟 (TTFT)、每 token 延迟 (TPOT) | TTFT < 1~2s |
| 资源 | GPU 利用率、显存占用、KV Cache 水位 | 显存 > 90% 预警 |
| 业务 | 排队长度、错误率、超时率 | 错误率 > 1% 告警 |
5.2 容量规划公式
所需并发 ≈ 峰值 QPS × 平均响应秒数
单卡并发容量 ≈ f(显存, 模型, 量化, 上下文长度) ← 用压测实测
卡数 ≈ ceil(所需并发 / 单卡并发容量)工程要点：容量必须压测得出，不能靠估算——用真实负载脚本（混合长度 prompt）打满单卡，测出"并发-延迟"曲线再乘冗余系数（通常 1.5~2×）。
6. 踩坑与调优（实战经验）
"能跑通" ≠ "能服务"：单请求推理成功只是起点；并发一上来，显存碎片、KV Cache 抖动、排队延迟全冒出来。上线前必做并发压测，这是私有化项目最常见的翻车点。
上下文长度是隐形成本炸弹：max_model_len 设得越大，KV Cache 占用越高、并发越少。按业务真实需要设（多数场景 4K~8K 足够），别默认拉满。
模型版本与引擎版本要一起锁：vLLM 升级可能改变算子行为/量化格式兼容性；生产环境锁定组合版本并压测回归后再升级，别追新。
和 RAG 链路一起测：私有化服务几乎总要接知识库（见 RAG 生产级全栈），端到端延迟 = 检索 + rerank + 生成；容量规划要把检索链路算进去。
监控要能回放问题：记录每条请求的（模型、量化、并发时段、延迟分布），出问题时能回答"当时什么在满"。
7. 效果量化与复盘
| 指标 | 参考基线（7B 模型, 单张 24G 卡, vLLM） |
|---|---|
| 单卡并发 | 数十路（连续批处理 + INT4 可上百） |
| 吞吐 | 数千 token/s 级（实测为准） |
| TTFT | 数百 ms 级（小批量时） |
| 服务可用性目标 | 99.9%（多副本 + 健康检查） |
口径说明：以上为工程经验量级，实际以自家压测为准——压测数据本身就是交付物的一部分。
复盘结论：私有化 LLM 服务 = 显存算清楚 + vLLM 机制吃透 + 高可用四层 + 压测驱动容量。选型与架构在头两天定完，剩下 80% 的精力都花在压测、调参与监控上。
工程启示
- 私有化服务是"智算侧应用"的通用底座：知识库问答、写作助手、代码助手都跑在它之上——先把服务做稳，再谈应用；
- 与 12 章的关系：12 章讲引擎原理与性能对比，本章讲生产架构——机制是"为什么快"，本章是"怎么让它一直稳"；
- 下一步可读：科学智能体落地——在稳定的推理服务之上，把单轮问答升级为多步骤科研工作流。