干这行大半年最深的感受是推理服务上线这件事正在从“能跑就行”变成“得像个正经服务一样被管起来”。单机玩vLLM一张A100恨不得塞三个模型显存吃紧就调gpu-memory-utilization凑合也能用。可一旦你要同时服务多个业务线、多个模型还要求高并发下响应稳定身边围着五台八台GPU服务器这时候没有一个编排层光靠人肉分配GPU和端口早晚会出乱子。我目前的解法就是标题里这套组合vLLM做推理引擎K8s做资源编排和弹性伸缩。vLLM负责把显存吃透、把吞吐拉满K8s负责让每张卡都“可被调度”让推理服务像普通微服务一样扩容、缩容、滚动更新。这篇文章我不讲PPT层面的架构图就按我实际搭建这套环境的顺序把镜像选型、GPU调度、服务暴露、弹性伸缩和排障经验一条条讲清楚。不管你是刚接触K8s的算法工程师还是准备把现有推理服务容器化的运维同学这篇都能给你一条可以直接照着走的路线。1. 为什么推理服务要同时上vLLM和K8s1.1 本地跑模型和线上跑模型差的不只是性能先说个可能扎心的事实我在本地用Jupyter加载Qwen系列模型做测试和最终在K8s里跑vLLM服务两者根本是两码事。本地你更关心单次推理的延迟线上你更关心的是“每秒能处理多少请求、显存有没有打满、某个模型崩了会不会拖垮整台机器”。用Ollama或LM Studio做个人工具没问题它们的交互体验确实好但跑到高并发生产场景就会暴露短板。vLLM的优势在于PagedAttention这套显存管理机制可以把KV Cache切成分页块显存碎片大幅减少配合Continuous Batching吞吐量比朴素方案高出一大截。同样是跑DeepSeek系列或者Qwen系列vLLM在线上的稳定性和吞吐表现确实更靠谱。那K8s解决的是另一层问题。GPU是稀缺资源单位成本高最忌讳的就是某张卡闲着、某张卡排队。K8s的调度器加上Device Plugin能把GPU当做一种可量化的资源让每个Pod明确“我要一张卡、我要4张卡”节点资源不够就自动等待不会出现人肉分配导致的内存错乱。更关键的是弹性伸缩白天业务高峰多拉两个副本凌晨低谷缩成一个这事情靠手搓脚本很难做到干净利落。1.2 架构设计的三个基本决策我最终落地的架构其实很朴素但每个决策背后都有对应的理由。第一模型服务统一用vLLM的OpenAI兼容接口业务方接入零成本。原来用/v1/chat/completions换成vLLM后接口几乎不变只是URL和鉴权换一下。第二每个模型独立部署为一个Deployment模型文件放在共享存储或节点本地不混装。混装模型虽然能省显存但会导致故障域扩大一个模型OOM把整容器搞崩其它模型跟着遭殃。独立部署以后某个模型要升级版本直接滚动更新不影响别的服务。第三资源请求必须声明GPU数量不能用limits不写requests更不能把GPU资源写成CPU那样的可压缩资源。K8s对GPU是“要么整卡分配、要么不调度”的刚性逻辑一旦你写错Key调度器根本认不出来Pod会一直Pending。这套组合拳打下来最直接的收益是新模型上线从“找卡、装环境、配端口、写启动脚本”变成“写个YAML、apply一下、等服务Ready”。这个体验变化做过多模型部署的人都懂。2. 镜像与版本选型先把跑车的发动机选对2.1 vLLM镜像Tag怎么选很多新手上来就docker pull vllm/vllm-openai:latest这在生产环境是给自己埋雷。latest标签随官方更新漂移你上周验证过的行为下周拉镜像可能就变了。尤其vLLM迭代快几乎每个版本都在调KV Cache策略、调度逻辑和算子实现不同版本对同一模型的兼容性差异也大。我当前在用的固定Tag是vllm/vllm-openai:v0.27.1这个版本我实测下来加载Qwen3系列的Embedding模型和Chat模型都没问题。如果你用的是GLM系列我的建议是先查官方文档里该模型对应的推荐镜像版本别直接用新版本去赌兼容性。实际上热词里有“GLM5.3用vLLM哪个版本的镜像”我的经验是先看模型官方仓库的issue再看vLLM的Release Notes找到那个明确写了“支持XX模型”的版本号再固定下来。镜像选型还有一个实际问题体积。vLLM镜像一般好几个GB内网拉取还好公网拉取一次够等半天。所以我会把用顺手的镜像提前推到私有仓库节点从私有仓库拉取顺便在下载阶段就把镜像在每台GPU节点上预热好。这个操作能省掉后面扩容时的大量等待时间。2.2 同一套镜像跑Chat模型和Embedding模型这个点我在热词里看到有人问“v0.27.1加载qwen3-embedding-0.6b”顺手说一下我的做法。vLLM的OpenAI兼容服务默认启动Chat模型走/v1/chat/completions但Embedding模型要走/v1/embeddings接口。实际上用同一个容器镜像就能跑两种服务区别只在启动参数。跑Chat模型时我一般这样启动python3 -m vllm.entrypoints.openai.api_server \ --model /models/Qwen3-8B \ --served-model-name qwen3-8b \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --port 8000跑Embedding模型时则要加一个关键参数python3 -m vllm.entrypoints.openai.api_server \ --model /models/qwen3-embedding-0.6b \ --served-model-name qwen3-embedding \ --task embedding \ --gpu-memory-utilization 0.3 \ --port 8000注意那个--task embedding。不加这个参数vLLM会按默认的生成式模型逻辑加载Embedding模型虽然也可能启动成功但接口行为不对甚至某些权重会被错误加载。Embedding模型显存占用不大--gpu-memory-utilization可以给低一点留出空间给别的服务或者干脆把小模型和别的模型混部。2.3 硬件底线和显存规划聊完镜像聊硬件。实测下来跑7B~8B级别的量化模型一张24G显存的卡比如RTX 4090或L40S是底线要跑14B以上的模型最好直接上单卡40G以上或者用两张卡做张量并行。vLLM的--tensor-parallel-size参数控制用几张卡并行切分模型2卡并行时吞吐并不是线性翻倍但能突破单卡显存上限。这个参数一旦定了K8s的YAML里limits.nvidia.com/gpu就要对应写几两者必须一致否则Pod会一直Pending。另外显存规划有个容易忽略的点--gpu-memory-utilization不是越高越好。我踩过坑设成0.95之后模型加载没问题但显存余量太小一旦请求并发上来KV Cache预分配不够会频繁触发显存不足的报错甚至导致容器OOM。现在生产上我一般稳定在0.85~0.9之间留一点余量给CUDA上下文和碎块。3. K8s集群里让GPU“可调度”是关键3.1 GPU节点接入Device Plugin与节点标签K8s本身不认GPU它只知道CPU和内存。要让GPU变成可调度的资源必须有NVIDIA的Device Plugin在节点上运行。这个东西本质是个DaemonSet它会探测节点上的GPU数量通过Extended Resource的方式上报给K8s之后你才能在YAML里写nvidia.com/gpu这个Key。我安装的时候用的是标准做法kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.16.2/nvidia-device-plugin.yaml装完之后确认一下kubectl get nodes -o json | jq .items[].status.capacity看到nvidia.com/gpu出现在Capacity里说明节点注册成功了。这一步如果没做后面写什么都是白搭Pod会一直Pending并报“0/1 nodes available”的调度错误。另外我强烈建议给GPU节点打上专用标签比如gpu-nodetrue后面所有推理服务的Deployment都加上节点亲和性确保Pod只调度到有卡的节点上。这是最简单的防呆设计防止某次配置疏忽把推理服务调度到纯CPU节点上。3.2 显存管理整卡、MIG、时间片的取舍很多人刚开始接触GPU调度时会想一张卡能不能同时跑两个显存占用小的模型答案是默认情况下K8s NVIDIA Device Plugin只能整卡分配一个Pod声明nvidia.com/gpu: 1就会独占整张卡即使这个模型只用了30%显存。如果你确实想切分显卡有三条路方案原理适用场景缺点NVIDIA MIG硬件级显存/计算切分仅部分专业卡支持A100/A30等专业卡跑多个小模型消费卡不支持切分后单块算力缩水时间片共享多个Pod共享一张卡按时间片抢占测试环境、低优先级负载隔离性弱高并发时互相干扰vLLM自身混部一个Pod里跑多个模型实例模型数量多且显存占比小管理复杂故障域扩大生产上我目前主要用的还是整卡分配配合vLLM自身的--gpu-memory-utilization参数来控制单模型显存占用通过“每张卡一个Pod”来保证稳定性。MIG方案我在A100上试过确实能把一张80G卡切成几块但配置复杂而且每块的计算能力是固定的如果请求量波动大反而捉襟见肘。3.3 初始化集群时“API Server不健康”的经典坑热词里提到一个报错“k8s控制节点master初始化显示the api server is not healthy after 4m0.00747357s”这个我太熟了几乎每个新集群都会碰到一次。这个报错本身信息量不大核心是kubeadm init之后等待API Server健康检查超时背后最常见的原因有三个第一系统资源不足。Master节点至少保证2核4G尤其是containerd或docker要能正常运行否则kube-apiserver容器根本起不来。我当时排查时第一件事就是crictl ps -a看容器状态发现kube-apiserver压根没起来。第二swap没关或网络配置不对。K8s要求关闭swapswapoff -a之后还要确保/etc/fstab里没有自动挂载swap的配置否则重启又回来。第三缺少CNI插件。初始化不装CNI集群的kube-system命名空间里一堆Pod会CrashLoopBackOffAPI Server本身能起来但网络组件没就绪。我在初始化完成后立刻装Calico或Flannel再执行kubectl get nodes看是否Ready。这个报错还有一个隐蔽原因就是/etc/hosts里没有解析本机主机名。kube-apiserver的健康检查走的是本机通信主机名解析不到回环地址就会一直不健康。我后来都习惯在/etc/hosts里显式加一行127.0.0.1 hostname。4. 推理服务Deployment实战与访问接入4.1 关键Resource配置逐行拆解下面直接给一份能用的Deployment配置以qwen3-embedding-0.6b为例因为它显存占用小部署成本低适合作为试验田。apiVersion: apps/v1 kind: Deployment metadata: name: qwen3-embedding namespace: ai spec: replicas: 1 selector: matchLabels: app: qwen3-embedding template: metadata: labels: app: qwen3-embedding spec: nodeSelector: gpu-node: true containers: - name: vllm image: registry.internal/vllm/vllm-openai:v0.27.1 command: [python3, -m, vllm.entrypoints.openai.api_server] args: - --model - /models/qwen3-embedding-0.6b - --served-model-name - qwen3-embedding - --task - embedding - --gpu-memory-utilization - 0.3 - --port - 8000 ports: - containerPort: 8000 resources: requests: cpu: 2 memory: 4Gi nvidia.com/gpu: 1 limits: cpu: 4 memory: 8Gi nvidia.com/gpu: 1 readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 60 periodSeconds: 10几个关键点解读一下requests和limits里的nvidia.com/gpu必须一致。GPU做不了CPU那样的超卖只能requestslimits否则调度器会直接报错。CPU和内存我习惯留一定余量因为vLLM处理长文本时CPU开销也不小limits给到requests的两倍比较合适。readinessProbe探活路径用/health。vLLM提供/health和/v1/models两个健康检查接口前者更快但只检查进程存活后者会额外检查模型是否成功加载。我用/health并配合initialDelaySeconds: 60给模型加载留了足够时间。注意不要用/v1/models当探活路径模型加载阶段这个接口响应很慢探活容易超时误判。4.2 服务暴露方式ExternalIPs / NodePort / LoadBalancer推理服务部署好之后得让业务方访问到。K8s的Service暴露方式里热词里提到了externalips这里就展开讲一下。我在的机房没有云厂商的LoadBalancer插件所以在三种方式里做选择NodePort在每个节点上开一个30000以上的随机端口通过http://任意节点IP:节点端口访问。配置简单但端口数量有限且要记住每个服务对应哪个端口服务多了容易乱。LoadBalancer需要云厂商提供LB插件机房环境没有就得自己装MetalLB。MetalLB分配的VIP倒是好用但那又是另一个组件要维护。ExternalIPs直接在Service定义里指定节点IP把Service暴露到特定IP上。配置最简单适合内部服务场景但要做好IP规划不能跟已有IP冲突。我目前的做法是内部推理服务统一用ClusterIP只有需要供外部业务方调用的服务才用ExternalIPs配置如下apiVersion: v1 kind: Service metadata: name: qwen3-embedding-svc namespace: ai spec: type: ClusterIP selector: app: qwen3-embedding ports: - port: 8000 targetPort: 8000 protocol: TCP externalIPs: - 10.10.10.10这样业务方就能通过http://10.10.10.10:8000/v1/embeddings访问到了。可以这样理解Service相当于一个固定门牌号Pod内部IP变了也不影响访问ExternalIPs则额外告诉路由器“这个门牌号使用的网络IP段是哪些”把链路串起来。4.3 上线验证OpenAI接口、metrics、日志一个推理服务上线后怎么确认它真正能扛流量我的检查顺序是先看Pod日志。vLLM启动阶段会打印模型加载日志包括权重文件路径、显存分配情况、总耗时。看到Starting vLLM server基本等于服务起来了kubectl logs -n ai deploy/qwen3-embedding -f然后看metrics。vLLM接口暴露了Prometheus格式的指标默认端口是/metrics里面有几个关键指标vllm:num_requests_running、vllm:num_requests_waiting、vllm:gpu_cache_usage_perc。前两个反映当前排队和运行的请求数第三个反映显存KV Cache占用率。这个在后文HPA配置里是核心依据。最后做一次真实调用验证curl http://10.10.10.10:8000/v1/embeddings \ -H Content-Type: application/json \ -d { model: qwen3-embedding, input: vLLM K8s 实战测试 }返回的向量维度对不对多测几条中文和英文句子确认Embedding行为符合预期。跑Chat模型的话就调/v1/chat/completions看响应速度和首Token延迟。5. 弹性伸缩从“人人抢卡”到“按需发卡”5.1 别拿CPU当伸缩依据做弹性伸缩最忌讳的是用CPU使用率作为唯一的HPA指标。推理服务是GPU密集型应用CPU可能一直维持在30%但显存已经打满请求排队排了几百个。这时候如果HPA只看CPUPod永远不会扩容业务就开始超时。反过来如果模型刚加载完还没接流量CPU和GPU都处于低水位这时候如果因为CPU低就缩容那下个请求来又得冷启动重新加载模型体验极差。所以我强烈建议伸缩指标必须来自vLLM的metrics而不是节点指标。vLLM暴露的vllm:num_requests_waiting是最直观的“业务排队数”这个值一旦长期大于某个阈值说明当前副本数已经扛不住了。5.2 基于vLLM队列长度的HPA配置示例要用自定义指标做HPA前提是集群里有一套监控体系能把vLLM的metrics采集并暴露成custom.metrics.k8s.io或external.metrics.k8s.io接口。我这边用的是Prometheus prometheus-adapter的方案metrics采集规则里把vLLM的/metrics抓进来然后注册一个自定义指标命名成vllm_waiting_requests。HPA配置大致长这样apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: qwen3-embedding-hpa namespace: ai spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: qwen3-embedding minReplicas: 1 maxReplicas: 3 metrics: - type: Pods pods: metric: name: vllm_waiting_requests target: type: AverageValue averageValue: 10意思是当每个Pod上的平均排队请求数大于10时逐步扩容副本小于这个值则缩容。这里有个细节容易被忽略HPA扩容不是立刻加副本就立刻生效。新副本拉起来后要把模型文件加载到显存这个时间可能长达几十秒甚至几分钟。扩容时副本数还没就绪流量会继续堆积所以如果业务波动剧烈可以把HPA的扩容周期调短一些或者配合K8s的ClusterAutoscaler做节点级扩容保证底层有足够的GPU资源。缩容侧则恰恰相反建议把--horizontal-pod-autoscaler-downscale-stabilization调大比如5分钟防止流量毛刺导致频繁销毁Pod把模型反复卸载加载。5.3 避免雪崩冷却时间与缩容保护弹性伸缩做不好最典型的雪崩场景是流量突增→扩容一个新副本→新副本加载模型耗时长→流量继续堆积→HPA再次扩容→节点GPU不足→新副本Pending→老副本被流量压垮→大量超时。要避免这个局面我对策有三条。第一给每个Deployment设置replicas下限哪怕凌晨没流量也至少保留一个副本保证模型热加载。这样早上流量突然上来时至少有一个副本已经在服务扩容只是“加一个”而不是“从零开始”。第二HPA扩容策略配置成“立即扩容”。默认HPA扩容周期是30秒缩容周期是300秒这个默认值其实比较合理但如果你的业务在一天内波动很大可以在HPA高级配置里调整behavior.scaleUp的stabilizationWindowSeconds从默认的0再往上调一点即可实际测试下来保留30秒左右能兼顾响应速度和稳定性。第三节点资源预留。GPU节点至少要预留一小部分资源或者在调度层面配置Pod优先级保证高优的推理服务能在资源紧张时抢占低优任务的资源。这个我们在生产里靠ResourceQuota和PriorityClass做的简单说就是给核心推理服务一个high-priority的PriorityClass让它在节点容量不足时优先调度。6. 生产环境排障实录与运维心得6.1 几个常见的GPU调度问题问的人最多的问题之一kubectl describe pod里面看到0/2 nodes available: 1 Insufficient nvidia.com/gpu, 1 node(s) didnt match pod anti-affinity rules。这种一般是显存真不够或者节点标签没匹配上。先执行kubectl get nodes --show-labels | grep gpu-node确认标签再kubectl describe node 节点名看GPU容量和已分配情况找出问题基本在十秒内。另一个高频坑是Pod运行一段时间后变成CrashLoopBackOff。看日志发现是CUDA out of memory。这种情况往往不是权重文件太大而是--gpu-memory-utilization给得太高加上max-model-len设得太大KV Cache预分配吃掉了太多显存。处理方法就是调低这两个参数我一般先看nvidia-smi确认一下进程实际显存占用再回头调参。还有一类情况是Pod一直Pending节点上明明有空卡。这大概率是Device Plugin没起来。检查kubectl get ds -n kube-system确认nvidia-device-plugin处于Running状态。如果之前装过旧版本插件升级后又残留在节点上也会导致资源状态错乱这时候重启节点上的kubelet和插件Pod最直接。6.2 模型加载太慢导致Pod频繁重启模型文件几个GB到几十GB加载到显存本来就要时间。K8s的readinessProbe如果initialDelaySeconds设得太短比如10秒模型还在加载探活请求直接失败K8s认为Pod不健康就重启重启又得从头加载陷入死循环。我这边现在用两个手段解决。一是模型文件放在节点本地SSD或高性能共享存储上不走NFS的慢速IO。同样一个7B模型放分布式文件系统加载可能要两三分钟放本地NVMe可能只要三四十秒。速度差几倍直接决定了Pod能不能快速Ready。二是readinessProbe的initialDelaySeconds给足。我一般按模型大小估算7B模型给60秒70B模型给300秒。同时把failureThreshold调大一点比如10次避免偶发IO抖动导致误杀。还有一个思路用preStop钩子对优雅退出做处理但实际意义有限GPU显存里的模型断电即失没有像数据库那样的持久化概念。更值得做的是在Deployment上配置strategy.rollingUpdate.maxUnavailable0这样滚动更新时老Pod会一直服务到新Pod Ready用户无感知。6.3 我的几条避坑清单最后整理一下这段时间攒下来的经验都是踩完坑才记住的。关于资源声明GPU的requests和limits必须一致且Key必须是nvidia.com/gpu别写成gpu或者nvidia/gpu。这个拼写错误能让调度器完全无视你的请求Pod Pending一整天你都不知道哪错了。关于镜像仓库镜像Tag千万别用latest哪怕测试环境也别用。我用latest吃过一次亏某天早上模型加载行为变了查了半天发现是vLLM镜像悄悄更新了。现在所有部署一律用固定Tag加摘要保证确定性。关于显存规划一张卡只部署一个大模型比硬塞两个小模型更省心。真碰上小模型优先考虑把多个模型放进同一个vLLM实例通过--served-model-name区分而不是在K8s层面切分显卡。关于监控GPU利用率、显存占用、请求队列这三个指标比任何业务层的自定义指标都有用。先盯这三样再去看业务指标排障路径会清晰很多。关于备份K8s的Deployment YAML是我的“基础设施即代码”每一个推理服务上线前都要提交到Git仓库。出了问题直接回滚上一个版本比在命令行里敲kubectl edit快速得多。这套vLLM K8s的方案跑下来最直观的成果就是把模型部署从“一个个手动伺候”变成了“写配置、提交、自动调度”。坦白说光是解决“某个模型挂了不影响其它模型”这一点就已经值回所有搭建成本了。如果你的环境也到了多模型、多GPU节点、需要弹性伸缩的阶段这篇文章里给的参数和命令可以直接作为起点剩下的坑等你踩到了自然就懂我为什么强调这些细节。