编者按：
人工智能正以前所未有的渗透力重塑生产与生活图景。作为国内领先的数据智能科技企业，和鲸科技自 2015 年成立以来，深耕人工智能与数据科学，历经十年发展，已在气象、教育、医疗、航空航天、金融、通信、能源、零售等领域，与众多高校、科研机构、企业等单位展开了深度合作。
大模型技术正掀起新一轮产业变革浪潮。在此背景下，和鲸科技资深架构工程师郑宇宸基于工作中的丰富经验，带来基于 Kubernetes 的 LLM 分布式推理框架架构分享。
随着大语言模型（LLM）在生产环境中的广泛应用，高效的推理部署已成为业界面临的核心挑战。为了应对这一挑战，工业界和学术界正在积极探索多种优化方案，包括：
多维度并行技术：数据并行（Data Parallelism）、张量并行（Tensor Parallelism）、流水线并行（Pipeline Parallelism）、专家并行（Expert Parallelism）等
批处理优化：连续批处理（Continuous Batching）
这些技术都对 LLM 的推理性能有着显著的优化。然而，随着模型规模的持续增长和应用场景的复杂化，传统的单机部署方式已经无法适用，特别是像 DeepSeek V3/R1 与 Kimi K2 等大规模 MoE（Mixture of Experts）模型的出现，其对计算资源的需求已经超出了单机的承载能力，对 LLM 的推理提出新的挑战。
本文将会围绕基于 Kubernetes 的大语言模型分布式推理框架架构进行介绍，包括目前 Kubernetes 社区主流的分布式推理解决方案以及其集成的学术界的相关工作，旨在分享目前基于 Kubernetes 的主流解决方案所解决的问题以及未来可能的发展方向。需要注意的是，本文主要关注集群编排层面的架构设计，不涉及 vLLM 与 SGLang 等推理引擎内部的具体优化实现。
背 景
在介绍基于 Kubernetes 的 LLM 分布式推理框架之前，我们需要对 LLM 的推理过程有初步的了解。
LLM 的推理
基于 Transformer 的 LLM 的推理主要分为两个阶段，Prefill 与 Decode。
Prefill：Prefill 阶段是推理过程的第一步，其核心任务是处理用户输入的 Prompt。在这个阶段，模型会并行处理输入提示中的所有 Token，一次性计算出整个输入序列的 Attention 状态 。这个过程会生成一组关键的中间结果，即 Key 与 Value，并将它们存储在 KV Cache 中 。由于 Prefill 阶段涉及对整个输入序列进行大量的矩阵乘法运算，它是一个计算密集型（Compute-bound）的过程 。
Decode：当 Prefill 阶段完成并生成初始的 KV Cache 后，模型便进入 Decode 阶段，开始逐个生成输出 Token 。这是一个自回归（Auto-regressive）的过程，即每生成一个新的 Token，都需要将其作为输入，与之前的所有上下文（包括原始 Prompt 和已生成的 Token）一同来预测下一个 Token。与 Prefill 不同，Decode 阶段是串行的，无法并行处理 。在生成每个 Token 时，主要的性能瓶颈在于从 HBM 中加载和读取庞大的模型权重参数，因此这是一个访存密集型（Memory-bound）的过程 。
LLM 推理的关键指标
本节介绍了一些在讨论 LLM 的推理的时候会提及的关键指标，这些关键指标是优化 LLM 推理性能的基准，通过它们才能够衡量在不同场景之下 LLM 推理优化的目标。
Time to First Token (TTFT)
请求到达之后生成第一个 Token 所需要的时间，是衡量 Prefill 阶段的性能的指标。
Time Per Output Token (TPOT)
平均生成一个输出 Token 所需要的时间，是衡量 Decode 阶段的性能的指标。
Latency (E2E Latency)
端到端的延迟。
latency = TTFT + TPOT x number of tokens
Throughput (Tokens Per Second)
单位时间内生成的 Token 的数量，即端到端的吞吐量。
Requests per second (RPS)
单位时间内成功的请求个数。
除了前述的几个常见的指标以外，还有一些额外的指标，如：
Normalized Time Per Output Token (NTPOT)：归一化的 TPOT，其计算方式为 NTPOP = latency / number of tokens。
Inter-Token Latency（ITL）：两个 Token 生成之间的延迟，与 TPOP 的不同之处在于其测量的是生成 Token 之间的时间的离散值。
回顾：在 Kubernetes 上单机部署 LLM
上图是在 Kubernetes 集群中部署基于 vLLM 单机推理服务的常见解决方案，采用的是基于 KEDA（Pod 自动扩缩容）与 Karpenter（节点自动扩缩容）的自动扩缩容，由 Gateway 在网关层面进行路由与负载均衡，是当时部署 LLM 的主流解决方案。当时的模型只需要单机多卡就能满足推理的需要，而基于 vLLM 与 Ray 的多机多卡部署由于网络基础设施的异同与限制会对 Decode 阶段张量并行的性能造成显著的下降（如在 10Gbps 的以太网的基础上网络带宽会成为性能瓶颈），因此采用前述的方案其实是相对合理的选择，可以利用多个维度的自动扩缩容机制根据流量对部署的规模进行控制，以得到更好的推理性能。
然而，随着 DeepSeek V3/R1 与 Kimi K2 等 MoE 架构的模型的横空出世，前述的这种部署架构就面临了挑战，而更大参数量与上下文的模型以及更复杂的使用场景使得单机的 GPU 部署方式无法再适用，因为节点内卡间的通信以及跨节点的通信（根据网络拓扑的不同）在不同的并行方式下都会引入难以忽略的延迟，对多个关键指标都会造成显著的降级，从而影响推理服务的质量。
因此，工程师们才会着眼于分布式推理，基于 Kubernetes 的分布式推理解决方案在 2024 年末至今得到了高速的发展，各大公司都在社区开源了自己所提出的解决方案，如何利用集群编排的能力使得下层的推理框架得到更好的性能，如服务质量的提升，以及成本的降低等，都是分布式推理框架所需要达成的目标。下文将会对基于 Kubernetes 的 LLM 分布式推理框架进行整体的介绍，以及这些框架如何将工业界的经验与学术界的成果互相有机结合，实现更加高效的 LLM 推理。
基于 Kubernetes 的 LLM 分布式推理框架
目前，开源社区当中基于 Kubernetes 的 LLM 分布式推理框架或解决方案主要有以下几个：
AIBrix (ByteDance)
Dynamo (NVIDIA)
llm-d (Red Hat / Google / IBM)
OME (SGLang / Oracle)
虽然前述项目都是由不同公司主导，但是它们的关注点是相似的，上图展示了较为通用的基于 LLM 的分布式推理框架的概览，主要由以下几个组件构成：
AI Gateway：提供兼容 OpenAI API 的接口的 API Server，以及负责调度请求的 Router
Inference Pool：负责工作负载的部署
Autoscaler：负责工作负载节点的自动扩缩容。
目前基于 Kubernetes 的分布式推理框架主要关注在以下几个主题，下文将会分别进行介绍：
PD 分离
负载均衡
KV Cache 管理
自动扩缩容
PD 分离
如同前文所提及的，LLM 的推理分为两个阶段，其中 Prefill 是计算密集型，Decode 是访存密集型，两者对资源的需求是完全不同的。一般而言，LLM 推理引擎都会采用 Continuous Batching 的方式聚合多个请求再进行处理，这就会造成严重的资源冲突与效率瓶颈，即执行计算密集的 Prefill 任务时，系统无法同时满足 Decode 任务对内存带宽的高频需求，另一方面，执行访存密集的 Decode 任务时，大量计算资源处于闲置状态。此外，这种混合执行的模式还会导致阻塞，即一个计算量大的 Prefill 请求会阻塞后面许多本可以快速完成的 Decode 步骤，从而增加了其他用户的等待延迟，使得 Continuous Batching 的优势无法充分发挥。
PD 分离（Prefill-Decode Disaggregation）正是为解决上述问题而提出的架构优化方案，该技术最初由学术界的 Splitwise 和 DistServe 等研究工作提出，核心思想是将 Prefill 和 Decode 阶段物理分离，在不同的工作节点上分别运行，根据彼此的资源使用特性分别调整两类服务的资源配置，从而实现不同关键指标的优化，同时还能避免两个阶段的作业的相互干扰。此外，在特定的工作场景下，甚至可以采用异构的硬件资源分别运行 Prefill 与 Decode 作业，更好地利用不同计算资源的能力。
然而， PD 分离并不是万能的策略，在 PD 分离的架构下，Prefill 阶段的 KV Cache 需要被传输到 Decode 阶段，这就引入了额外的数据传输开销，考虑到 KV Cache 的大小，频繁地在不同服务之间传输数据可能会带来显著的延迟，甚至可能抵消掉 PD 分离带来的性能提升。此外，PD 分离还需要额外的编排与调度逻辑来管理 Prefill 和 Decode 服务之间的协作，以及服务间的 KV Cache 的管理，这会显著增加系统的复杂性。因此，PD 分离会更加适合于大规模部署的推理场景，尤其是在请求足够异构（即请求的模式以及资源需求差异化较大）的情况下，会带来更佳的收益，而在如具身智能等边缘场景可能引入的收益有限，甚至可能产生负面的影响。目前，AIBrix、Dynamo 与 llm-d 等项目都基于不同实现提供了基于推理引擎的 PD 分离的支持。
路由与负载均衡
在分布式推理场景下，Gateway 需要将用户请求转发到特定的实例上，这些实例是运行在不同 GPU 或服务器节点上的模型副本。然而，LLM 的负载均衡要比传统的无状态服务更加复杂，其核心挑战源于推理过程本身的状态性和异构性。LLM 推理的核心是 KV Cache，其存储了模型在 Prefill 阶段计算出的 Key 和 Value。由于不同请求的 Prompt 可能存在重叠的前缀，这些共享的前缀信息可以被多个请求复用，从而显著提升推理效率。因此，在负载均衡时需要考虑如何高效地利用这些缓存，而不是简单地将请求随机分配到不同的实例上。Dynamo 与 AIBrix 等项目都通过插件化的方式扩展了负载均衡的功能，支持在网关层面进行多种负载均衡算法的灵活配置。
Prefix-Aware
Prefix Caching 是一种能够缓存并复用请求前缀部分 KV Cache 的技术。当多个请求共享相同的前缀时，系统可以避免重复计算，直接复用已缓存的 Key 和 Value，从而显著降低 TTFT 并提升整体吞吐量。vLLM 和 SGLang 等推理引擎都实现了 Prefix Caching 功能。在分布式推理环境中，Prefix-Aware 负载均衡策略会优先将具有相似前缀的请求路由到同一个实例，以最大化缓存的命中率。这种策略需要负载均衡器维护每个实例的缓存状态信息，并根据请求的前缀特征进行路由。
Fairness
LLM 实例的公平调度也是负载均衡的一个重要方面，尤其是在多租户环境中，公平性确保了所有用户都能获得相对一致的服务质量，而不会因为某些实例过载而导致其他用户的请求延迟。
AIBrix 基于 Sheng et al. 实现了 Virtual Token Counter (VTC) 的 Fair Queuing 调度策略。VTC 为每个客户端维护一个虚拟 Token 计数器，通过跟踪每个客户端已接受的服务量来实现公平调度，优先服务计数器值最小的客户端。
Example: Ray Serve LLM
Source: https://github.com/ray-project/ray/blob/master/python/ray/llm/_internal/serve/request_router/prefix_aware/prefix_aware_router.py
The Power of Two Choices 是负载均衡领域很经典的算法，其主要思想相当简单，即在所有的可选项中随机选择两个，再根据某种标准选择更好的那个（在负载均衡场景下即为负载更小的那个），从数学期望的角度理解的话，这个算法可将最坏的情况由
降低到
。
Ray Serve LLM 目前的实现将 Power of Two Choices 与 Prefix-Aware 进行结合：
当负载均衡（即 Queue 之间的差异小于一定阈值）时，它会选择与输入的前缀匹配度最高的实例；
当负载均衡当时匹配度低于 10% 时，它会选择负载最小的实例；
当负载不均衡时，它会使用 Power of Two Choices 进行选择。
这种混合的负载均衡策略可以在保证 KV Cache 的有效利用的同时，尽可能地平衡不同实例之间的负载，从而提高整体的推理性能。
KV Cache 管理
如同前文所述，KV Cache 是被设计来在自回归的过程中缓存前序 Token 计算出来的 Key 与 Value 的值，它们会被保存在显存中供后续的步骤使用。通过 KV Cache，在推理的过程中就不需要重复计算前序的 Token 的 KV 值，从而能够显著加快推理的过程。然而，随着上下文长度的增加，KV Cache 的大小也会随之线性增长，尤其是在大规模推理的场景之下，GPU 的显存很快就会被消耗殆尽从而导致推理服务无法利用 KV Cache 能力，成为推理过程当中的瓶颈。
KV Cache Offloading
KV Cache Offloading 指的是将 GPU 显存中的 KV Cache 卸载到 CPU 内存或是外部存储的过程，其提出就是为了解决前述的 KV Cache 占用 GPU 显存的问题，当 LLM 需要访问被卸载的 KV Cache 时，它会按需将这些 Block 重新加载回 GPU 显存中。AIBrix 提供了多层 KV Cache 的缓存框架，默认情况下会使用 DRAM 中的 L1 Cache，在需要共享 KV Cache 的场景下则可以使用 L2 Cache，即分布式的外部存储。Dynamo 与 llm-d 等框架同样也支持使用 LMCache 等框架将不常用的 KV Cache 卸载到 CPU 内存与外部存储中。
KV Cache Sharing
随着 KV Cache Offloading 的引入，如何在不同的 LLM 推理实例共享 KV Cache 也是个被广泛研究的问题。
Centralized：即通过一个中心化的 KV Cache 的池来管理不同实例的 KV Cache，其优点在于能够最大化地共享 KV Cache，可以更好地利用 Prefix Caching 的能力，但是在高并发的场景之下其可能会成为单点的性能瓶颈。
Peer-to-Peer：即直接通过 P2P 通信机制在不同实例间传输 KV Cache，避免了中心化的存储，且具有更好的容错与动态扩缩容的能力的支持。
自动扩缩容
目前 Kubernetes 的生态系统中被广泛使用的自动扩缩容工具主要有以下三个：
HPA（Horizontal Pod Autoscaler）：Kubernetes 的水平扩缩器
KPA（Knative Pod Autoscaler）：Knative 的水平扩缩器
KEDA（Kubernetes Event-driven Autoscaling）：事件驱动的服务扩缩器，支持服务的从零到一部署
而针对 LLM 推理服务的自动扩缩容，其关键在于如何决定触发自动扩缩容的指标。AIBrix 的演讲者在 vLLM Meetup Beijing 分享了与传统的微服务的自动扩缩容不同，LLM 推理请求的 QPS 可能与产生的延迟并不是正相关的，且 SM Active 等 GPU 指标也不一定能及时反映出指标的变化。因此，如何基于 LLM 推理的特性来进行可靠的自动扩缩容仍然是需要探索的问题。长期来看，笔者认为 LLM 推理服务的自动扩缩容也有可能会由 Reactive 逐渐发展到 Proactive 甚至是 Predictive 的形态（如时间序列分析与基于强化学习的预测）。
讨 论
推理引擎
笔者在 2023 年末的时候就开始使用 vLLM 部署 LLM，在当时主流的几个推理框架当中，基于 PagedAttenton 的 vLLM 无论从性能上还是易用性的角度来看都是属于前列的，当时同期的一些推理引擎如 Microsoft 的 DeepSpeed-MII 与 NVIDIA 的 TensorRT-LLM 都不是其竞争对手。直到随后同样来自 UCB 的 Sky Computing Lab 所开源的基于 RadixAttention 的 SGLang 的出现才让 vLLM 的垄断地位受到了挑战，当前 vLLM 与 SGLang 两者社区的发展都相当迅速。
AIBrix 与 llm-d 等项目都将 vLLM 作为首个接入的推理，Dynamo 在前两者之上又兼容了 NVIDIA 自身的 TersorRT-LLM，而 OME 作为 SGLang 社区开源的框架对 SGLang 提供了第一方的支持。在编排侧的一些框架会选择兼容更多种类的底层推理引擎，如使用 LWS 来作为有状态服务的抽象（如 llm-d 与 OME）。LWS 是 Kubernetes SIGs 所提出的用于封装主从 StatefulSet 的抽象，它为在 Kubernetes 上运行像 LLM 推理这样的复杂有状态应用提供了标准化的范式。
基于 Kubernetes 的分布式推理
由目前 AIBrix 与 llm-d 等框架的设计上来看，将负载均衡与 KV Cache 管理等功能由推理引擎的层面上升到集群编排的层面去解决是目前的主流趋势，编排侧能够更好地与现有的集群资源管理系统（如 Kubernetes）的生态系统集成，避免一些重复性的工作，推理引擎也可以关注在内部的推理过程优化，只需要暴露一些特定的抽象与接口供编排侧对接。
另一方面，随着 LLM 的兴起，很多早年专注于传统 MLOps 生态的 Kubernetes 生态的项目都在尝试向 LLM 生态靠拢，比如 Kubeflow 的子项目 Trainer（Training Operator）与 KServe 目前新的版本都在引入第一方的 LLM 支持，尝试往 LLMOps 靠拢，这对平台侧用户而言可以以更小的成本由 MLOps 向 LLMOps 转型，能更加便利地与 LLM 的生态系统集成。近期，SGLang 社区也开源了与 Oracle 合作的 OME，除了推理服务的集成，OME 也关注在模型管理的能力。此外，除了 Kubernetes 生态系统以外，Ray 近期也基于 Ray Data 与 Ray Serve 与提供对 LLM 相关功能的第一方支持。
从分布式推理到分离式推理
除了前文所提及的 PD 分离以及 KV Cache 管理之外，目前基于基础设施层的分离式推理（Disaggregated Inference）也是被广泛讨论的话题，即模块化地拆分推理的各个模块形成分离式的部署，彼此之间通过协议传输数据。目前学术界与工业界的相关工作如下所示，展示了未来大规模推理的基础设施可能的发展方向：
Prefill / Decode Disaggregation
Splitwise: Efficient generative LLM inference using phase splitting, https://arxiv.org/abs/2311.18677
DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving, https://arxiv.org/abs/2401.09670
Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving, https://arxiv.org/abs/2407.00079
MoE Attention / FFN Disaggregation
MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism, https://arxiv.org/abs/2504.02263
Step-3 is Large yet Affordable: Model-system Co-design for Cost-effective Decoding, https://arxiv.org/abs/2507.19427
MM Encode Disaggregation
Efficiently Serving Large Multimodal Models Using EPD Disaggregation, https://arxiv.org/abs/2501.05460
结 语
基于 Kubernetes 的分布式推理框架目前仍处于百家争鸣的阶段，各个公司也都分别提出了各自的解决方案，如字节跳动的 AIBrix，Red Hat、Google 与 IBM 的 llm-d，以及 NVIDIA 的 Dynamo 等。这些公司也都积极与包括 vLLM 与 SGLang 在内的推理引擎的社区紧密合作，期望推理引擎提供必要的接口与抽象供上层的编排框架使用，以期能够更加方便地与推理引擎集成，从而能以更低的成本得到更好的推理性能并提高部署的性价比。
分布式推理框架也在不断吸收学术界所提出的解决方案，集成了如 PD 分离、LLM 特有的负载均衡策略以及更加动态的 KV Cache 管理等功能，学术界与工业界的紧密合作笔者认为是在未来一段时间内在该领域的常态，也因此负责推理的工程师更加需要关注前沿的学术成果与开源社区的动态，才能根据自身的使用场景与使用需求提出更好的解决方案。
参 考
NVIDIA. A Comprehensive Guide to NIM LLM Latency-Throughput Benchmarking
Austin et al. All About Transformer Inference | How To Scale Your Model, Google DeepMind. (2025)
Bo Jiang and Sherlock Xu. The Shift to Distributed LLM Inference: 3 Key Technologies Breaking Single-Node Bottlenecks (2025)
Fog Dong and Sherlock Xu. 25x Faster Cold Starts for LLMs on Kubernetes (2025)
Yu et al. Orca: A Distributed Serving System for Transformer-Based Generative Models, OSDI 2022. https://www.usenix.org/conference/osdi22/presentation/yu
Patel et al. Splitwise: Efficient Generative LLM Inference Using Phase Splitting. arXiv:2311.18677 (2024)
Zhong et. al. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving, OSDI 2024. https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin
QIn et al. Mooncake: Trading More Storage for Less Computation — A KV Cache-centric Architecture for Serving LLM Chatbot, FAST 2025, https://www.usenix.org/conference/fast25/presentation/qin
Qin et al. Mooncake: A KV Cache-centric Disaggregated Architecture for LLM Serving. arXiv:2407.00079 (2024)
Sheng et al. Fairness in Serving Large Language Models, OSDI 2024. https://www.usenix.org/conference/osdi24/presentation/sheng
Liu et al. CacheGen: KV Cache Compression and Streaming for Fast Large Language Model Serving. SIGCOMM 2024. 10.1145/3651890.3672274
Yao et al. CacheBlend: Fast Large Language Model Serving for RAG with Cached Knowledge Fusion. EuroSys 2025. 10.1145/3689031.3696098
Srivatsa et al. Preble: Efficient Distributed Prompt Scheduling for LLM Serving. ICLR 2025. arXiv:2407.00023
Lou et al. Towards Swift Serverless LLM Cold Starts with ParaServe. arXiv:2502.15524v1 (2025)
Zhu et al. MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism. arxiv:2504.02263 (2025)
Wang et al. Step-3 is Large yet Affordable: Model-system Co-design for Cost-effective Decoding. arxiv:2507.19427 (2025)
Singl et al. Efficiently Serving Large Multimodal Models Using EPD Disaggregation. arxiv:2501.05460 (2024)
Zhu et al. PolyServe: Efficient Multi-SLO Serving at Scale. arxiv:2507.17769 (2025)
Prefix Caching 详解：实现 KV Cache 的跨请求高效复用 | Se7en的架构笔记 (2025)
Ce Gao. 在 Kubernetes 中 Autoscale LLM 的实践 (2024)
AIBrix 团队. AIBrix v0.3.0 发布：KVCache 多级卸载、前缀缓存、公平路由与基准测试工具 (2025)
BentoML. LLM Inference Handbook (2025)
[PUBLIC] llm-d Autoscaling Northstar - Google 文档
[PUBLIC] llm-d Disaggregated Serving Northstar - Google 文档