大模型部署越来越复杂之后很多团队会遇到一个共同的困惑底层有Kubernetes在调度Pod中间层可能跑着Ray在调度任务到了模型服务层面vLLM自己还带了一套scheduler。三套调度器叠在一起表面上都是“调度”但很多人搞不清楚它们到底各自决定什么、分界线在哪里、出了问题该查哪一层。这篇文章我就围绕“Kubernetes、Ray、vLLM都在调度”这个现象把三者的职责边界、底层逻辑、协同方式讲透。适合正在做推理服务部署、训练平台建设、或者想把大模型任务从“能跑”变成“跑得稳”的工程师参考。1. 三种调度器三个不同的关注维度1.1 一句话先记住三者的差异想理解这套体系第一件事是把“调度”这个词拆开。Kubernetes、Ray、vLLM虽然都叫scheduler但它们调度的对象完全不是一个层级的东西Kubernetes调度的是Pod它只关心一个容器组该放到哪台物理节点上运行以及节点的CPU、内存、GPU有没有余量。Ray调度的是Task和Actor它关心的是一个分布式计算任务该分配到哪个Worker进程上执行数据依赖怎么传递哪些任务可以并行。vLLM调度的是Request请求/序列它关心的是在GPU显存容量有限的情况下一批并发请求里先算哪些、谁被抢占、谁被排队。打个比方Kubernetes像一个酒店前台只负责把客人分配到有空房的楼层Ray像酒店里的会议调度决定哪场会议用哪个会议室、需要哪些设备vLLM则像是餐厅的取餐叫号系统排队的人这么多先做哪一桌的菜、锅不够用时先暂停谁的订单。三个调度器各有各的“资源账本”各管各的决定。没有谁替代谁的问题只有合不合作的问题。1.2 为什么大模型时代调度问题变得复杂早年间做普通Web服务一个Deployment加一个Service就够用了Kubernetes自带的调度器几乎不需要关心。但大模型服务不一样它有三个特点直接把调度复杂度拉满了第一GPU是昂贵且异构的资源。一张A100和一张L20的算力、显存都不一样Kubernetes只认“显卡个数”不认“显卡性能”这就导致调度必须引入更多语义。第二大模型任务不再是单一的Pod。一个完整的LLM服务往往包含数据预处理、模型加载、推理服务、评估任务有的环节还需要分布式执行。这些任务之间的依赖关系、并行关系Kubernetes原生模型很难描述清楚。第三推理服务本身有动态的显存压力和并发调度需求。请求是大量涌入的有些请求上下文很长有些很短。如果由Kubernetes来管这种秒级甚至毫秒级的请求分配Pod级别的调度粒度完全不够用。所以最终局面就是Kubernetes管“跑服务的机器”Ray管“分布式任务的组织”vLLM管“模型进程内部的GPU显存和请求分配”。这也是大模型架构里最典型的三层调度体系。2. Kubernetes 调度决定大模型跑在哪台机器上2.1 K8s调度的核心逻辑从Pending到BindingKubernetes的调度器kube-scheduler做的事情严格来说是“为一个待调度的Pod找到最合适的Node”。整个流程从它Watch到新建的Pod开始经历四个阶段第一是预选Filtering。调度器会先过滤掉不满足硬性条件的节点。比如GPU数量不够、CPU不足、端口冲突、节点被打了污点Taint。经过这一步剩下的节点都是“能放”的。第二是打分Scoring。在能放的节点里按各种优先级策略打分比如资源余量大的分高、尽量分散分布的分高、满足亲和性的分高。得分最高的节点就是“最适合的”。第三是绑定Binding。写入Pod的NodeName字段然后kubelet真正去把容器拉起来。第四是抢占Preemption。如果一个高优先级的Pod进不来调度器可能把低优先级Pod挤掉腾出资源来。说白了Kubernetes调度器做决定时输入是“Pod的资源需求和集群各节点的剩余资源”输出是“Pod应该去哪个节点”。我在实际部署vLLM服务时最常用到的Kubernetes调度配置就几个resources.requests和resources.limits声明GPU、CPU、内存nodeSelector或nodeAffinity指定GPU机型tolerations允许Pod调度到有特殊污点的GPU节点。尤其要注意的是GPU资源在Kubernetes里并不是CPU和内存那样的“数值型资源”而是通过设备插件Device Plugin上报的Extended Resource必须配合nvidia.com/gpu这个资源名来用。2.2 GPU工作负载下K8s调度必须改的默认习惯Kubernetes默认的调度策略是“资源最优”优先往空闲节点塞。这在CPU密集型服务里没问题但在GPU集群里容易踩两个坑。第一个坑是不感知GPU拓扑。一张8卡机器上每张卡之间的NVLink带宽不一样4张卡和8张卡之间还有不同的拓扑距离。Kubernetes原生调度不管这些它只保证“你要2张卡我就给你2张卡”至于这2张卡离得近不近它不关心。如果跑的是张量并行Tensor Parallelism的模型卡间通信频率极高跨了PCIe Switch和NVLink的通信时延能差好几倍。这个问题一般是靠插件解决的比如NVIDIA的GPU Topology插件或者直接用Node Affinity把Pod固定到特定的卡组。第二个坑是binpacking与散列分配的矛盾。Kubernetes默认偏向资源余量最少的节点binpacking这对省钱是好事但对推理服务未必好——所有Pod挤在一个节点上一旦节点故障全部挂掉。我的做法是部署服务时显式加podAntiAffinity让同一服务的多个副本错开节点调度用一个小代价换取可用性。另外Kubernetes调度还有对GPU资源request和limit不匹配的坑。容器里如果只写limits: nvidia.com/gpu: 1而不写requests部分版本的调度逻辑会把requests补成和limits一样反之如果你只写requestslimit没写那调度器认为你只用了0反而可能把一个Pod调度到GPU已经满载的节点上。这种细节在排查“Pod能起来但报CUDA OOM”的时候特别容易让人懵。2.3 实际部署vLLM时K8s的常见配合点用Kubernetes部署vLLM推理服务经典的组合是一个Deployment加一个Service加HPA水平自动扩缩再配合一个持久化卷做模型缓存。模型权重文件一般有十几GB甚至上百GB每次新Pod启动都重新下模型很浪费。我通常的做法是挂一个PVC作为模型缓存目录Pod启动时先检查快照是否存在存在就直接加载不存在才从对象存储下载。这样做的收益非常大实测能省掉80%以上的扩容等待时间。HPA的指标也很有讲究。vLLM暴露了Prometheus指标可以用vllm:num_requests_running或者gpu_memory_used_bytes来做HPA的触发指标而不是用默认的CPU使用率——CPU使用率在GPU推理场景里基本没有参考价值因为瓶颈在显存在算力不在CPU。在实际排查“Pod起来了但一直Pending”时多数原因就是Kubernetes调度器找不到满足条件的节点。要么是GPU资源不够要么是nodeSelector写的标签和节点不匹配要么是GPU节点的污点没有被容忍。有一个排查技巧kubectl describe pod直接看Events里的SchedulerError信息里面会直接写明是“0/2 nodes available”还是“node(s) didnt match node selector”。3. Ray 调度决定分布式计算任务给哪个Worker3.1 Ray的核心抽象Task、Actor和对象存储如果说Kubernetes调度的最小单位是Pod那Ray调度的最小单位是Task。Ray把分布式计算抽象成两类执行单元一类是无状态的Task像是“对这批数据执行一次预处理”的函数执行完就释放一类是有状态的Actor类似一个常驻的服务进程可以反复接收调用适合承载模型推理、训练循环之类的场景。除了执行单元Ray还有一个底层的东西是Object Store对象存储。Ray的调度器在做调度决策时不只是看CPU、GPU够不够还要考虑数据本地性——任务要处理的数据在哪个节点上。如果数据在节点A的对象存储里节点B上有空闲CPU调度器会更倾向于把任务发到节点A因为这样可以省掉跨节点的数据传输时间。实际使用中Ray调度器会为每个任务计算一个“打分”这个分数结合了资源可用性、数据本地性和节点的当前负载。它不像Kubernetes那样做严格的过滤再打分而是像快递分拣员每个包裹来了看看哪个分拣口最顺路就丢过去追求的是整体吞吐而不是完美均匀。3.2 Ray调度策略与资源感知Ray调度的核心资源模型包括CPU、GPU、内存和自定义资源。我们可以在ray.init或者ray.remote(num_gpus1)里显式声明某个任务需要几张显卡、几个CPU核心。Ray的调度器会参考每个节点的可用资源来分配。这里有个很关键的参数叫placement group。在大模型训练里我们需要同时启动多个Worker而且这些Worker最好分布在同一个节点组内、保证网络互通。用Placement Group可以一次性预留一批资源比如一个PACK策略会把所有任务尽量打包进同一个节点SPREAD策略则会尽量分散这样就能灵活控制“模型并行该聚集就聚集数据并行该分散就分散”。Ray还有一个经常被忽略的调度特性是溢出调度Spillback Scheduling。当本节点的资源不够时任务会溢出到其他节点这会让调度器面临一个决策——是把任务发到一个“资源够但数据要跨节点拉取”的远程节点还是在本节点排长队等资源释放。默认情况下Ray比较激进倾向于溢出去但这对数据密集型任务来说可能导致大量数据在网络中搬运反而比等一等更慢。遇到这类问题时我一般通过RAY_SCHEDULER_JOIN_THRESHOLD环境变量调节让调度器在决定溢出前多等一段时间增加数据本地性。实话说这个参数的调优比较依赖具体场景没有固定的最佳值需要多做几轮实验。3.3 大模型场景下拉长Ray的原因很多做推理服务的团队会问一个问题我直接用Kubernetes加vLLM不引入Ray行不行答案是纯在线推理服务可以不用Ray但如果你的业务还涉及离线批量推理、训练数据预处理、模型评估、甚至RLHF的多个阶段Ray就很值得引入了。Ray最适合承接的是“多阶段、有依赖、需要并行执行的计算流水线”。比如要做一周的行业数据批量推理Kubernetes只能管“起N个Pod”而Pod之间谁先谁后、失败重试、中间结果缓存这种逻辑Kubernetes原生是不管的。Ray的DAG任务图可以很自然地描述“先处理数据A再并行推理A和B最后汇总结果”这一整条流水线。以一个在线服务离线任务的混合场景为例在线推理请求走vLLM离线批量任务由Ray调度到空闲GPU上。用Ray的Autoscaler可以在资源不够时自动向Kubernetes申请新节点空闲时再释放。这样Kubernetes和Ray就形成了“上下级”协作——Ray负责“我要多少资源”Kubernetes负责“帮你把这批资源以Pod的形式拉起来”。4. vLLM 调度决定同一批GPU显存里先跑哪些请求4.1 vLLM为什么需要自己的调度器很多人不理解请求发到vLLM之后为什么不直接用GPU一个一个按顺序算还需要什么调度核心原因是GPU显存有限而LLM推理的显存占用是动态的。传统推理框架在显存中为每个请求预分配固定大小的KV Cache空间比如一个请求最长支持2048个token就预分配最坏情况下的显存。这样一来实际只有几十个token的短请求也会占用大量预留空间GPU显存根本容不下太多并发。vLLM引入了PagedAttention技术把KV Cache按固定大小的块Block来管理类似于操作系统中的虚拟内存分页。每个请求占用的显存是动态伸缩的生成了新的token就申请新的block不生成就不占用。这就让同一块GPU显存同时服务的请求数量大幅提升。有虚拟内存式的显存管理就需要有“页面置换”和调度策略——这就是vLLM内嵌SchedulerEngine存在的原因。它做的事情是在每步解码前从等待队列、运行队列、交换队列中挑选一批请求把它们需要的KV Cache block加载到GPU显存中让Transformer引擎执行一次前向计算。我记得第一次看vLLM源码时印象最深的就是Scheduler和LLMEngine的交互流程LLMEngine的step()方法每轮调用scheduler.schedule()调度器返回SchedulerOutputs里面包含本轮要执行的seq_group列表然后才交给executor去实际的GPU上跑。整个流程非常清晰——先由调度器“选人”再由执行器“干活”。4.2 vLLM scheduler的关键数据结构与决策逻辑vLLM的Scheduler内部维护了几个关键队列理解这几个队列就理解了它的调度逻辑Waiting队列存放刚接收的请求还没分配到任何block。新请求来了先在这里排队。Running队列正在执行解码的序列。每轮迭代都会被调度器选中执行一次前向计算。Swapped队列运行中被抢占的序列它们的KV Cache被暂时换出到CPU内存等待合适的时机再换回GPU。调度器每步做的事就是从这个三个队列中做决策。首先要判断有没有足够的物理block来容纳一个新请求。如果物理block不足就需要考虑抢占——把Running队列里优先级较低的请求换到Swapped队列腾出block给新的高优请求。vLLM默认采用的是先来先服务优先级抢占的混合策略。采样参数里可以配置policy为fcfs或者priority。在用priority策略时每个请求可以带一个priority值调度器会优先保证高优先级请求的执行。在实际推理过程中最影响体验的调度行为是抢占Preemption。vLLM默认使用的是RECOMPUTE模式即被抢占的请求直接丢弃KV Cache等资源恢复后重新计算而SWAP模式则是把KV Cache搬到CPU等GPU有空再搬回来。SWAP模式能在一定程度上避免重新计算的浪费但CPU到GPU的PCIe带宽往往成为瓶颈实测中经常比重新计算还慢。对大多数场景我的建议是保持默认的RECOMPUTE。4.3 参数如何影响调度结果vLLM的调度行为直接受几个启动参数影响这几个参数是所有部署vLLM的人都绕不开的--max-num-seqs限制的是同一个迭代步里最多有多少个序列同时被处理。设得越大吞吐量越高但也意味着显存压力更大每个请求的延迟会被拉高。默认256如果你追求低延迟可以调到64或者32。--max-num-batched-tokens限制的是每个迭代步最多处理多少token。它和max-num-seqs配合起来决定了每步前向计算的规模。如果模型是性能不太强的GPU建议把这个数调低否则单步耗时过长整体TTFT首token延迟会很难看。--gpu-memory-utilization控制vLLM使用多少比例的GPU显存来做KV Cache默认值是0.9。如果这个值设置得过高能容纳的KV Cache block就多并发能力更强但留给模型权重和前向计算的空间就少了如果过低最大并发就会受限。用一个小场景说明调度差异部署DeepSeek这类长上下文的模型时长请求会消耗大量block可能一个请求就把几百个block吃掉了。这时如果max-num-seqs还保持默认值调度器可能会因为物理block不足而不断发生抢占导致服务吞吐量暴跌。处理办法是把长上下文请求拆成短请求、提高max-num-seqs、或者增加max-model-len让模型不拒绝长请求但调度上做文章。这种“调度参数联动”的问题是调优vLLM时最有意思也最磨人的地方。4.4 vLLM调度与Ray/K8s的协作分工放到整个系统里看vLLM的调度器管的是一个模型实例内部的请求调度它不知道外面有几台机器也不知道哪个节点GPU更空闲。而Kubernetes和Ray管的是实例该放在哪里、实例副本该有多少个。所以一个常见的谬误是——我只要把max-num-seqs调大就能提高单实例吞吐。没错但如果你已经在Kubernetes上部署了多个vLLM副本这种调整可能不如让Kubernetes再多拉一个副本来得有效。原因很简单vLLM的调度是单机、单实例内的每个实例各自维护自己的Waiting队列不共享。多个副本之间的负载均衡是靠上游负载均衡器做的。分层去看这套调度体系会得到一个很有价值的结论Kubernetes负责的“调度”是分钟级的资源布局vLLM负责的“调度”是毫秒级的请求分配而Ray处于两者之间负责任务级编排。三层各管各的时间尺度出了问题先看症状落在哪一层这是排查问题的核心方法论。5. 三层调度协同以DeepSeek R1部署为例5.1 一个端到端调度流程假设我们的目标是部署一个DeepSeek R1的70B量化模型推理服务架构是Kubernetes Ray vLLM。用户请求从进入到生成第一个token整个流程是这样的第一步外部请求到达网关比如Nginx或API Gateway网关根据负载均衡策略把请求转发到某个vLLM Pod的Service入口。这一步的“分配”是网关做的不涉及任何调度器。第二步Kubernetes层面在做的事是确保“vLLM的Pod副本数是匹配当前负载的”。如果负载升高HPA触发扩容Kubernetes调度器创建一个新的Pod。此时它会检查集群里还有哪台GPU节点有显存、有可用的nvidia.com/gpu资源把这个Pod绑定上去。如果所有节点都满了新Pod就卡在Pending状态。第三步Pod创建后内部的vLLM进程开始初始化。vLLM从模型仓库加载权重然后由SchedulerEngine创建KV Cache管理器。此时vLLM内置调度器并不能立刻处理请求因为它要先完成权重加载和显存预热这个过程通常需要几十秒到几分钟取决于磁盘速度和模型大小。第四步Pod的Ready探针通过后请求流量才开始进入vLLM。vLLM的Scheduler把每个请求包装成一个SequenceGroup放入Waiting队列。调度器根据当前可用block数量决定是否将它升级为Running并开始解码。第五步如果模型权重被拆成了多张卡做张量并行比如TP4那么这一个副本就消耗4张GPU。每轮解码时vLLM会通过分布式的executor把同一批请求分发给4个进程各进程同时做局部计算再通过通信汇总。在这个全流程中Ray的作用有两种可能一种是不用Ray纯Kubernetes部署另一种是Kubernetes作为底层提供节点Ray在工作负载层面调度“预处理任务”“后处理任务”“定时评估任务”。以批量推理为例Ray会把大批量输入数据切成小分片然后通过Actor向Kubernetes集群中的多个vLLM实例分发推理任务最后聚合结果。此时vLLM内部的请求级调度依然在做它自己该做的事。5.2 调度配置Checklist与实测体验我自己在部署类似架构时会给三层分别配置一份检查清单避免遗漏导致意想不到的“调度空转”。Kubernetes层至少要确认这几项GPU资源声明正确requests和limits都写了nvidia.com/gpu节点标签和Pod的nodeSelector匹配且GPU节点没有被打上不相关的污点为推理服务配了podAntiAffinity保证多副本不在同一节点上HPA的指标用的是GPU相关指标而不是默认CPU模型权重有PVC缓存扩容时不需要重新下载Ray层至少确认ray.init指定了GPU资源为0避免Ray进程本身抢占GPU资源Placement Group的PACK/SPREAD策略符合模型并行/数据并行的需求任务失败重试的max_retries设了一个合理值避免因为上游实习问题无限重试打满队列Ray Dashboard监控到每个Worker的资源利用率别让CPU和GPU使用率差异过大vLLM层至少确认--gpu-memory-utilization尽量卡在0.85到0.95之间太低并发上不去太高容易OOM--max-num-seqs根据实际显存推算。一个经验法则是max_num_seqs * 单序列平均KV Cache占用不应超过KV Cache总容量的70%留出缓冲--max-model-len和KV Cache预留大小匹配过长会把显存全吃掉开了--enable-prefix-caching如果业务有大量共享前缀比如System Prompt很长这个开关能带来成倍的吞吐提升实测下来的感受是这三层里最容易出问题的其实是Kubernetes层和vLLM层的交互。Kubernetes认为节点还有2张显卡可用但其中一张卡已经被其他进程占用了大部分显存这时候新的vLLM Pod会被调度上去然后直接OOM。解决这个问题要么靠Kubernetes上的GPU显存监控做精确调度要么在vLLM启动时显式加上--max-model-len限制显存占用的上限。5.3 排查问题时先定位哪一层很多人在大模型服务出问题时的第一反应是查模型代码但在调度体系里90%的问题其实出在调度配置上。我给你几个快速定位的经验法则如果现象是“请求卡住不返回但没有报错日志”优先看vLLM的调度层。大概率是max_num_seqs被占满了或者等待队列里有大量长请求在抢blockRunning的请求一直被抢占导致某些请求永远在排队。看日志里scheduler相关的排队时长统计能很快确认。如果现象是“流量过低时请求也超时”先看Kubernetes层。可能是因为Pod调度到了性能较差的节点比如L20和A100混部但你没给Pod按机型打不同标签vLLM跑在L20上的性能完全达不到预期。这时用kubectl top node看一下GPU型号和实际利用率基本就清楚了。如果现象是“离线批量任务和在线推理互相影响”问题通常出在Ray层。Ray把批量任务调度到了正在跑在线推理的GPU节点上抢占了资源导致在线推理延迟升高。解决办法是在Ray里对不同的资源池做隔离用placement_group把离线任务和在线任务分开调度。还有一个小技巧给每个vLLM副本的Pod加上container-level的GPU利用率日志或Metric这样你就能直接通过Prometheus看到某个时刻是“节点卡没有高利用还是请求排队在等待”用数据把三层调度的问题拆解开。6. 不同场景下怎么选、怎么平衡6.1 小团队用K8svLLM就够了为什么如果你的场景是纯在线推理、不需要批量计算、不需要复杂的DAG任务编排那真的不需要Ray。一个Kubernetes集群加若干个vLLM Deployment配合HPA和负载均衡已经能够满足绝大部分生产需求。少一层调度器就少一类故障源。三套调度叠在一起每一个都是一套需要监控、调参、排查的复杂系统。实际运营推理服务时vLLM的调度和Kubernetes的调度已经够费心了。只有当任务模式多样化、需要精细的分布式编排时Ray的价值才会凸显出来。6.2 训练/调优/RL场景离不开Ray如果你的业务涉及模型微调、数据并行训练、RLHF、或者大批量离线的数据推理Ray几乎是绕不开的选择。以RLHF为例整个流程要“策略模型采样、奖励模型打分、策略模型更新”多阶段迭代。这个场景天然需要多个模型之间的消息传递、进度同步、资源调度。Ray的Actor模型可以很优雅地表达“一个RewardModelActor常驻、多个RolloutWorker持续采样”这种模式。而如果只用Kubernetes你需要自己写一套分布式框架去协调这些进程工程成本高得多。我见过不少团队一开始觉得“引入Ray太重”但到了写分布式训练pipeline的时候最终还是回头来用Ray。原因很简单Kubernetes的设计目标是“服务编排”它并不擅长处理进程间的数据依赖和任务图执行而Ray就是专门为“分布式计算编排”设计的这层匹配关系很难替代。6.3 实用经验调度协调失误常见的坑最后分享几个我在同时使用三层调度器时踩过的坑希望你能避开。第一个坑是资源重复统计。Kubernetes上报了GPU资源Ray的ray status也会统计GPU如果你在Kubernetes节点上直接装Ray而不是用Kubernetes管理Ray的Pod很可能会发现Ray调度器认为某节点有8张卡而Kubernetes也认为这8张卡可用结果两边同时分配把实际只有8张卡的节点分配了16次。解决方法是明确“资源的唯一所有权”GPU资源谁注册谁分配通常建议用Kubernetes管理一切资源Ray只作为工作负载层运行在Kubernetes之上。第二个坑是vLLM实例被Kubernetes调度到多卡节点时--tensor-parallel-size与实际卡数不匹配。如果TP4但Kubernetes只分配了2张卡vLLM启动时会尝试用4个进程占用4张卡导致节点上的其他工作负载OOM或资源冲突。我的经验是在Kubernetes的Pod里显式设置limits.nvidia.com/gpu然后在vLLM启动脚本里通过nvidia-smi -L动态检测实际可用的卡数再用这个数字组装参数。第三个坑是PV缓存权和多副本同时启动的竞争。用PVC缓存模型权重时如果HPA一下子拉起5个副本5个进程同时尝试往同一个PV路径写缓存可能产生数据损坏。解决方法是给缓存目录做成只读挂载模型准备好后统一分发或者用支持Write-Around的缓存设计。总结就是挂在什么层的问题就在什么层解决。Kubernetes的调度解决的是“Pod放哪”的容量问题Ray的调度解决的是“任务给谁干”的执行问题vLLM的调度解决的是“请求谁来算”的微观问题。只要把这三个问题在架构设计时想清楚部署大模型服务的过程会很顺排查问题时也会少走很多弯路。