本文档介绍了如何在 GKE 推理网关中启用和使用 llm-d 提供的基于预测延迟时间的路由。默认情况下，GKE 推理网关使用负载信号和前缀缓存亲和性启发法的组合来路由请求。基于预测延迟时间的路由使用根据实时流量持续训练的 XGBoost 模型替换静态启发式权重，从而在工作负载模式发生变化时做出更准确的路由决策。
何时使用基于预测延迟时间的路由
当您的工作负载符合以下条件时，此功能最为有效：
- 提示和完成长度差异很大：当请求大小差异很大时，仅队列深度不足以作为服务器负载的 代理。延迟时间预测器会考虑每个请求的实际预填充和解码费用。
- 每个请求的延迟时间 SLO：当您的应用在单个请求中指定 首个 token 延迟时间 (TTFT) 或每个输出 token 的时间 (TPOT) 目标时，调度器会在路由期间强制执行这些目标。它通过计算每个候选 Pod 的余量（预测延迟时间减去 SLO 目标）来实现此目的。
- 静态权重调整不稳定：如果您经常在流量模式发生变化时重新调整 缓存亲和性和负载信号之间的平衡 ，则在线训练的模型会自动适应。
基于预测延迟时间的路由的工作原理
本部分详细介绍了基于预测延迟时间的路由使用的架构和调度流水线。
架构
基于预测延迟时间的调度会在 EPP Pod 内部署两个额外的边车容器，以及 EPP 本身：
| 组件 | 说明 |
|---|---|
| 训练服务器 | 根据从 EPP 收到的已完成 请求样本，持续重新训练 XGBoost TTFT 和 TPOT 模型。使用滑动窗口上的分层分桶，以便不会忘记罕见的流量机制。将更新后的模型写入共享卷。 |
| 预测服务器 | 在请求热路径上向 EPP 提供 TTFT 和 TPOT 预测。从共享卷读取最新训练的模型。可横向伸缩 - 每个服务器实例大约支持 300 QPS 的预测工作。多个实例由 EPP 中的 Go 合并代理进行负载均衡，该代理会在 1 毫秒的时间窗口内批量处理并发预测请求。 |
llm-d EPP 调度流水线
启用基于预测延迟时间的调度后，EPP 会通过以下一系列可组合的插件处理每个请求：
predicted-latency-producer：调用预测服务器，以获取InferencePool中每个候选 Pod 的 TTFT 和 TPOT 估计值，条件是每个 Pod 的当前 KV 缓存利用率、队列深度、前缀缓存匹配得分以及传入请求特征。在响应返回给客户端后，生产者会将观察到的 TTFT 和 token 间延迟时间发送回训练服务器，作为新的训练样本。- 回退行为：如果预测服务器无法访问或 返回错误，EPP 会自动回退到基于 KV 缓存利用率、队列深度和前缀缓存匹配的综合得分 。
prefix-cache-affinity-filter：当任何 Pod 的前缀缓存匹配得分超过亲和性阈值（默认值为 0.80）时，此过滤条件会将候选集缩小到缓存预热的 Pod。此阈值分隔了在生产环境中观察到的两个群体：已缓存先前轮次对话历史记录的 Pod，以及未缓存对话历史记录的 Pod。此过滤条件实现了 epsilon-greedy 探索和利用策略：利用（默认路径）：此路径会路由到缓存预热的 Pod，以便 评分集中在这些 Pod 上重复使用缓存。
探索（小概率）：此路径会完全绕过可配置比例的请求的过滤条件 以便在冷 Pod 上播种缓存条目，从而防止缓存碎片。
TTFT 负载门：即使在利用路径上，如果最佳缓存预热 Pod 的预测 TTFT 超过最佳整体 Pod 的 TTFT 的可配置阈值（默认值为 5,000 毫秒），亲和性也会中断，并使用完整的候选集。
slo-headroom-tier-filter（仅限 SLO 请求）：当请求 包含 SLO 标头时，将候选 Pod 分为正层（预计 满足 SLO）和负层（预计违反 SLO）。latency-scorer：对候选 Pod 进行评分。如果没有 SLO 标头，则选择预测延迟时间最短的 Pod。如果有 SLO 标头，则得分基于余量（SLO 减去预测延迟时间），使用headroomSelectionStrategy：least（默认）：Bin-pack。路由到余量最小的正 Pod，最大限度地提高利用率，并为未来的流量突增保留负载较少的 Pod。most：Spread。路由到余量最大的正 Pod，为意外的负载峰值留下更多空间。
latency-slo-admitter（仅限 SLO 请求） ：当没有候选 Pod 预计满足 SLO 时，拒绝可舍弃的请求（优先级小于 0），而不是消耗预计会错过其目标的请求的容量。当缺少 SLO 标头或存在满足 SLO 的 Pod 时，此过滤条件不起作用。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 推理网关且部署正常运行。请参阅 部署 GKE 推理网关。
确保您的
InferencePool使用一组同质的 Pod，即相同的 GPU 类型、模型权重和服务配置。确保您的 GKE 集群为 1.32.3 或更高版本。
安装 Helm。请参阅 Helm 安装 指南。
启用基于预测延迟时间的调度
以下步骤将指导您为 GKE 推理网关部署启用基于预测延迟时间的调度。
第 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：可接受的首个 token 延迟时间上限（以毫秒为单位）。x-slo-tpot-ms：可接受的每个输出 token 的时间上限（以毫秒为单位）。
监控预测延迟时间调度
启用延迟时间预测器后，EPP 会通过 Cloud Monitoring 公开其他指标。
| 指标 | 说明 |
|---|---|
inference_objective_request_ttft_seconds |
实际 TTFT 分布（如果 streamingMode=false，则为 E2E 延迟时间）。 |
inference_objective_request_predicted_ttft_seconds |
预测的 TTFT 分布（如果 streamingMode=false，则为 E2E 延迟时间）。 |
inference_objective_request_tpot_seconds |
实际 TPOT 分布。 |
inference_objective_request_predicted_tpot_seconds |
预测的 TPOT 分布。 |
inference_objective_request_ttft_slo_violation_total |
TTFT SLO 违规计数器。 |
扩缩预测服务器
EPP 会为每个传入请求的每个候选 Pod 进行一次预测调用。每个预测服务器实例大约支持 300 QPS 的预测工作。
预测服务器实例数量的近似指南：
| 集群 QPS（100 个 Pod） | 所需的预测服务器 |
|---|---|
| 最多 1,000 QPS | 1 个服务器 |
| 最多 5,000 QPS | 2 个服务器 |
| 最多 10,000 QPS | 4 个服务器 |
通过更新 latencyPredictor.predictionServerCount Helm 值来添加预测服务器实例。
限制
- 需要同质的
InferencePool：不支持在单个池中混合使用 GPU 类型、模型变体、 或服务配置。 - 预热期：XGBoost 模型需要足够的实时流量 样本，预测才能准确。
- SLO 强制执行：强制执行仅在路由层进行。模型服务器不会终止选择后超出 SLO 目标的请求。
- 状态：此功能目前为预览版。如果不经过全面测试，不建议将其用于具有严格 SLA 要求的生产工作负载。