一、项目背景：为什么需要K8s持久化存储vLLM？

说实话，我第一次在Kubernetes上跑vLLM推理服务时，踩了不少坑。那时候模型文件直接放在Pod里，每次重启都要重新下载，一个70B的模型动辄上百GB，下载时间够我喝三杯咖啡了。

你想想看，大语言模型推理和传统应用最大的区别在哪？模型文件太大了。我见过不少团队把模型塞进容器镜像里，结果镜像体积直奔200GB，拉取一次镜像能把集群带宽打满。这显然不是长久之计。

核心痛点：模型文件的管理困境

我个人习惯把问题拆成三个维度来看：

• 存储维度：模型文件动辄几十GB到几百GB，Pod重启就得重新加载，效率极低
• 共享维度：多个推理副本需要读取同一份模型，总不能每个副本都存一份吧？
• 版本维度：模型迭代频繁，如何优雅地切换版本而不中断服务？

我在项目中遇到过最典型的情况：团队用StatefulSet部署vLLM，每个Pod挂载自己的EmptyDir。结果模型更新时，需要逐个Pod重建，整个过程耗时半小时以上。说白了，这就是没有持久化存储的锅。

为什么是vLLM？

vLLM这个框架，我用了快两年了。它最大的特点是PagedAttention机制，能把显存利用率提升到90%以上。但再好的推理引擎，也得有稳定的模型加载方式。

vLLM启动时需要加载完整的模型权重，这个过程对I/O要求很高。如果存储性能跟不上，模型加载时间会直接拖慢Pod的就绪时间。嗯，这里要注意：K8s的健康检查如果配置不当，Pod可能因为加载超时被反复重启。

二、整体架构设计：组件与数据流

下面这张图是我在实际项目中沉淀下来的架构。它解决了一个核心问题：模型文件如何高效、可靠地在K8s集群中流转。

组件说明：每一层都在做什么

这张图分四层，我按数据流向从上往下讲：

1. 模型仓库层

模型文件的源头。可以是HuggingFace Hub、自建的MinIO对象存储，或者NFS服务器。我个人推荐用MinIO，因为它兼容S3协议，而且部署在K8s内部，延迟更低。

2. 持久化存储层

这是K8s的核心能力。通过PV和PVC，我们把模型文件挂载到Pod里。关键参数是accessModes: ReadOnlyMany，这样多个推理副本可以共享同一份模型数据。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: vllm-model-pvc
spec:
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 200Gi
  storageClassName: nfs-client

StorageClass这里我建议用NFS或者CephFS。为什么？因为它们支持ReadOnlyMany模式。你想想看，如果每个Pod都复制一份模型，200GB的模型复制10份就是2TB，太浪费了。

3. vLLM推理服务层

Pod启动时，通过volume挂载PVC，模型文件就直接出现在容器里了。vLLM启动命令也很简单：

vllm serve /mnt/models/llama-70b \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 4096

这里有个坑：--tensor-parallel-size要跟GPU数量匹配。我曾经遇到过有人设成8，但节点只有4张卡，结果OOM了。

4. 流量接入层

Service把vLLM的API暴露出去，Ingress做域名和TLS终结。我习惯用Nginx Ingress Controller，配合nginx.ingress.kubernetes.io/proxy-body-size: "0"注解，避免请求体被截断。

三、避坑指南：我踩过的那些坑

讲几个真实案例，希望能帮你少走弯路：

四、总结：架构设计的核心原则

说了这么多，其实就三个原则：

• 存储与计算分离：模型文件独立于Pod生命周期，Pod挂了模型还在
• 共享而非复制：一份模型数据，多个推理副本共享，节省存储空间
• 声明式管理：用PVC和StorageClass描述存储需求，K8s自动搞定底层细节

这套架构我在生产环境跑了半年多，支撑了日均百万级的推理请求。说白了，持久化存储不是锦上添花，而是让vLLM推理服务真正可运维的基础。

---

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