“大模型”技术专栏 | 浅谈基于 Kubernetes 的 LLM 分布式推理框架架构：概览

编者按：

人工智能正以前所未有的渗透力重塑生产与生活图景。作为国内领先的数据智能科技企业，和鲸科技自 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 的数量，即端到端的吞吐量。

• Req