vLLM镜像支持多实例共享同一物理GPU

你有没有遇到过这种情况：手头只有一块A100，却要跑好几个大模型服务——Qwen、ChatGLM、Llama……每个都想独占GPU，结果谁也跑不顺，显存爆了，请求排队排到“天荒地老”。😅

传统推理方案里，“一卡一模型”几乎是默认规则。但现实是，很多业务场景下单个模型根本吃不满整张卡的算力，GPU利用率长期徘徊在40%以下，简直是拿金锄头挖土豆——浪费啊！

而今天我们要聊的 vLLM，正是打破这一困局的“显存魔术师”。它通过一套精巧的设计，让多个模型实例安全、高效地共享同一块物理GPU，把原本闲置的资源“榨”出几倍性能。这背后靠的不是蛮力，而是三大核心技术：PagedAttention、连续批处理、容器化资源调度。

---

我们先从一个最痛的点说起：KV Cache。

在自回归生成中，每生成一个token，都要依赖前面所有token的Key和Value向量，这些缓存统称为KV Cache。问题来了——它们通常得放在连续的显存块里。可用户的请求长短不一，有的300 token，有的8000 token，系统为了保险，往往预分配一大块空间，导致大量浪费。更糟的是，短请求无法复用长请求释放后的碎片，显存利用率常常只有30%~50%。

vLLM的解法很妙：PagedAttention。

这个名字听着像操作系统里的“虚拟内存分页”，其实思路真就一模一样。它把KV Cache切成一个个固定大小的“页面”（比如每页16个token），每个请求的缓存可以分散存储在不同页面中，再用一张“页表”记录逻辑页到物理地址的映射。这样，显存不再需要连续，新token来了只需分配新页，无需搬移旧数据——零拷贝扩容，丝滑得很。

llm = LLM(
    model="meta-llama/Llama-2-7b-chat-hf",
    block_size=16,               # 每页16个token
    max_num_seqs=256,            # 最多256个并发序列
    enable_prefix_caching=True   # 开启前缀缓存，相同提问直接复用
)

你看这段代码，block_size=16就是那个“页面大小”。别小看这个数字，它直接影响内存对齐效率和碎片率。太小了页表开销大，太大了又容易浪费。实践中16是个不错的平衡点。

更重要的是，PagedAttention让“多实例共享GPU”成为可能。每个vLLM实例都有自己的页面池，彼此隔离，但共用同一块显存池。就像合租一栋楼，每家住自己的房间，但共用电梯和水电。

但这还不够——就算显存省下来了，如果GPU还是经常空转，那也是白搭。

传统批处理是“静态”的：等一批请求全来了，一起跑，跑完再接下一批。可问题是，有些请求生成快，有些慢，GPU只能等最慢的那个结束才能开工。中间空闲时间，算力白白流失。

vLLM怎么做？连续批处理（Continuous Batching），也叫“迭代批处理”。

它的核心思想是：每次只推理一个token。每步结束后，立刻检查队列里有没有新请求，或者哪些请求已经完成可以退出。然后动态重组下一个batch，马上进入下一步推理。

想象一下工厂流水线：以前是一整车零件装满才启动，现在是边来边装，边走边卸，几乎不停机。GPU利用率直接从40%~60%飙到80%~95%，吞吐量提升5~10倍不是梦。

而且，这种机制天然支持异构混合：短请求不会被长请求“绑架”，能更快出结果；新来的高优请求也能插队加入，延迟更可控。

llm = LLM(
    model="Qwen/Qwen-7B-Chat",
    max_num_seqs=100,
    max_model_len=8192,
    use_beam_search=False  # 注意！束搜索会关闭连续批处理
)

这里有个坑得提醒你：beam search 这种采样方式会禁用连续批处理。因为它需要维护多条候选路径，状态管理复杂，没法和其他请求灵活拼batch。所以如果你追求高吞吐，尽量用temperature或top_p这类简单采样。

---

现在，轮到真正的重头戏：多实例共享GPU。

光有PagedAttention和连续批处理还不够，还得解决“谁来管资源”的问题。毕竟，多个实例一起跑，万一某个“熊孩子”把显存吃光了，其他实例就得崩溃。

vLLM的做法是：三层协同治理。

第一层，显存层面。
靠PagedAttention实现细粒度分配。每个实例有自己的页面池，CUDA内存池统一调度，避免冲突。你可以通过gpu_memory_utilization=0.9来限制总使用率，留点余量防突发。

第二层，计算层面。
利用CUDA Stream实现异步执行。每个实例的任务被包装成独立流，GPU按时间片轮转调度，毫秒级切换，互不阻塞。配合连续批处理，每个实例都能获得稳定的推理节奏。

第三层，容器层面。
这才是生产环境的关键。我们通常用Kubernetes部署：

apiVersion: v1
kind: Pod
metadata:
  name: vllm-inference-pod
spec:
  containers:
  - name: qwen-7b
    image: vllm:latest
    resources:
      limits:
        nvidia.com/gpu: 1
    env:
      - name: MAX_SEQS
        value: "64"
      - name: BLOCK_SIZE
        value: "16"

  - name: chatglm3-6b
    image: vllm:latest
    resources:
      limits:
        nvidia.com/gpu: 1

注意！K8s原生不支持GPU分时共享。上面的配置只是“声明”要用GPU，实际能否共用取决于底层插件。推荐两种方案：

1. NVIDIA MIG（Multi-Instance GPU）：适用于A100/H100，硬件级切分，强隔离，适合多租户；
2. 软共享 + 资源配额：通过max_num_seqs、max_model_len等参数控制每个实例的“最大占用”，靠vLLM自身调度保障公平性。

我们画个架构图感受一下：

+----------------------------+
|     Kubernetes Cluster     |
|                            |
|  +---------------------+   |
|  |    Ingress Gateway    | ← 接收OpenAI风格API
|  +----------+----------+   |
|             |              |
|  +----------v----------+   |
|  |   Load Balancer       | → 按模型路由到对应实例
|  +----------+----------+   |
|             |              |
|  +----------v----------+   |     +------------------+
|  |  vLLM Instance 1      | <──→ | GPU 0 (A100)       |
|  |  (Model: Qwen-7B)     |       | Shared Memory     |
|  +----------+----------+   |     +------------------+
|             |              |
|  +----------v----------+   |
|  |  vLLM Instance 2      | 
|  |  (Model: ChatGLM3-6B) | 
|  +---------------------+   |
+----------------------------+

所有实例共享同一块GPU，通过命名空间隔离。前端用Nginx或Istio做路由，后端用Prometheus监控各实例的QPS、延迟、显存使用。一旦某个实例异常增长，立即告警甚至自动重启。

---

这种架构解决了太多实际痛点：

• GPU利用率低？ → 连续批处理+多实例共享，让GPU几乎“永动机”式运转。
• 多模型部署成本高？ → 原本需要4张卡的业务，现在1张卡搞定，成本直接砍掉70%。
• 高并发延迟波动大？ → 动态批处理让短请求不被长请求拖累，SLA更有保障。
• 客户要隔离？ → 容器级隔离+独立实例，既安全又高效。

当然，设计时也有几个关键考量：

• 显存总量要算准：所有实例峰值显存之和 ≤ GPU总显存 × 0.9（留10%缓冲）；
• 模型规模要匹配：优先共享中小模型（<13B），大模型建议独占或用MIG；
• 量化能省不少：上GPTQ/AWQ量化，显存占用直接减半，共享空间更大；
• 别用beam search：除非必要，否则会破坏连续批处理优势；
• 监控必须到位：GPU显存、温度、利用率实时监控，设置阈值自动告警。

---

最后说句实在话：vLLM不只是个推理加速库，它是云原生AI基础设施的一次重构。

它让我们重新思考：GPU到底该怎么用？

不再是“一人一卡”的粗放模式，而是走向“资源池化 + 按需分配 + 弹性调度”的精细化运营。就像当年虚拟机取代物理机，vLLM正在推动AI服务从“手工作坊”迈向“工业流水线”。

未来，随着MLOps、多租户SaaS、边缘推理等场景普及，这种高密度、低成本、易运维的部署模式，将成为标配。

所以，如果你还在为GPU成本发愁，不妨试试vLLM——
也许，你缺的不是更多显卡，而是一个更聪明的调度大脑。🧠💡