大模型推理服务生产运维：vLLM、KServe与GPU资源治理
把模型启动并提供一个兼容 OpenAI 的接口只是第一步。生产推理还要解决模型来源、显存容量、并发调度、KV Cache、长上下文、冷启动、自动伸缩、限流、内容安全、成本和故障降级。本文以 vLLM 与 KServe 为代表，给出大模型推理平台的生产运维路线。
一、先定义服务目标
传统 Web 服务关注请求数和毫秒级延迟，大模型还需要关注 Token。
定义：
- TTFT：首 Token 延迟；
- TPOT：后续每 Token 时间；
- 端到端延迟；
- 输入/输出 Token 数；
- 每秒输入与输出 Token；
- 并发序列数；
- 上下文长度；
- 生成成功率与截断率；
- GPU 利用率、显存和单 Token 成本。
交互问答重视 TTFT，批量生成更重视总吞吐。两者若混在同一队列，长请求可能拖慢短请求。
二、容量不是只看模型文件大小
显存消耗包括：
模型权重
+ KV Cache
+ 激活与工作区
+ CUDA Graph/通信缓冲
+ 运行时和碎片
权重量可按参数量 × 每参数字节粗估，但量化格式、张量并行和加载格式会改变实际值。KV Cache 与层数、隐藏维度、并发序列、上下文和数据类型相关，长上下文通常是容量风险核心。
上线前用真实输入分布压测，不能只用几十 Token 的简单请求。
三、vLLM核心机制
vLLM 通过分页式 KV Cache、连续批处理和高效内核提高吞吐。关键参数通常包括：
- 模型和 Tokenizer；
- tensor parallel size；
- pipeline parallel size；
- GPU memory utilization；
- max model length；
- max number of sequences；
- max batched tokens；
- KV Cache 数据类型；
- 前缀缓存；
- 量化方式；
- eager/CUDA Graph 行为。
不要为追求显存利用率把余量压得过小。模型加载、请求峰值、碎片和运行时变化都可能触发 OOM。
四、并行策略
张量并行
将单层计算拆到多 GPU，适合模型无法放入单卡。要求 GPU 间有足够高速互联，PCIe、NVLink 和跨 NUMA 拓扑会显著影响性能。
流水线并行
将不同层放在不同设备，可能产生流水线气泡，对小批量交互请求影响明显。
数据并行
每个副本持有完整模型，通过入口分配请求。扩展简单，但每个副本都占一份权重显存。
专家并行
MoE 模型还要关注专家分布和 all-to-all 通信热点。
选择并行策略要结合模型大小、GPU 型号、拓扑、请求长度和容错，而不是只看 GPU 数量。
五、KServe生产架构
KServe 负责模型服务 CRD、路由、伸缩、健康检查和部署管理，可接入 vLLM 等后端。
生产需要拆分：
- 控制面；
- 模型存储与下载凭据；
- 本地模型缓存；
- 推理工作负载；
- 网关和认证；
- 可观测性；
- 配额和调度；
- 灰度/回滚。
控制面暂时不可用时，已有数据面应尽量继续服务。升级前验证 CRD、Webhook、网关和后端兼容。
六、模型供应链
模型文件本质上是生产制品。记录：
- 来源仓库和许可证；
- 精确 revision/commit；
- 文件哈希；
- 权重格式；
- Tokenizer 与配置；
- 量化工具和参数；
- 安全扫描和评测结果；
- 审批人和上线时间。
不要在生产启动时无版本地下载 latest。将模型同步到受控对象存储或制品库，固定 revision，并验证哈希。
部分模型序列化格式可能执行代码。优先安全格式并限制 trust_remote_code，构建过程放入隔离环境。
七、冷启动与模型缓存
大模型启动包含调度、镜像拉取、权重下载、加载、通信初始化和图编译，可能耗时数分钟。
优化：
- 节点预拉镜像；
- 本地 NVMe 模型缓存；
- 固定模型 revision；
- 分离权重下载与服务启动；
- 设置 startup probe；
- 预热典型请求；
- 保留最小副本；
- 预测扩容；
- 监控每个启动阶段。
缓存要有容量水位、LRU 清理、校验和租户隔离，防止节点磁盘被权重占满。
八、自动伸缩
CPU 利用率通常不能代表推理压力。更合适的信号包括：
- 等待队列长度；
- 运行中请求；
- Token 吞吐；
- TTFT；
- KV Cache 使用率；
- GPU 利用率和显存；
- 请求拒绝数。
扩容速度受 GPU 节点供给和模型冷启动限制。应同时使用：
- 最小热副本；
- 队列和并发上限；
- 预测扩容；
- 不同优先级队列；
- 超时和快速拒绝；
- 小模型降级。
Scale-to-zero 适合低频模型，不一定适合对首请求时延敏感的服务。
九、批处理与公平调度
连续批处理提高吞吐，但长提示和长输出会占用更多 KV Cache。需限制：
- 单请求输入 Token；
- 最大生成 Token；
- 并发序列；
- 每租户请求与 Token 速率；
- 队列等待时间；
- 单请求总预算。
仅按请求数限流不公平：一个 200 Token 请求和一个 100000 Token 请求成本完全不同。应按输入、输出和在途 Token 建模。
十、GPU调度与节点
Kubernetes 环境关注：
- NVIDIA Driver、Container Toolkit 和 device plugin 兼容；
- GPU Operator 版本；
- 节点标签、污点和亲和性；
- GPU 型号、显存和互联拓扑；
- NUMA、CPU、内存和本地盘；
- MIG 划分；
- RDMA/NCCL 网络；
- 驱动升级和节点维护。
GPU 工作负载不能只申请 GPU，还要请求足够 CPU、内存、共享内存和临时存储。
十一、MIG与共享
MIG 能把支持的 GPU 划分为隔离实例，适合小模型或多租户；时间切片提高利用率但隔离和性能可预测性较弱。
选择时考虑：
- 模型最小显存；
- 是否需要独占带宽；
- 故障隔离；
- 多租户安全；
- 调度碎片；
- 监控粒度；
- 动态重配置是否需要驱逐任务。
十二、入口网关与API治理
推理入口应处理：
- 认证和租户；
- 配额和 Token 限流；
- 模型别名到精确版本；
- 流式响应；
- 请求大小和上下文上限；
- 超时与取消；
- 幂等和重试；
- 审计；
- 敏感字段脱敏。
流式请求一旦客户端断开，应尽快将取消传递到后端，避免 GPU 继续生成无人消费的 Token。
十三、重试与降级
生成请求可能已经消耗大量算力，代理无脑重试会成倍增加成本。只对连接建立失败、明确未开始计算或幂等场景有限重试。
降级选项：
- 缩短最大输出；
- 降低上下文；
- 切换小模型；
- 关闭非必要工具调用；
- 返回缓存答案；
- 排队或异步处理；
- 对低优先级快速拒绝。
十四、可观测性
指标按四层组织：
请求层
请求率、错误率、TTFT、TPOT、端到端延迟、输入/输出 Token、取消和截断。
调度层
等待/运行请求、批大小、抢占、KV Cache 使用率、前缀缓存命中、队列时间。
GPU层
利用率、显存、功耗、温度、时钟、ECC、Xid 错误、PCIe/NVLink 吞吐。
平台层
Pod 重启、调度失败、镜像/模型下载、节点压力、网关连接和对象存储延迟。
日志避免记录完整提示词和输出。生产调试可抽样、脱敏并设置短保留期。
十五、常见故障
CUDA OOM
确认是权重、KV Cache、批量、上下文、其他进程还是碎片。保存并发、Token 和显存时间线；降低上限或分流，不要只依赖自动重启。
TTFT突然升高
检查队列、批大小、长提示比例、KV Cache、GPU 降频、模型副本和入口重试；区分排队与实际计算。
GPU Xid错误
保存 Xid、驱动、GPU 序列号、温度和任务；隔离节点并按 NVIDIA 指南判断驱动、硬件或链路故障。反复 Xid 的节点不应继续承载关键流量。
模型启动失败
按调度、镜像、凭据、存储、哈希、显存、并行拓扑和健康探针逐段定位。不要把 startup probe 配置得比模型正常加载时间更短。
NCCL超时
检查 GPU 拓扑、网卡/RDMA、MTU、PFC/ECN、NCCL 环境、节点时钟和某个 rank 是否 OOM 或进程退出。
十六、灰度与模型评测
模型版本灰度不仅看系统指标，还要看质量与安全：
- 固定评测集；
- 事实正确率；
- 拒答与越权；
- 提示注入；
- 工具调用正确率；
- 延迟和 Token 成本；
- 用户反馈；
- 不同语言和长度分布。
通过模型别名将少量租户导向新版本，保留快速切回。提示模板、Tokenizer 和模型必须作为一个发布单元管理。
十七、成本治理
成本拆解：
- GPU 节点时间；
- 空闲保底副本；
- 模型和镜像存储；
- 跨区网络；
- 输入/输出 Token；
- 失败与重试请求；
- 预热和评测。
按模型、版本、租户和业务标签分摊。优化顺序通常是减少无效请求、限制 Token、提升批处理和缓存命中，再评估量化和更换 GPU。
十八、安全边界
- 权重和数据来源合规；
- 模型服务不直接暴露管理端口；
- 提示词、输出和向量数据分类保护；
- 工具调用采用最小权限和人工确认；
- 防止 SSRF、命令执行和数据越权；
- 多租户配额与日志隔离；
- 管理员不能随意读取用户对话；
- 敏感模型和数据不进入不受控外部服务。
十九、上线清单
- [ ] 模型 revision、哈希、许可证和评测可追溯；
- [ ] 显存模型包含权重、KV Cache 和运行时余量；
- [ ] 真实上下文和输出分布压测完成；
- [ ] GPU 拓扑、驱动、运行时和调度兼容；
- [ ] 冷启动、模型缓存和最小热副本可控；
- [ ] 入口按 Token 与租户限流，支持取消；
- [ ] 自动伸缩使用队列、Token 或延迟指标；
- [ ] OOM、Xid、节点故障和小模型降级已演练；
- [ ] 提示与输出日志经过采样和脱敏；
- [ ] 模型质量、安全、成本和系统指标共同作为发布门禁。
二十、结语
大模型推理平台是“高成本、长请求、强状态缓存”的特殊在线系统。可靠性来自对 Token、显存、KV Cache、队列和 GPU 拓扑的共同治理。真正成熟的平台既要让模型跑得快，也要在过载、节点故障和新模型发布时保持可控、可降级、可审计。
参考资料
- vLLM Documentation：https://docs.vllm.ai/
- KServe Documentation：https://kserve.github.io/website/docs/
- NVIDIA DCGM：https://docs.nvidia.com/datacenter/dcgm/