Kubernetes+vLLM大模型推理集群化部署实战与避坑指南

聊大模型部署方案Kubernetes和vLLM这套组合在2024年之后几乎成了生产环境的默认选择。一个做Qwen、Llama这类模型推理服务的运维或后端工程师只要模型量级到了几十B显存、并发、故障恢复这些单机跑不顺的问题最后基本都得落到Kubernetes上解决。这篇文章主要讲三件事怎么把vLLM推理服务容器化并跑进K8s集群怎么让GPU资源和容器调度配合好以及我在实际部署过程中踩过的那些和生产环境直接相关的坑。适合已经能跑通vLLM单机推理、但想往集群化方向走的人。我不打算把这篇写成K8s官方文档的翻译版重点放在“推理项目落地”这个角度。如果你之前已经用docker run启动过vLLM会发现容器化本身不复杂真正复杂的是模型文件放哪里、GPU怎么分配、多个副本如何接收流量、节点挂了怎么恢复、显存不够时调度器会做什么。这些才是KubernetesvLLM组合里真正花时间的部分。1. 整体架构与设计思路为什么非要用Kubernetes管理大模型推理1.1 单机部署的“天花板”在哪里先说一个很现实的问题单机docker run vllm到底缺什么。如果你的场景是个人开发机、公司内部小范围试用模型量级在7B到14B之间并发量不高那单机部署完全够用。但生产环境一旦出现下面几个信号基本就到了必须上集群的阶段。第一个信号是并发抖动。vLLM本身有continuous batching连续批处理机制能把多个请求拼在一个step里跑但单卡能同时容纳的请求数受KV cache显存限制。假设一个8B模型用FP16加载权重占16GB48GB显卡上剩余约30GB可以给KV cache实测大概能支撑几十路并发。如果业务方突然来一波推广活动并发从50跳到300单机直接超时甚至OOM这种问题靠调参解决不了只能加副本。第二个信号是故障恢复。显卡驱动崩了、GPU被其他任务占满、节点重启这些事在物理机上是常态。单机部署时服务挂了只能靠人肉重启半夜被叫起来的滋味不好受。而Kubernetes的Deployment控制器天然支持副本管理和故障自愈Pod异常会自动重建节点宕掉后Pod会在其他可用节点上重新调度。第三个信号是多模型、多版本的迭代需求。你可能同时要部署Qwen3-8B、Qwen3-27B、一个embedding模型、一个reranker模型每个模型占用的显存不同版本还要灰度。用K8s可以按模型拆成多个Deployment每个服务独立扩缩容互不影响这在单机上很难做到。1.2 vLLM在推理侧的核心优势既然要搭集群推理引擎选择同样关键。vLLM能在众多方案里被选中核心原因是几个特性在“生产可用”这个维度上做得比较到位。PagedAttention是vLLM的招牌技术。它把KV cache从连续的显存块拆成不连续的page块来管理类似操作系统里的虚拟内存分页。没有这套机制时KV cache的预分配很容易导致显存碎片化比如一个请求本来只需要4GB的cache空间但程序一次性预留了10GB其余请求就没地方放了。用PagedAttention后显存利用率能提升不少生产环境里相同硬件条件下支撑的并发数明显更高。continuous batching决定了吞吐上限。传统批处理是把一个batch里的请求都跑完再接收新请求而vLLM是每个step完成后立刻把完成的请求移出同时插入新请求这样GPU始终在跑满状态。实测在8B模型上吞吐量比不带continuous batching的引擎能高出数倍这个差异在长文本场景尤其明显。还有个容易忽视的点是vLLM对OpenAI接口协议的兼容。它启动后提供/v1/chat/completions、/v1/embeddings、/v1/rerank这些标准端点意味着业务侧接入成本极低。原来用OpenAI SDK的代码只要改一下base_url就能切到本地模型这对团队协作、工具链复用都是很好的加分项。1.3 SGLang和vLLM该怎么选热词里提到了sglang和vllm这里也说说我的看法。SGLang在做复杂推理、Agent类场景时表现不错它的RadixAttention机制对多轮对话里的共享前缀处理很友好如果产品形态是高度多轮、带有很长system prompt的对话SGLang可能更匹配。但vLLM生态更成熟社区反馈、文档、镜像、监控指标这些周边配套更全加上我们团队对它的调优经验更多最终选了vLLM。这轮选型我建议不必太纠结先把vLLM跑通如果性能不满足再对比SGLang。两者的部署方式差异不大Kubernetes层面的流程是通用的。2. 环境准备从硬件选型到vLLM装进容器2.1 显存估算和硬件准备部署前先算清楚显存这是很多问题的根源。一个推理服务占用的显存主要由三部分组成模型权重、KV cache、激活值。模型权重最容易估算参数量(单位B) × 字节数 显存占用。FP16/BF16每个参数占2字节所以8B模型权重约16GB27B模型约54GB如果用FP8量化则减半。KV cache比较难估算它和max_model_len最大序列长度、max_num_seqs最大并发序列数、层数、注意力头数都有关系。经验公式是每个token大约需要2 × 层数 × 头维度 × 字节数但实际操作中不用扣得这么细直接用vLLM启动时打印的显存分配信息就行。它会告诉你KV cache实际分到了多少GB不够就调低max_model_len或gpu_memory_utilization。按这两个公式可以得出一个粗略结论一张48GB的显卡跑8B模型很舒服跑27B模型需要FP8或AWQ量化如果要做双卡甚至四卡推理就要用到tensor-parallel-size参数让多张卡一起承载一个模型。热词里有人问L20能不能双卡跑模型多卡推理本身不挑卡型但L20显存只有48GB双卡跑27B量化模型是可行的关键是要把网络和驱动环境排查清楚。2.2 vLLM安装的三种方式和踩坑记录vLLM的安装方式直接决定了你后续踩坑的深度。这里我把三种方式都列出来并说清楚各自适合什么场景。第一种是pip install vllm最简单适合快速验证。你需要Python 3.9到3.12同时注意CUDA版本。vLLM的wheel包通常针对特定CUDA版本编译装完跑一下python -c import vllm; print(vllm.__version__)如果提示找不到CUDA库基本是驱动和PyTorch的CUDA版本对不上。我的建议是直接用官方镜像避免本机环境把时间耗光。第二种是Docker方式也是我推荐的生产方式。官方镜像干净、依赖完整只需要把模型路径和GPU设备映射进去。比如docker run --runtime nvidia --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen3-8B \ --served-model-name qwen3-8b这种方式的优点是不污染宿主机环境vLLM升级、回滚都很方便。缺点是镜像比较大尤其首次拉取时要等一段时间建议在CI/CD流程里提前把镜像推送到私有仓库。第三种是源码编译除非你要改vLLM内核或者做二次开发否则不建议碰。编译过程涉及FlashAttention、CUDA kernel这些组件耗时很长而且编译工具链版本很挑剔。我们团队只在昇腾适配时用过源码方式后面会细说。2.3 模型下载与格式选择模型文件一般从HuggingFace或ModelScope下载。国内环境建议直接用ModelScope速度快很多命令也简单pip install modelscope modelscope download --model Qwen/Qwen3-8B --local_dir /data/models/Qwen3-8B注意下载完整性我遇到过好几次因为网络中断导致safetensors文件不完整vLLM加载时报Invalid magic number或file size mismatch卡了很久才发现是文件没下全。下载后先核对目录里的文件大小再看有没有model.safetensors.index.json这个索引文件这是个很实用的判断方法。格式方面FP16/BF16的权重文件最大但兼容性最好。如果你显存紧张可以选FP8、AWQ或GPTQ量化版。热词里有人问qwen3-8b-27b-fp8部署延迟的问题FP8模型推理延迟高通常有三个原因一是--quantization fp8没配对导致反量化开销大二是max_num_seqs设太大导致批次排得过满单个请求等待时间变长三是GPU不支持FP8加速在无FP8张量核心的卡上跑FP8反而更慢。排查顺序建议先看显卡型号是否支持FP8再确认量化参数最后调低并发限制。3. Kubernetes部署vLLM从YAML到Pod跑起来3.1 镜像和模型文件的目录规划容器化部署的第一个问题是模型文件放哪。三个方案镜像内置、节点本地目录、共享存储。镜像内置最省事但镜像体积会膨胀到几十GB根本不适合版本迭代。节点本地目录用hostPath挂载读取快但每个节点都要放一份模型多节点调度时容易出问题。共享存储NFS、CephFS、JuiceFS是生产环境最常用的方案所有节点挂载同一个模型目录Pod调度到哪个节点都能直接读到模型。共享存储的坑在网络延迟。模型文件加载是顺序读为主千兆网络下加载27B模型可能要几分钟所以我对readinessProbe的初始延迟设置得比较长通常是180秒起步。如果集群里的节点都挂了SSD或NVMe也可以考虑用local-path这类方案加上节点亲和性每个节点缓存一份模型文件速度比走网络存储快得多。我建议的目录结构是这样/data/models/ Qwen3-8B/ config.json model.safetensors.index.json model-00001-of-0000X.safetensors Qwen3-27B-FP8/启动命令里用--model /data/models/Qwen3-8B指向这个目录。3.2 Service和Deployment清单实战下面这份Deployment是我在生产环境里实际使用的模板关键参数都做了注释可以直接复制改一改就上线。apiVersion: apps/v1 kind: Deployment metadata: name: vllm-qwen3-8b namespace: ai spec: replicas: 2 selector: matchLabels: app: vllm model: qwen3-8b template: metadata: labels: app: vllm model: qwen3-8b spec: nodeSelector: gpu-type: a800-48g containers: - name: vllm image: vllm/vllm-openai:latest imagePullPolicy: IfNotPresent command: [python3, -m, vllm.entrypoints.openai.api_server] args: - --model/data/models/Qwen3-8B - --served-model-nameqwen3-8b - --tensor-parallel-size1 - --gpu-memory-utilization0.9 - --max-model-len8192 - --max-num-seqs128 - --port8000 - --host0.0.0.0 ports: - containerPort: 8000 resources: limits: nvidia.com/gpu: 1 volumeMounts: - name: models mountPath: /data/models readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 180 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 30 livenessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 300 periodSeconds: 30 timeoutSeconds: 5 failureThreshold: 10 volumes: - name: models nfs: server: 192.168.1.100 path: /data/modelsapiVersion: v1 kind: Service metadata: name: vllm-qwen3-8b-svc namespace: ai spec: selector: app: vllm model: qwen3-8b ports: - name: http port: 8000 targetPort: 8000 --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: vllm-qwen3-8b-ing namespace: ai spec: ingressClassName: nginx rules: - host: qwen3-8b.ai.internal http: paths: - path: / pathType: Prefix backend: service: name: vllm-qwen3-8b-svc port: name: http有几个点需要特别提醒。首先是resources.limits里的nvidia.com/gpu这个资源由NVIDIA device plugin注册到Kubernetes没有这个字段Pod永远调度不到GPU节点。其次是readinessProbe的initialDelaySeconds模型加载耗时可能超过默认值设短了Pod会被反复重启导致模型每次都重新加载非常浪费。--gpu-memory-utilization0.9表示KV cache使用的显存总量可以到达GPU显存的90%剩下的留给模型权重和运行时。这个值不是越高越好如果权重加载完加上激活值之后剩余显存不够KV cache分配vLLM会启动失败并提示CUDA out of memory。建议先在单机上用nvidia-smi观察空闲显存再定这个值。3.3 Kubernetes是怎么调用containerd把Pod跑起来的热词里有个问题很典型Kubernetes到底怎么调用containerd的。这个是理解整个容器调度的地基我用自己的话梳理一遍。当用户提交一个Deployment后kube-apiserver把期望状态写入etcd。kubelet每个节点上的代理进程通过watch机制感知到有一个新的Pod被调度到本节点接下来就是关键的调用链。kubelet并不是直接fork一个containerd进程而是通过CRIContainer Runtime Interface调用containerd的gRPC接口。kubelet在本地通过Unix socket访问containerdsocket路径一般是/run/containerd/containerd.sock。kubelet调用的第一个接口是RunPodSandbox先创建Pod沙箱本质是一个由containerd管理的隔离环境然后调用CreateContainer创建容器再调用StartContainer启动它。containerd收到创建请求后会解析镜像配置、准备rootfs挂载点、生成OCI运行时规范随后启动一个containerd-shim进程。shim是containerd和真正运行容器进程的runc之间的一道桥梁它负责保持容器运行时的标准输入输出、转发信号、上报状态避免containerd主进程重启导致容器全部退出。最后runc根据OCI规范调用Linux内核的namespace、cgroup、chroot等机制真正把进程隔离起来。GPU设备的注入是在创建容器时通过device plugin和runtime hook完成的NVIDIA的runtime会在容器启动前把GPU设备文件和驱动库挂载进去。这条链路通常在排障时会用到。比如Pod一直停留在ContainerCreating状态你就可以在节点上执行crictl ps -a看一看容器状态再用crictl logs拉日志这比kubectl logs在某些情况下更快。另外kubelet日志里会有完整的CRI调用过程遇到容器起不来的问题去看/var/log/syslog或journalctl -u kubelet基本都能找到根因。3.4 为什么用Deployment而不是StatefulSet不少朋友会在这一步纠结。有状态服务通常用StatefulSet但vLLM推理服务我推荐用Deployment。因为vLLM自身不保存状态模型权重从共享存储读取KV cache存在GPU显存里且随Pod销毁而丢失请求在副本之间如何分配由上游负载均衡器决定不需要稳定的网络标识和稳定的存储绑定。使用Deployment带来的最大好处是可以方便地滚动更新修改模型参数或启动参数后通过滚动升级逐个替换Pod不会中断全部流量。StatefulSet更适合数据库这类需要稳定标识的中间件用在vLLM上反而限制太多。4. 容器调度与弹性伸缩让GPU资源和副本数自动匹配需求4.1 GPU调度与多卡推理配置Kubernetes默认的Pod调度器并不了解GPU是NVIDIA device plugin往节点上注册了nvidia.com/gpu这个扩展资源。你可以通过kubectl describe node node-name查看节点是否包含了这个资源以及可分配的数量。调度器看到Pod请求了nvidia.com/gpu: 1就会把Pod放到有这个资源的节点上。如果你的模型很大单卡放不下vLLM有两个维度可以拆tensor-parallel-size和pipeline-parallel-size。Tensor并行是把模型的层内参数切到多张卡上每张卡算一部分最后通过all-reduce汇总通信量非常大所以建议配合高速互联比如NVLink使用Pipeline并行是把模型按层切成多段每张卡负责其中若干层通信量小一些但存在空闲气泡。生产环境里8B模型基本单卡就能跑27B模型用tensor-parallel-size2或4比较常见。多卡部署还要注意同一个Pod里的GPU必须落在同一台物理机上。K8s设计里Pod请求多个GPU时只能调度到同一节点如果集群里有混用不同显卡型号的节点最好用nodeSelector或nodeAffinity把模型钉在显卡型号一致的节点组里。热词里有人提到L20双卡跑模型跑不起来最常见的原因就是两张卡之间的NVLink拓扑不支持tensor并行所需的高通信带宽这种情况换成pipeline并行或直接降低tensor-parallel-size可能就正常了。4.2 节点亲和性、污点和容忍的落地用法混部是另一种常见场景。如果集群里既有A100、A800又有L20还跑着一些CPU服务你需要做两件事给GPU节点打上污点taint给vLLM Pod加上tolerations和nodeSelector。# 给GPU节点打污点 kubectl taint nodes gpu-node-01 gpureserved:NoSchedule# vLLM Pod声明容忍和亲和性 tolerations: - key: gpu operator: Equal value: reserved effect: NoSchedule nodeSelector: gpu-type: a800-48g这样做的好处是CPU任务不会被调度到GPU节点上占用显存资源而GPU任务可以精确降落到指定型号的节点。如果节点上有两块GPU但你只请求了一块剩下那块仍可能被其他Pod请求这种资源隔离方式比手动管理干净得多。4.3 为什么HPA不能直接用在vLLM上以及替代方案很多第一次部署的人会把HPA的指标设置为CPU使用率结果发现完全没有效果。原因是vLLM推理是IO密集型加计算密集型混合GPU利用率高时CPU可能才百分之十几反过来说CPU被打满时GPU也不一定忙。用CPU指标做HPA基本没有参考价值。正确的做法是用自定义指标。vLLM暴露了Prometheus格式的监控端点默认端口8000路径/metrics热词里的vllm enable metrics说的就是这个能力。可以采集vllm:num_requests_running、vllm:num_requests_waiting等指标然后通过Prometheus Adapter把指标暴露给K8s的HPA。apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: vllm-qwen3-8b-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: vllm-qwen3-8b minReplicas: 2 maxReplicas: 8 metrics: - type: Pods pods: metric: name: vllm_num_requests_waiting target: type: AverageValue averageValue: 16这里的目标值设置需要关注模型单副本能承受的排队请求数。假设单副本max_num_seqs128当队列里有超过16个请求等待时说明已经有点拥挤了可以扩容。但这只适合requests-waiting持续偏高的情况如果只是瞬时波动扩容带来的模型加载时间和显存占用反而会成为新瓶颈。还有一个更直接的做法是在Ingress或网关层做限流把超出系统容量的请求直接返回429或排队等待避免所有流量同时涌入vLLM导致超时雪崩。生产环境里我建议先做好限流再考虑弹性扩容因为GPU节点扩容通常需要提前备好资源池临时扩容往往来不及。4.4 排队队列和批次参数的取舍vLLM的max_num_seqs参数决定了同一时刻最多并行处理多少个序列。这个值设得越大GPU越不容易空闲吞吐越高但单个请求的排队延迟也会增加。如果业务方要求的是低延迟比如智能客服要求首token延迟小于500ms那max_num_seqs就该调小比如32或64如果是离线批量处理、对延迟不敏感可以调到256甚至更高。max_model_len也是类似逻辑。它控制了KV cache能支撑的最长序列设太大会吃掉大量显存导致并发能力下降设太小又可能截断合法请求。我通常的做法是统计业务侧P99的prompt长度加生成长度再留出20%到30%余量作为max_model_len取值。5. 常见故障排查与性能问题实录5.1 Kubernetes层面的故障速查表从Pod到集群的故障排查我把最常见的几类整理成了表格。这些不是理论推演都是我自己在线上遇到过的问题。故障现象可能原因排查命令和解决思路Pod一直PendingGPU资源不足或节点标签不匹配kubectl describe pod看Eventskubectl get nodes --show-labels检查nodeSelector用kubectl top nodes看资源水位ImagePullBackOff镜像名打错或私有仓库未认证kubectl describe pod看事件手动docker pull验证检查imagePullSecretCrashLoopBackOff启动命令参数错误或模型路径不存在kubectl logs看stdout进入容器手动跑一次启动命令定位ContainerCreating卡住镜像拉取慢、存储挂载失败、CNI网络问题节点上crictl ps -ajournalctl -u kubelet看CRI调用日志节点NotReadykubelet异常、磁盘满、dockerd/containerd异常节点上systemctl status kubeletdf -h清理磁盘OOMKilledPod内存limit设置过低模型加载内存超限调大resources.limits.memory或改用hostIPC观察实际内存ReadinessProbe失败模型未加载完成、端口监听异常适当调大initialDelaySeconds用kubectl exec进容器curl /health这里多提一句kubectl describe pod真的很有用。很多人习惯只看kubectl get pods看到CrashLoopBackOff就手忙脚乱其实所有调度失败、镜像拉取失败、探针检查失败的原因都会写在Events里先看Events是最快的定位方式。5.2 vLLM启动和推理侧的典型报错我把热词里跟vLLM启动相关的几个报错都整理了一下这些都是社区里出现频率极高的问题。第一个是expected m1 and m2 to have the same dtype, but got: c10。这类错误通常出现在用FP8或量化模型时模型文件里的权重大部分是量化后的低精度但某些层依旧是FP16/BF16vLLM加载时dtype不一致就会报这个错。解决办法是检查启动命令里是否正确指定了量化方式比如用FP8模型时加上--quantization fp8如果模型是AWQ则对应--quantization awq。另一个可能是你下载的模型权重是FP16版本但启动命令里写了--dtype float16以外的值建议先去掉--dtype让vLLM自动判断再逐步加参数。第二个是爆显存。现象是启动阶段直接报CUDA out of memory或者在推理中段突然OOM。启动阶段爆显存通常是gpu_memory_utilization设置太高模型权重加载完以后剩余显存不够分配KV cache。解决方式是把这个值从0.9降到0.8甚至0.7。另外一种情况是max_model_len设得过大比如在48GB显卡上给8B模型设了32768的上下文KV cache占掉太多空间此时要么降低max_model_len要么用量化模型减少权重开销。第三个是模型加载失败、报No such file或文件损坏。优先检查共享存储挂载和文件完整性。如果多个Pod同时启动都在加载同一个大模型对存储IO的压力会很大可能导致加载超时。经验做法是给Deployment加podAntiAffinity让多个副本尽量不落在同一个节点上或者提前用一个初始化容器把模型文件拉取到节点本地缓存再做软链接。第四个是vllm部署的本地模型可以联网吗。这个很多人混淆。vLLM服务本身不主动联网它只监听端口等待请求。会联网的场景是模型文件托管在HuggingFace启动时如果本地没有缓存程序会自动向HF拉取模型。另外如果代码里调用了远程API做外部工具的function calling那请求会带着你的业务数据走外网。生产环境部署时要根据安全要求做好网络隔离多数情况下建议内网部署模型文件走内网存储vLLM对外只暴露在内网或网关后面。5.3--enforce-eager对性能的影响到底多大热词里有人专门问--enforce-eager。这个参数的核心是关闭CUDA graph加速。vLLM默认会预先捕获一组CUDA graph来降低kernel launch的开销这是它性能好的原因之一。开启--enforce-eager后每次推理都走PyTorch的eager模式kernel launch开销变大吞吐明显下降但好处是显存占用减少启动速度更快兼容性更好。我实测过8B模型在A800上的对比开启默认CUDA graph时吞吐大约比eager模式高20%到40%显存占用则高出1到2GB。如果你的显存非常紧张或者遇到驱动兼容性问题可以临时用--enforce-eager应急但长期生产不建议性能损失太大。5.4 昇腾910b适配问题能跑但别想当然热词里提到了昇腾910b-a2服务器上不能通过vLLM启动embedding和reranker模型。这个问题确实存在原因是昇腾的vLLM适配走的是vllm-ascend插件它映射到vLLM的VllmRunner主要支持LLM的text generation类任务。embedding模型用的是vLLM的EmbeddingModel路径reranker模型走的是RerankerModel由Embedding模块扩展路径这几个入口在昇腾插件里支持程度不齐直接硬跑就会报not implemented或device not supported。解决思路有两个方向。第一等vllm-ascend新版本是否补齐这几个入口需要持续关注社区第二embedding和reranker任务本来就不是vLLM的强项如果你只是做RAG管线可以单独部署专门的embedding服务比如TEI或者自己用sentence-transformers起一个再接进同一个K8s服务网格里。昇腾卡在这个场景下更建议用MindIE推理引擎它对embedding和rerank支持更完整。5.5 continuous batching和延迟的调优方向vllm continuous batching怎么设置这个问题其实没有单独的参数叫continuous batching它是vLLM默认开启的调度行为。你可以把它理解成“来了新请求就赶紧塞进正在跑的批次里”而不是像传统批处理那样攒够一个batch才跑。影响它行为的主要是三个参数max_num_seqs控制一批最多容纳多少序列max_num_batched_tokens控制在单次forward里最多处理多少tokenmax_paddings控制尾部padding的容忍度。热词里有人反馈Qwen3-27B-FP8部署后经常延迟、卡顿。我怀疑问题出在批大小和KV cache资源不匹配上。可以按下面的顺序排查先用--max-num-seqs 32限制并发观察延迟是否下降再检查gpu_memory_utilization是否偏低导致KV cache太少每个请求都在抢cache最后确认量化方式是否跟卡型匹配。如果这三个都排除了再看模型文件是否使用了FP8动态量化导致反量化算力开销大必要时换回BF16版本。6. 工程化落地中值得注意的细节与经验6.1 从单机到集群的部署节奏建议我见过不少团队一上来就把K8s环境搭好结果光排查环境问题就耗了两周这是最亏的。我推荐的节奏是先单机把vLLM跑通确认模型路径、启动参数、推理效果都没问题再封装成镜像跑docker run最后才写K8s YAML。为什么强调这个节奏因为K8s层会引入太多变量网络、存储、调度、探针任何一个环节出问题都会让你怀疑是参数配错了还是环境坏了。先在单机上确认“模型效果没问题、启动参数没问题”再上K8s时定位范围就小了很多。我在生产环境里一次成型率最高的项目都是在单机验证阶段就把模型加载时间、显存水位、启动命令的日志都记录下来的项目。6.2 镜像和启动命令的标准化公司内部最好统一一套镜像tag和启动模板。比如在CI流程里把vllm/vllm-openai固定到某个版本更新时走测试环境验证后再升级。不要写latest几个月后一个偶然的重新拉取就可能把线上环境搞挂。我这边一个推荐的标准化启动命令python3 -m vllm.entrypoints.openai.api_server \ --model/data/models/Qwen3-8B \ --served-model-nameqwen3-8b \ --tensor-parallel-size1 \ --gpu-memory-utilization0.9 \ --max-model-len8192 \ --max-num-seqs128 \ --port8000 \ --host0.0.0.0 \ --trust-remote-code--trust-remote-code这个参数要特别提醒使用来源不明的模型时模型仓库里的代码可能包含任意Python逻辑运行前务必确认模型来源可信。对于公开的主流模型加了它只是避免配置文件加载时被阻止不影响推理逻辑。6.3 监控指标与告警配置vLLM的/metrics端点能暴露非常多有价值的信息这些是判断性能和稳定性的关键数据。通常建议采集这几个指标项vllm:num_requests_running当前正在推理的请求数如果这个值长期等于max_num_seqs说明系统已经满载。vllm:num_requests_waiting排队等待的请求数持续大于零说明容量不足需要扩容或限流。vllm:gpu_cache_usage_percKV cache使用率长期接近100%说明并发设置过高可能导致OOM。vllm:time_to_first_token_seconds和vllm:time_per_output_token_seconds这两个是用户可感知的延迟指标也是判断是否过度批处理的核心参考。告警规则我建议这样设gpu_cache_usage_perc高于95%持续5分钟触发warningnum_requests_waiting持续大于16触发扩容提醒Pod重启次数超过3次触发error告警。这些数值需要根据业务调整但大方向不会变。6.4 最后分享一个我们踩过的坑最后说一个印象很深的教训。有次我们升级了vLLM版本从0.6.x升到0.7.x只改了镜像tag就滚动更新了。结果新Pod一直CrashLoopBackOff看日志发现是一个旧的启动参数被移除了。因为我们没有在测试环境跑一遍全量验证直接把老命令套到新镜像上白白浪费了一个下午。从那以后我要求所有vLLM版本升级都必须先在测试环境跑一轮启动加推理的回归然后才允许上生产。后来我又在另外一个环境里遇到类似的问题这次是containerd没有正确配置GPU runtime。Pod起来以后一直报找不到CUDA设备从kubelet日志里能看到CRI创建容器时没有把GPU设备注入进去。解决办法是在containerd配置里加上nvidia runtime重启containerd后解决了。这类坑排查起来很费劲但经历一次之后你对kubelet、CRI、containerd这条链路的理解会特别深。我在实际操作中最大的体会是Kubernetes和vLLM的组合真正比拼的不是你多会用某个参数而是你能不能在出现问题时快速定位是模型层、引擎层还是编排层的问题。把单机验证做扎实、把监控指标建好、把日志采集好这三个基本功比任何“高级参数技巧”都更能保住你的睡眠质量。