让模型自己选模型:Embedding 驱动的 LLM 智能路由机制

在多模型并存的 AI 架构中(如 GPT-4 / GPT-4o / 轻量模型 / 垂直模型等),一个核心问题是: 如何在不显式指定模型 ID 的情况下,让系统自动选择最合适的模型? 本文介绍一种工程可落地的方案: 通过 Embedding 模型计算用户意图 → 在网关层进行语义匹配 → 动态路由到最合适的上游模型服务 我们将基于: Embedding 模型:Azure OpenAI text-embedding-3-small 网关:Envoy 核心机制:向量相似度打分 + 策略路由 问题背景与动机 在真实生产环境中,大模型调用通常面临几个挑战: 1. 成本与性能权衡 模型类型 优点 缺点 大模型(如 GPT-4) 能力强 成本高 / 延迟高 小模型(如 GPT-4o-mini) 快 / 便宜 能力有限 专用模型 精准 泛化弱 不同请求应该走不同模型,而不是“一刀切”。 2. 传统做法的局限 常见策略: 手动指定 model_id ❌(不智能) 基于规则(if/else)❌(不可扩展) 基于关键词匹配 ❌(语义不鲁棒) 3. 理想目标 我们希望: 用户只输入 prompt,系统自动理解“意图”,并选择最优模型 这正是 Embedding 可以发挥作用的地方。...

五月 26, 2026 · 2 分钟

Kubernetes Ingress NGINX 退役:全面迁移到 Gateway API 的方案与实践指南

Kubernetes 官方在 2025 年 11 月 11 日发布博客,正式宣布 Ingress NGINX 项目进入退役(Retirement)阶段,并将于 2026 年 3 月彻底停止维护。 这一举措标志着 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 模型难以满足现代需求。...

十二月 1, 2025 · 3 分钟