LLM路由器已成为一个独立服务类别

# LLM 路由器已成为独立服务类别 来源：https://techstrong.ai/articles/llm-routers-have-become-a-service-category-of-their-own/ 跳转到内容 (https://techstrong.ai/articles/llm-routers-have-become-a-service-category-of-their-own/#content)Techstrong.ai 标志 (https://techstrong.ai/) - 最新 (https://techstrong.ai/articles/llm-routers-have-become-a-service-category-of-their-own/#)- 文章 (https://techstrong.ai/category/articles/) - 专题 (https://techstrong.ai/category/features/) - 新闻 (https://techstrong.ai/category/news/) - 视频 (https://techstrong.ai/category/videos/) - 相关站点 (https://techstrong.ai/articles/llm-routers-have-become-a-service-category-of-their-own/#)- DevOps.com (https://devops.com/) - Security Boulevard (https://securityboulevard.com/) - Cloud Native Now (https://cloudnativenow.com/) - Digital CxO (https://digitalcxo.com/) - DevOps Dozen (https://devopsdozen.com/) - DevOps TV (https://www.youtube.com/channel/UC-zcE077X98oTEDPwKkDQxQ) - Platform Engineering (https://platformengineering.com/) - Techstrong TV (https://techstrong.tv/) - Techstrong TV Podcast (https://www.techstrongpodcasts.com/) - Techstrong TV Twitch (https://www.twitch.tv/techstrongtv) - Techstrong Group (https://techstronggroup.com/) - 关于我们 (https://techstrong.ai/about/) - 媒体工具包 (https://techstronggroup.com/assets/techstrong-media-kit.pdf) - AI 基础设施 (https://techstrong.ai/category/ai-infrastructure/) - 自主 AI (https://techstrong.ai/category/agentic-ai/) - AI 职业 (https://techstrong.ai/category/ai-careers/) - AI 安全 (https://techstrong.ai/category/ai-security/) - AI 治理 (https://techstrong.ai/category/ai-governance/) - 数据工程 (https://techstrong.ai/category/data-engineering/) - 数据科学 (https://techstrong.ai/category/data-science/) - 更多 (https://techstrong.ai/articles/llm-routers-have-become-a-service-category-of-their-own/#)- 航空航天 (https://techstrong.ai/category/aerospace/) - 自主 AI (https://techstrong.ai/category/agentic-ai/) - AIOps (https://techstrong.ai/category/aiops/) - 教育 (https://techstrong.ai/category/education/) - 能源 (https://techstrong.ai/category/energy/) - 环境 (https://techstrong.ai/category/environmental/) - 金融服务 (https://techstrong.ai/category/financial-services/) - 生成式 AI (https://techstrong.ai/category/generative-ai/) - 政府 (https://techstrong.ai/category/government/) - 医疗保健 (https://techstrong.ai/category/healthcare/) - 机器学习/深度学习 (https://techstrong.ai/category/machine-deep-learning/) - 媒体/娱乐 (https://techstrong.ai/category/media-entertainment/) - 专业服务 (https://techstrong.ai/category/professional-services/) - 提示工程 (https://techstrong.ai/category/prompt-engineering/) - 零售 (https://techstrong.ai/category/retail/) - 电信 (https://techstrong.ai/category/telecommunications/) - 交通/旅行 (https://techstrong.ai/category/transportation-travel/) 首页 (https://techstrong.ai/)»LLM 路由器已成为独立服务类别## LLM 路由器已成为独立服务类别 如今，单一 LLM 已不够用，因此 LLM 路由器能够自动在多个模型之间切换，让用户以最低成本模型完成特定任务，同时获得最佳效果。 LLM 路由器正从小众基础设施技巧转变为主流产品类别。核心主题不再是“一个最佳模型”，而是“为每个请求选择最合适的模型”。原因很简单：随着 AI 价格上涨以及基于 Token 的 AI 定价模式的普及，前沿模型的成本变得极其高昂 (https://techstrong.ai/articles/tech-giants-slashing-budgets-as-token-costs-skyrocket/)。这些服务的实际目标也很简单：将简单任务发送给廉价模型，将困难任务发送给更强大的模型，在保持高质量的同时降低成本。 这一切始于 2021 年，当时 IBM 描述了 LLM 路由器如何实时将查询发送给最具成本效益的模型 (https://research.ibm.com/blog/LLM-routers)。到 2024 年，这一想法已明显成为实用的工程模式。虽然很难指出“第一个”LLM 路由器，但 Anyscale 在 2024 年发布的构建 LLM 路由器教程 (https://www.anyscale.com/blog/building-an-llm-router-for-high-quality-and-cost-effective-responses)（基于分类器将请求路由到最具成本效益的模型）无疑是重要候选。 此后，众多 LLM 路由器相继出现。今天的 LLM 路由器可分为几种可识别的类型：基于规则、语义、预测、级联和基于成本。实际上，许多产品结合了多种方法，因此类别之间存在重叠。 另一种思考该领域的方式是按部署风格划分。像 OpenRouter (https://openrouter.ai/)、LiteLLM (https://www.litellm.ai/) 和 Portkey (https://portkey.ai/) 这样的网关，专注于 API 统一、日志记录、密钥管理、路由和故障转移。而智能路由器，如 Martian RouterBench (https://withmartian.com/post/introducing-routerbench)、Not Diamond (https://www.notdiamond.ai/) 和 RouteLLM (https://arxiv.org/abs/2406.18665)，则更专注于为每个请求选择最佳模型。 ## 首批 LLM 路由器 ### 网关 OpenRouter 可以说是最知名的，它是最清晰的托管聚合器示例。它拥有单一 API，支持众多模型、自动故障转移，以及跨数十个提供商的路由功能。其官方文档提到由 Not Diamond 提供支持的自动路由器，因此它介于网关和路由器之间。 对于希望在自己基础设施内使用相同基本抽象的团队来说，自托管替代方案是 LiteLLM。它是一个你自己运行的代理层，提供加权、基于延迟、感知速率限制、最少负载、最低成本以及自定义 Python 逻辑等多种路由模式。 Portkey 更像是一个控制平面，而非纯路由器。它在你已经管理的提供商密钥之上增加了治理、可观测性、防护栏、缓存和路由功能，这对希望同时拥有策略和模型选择的生产团队很有吸引力。 ### 智能路由器 Martian 和 Not Diamond 更接近最初的“为每个提示选择最佳或最便宜模型”的理念。它们旨在对请求进行分类并动态路由，而不仅仅是通过统一 API 传递流量。 RouteLLM 是该理念的研究导向版本。它专注于路由决策本身，而非账单、日志记录或密钥管理等更广泛的网关功能。 Semantic Router 是一种更轻量级的方法，它使用嵌入向量和语义相似性来路由请求。当你希望有确定性、可解释的路由规则而又不想构建完整的网关堆栈时，这非常有用。 ## 新路由器的崛起：Cursor、Ramp 和 Meta Cursor Router (https://www.eigent.ai/blog/cursor-router-model-routing)、Ramp Router (https://ramp.com/router/) 以及 Meta 即将推出的 SwitchBoard (https://www.techrepublic.com/article/news-meta-switchboard-ai-model-router/) 展示了相同的模式正在进入产品和平台战略。Cursor 将路由定位为编程助手的一项功能，Ramp 将其作为业务成本优化层进行销售，而 Meta 据报道正在内部构建 SwitchBoard，目的是通过将简单工作转移给更便宜的模型来降低编码成本。 Cursor 表示其路由器使用 AI 根据查询、上下文、任务复杂度和领域对请求进行分类。路由器的主要任务是在请求进入时将简单、常规的工作发送给更便宜的模型，而将庞大、混乱的查询发送给高价格的前沿推理模型。Cursor 声称早期用户成本降低了约 30% 到 50%，在线 A/B 测试显示节省了 60%。 Cursor Router 的销售宣传紧密围绕编码工作流程。Cursor 已经路由了数百万个编码请求，并明确以低成本达到前沿质量输出为目标，提供允许团队在成本与智能之间权衡的模式。 Ramp 将其 Ramp Router 描述为一个兼容 OpenAI 的端点，能够将每个请求发送到最适合任务需求且最具成本效益的模型。Ramp 称其最初内部构建了这个路由器以支持自己的 AI 产品，并将 LLM 成本降低了 30%。现在它正在向外部用户开放该系统。 Ramp 的宣传更广泛且更具操作性。其 Router 页面展示了从发票提取、工单分类到编码、多语言翻译和内容审核等用例。在我看来，这更像是一个流量整形层，而非特定于编码的产品。 Cursor 和 Ramp 都将路由定位为在请求到达模型之前对其进行分类的方式。然后它们将简单工作发送给更便宜的系统，将更难的工作发送给更强的系统。Cursor 表示其路由器根据查询、上下文、任务复杂度和领域对请求进行分类，而 Ramp 表示其路由器根据质量、成本和可用性在模型之间进行选择。 至于 Meta？目前我们还没有详细信息，但目标与其他公司相同：削减 AI 成本。就这么简单。 不过，SwitchBoard 看起来更像是一个内部成本削减平台，而非面向公众的产品发布。这使得 Meta 与 Cursor 和 Ramp 处于同一战略轨道，但动机不同。Cursor 和 Ramp 已经在将路由转化为产品；Meta 似乎首先为自己使用而构建，稍后可能有外部野心。 这些路由器在堆栈中的位置也不同。Cursor 嵌入在 IDE 和 Agent 工作流中，Ramp 定位为多用途企业 API 和支出管理层，而 SwitchBoard 仍然有些神秘。 它们在透明度和路由风格上也存在差异。Cursor 描述了一个经过训练的类分类器，该分类器从 600,000 多个实时请求中学习，并基于在线反馈进行优化；而 Ramp 强调单一端点、回退、支出控制以及跨提供商的兼容性；Meta 公开的细节较少，因此其确切的路由方法仍然未知。 ## 一切都是为了钱 这个类别正在增长，因为模型选择现在是一个优化问题，而不仅仅是能力问题。市面上还有更多 LLM 路由器。我只提到了我认为最重要的几个。随着模型格局日益拥挤且价格差距不断扩大，路由使公司能够像管理船队而非单一船只一样对待 LLM。 构建路由器的公司也在试图掌控应用与模型提供商之间的决策层。这个层可能变得和模型本身一样具有战略意义，因为它控制着支出、延迟以及哪个提供商能首先获得流量。 更大的故事在于，路由正成为应对模型泛滥的新默认答案。随着更强大的模型出现，团队不再希望为每个请求硬编码一个昂贵的选择。他们希望有一个自动化层，只在任务需要的地方花钱。谁又能责怪他们呢？ 这里还存在一种商业模式的讽刺。模型提供商在用户默认使用高级模型时赚得更多，而路由器则在用户花费更少时获胜。因此，路由在构建模型的公司与优化模型使用的企业之间制造了一种持久的紧张关系。这将如何发展，值得关注。 #### TECHSTRONG AI 播客 #### 分享此故事 © Techstrong Group, Inc. 保留所有权利。 页面加载链接 (https://techstrong.ai/articles/llm-routers-have-become-a-service-category-of-their-own/#)你的平台工程 2.0 平台由什么构成？ - 哪个描述最符合你的角色？（单选）* - 平台工程 - DevOps、DevSecOps 或 SRE - 软件工程 - 云或基础设施工程 - 企业架构 - 数据科学、ML 工程或 MLOps - 安全、风险或合规 - FinOps - 工程或 IT 领导 - 顾问或技术供应商 - 其他 - 你所在组织的平台工程现状如何？（单选）* - 运营一个成熟的内部平台 - 运营一个仍在扩展的平台 - 正在构建我们的第一个内部平台 - 评估或规划平台计划 - 运营多个专用平台 - 当前没有平台工程计划 - 不确定 - 你的平台预期带来的主要成果是什么？（最多选三项）* - 提高开发者生产力 - 加速并标准化软件交付 - 改善安全、合规或可靠性 - 控制基础设施、云或 AI 成本 - 支持 AI/ML 开发和运营 - 治理 AI 模型和 Agent - 现代化传统应用 - 支持混合云或多云运营 - 满足数据主权或驻留要求 - 其他 - 你的平台主要由什么组成？（可多选）* - Backstage - 另一个内部开发者门户或服务目录 - API、命令行工具或 Agent 接口 - CI/CD、GitOps 或基础设施即代码 - 自管理 Kubernetes - 托管公有云 Kubernetes - VMware Cloud Foundation 或 VMware vSphere - 其他私有云或虚拟化平台 - 公有云基础设施和托管服务 - 在 Kubernetes 之外管理的虚拟机 - 无服务器或应用平台服务 - 裸金属基础设施 - 多个平台，无共同控制层 - 不确定 - 其他 - 你的组织如何支持 AI 工作负载？（单选）* - 扩展现有平台以支持 AI - 构建独立的 AI/ML 平台 - 将平台连接到外部模型 API - 使用托管的公有云 AI 平台 - 运营私有 AI 平台 - 结合外部服务与内部托管模型 - 支持 AI 实验，无需正式平台 - 目前不支持 AI 工作负载 - 不确定 - 目前可用的 AI 特定平台能力有哪些？（可多选）* - AI 网关或统一模型访问 - 模型注册、评估或服务 - AI 特定可观测性 - Token 或推理成本核算 - GPU 供应、调度或优化 - Agent 身份与权限 - Agent 行为防护与审计 - MCP 服务器发现或治理 - 数据访问、血缘或驻留控制 - 以上均无 - 不确定 - 你的 AI 治理和成本控制成熟度如何？（单选）* - 嵌入平台各层面，拥有明确所有权和成本归属 - 部分集中，但仍存在重要差距 - 由各团队单独管理 - 主要在部署后或成本发生后实施 - 没有一致的治理或成本控制模型 - 不适用 - 不确定 - 阻止你的平台交付业务期望的最大限制是什么？（单选）* - 平台采用或开发者体验 - 编排与集成 - Kubernetes 或工作负载管理 - 基础设施或 GPU 可用性 - 数据访问与治理 - AI 模型或 Agent 管理 - 安全或合规 - 可观测性 - 成本可见性与 FinOps - 平台技能或人员配置 - 资金或高管支持 - 难以展示平台价值 - 其他 - 可选：你最需要添加或改进的一项能力是什么？ - 你是否愿意参与一个简短的后续访谈？（单选）* - 愿意 - 不愿意 - 如果愿意，请分享你的联系信息（姓名、邮箱和公司），以便我们联系。 × (https://techstrong.ai/articles/llm-routers-have-become-a-service-category-of-their-own/#) 返回顶部 (https://techstrong.ai/articles/llm-routers-have-become-a-service-category-of-their-own/#)