智能路由项目 · 进度汇报

在 LiteLLM 网关上的请求级智能模型路由

汇报人 hsh · 日期 2026-05-21（周四）· 阶段 MVP · 联调前

项目概览：我们在做什么 · 为什么做

在 LiteLLM（统一代理多个大模型的网关）上加一层智能路由 —— 客户端只填一个占位模型名，系统自动决定这次该用哪个真实大模型。

三大价值

• 用得划算 —— 简单请求走便宜模型、难请求才上贵模型。不为每一次调用都付高价。
• 全程可追溯 —— 每条请求都记录「为什么这么选」，事后随时可查，便于排查与优化。
• 客户端零改造 —— 调用方代码不用改；后端增减、替换模型，对业务无感。

💡 一句话：让每一个请求自动落到「能力够用，又最划算」的模型上，决策过程透明可查。

路由设计：一次请求是怎么被路由的

请求进来后，在发给真实模型之前，会顺序走完六步判断：

↓ 把选中的模型交还给 LiteLLM 正常发出 —— 整个过程毫秒级，每一步判断都记录在案。

💡 这六步对应五块能力：日志采集 · 硬约束过滤 · 难度分类 · 会话粘性 · 加权随机选择 —— 共同保证「选得对、选得稳、选得划算」。

部署架构与一项关键调整

「判难度」这一步要靠一个小模型完成。整条链路原本设想拆成三块独立部署，本周对齐后决定合并中间一块。

原设想：三块各自部署

LiteLLM 网关（我们的路由层所在）
    → 网络 →
预处理层（独立后端服务，整理/加工请求）
    → 网络 →
4090 服务器（跑小模型，判断请求难度）

本周决策：合并为两块

LiteLLM 网关 ＋ 预处理函数（合并部署，代码仍隔离）
    → 网络 →
4090 服务器（跑小模型，判断请求难度）

⚠️ 为什么合并：中间层独立服务部署不顺、还要为它单独搭一套压测环境，成本不划算。合并后代码仍隔离成独立函数 —— 算法侧能单独维护，互不干扰。

目前进展：代码侧已就绪

五块核心能力全部开发完成并通过测试，路由逻辑本身已具备上线条件。

功能完成情况

测试数据

✅ 结论：代码侧风险已基本收敛。当前未完成的部分，是与算法侧的联调和真实环境压力测试。

本周卡点：周三为何未完成

周三的计划是对 4090 上的小模型做上限压力测试（测它每秒能扛多少请求），没能完成。

🚧 卡点：压测服务器到 4090 的网络一直没连通

• 压不出可信数据 —— 没有低延迟的网络环境，压测结果会被网络拖累、不能作数 —— 压了也白压。
• 中间层也部署不起来 —— 预处理服务在测试环境起不来 —— 已据此决定合并进 LiteLLM（见上页），规避这块。

✅ 定性：这是外部网络/运维环境的依赖问题，不是路由代码的问题。代码侧已就绪、测试通过，环境一通即可推进。

本周怎么推进

环境与代码两条线并行推进，目标是周五盘后完成第一次上线测试。

今天（周四 · 05-21）

• 算法组：前往现场探索压力测试，排查并打通压测服务器到 4090 的网络。
• hsh：继续修改代码，把算法侧预处理代码合并进 LiteLLM、做成隔离函数。

→ 周五盘后（05-22）

• 关键节点：利用盘后窗口做上线测试 —— 智能路由在真实环境第一次端到端跑通。

💡 盘后窗口业务量低、影响可控，是验证的安全时机；前提是今天网络能打通。

下周方向（视本周结果）

上线测试跑通后，下周从「能跑」转向「调优」，重点有三块：

1. 路由策略探索 —— 对比两种取向：优先省成本（命中即复用上次模型），还是优先保能力（先选够用的模型再省钱），考虑让业务方按需选择。
2. 分类模型优化 —— 算法侧持续打磨判难度的小模型，提升分类准确率与响应速度。
3. 优化目标的取舍 —— 明确到底优化什么、如何平衡：成本、缓存命中率、首字响应速度、难题档模型的能力上限，几个目标之间需要决策定夺。

💡 下周具体节奏取决于本周上线测试的结果；若环境受阻，下周首要任务仍是打通联调。

小结 · 风险与信心

总体判断：项目主体进展顺利，路由逻辑已就绪；当前瓶颈是外部环境，不在代码本身。打通网络后即可快速推进上线。