如何在不显式指定模型 ID 的情况下，让系统自动选择最合适的模型？

本文介绍一种工程可落地的方案：

通过 Embedding 模型计算用户意图 → 在网关层进行语义匹配 → 动态路由到最合适的上游模型服务

我们将基于：

• Embedding 模型：Azure OpenAI text-embedding-3-small
• 网关：Envoy
• 核心机制：向量相似度打分 + 策略路由

问题背景与动机

在真实生产环境中，大模型调用通常面临几个挑战：

1. 成本与性能权衡

不同请求应该走不同模型，而不是“一刀切”。

2. 传统做法的局限

常见策略：

• 手动指定 model_id ❌（不智能）
• 基于规则（if/else）❌（不可扩展）
• 基于关键词匹配 ❌（语义不鲁棒）

3. 理想目标

我们希望：

用户只输入 prompt，系统自动理解“意图”，并选择最优模型

这正是 Embedding 可以发挥作用的地方。

核心原理：Embedding 驱动的语义路由

1. Embedding 本质

Embedding 模型（如 text-embedding-3-small）可以将文本映射为高维向量：

"写一段 Python 排序代码"
→ [0.012, -0.98, ..., 0.33]  (1536维向量)

语义相似的文本，其向量距离更近。

2. 路由思路

核心逻辑可以抽象为：

用户请求 → Embedding → 与“意图模板库”计算相似度 → 选择最佳匹配 → 路由模型

3. 意图模板（Intent Prototypes）

我们预先定义一组“意图向量”：

这些文本会提前计算 embedding 并缓存。

4. 相似度计算

常用方法：

• Cosine Similarity（推荐）

similarity = cosine(query_embedding, intent_embedding)

选择最高分：

argmax(similarity_i)

系统架构设计

整体架构如下：

                ┌──────────────┐
                │   Client     │
                └──────┬───────┘
                       │
               ┌───────▼────────┐
               │    Envoy 网关   │
               │   (智能路由层)   │
               └───────┬────────┘
                       │
        ┌──────────────┼──────────────┐
        │              │              │
 ┌──────▼─────┐ ┌──────▼─────┐ ┌──────▼─────┐
 │ GPT-4      │ │ GPT-4o-mini│ │ 专用模型    │
 └────────────┘ └────────────┘ └────────────┘

实现逻辑拆解

1. 请求流程

Step 1：获取用户请求

{
  "input": "帮我写一段 Go 的 HTTP server 示例"
}

Step 2：调用 Embedding API

使用 Azure OpenAI：

POST https://{endpoint}/openai/deployments/text-embedding-3-small/embeddings?api-version=2024-02-15-preview

请求体：

{
  "input": "帮我写一段 Go 的 HTTP server 示例"
}

Step 3：计算相似度

伪代码：

def route(query_embedding):
    best_score = -1
    best_model = None

    for intent in intents:
        score = cosine_similarity(query_embedding, intent.embedding)
        if score > best_score:
            best_score = score
            best_model = intent.model

    return best_model

Step 4：Envoy 动态路由

将结果写入 Header：

x-llm-route: gpt-4

Envoy 根据 Header 路由：

routes:
- match:
    prefix: "/v1/chat"
    headers:
      - name: x-llm-route
        exact_match: gpt-4
  route:
    cluster: gpt4_service

Envoy 网关实现方式

Envoy 本身不直接支持向量计算，因此需要扩展：

方案 1：External Processing（推荐）

Envoy 调用外部服务（ext_proc）：

Envoy → ext_proc 服务 → 返回路由决策 → Envoy 转发

ext_proc 负责：

• 调用 embedding
• 计算相似度
• 返回 header

方案 2：WASM 插件

在 Envoy 内嵌逻辑：

• 优点：低延迟
• 缺点：开发复杂（Rust/CPP）

方案 3：Sidecar Router（简单）

Client → Router Service → Envoy → Model

Router 服务负责所有智能逻辑。

优化策略

1. 向量缓存

避免重复调用 embedding：

cache[input_hash] = embedding

2. 意图分层

避免单层分类过粗：

一级：代码 / 问答 / 写作
二级：语言 / 长度 / 难度

3. 阈值控制

if best_score < threshold:
    fallback_model = "gpt-4"

防止误判。

4. 多模型融合（Ensemble）

可扩展为：

• Top-K 模型候选
• A/B 测试
• 加权路由

5. 成本感知路由

结合：

• token 预算
• 用户等级
• SLA

做策略增强：

if user == "free":
    prefer_small_model()

优势分析

相比规则路由

相比手动指定模型

• 用户体验更好（无需关心模型）
• 自动最优成本
• 支持动态策略

落地建议

1. 初始阶段

• 5~10 个意图模板即可
• 手动标注 + 调优

2. 数据驱动优化

记录：

• 用户请求
• 路由结果
• 用户反馈

持续优化 intent embedding。

3. 与 LLM Router 结合

未来可以升级为：

用小模型 + embedding 混合决策（Hybrid Router）

总结

本文方案的本质是：

用 Embedding 替代规则，用向量相似度驱动模型选择

关键收益：

• 降低成本（智能选择轻量模型）
• 提升效果（复杂任务走强模型）
• 架构解耦（路由逻辑与模型解耦）

在多模型时代，这种“语义驱动的网关”会成为标准架构组件。

这一举措标志着 Kubernetes 在集群入口与流量管理方面正式进入 Gateway API 时代。对于正在使用 Ingress NGINX 的团队，这不仅是一次技术升级，更是一项需要尽快规划的风险管理工作。

本文将基于 Kubernetes 官方退役公告、Gateway API 最新生态与社区最佳实践，系统介绍：

• 为什么 Ingress NGINX 被退休？
• Ingress 模型的根本局限与 Gateway API 的优势
• 新的推荐替代方案：Envoy Gateway（基于 Gateway API）
• 如何从 Ingress 迁移到 Gateway API（完整迁移路径）
• 关键注意事项与生产实践建议

Ingress NGINX 为什么从 Kubernetes 正式退役？

根据官方博客（2025–11–11），Ingress NGINX 的退役原因包括：

● 1. 项目长期缺乏维护者

虽然 Ingress NGINX 使用极广，但维护压力巨大，而核心维护者数量越来越少，社区贡献下滑。项目经过数月讨论，确定无法持续投入。

● 2. 无法跟上 Kubernetes 网络模型的发展

Ingress 诞生于 Kubernetes 早期，仅支持 HTTP(s) 基础路由；而随着 Service Mesh、多协议服务、网关统一治理等场景爆发，Ingress 模型难以满足现代需求。

● 3. 功能严重依赖 Controller 私有扩展

如 NGINX Ingress 的大量 Annotation、Rewrite、Header 管理等，使得 Ingress 配置在不同控制器之间高度不兼容，难以形成云原生网络的统一抽象。

● 4. Gateway API 已经成熟，能够全面替代

Gateway API 于 2023–2024 进入 GA，解决了 Ingress 的所有痛点，是 Kubernetes SIG-Network 未来 10 年的官方战略方向。

官方公告明确：

• 从 2026 年 3 月起将不再提供任何补丁，包括安全补丁。
• 项目代码、容器镜像、Helm Chart 虽然仍可访问，但不会再更新。
• 官方建议用户“尽快迁移”。

Ingress 的局限性：为什么它必须退出历史舞台？

Ingress 的设计非常简单，只能做最基础的 L7 HTTP(s) 路由：

Ingress 的能力已无法支撑现代云原生系统的需求，而且控制器之间的行为极不一致。Gateway API 的出现正是为了解决上述所有问题。

推荐替代方案：Envoy Gateway + Gateway API

目前官方推荐的方向是：转向 Gateway API，并选择任意兼容的 Gateway 实现。

在众多实现中，我们推荐 Envoy Gateway，原因包括：

1. 对 Gateway API 支持最完整

完美支持 HTTPRoute / TCPRoute / GRPCRoute 这是 Ingress 无法做到的。

2. 基于 Envoy Proxy，性能与可扩展性行业领先

Envoy 是 CNCF 毕业项目，得到大规模生产验证。

3. 社区活跃，长期维护无风险

与 Ingress NGINX 的“维护者不足”相比，Envoy Gateway 是明确的长期支持项目。

4. 与 Service Mesh（如 Istio）原生兼容

Gateway API 未来将成为 Service Mesh 入口的新标准。

换句话说：Envoy Gateway 是最稳妥的迁移目标。

迁移路径：从 Ingress NGINX → Gateway API（Envoy Gateway）

大多数企业推荐采用 双栈迁移：

Ingress（旧） 和 Gateway API（新） 并存 → 服务逐个迁移 → 完全切流 → 卸载 Ingress NGINX

以下是完整步骤。

步骤 1：安装 Gateway API 和 Envoy Gateway

安装标准 Gateway API CRD：

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/latest/download/standard-install.yaml

然后安装 Envoy Gateway 控制器（官方提供 Helm / YAML）。

步骤 2：创建 Gateway（替代 Ingress Controller + LoadBalancer）

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: infra
spec:
  gatewayClassName: envoy
  listeners:
  - name: http
    port: 80
    protocol: HTTP
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: demo-cert

这相当于原来的：

• Ingress Controller
• • LoadBalancer Service
• • TLS 配置

步骤 3：把 Ingress 转换为 Gateway API 路由

原 Ingress：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
spec:
  rules:
  - host: demo.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: demo-svc
            port:
              number: 80

新 HTTPRoute：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: demo
spec:
  parentRefs:
    - name: main-gateway
      namespace: infra
  hostnames:
    - "demo.example.com"
  rules:
  - matches:
      - path:
          type: PathPrefix
          value: "/"
    backendRefs:
      - name: demo-svc
        port: 80

步骤 4：灰度切流（可选但强烈推荐）

Gateway API 支持权重：

backendRefs:
  - name: demo-svc-v1
    port: 80
    weight: 90
  - name: demo-svc-v2
    port: 80
    weight: 10

用于：

• 灰度发布
• 蓝绿切换
• 测试新网关
• 逐步迁移流量

这是 Ingress 以前必须靠 Nginx snippet 才能做到的。

步骤 5：服务逐个迁移 → 最终替换所有 Ingress

建议迁移顺序：

1. 无状态服务
2. 内部服务（非公网）
3. 低风险流量
4. 高风险 / 主业务
5. 全局入口流量
6. 完成后卸载 Ingress NGINX

迁移注意事项（生产环境必读）

1. Annotation 不会自动迁移

Ingress 的 Annotation（rewrite、headers、timeouts 等）要重写为 Gateway API 的 Policy / Filter。

2. TLS 配置方式不同

Gateway API 是 Listener 层统一处理 TLS。

3. 流量切换建议逐步进行

不要一次性替换大量入口。

4. 建议提前半年开始迁移

要赶在 2026 年 3 月停止维护前完成迁移。

总结：Gateway API 是 Kubernetes 入口的未来

Ingress NGINX 的退役并不是坏事，而是 Kubernetes 网络体系完成演进的标志。

Ingress → Gateway API 是必然趋势，也是一次全面升级：

• 更强的路由能力
• 更清晰的多租户设计
• 更丰富的现代云原生场景支持
• 更长期的社区维护保障

对于已经依赖 Ingress NGINX 的团队，现在就应该开始迁移规划。

Gateway API + Envoy Gateway 是当前生态最稳、最现代、最推荐的方案。