# llm-d 推理调度器：基于 Kubernetes Gateway API 的大模型推理请求智能路由系统

> 本文介绍 llm-d 推理调度器，一个专为大规模语言模型推理设计的 Kubernetes 原生调度系统。该系统基于 Gateway API Inference Extension (GIE) 构建，通过可插拔的过滤器、评分器和抓取器实现智能路由决策，支持多模型部署、KV 缓存局部性优化和 Prefill/Decode 分离等高级特性。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-04-02T16:12:32.000Z
- 最近活动: 2026-04-02T16:23:54.518Z
- 热度: 145.8
- 关键词: Kubernetes, Gateway API, 大模型推理, 智能路由, KV 缓存, Prefill/Decode 分离, Envoy, 负载均衡, 多模型部署, 云原生
- 页面链接: https://www.zingnex.cn/forum/thread/llm-d-kubernetes-gateway-api
- Canonical: https://www.zingnex.cn/forum/thread/llm-d-kubernetes-gateway-api
- Markdown 来源: ingested_event

---

# llm-d 推理调度器：基于 Kubernetes Gateway API 的大模型推理请求智能路由系统

在大规模语言模型推理服务的生产部署中，如何高效地将用户请求路由到最合适的模型实例，是一个极具挑战性的技术问题。传统的负载均衡策略往往无法充分利用大模型推理的特性，如 KV 缓存复用、Prefill/Decode 阶段分离、异构硬件支持等。llm-d 推理调度器项目针对这些挑战，基于 Kubernetes Gateway API 构建了一套可扩展的智能路由系统，为生产级 LLM 推理服务提供了企业级的调度能力。

## 项目背景与核心目标

llm-d 是一个专为大规模语言模型推理设计的可扩展架构，其核心组件是推理网关（Inference Gateway）。该项目构建在 Kubernetes 原生的 Gateway API Inference Extension (GIE) 之上，旨在实现以下核心目标：

- **智能路由**：基于基础模型兼容性、KV 缓存复用、负载均衡等多维度因素，将推理请求调度到最优 Pod
- **多模型支持**：在同一集群内支持多种基础模型的并行部署
- **异构硬件适配**：支持在不同类型硬件（GPU、TPU 等）上部署不同模型
- **运行时可扩展**：通过可插拔的过滤器、评分器和抓取器实现自定义调度逻辑
- **社区对齐**：与 GIE 和 Envoy 生态紧密集成，遵循云原生标准

## 架构设计：Envoy + EPP 双层架构

llm-d 推理调度器采用经典的数据平面/控制平面分离架构：

### 数据平面：Envoy 网关

Envoy 作为可编程的数据平面，负责接收所有推理请求并执行最终的路由决策。Envoy 通过 External Processing (ext-proc) 机制与控制平面通信，在请求处理的关键节点获取调度决策。这种设计允许在不影响数据路径性能的情况下，实现复杂的调度逻辑。

### 控制平面：EPP（Endpoint Picker）

EPP 是 llm-d 推理调度器的核心组件，负责实际的调度决策。它扩展了 GIE 项目中的 EPP 实现，添加了 llm-d 特有的功能，如 Prefill/Decode (P/D) 分离支持。EPP 通过 Envoy 的 ext-proc 回调机制介入请求处理流程，根据配置的调度策略选择最优的目标 Pod。

### 可选组件：BBR（Body Based Routing）

BBR 组件用于在请求到达 EPP 之前，根据请求体内容识别目标模型。这对于多模型部署场景尤为重要，可以在调度决策之前确定请求应该路由到哪个 InferencePool。

## 核心调度机制：过滤器、评分器与抓取器

llm-d 推理调度器的路由决策由三类可插拔组件协同完成：

### 过滤器（Filters）

过滤器用于排除不符合条件的 Pod。所有 Pod 按顺序通过过滤器链，任一过滤器都可以将某个 Pod 从候选列表中移除。常见的过滤条件包括：

- **模型兼容性过滤**：排除未加载目标模型的 Pod
- **资源使用过滤**：排除资源使用率过高的 Pod
- **健康状态过滤**：排除未通过健康检查的 Pod
- **自定义逻辑过滤**：用户可扩展的自定义过滤规则

### 评分器（Scorers）

评分器为通过过滤的候选 Pod 打分。多个评分器可以按权重组合，最终得分最高的 Pod 被选中。llm-d 实现了多种评分策略：

- **KV 缓存局部性评分**：优先选择具有相关 KV 缓存的 Pod，减少重复计算
- **会话亲和性评分**：优先选择处理过同一用户会话的 Pod
- **负载均衡评分**：考虑当前负载情况，避免热点
- **模型元数据评分**：基于模型版本、量化精度等元数据评分

### 抓取器（Scrapers）

抓取器负责收集 Pod 的元数据和运行时指标，为评分器提供决策依据。抓取器持续监控集群状态，维护一个共享的数据存储，供评分器查询。

## 调度流程详解

当一个推理请求到达时，llm-d 推理调度器执行以下流程：

### 阶段 1：请求识别

BBR 组件（如启用）解析请求体，识别目标模型和 InferencePool。这一步骤确保请求被路由到正确的基础模型实例组。

### 阶段 2：候选 Pod 过滤

EPP 获取目标 InferencePool 中的所有 Pod，依次通过配置的过滤器链：

1. 模型兼容性检查：排除未加载目标模型的 Pod
2. 资源容量检查：排除资源不足的 Pod
3. 健康状态检查：排除不健康的 Pod
4. 自定义过滤：执行用户定义的过滤逻辑

### 阶段 3：候选 Pod 评分

通过过滤的 Pod 进入评分阶段。每个评分器独立计算得分，然后按权重加权求和：

```
总得分 = Σ(评分器得分 × 评分器权重)
```

评分器可以访问抓取器维护的共享数据存储，获取 Pod 的实时状态和历史指标。

### 阶段 4：Pod 选择与路由

得分最高的 Pod 被选中。如果多个 Pod 得分相同，则随机选择其中一个。EPP 将选择结果返回给 Envoy，Envoy 将请求路由到选定的 Pod。

## 高级特性：Prefill/Decode 分离

llm-d 推理调度器的一个核心创新是支持 Prefill/Decode (P/D) 分离，这是大模型推理优化的重要技术。

### P/D 分离原理

大模型推理包含两个计算特性截然不同的阶段：

- **Prefill 阶段**：处理输入提示（prompt），计算量大但并行度高，对带宽敏感
- **Decode 阶段**：生成输出 token，计算量小但依赖 KV 缓存，对延迟敏感

传统架构将两个阶段在同一 Pod 上执行，导致资源利用不均衡。P/D 分离允许将两个阶段调度到专门优化的 Pod 上执行。

### 实验性 E/P/D 分离

llm-d 进一步实验性地支持 Encode/Prefill/Decode (E/P/D) 三阶段分离，以及这些阶段的各种排列组合。这种细粒度的分离允许更灵活的资源分配和优化策略。

## 可插拔架构与扩展性

llm-d 推理调度器的设计强调可扩展性，所有核心组件都支持自定义扩展：

### 插件生命周期钩子

调度器在以下生命周期节点支持插件介入：

- **Pre-call**：请求到达时，可用于前置过滤或预处理
- **Scoring**：评分阶段，自定义评分逻辑
- **Post-choice**：Pod 选择后，可用于后处理或记录
- **After-response**：响应返回后，可用于指标收集或反馈

### 配置驱动的插件系统

所有插件通过 YAML 配置启用和参数化：

```yaml
apiVersion: inference.networking.x-k8s.io/v1alpha1
kind: EndpointPickerConfig
plugins:
  - name: kvCacheScorer
    type: kv-cache-locality
    parameters:
      weight: 0.5
      historyWindow: 100
  - name: loadBalancer
    type: least-loaded
    parameters:
      weight: 0.3
schedulingProfiles:
  - name: default
    plugins:
      - kvCacheScorer
      - loadBalancer
```

这种配置驱动的方式允许运维人员在不停机的情况下调整调度策略。

## 与 GIE 的关系与协作

llm-d 推理调度器与 Gateway API Inference Extension (GIE) 项目紧密协作：

- GIE 提供 API 资源和基础调度机制
- llm-d 在 GIE 基础上添加特定功能，如 P/D 分离
- 通用功能优先上游到 GIE，llm-d 特有功能保留在本地
- 两个项目共享社区会议和 Slack 频道，保持技术对齐

这种分层设计确保了 llm-d 可以专注于创新功能，同时受益于 GIE 生态的成熟度和广泛支持。

## 技术栈与依赖

llm-d 推理调度器的技术栈完全基于云原生标准：

- **编程语言**：Go（与 Kubernetes 生态一致）
- **网关**：Envoy（支持 ext-proc）
- **编排平台**：Kubernetes
- **API 标准**：Gateway API
- **扩展机制**：External Processing (ext-proc)

这种技术选择确保了与现有云原生基础设施的兼容性，降低了采用门槛。

## 应用场景与价值

llm-d 推理调度器适用于以下场景：

- **多模型服务**：在同一集群中服务多个基础模型，根据请求内容智能路由
- **高吞吐量推理**：通过 KV 缓存局部性优化，显著提升吞吐量
- **异构硬件部署**：在不同硬件类型上部署不同模型，统一调度
- **成本优化**：通过负载均衡和资源感知调度，最大化硬件利用率
- **生产级可靠性**：基于 Kubernetes 的成熟生态，提供企业级可靠性

通过将大模型推理的特有需求（KV 缓存、P/D 分离、会话亲和性）与 Kubernetes Gateway API 的标准能力相结合，llm-d 推理调度器为生产级 LLM 服务提供了一个功能强大、可扩展、云原生的调度解决方案。