一、项目背景与架构设计：为什么需要多模型管理？vLLM + K8s 架构总览
1.1 从单模型部署到多模型管理的痛点
说实话，我最早接触大模型部署的时候，也觉得“一个模型一个服务”挺简单的。那时候公司就一个 GPT 类模型，跑在单机上，大家凑合用。
但后来业务一多，问题就来了。我记得有一次，团队同时要上线三个模型：一个对话模型、一个代码生成模型、还有一个翻译模型。每个模型都得单独部署一套服务，端口、显存、GPU 都得各自规划。结果呢？
- 资源利用率低：有的模型白天忙，晚上闲；有的模型正好反过来。但你不能动态调整，只能各自预留最大资源。
- 运维成本高：每个模型都要单独配置监控、日志、告警、扩缩容。我那时候光维护这些 YAML 文件就快疯了。
- 版本管理混乱：模型 A 升级了，模型 B 还在旧版本。你想统一回滚？对不起，每个服务都得单独操作。
核心矛盾：GPU 是稀缺资源，但传统部署方式让 GPU 利用率普遍低于 40%。说白了，你花大价钱买的显卡，一大半时间在空转。
为什么会这样？因为单模型部署本质上是一种“物理隔离”的思路。每个模型独占资源，互不干扰，但代价就是资源浪费。你想想看，如果能让多个模型共享同一批 GPU，按需调度，那该多好？
1.2 vLLM 为什么能解决这个问题？
vLLM 这个项目，我第一次接触是在 2023 年底。当时我正被一个推理延迟问题搞得焦头烂额，偶然看到 vLLM 的论文，眼前一亮。
vLLM 的核心优势有三个：
| 特性 | 说明 | 我的感受 |
|---|---|---|
| PagedAttention | 类似操作系统的虚拟内存管理，显存利用率提升 2-4 倍 | 这个设计太巧妙了，把 KV Cache 分页管理，彻底解决了显存碎片问题 |
| 连续批处理 | 动态拼接请求，最大化 GPU 计算吞吐 | 我在项目中实测过，吞吐量比传统方案高了 3 倍以上 |
| 多模型支持 | 原生支持加载多个模型，共享 GPU 资源 | 嗯，这就是我们做多模型管理的基础 |
个人经验：我曾经在一个项目中，用 vLLM 同时加载了 3 个 7B 模型到一张 A100 上。刚开始我还有点担心显存不够，结果 PagedAttention 帮我省下了将近 40% 的显存。那感觉，就像白捡了一张显卡。
1.3 K8s 在这里扮演什么角色？
vLLM 解决了“单机多模型”的问题，但光有 vLLM 还不够。你想想看，生产环境里模型要升级、要扩缩容、要故障恢复、要灰度发布……这些事儿，vLLM 一个人搞不定。
这时候就需要 K8s 出场了。K8s 能帮我们做三件事：
- 资源调度：自动分配 GPU，哪个节点有空闲，就把模型调度过去。我曾经遇到过节点显存不足导致 Pod 启动失败的情况，K8s 的节点亲和性策略帮我完美避坑。
- 弹性伸缩：业务高峰期自动扩容，低谷期自动缩容。我记得有一次双十一活动，流量突然暴涨，HPA 自动帮我加了 5 个副本，整个过程我就在旁边看着，一杯咖啡的功夫就搞定了。
- 生命周期管理：滚动更新、回滚、健康检查、日志收集……这些 K8s 原生能力，直接拿来用就行。
避坑指南：我曾经在 K8s 里直接跑 vLLM，结果发现 Pod 频繁 OOM。后来排查发现，是 K8s 的 resource limits 设置得太死，vLLM 的显存动态分配被限制了。解决方案是给 vLLM 的 Pod 设置合适的 requests 和 limits，并且开启 Guaranteed QoS 模式。
1.4 整体架构设计
好了，现在我们把 vLLM 和 K8s 结合起来，看看整体架构长什么样。
这张图展示的是我们项目最终要实现的架构。从下往上看：
- 底层是 GPU 工作节点：每个节点上可以跑多个 vLLM Pod，共享 GPU 资源。vLLM 的 PagedAttention 机制确保显存利用率最大化。
- 中间是 K8s 控制平面：负责 Pod 的调度、扩缩容、服务发现。我建议把 vLLM 的配置（模型路径、端口、显存限制等）放到 ConfigMap 里，方便统一管理。
- 上层是网关层：用户请求先打到 Ingress 或 API Gateway，然后根据请求中的模型标识（比如 URL 路径或 Header），路由到对应的 vLLM Pod。
我的建议：网关层最好用 Envoy 或 Kong，它们对 gRPC 的支持更好。vLLM 原生支持 OpenAI 兼容的 API，所以网关层可以直接复用现有的路由规则。
1.5 多模型管理的核心能力
基于上面的架构，我们最终要实现的多模型管理平台，应该具备以下能力：
| 能力 | 说明 | 实现方式 |
|---|---|---|
| 模型注册 | 上传新模型，自动部署到 K8s | 通过 API 触发 CI/CD Pipeline |
| 模型路由 | 根据请求内容，分发到正确的模型 | Ingress + 自定义路由规则 |
| 弹性伸缩 | 根据负载自动调整副本数 | K8s HPA + 自定义指标 |
| 版本管理 | 支持模型版本回滚、灰度发布 | K8s Deployment 滚动更新 |
| 监控告警 | 实时查看 GPU 利用率、推理延迟 | Prometheus + Grafana |
注意：模型注册时，一定要做模型格式校验。我曾经遇到过有人上传了一个损坏的模型文件，结果 vLLM 加载时直接崩溃，影响了其他正常运行的模型。后来我加了一个模型健康检查的步骤，加载失败就自动回滚。
1.6 本章小结
好了，这一章我们聊了为什么需要多模型管理，以及 vLLM + K8s 的整体架构。说白了，核心就一句话：用 vLLM 解决单机多模型的显存共享问题，用 K8s 解决多机多模型的编排管理问题。
下一章，我们会动手搭建 vLLM 的 K8s 部署环境，包括 GPU 节点的配置、vLLM 的 Docker 镜像构建、以及第一个 vLLM Pod 的启动。到时候我会分享一些我在 GPU 驱动配置上踩过的坑，保证让你少走弯路。