Higress vs LiteLLM

目录

• 🆚 场景对比：控制租户 A 的大模型预算
  • 1. LiteLLM 的做法（有状态的“SaaS”管家）
  • 2. Higress 的做法（无状态的“交警”）
• 💡 核心边界总结（一句话看透）
• 给出你的最终行动指南：

你总结得非常接近本质了！但为了你在技术选型时绝对精准，我需要做一个微调：

Higress 并不是不能精细到“租户/用户”维度，而是它在“租户/用户”维度上，只做“无状态的流量拦截”，不做“有状态的资产管理”。

为了让你彻底看清两者的底层逻辑差异，我们用一个最经典的场景——“给楼宇客户 A 设置 500 块钱的大模型预算”，来看看 Higress 和 LiteLLM 分别是怎么处理的。

---

🆚 场景对比：控制租户 A 的大模型预算

1. LiteLLM 的做法（有状态的“SaaS”管家）

LiteLLM 内部自带了一个数据库（PostgreSQL）。它知道什么是“钱”，什么是“账户”。

• 配置阶段：你调用 LiteLLM 的 API：给 Tenant_A 充值 500 元。LiteLLM 把它存进自己的数据库。
• 运行阶段：Tenant_A 每次发起请求，LiteLLM 会在内部数据库里自动扣钱（比如扣了 0.01 元）。
• 熔断阶段：当扣到 500 元时，LiteLLM 自动拒绝 Tenant_A 的请求，提示 "Budget Exceeded"（预算超限）。
• 结论：LiteLLM 在业务资产维度管理到了租户。

2. Higress 的做法（无状态的“交警”）

Higress 作为一个纯粹的网关，它内部没有数据库，它不懂什么是“钱”，也不记账。但它能识别流量上的“车牌号”（TenantID）。

• 配置阶段：你不能告诉 Higress “给 A 充 500 块”。你只能通过配置规则告诉 Higress：“如果 Header 里 TenantID=A，限制他每分钟最多消耗 1000 个 Token”。
• 运行阶段：Tenant_A 发起请求，Higress 看到车牌号是 A，放行，并在日志里记录：“A 消耗了 50 个 Token”。
• 熔断阶段：如果 A 这一分钟内消耗了 1001 个 Token，Higress 自动拦截。但到了下一分钟，Higress 又会放行（因为它是限流，不是扣费）。
• 如何实现 500 元阻断？
  你必须自己写一个后台程序，实时拉取 Higress 的日志，自己算账：“50 Token = 0.01 元”。算到 500 元时，你的后台程序去调用 Higress 的接口，下发一条新规则：“把 TenantID=A 加入黑名单”。
• 结论：Higress 在网络流量维度管理到了租户。

---

💡 核心边界总结（一句话看透）

• LiteLLM 管理的是“账户与钱包”：它包揽了多租户的 API Key 分发、计费、账单、预算熔断。它是有记忆的（Stateful）。
• Higress 管理的是“管道与阀门”：它包揽了多租户的身份核实（接你们公司系统）、并发限流、路由分发、大模型宕机切换。它是没有记忆的（Stateless）。

给出你的最终行动指南：

既然你们公司不支持 OIDC，且必须深度集成现有的内部账号和角色权限，那么：

👉 强烈建议你选择：Higress + 自研账单模块

理由：

1. Higress 可以极其丝滑地对接你们公司现有的鉴权系统（通过 Ext-Authz 插件），直接提取出你们现有的 UserID 和 TenantID。
2. 你的 Agent 带着现成的公司 Token 就能一插到底，不需要搞恶心的“Token 交换”。
3. 大模型的路由、容灾切换交给 Higress 的 ai-proxy 插件。
4. 至于“租户消耗了多少 Token”，你们的后端自己写个脚本，每天晚上去拉一次 Higress 的统计日志，存到你们自己的 MySQL 里算账就行了。

这样做，整个系统完全长在你们公司现有的基础设施上，架构最干净！