如果你同时跑过 Kubernetes 和 vLLM一定在部署日志里见过这样的组合K8s 把带 GPU 的 Pod 调度到某个节点vLLM 引擎在进程内部又做了一堆“scheduler”相关的初始化中间如果还插了 Ray那日志里还会多出 task pending、actor started 这类字样。三个系统都说自己在“调度”可它们调度的对象、时间尺度、资源维度完全不是一回事。这就像一个园区里同时有物业、班车调度台和生产排产系统物业管“哪栋楼分配给哪个部门”班车调度管“哪辆车去哪个站点拉人”排产系统管“每条产线当前加工哪个订单”。三个系统碰巧都叫“调度”但职责边界天差地别。Kubernetes、Ray、vLLM 也是这样——它们各自在解决不同层级、不同粒度的资源分配问题只是中文里恰好都翻译成了“调度”。这篇文章我会把三个系统的调度器剥开来看各自调度的单元是什么、资源视图是什么、决策频率有多快、失败代价有多大以及在你实际部署大模型时它们是如何在一个集群里协同工作的。如果你正在被“到底该用哪个调度器”“为什么三层都要配”这类问题困扰这篇文章应该能帮你把线索理清楚。1. 三个“调度”到底在抢什么先统一认知框架1.1 调度的本质是资源分配决策不管哪个系统的调度器核心都是一道决策题有一批等待执行的工作单元有一批可用的物理或逻辑资源调度器要决定“哪个单元放到哪个资源上什么时候放、放多久”。区别在于每个系统对“工作单元”和“资源”的定义完全不同。Kubernetes 的工作单元是 Pod资源是集群里的节点Node决策结果是 Pod 与 Node 的绑定关系。Ray 的工作单元是 Task 或 Actor资源是节点上的 CPU、GPU、内存配额决策结果是任务被发送到哪个 worker 进程执行。vLLM 的工作单元是用户请求对应的 token 序列资源是 GPU 显存里的 KV cache 池和一次前向传播的 batch 槽位决策结果是下一轮迭代里哪几条序列能被放进计算图。这三个层级不是替代关系而是层层嵌套的包含关系。一个 K8s Pod 里面可以跑一个 Ray 集群一个 Ray Actor 里面又可以启动一个 vLLM engine而 vLLM engine 内部的调度器又在以毫秒级的频率决定显存里的数百个请求谁先谁后。所以当你听到“Kubernetes、Ray、vLLM 都在调度”时正确的理解不是“它们竞争同一个资源池”而是“它们分别在上一层和下一层之间传递决策”。1.2 用一张表看清三者的差异我整理了对比表方便你对照理解三个调度器的本质差异维度KubernetesRayvLLM调度单元PodTask / Actortoken 序列Sequence资源视图节点CPU、内存、GPU 整数卡节点上的逻辑资源CPU、GPU、内存配额GPU 显存内的 KV cache 块、batch 槽位决策频率秒级一次 Pod 调度之后长时间不变毫秒到秒级随任务提交和完成动态变化毫秒级每个 forward iteration 都重新决策决策结果Pod 绑定到某个 Node任务被分发到某个 worker 进程这个 iteration 中哪些序列进入 prefill / decode失败代价调度错一次Pod 重建分钟级恢复调度错一次任务排队重试秒级恢复调度错一次显存 OOM 或 preemption 风暴影响所有并发请求关注的核心指标集群资源利用率、调度延迟、分布均衡任务完成时间、数据本地性、依赖就绪吞吐量、首 token 延迟、KV cache 命中率这张表基本回答了标题里的问题三个系统都在调度但 K8s 调度的是“进程放到哪台机器”Ray 调度的是“分布式计算任务放到哪些进程”vLLM 调度的是“GPU 内部的算力给哪些请求”。下面我逐个拆开讲结合实操中我踩过的坑。2. Kubernetes 调度它管的是“容器放哪台机器”2.1 Pod 到 Node调度单元和决策目标Kubernetes 的默认调度器是 kube-scheduler它做的是 Pod 与 Node 的绑定。调度过程分两阶段Filter过滤和 Score打分。Filter 阶段会把不满足条件的节点剔除比如节点资源不足、打了 taint、不满足 nodeAffinity、不满足持久卷要求Score 阶段在剩余节点里按优先级打分比如资源余量越多的节点分越高、spread 拓扑分布分越高最后选最高分的节点完成绑定。这台调度器在 AI 场景里经常被吐槽“太笨”因为它根本不理解 GPU 显存。K8s 对 GPU 的资源粒度只停留在“整数卡”比如 nvidia.com/gpu: 1。哪怕一张 A100 上已经塞了三个占 8GB 显存的进程只要没有到显存上限K8s 还能继续往这张卡上调 Pod。这就是为什么很多团队部署多个推理服务时明明节点还有“剩余 GPU 卡”配额Pod 启动后却直接爆显存。我见过的最常见做法是给 GPU 节点打上专用标签再用 nodeSelector 或 nodeAffinity 把推理类 Pod 固定到指定节点组避免和训练任务混部。另一个实用配置是给每个 GPU Pod 的 requests 写明确切需求的卡数和内存不要只写 limits否则调度器在 Filter 阶段只会按 requests 计算资源占用超卖了一旦多 Pod 落到同一张卡上运行时才报错浪费了调度时机。2.2 K8s 调度为什么是“秒级”且“不敏感”的关键要理解 K8s 调度的目标函数。一个 Pod 创建之后通常要运行几十分钟、几小时甚至几天所以调度器有充分的耐心做全局最优选择。它追求的是节点资源水位均衡、故障域分散、亲和性满足而不是单个请求的响应延迟。一个 Pod 被调度到次优节点影响的也只是这一份服务的启动位置不会导致单个线上请求变慢。这就意味着在纯在线推理场景里K8s 调度器距离“毫秒级请求调度”非常远。真正决定在线延迟的是后续的负载均衡器和 vLLM 内部的 batch 调度。K8s 调度器在推理链路里的角色更像“楼盘分配”先把房间分好至于房间里的人谁先坐下它完全不管。实操中还有一点容易被忽略Kubernetes 调度器是基于节点资源请求量requests而不是实际使用量来做决策的。如果某个 Pod 把 requests 写得很保守比如只申请 1 个 CPU 但实际跑满 8 核调度器会一直以为这个节点还很空闲持续往上面塞 Pod。对于大模型推理这种 CPU 占用低但显存暴力的负载建议 requests 要与实际规格对齐尤其在申请 GPU 整数卡时配足显存避免集群层面的资源视图失真。2.3 实操心得推理场景下 K8s 该配置什么我在实际部署 vLLM 推理服务时通常会在 K8s 里做这几件事给 GPU 节点打专用 taint比如 gpu-nodetrue:NoSchedule然后给推理 Pod 配上对应的 toleration保证只有需要 GPU 的服务会落到这些节点。在部署清单里同时写清 requests 和 limitsGPU 配额为整数卡内存按模型显存占用估算避免超卖。用 PodTopologySpreadConstraints 限制同服务的多个副本不要被塞到同一个节点上降低单节点故障时的影响面。给关键推理服务设置 priorityClass让它可以在资源紧张的节点上抢占低优先级任务的资源。下面是常见的 vLLM Deployment 片段你可以参考apiVersion: apps/v1 kind: Deployment metadata: name: vllm-llama spec: replicas: 2 template: spec: tolerations: - key: gpu-node operator: Exists effect: NoSchedule topologySpreadConstraints: - maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: DoNotSchedule containers: - name: vllm image: vllm/vllm-openai:latest resources: requests: nvidia.com/gpu: 1 memory: 32Gi limits: nvidia.com/gpu: 1 memory: 32GiK8s 这层调度器不是性能瓶颈但它决定了下层一切运行的物理边界。如果你在这里没把节点分组和资源配额规划好后面 Ray 和 vLLM 再智能也补不回来。这也是我反复跟团队强调的K8s 调度首先要对“这台机器上能跑什么”负责而不是对“跑得快不快”负责。3. Ray 调度它管的是“分布式任务怎么拆”3.1 Task 与 Actor更细粒度的调度单元Ray 的调度单元比 K8s 小一个层级。K8s 调度的是整个容器进程而 Ray 调度的是进程内的分布式计算单元。你在 Ray 里定义了一个远程函数或一个 ActorRay 会把它放到集群中的某个 worker 进程上执行。这个 worker 进程可能直接就是一个 K8s Pod所以 Ray 天然可以跑在 K8s 之上。Ray 的调度决策基于资源需求声明比如ray.remote(num_gpus1)表示这个任务需要 1 张 GPUray.remote(num_cpus4, memory8 * 1024 * 1024 * 1024)表示需要 4 核 CPU 和 8GB 内存。调度器在发布任务时会根据当前各节点的可用资源把任务推送到合适节点。核心组件包括 GCS全局控制存储保存集群元数据与资源状态每个节点上的 Raylet 负责本节点资源管理与任务执行。Ray 调度的强大之处在于依赖感知。你可以构建一个有向无环图前一个任务产出的对象直接作为后一个任务的输入Ray 会尽量把后一个任务调度到持有前一个任务产出对象的节点上减少跨节点数据传输。这个特性在大模型数据处理、RLHF 的经验收集场景里非常实用——策略模型训练完采样任务和奖励模型评估任务能在数据本地快速接力而不是每个都跨机器拉对象。3.2 负载感知与延迟调度很多人误以为 Ray 就是粗暴的“先到先得谁有空跑谁”实际上它有一套负载感知和延迟调度策略。当提交一个任务时Ray 会优先看本地节点的可用资源如果本地资源不足再考虑是否等待或远程推送。对于一组需要打包放置的任务可以用 placement group 明确要求是 PACK尽可能紧凑放在同一节点还是 SPREAD尽量分散到不同节点。这里有个我在实际项目中踩过的坑把需要两张 GPU 的任务写进同一个 placement group 时如果用了 PACK 策略但节点上只有两张卡的空闲资源调度器可能会把两个任务卡在 PENDING 状态等资源。而如果你用的是 SPREADRay 又可能把任务分别放到两台各有一张空闲 GPU 的节点上导致张量并行通信跨节点变得很慢。正确做法是先明确你的并行模式张量并行强烈建议 PACK 到同一节点数据并行则无所谓。Ray 调度对 GPU 的感知也是“整数资源视图”的它不感知显存大小。这个问题和 K8s 一样如果一个节点声明了 4 张 GPURay 会认为它有 4 个 GPU 额度不会管每张卡显存是否已经满了。所以当你在同一台物理机上同时跑多个 Ray 任务时必须靠外层 K8s 的 Pod 资源限制来兜底否则两个num_gpus1的 Actor 可以被 Ray 愉快地调度到同一张卡上然后一个 OOM 把整个节点带走。3.3 Ray 和 K8s 的重叠与边界由于 Ray 本身可以在 K8s 上以 operator 方式部署这两层的边界常常被搞混。我给你的判断标准是K8s 管“进程的生死”Ray 管“进程内的任务分配”。假设你有一个 Ray 集群跑在 K8s 上K8s 负责创建 Ray head Pod 和 worker Pod当某个 worker Pod 被杀掉重启Ray 会自动感知到节点失联并把分配给它的任务重新调度到其他存活节点。这就是两层各自发挥作用的典型场景。反过来Ray 的无状态 Actor 调度又在一定程度上“抢了” K8s 的活。在纯 Ray 集群里你不写任何 K8s Deployment 也能跑分布式训练。所以很多训练团队会直接用 Ray cluster 而不上 K8s但在生产环境里K8s 提供的滚动更新、节点故障自愈、统一日志采集仍然更有优势。我的经验是需要长时间稳定运行、需要对接公司统一发布体系的就让 K8s 管 Pod需要动态拆任务的让 Ray 管 Task。再补充一个实际经验不要把 Ray 的资源和 K8s 的资源请求割裂配置。比如 K8s Pod 申请了 1 个 GPURay 里又声明num_gpus0一旦两个这种 Pod 被放在同一张卡上Ray 的任务就会全部挤在一块物理卡上跑性能直接受影响。我通常会让 Pod 的 GPU 命名空间和 Ray 的 GPU 资源保持一致确保 Ray 认为的资源视图与物理分配一致。4. vLLM 调度它管的是“显存里的词元给谁算”4.1 从 Batch 到 Continuous BatchingvLLM 的调度器是我认为三者中最值得细看的因为它把“调度”做到了 token 级别。传统的批处理推理是静态的攒满一个 batch全部请求做完再进下一批。静态 batch 的最大问题是 batch 内所有请求必须一起结束短的请求会卡在长的请求后面GPU 利用率波动很大。vLLM 采用的是 continuous batching也叫 iteration-level scheduling。调度器不再按“请求批次”做决策而是按“模型迭代”做决策。每一轮 forward pass 结束时调度器重新决定下一轮哪些序列继续算。一个请求就算只生成一个 token 也可能立刻退出批次新请求可以随时插入。这样 GPU 永远在处理“当前最合适的 token”而不是等整个 batch 结束。我习惯用公交车的例子解释静态 batch 是包车必须等所有人下车才接下一批乘客continuous batching 是公交站点车一直在跑到站有人下就有人上。所以 vLLM 这种调度模式下即使同时有几百个请求在排队只要显存里有地方放新序列的 KV cache新请求就能快速开始 prefill。4.2 KV Cache 池与序列槽位vLLM 的核心数据结构是 PagedAttention 管理的 KV cache 块池。调度器管理的是这些显存块怎么分配给不同的序列。放到工程层面每个请求进入 vLLM 时prompt 会被切分成 token 序列每生成一个新 tokenKV cache 就要多存一组键值向量。如果 KV cache 满新请求无法获得足够块就必须等待已经完成的序列释放资源或者触发 preemption 把部分序列的 KV cache 换出到 CPU 内存。所以 vLLM 调度器的本质是一个“显存槽位分配器”。它在一轮迭代中决定三条路让处于 running 状态的序列继续 decode、让等待中的序列开始 prefill、让排队中的序列继续等待。这些决策直接影响 GPU 有效计算时间占比。如果调度得太激进把 KV cache 全部分给长序列新请求的 prefill 延后会非常严重如果太保守可能 GPU 每轮只算很少的序列吞吐量上不去。实际操作中我一般会先看模型规模估算 KV cache 空间再调整gpu_memory_utilization默认 0.9和max_num_seqs。max_num_seqs限制了同一轮最多并行的序列数它是一个调度器用来约束 batch 规模的关键旋钮。如果你发现延迟稳定但吞吐上不去优先检查是不是这个值太小如果你发现 preemption 频繁就要考虑调低并发度或增大 KV cache 预留。4.3 vLLM 调度器和执行器的交互流程从源码角度看vLLM 里 Scheduler 和 Executor 的交互是理解整条链路的关键。LLMEngine 每轮迭代会经历一个三元组流程schedule - execute - update。schedule调度器拿到所有未完成的序列根据状态分为 RUNNING、SWAPPED、WAITING再结合显存可用块、max_num_seqs、preemption 策略决定本轮要执行的序列和各自的 token 数量。execute执行器拿到调度结果把选中的 token IDs 打包成 tensor喂给模型做 forward pass。update模型输出完成后更新每个序列的状态把新生成的 token 追加到序列尾部并标记哪些序列已完成、哪些需要被抢占。在这个流程里调度器相当于“项目经理”决定哪些活本轮开工执行器相当于“施工队”只负责把开工的活干完。施工队从来不拍板干哪条活但调度器拍板时又必须考虑施工队手里的显存和算力。这种解耦的好处是调度策略和底层执行可以分别调整——比如你可以换更激进的抢占策略或者换更强的执行内核而两边的接口基本稳定。我实际排查过这样一个案例模型加载正常但服务延迟时不时突然飙高。看日志发现每次飙高前都有 vLLM 的 scheduler 在做 preemption把一段序列的 KV cache 换出到 CPU再换入另一段。本质上就是调度器的 preemption 策略在显存紧张时频繁生效导致额外的显存拷贝开销。最后我通过调低max_num_seqs、提高gpu_memory_utilization给 KV cache 多一点空间问题就消失了。4.4 vLLM 调度为什么“这么紧急”vLLM 的调度器是三者的时间尺度最紧张的一个。K8s 的调度可以在秒级完成Ray 的任务分配能在毫秒到秒级完成而 vLLM 的调度发生在每一次模型迭代之间间隔大约只有几十到几百毫秒甚至更短。也就是说调度器必须在一次 forward pass 返回的空档里完成所有序列状态的更新和下一轮序列的挑选绝不能阻塞计算流水线。这也是为什么 vLLM 的调度器不是外挂而是嵌在引擎内部、与模型推理紧耦合的组件。任何外部系统都无法做到这么高频的决策因为外部调度器根本没有 GPU 显存布局的实时视图。K8s 和 Ray 只能把“决策权”下放到进程内部由 vLLM 自己来管理 GPU 上的请求切分。从产品定位来看如果一个请求到达 vLLM 服务时发生排队这通常不是 K8s 或 Ray 的调度问题而是 vLLM 内部调度器面对大量请求时做的取舍——它要平衡首 token 延时、吞吐和显存压力。你通过日志看到的Waiting: 120 Running: 32其实就是调度器当前的真实队列状态。5. 三层协同一次大模型部署里到底谁干了什么5.1 一次完整的链路拆解假设你在生产环境跑一个多机 vLLM 推理服务组件齐全请求路径大致是这样的第一阶段K8s 调度器先把 vLLM 的 Deployment 副本调度到集群里带 GPU 的节点上为每个副本创建一个 Pod并挂载模型存储、暴露 service。此时 K8s 的任务已经完成它不再参与单个请求的路径。第二阶段如果你在同一个集群里跑 Ray 来处理请求的前置逻辑比如数据预处理、RAG 检索、多模型路由Ray 会把每个预处理任务分发到 CPU worker 上。在这个阶段K8s 继续负责 Ray worker Pod 的生命周期Ray 负责 worker 内部的任务切分。第三阶段当预处理完成、请求真正到达 vLLM engine 时vLLM 的调度器在 GPU 显存里给每个请求分配 KV cache 块决定当前迭代哪些序列进入 prefill、哪些继续 decode、哪些降级等待。这一层直接决定线上延迟和吞吐。第四阶段如果某个 GPU 节点宕机K8s 首先感知到 Node NotReady然后自动在其他节点上重建 Pod如果 Pod 内跑的是 Ray workerRay 会把该 worker 上未完成的任务转移到存活节点重新执行。这就是三层调度器在故障场景下的协作方式。从这四阶段能看出一个清晰的规律离实际计算越近的调度器时间尺度越短、决策越精细、对性能影响越直接。K8s 管最外层Ray 管中间层vLLM 管最内层任何一层配置不当都可能影响整条链路的稳定性。5.2 场景矩阵不同场景用谁做主调度为了帮你快速决策我把不同场景下的主调度器选择整理成了下表场景主调度器原因单机多卡 vLLM 在线推理vLLM K8sK8s 负责进程放置vLLM 负责请求级调度Ray 在这一层基本不参与多机多卡张量并行推理K8s RayRay 负责把多个 worker 调度到不同节点并建立拓扑连接vLLM 在各 worker 内部处理请求离线批量推理大量样本打分Ray vLLMRay 负责样本切分和分布式执行vLLM 负责在每个 worker 内部做连续批处理RLHF 训练Ray收集样本、启动 rollout worker、训练 worker 之间的调度完全由 Ray 承担在线高并发服务K8s vLLMK8s 做 HPA 弹性伸缩vLLM 做显存级请求调度引入 Ray 反而增加链路复杂度这张表说明了一个现实不是所有场景都需要三层调度器叠加。很多时候我们以为要用 Ray其实 vLLM 自己已经处理了请求层面的并发反过来你以为 K8s 能解决弹性伸缩但如果副本内没有 vLLM 这种内部调度器单纯扩容 Pod 并不能缓解单实例内的排队压力。5.3 边界划分的通用原则我在团队里总结过几条边界划分原则方便在各种项目中复用请求进入进程后所有调度决策都应当由进程内部组件负责外部调度器只负责进程间的资源分配。如果你的资源单位是“进程”或“Pod”用 K8s如果你的资源单位是“函数”“Actor”“任务”用 Ray如果你的资源单位是“token”“序列”“KV cache 块”用 vLLM。调度器的时间尺度要匹配业务对决策的要求。K8s 不该成为请求路径上的决策点vLLM 也不该去管节点水位均衡。尽量避免用外部系统去模拟内部调度器做不了的事。比如很多团队想在 K8s 层做请求级智能路由结果发现还是需要在接入层做特定逻辑反而绕了一个大圈。这些原则看似简单但实际项目里经常被突破。最常见的原因是企业刚好买了某个平台于是想把所有调度都塞到那个平台里最后面对性能问题只能靠加机器硬扛。6. 常见误区与排查实录6.1 高频典型问题速查症状真正原因排查方向多个 vLLM Pod 被调度到同一张 GPU 卡启动后显存 OOMK8s 的 GPU 资源粒度只有整数卡不感知显存检查节点标签和 requests 配置避免超卖必要时用 device plugin 或显存感知调度器Ray 任务一直 PENDING日志里没有报错Ray 等待的资源如 GPU、placement group 策略不可用用ray status查看资源总量用ray summary tasks看任务状态检查是否设置了不匹配的 PACK/SPREADvLLM 请求排队明显但 GPU 利用率不高调度器保守max_num_seqs或 KV cache 容量限制过小调大 max_num_seqs同时观察是否触发 preemption观察 gpu_memory_utilization 与 KV cache 命中率vLLM 延迟突然飙高周期性出现尖峰preemption 频繁KV cache 换入换出看 preemption count 指标调低并发或调大 KV cache 预留容器日志显示 GPU 找不到但节点明明有卡K8s 把 Pod 调度到了没有 GPU 的节点或 device plugin 未生效检查 nodeSelector / taint / toleration确认 nvidia-device-plugin 处于 Running 状态Ray 和 K8s 都声明了 GPU但 Ray 任务全部挤在同一张卡Pod 资源请求与 Ray 资源声明不一致导致 Ray 的 GPU 视图失真让 Pod 的 limits 与 Ray 的 num_gpus 保持一致用ray status验证每个节点 GPU 数这些是我在实际环境和线上事故中遇到过的组合能覆盖绝大多数调度类问题的排查起点。6.2 排查逻辑梳理遇到跨层调度问题时最忌讳一上来就改配置。我推荐按“物理层 - 进程层 - 请求层”的顺序排查先看物理层节点上有没有 GPU、显存还有多少、驱动是否正常、K8s 是否能识别 GPU 数量。这一层可以用kubectl describe node来确认节点上的资源列表同时用nvidia-smi看实际显存占用。再看进程层如果进程没起来或起了就崩大概率是 K8s 调度或 Ray 资源声明的问题如果进程起来了但任务等待就看 Ray 的任务状态和资源分配如果进程内有报错比如 CUDA OOM要回到物理层看是不是有多进程共享了同一张卡。最后看请求层如果进程正常、模型加载成功但服务延迟和吞吐不达标就要进 vLLM 的 metrics 和日志看 running 序列数、等待序列数、preemption 次数。这一层的信息在 K8s 和 Ray 里都看不到只能从 vLLM 内部捞。三层排查下来一般能在半小时内定位到问题层级再针对该层做优化。如果直接从最内层开始调参往往治标不治本比如你把它调好了但外层 K8s 把两副本放一起事故又复现了。6.3 关于“谁更重要”的一点思考经常有人问这三个调度器哪个最重要。我的答案是没有绝对的最重要但在线推理场景里vLLM 调度器的配置权重最高因为只有它直接决定每一个请求的 GPU 执行顺序。K8s 调度配置错了影响的是部署层面进程起来了还能救Ray 调度配置错了影响的是任务分布重试能兜底vLLM 调度配置错了直接影响线上每一个 token 的生成速度问题暴露最直观。按照我自己的经验设计大模型推理系统时应该先把 vLLM 这层做对再做 Ray 的任务拆分最后交给 K8s 做资源兜底。这个顺序和在纸上画架构图相反——画图是从底层往上画排查和调优则是从最靠近请求的那层开始。三层调度器同时跑在一个集群里并不冲突只要你清楚每一层在调度什么。K8s 决定进程放哪里Ray 决定任务跑哪里vLLM 决定 GPU 里的 token 给谁算。下一次再看到三个系统的日志混在一起时你就能快速分辨哪一层的决策在起作用哪一层的配置需要动手调整。