背景与动机
为什么需要 LLM 路由
多数团队以轮询或权重规则起步——初期尚可满足需求，但很快便会显现局限。
问题出在哪里
03 / 问题- 模型持续分化。各模型在价格、速度与擅长任务上差异显著，且每个季度均有新模型加入。
- 请求承载语义。请求不再仅是 URL 路径，而包含对话、工具输出与各类指令，难以由一份静态配置涵盖。
- 策略变化快于配置。业务侧期望自行调整路由策略，而非每周提工单申请修改规则。
「纯 LLM 路由」指什么
路由决策本身由一次 LLM 调用完成——既非旁路挂载的轻量分类器，亦非完全由人工维护的规则树。其输入输出的形式与边界，详见技术方案页。
其收益在于灵活性：语义理解、自然语言策略、规则爆炸的消解。代价则是延迟、成本与可解释性——这些是方案设计中明确纳入考量的工程约束，对应的取舍见技术方案页。
收益
语义理解、以自然语言描述策略、在意图多变时显著降低规则爆炸的风险。
代价
额外的延迟、真实的 token 成本、更复杂的可解释性，以及更严格的安全边界设计。
与相关概念的区分
03 / 区分- API 网关 本项目的关注点在于「本次请求进入哪个模型」，而非仅限鉴权与限流。
- 负载均衡 upstream 列表可分摊流量，但不会解析请求体中的语义。
- 简单 Prompt 路由 常见做法是一次性分类打标；本项目的目标是贯穿整条链路、与策略绑定的决策。
适用场景
用例- 代码生成交由大模型，内容摘要交由轻量模型。
- 以自然语言描述「新后端先承接 5% 流量」等策略。
- 客户端 SDK 保持不变，后端可更换供应商。
从规则到语义。OrangeRouter 用一次 LLM 推理取代难以维护的静态规则表：以语义理解与自然语言策略驱动路由，把规则爆炸的问题交给模型解决。技术实现见技术方案页。