Experiential 是一个覆盖 1000+ 模型的 BYOK 零加价网关。它会从流量中学习，以压低成本并推荐更合适的模型。适合需要自建多模型路由的团队。 定价：开源免费（含托管平台）。编辑评分：⭐ 4.5。
Experiential：自带 Key 的零加价多模型网关，值不值得自建？
Experiential是什么？
一句话说清楚：它是一个模型网关，你把自己在各个模型厂商的 API Key 接进去，它帮你统一转发到 1000+ 个模型上，而且不加价。
BYOK 就是 Bring Your Own Key——钥匙是你的，账单也是你的，网关本身不从 token 差价里赚钱。这跟很多"帮你省事但每百万 token 抽一笔"的中转服务思路完全不同。
它还有一点比较有意思：会从你的实际调用流量里学习，用来压低成本、推荐更合适的模型。说白了就是你用着用着，它慢慢知道哪些活儿该派给便宜模型，哪些必须上贵的。
项目托管在 GitHub（github.com/experientiallabs/experiential），2026 年 9 月首发，最近在 GitHub 周榜上新增了 544 星（来源：GitHub Trending）。热度不低，但确实还是个新项目，这点后面会展开说。
核心功能
1. 覆盖 1000+ 模型的 BYOK 网关
这是它的基本盘。你不用为每家厂商单独写一套调用逻辑，接一次网关，后面换模型基本就是改个参数的事。对已经有一堆 Key 在手的团队来说，迁移成本不算高。
2. 零加价转发
调用请求原样转发到对应厂商，网关不在中间加价。对调用量大的团队，这一点比"功能多"重要得多——省下的是真金白银，而且账目更清楚：你付给谁的，一目了然。
3. 多模型路由与统一接入
统一入口，统一鉴权，统一日志。实际使用中，这类统一层最大的价值往往不是"能调很多模型"，而是排障时不用在五六个后台之间来回跳。团队协作时谁在用什么模型、花了多少，能在一个地方看到。
4. 基于流量的成本学习与优化
它会观察你的调用模式，找出成本上的浪费点。注意这是"学习型优化"，不是魔法——你得先有真实流量它才有东西可学，冷启动阶段别期待太高。
5. 更合适的模型推荐
根据你的实际使用情况推荐模型，而不是推一个通用榜单。这个功能的价值取决于你愿不愿意认真做 A/B——如果只是看一眼推荐就关掉，那它基本等于不存在。
版本/套餐对比
这里得说实话：官方目前没有公开分版本定价或套餐信息，项目以 GitHub 仓库形式分发。所以与其编一张看着漂亮的对比表，不如把已知的客观事实列清楚：
| 维度 | 现状 |
|---|---|
| 获取方式 | GitHub 仓库（experientiallabs/experiential） |
| 计费模式 | BYOK，零加价；模型调用费用由各厂商 API Key 直接结算 |
| 价格/套餐 | 官方未公开分层定价信息 |
| 模型覆盖 | 1000+ 模型 |
| 部署方式 | 团队自建部署 |
换句话说，你能不能"买到"它，取决于你愿不愿意自己部署和运维——因为项目方本身不靠 token 差价赚钱，商业模式这块目前也不是很清楚。真要上生产，建议自己盯一下仓库的更新节奏和 issue 活跃度。
值不值得用？
先说优点，都很实在：
- 1000+ 模型一个入口，多模型路由这件事终于能收敛到一层
- 零加价，调用量越大越能感受到差别
- 会从流量里学，长期看有机会把成本结构压下来
- 团队自建，数据和控制权都在自己手里，合规上省心
再说缺点，也别装看不见：
- 你得自备各家的 API Key，Key 越多，配置和权限管理越麻烦
- 自建部署不是一键脚本级别的活，后续运维需要有人管
- 项目很新，生态成熟度和长期稳定性都还需要时间验证
- 成本学习和模型推荐都要靠流量喂，前期收益有限
- 项目方不靠加价赚钱，商业模式不明确，长期路线图有不确定性
结论：值得关注的工具，但不适合所有人。 如果你团队本来就在维护多厂商 Key、调用量不小、又愿意投人做部署，那它值得认真评估一轮。如果你只是想找一个开箱即用的模型接口，那它大概率会让你觉得折腾——这种需求用托管型服务更省心。
使用建议
- 先小范围跑通，别一上来全量切。挑一个非核心业务接进去，验证转发稳定性、错误处理、限流表现，再考虑扩大范围。
- Key 管理要提前设计。每家厂商的 Key 权限、额度、轮换策略都不一样，最好在上线前就定好谁能碰、存在哪、怎么轮换。
- 给路由设明确的降级和兜底规则。别全指望自动推荐，先把"贵模型失败→切便宜模型""超预算→暂停"这类规则写死。
- 冷启动阶段别太依赖优化建议。流量少的时候，它的学习结果参考价值有限，等数据量起来再看。
- 把运维成本算进决策里。部署不难，长期维护才花时间，先问清楚团队里谁负责。
- 盯住仓库更新。项目新，版本迭代可能比较快，升级前看清楚 changelog 和破坏性变更。
适合谁用？
推荐
- 已经在多个模型厂商之间来回切换、Key 一堆的中大型团队
- 对 token 成本敏感、调用量能撑起优化空间的业务
- 有明确数据合规要求，需要自建网关、控制权在自己手里的团队
- 有专门的基础设施/平台工程人手能接住部署和运维
可考虑
- 模型调用量中等、正在从单厂商往多厂商过渡的小团队
- 想先搭一套统一接入层、为将来做技术储备的团队
- 有技术能力但运维人力紧张的团队——能跑起来，能不能长期养住要打个问号
不推荐
- 只想调一个模型、图省事的个人开发者
- 完全没有人手做部署和运维的团队
- 需要稳定 SLA 和成熟商业支持的生产环境
- 对长期维护性要求高、不愿意押注新项目的团队
