七成请求不必用前沿模型：GKE 上搭建 Gemini 智能路由层

核心洞察

这篇文章最有意思的地方在于它戳破了一个很多团队心知肚明但不愿承认的事实：大部分请求根本不需要前沿推理模型。70% 的流量花在了分类、摘要、结构化提取这类轻活上，却按前沿模型的价码付费。作者给的方案不算新鲜（网关层做路由），但把 GKE Gateway、Workload Identity 和 Gemini 多区域端点串起来的具体配置，确实省去了不少翻文档的时间。

把所有进来的用户请求都丢给前沿推理模型，是烧光 token 预算、拖垮 p99 尾延迟最快的方式。Gemini 平台上线 Gemini 4 ArgonGemini平台上的前沿推理模型，适用于复杂多步推理、代码生成等任务。 之后，工程团队手里多了两个选择：gemini-4-argon 负责深度多步推理，gemini-3.8-flash 和跑在集群加速器上的开源权重模型负责高吞吐、低延迟的执行。

生产环境里的负载复杂度基本遵循一条陡峭的幂律曲线。大约 70% 的请求是分类、摘要、schema 提取或者简单检索，快速层几百毫秒就能搞定。剩下 30% 才需要多跳综合、复杂代码生成或者模糊约束求解，这才是 gemini-4-argon 的用武之地。在应用容器里硬编码一个模型 ID，结果只有两种：要么在简单查询上多花钱，要么在复杂任务上交付不足。

用 GKE Gateway APIGoogle Kubernetes Engine的网关API，用于管理入口流量和路由规则。 在 Google Kubernetes Engine（GKE）上搭一个集中式 AI 路由层，平台团队就能在入口边缘判断 prompt 复杂度，把请求分发到不同 Gemini 层级（gemini-4-argon 和 gemini-3.8-flash）以及自托管的 GKE Inference GatewayGKE的推理网关，用于在集群内自托管模型（如vLLM）的流量管理。 池，还能在触发限流时自动降级。

下面拆解这套多层级 Gemini 4 Argon 路由器的架构，配置 GKE Standard 和 Autopilot 基础设施并接入 Workload Identity Federation for GKEGKE的工作负载身份联合，允许Kubernetes ServiceAccount以IAM身份安全访问Google Cloud服务。，然后过一遍路由、健康检查和可观测性配置。

核心结论

1. 生产环境中约 70% 的请求属于分类、摘要、schema 提取或简单检索等轻量任务，仅剩 30% 需要多跳综合、复杂代码生成或模糊约束求解等深度推理能力，将全部流量交给前沿推理模型是推高 token 成本与 p99 延迟的最快方式。

2. 在 GKE 上通过 Gateway API 构建集中式 AI 路由层，可将请求分发至三个层级：gemini-4-argon（前沿推理）、gemini-3.8-flash（低延迟交互）以及集群内 vLLM一个高性能的LLM推理和服务库，为DeepSeek-OCR提供优化的推理能力，支持流式输出和批量处理。 池运行的开源权重模型（高吞吐本地），并在触发限流时自动降级。

3. gemini-4-argon 在大上下文下推理链执行需 30 至 90 秒，超过标准 HTTP 负载均衡器 30 秒超时限制，需通过 GCPBackendPolicy 将后端超时延长至 180 秒，并额外配置 HealthCheckPolicy 将探针指向 /healthz（GKE Gateway 默认探测 /，而路由服务对该路径返回 404）。

4. 通过 Workload Identity Federation for GKE 将 Kubernetes ServiceAccount 绑定至 IAM 角色（roles/aiplatform.user），可在不分发静态服务账号密钥的前提下调用 Gemini 平台，该做法在 GKE Standard 和 Autopilot 上一致，前提是 GKE 版本 1.32 或更高且启用 Gateway 控制器。

5. 路由层并非普适方案：若仅运行单一应用、提示复杂度可预测且延迟目标统一，直接从应用 SDK 调用 Gemini 平台并配置内置重试策略即可，无需在集群中额外维护一跳。

为什么静态模型绑定在生产环境会失效

应用团队在几十个微服务里直接对接 LLM 端点，三个运维问题很快会浮出水面：

• token 花费失控、延迟膨胀：一个微服务为了常规的 JSON 格式化去调 gemini-4-argon，付的是前沿模型的单价，等的是深度推理链，而 gemini-3.8-flash 用零头的时间就能产出同样的 schema。
• 凭证和配额管理散落各处：Gemini 平台 API 配额、重试退避、区域故障转移分散在 30 个独立的应用仓库里，流量高峰期的行为一致性根本没法保证。
• 没有混合集群内卸载的路径：高并发、低复杂度的任务本来可以由 GKE GPU 或 TPU 节点池上的开源权重模型以固定成本承接，但应用代码和单一模型字符串绑死，想切流量就得改代码、重新部署。

把模型路由集中到 GKE Gateway 和智能路由服务后面，客户端微服务就和底层模型层级解耦了。

GKE 上的多层级路由架构

这套架构里，内部微服务把标准请求发给区域内部 GKE Gateway（gke-l7-rilb）。Gateway 把流量转给 ai-model-router 服务，后者评估请求元数据或者跑一次快速复杂度检查，再分发到三个模型层级之一：

• 第一层（前沿推理）：高复杂度任务、代码合成、多步规划走 Gemini 平台的 gemini-4-argon。
• 第二层（低延迟交互）：常规摘要、分类、结构化提取走 Gemini 平台的 gemini-3.8-flash。
• 第三层（高吞吐本地）：大批量转换和严格数据本地化的工作负载走集群内 vLLM 池，通过 GKE Inference Gateway 跑 Gemma 4Gemma 4，Google的轻量级开源模型系列，边缘变体（E2B/E4B）可在1.5GB RAM以下运行。。

三个层级在生产运维维度上的对比如下：

本文后面的示例路由器实现了第一层和第二层的位置故障转移，以及第一层的降级。进出集群内第三层池的路径取决于你的 Inference Gateway 配置，留给自己的分发逻辑处理。

配置 Workload Identity 和 GKE 计算资源

要在不分发静态服务账号密钥的前提下调用 Gemini 平台，用 Workload Identity Federation for GKE 把 ai-model-router 的 Kubernetes ServiceAccount 直接绑定到 IAM 角色。这套做法在 GKE Standard 和 GKE Autopilot 集群上完全一致，前提是 GKE 版本 1.32 或更高、启用了 GKE Gateway 控制器（--gateway-api=standard），并且 VPC 里有一个活跃的区域代理专用子网（--purpose=REGIONAL_MANAGED_PROXY）。

关于模型标识符和位置的说明：下面的示例通过环境变量（PRO_MODEL 和 FLASH_MODEL）配置 gemini-4-argon（Gemini 4 Argon）和 gemini-3.8-flash（Gemini 3.8 Flash面向软件工程、自主智能体和复杂工作流的最新 Flash 型号，支持多模态输入、文本输出、结构化输出及搜索接地，输入上限 1,048,576 tokens。）。两个模型都从 global 端点以及 us、eu 多区域端点提供服务，而不是从 us-central1 这类单个区域，所以路由器是从 global 故障转移到 us。

export PROJECT_ID="production-ai-platform"
export PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}" --format="value(projectNumber)")
export LOCATION="us-central1"
export CLUSTER_NAME="ai-gateway-cluster"

# 把 kubectl 指向集群
gcloud container clusters get-credentials "${CLUSTER_NAME}" --location="${LOCATION}" --project="${PROJECT_ID}"

# 创建命名空间和 Kubernetes ServiceAccount
kubectl create namespace ai-routing
kubectl create serviceaccount gemini-router-sa --namespace=ai-routing

# 授予 Kubernetes ServiceAccount 调用 Gemini 平台模型的权限
# （底层 IAM 角色字符串仍然是 roles/aiplatform.user）
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
    --member="principal://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${PROJECT_ID}.svc.id.goog/subject/ns/ai-routing/sa/gemini-router-sa" \
    --role="roles/aiplatform.user" \
    --condition=None

GKE Autopilot 与 Standard 的容量配置

路由器 Deployment 本身用标准 CPU 计算资源就够了。如果你还要运营第三层（通过 GKE Inference Gateway 做集群内开源权重推理，用于高并发卸载），加速器容量要按集群模式来配：

• GKE Autopilot 配 ComputeClass：定义一个声明式 ComputeClass（cloud.google.com/v1），请求 NVIDIA L4 GPU（gpu.type: nvidia-l4，gpu.count: 2），并配置从按需容量到 Spot VM 的优先级回退，应对区域库存紧张。
• GKE Standard 节点池：创建专用 GPU 节点池（gcloud container node-pools create vllm-l4-pool --cluster="${CLUSTER_NAME}" --location="${LOCATION}" --machine-type=g2-standard-24 --accelerator=type=nvidia-l4,count=2,gpu-driver-version=latest --enable-autoscaling --min-nodes=1 --max-nodes=6）。

实现 Gemini 4 层级路由器

ai-model-router 服务检查进来的请求，估算任务复杂度（用显式的客户端 header、token 数阈值或者关键词触发），然后通过 google-genai SDK 发起调用，带跨位置故障转移和跨层级降级。它还暴露一个 /healthz 端点，Pod 的 readinessProbe 和 GKE Gateway 负载均衡健康检查都用它来确认后端就绪状态。

把下面的实现保存为 router_app.py：

模型选好了，接下来得让它真的能跑起来。上面那段代码是整个路由服务的核心，我拆开说几个关键点。

先是客户端初始化。这里用了 vertexai=True 这个开关，走的是项目级 IAM 认证，不是 API key。配合 GKE 的 Workload Identity Federation，Pod 里的服务账号直接映射到 GCP 的 IAM 权限，代码里看不到任何密钥。两个 client 分别指向 global 和 us 两个 endpoint，后面做故障转移用。

路由逻辑本身不复杂。select_model_tier 先看调用方有没有显式指定 tier，x-model-tier 头传了 pro 或 flash 就直接照办。没传的话就看 prompt 本身：词数超过 600，或者命中了一组推理关键词（architect、debug、prove、multi-step 这类），就走 Argon；否则默认 Flash。

有个细节值得单独拎出来说。build_config 里对两个模型的处理不一样。Argon 会忽略采样参数，thinking level 默认就是 MEDIUM，所以只传 system_instruction。Flash 那边才设 temperature=0.2。这个差异如果不处理，给 Argon 传 temperature 不会报错，但也不会有任何效果，容易让人误以为参数生效了。

请求进来之后的执行链路是这样的：先打 global endpoint，失败就切到 us 多区域 endpoint。如果目标模型是 Argon、但调用方并没有显式要求深度推理，还会再追加一次降级到 Flash 的尝试。换句话说，自动路由到 Argon 的请求在两次失败后可以退到 Flash 保底；显式指定 pro 的请求不会降级，宁可报错也不偷偷换模型。

这个设计上的取舍挺明确：自动判断可能判错，判错了降级比直接失败对用户更友好；但用户明确说要 pro，那就是有理由的，不能自作主张。

/healthz 单独留了一个轻量端点，不碰任何模型调用，给 GKE 的 readiness probe 用。/v1/generate 是主入口，接收 prompt、可选的 system_instruction，以及 require_deep_reasoning 这个布尔开关。

代码到这里只是单实例的逻辑。真正上 GKE 之后，多副本、滚动更新、跨区容灾这些才是下一层要处理的事。

模型跑通了，接下来得让它能被外面访问。这里有个坑得提前说：gemini-4-argon 在大上下文下推理链跑完要 30 到 90 秒，标准 HTTP 负载均衡器 30 秒就超时断连，客户端一重试，钱又烧一遍。

所以得配 GKE 的 Gateway、HTTPRoute 和 GCPBackendPolicy（networking.gke.io/v1），把后端超时拉到 180 秒，顺便开启滚动更新时的连接排空。

还有个细节容易漏。GKE Gateway 不像 GKE Ingress 那样从 Pod 的 readinessProbe 推断负载均衡健康检查，它默认探 /，而路由服务对 / 返回 404。得单独加一个 HealthCheckPolicy（同样是 networking.gke.io/v1），把探针指到 /healthz。

如果你集群里还跑着一个 vLLM 池，由 GKE Inference Gateway 管着（inference.networking.k8s.io/v1 里的 InferencePool，加上 inference.networking.x-k8s.io 里做优先级调度的 InferenceObjective），那可以在同一个 internal-ai-gateway 上再挂一条 HTTPRoute 规则，或者在 router_app.py 里做内部分发，把大批量流量直接打到 group: inference.networking.k8s.io、kind: InferencePool。

验证网关和路由行为

清单 apply 完之后，先确认 GKE Gateway 控制器已经把内部负载均衡器配好，两个后端策略也都挂上了：

# 确认 Gateway 已编程，拿到内部 IP
kubectl get gateway internal-ai-gateway -n ai-routing

# 检查两个策略是否都挂到了 Service 上（看 Reason 是不是 Attached）
kubectl describe gcpbackendpolicy gemini-router-backend-policy -n ai-routing
kubectl describe healthcheckpolicy gemini-router-healthcheck -n ai-routing

<svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewBox="0 0 24 24"><title>Exit fullscreen mode</title>
<path d="M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z"></path>

`gke-l7-rilb` 只暴露内网 IP，所以得先用 `kubectl` 把地址查出来，然后从同一个 VPC、同一个 region 里的客户端发测试请求，比如集群里起个 debug Pod：

export GATEWAY_IP=$(kubectl get gateway internal-ai-gateway -n ai-routing -o jsonpath='{.status.addresses[0].value}')

# 1. 快速分类查询（自动路由到 gemini-3.8-flash）
curl -s -X POST "http://${GATEWAY_IP}/v1/generate" </span>
    -H "Content-Type: application/json" </span>
    -d '{"prompt": "Extract the HTTP status code from this log line: GET /checkout 502 Bad Gateway"}' | jq .
# 2. 复杂架构查询（自动路由到 gemini-4-argon）
curl -s -X POST "http://${GATEWAY_IP}/v1/generate" </span>
    -H "Content-Type: application/json" </span>
    -d '{"prompt": "Analyze the root cause and trade-offs of etcd leader election timeouts during cross-zone network partitions."}' | jq .

<svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewBox="0 0 24 24"><title>Exit fullscreen mode</title>
<path d="M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z"></path>

返回结果里应该能看到选中的档位、location、fallback 状态，还有 token 计费明细（包括推理用的 `thoughts_tokens`）：

运维上的坑，以及什么时候不该上路由

在 Gemini 4 Argon 前面加一层模型路由之前，先掂量掂量这几个取舍：

• 分类器准确率和质量回退：基于启发式或 embedding 的路由器，容易把简短提示误判成简单请求，可它实际上需要深度推理（比如一道很短的数学谜题）。务必留一个显式覆盖头（X-Model-Tier: pro），让能忍延迟或者高风险的流程直接绕过启发式判断。
• 多轮对话状态：对话中途切换模型层级，输出格式或工具调用行为可能会变。有状态的聊天会话，要么在第一轮就把模型层级钉死，要么只在工具执行失败时才评估要不要升级。
• 什么时候不该用路由层：如果你只跑一个应用，提示复杂度可预测，延迟目标也统一，那直接从应用 SDK 调 Gemini 平台、配上内置重试策略就行，省得在集群里多维护一跳。

下一步

把微服务跟硬编码的模型字符串解耦，你就能在真正需要推理能力的地方用上 Gemini 4 Argon，同时让日常查询继续跑在 gemini-3.8-flash 或集群内的加速器上，又快又省钱。

想扩展这套架构，可以翻翻 GKE Gateway API 文档，看看 GKE Inference Gateway 指南里怎么路由到自托管开源模型，再查一下 Gemini 平台的模型位置和配额文档，了解多区域可用性和吞吐配置。

常见问题（FAQ）

为什么不能把模型 ID 硬编码在应用容器里？

硬编码单一模型 ID 会导致简单查询多花钱、复杂任务交付不足。生产负载约 70% 是分类、摘要等轻活，30% 才需深度推理，静态绑定无法按复杂度分流，还会让配额与故障转移分散在各仓库。

GKE 上的多层级路由架构是怎么分流的？

内部微服务把请求发给区域内部 GKE Gateway，再转给 ai-model-router 服务评估复杂度，分发到三层：gemini-4-argon 负责前沿推理，gemini-3.8-flash 负责低延迟交互，集群内 vLLM 池负责高吞吐本地任务。

调用 Gemini 平台时怎么避免分发静态密钥？

用 Workload Identity Federation for GKE 把 ai-model-router 的 Kubernetes ServiceAccount 绑定到 IAM 角色 roles/aiplatform.user，无需静态服务账号密钥。该做法在 GKE Standard 和 Autopilot 上一致，需 GKE 1.32 以上。