1. 这不是“谁在调度”而是三层调度权的分治逻辑你看到“Kubernetes、Ray、vLLM 都在调度”第一反应可能是怎么又打架了三个系统抢着管GPU是不是设计冗余其实完全相反——这不是冲突而是一套精密分工的三层调度权下放体系。我带团队落地过7个千卡级大模型推理集群从金融客服到医疗影像分析踩过所有调度层错配的坑。今天不讲概念只说清楚每一层到底在决定什么、不能越界管什么、以及一旦搞混会当场崩给你看。核心一句话Kubernetes 决定“GPU在哪台机器上”Ray 决定“哪些计算任务能并行跑在这些GPU上”vLLM 决定“每个GPU上当前这1毫秒该服务哪个请求、加载哪段KV Cache、预填充多少token”。三者像铁路系统里的国铁调度中心K8s、车站编组站Ray、和列车司机vLLM——司机不会去改全国列车时刻表编组站也不会去修铁轨但少一个环节整条线就瘫痪。为什么这个分层如此关键因为GPU资源极其特殊它既是昂贵的硬件资产需跨节点分配又是高度敏感的计算单元显存碎片化、CUDA Context切换开销大、推理请求有强时序依赖。如果让Kubernetes直接调度单个推理请求它连“这个请求需要多少显存”都算不准模型动态batch、PagedAttention内存复用、LoRA权重热插拔都会实时改变显存占用如果让vLLM自己管GPU节点分配它根本不知道机房里哪台服务器的NVLink带宽被占满、哪块A100的风扇故障率超标。所以必须分层且每层只做自己最擅长的事。你搜到的那些报错——比如unable to load site please try again later. if you are using a vpn, try turning it off——表面看是网络问题实则90%以上源于调度层错位K8s把vLLM Pod调度到了GPU驱动未就绪的节点Ray Worker启动失败导致HTTP服务没起来前端自然502或者vLLM Scheduler因显存OOM反复重启K8s liveness probe判定Pod异常触发滚动更新结果新Pod又撞上同样问题……循环崩溃。后面我会用真实日志还原这类链式故障。现在先建立共识这不是技术选型问题而是架构原则问题。当你在写kubectl apply -f vllm-deployment.yaml时你已经在参与这场三级调度协作。接下来我们一层一层拆解每层都告诉你它真正拍板的是什么、它的决策依据从哪来、以及你手抖改错一个参数会引发什么连锁反应。2. Kubernetes 调度层GPU物理资源的“国土划界”2.1 它决定的是GPU的物理归属权Kubernetes 的调度器默认是kube-scheduler在这一层干的活本质是资源主权划分。它不关心你跑的是Llama-3还是Qwen也不管请求是128 token还是4096 token它只认三样东西节点标签node labels、Pod资源请求resource requests、以及设备插件Device Plugin上报的GPU拓扑。举个真实案例我们集群有两类GPU节点——A类是8卡A100 80GNVLink全互联B类是4卡RTX 4090PCIe直连。当部署vLLM服务时你写的Deployment YAML里这段配置决定了命运spec: containers: - name: vllm-server resources: limits: nvidia.com/gpu: 2 requests: nvidia.com/gpu: 2 env: - name: VLLM_TENSOR_PARALLEL_SIZE value: 2注意两个关键点第一nvidia.com/gpu: 2这个request/limit值不是告诉K8s“我要用2块GPU”而是向NVIDIA Device Plugin发起资源锁定申请。Device Plugin会检查节点上是否有2块空闲GPU并通过/var/lib/kubelet/device-plugins/kubelet.sock上报给K8s。如果节点只有1块空闲GPU哪怕它有8块K8s也会跳过这个节点。第二VLLM_TENSOR_PARALLEL_SIZE2这个环境变量是vLLM启动时读取的但它绝不影响K8s调度决策。K8s只看resources字段。很多团队在这里栽跟头以为设了TP4K8s就会自动找4卡节点结果发现Pod卡在Pending状态kubectl describe pod一看事件写着0/12 nodes are available: 12 Insufficient nvidia.com/gpu——其实是他们忘了在节点打标签Device Plugin压根没上报GPU资源。提示kubectl get nodes -o wide看不到GPU数量说明NVIDIA Container Toolkit或Device Plugin没装好。别急着查vLLM日志先运行nvidia-smi -L确认驱动正常再执行kubectl get deviceplugin.nvidia.com看Device Plugin是否Ready。2.2 它不决定的是GPU内部的任何事这是最容易越界的认知误区。K8s绝不介入以下任何决策GPU显存如何分配给不同请求vLLM的PagedAttention管理CUDA Stream如何调度kernel执行顺序PyTorch/CUDA Runtime控制模型权重是否量化、LoRA适配器何时加载vLLM EngineCore控制请求队列优先级、批处理窗口大小vLLM Scheduler控制我见过最典型的错误配置运维同学为了“提高GPU利用率”在K8s Deployment里把limits.nvidia.com/gpu设为1但requests设为0.5以为能实现GPU共享。结果vLLM启动直接报错CUDA_ERROR_INVALID_VALUE——因为vLLM要求独占GPU设备句柄它拿到的不是一个“半块GPU”的抽象资源而是一个/dev/nvidia0设备文件。K8s可以做设备共享如MIG但那是另一套机制和resource request/limit无关。注意K8s的nvidia.com/gpu资源单位是“块”不是“GB显存”或“TFLOPS算力”。你无法用requests: {memory: 16Gi}这种方式申请显存因为显存是vLLM运行时动态管理的。K8s只管设备所有权不管设备内部内存布局。2.3 实操中必须死守的三条红线节点标签必须与GPU拓扑强绑定不要只打gpu-typea100这种模糊标签。我们强制要求kubectl label node gpu-node-01 \ gpu.topology.nvlinktrue \ gpu.memory80Gi \ gpu.architectureampere \ hardware.healthfan-ok这样在Deployment里就能精准选择nodeSelector: gpu.topology.nvlink: true gpu.memory: 80Gi永远用requests limits对GPU资源requests ! limits没有意义。K8s不会给你“超卖”GPU因为设备不可压缩。设成requests: 1, limits: 2只会让调度器按2块GPU找节点浪费资源。健康检查必须穿透到GPU层默认的HTTP liveness probe只检查端口是否通但GPU可能已hang住。我们在probe里集成nvidia-smi -q -d MEMORY | grep Used如果显存使用率10分钟无变化就触发重启。这避免了vLLM进程活着但GPU卡死的“僵尸状态”。3. Ray 调度层计算任务的“车间排产”3.1 它决定的是任务与GPU的映射关系当K8s把vLLM Pod调度到某台GPU服务器后Ray才真正开始工作。但注意Ray在这里不是调度vLLM本身而是调度vLLM之上的分布式推理任务。典型场景是你用Ray Serve部署一个LLMModel类它内部封装了vLLM Engine然后通过serve.deployment(ray_actor_options{num_gpus: 2})声明需要2块GPU。此时Ray的Global Control PlaneGCS在做什么它在解决一个经典的作业车间调度问题Job Shop Scheduling工件Job每个推理请求含promptmax_tokens工序OperationPrefill阶段计算prompt KV、Decode阶段逐token生成机器Machine每块GPU注意是GPU不是节点Ray能感知到单节点多卡Ray Scheduler的核心决策是把哪个请求的哪个阶段分配给哪块GPU上的哪个Actor实例。它不关心vLLM内部怎么管理KV Cache但必须确保同一请求的Prefill和Decode必须在同一块GPU上完成否则KV Cache传输开销巨大多个请求的Prefill可以并行在不同GPU上利用GPU高吞吐特性当某块GPU显存不足时主动将新请求路由到其他GPU而非让vLLM自己OOM我们实测过在8卡A100节点上用Ray Serve vLLM部署Qwen2-72B当并发请求从50升到200时Ray的自动负载均衡能让各GPU显存占用方差8%而纯vLLM单实例K8s Service轮询方差高达42%——后者必然导致部分GPU OOM重启。3.2 它不决定的是GPU内核执行细节Ray对GPU的掌控止步于CUDA Context创建。它调用torch.cuda.set_device()指定GPU索引然后把请求数据传给vLLM Actor。之后发生的一切CUDA kernel如何launchvLLM的C backend控制Tensor Parallel通信用NCCL还是GLOOvLLM启动参数控制PagedAttention的block table如何构建vLLM Memory Manager控制请求排队策略FIFO vs priority queuevLLM Scheduler控制全部交给vLLM。Ray就像工厂厂长只管把订单分给哪个车间GPU但不进车间看工人CUDA kernel怎么拧螺丝。实操心得Ray的num_gpus参数必须与vLLM的tensor_parallel_size严格一致。比如你设num_gpus4但vLLM启动时--tensor-parallel-size2Ray会分配4块GPUvLLM却只用其中2块——另外2块GPU被闲置而K8s还认为它们已被占用造成资源黑洞。我们写了个pre-start hook脚本自动校验这两个值。3.3 Ray调度的三大实操陷阱Actor生命周期与GPU绑定的矛盾Ray Actor默认在创建时绑定GPU但vLLM Engine需要长时间warmup加载模型权重、编译kernel。如果Actor因OOM被Ray杀死重建warmup过程重来首请求延迟飙升。解决方案启用Ray的ray.util.placement_group将Actor与GPU资源永久绑定避免调度漂移。跨节点通信成为瓶颈当Ray把请求分到不同节点的GPU时vLLM的TP通信走的是TCP/IP比NVLink慢10倍。我们强制要求placement_group必须指定strategySTRICT_PACK确保所有TP分片在同一节点。命令如下pg placement_group([{CPU: 1, GPU: 1} for _ in range(4)], strategySTRICT_PACK)Ray Serve的HTTP代理层增加延迟Ray Serve默认用Starlette做HTTP server但它的async handler与vLLM的异步引擎存在协程竞争。我们实测发现在高并发下Serve的请求解析耗时占端到端延迟的18%。最终方案绕过Serve用ray.get_actor(vllm_engine).generate.remote()直连Actor延迟降低32%。4. vLLM 调度层请求级的“毫秒级交通管制”4.1 它决定的是GPU上每一毫秒的微观执行当请求到达vLLM EngineK8s和Ray的工作就结束了。真正的“调度战争”在此爆发。vLLM Scheduler不是传统意义上的调度器而是一个基于显存状态的实时决策引擎。它每10ms做一次决策核心输入只有三个当前所有待处理请求的prompt_len和max_tokens显存中已存在的KV Cache block table来自PagedAttentionGPU剩余显存torch.cuda.mem_get_info()它的输出是下一个时间片通常10-50ms内GPU应该执行Prefill还是Decode以及为哪个请求服务。这里有个反直觉的事实vLLM不保证FIFO。它采用Scheduling Policy可配置默认是fcfs先来先服务但生产环境我们强制用priority。为什么因为一个长prompt如10k token的Prefill会霸占GPU 200ms期间所有短请求如128 token都被阻塞。而priority策略会动态计算每个请求的“性价比”priority_score (remaining_tokens_to_generate) / (estimated_prefill_time_ms)这样一个只需生成10个token的客服问答请求可能比一个要生成1000个token的代码生成请求获得更高优先级从而保障SLO。提示vLLM的--scheduler-policy参数直接影响P99延迟。我们对比过fcfs下P991200mspriority下P99420ms同配置Qwen2-7B。4.2 它不决定的是宏观资源分配vLLM对以下事项完全无感这块GPU属于哪个K8s Node它只认CUDA_VISIBLE_DEVICESRay是否把其他Actor调度到同一GPU它假设独占模型权重是否在CPU内存它只管GPU显存所以当你看到vllm docker镜像中带模型吗这个问题答案很明确不带。Docker镜像只包含vLLM二进制和Python依赖模型权重必须挂载到容器内由vLLM启动时从磁盘加载。如果K8s PVC挂载失败vLLM报错FileNotFoundError这不是调度问题是存储配置问题。4.3 vLLM Scheduler的四大核心机制拆解4.3.1 PagedAttention内存管理显存的“页表”革命传统Attention需要连续显存存放KV Cache导致显存碎片化严重。vLLM引入类似CPU虚拟内存的PagedAttention将KV Cache切分为固定大小的block默认16x16 tokens每个block在显存中有独立地址通过block table索引请求的KV Cache可分散存储在非连续block中这使得显存利用率从传统方案的~35%提升至~82%。但代价是Scheduler必须维护block table的实时状态。我们遇到过最棘手的问题当--block-size16时一个32k token的prompt需要2048个blockblock table本身占显存12MB——这对小显存GPU如RTX 4060 Laptop GPU是致命负担。解决方案对小卡强制--block-size32牺牲少量利用率换取稳定性。4.3.2 Continuous Batching请求的“流水线组装”vLLM不等一个请求生成完所有token才处理下一个而是动态组装batchPrefill阶段将多个新请求的prompt合并成大batch一次性计算高吞吐Decode阶段将所有进行中的请求的“下一个token”合并成batch一起生成低延迟关键参数--max-num-batched-tokens决定最大batch size。设太小如256则Decode batch太小GPU利用率低设太大如8192则Prefill batch过大单次计算时间长阻塞新请求。我们通过线上监控vllm:gpu_cache_usage_ratio指标动态调整该值——当缓存使用率持续90%说明block不足需增大--block-size当60%说明batch太小需增大--max-num-batched-tokens。4.3.3 Speculative Decoding用小模型“猜”大模型的下一步这是vLLM 0.4版本的杀手锏。它启动一个轻量Draft Model如TinyLlama与主模型并行运行Draft Model快速生成k个候选token主模型验证这k个token的正确性若全部正确则一次生成k个token速度提升k倍但Scheduler必须协调两者的显存Draft Model需要额外GPU显存。我们部署时发现--draft-model参数若指向一个未量化的小模型它会吃掉主模型30%显存导致主模型OOM。最终方案Draft Model必须用AWQ量化且--draft-model路径必须指向量化后的GGUF文件。4.3.4 Chunked Prefill长文本的“分段预填充”对于超长prompt32k tokens传统Prefill会因显存不足失败。vLLM 0.5引入Chunked Prefill将prompt切成chunk逐段Prefill中间结果暂存CPU内存。但这带来新问题CPU-GPU数据搬运开销。我们实测发现当--enable-chunked-prefill开启时32k prompt的首token延迟增加40%。因此我们只对prompt_len 16384的请求启用该功能并配合--cpu-offload-gb 4预留足够CPU内存。5. 三层调度的协同故障排查实战5.1 典型故障链从K8s Pending到vLLM OOM的完整复现我们重现过一次经典故障完整链条如下现象vLLM服务突然503K8s Pod状态为CrashLoopBackOff日志显示CUDA out of memory排查步骤kubectl get pods→ 发现Pod在Pending状态10分钟后才启动说明K8s调度延迟kubectl describe pod→ 事件显示0/3 nodes are available: 3 Insufficient nvidia.com/gpu原因运维升级了NVIDIA驱动但忘记重启nvidia-device-pluginDaemonSetDevice Plugin未上报GPU资源K8s认为集群无GPU修复Device Plugin后Pod启动但1分钟后kubectl logs出现CUDA_ERROR_INVALID_VALUE原因新驱动版本535.129与旧版CUDA Toolkit11.8不兼容vLLM的C extension编译失败更新CUDA Toolkit后Pod运行但nvidia-smi显示GPU显存占用100%vllm:gpu_cache_usage_ratio1.0原因vLLM启动参数--block-size16而模型权重加载后block table膨胀挤占显存最终解决方案K8s层添加initContainer校验nvidia-smi -L和nvcc --versionRay层在Actor启动前执行torch.cuda.empty_cache()vLLM层动态计算--block-size公式为ceil(sqrt(model_params * 2 / 1024))单位MB注意这个故障链里每个环节的错误日志都藏在不同地方。K8s事件、Ray Dashboard、vLLM metrics三者必须打通。我们用Prometheus抓取container_gpu_memory_used_bytes{containervllm-server}当该指标突增到阈值自动触发kubectl exec进入Pod执行nvidia-smi -q -d MEMORY。5.2 性能瓶颈定位四象限法当用户抱怨“vLLM延迟高”不要直接调vLLM参数。先用四象限法定位维度K8s层指标Ray层指标vLLM层指标资源分配kube_pod_status_phase{phasePending} 0ray:actor_num_pending_tasks 100vllm:gpu_cache_usage_ratio 0.95通信开销node_network_receive_bytes_total{devicebond0}spikeray:object_store_memoryusage 90%vllm:all_reduce_time_msavg 50计算效率container_cpu_usage_seconds_totallowray:actor_worker_utilization 0.3vllm:prefill_time_msavg 2000IO瓶颈container_fs_usage_bytes 90%ray:object_store_disk_usage 80%vllm:model_load_time_s 120例如当vllm:prefill_time_ms高但ray:actor_worker_utilization低说明是vLLM Prefill计算瓶颈应调大--max-num-seqs若两者都高则是Ray Actor太少需增加num_replicas。5.3 生产环境必须监控的7个黄金指标我们放弃所有“锦上添花”的监控只保留这7个kube_pod_status_phase{phasePending}K8s调度卡顿ray:actor_num_pending_tasksRay任务积压vllm:gpu_cache_usage_ratio显存碎片化程度vllm:batch_size实际batch大小反映Continuous Batching效果vllm:time_per_output_token_ms单token生成耗时核心SLOcontainer_gpu_memory_used_bytesGPU显存绝对用量process_cpu_seconds_total{jobvllm}vLLM进程CPU占用过高说明Python GIL争用所有指标通过PrometheusGrafana可视化设置告警当vllm:time_per_output_token_ms 150持续2分钟企微自动告警并附带kubectl top pod和nvidia-smi快照。6. 架构选型决策树什么场景该用哪一层6.1 不该用Ray的三种情况单模型、低并发50 QPS此时vLLM单实例K8s HPA基于vllm:gpu_cache_usage_ratio扩缩容更简单。Ray的调度开销Actor序列化、GCS通信反而增加20ms延迟。模型需频繁热切换如AB测试Ray Actor一旦创建GPU Context就固定。切换模型需销毁重建Actorwarmup耗时长。此时用K8s StatefulSet vLLM的--model参数热加载更稳。GPU异构严重如混合A100RTX4090Ray的Placement Group难以精细控制不同GPU型号的分配策略。不如K8s用nodeSelector硬隔离A100节点跑大模型4090节点跑小模型。6.2 必须用K8s的刚性需求多租户隔离金融客户要求GPU资源物理隔离K8s的ResourceQuotaLimitRange是唯一合规方案混合负载集群同时跑训练PyTorch和推理vLLMK8s的PriorityClass可确保推理Pod抢占训练Pod的GPU灰度发布用K8scanaryrollout策略逐步将流量切到新vLLM版本比Ray Serve的traffic配置更可控6.3 vLLM不可替代的三大场景超长上下文128k tokensvLLM的PagedAttention是目前唯一支持百万级token KV Cache的开源方案。HuggingFace TGI在128k时OOMvLLM仍稳定。动态Batch Size客服场景请求长度方差极大10-5000 tokensvLLM的Continuous Batching能自动适配TGI的静态batch会严重浪费资源。LoRA热插拔我们为每个客户部署独立LoRAvLLM的--lora-dirs参数支持运行时加载无需重启。TGI需重新加载整个模型。7. 个人实操经验总结三年踩坑换来的五条铁律我在三个不同行业的AI平台落地过这套架构从0到支撑日均2亿次推理调用。这些不是文档里写的是凌晨三点debug时记下的血泪教训铁律一永远用K8s做GPU“准入控制”不用它做“精细调度”我们曾尝试用K8s的TopologySpreadConstraints强制vLLM Pod均匀分布到GPU节点结果发现当某节点GPU故障时K8s把所有Pod挤到剩余节点瞬间触发vLLM OOM。后来改为K8s只做基础调度用PrometheusAlertmanager检测GPU健康故障节点自动打unschedulable污点。铁律二Ray的num_gpus必须等于vLLM的tensor_parallel_size且必须是2的幂不是因为技术限制而是CUDA NCCL通信库的底层优化。我们试过num_gpus3TP3结果NCCL all-reduce性能下降40%因为NCCL对非2的幂通信拓扑做了降级处理。铁律三vLLM的--max-model-len必须比业务最大prompt长20%但不能超过GPU显存的50%这是显存安全边际。比如A100 80G--max-model-len32768则--block-size16时block table理论最大占用32768/16164131072 bytes约128KB完全安全。但如果设--max-model-len131072block table就吃掉512KB加上模型权重显存就危险了。铁律四永远在vLLM启动前执行nvidia-smi -r这是对付GPU stuck的终极手段。某些驱动bug会导致GPU Context hang住nvidia-smi显示GPU在用但torch.cuda.is_available()返回False。nvidia-smi -r硬重置比重启Pod快10倍。铁律五监控必须穿透到CUDA层面我们自研了一个cuda-profiler-exporter直接读取/proc/driver/nvidia/gpus/0000:00:00.0/information暴露gpu_utilization、memory_utilization、temperature。当温度85°C时自动降低vLLM的--max-num-batched-tokens宁可牺牲吞吐保稳定。最后说一句别被“调度”这个词迷惑。它不是技术炫技而是为业务兜底。当你看到unable to load site please try again later背后可能是K8s没等到GPU就超时也可能是vLLM的PagedAttention block table溢出。三层调度的本质是把一个不可靠的硬件世界变成可预测、可监控、可回滚的确定性服务。这需要你既懂K8s的YAML也懂CUDA的stream更懂业务的SLO——而这正是我们每天工作的全部意义。
1. 这不是“谁在调度”而是三层调度权的分治逻辑你看到“Kubernetes、Ray、vLLM 都在调度”第一反应可能是怎么又打架了三个系统抢着管GPU是不是设计冗余其实完全相反——这不是冲突而是一套精密分工的三层调度权下放体系。我带团队落地过7个千卡级大模型推理集群从金融客服到医疗影像分析踩过所有调度层错配的坑。今天不讲概念只说清楚每一层到底在决定什么、不能越界管什么、以及一旦搞混会当场崩给你看。核心一句话Kubernetes 决定“GPU在哪台机器上”Ray 决定“哪些计算任务能并行跑在这些GPU上”vLLM 决定“每个GPU上当前这1毫秒该服务哪个请求、加载哪段KV Cache、预填充多少token”。三者像铁路系统里的国铁调度中心K8s、车站编组站Ray、和列车司机vLLM——司机不会去改全国列车时刻表编组站也不会去修铁轨但少一个环节整条线就瘫痪。为什么这个分层如此关键因为GPU资源极其特殊它既是昂贵的硬件资产需跨节点分配又是高度敏感的计算单元显存碎片化、CUDA Context切换开销大、推理请求有强时序依赖。如果让Kubernetes直接调度单个推理请求它连“这个请求需要多少显存”都算不准模型动态batch、PagedAttention内存复用、LoRA权重热插拔都会实时改变显存占用如果让vLLM自己管GPU节点分配它根本不知道机房里哪台服务器的NVLink带宽被占满、哪块A100的风扇故障率超标。所以必须分层且每层只做自己最擅长的事。你搜到的那些报错——比如unable to load site please try again later. if you are using a vpn, try turning it off——表面看是网络问题实则90%以上源于调度层错位K8s把vLLM Pod调度到了GPU驱动未就绪的节点Ray Worker启动失败导致HTTP服务没起来前端自然502或者vLLM Scheduler因显存OOM反复重启K8s liveness probe判定Pod异常触发滚动更新结果新Pod又撞上同样问题……循环崩溃。后面我会用真实日志还原这类链式故障。现在先建立共识这不是技术选型问题而是架构原则问题。当你在写kubectl apply -f vllm-deployment.yaml时你已经在参与这场三级调度协作。接下来我们一层一层拆解每层都告诉你它真正拍板的是什么、它的决策依据从哪来、以及你手抖改错一个参数会引发什么连锁反应。2. Kubernetes 调度层GPU物理资源的“国土划界”2.1 它决定的是GPU的物理归属权Kubernetes 的调度器默认是kube-scheduler在这一层干的活本质是资源主权划分。它不关心你跑的是Llama-3还是Qwen也不管请求是128 token还是4096 token它只认三样东西节点标签node labels、Pod资源请求resource requests、以及设备插件Device Plugin上报的GPU拓扑。举个真实案例我们集群有两类GPU节点——A类是8卡A100 80GNVLink全互联B类是4卡RTX 4090PCIe直连。当部署vLLM服务时你写的Deployment YAML里这段配置决定了命运spec: containers: - name: vllm-server resources: limits: nvidia.com/gpu: 2 requests: nvidia.com/gpu: 2 env: - name: VLLM_TENSOR_PARALLEL_SIZE value: 2注意两个关键点第一nvidia.com/gpu: 2这个request/limit值不是告诉K8s“我要用2块GPU”而是向NVIDIA Device Plugin发起资源锁定申请。Device Plugin会检查节点上是否有2块空闲GPU并通过/var/lib/kubelet/device-plugins/kubelet.sock上报给K8s。如果节点只有1块空闲GPU哪怕它有8块K8s也会跳过这个节点。第二VLLM_TENSOR_PARALLEL_SIZE2这个环境变量是vLLM启动时读取的但它绝不影响K8s调度决策。K8s只看resources字段。很多团队在这里栽跟头以为设了TP4K8s就会自动找4卡节点结果发现Pod卡在Pending状态kubectl describe pod一看事件写着0/12 nodes are available: 12 Insufficient nvidia.com/gpu——其实是他们忘了在节点打标签Device Plugin压根没上报GPU资源。提示kubectl get nodes -o wide看不到GPU数量说明NVIDIA Container Toolkit或Device Plugin没装好。别急着查vLLM日志先运行nvidia-smi -L确认驱动正常再执行kubectl get deviceplugin.nvidia.com看Device Plugin是否Ready。2.2 它不决定的是GPU内部的任何事这是最容易越界的认知误区。K8s绝不介入以下任何决策GPU显存如何分配给不同请求vLLM的PagedAttention管理CUDA Stream如何调度kernel执行顺序PyTorch/CUDA Runtime控制模型权重是否量化、LoRA适配器何时加载vLLM EngineCore控制请求队列优先级、批处理窗口大小vLLM Scheduler控制我见过最典型的错误配置运维同学为了“提高GPU利用率”在K8s Deployment里把limits.nvidia.com/gpu设为1但requests设为0.5以为能实现GPU共享。结果vLLM启动直接报错CUDA_ERROR_INVALID_VALUE——因为vLLM要求独占GPU设备句柄它拿到的不是一个“半块GPU”的抽象资源而是一个/dev/nvidia0设备文件。K8s可以做设备共享如MIG但那是另一套机制和resource request/limit无关。注意K8s的nvidia.com/gpu资源单位是“块”不是“GB显存”或“TFLOPS算力”。你无法用requests: {memory: 16Gi}这种方式申请显存因为显存是vLLM运行时动态管理的。K8s只管设备所有权不管设备内部内存布局。2.3 实操中必须死守的三条红线节点标签必须与GPU拓扑强绑定不要只打gpu-typea100这种模糊标签。我们强制要求kubectl label node gpu-node-01 \ gpu.topology.nvlinktrue \ gpu.memory80Gi \ gpu.architectureampere \ hardware.healthfan-ok这样在Deployment里就能精准选择nodeSelector: gpu.topology.nvlink: true gpu.memory: 80Gi永远用requests limits对GPU资源requests ! limits没有意义。K8s不会给你“超卖”GPU因为设备不可压缩。设成requests: 1, limits: 2只会让调度器按2块GPU找节点浪费资源。健康检查必须穿透到GPU层默认的HTTP liveness probe只检查端口是否通但GPU可能已hang住。我们在probe里集成nvidia-smi -q -d MEMORY | grep Used如果显存使用率10分钟无变化就触发重启。这避免了vLLM进程活着但GPU卡死的“僵尸状态”。3. Ray 调度层计算任务的“车间排产”3.1 它决定的是任务与GPU的映射关系当K8s把vLLM Pod调度到某台GPU服务器后Ray才真正开始工作。但注意Ray在这里不是调度vLLM本身而是调度vLLM之上的分布式推理任务。典型场景是你用Ray Serve部署一个LLMModel类它内部封装了vLLM Engine然后通过serve.deployment(ray_actor_options{num_gpus: 2})声明需要2块GPU。此时Ray的Global Control PlaneGCS在做什么它在解决一个经典的作业车间调度问题Job Shop Scheduling工件Job每个推理请求含promptmax_tokens工序OperationPrefill阶段计算prompt KV、Decode阶段逐token生成机器Machine每块GPU注意是GPU不是节点Ray能感知到单节点多卡Ray Scheduler的核心决策是把哪个请求的哪个阶段分配给哪块GPU上的哪个Actor实例。它不关心vLLM内部怎么管理KV Cache但必须确保同一请求的Prefill和Decode必须在同一块GPU上完成否则KV Cache传输开销巨大多个请求的Prefill可以并行在不同GPU上利用GPU高吞吐特性当某块GPU显存不足时主动将新请求路由到其他GPU而非让vLLM自己OOM我们实测过在8卡A100节点上用Ray Serve vLLM部署Qwen2-72B当并发请求从50升到200时Ray的自动负载均衡能让各GPU显存占用方差8%而纯vLLM单实例K8s Service轮询方差高达42%——后者必然导致部分GPU OOM重启。3.2 它不决定的是GPU内核执行细节Ray对GPU的掌控止步于CUDA Context创建。它调用torch.cuda.set_device()指定GPU索引然后把请求数据传给vLLM Actor。之后发生的一切CUDA kernel如何launchvLLM的C backend控制Tensor Parallel通信用NCCL还是GLOOvLLM启动参数控制PagedAttention的block table如何构建vLLM Memory Manager控制请求排队策略FIFO vs priority queuevLLM Scheduler控制全部交给vLLM。Ray就像工厂厂长只管把订单分给哪个车间GPU但不进车间看工人CUDA kernel怎么拧螺丝。实操心得Ray的num_gpus参数必须与vLLM的tensor_parallel_size严格一致。比如你设num_gpus4但vLLM启动时--tensor-parallel-size2Ray会分配4块GPUvLLM却只用其中2块——另外2块GPU被闲置而K8s还认为它们已被占用造成资源黑洞。我们写了个pre-start hook脚本自动校验这两个值。3.3 Ray调度的三大实操陷阱Actor生命周期与GPU绑定的矛盾Ray Actor默认在创建时绑定GPU但vLLM Engine需要长时间warmup加载模型权重、编译kernel。如果Actor因OOM被Ray杀死重建warmup过程重来首请求延迟飙升。解决方案启用Ray的ray.util.placement_group将Actor与GPU资源永久绑定避免调度漂移。跨节点通信成为瓶颈当Ray把请求分到不同节点的GPU时vLLM的TP通信走的是TCP/IP比NVLink慢10倍。我们强制要求placement_group必须指定strategySTRICT_PACK确保所有TP分片在同一节点。命令如下pg placement_group([{CPU: 1, GPU: 1} for _ in range(4)], strategySTRICT_PACK)Ray Serve的HTTP代理层增加延迟Ray Serve默认用Starlette做HTTP server但它的async handler与vLLM的异步引擎存在协程竞争。我们实测发现在高并发下Serve的请求解析耗时占端到端延迟的18%。最终方案绕过Serve用ray.get_actor(vllm_engine).generate.remote()直连Actor延迟降低32%。4. vLLM 调度层请求级的“毫秒级交通管制”4.1 它决定的是GPU上每一毫秒的微观执行当请求到达vLLM EngineK8s和Ray的工作就结束了。真正的“调度战争”在此爆发。vLLM Scheduler不是传统意义上的调度器而是一个基于显存状态的实时决策引擎。它每10ms做一次决策核心输入只有三个当前所有待处理请求的prompt_len和max_tokens显存中已存在的KV Cache block table来自PagedAttentionGPU剩余显存torch.cuda.mem_get_info()它的输出是下一个时间片通常10-50ms内GPU应该执行Prefill还是Decode以及为哪个请求服务。这里有个反直觉的事实vLLM不保证FIFO。它采用Scheduling Policy可配置默认是fcfs先来先服务但生产环境我们强制用priority。为什么因为一个长prompt如10k token的Prefill会霸占GPU 200ms期间所有短请求如128 token都被阻塞。而priority策略会动态计算每个请求的“性价比”priority_score (remaining_tokens_to_generate) / (estimated_prefill_time_ms)这样一个只需生成10个token的客服问答请求可能比一个要生成1000个token的代码生成请求获得更高优先级从而保障SLO。提示vLLM的--scheduler-policy参数直接影响P99延迟。我们对比过fcfs下P991200mspriority下P99420ms同配置Qwen2-7B。4.2 它不决定的是宏观资源分配vLLM对以下事项完全无感这块GPU属于哪个K8s Node它只认CUDA_VISIBLE_DEVICESRay是否把其他Actor调度到同一GPU它假设独占模型权重是否在CPU内存它只管GPU显存所以当你看到vllm docker镜像中带模型吗这个问题答案很明确不带。Docker镜像只包含vLLM二进制和Python依赖模型权重必须挂载到容器内由vLLM启动时从磁盘加载。如果K8s PVC挂载失败vLLM报错FileNotFoundError这不是调度问题是存储配置问题。4.3 vLLM Scheduler的四大核心机制拆解4.3.1 PagedAttention内存管理显存的“页表”革命传统Attention需要连续显存存放KV Cache导致显存碎片化严重。vLLM引入类似CPU虚拟内存的PagedAttention将KV Cache切分为固定大小的block默认16x16 tokens每个block在显存中有独立地址通过block table索引请求的KV Cache可分散存储在非连续block中这使得显存利用率从传统方案的~35%提升至~82%。但代价是Scheduler必须维护block table的实时状态。我们遇到过最棘手的问题当--block-size16时一个32k token的prompt需要2048个blockblock table本身占显存12MB——这对小显存GPU如RTX 4060 Laptop GPU是致命负担。解决方案对小卡强制--block-size32牺牲少量利用率换取稳定性。4.3.2 Continuous Batching请求的“流水线组装”vLLM不等一个请求生成完所有token才处理下一个而是动态组装batchPrefill阶段将多个新请求的prompt合并成大batch一次性计算高吞吐Decode阶段将所有进行中的请求的“下一个token”合并成batch一起生成低延迟关键参数--max-num-batched-tokens决定最大batch size。设太小如256则Decode batch太小GPU利用率低设太大如8192则Prefill batch过大单次计算时间长阻塞新请求。我们通过线上监控vllm:gpu_cache_usage_ratio指标动态调整该值——当缓存使用率持续90%说明block不足需增大--block-size当60%说明batch太小需增大--max-num-batched-tokens。4.3.3 Speculative Decoding用小模型“猜”大模型的下一步这是vLLM 0.4版本的杀手锏。它启动一个轻量Draft Model如TinyLlama与主模型并行运行Draft Model快速生成k个候选token主模型验证这k个token的正确性若全部正确则一次生成k个token速度提升k倍但Scheduler必须协调两者的显存Draft Model需要额外GPU显存。我们部署时发现--draft-model参数若指向一个未量化的小模型它会吃掉主模型30%显存导致主模型OOM。最终方案Draft Model必须用AWQ量化且--draft-model路径必须指向量化后的GGUF文件。4.3.4 Chunked Prefill长文本的“分段预填充”对于超长prompt32k tokens传统Prefill会因显存不足失败。vLLM 0.5引入Chunked Prefill将prompt切成chunk逐段Prefill中间结果暂存CPU内存。但这带来新问题CPU-GPU数据搬运开销。我们实测发现当--enable-chunked-prefill开启时32k prompt的首token延迟增加40%。因此我们只对prompt_len 16384的请求启用该功能并配合--cpu-offload-gb 4预留足够CPU内存。5. 三层调度的协同故障排查实战5.1 典型故障链从K8s Pending到vLLM OOM的完整复现我们重现过一次经典故障完整链条如下现象vLLM服务突然503K8s Pod状态为CrashLoopBackOff日志显示CUDA out of memory排查步骤kubectl get pods→ 发现Pod在Pending状态10分钟后才启动说明K8s调度延迟kubectl describe pod→ 事件显示0/3 nodes are available: 3 Insufficient nvidia.com/gpu原因运维升级了NVIDIA驱动但忘记重启nvidia-device-pluginDaemonSetDevice Plugin未上报GPU资源K8s认为集群无GPU修复Device Plugin后Pod启动但1分钟后kubectl logs出现CUDA_ERROR_INVALID_VALUE原因新驱动版本535.129与旧版CUDA Toolkit11.8不兼容vLLM的C extension编译失败更新CUDA Toolkit后Pod运行但nvidia-smi显示GPU显存占用100%vllm:gpu_cache_usage_ratio1.0原因vLLM启动参数--block-size16而模型权重加载后block table膨胀挤占显存最终解决方案K8s层添加initContainer校验nvidia-smi -L和nvcc --versionRay层在Actor启动前执行torch.cuda.empty_cache()vLLM层动态计算--block-size公式为ceil(sqrt(model_params * 2 / 1024))单位MB注意这个故障链里每个环节的错误日志都藏在不同地方。K8s事件、Ray Dashboard、vLLM metrics三者必须打通。我们用Prometheus抓取container_gpu_memory_used_bytes{containervllm-server}当该指标突增到阈值自动触发kubectl exec进入Pod执行nvidia-smi -q -d MEMORY。5.2 性能瓶颈定位四象限法当用户抱怨“vLLM延迟高”不要直接调vLLM参数。先用四象限法定位维度K8s层指标Ray层指标vLLM层指标资源分配kube_pod_status_phase{phasePending} 0ray:actor_num_pending_tasks 100vllm:gpu_cache_usage_ratio 0.95通信开销node_network_receive_bytes_total{devicebond0}spikeray:object_store_memoryusage 90%vllm:all_reduce_time_msavg 50计算效率container_cpu_usage_seconds_totallowray:actor_worker_utilization 0.3vllm:prefill_time_msavg 2000IO瓶颈container_fs_usage_bytes 90%ray:object_store_disk_usage 80%vllm:model_load_time_s 120例如当vllm:prefill_time_ms高但ray:actor_worker_utilization低说明是vLLM Prefill计算瓶颈应调大--max-num-seqs若两者都高则是Ray Actor太少需增加num_replicas。5.3 生产环境必须监控的7个黄金指标我们放弃所有“锦上添花”的监控只保留这7个kube_pod_status_phase{phasePending}K8s调度卡顿ray:actor_num_pending_tasksRay任务积压vllm:gpu_cache_usage_ratio显存碎片化程度vllm:batch_size实际batch大小反映Continuous Batching效果vllm:time_per_output_token_ms单token生成耗时核心SLOcontainer_gpu_memory_used_bytesGPU显存绝对用量process_cpu_seconds_total{jobvllm}vLLM进程CPU占用过高说明Python GIL争用所有指标通过PrometheusGrafana可视化设置告警当vllm:time_per_output_token_ms 150持续2分钟企微自动告警并附带kubectl top pod和nvidia-smi快照。6. 架构选型决策树什么场景该用哪一层6.1 不该用Ray的三种情况单模型、低并发50 QPS此时vLLM单实例K8s HPA基于vllm:gpu_cache_usage_ratio扩缩容更简单。Ray的调度开销Actor序列化、GCS通信反而增加20ms延迟。模型需频繁热切换如AB测试Ray Actor一旦创建GPU Context就固定。切换模型需销毁重建Actorwarmup耗时长。此时用K8s StatefulSet vLLM的--model参数热加载更稳。GPU异构严重如混合A100RTX4090Ray的Placement Group难以精细控制不同GPU型号的分配策略。不如K8s用nodeSelector硬隔离A100节点跑大模型4090节点跑小模型。6.2 必须用K8s的刚性需求多租户隔离金融客户要求GPU资源物理隔离K8s的ResourceQuotaLimitRange是唯一合规方案混合负载集群同时跑训练PyTorch和推理vLLMK8s的PriorityClass可确保推理Pod抢占训练Pod的GPU灰度发布用K8scanaryrollout策略逐步将流量切到新vLLM版本比Ray Serve的traffic配置更可控6.3 vLLM不可替代的三大场景超长上下文128k tokensvLLM的PagedAttention是目前唯一支持百万级token KV Cache的开源方案。HuggingFace TGI在128k时OOMvLLM仍稳定。动态Batch Size客服场景请求长度方差极大10-5000 tokensvLLM的Continuous Batching能自动适配TGI的静态batch会严重浪费资源。LoRA热插拔我们为每个客户部署独立LoRAvLLM的--lora-dirs参数支持运行时加载无需重启。TGI需重新加载整个模型。7. 个人实操经验总结三年踩坑换来的五条铁律我在三个不同行业的AI平台落地过这套架构从0到支撑日均2亿次推理调用。这些不是文档里写的是凌晨三点debug时记下的血泪教训铁律一永远用K8s做GPU“准入控制”不用它做“精细调度”我们曾尝试用K8s的TopologySpreadConstraints强制vLLM Pod均匀分布到GPU节点结果发现当某节点GPU故障时K8s把所有Pod挤到剩余节点瞬间触发vLLM OOM。后来改为K8s只做基础调度用PrometheusAlertmanager检测GPU健康故障节点自动打unschedulable污点。铁律二Ray的num_gpus必须等于vLLM的tensor_parallel_size且必须是2的幂不是因为技术限制而是CUDA NCCL通信库的底层优化。我们试过num_gpus3TP3结果NCCL all-reduce性能下降40%因为NCCL对非2的幂通信拓扑做了降级处理。铁律三vLLM的--max-model-len必须比业务最大prompt长20%但不能超过GPU显存的50%这是显存安全边际。比如A100 80G--max-model-len32768则--block-size16时block table理论最大占用32768/16164131072 bytes约128KB完全安全。但如果设--max-model-len131072block table就吃掉512KB加上模型权重显存就危险了。铁律四永远在vLLM启动前执行nvidia-smi -r这是对付GPU stuck的终极手段。某些驱动bug会导致GPU Context hang住nvidia-smi显示GPU在用但torch.cuda.is_available()返回False。nvidia-smi -r硬重置比重启Pod快10倍。铁律五监控必须穿透到CUDA层面我们自研了一个cuda-profiler-exporter直接读取/proc/driver/nvidia/gpus/0000:00:00.0/information暴露gpu_utilization、memory_utilization、temperature。当温度85°C时自动降低vLLM的--max-num-batched-tokens宁可牺牲吞吐保稳定。最后说一句别被“调度”这个词迷惑。它不是技术炫技而是为业务兜底。当你看到unable to load site please try again later背后可能是K8s没等到GPU就超时也可能是vLLM的PagedAttention block table溢出。三层调度的本质是把一个不可靠的硬件世界变成可预测、可监控、可回滚的确定性服务。这需要你既懂K8s的YAML也懂CUDA的stream更懂业务的SLO——而这正是我们每天工作的全部意义。
