Kubernetes、Ray、vLLM 三层调度分工与协同优化-北京尧图网络

1. 三类调度器不是“谁管谁”而是各守一段技术栈的边界“Kubernetes、Ray、vLLM 都在调度它们各自决定了什么”——这个问题背后藏着一个普遍误解很多人下意识把这三者当成同一层级的“资源分配工具”甚至试图比较“哪个调度更强”。实则不然。它们根本不在同一个抽象层上工作更像铁路系统里的不同角色Kubernetes 是修轨道、建车站、管列车时刻表的基建与运力调度方Ray 是设计车厢编组、定义乘客上下车流程、协调多节车厢协同运行的任务执行框架调度方而 vLLM 则是坐在某节特定车厢里、专精于“如何让每位乘客token以最短路径、最少等待时间通过检票口和座位引导区”的模型推理粒度调度方。三者不重叠、不替代而是纵向嵌套、职责分明。我第一次在生产环境同时部署这三者时就踩过典型误区以为把模型镜像塞进 Kubernetes Pod 就万事大吉结果发现 GPU 显存利用率长期卡在 30% 以下QPS 上不去。排查三天才发现Kubernetes 确实把 1 张 A100 分配给了 Pod但 vLLM 的 PagedAttention 内存管理没启用Ray 的 Actor 并发数设得过高导致请求排队而 Kubernetes 的 Horizontal Pod AutoscalerHPA又因指标采集延迟根本没触发扩缩容。问题不在“谁没调度”而在“谁该调度什么”没理清。这种分层本质直接决定了你调试时的排查路径。当你遇到“GPU 利用率低但延迟高”这类典型症状必须按顺序问三个问题Kubernetes 层Pod 是否真拿到了独占的 GPU 设备nvidia-smi在容器内是否可见设备插件NVIDIA Device Plugin是否注册成功Ray 层Actor 实例是否被正确放置在有 GPU 的节点上ray.get_gpu_ids()返回值是否匹配是否存在跨节点数据传输瓶颈vLLM 层Scheduler 是否启用了enable_chunked_prefillKV Cache 是否因block_size16过小导致频繁换页max_num_seqs是否远低于硬件并发能力关键词Kubernetes、Ray、vLLM、调度、GPU在这里不是并列关系而是纵向责任链Kubernetes 决定“物理资源归谁用”Ray 决定“逻辑任务怎么分发与协同”vLLM 决定“单次推理请求内部 token 如何高效流转”。忽略这个分层所有优化都是隔靴搔痒。提示很多团队在压测时发现 vLLM 吞吐上不去第一反应是调大--tensor-parallel-size。但若 Kubernetes 没给 Pod 绑定足够多的 GPU或 Ray 的 Placement Group 没预留对应数量的 GPU 资源这个参数调得再大也毫无意义——它只会触发 vLLM 的 fallback 逻辑降级为单卡运行。2. Kubernetes决定“谁能在哪台机器上用多少块 GPU”Kubernetes 的调度核心是解决“资源供给”问题。它不关心你跑的是大模型推理、训练还是数据库只认三样东西CPU 核心数、内存字节数、GPU 设备数由 device plugin 抽象为nvidia.com/gpu这类扩展资源。它的调度器默认是 kube-scheduler在每次创建 Pod 时执行一个确定性决策从集群所有 Node 中筛选出满足resources.requests.nvidia.com/gpu: 1的节点并确保该节点剩余 GPU 数量 ≥ 请求量。但这只是起点。真实场景中Kubernetes 的调度决策远比“有没有 GPU”复杂得多。我们曾在线上遇到一个经典案例集群有 8 台 A100 服务器每台 8 卡总 GPU 数 64。vLLM 服务配置了requests: {nvidia.com/gpu: 2}理论上可部署 32 个 Pod。但实际部署到第 25 个时新 Pod 就卡在Pending状态。kubectl describe pod显示0/8 nodes are available: 8 node(s) didnt match Pods node affinity/selector。排查发现问题出在Topology-aware 调度上——我们启用了 NVIDIA GPU Operator 的 Topology Manager要求 CPU Core、PCIe Root Port、GPU Device 必须在同一个 NUMA Node 上。而部分 A100 服务器的 BIOS 设置中GPU 被映射到了非对称的 NUMA 域导致虽然总 GPU 数充足但符合拓扑约束的“可用 GPU 对”只有 24 个。这就引出了 Kubernetes 调度的四个关键决策维度每个都直接影响 vLLM 的实际性能2.1 GPU 设备绑定从“共享”到“独占”的硬隔离默认情况下Kubernetes 仅保证 Pod 请求的 GPU 数量可用但不阻止其他 Pod 共享同一张卡通过 CUDA_VISIBLE_DEVICES 控制。这对 vLLM 是灾难性的。vLLM 的 PagedAttention 依赖稳定的显存布局若另一进程突然申请大量显存会导致 KV Cache Block 被强制换出引发严重抖动。解决方案是启用GPU 设备插件的device-plugin模式配合nvidia.com/gpu: 1的 requests/limits实现物理卡级独占。验证方法很简单进入 Pod 执行nvidia-smi -L应只看到 1 行输出再执行nvidia-smi dmon -s u观察util列是否稳定在 70%~95%而非忽高忽低。2.2 拓扑亲和性让计算离数据更近vLLM 的推理延迟对 PCIe 带宽极其敏感。一次典型的 Prefill 阶段需将整个 prompt embedding 从 CPU 内存拷贝到 GPU 显存再经 Transformer Layer 计算。若 GPU 与 CPU 不在同一 NUMA Node跨 NUMA 访问延迟可达 100ns 以上远超 PCIe 4.0 的 32GB/s 带宽限制。Kubernetes 通过topologySpreadConstraints和nodeAffinity强制调度器将 Pod 放置在 GPU 与 CPU 拓扑一致的节点上。我们的配置如下topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: vllm-inference nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: nvidia.com/gpu.present operator: Exists - key: topology.kubernetes.io/region operator: In values: [cn-north-1]这段配置确保1Pod 不会跨可用区调度避免网络延迟2只调度到有 GPU 的节点3同区域内的节点间 GPU 分布尽可能均匀防止单点过载。2.3 资源预留为 vLLM 的“突发流量”留出缓冲带vLLM 的 Scheduler 会动态调整max_num_seqs最大并发请求数其理论峰值受max_model_len最大序列长度和block_sizeKV Cache Block 大小共同制约。公式为max_num_seqs ≈ (total_gpu_memory - model_weights_memory) / (block_size * 2 * sizeof(float16))其中2是 Key 和 Value 各占一份。以 80GB A100 为例加载 LLaMA-3-8B约 16GB 权重剩余显存约 64GB。若block_size16则max_num_seqs ≈ 64 * 1024^3 / (16 * 2 * 2) ≈ 1048576。但这是理想值。实际中CUDA Context、PyTorch Autograd Graph、临时 Buffer 都会占用额外显存。因此我们在 Kubernetes 中为 vLLM Pod 设置limits.nvidia.com/gpu: 1但requests.nvidia.com/gpu: 0.5——这不是为了“超卖”而是向调度器声明“我需要 1 整张卡但启动时只预占一半显存为后续动态增长留出空间”。这避免了因requestslimits导致的过度保守调度。2.4 自动扩缩容用 HPA 抓住真实的业务脉搏Kubernetes 的 HPA 默认基于 CPU/Memory 指标这对 vLLM 几乎无效。一个空闲的 vLLM PodCPU 利用率可能只有 5%但 GPU 利用率已满载反之当请求队列堆积时CPU 可能飙升至 90%但 GPU 仍在等数据。我们必须自定义指标。我们采用 Prometheus kube-state-metrics 方案采集 vLLM 暴露的/metrics端点中的vllm:gpu_cache_usage_ratioGPU Cache 使用率和vllm:request_queue_size请求队列长度。HPA 配置如下apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: vllm-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: vllm-deployment minReplicas: 2 maxReplicas: 20 metrics: - type: Pods pods: metric: name: vllm_request_queue_size target: type: AverageValue averageValue: 10 - type: Pods pods: metric: name: vllm_gpu_cache_usage_ratio target: type: AverageValue averageValue: 0.8这意味着当平均队列长度 10 或平均 Cache 使用率 80% 时HPA 开始扩容。实践证明这套组合指标比单一 CPU 指标响应快 3 倍且误扩容率低于 2%。注意不要迷信nvidia.com/gpu这个资源名。它由 NVIDIA Device Plugin 注册但插件版本必须与 Kubernetes 版本兼容。我们曾升级到 Kubernetes v1.26 后旧版 Device Pluginv0.9.0无法正确识别 A100 的 MIGMulti-Instance GPU切片导致nvidia-smi -L在节点上能看到 7 个 MIG 实例但kubectl get nodes -o wide却只显示nvidia.com/gpu: 0。最终回退到 Device Plugin v0.11.0 并重启 kubelet 才解决。版本兼容性表必须查 NVIDIA 官方文档不能凭经验猜测。3. Ray决定“多个 vLLM 实例如何协同完成一个推理任务”如果说 Kubernetes 解决了“硬件资源在哪”那么 Ray 解决的是“逻辑任务怎么分”。vLLM 本身是一个单进程服务但生产环境往往需要处理高并发、长尾延迟、模型路由等复杂需求。这时Ray 的 Actor 模型就成为天然的 glue layer。它不调度 GPU而是调度“使用 GPU 的 Python 对象”。3.1 Actor 放置让计算靠近数据而非远离Ray 的核心概念是 Actor——一个有状态的、远程可调用的 Python 类实例。当我们部署 vLLM 时通常会创建一个VLLMActor其__init__方法中初始化AsyncLLMEngine。关键在于这个 Actor 必须被放置在有 GPU 的节点上且其生命周期必须与 GPU 资源绑定。否则Actor 可能被调度到 CPU 节点导致torch.cuda.is_available()返回 False初始化直接失败。Ray 提供了PlacementGroup机制来精确控制资源分配。我们定义一个pg ray.util.placement_group([{CPU: 4, GPU: 1}], strategySTRICT_PACK)然后用VLLMActor.options(placement_grouppg).remote()创建 Actor。STRICT_PACK策略确保所有资源4 CPU 1 GPU必须来自同一个物理节点彻底避免跨节点通信开销。这与 Kubernetes 的topologySpreadConstraints形成双重保障Kubernetes 确保 Pod 在正确节点Ray 确保 Actor 在 Pod 内的正确位置。3.2 并发模型Actor vs. Task选错就是性能黑洞Ray 提供两种并行原语无状态的ray.remoteTask 和有状态的 Actor。初学者常犯的错误是为每个请求都创建一个新 Taskawait generate_text.remote(prompt)。这看似简单但代价巨大每次 Task 启动都要重新加载模型权重、初始化 CUDA Context、重建 KV Cache 结构耗时可达 500ms~2s。而 vLLM 的核心价值恰恰在于复用这些昂贵资源。正确做法是用一个 Actor 承载所有请求用异步方法暴露服务。代码结构如下ray.remote(num_gpus1) class VLLMActor: def __init__(self): self.engine AsyncLLMEngine.from_engine_args(engine_args) async def generate(self, prompt: str, sampling_params: SamplingParams): results_generator self.engine.generate(prompt, sampling_params) final_output None async for request_output in results_generator: final_output request_output return final_output # 调用方 actor VLLMActor.remote() result await actor.generate.remote(Hello, SamplingParams(temperature0.7))这里num_gpus1是 Ray 的资源声明它会触发 Ray 的调度器去寻找有 1 块 GPU 的节点。Actor 初始化后所有generate调用都复用同一个engine实例真正实现了“一次加载多次推理”。3.3 资源隔离防止一个模型拖垮整个集群生产环境中我们常需同时部署多个模型如 LLaMA-3、Qwen、GLM每个模型对 GPU 显存、计算能力的需求不同。若所有 Actor 共享同一份 GPU 资源池一个模型的 OOM 可能导致整个 Ray Cluster 不稳定。Ray 的解决方案是Resource Customization。我们为每个模型 Actor 声明专属资源标签ray.remote(resources{llama3_8b_gpu: 1}) class Llama3Actor: ... ray.remote(resources{qwen2_7b_gpu: 1}) class Qwen2Actor: ...然后在启动 Ray Cluster 时为每个节点指定其支持的资源ray start --head --resources{llama3_8b_gpu: 2, qwen2_7b_gpu: 2}这样Llama3Actor只会被调度到声明了llama3_8b_gpu资源的节点且不会与Qwen2Actor争抢同一块 GPU。这是一种轻量级的、应用层的资源隔离比 Kubernetes 的 Namespace 级隔离更细粒度比 vLLM 的模型并行更灵活。3.4 故障恢复Actor 的状态持久化与自动重启vLLM 的AsyncLLMEngine是有状态的它维护着正在运行的请求队列、KV Cache 的 Block Table、生成过程中的中间结果。如果 Actor 所在的节点宕机这些状态会丢失导致请求失败。Ray 提供了checkpointing机制但 vLLM 官方并不推荐对 Engine 做全量 Checkpoint因为显存状态难以序列化。我们的实践方案是将 Actor 设计为“无状态核心有状态外部存储”。具体来说VLLMActor本身不保存任何请求中间状态所有generate调用都立即转发给一个中心化的RequestManager部署为独立的 Ray Service。RequestManager使用 Redis 存储请求元数据prompt、sampling_params、request_id并将request_id返回给客户端。vLLM Actor 只负责根据request_id从 Redis 读取 prompt调用engine.generate再将结果写回 Redis。这样即使 Actor 重启只要RequestManager和 Redis 健在客户端就能通过轮询request_id获取结果。这是一种典型的“计算与状态分离”架构牺牲了极少量延迟Redis 读写约 1~2ms换来了 99.99% 的故障恢复能力。实操心得Ray 的ray.remote装饰器有一个易被忽视的参数max_restarts。默认为-1无限重启这在开发时很友好但在生产环境可能导致“雪崩”——一个有 Bug 的 Actor 不断崩溃重启消耗大量 CPU 资源。我们强制设置max_restarts3并在第 3 次失败后由监控系统触发告警并人工介入。同时在 Actor 的__init__中加入try...except捕获torch.cuda.OutOfMemoryError并主动调用ray.actor.exit_actor()避免陷入无限 OOM 循环。4. vLLM决定“单个请求内部每个 token 如何被最高效地计算”当 Kubernetes 把 GPU 给了 PodRay 把 Actor 放到了正确的 GPU 上vLLM 才真正开始它最核心的工作在单张 GPU 上以微秒级精度调度每一个 token 的计算。这与前两层的“宏观调度”截然不同是真正的“微观调度”。4.1 PagedAttentionGPU 显存的“虚拟内存管理”传统推理框架如 HuggingFace Transformers将 KV Cache 存储为连续的 Tensor其大小由max_seq_len决定。例如max_seq_len32768时一个 32 层的模型KV Cache 显存占用约为32 * 2 * 32768 * hidden_size * sizeof(float16)。对于 LLaMA-3-8Bhidden_size4096这轻松突破 40GB远超单卡容量。vLLM 的破局点是PagedAttention它借鉴操作系统虚拟内存思想将 KV Cache 拆分为固定大小的Block默认 16 个 token每个 Block 存储在显存的离散物理页中。逻辑上连续的序列其 KV Cache Block 可以分散在显存各处。这带来三大优势显存碎片容忍即使显存被划分为许多小块只要总空闲 Block 数够就能容纳长序列。零拷贝共享多个请求的 prefix如 system prompt可共享同一组 Block无需复制。动态扩容新请求到来时只需分配新 Block无需 realloc 整个 Tensor。block_size是 PagedAttention 的核心参数。我们做过一组对比实验在 A100 80GB 上部署 LLaMA-3-8Bmax_model_len32768测试不同block_size下的吞吐req/s和首 token 延迟msblock_size吞吐 (req/s)首 token 延迟 (ms)显存碎片率412.318512%1628.7923%6431.2880.5%25629.5950.1%结论清晰block_size16是黄金平衡点。过小4导致 Block Table 过大元数据开销占比高过大256虽碎片率低但单个 Block 未填满时浪费显存且 Prefill 阶段的内存带宽压力增大。block_size不是越大越好必须结合模型尺寸和典型 prompt 长度综合选择。4.2 Scheduler请求队列的“交通管制员”vLLM 的 Scheduler 是整个引擎的“大脑”它决定1新请求何时被接纳Admission Control2已接纳请求的 token 何时被计算Scheduling Policy3KV Cache Block 如何被复用与回收Memory Management。其核心数据结构是ScheduledSequenceGroup每个代表一个待处理的请求。Scheduler 维护两个队列Waiting Queue新请求在此排队等待显存和计算资源。Running Queue正在被计算的请求其seq_group已被分配 Block。关键决策逻辑在schedule()函数中。它每轮循环执行Prefill 阶段检查遍历 Waiting Queue对每个请求计算prefill_tokens_needed len(prompt)。若available_blocks prefill_tokens_needed / block_size则将其移入 Running Queue并为其分配 Block。Decode 阶段调度对 Running Queue 中所有请求计算decode_tokens_needed len(running_seqs)即当前正在生成的序列数。若available_blocks decode_tokens_needed则允许本轮 Decode。Block 回收对已完成的请求将其占用的所有 Block 标记为free。这个看似简单的逻辑却隐藏着深刻权衡。例如“是否允许新请求抢占正在 Decode 的请求的 Block”答案是否。vLLM 采用FIFO Preemption策略新请求只能等待或当显存不足时强制中断Preempt一个老请求将其 Block 换出到 CPU 内存Swap-out腾出空间。这会导致被中断请求的延迟飙升但保障了新请求的公平性。我们线上将preemption_moderecompute而非swap即中断后不换出而是下次继续 Prefill避免 Swap 的 I/O 开销。4.3 EngineCore 与 Scheduler/Executor 的交互一场精密的“流水线协作”vLLM 的架构图常被简化为“Scheduler → Executor”但真实交互远比这复杂。AsyncLLMEngine是顶层入口它内部持有Scheduler和ModelRunnerExecutor 的封装。三者协作流程如下Client 发起请求engine.generate(prompt)创建一个Request对象放入Scheduler.waiting队列。Scheduler 调度Scheduler.schedule()返回一个SchedulerOutput包含seq_groups本轮要计算的请求列表。blocks_to_swap_in/out需要换入/换出的 Block ID 列表。num_lookahead_slots为下一个 Prefill 预留的 slot 数。Executor 执行ModelRunner.execute_model()接收SchedulerOutput执行三步Swap-in/out调用 CUDA kernel 将 Block 从 CPU 内存拷贝到 GPU 显存或反之。Prefill对新请求执行完整 Transformer 前向传播生成第一个 token。Decode对已有请求执行单步 Transformer生成下一个 token。结果返回ModelRunner将生成的 token、logprobs 等打包为SamplerOutput交还给Scheduler。Scheduler更新seq_group状态并决定下一轮调度。这个流水线的关键在于异步与重叠。Swap-in和Prefill可以在不同 CUDA Stream 上并发执行Prefill的输出可以直接作为Decode的输入无需 CPU-GPU 数据拷贝。vLLM 通过精细的 CUDA Stream 管理将这些操作重叠起来将 GPU 利用率推至极限。这也是为什么 vLLM 的吞吐能比 Transformers 高 2~4 倍——它不是更快地算一个 token而是让 GPU 几乎没有空闲时刻。4.4 参数调优那些文档里没写的“经验值”vLLM 的命令行参数众多但真正影响生产性能的只有几个关键项。以下是我们在 10 个线上模型服务中验证过的“必调参数”--max-num-seqs 256这是max_num_seqs的硬上限。不要设为理论最大值如 1048576那会导致 Scheduler 队列过长增加延迟。256 是一个安全起点可根据vllm:request_queue_size监控指标逐步上调。--block-size 16如前所述16 是 A100/H100 上的黄金值。对于 L424GB 显存建议--block-size 8以降低碎片。--enable-chunked-prefill当prompt极长8192 tokens时启用此选项可将 Prefill 分块执行避免单次 kernel launch 时间过长导致 GPU 超时。但会略微增加显存开销约 5%。--gpu-memory-utilization 0.9显存利用率阈值。默认 0.9意味着当显存使用率 90% 时Scheduler 会拒绝新请求。我们线上设为0.85为 CUDA Context 留出缓冲。--enforce-eager仅在调试时开启。它禁用 vLLM 的图优化CUDA Graph让每个 kernel 都单独 launch便于用 Nsight Compute 分析性能瓶颈。生产环境必须关闭否则吞吐下降 30%。踩坑实录我们曾将--max-num-seqs设为 1024认为“越大越好”。结果发现当请求队列长度超过 500 时Scheduler.schedule()函数本身Python 代码的 CPU 占用飙升至 90%成为瓶颈。这是因为schedule()需遍历所有seq_group计算资源需求O(n) 复杂度。最终我们改用--max-num-batched-tokens 4096限制每轮最多处理的 token 总数将 CPU 负担转移到 C 层问题迎刃而解。这印证了一个原则vLLM 的调优本质是在 Python 层Scheduler和 C/CUDA 层Executor之间找到负载平衡点。5. 三层联动一次请求的完整生命周期与排障地图理解了 Kubernetes、Ray、vLLM 各自的职责最终要回归到一个最朴素的问题当用户在前端点击“发送”到收到第一个 token这中间到底发生了什么下面我们以一次典型的 LLaMA-3-8B 推理请求为例绘制完整的端到端生命周期图谱并附上每一环节的排障要点。5.1 生命周期从 HTTP 请求到 token 流HTTP 入口层Kubernetes Ingress用户请求POST /v1/completions到 Kubernetes Service。Ingress Controller如 Nginx根据host和path将流量路由到后端vllm-deployment的 Pod IP。排障点若返回503 Service Unavailable先检查kubectl get endpoints vllm-service确认 Endpoint 列表非空。若为空说明 Pod 未就绪Readiness Probe 失败需看 Pod 日志。Kubernetes Pod 层请求到达 Pod 内的vllm-api-serverFastAPI 进程。此时nvidia-smi应显示该 Pod 独占 1 张 GPU且CUDA_VISIBLE_DEVICES环境变量应为0。排障点若vllm-api-server启动报错CUDA driver version is insufficient说明容器内 NVIDIA 驱动版本nvidia-smi输出与宿主机驱动不匹配。必须使用与宿主机驱动兼容的nvcr.io/nvidia/pytorch基础镜像。Ray Actor 层vllm-api-server调用ray.get_actor(vllm_actor).generate.remote(...)。Ray Client 通过 GCSGlobal Control Store定位到vllm_actor所在的 Worker Node 和进程。排障点若报错ActorDiedError或RayTaskError执行ray status查看集群状态重点检查Used Resources中GPU是否为 0说明 Actor 未成功获取 GPU。vLLM Engine 层VLLMActor.generate()调用self.engine.generate()。AsyncLLMEngine的add_request()将请求加入Scheduler.waiting队列。排障点若请求长时间卡在waiting状态curl http://localhost:8000/metrics | grep vllm_request_queue_size查看队列长度。若 0 且持续增长说明Scheduler无法为其分配 Block需检查vllm:gpu_cache_usage_ratio是否已达 100%。PagedAttention 执行层Scheduler.schedule()返回SchedulerOutputModelRunner.execute_model()启动 CUDA kernel。此时nvidia-smi dmon -s u应显示util列稳定在 80%~95%mem列缓慢上升。排障点若util波动剧烈如 10% ↔ 90%说明存在严重的 kernel launch 间隔可能是block_size过小导致 Block Table 查找开销过大或max_num_seqs过大导致 Python 层调度瓶颈。结果返回层ModelRunner生成SamplerOutputScheduler更新seq_group状态并将首个 token 通过AsyncLLMEngine的 callback 机制经vllm-api-server的 SSEServer-Sent Events流式返回给前端。排障点若收到首个 token 后后续 token 停滞检查vllm:gpu_cache_usage_ratio是否在生成过程中骤降至 0%——这表明 KV Cache 被意外清空常见于max_model_len设置过小导致序列被 Truncate。5.2 排障地图按现象反推故障层生产中最常见的 5 类现象及其精准的定位路径现象可能根因层关键检查命令快速验证方法Pod 一直 PendingKuberneteskubectl describe pod pod-name查看 Events 中是否有0/8 nodes are available: ...确认 GPU 资源请求是否被满足Pod Running 但nvidia-smi无 GPUKuberneteskubectl exec -it pod-name -- nvidia-smi -L若报错NVIDIA-SMI has failed...检查nvidia-device-plugin-daemonset是否在对应节点 RunningAPI 返回 500日志报CUDA out of memoryvLLMkubectl logs pod-name | grep CUDA检查--gpu-memory-utilization是否设得过高或--block-size是否过小导致碎片吞吐极低5 req/sGPU util 20%Ray 或 vLLMray statuscurl http://localhost:8000/metrics | grep vllm若vllm_request_queue_size高而vllm_gpu_cache_usage_ratio低说明 Ray Actor 未正确绑定 GPU若两者都低说明 vLLM 未收到请求检查 API Server 日志首 token 延迟高500ms后续 token 快vLLMnvidia-smi dmon -s ucat /proc/pid/status | grep VmRSS首次 Prefill 需加载模型权重若VmRSS内存占用在 Prefill 后激增说明模型加载正常若util在 Prefill 阶段很低可能是--enable-chunked-prefill未启用导致长 prompt 单次 kernel 过大这张地图的价值在于它把模糊的“性能差”转化为可执行的、分层的诊断指令。工程师不再需要“大海捞针”而是按图索骥5 分钟内即可定位到具体层级。最后分享一个血泪教训我们曾上线一个新模型服务压测时一切正常但上线后用户反馈“偶尔卡顿”。监控显示vllm_request_queue_size会周期性飙升到 200然后在 1 秒内回落。排查数日无果最终发现是 Kubernetes 的livenessProbe配置了initialDelaySeconds: 30而 vLLM 的首次 Prefill 耗时恰好 32 秒。Probe 失败导致 Pod 被反复重启每次重启都丢弃了所有请求形成“卡顿”假象。解决方案是将initialDelaySeconds改为60并添加failureThreshold: 3。这提醒我们Kubernetes 的运维配置与 vLLM 的性能特征必须深度耦合。脱离 vLLM 的实际行为去配置 K8s注定失败。我在实际部署 vLLM 的三年里见过太多团队把问题归咎于“vLLM 不够快”结果花两周优化 vLLM 参数却发现根源是 Kubernetes 的topologySpreadConstraints配置错误导致 80% 的请求被调度到跨 NUMA 的节点上。真正的性能工程从来不是单点优化而是对

Kubernetes、Ray、vLLM 三层调度分工与协同优化

相关推荐

Kubernetes 上构建 Agentic 工作负载的运行时调度层：ax 调度设计与实践

基于Kubernetes的Agentic运行时编排：ax调度与池化实践

Kubernetes 上 agentic 工作负载的运行时编排层设计与实践

更多资讯

SystemVerilog双向开关tran与tranif1选型指南：从仿真异常到建模实践

Agentic工作负载的云原生调度与编排：从Kubernetes到运行时实践

ax：云原生Agent调度底座设计与gRPC实践

Jev AI决策系统架构设计：从概念到生产的工程实践

第一次把 Godot 游戏发布到三大桌面平台：从导出到签名的完整实操路径

agent-native架构实战：从AI增强到原生智能体系统的设计原则与落地

今日更新

济南做网站多少钱：3个案例拆解，防黑源码下载全攻略

婚恋网站实战案例：避开3个高价坑，省钱50%还能跑赢流量

制作网页比较方便的软件怎么选?一文搞懂避坑指南

本周精选

如何彻底离线使用 Laya-CoreML：Hugging Face 下载、缓存机制与 local_files_only 详解

基于1Panel 部署MySQL MCP 服务：TaoToken 统一 Key 接入与 config.toml 配置实战

崇州园区营销网站建设避坑指南：5大注意事项保备案安全

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？