KubeRay vLLMKubernetes 上的大模型推理服务生产级部署与三级弹性伸缩实战摘要在大模型落地过程中推理服务的稳定性、吞吐量和资源利用率是决定用户体验的核心指标。本文以生产环境实践为基础详细拆解如何基于 KubeRay 与 vLLM 在 Kubernetes 集群上构建高可用的大模型推理平台涵盖 GPU 精细化调度、三级弹性伸缩机制、PagedAttention 内存优化及全链路监控方案力求为 AI Infra 工程师提供一套可直接落地的技术实现路径。一、背景推理服务的生产级痛点随着 LLM大语言模型从实验室走向业务前台推理侧的工程挑战日益尖锐。以笔者所在团队维护的 70B 参数级模型为例上线初期我们遭遇了以下典型问题GPU 显存碎片化严重传统推理框架按请求动态分配显存长序列请求导致 OOMOut of Memory频发显存利用率长期低于 40%。扩容滞后基于 CPU 指标的 HPA 无法感知 GPU 显存压力和 Token 生成延迟流量突增时扩容周期长达 3-5 分钟远超用户容忍度。多模型混部困难不同业务线模型如 7B、13B、70B共存时Kubernetes 默认调度器缺乏对 GPU 拓扑和 MIGMulti-Instance GPU的细粒度感知导致节点负载严重不均衡。这些问题的根源在于Kubernetes 原生的资源调度语义与大模型推理的工作负载特征存在本质错配。vLLM 通过 PagedAttention 解决了显存管理问题而 KubeRay 则为分布式推理提供了 Gang Scheduling 和自动扩缩容能力两者的结合恰好补齐了生产环境的最后一块拼图。二、整体架构KubeRay vLLM 的核心设计2.1 架构全景我们采用的架构分为四层接入层Nginx Ingress Redis 缓存热点 Prompt降低重复请求对后端的压力。调度层KubeRay Operator 管理 RayCluster 生命周期集成 KubeFlow Training Operator 处理训练与推理的混合调度。推理层vLLM 作为推理引擎支持 Tensor ParallelismTP和 Pipeline ParallelismPP通过 Ray Serve 暴露 RESTful API。存储层S3 兼容对象存储存放模型权重配合本地 NVMe SSD 作为二级缓存模型加载时间从 11 分钟压缩至 20 秒。在这套架构中KubeRay 的核心价值在于Gang Scheduling当 vLLM 需要以 TP4 启动一个分布式推理实例时KubeRay 会确保 4 个 GPU Pod 同时被调度到具备高速 NVLink 互联的同一台物理机上避免因部分 Pod Pending 导致的资源死锁。2.2 为什么选 KubeRay 而不是原生 Deployment很多团队初期会直接用 Kubernetes Deployment 部署 vLLM但这会在生产环境埋下隐患对比维度原生 DeploymentKubeRay调度语义逐个调度 PodGang Scheduling全有或全无分布式感知无原生支持 TP/PP 的 GPU 拓扑感知自动扩缩容HPA 基于 CPU/内存Autoscaler 基于 Ray 任务队列深度故障恢复依赖 Pod 重启Ray 级 Actor 重建状态可恢复多租户隔离Namespace 级别Ray Queue 资源组细粒度隔离对于需要跨多卡分布式推理的 70B 模型Gang Scheduling 几乎是必选项。没有它Scheduler 可能将 Worker Pod 分散到不同节点导致 NCCL 通信走慢速网络TPOTTime Per Output Token飙升数倍。三、生产部署实战从 YAML 到 GPU 拓扑感知3.1 RayCluster 资源配置以下是我们生产环境使用的 KubeRay RayCluster 配置已脱敏核心要点包括apiVersion:ray.io/v1kind:RayClustermetadata:name:vllm-70b-inferencenamespace:llm-servingspec:rayVersion:2.32.0headGroupSpec:rayStartParams:dashboard-host:0.0.0.0block:truetemplate:spec:containers:-name:ray-headimage:vllm/vllm-openai:v0.5.4resources:limits:nvidia.com/gpu:1memory:64Gicpu:16env:-name:VLLM_ATTENTION_BACKENDvalue:FLASH_ATTN# FlashAttention 降低显存占用workerGroupSpecs:-groupName:gpu-workersreplicas:2minReplicas:1maxReplicas:6rayStartParams:block:truetemplate:spec:containers:-name:ray-workerimage:vllm/vllm-openai:v0.5.4resources:limits:nvidia.com/gpu:4# 每 Worker 4 张 A100 80Gmemory:512Gicpu:64env:-name:CUDA_VISIBLE_DEVICESvalue:0,1,2,3affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:-labelSelector:matchExpressions:-key:ray.io/node-typeoperator:Invalues:[head]topologyKey:kubernetes.io/hostname# 强制同节点部署关键设计决策解析TP4 PP2 组合70B 模型在 FP16 下约需 140GB 显存单 Worker 4 张 A100 80G 通过 Tensor Parallelism 拆分2 个 Worker 通过 Pipeline Parallelism 接力实现显存与吞吐的最佳平衡。强制同节点亲和性topologyKey: kubernetes.io/hostname确保 Head 与 Worker 落在同一物理机避免跨节点通信瓶颈。FlashAttention 后端相比传统 Attention 实现FlashAttention-2 在序列长度 4K 时可将显存占用降低 30%推理速度提升 1.5-2 倍。3.2 GPU 精细化调度MIG 与拓扑感知在 A100/H100 集群中我们启用了 NVIDIA Device Plugin 的 MIG 策略使得单张物理 GPU 可被切分为多个独立实例。这对于 7B/13B 小模型混部场景至关重要# MIG 配置示例spec:containers:-name:vllm-smallresources:limits:nvidia.com/mig-3g.40gb:1# 申请 1 个 MIG 3g.40gb 实例同时我们为集群部署了 NVIDIA GPU Operator 与 Node Feature DiscoveryNFD在节点上自动标注 GPU 拓扑信息feature.node.kubernetes.io/pci-10de.presenttrue nvidia.com/gpu.productA100-SXM4-80GB nvidia.com/gpu.memory81920 nvidia.com/gpu.topology.p2ptrue # NVLink P2P 互联调度时KubeRay 的 extended resources 插件会优先选择具备nvidia.com/gpu.topology.p2ptrue标签的节点确保 TP 组内 GPU 通过 NVLink 高速互联。四、三级弹性伸缩从被动响应到主动预测生产环境的流量特征往往是突发且不可预测的。我们设计了一套三级弹性伸缩体系将平均扩容响应时间从分钟级压缩至秒级。4.1 第一级HPA 基于自定义 GPU 指标Kubernetes 默认 HPA 只能基于 CPU/内存扩缩无法感知 GPU 显存和 Token 延迟。我们通过 Prometheus Adapter 暴露了 vLLM 的自定义指标# prometheus-adapter 规则customMetrics:-seriesQuery:vllm:gpu_cache_usage_percresources:template:.Resourcename:matches:^(.*)_percas:${1}_ratiometricsQuery:avg(.Series{.LabelMatchers})HPA 配置如下apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:vllm-hpaspec:scaleTargetRef:apiVersion:ray.io/v1kind:RayClustername:vllm-70b-inferenceminReplicas:1maxReplicas:6metrics:-type:Podspods:metric:name:vllm_gpu_cache_usage_ratiotarget:type:AverageValueaverageValue:0.75# GPU KV Cache 利用率超 75% 触发扩容-type:Podspods:metric:name:vllm_time_to_first_token_secondstarget:type:AverageValueaverageValue:800m# TTFT 800ms 触发扩容4.2 第二级KEDA 基于消息队列的事件驱动对于异步批处理场景如文档批量摘要我们使用 KEDA 监听 Redis Stream 的待处理消息数apiVersion:keda.sh/v1alpha1kind:ScaledObjectmetadata:name:vllm-batch-scalerspec:scaleTargetRef:name:vllm-batch-workerstriggers:-type:redis-streamsmetadata:address:redis.llm-serving.svc:6379stream:inference-queueconsumerGroup:vllm-consumerspendingEntriesCount:50# 堆积 50 条即扩容4.3 第三级定时 预测式扩缩容结合业务特征我们在每日 9:00、14:00 等流量高峰前 5 分钟通过 CronJob 预扩容apiVersion:batch/v1kind:CronJobmetadata:name:vllm-precachespec:schedule:55 8,13 * * *# 高峰前 5 分钟jobTemplate:spec:template:spec:containers:-name:scalerimage:bitnami/kubectlcommand:[kubectl,scale,raycluster,vllm-70b-inference,--replicas4]三级伸缩的效果对比基于生产环境 7 天数据指标仅 HPA三级弹性体系P99 TTFT2.3s420ms平均 GPU 利用率38%72%扩容响应时间180s15s闲置资源成本基准降低 41%五、性能调优PagedAttention 与请求调度策略vLLM 的核心创新在于PagedAttention它借鉴操作系统虚拟内存的分页机制将 KV Cache 划分为固定大小的块Block按需分配而非连续预分配。5.1 PagedAttention 内存优化原理传统推理框架为每个请求预分配max_seq_len的连续 KV Cache导致内部碎片实际序列长度远小于 max_seq_len外部碎片请求完成后释放的连续空间难以复用。PagedAttention 将 KV Cache 组织为非连续的 Block Table每个 Block 默认 16 tokens。当序列长度从 512 增长到 4096 时只需追加分配新 Block无需预留连续空间。在我们的生产环境中这一机制使单卡并发请求数从 8 提升至 32显存利用率从 40% 提升至 85%。5.2 请求调度策略对比vLLM 支持多种调度策略需根据业务场景选择策略适用场景特点FCFS先到先服务低延迟对话简单公平但短请求可能被长请求阻塞Shortest Job First多样化长度最小化平均等待时间需预估输出长度Continuous Batching高吞吐服务动态合并新请求到正在运行的 Batch 中吞吐量最高生产环境我们采用Continuous Batching又称 In-flight Batching配合--max-num-seqs256和--max-model-len8192参数在延迟与吞吐之间取得平衡。5.3 关键启动参数调优python-mvllm.entrypoints.openai.api_server\--model/models/Qwen2-72B-Instruct\--tensor-parallel-size4\--pipeline-parallel-size2\--max-num-seqs256\# 最大并发序列数--max-model-len8192\# 最大上下文长度--gpu-memory-utilization0.92\# 显存利用率上限留 8% 缓冲--enable-chunked-prefill\# 大 Prefill 请求分块降低 TTFT--dtypebfloat16# Ampere 架构推荐其中--enable-chunked-prefill是 v0.5.x 引入的关键特性它将长序列的 Prefill 阶段拆分为多个小块执行避免单个长请求阻塞整个 Batch 的 Decode 阶段P99 TTFT 可降低 50% 以上。六、全链路可观测性指标、日志与追踪推理服务的可观测性不能仅停留在服务是否存活必须深入到 Token 级别的延迟分析。6.1 核心监控指标体系我们基于 Prometheus Grafana 构建了四层监控大盘集群层GPU 利用率、显存占用、NVLink 带宽、温度与功耗服务层QPS、P50/P99 TTFT、TPOT、请求成功率引擎层vLLM 的gpu_cache_usage_perc、num_running_reqs、prefill_time_ms业务层首字返回时间、输出 Token 数、用户会话长度分布6.2 分布式追踪通过集成 OpenTelemetry我们将请求从前端 Ingress 到 vLLM 的 Prefill/Decode 阶段全链路串联fromopentelemetryimporttrace tracertrace.get_tracer(vllm.inference)withtracer.start_as_current_span(vllm_generate)asspan:span.set_attribute(model.name,Qwen2-72B)span.set_attribute(input.tokens,len(input_ids))span.set_attribute(tpot.avg_ms,avg_tpot)# 调用 vLLM generate在 Jaeger UI 中可以清晰看到每个请求的 Prefill 耗时、Queue 等待耗时、Decode 逐 Token 耗时为性能瓶颈定位提供精确依据。七、总结与展望本文从生产实践出发系统性地介绍了基于 KubeRay vLLM 构建大模型推理平台的关键技术点架构层面利用 KubeRay 的 Gang Scheduling 解决分布式推理的 Pod 协同调度问题利用 vLLM 的 PagedAttention 突破显存瓶颈调度层面通过 MIG GPU 拓扑感知实现异构模型混部通过三级弹性伸缩应对流量波动性能层面Continuous Batching Chunked Prefill 显著提升吞吐降低延迟尾部效应运维层面构建从集群到 Token 的四层可观测体系实现问题分钟级定位。展望未来随着 vLLM 对 Speculative Decoding投机采样和 Prefix Caching前缀缓存的支持日趋成熟推理延迟有望再降低 30%-50%。而 KubeRay 与 KubeFlow、KAI Scheduler 的深度集成也将推动训练与推理在统一集群内的无缝混部进一步压缩 AI Infra 的总体拥有成本。参考资料vLLM 官方文档 Kubernetes 部署指南KubeRay 官方文档Pipeline Parallelism 教程《Performance Optimization of LLM-Based Agentic Workloads in Kubernetes Environments》TechRxiv 2025
KubeRay vLLMKubernetes 上的大模型推理服务生产级部署与三级弹性伸缩实战摘要在大模型落地过程中推理服务的稳定性、吞吐量和资源利用率是决定用户体验的核心指标。本文以生产环境实践为基础详细拆解如何基于 KubeRay 与 vLLM 在 Kubernetes 集群上构建高可用的大模型推理平台涵盖 GPU 精细化调度、三级弹性伸缩机制、PagedAttention 内存优化及全链路监控方案力求为 AI Infra 工程师提供一套可直接落地的技术实现路径。一、背景推理服务的生产级痛点随着 LLM大语言模型从实验室走向业务前台推理侧的工程挑战日益尖锐。以笔者所在团队维护的 70B 参数级模型为例上线初期我们遭遇了以下典型问题GPU 显存碎片化严重传统推理框架按请求动态分配显存长序列请求导致 OOMOut of Memory频发显存利用率长期低于 40%。扩容滞后基于 CPU 指标的 HPA 无法感知 GPU 显存压力和 Token 生成延迟流量突增时扩容周期长达 3-5 分钟远超用户容忍度。多模型混部困难不同业务线模型如 7B、13B、70B共存时Kubernetes 默认调度器缺乏对 GPU 拓扑和 MIGMulti-Instance GPU的细粒度感知导致节点负载严重不均衡。这些问题的根源在于Kubernetes 原生的资源调度语义与大模型推理的工作负载特征存在本质错配。vLLM 通过 PagedAttention 解决了显存管理问题而 KubeRay 则为分布式推理提供了 Gang Scheduling 和自动扩缩容能力两者的结合恰好补齐了生产环境的最后一块拼图。二、整体架构KubeRay vLLM 的核心设计2.1 架构全景我们采用的架构分为四层接入层Nginx Ingress Redis 缓存热点 Prompt降低重复请求对后端的压力。调度层KubeRay Operator 管理 RayCluster 生命周期集成 KubeFlow Training Operator 处理训练与推理的混合调度。推理层vLLM 作为推理引擎支持 Tensor ParallelismTP和 Pipeline ParallelismPP通过 Ray Serve 暴露 RESTful API。存储层S3 兼容对象存储存放模型权重配合本地 NVMe SSD 作为二级缓存模型加载时间从 11 分钟压缩至 20 秒。在这套架构中KubeRay 的核心价值在于Gang Scheduling当 vLLM 需要以 TP4 启动一个分布式推理实例时KubeRay 会确保 4 个 GPU Pod 同时被调度到具备高速 NVLink 互联的同一台物理机上避免因部分 Pod Pending 导致的资源死锁。2.2 为什么选 KubeRay 而不是原生 Deployment很多团队初期会直接用 Kubernetes Deployment 部署 vLLM但这会在生产环境埋下隐患对比维度原生 DeploymentKubeRay调度语义逐个调度 PodGang Scheduling全有或全无分布式感知无原生支持 TP/PP 的 GPU 拓扑感知自动扩缩容HPA 基于 CPU/内存Autoscaler 基于 Ray 任务队列深度故障恢复依赖 Pod 重启Ray 级 Actor 重建状态可恢复多租户隔离Namespace 级别Ray Queue 资源组细粒度隔离对于需要跨多卡分布式推理的 70B 模型Gang Scheduling 几乎是必选项。没有它Scheduler 可能将 Worker Pod 分散到不同节点导致 NCCL 通信走慢速网络TPOTTime Per Output Token飙升数倍。三、生产部署实战从 YAML 到 GPU 拓扑感知3.1 RayCluster 资源配置以下是我们生产环境使用的 KubeRay RayCluster 配置已脱敏核心要点包括apiVersion:ray.io/v1kind:RayClustermetadata:name:vllm-70b-inferencenamespace:llm-servingspec:rayVersion:2.32.0headGroupSpec:rayStartParams:dashboard-host:0.0.0.0block:truetemplate:spec:containers:-name:ray-headimage:vllm/vllm-openai:v0.5.4resources:limits:nvidia.com/gpu:1memory:64Gicpu:16env:-name:VLLM_ATTENTION_BACKENDvalue:FLASH_ATTN# FlashAttention 降低显存占用workerGroupSpecs:-groupName:gpu-workersreplicas:2minReplicas:1maxReplicas:6rayStartParams:block:truetemplate:spec:containers:-name:ray-workerimage:vllm/vllm-openai:v0.5.4resources:limits:nvidia.com/gpu:4# 每 Worker 4 张 A100 80Gmemory:512Gicpu:64env:-name:CUDA_VISIBLE_DEVICESvalue:0,1,2,3affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:-labelSelector:matchExpressions:-key:ray.io/node-typeoperator:Invalues:[head]topologyKey:kubernetes.io/hostname# 强制同节点部署关键设计决策解析TP4 PP2 组合70B 模型在 FP16 下约需 140GB 显存单 Worker 4 张 A100 80G 通过 Tensor Parallelism 拆分2 个 Worker 通过 Pipeline Parallelism 接力实现显存与吞吐的最佳平衡。强制同节点亲和性topologyKey: kubernetes.io/hostname确保 Head 与 Worker 落在同一物理机避免跨节点通信瓶颈。FlashAttention 后端相比传统 Attention 实现FlashAttention-2 在序列长度 4K 时可将显存占用降低 30%推理速度提升 1.5-2 倍。3.2 GPU 精细化调度MIG 与拓扑感知在 A100/H100 集群中我们启用了 NVIDIA Device Plugin 的 MIG 策略使得单张物理 GPU 可被切分为多个独立实例。这对于 7B/13B 小模型混部场景至关重要# MIG 配置示例spec:containers:-name:vllm-smallresources:limits:nvidia.com/mig-3g.40gb:1# 申请 1 个 MIG 3g.40gb 实例同时我们为集群部署了 NVIDIA GPU Operator 与 Node Feature DiscoveryNFD在节点上自动标注 GPU 拓扑信息feature.node.kubernetes.io/pci-10de.presenttrue nvidia.com/gpu.productA100-SXM4-80GB nvidia.com/gpu.memory81920 nvidia.com/gpu.topology.p2ptrue # NVLink P2P 互联调度时KubeRay 的 extended resources 插件会优先选择具备nvidia.com/gpu.topology.p2ptrue标签的节点确保 TP 组内 GPU 通过 NVLink 高速互联。四、三级弹性伸缩从被动响应到主动预测生产环境的流量特征往往是突发且不可预测的。我们设计了一套三级弹性伸缩体系将平均扩容响应时间从分钟级压缩至秒级。4.1 第一级HPA 基于自定义 GPU 指标Kubernetes 默认 HPA 只能基于 CPU/内存扩缩无法感知 GPU 显存和 Token 延迟。我们通过 Prometheus Adapter 暴露了 vLLM 的自定义指标# prometheus-adapter 规则customMetrics:-seriesQuery:vllm:gpu_cache_usage_percresources:template:.Resourcename:matches:^(.*)_percas:${1}_ratiometricsQuery:avg(.Series{.LabelMatchers})HPA 配置如下apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:vllm-hpaspec:scaleTargetRef:apiVersion:ray.io/v1kind:RayClustername:vllm-70b-inferenceminReplicas:1maxReplicas:6metrics:-type:Podspods:metric:name:vllm_gpu_cache_usage_ratiotarget:type:AverageValueaverageValue:0.75# GPU KV Cache 利用率超 75% 触发扩容-type:Podspods:metric:name:vllm_time_to_first_token_secondstarget:type:AverageValueaverageValue:800m# TTFT 800ms 触发扩容4.2 第二级KEDA 基于消息队列的事件驱动对于异步批处理场景如文档批量摘要我们使用 KEDA 监听 Redis Stream 的待处理消息数apiVersion:keda.sh/v1alpha1kind:ScaledObjectmetadata:name:vllm-batch-scalerspec:scaleTargetRef:name:vllm-batch-workerstriggers:-type:redis-streamsmetadata:address:redis.llm-serving.svc:6379stream:inference-queueconsumerGroup:vllm-consumerspendingEntriesCount:50# 堆积 50 条即扩容4.3 第三级定时 预测式扩缩容结合业务特征我们在每日 9:00、14:00 等流量高峰前 5 分钟通过 CronJob 预扩容apiVersion:batch/v1kind:CronJobmetadata:name:vllm-precachespec:schedule:55 8,13 * * *# 高峰前 5 分钟jobTemplate:spec:template:spec:containers:-name:scalerimage:bitnami/kubectlcommand:[kubectl,scale,raycluster,vllm-70b-inference,--replicas4]三级伸缩的效果对比基于生产环境 7 天数据指标仅 HPA三级弹性体系P99 TTFT2.3s420ms平均 GPU 利用率38%72%扩容响应时间180s15s闲置资源成本基准降低 41%五、性能调优PagedAttention 与请求调度策略vLLM 的核心创新在于PagedAttention它借鉴操作系统虚拟内存的分页机制将 KV Cache 划分为固定大小的块Block按需分配而非连续预分配。5.1 PagedAttention 内存优化原理传统推理框架为每个请求预分配max_seq_len的连续 KV Cache导致内部碎片实际序列长度远小于 max_seq_len外部碎片请求完成后释放的连续空间难以复用。PagedAttention 将 KV Cache 组织为非连续的 Block Table每个 Block 默认 16 tokens。当序列长度从 512 增长到 4096 时只需追加分配新 Block无需预留连续空间。在我们的生产环境中这一机制使单卡并发请求数从 8 提升至 32显存利用率从 40% 提升至 85%。5.2 请求调度策略对比vLLM 支持多种调度策略需根据业务场景选择策略适用场景特点FCFS先到先服务低延迟对话简单公平但短请求可能被长请求阻塞Shortest Job First多样化长度最小化平均等待时间需预估输出长度Continuous Batching高吞吐服务动态合并新请求到正在运行的 Batch 中吞吐量最高生产环境我们采用Continuous Batching又称 In-flight Batching配合--max-num-seqs256和--max-model-len8192参数在延迟与吞吐之间取得平衡。5.3 关键启动参数调优python-mvllm.entrypoints.openai.api_server\--model/models/Qwen2-72B-Instruct\--tensor-parallel-size4\--pipeline-parallel-size2\--max-num-seqs256\# 最大并发序列数--max-model-len8192\# 最大上下文长度--gpu-memory-utilization0.92\# 显存利用率上限留 8% 缓冲--enable-chunked-prefill\# 大 Prefill 请求分块降低 TTFT--dtypebfloat16# Ampere 架构推荐其中--enable-chunked-prefill是 v0.5.x 引入的关键特性它将长序列的 Prefill 阶段拆分为多个小块执行避免单个长请求阻塞整个 Batch 的 Decode 阶段P99 TTFT 可降低 50% 以上。六、全链路可观测性指标、日志与追踪推理服务的可观测性不能仅停留在服务是否存活必须深入到 Token 级别的延迟分析。6.1 核心监控指标体系我们基于 Prometheus Grafana 构建了四层监控大盘集群层GPU 利用率、显存占用、NVLink 带宽、温度与功耗服务层QPS、P50/P99 TTFT、TPOT、请求成功率引擎层vLLM 的gpu_cache_usage_perc、num_running_reqs、prefill_time_ms业务层首字返回时间、输出 Token 数、用户会话长度分布6.2 分布式追踪通过集成 OpenTelemetry我们将请求从前端 Ingress 到 vLLM 的 Prefill/Decode 阶段全链路串联fromopentelemetryimporttrace tracertrace.get_tracer(vllm.inference)withtracer.start_as_current_span(vllm_generate)asspan:span.set_attribute(model.name,Qwen2-72B)span.set_attribute(input.tokens,len(input_ids))span.set_attribute(tpot.avg_ms,avg_tpot)# 调用 vLLM generate在 Jaeger UI 中可以清晰看到每个请求的 Prefill 耗时、Queue 等待耗时、Decode 逐 Token 耗时为性能瓶颈定位提供精确依据。七、总结与展望本文从生产实践出发系统性地介绍了基于 KubeRay vLLM 构建大模型推理平台的关键技术点架构层面利用 KubeRay 的 Gang Scheduling 解决分布式推理的 Pod 协同调度问题利用 vLLM 的 PagedAttention 突破显存瓶颈调度层面通过 MIG GPU 拓扑感知实现异构模型混部通过三级弹性伸缩应对流量波动性能层面Continuous Batching Chunked Prefill 显著提升吞吐降低延迟尾部效应运维层面构建从集群到 Token 的四层可观测体系实现问题分钟级定位。展望未来随着 vLLM 对 Speculative Decoding投机采样和 Prefix Caching前缀缓存的支持日趋成熟推理延迟有望再降低 30%-50%。而 KubeRay 与 KubeFlow、KAI Scheduler 的深度集成也将推动训练与推理在统一集群内的无缝混部进一步压缩 AI Infra 的总体拥有成本。参考资料vLLM 官方文档 Kubernetes 部署指南KubeRay 官方文档Pipeline Parallelism 教程《Performance Optimization of LLM-Based Agentic Workloads in Kubernetes Environments》TechRxiv 2025
