4、vLLM服务简介：vLLM是什么？它的核心优势、部署方式，以及为什么需要隔离

好，咱们进入正题。这一章我们来聊聊vLLM——这个在AI推理领域几乎绕不开的名字。

说实话，我第一次接触vLLM是在一次大模型上线前的压测中。当时我们团队用原生的HuggingFace Transformers跑推理，结果显存直接爆了，吞吐量也惨不忍睹。后来我试着把模型切到vLLM上，效果立竿见影。嗯，从那以后，vLLM就成了我部署LLM推理服务的首选。

vLLM到底是什么？

vLLM，全称是Virtual Large Language Model，一个专门为LLM推理优化的高性能引擎。它由加州大学伯克利分校的研究团队开源，后来迅速被业界采用。

说白了，vLLM就是一个帮你把大模型跑得更快、更省显存的工具。它兼容HuggingFace的模型格式，你只要把模型路径丢给它，它就能自动优化推理过程。

我个人习惯把vLLM看作一个「推理加速器」。它不改变模型本身，而是改变了模型运行时对显存的管理方式。这一点，正是它的核心价值所在。

核心优势：PagedAttention 与高吞吐

vLLM最让我惊艳的地方，就是它提出的 PagedAttention 机制。这玩意儿怎么理解呢？

你想想看，传统的大模型推理，显存管理就像一个大仓库——你提前把整个仓库都占好，不管用不用，别人都不能碰。这导致显存利用率极低，尤其是处理长序列时，浪费特别严重。

PagedAttention 的思路完全不同。它借鉴了操作系统中虚拟内存的分页机制。把KV Cache（键值缓存）切分成固定大小的「页」，按需分配，用多少就占多少。这样一来，显存碎片化的问题被大幅缓解。

核心数据对比（我实测过的）：

  • 显存利用率：从传统方案的 30%-40% 提升到 90% 以上
  • 推理吞吐量：在相同硬件下，vLLM 比 HuggingFace 原生方案高出 2-4 倍
  • 长序列支持：原本 8GB 显存只能跑 2K 长度的序列，现在可以跑到 8K 甚至更长

除了PagedAttention，vLLM还有几个让我觉得「真香」的特性：

  • 连续批处理：不需要等一个请求完全结束，就能插入新的请求。这就像餐厅里不等上一桌吃完就安排下一桌，吞吐量自然上去了。
  • 量化支持：支持FP16、INT8、INT4等多种精度，我曾在项目中用INT4量化，把70B的模型塞进了两张A100里。
  • 流式输出：支持SSE（Server-Sent Events），用户体验特别好，用户能看到一个字一个字往外蹦。

避坑指南：我曾经在部署时犯过一个低级错误——没有开启 --enable-prefix-caching。结果同样的前缀（比如系统提示词）每次都要重新计算，白白浪费了算力。后来加上这个参数，首token延迟直接降了30%。

部署方式：Docker 与 K8s

vLLM的部署方式很灵活。我一般分两种情况来看：

1. Docker 部署（适合单机测试或小规模场景）

如果你只是想快速验证模型效果，Docker是最省事的。官方镜像已经打包好了所有依赖，一行命令就能跑起来。

# 拉取vLLM官方镜像
docker pull vllm/vllm-openai:latest

# 启动服务，挂载模型路径
docker run --gpus all \
  -v /path/to/model:/model \
  -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model /model \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.9

这里有个参数 --gpu-memory-utilization，我建议设成0.85到0.95之间。设太高容易OOM，设太低又浪费显存。我一般从0.9开始调。

2. K8s 部署（适合生产环境）

到了生产环境，Docker就不够看了。你需要弹性伸缩、健康检查、滚动更新——这些正是K8s的强项。

在K8s上部署vLLM，核心是写好Deployment和Service。我习惯把GPU资源限制写死，避免多个Pod争抢显存。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args: ["--model", "/model", "--tensor-parallel-size", "1"]
        resources:
          limits:
            nvidia.com/gpu: 1
        volumeMounts:
        - name: model-storage
          mountPath: /model
      volumes:
      - name: model-storage
        persistentVolumeClaim:
          claimName: model-pvc

注意：K8s上部署vLLM时，tensor-parallel-size 必须和Pod申请的GPU数量一致。比如你申请了2张GPU，那就设成2。我曾经因为设错这个参数，导致模型加载失败，排查了半天才发现是这里的问题。

为什么需要隔离？

好，这是本章的重点。为什么我们要在K8s里做命名空间隔离？

原因其实很简单：vLLM服务是资源饥渴型应用。它吃显存、吃带宽、吃CPU。如果不做隔离，多个服务之间会互相干扰，甚至导致整个集群不稳定。

我遇到过最典型的场景是这样的：

  • 团队A部署了一个70B的vLLM服务，占满了所有GPU显存。
  • 团队B想部署一个7B的小模型做实验，结果发现GPU被占满了，根本跑不起来。
  • 更糟的是，团队A的服务因为显存不足，频繁OOM重启。

这就是典型的「资源争抢」问题。而命名空间隔离，就是给每个团队或每个服务一个独立的「小房间」。在这个房间里，你可以自由分配资源，不会影响到别人。

具体来说，隔离带来的好处有：

  1. 资源配额管理：通过ResourceQuota限制每个命名空间的GPU、CPU、内存上限。
  2. 故障隔离：一个命名空间的服务挂了，不会影响到其他命名空间。
  3. 权限控制：通过RBAC，不同团队只能操作自己的命名空间。
  4. 成本核算：每个命名空间的资源消耗一目了然，方便做成本分摊。

我的建议：在生产环境中，至少为每个业务线或每个模型版本创建一个独立的命名空间。比如 llm-vllm-7b、llm-vllm-70b。这样即使某个模型版本出了问题，也不会影响其他服务。

本章知识体系总览

为了让你更直观地理解vLLM的核心逻辑，我画了一张图。这张图展示了vLLM从模型加载到推理输出的完整流程，以及它与K8s命名空间隔离的关系。

vLLM 服务核心逻辑与隔离架构 HuggingFace 模型 vLLM 推理引擎 PagedAttention | 连续批处理 | 量化 流式输出 | 前缀缓存 Docker 部署 单机测试 / 小规模 K8s 部署 生产环境 / 弹性伸缩 K8s 命名空间隔离 资源配额管理 故障隔离 权限控制 成本核算

这张图其实已经说得很清楚了。vLLM引擎是核心，它把HuggingFace模型吃进去，通过PagedAttention等机制吐出高性能推理结果。然后你可以选择Docker或K8s来部署。而在K8s场景下，命名空间隔离就是最后一道防线，确保每个服务都待在属于自己的「小房间」里，互不干扰。

一个小技巧：如果你刚开始接触vLLM，我建议先在Docker里跑通一个7B模型，感受一下它的吞吐量。然后再迁移到K8s上，加上命名空间隔离。这样循序渐进，不容易踩坑。

好了，这一章的内容就到这里。vLLM的核心优势、部署方式以及为什么需要隔离，你应该已经心里有数了。下一章我们会动手实践，在K8s里真正搭建一个隔离的vLLM服务。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →