使用基于预测延迟的路由与 GKE Inference Gateway

本文档介绍了如何在 GKE Inference Gateway 中启用和使用 llm-d 提供的基于预测延迟时间的路由。默认情况下，GKE Inference Gateway 会结合使用负载信号和前缀缓存亲和性启发法来路由请求。基于预测延迟时间的路由会使用在实时流量上持续训练的 XGBoost 模型来取代静态启发式权重，从而在工作负载模式发生变化时做出更准确的路由决策。

何时使用基于预测延迟时间的路由

如果您的工作负载符合以下条件，则此功能最为有效：

• 提示和补全长度差异较大：当请求大小差异很大时，仅队列深度无法很好地反映服务器负载。延迟时间预测器会考虑每个请求的实际预填充和解码费用。
• 按请求延迟时间 SLO：当应用在单个请求中指定首 token 延迟时间 (TTFT) 或每个输出 token 的时间 (TPOT) 目标时，调度程序会在路由期间强制执行这些目标。为此，它会计算每个候选 Pod 的提升空间（预测延迟时间减去 SLO 目标值）。
• 脆弱的静态权重调整：如果流量模式发生变化，您需要频繁重新调整缓存亲和性和负载信号之间的平衡，那么在线训练的模型会自动适应。

基于预测延迟时间的路由的工作原理

本部分详细介绍了基于预测延迟时间的路由所使用的架构和调度流水线。

架构

基于预测延迟时间的调度会在 EPP Pod 内部署两个额外的边车容器，与 EPP 本身并排：

llm-d EPP 调度流水线

启用基于预测延迟时间的调度后，EPP 会通过以下可组合插件序列处理每个请求：

1. predicted-latency-producer：调用预测服务器，以获取 InferencePool 中每个候选 Pod 的 TTFT 和 TPOT 估计值，这些估计值以每个 Pod 当前的 KV 缓存利用率、队列深度、前缀缓存匹配得分和传入的请求特征为条件。在将响应返回给客户端后，生产者会将观测到的 TTFT 和令牌间延迟时间作为新的训练样本发送回训练服务器。

   • 回退行为：如果预测服务器无法访问或返回错误，EPP 会自动回退到基于 KV 缓存利用率、队列深度和前缀缓存匹配的综合得分。

2. prefix-cache-affinity-filter：当任何 Pod 的前缀缓存匹配得分超过亲和性阈值（默认值为 0.80）时，此过滤条件会将候选集缩小到缓存预热 Pod。此阈值用于区分生产环境中观察到的两个群体：已缓存之前轮次的对话历史记录的 Pod 和未缓存的 Pod。此过滤条件实现了 epsilon-greedy 探索和利用策略：

   • 探索（默认路径）：此路径会路由到缓存预热的 Pod，以便评分将缓存重用集中在这些 Pod 上。

   • 探索（小概率）：此路径会绕过过滤器，在可配置比例的请求中播种冷 Pod 上的缓存条目，以防止缓存碎片化。

   • TTFT 加载门：即使在利用路径上，如果最佳缓存预热 Pod 的预测 TTFT 比最佳总体 Pod 的 TTFT 高出可配置的阈值（默认值为 5,000 毫秒），则会打破亲和性并使用完整的候选集。

3. slo-headroom-tier-filter（仅限 SLO 请求）：当请求包含 SLO 标头时，将候选 Pod 分为正层级（预计可满足 SLO）和负层级（预计会违反 SLO）。

4. latency-scorer：对候选 Pod 进行评分。如果没有 SLO 标头，系统会选择预测延迟时间最短的 Pod。使用 SLO 标头时，得分基于提升空间（SLO 减去预测延迟时间），使用 headroomSelectionStrategy：

   • least（默认）：箱装。路由到具有最小正余量的 Pod，从而最大限度地提高利用率，并使负载较小的 Pod 能够应对未来的流量突增。
   • most：价差。路由到具有最正向裕度的 Pod，为意外的负载峰值留出更多裕度。

5. latency-slo-admitter（仅限 SLO 请求）：当没有候选 Pod 预计能满足 SLO 时，拒绝可舍弃的请求（优先级低于 0），而不是在预计无法达到目标的请求上消耗容量。如果缺少 SLO 标头或存在满足 SLO 的 Pod，则此过滤条件不会产生任何影响。

6. weighted-random-picker：使用基于得分的加权随机选择来选择最终 Pod。这样可以在分散负载的同时，优先选择得分较高的 Pod。

流处理模式

predicted-latency-producer 插件支持两种训练模式，可使用 streamingMode 参数进行配置：

• streamingMode: false（默认）：根据端到端 (E2E) 请求延迟时间进行训练。 如果您的工作负载混合了流式响应和非流式响应，或者您只需要延迟感知型路由，而无需强制执行每个请求的 SLO，请使用此模式。
• streamingMode: true：训练单独的 TTFT 和 TPOT 模型。TTFT 记录在第一个流式传输的块中；TPOT 在后续 token 中进行抽样。如果您的工作负载完全是流式工作负载，并且您需要有意义的 x-slo-ttft-ms / x-slo-tpot-ms 强制执行，请使用此模式。

准备工作

在开始之前，请确保您已执行以下任务：

• 启用 Google Kubernetes Engine API。
启用 Google Kubernetes Engine API
• 如果您要使用 Google Cloud CLI 执行此任务，请安装并初始化 gcloud CLI。如果您之前安装了 gcloud CLI，请通过运行 gcloud components update 命令来获取最新版本。较早版本的 gcloud CLI 可能不支持运行本文档中的命令。

• 根据需要启用 Compute Engine API、Network Services API 和 Model Armor API。

  前往启用对 API 的访问，然后按照说明操作。

• 确保您已部署正常运行的 GKE Inference Gateway。请参阅部署 GKE 推理网关。

• 确保 InferencePool 使用一组同类 Pod，即 GPU 类型、模型权重和服务配置完全相同。

• 确保您的 GKE 集群版本为 1.32.3 或更高版本。

• 安装 Helm。请参阅 Helm 安装指南。

启用基于预测延迟时间的调度

以下步骤将引导您为 GKE Inference Gateway 部署启用基于预测延迟时间的调度。

第 1 步：安装或升级已启用预测延迟时间的 InferencePool

latencyPredictor.enabled=true 标志会在 EPP Pod 内部署训练服务器和预测服务器边车，并连接完整的调度插件流水线：

helm upgrade --install INFERENCE_POOL_NAME \
  --set inferencePool.modelServers.matchLabels.app=MODEL_SERVER_LABEL \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  --set inferenceExtension.latencyPredictor.enabled=true \
  --version LLM_D_VERSION \
  oci://LLM_D_REGISTRY_PATH

替换以下内容：

• INFERENCE_POOL_NAME：InferencePool 的名称，例如 vllm-llama3-8b-instruct。
• MODEL_SERVER_LABEL：用于选择模型服务器 Pod 的标签键。
• LLM_D_VERSION：要使用的 llm-d Helm 图表版本。
• LLM_D_REGISTRY_PATH：llm-d OCI 注册表路径。

第 2 步：验证部署

确认 EPP Pod 正在运行，并且所有边车容器都已准备就绪：

kubectl get pods -l app=INFERENCE_POOL_NAME-epp

EPP Pod 应显示处于“正在运行”或“就绪”状态的所有容器：EPP 本身、训练服务器和一个或多个预测服务器。

第 3 步：发送基准请求

在启用 SLO 标头之前，请发送标准推理请求以确认路由正常运行：

curl -i -X POST GATEWAY_IP:PORT/v1/completions \
 -H 'Content-Type: application/json' \
 -H 'Authorization: Bearer $(gcloud auth print-access-token)' \
 -H 'x-prediction-based-scheduling: true' \
 -d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "0"
 }'

替换以下内容：

• GATEWAY_IP：网关服务的 IP 地址。
• PORT：网关服务的端口号。
• MODEL_NAME：用于推理的模型的名称。
• PROMPT_TEXT：输入提示。
• MAX_TOKENS：要生成的 token 数量上限。

x-prediction-based-scheduling: true 标头可让相应请求加入预测延迟时间调度流水线。在预测器预热期间，EPP 会回退到启发式路由。

第 4 步：发送 SLO 感知型请求（可选）

如需启用按请求 SLO 强制执行，请添加 TTFT 和 TPOT 延迟时间目标标头：

curl -i -X POST GATEWAY_IP:PORT/v1/completions \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer $(gcloud auth print-access-token)' \
  -H 'x-prediction-based-scheduling: true' \
  -H 'x-slo-ttft-ms: 500' \
  -H 'x-slo-tpot-ms: 50' \
  -d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "0",
    "stream": true
  }'

替换以下内容：

• GATEWAY_IP：网关服务的 IP 地址。
• PORT：网关服务的端口号。
• MODEL_NAME：用于推理的模型的名称。
• PROMPT_TEXT：输入提示。
• MAX_TOKENS：要生成的 token 数量上限。

请求标头：

• x-prediction-based-scheduling: true：选择将请求纳入预测延迟时间调度流水线。
• x-slo-ttft-ms：可接受的最长 Time-to-First-Token（以毫秒为单位）。
• x-slo-tpot-ms：可接受的每个输出 token 所需时间上限（以毫秒为单位）。

监控预测延迟调度

启用延迟时间预测器后，EPP 会通过 Cloud Monitoring 公开其他指标。

扩缩预测服务器

对于每个传入请求，EPP 会针对每个候选 Pod 进行一次预测调用。每个预测服务器实例可维持大约 300 QPS 的预测工作。

预测服务器实例数量的大致指导：

通过更新 latencyPredictor.predictionServerCount Helm 值来添加预测服务器实例。

限制

• 需要同构 InferencePool：不支持在单个池中混合使用 GPU 类型、模型变体或部署配置。
• 预热期：XGBoost 模型需要有足够的实际流量样本，预测才能变得准确。
• SLO 强制执行：强制执行仅在路由层进行。模型服务器不会在选择后终止超出 SLO 目标的请求。
• 状态：此功能目前为预览版。如果不经过全面测试，不建议将其用于具有严格 SLA 要求的生产工作负载。

后续步骤

• 自定义 GKE 推理网关配置。
• 为 GKE Inference Gateway 执行发布操作。