大模型部署越来越复杂之后，很多团队会遇到一个共同的困惑：底层有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到Binding
Kubernetes的调度器（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一样；反之如果你只写requests，limit没写，那调度器认为你只用了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) didn't match node selector”。
3. Ray 调度：决定分布式计算任务给哪个Worker
3.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_gpus=1)里显式声明某个任务需要几张显卡、几个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，并开始解码。
第五步，如果模型权重被拆成了多张卡做张量并行，比如TP=4，那么这一个副本就消耗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被占满了，或者等待队列里有大量长请求在抢block，Running的请求一直被抢占，导致某些请求永远在排队。看日志里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 小团队用K8s+vLLM就够了，为什么
如果你的场景是纯在线推理、不需要批量计算、不需要复杂的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与实际卡数不匹配。如果TP=4但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的调度解决的是“请求谁来算”的微观问题。只要把这三个问题在架构设计时想清楚，部署大模型服务的过程会很顺，排查问题时也会少走很多弯路。
