Hacker News 上有人发了个新项目,标题挺敢说:我们做了个开源版OpenRouter,能把用量变成更好的模型。这类标题在HN上不新鲜,但这次的野心更大:项目团队 Experiential 不只想做一个统一入口,把OpenAI、Anthropic、Gemini、本地模型全塞进一个OpenAI兼容API,还想吃掉更值钱的一层——拿你的真实流量,训练出一个专属路由器,甚至一个专属模型。问题是,这个更值钱的承诺,证据够不够撑得住?

一个网关,两层野心

Experiential 分两层。第一层是基础设施——统一接入托管模型、BYOK(自带密钥)、本地模型和自定义模型,按用户和agent设定可用模型、用途和花费上限,命令预算默认 $50。这一层,LiteLLM、Portkey早就在做。

第二层才是它想差异化的地方:用 exp buildexp optimize model,把生产环境跑出来的 OpenTelemetry 调用记录喂给优化引擎,吐出一个针对质量、速度、成本调过的专属路由器,还能用 Tinker 微调出一个专属开源模型。这才是标题里"turns usage into a better model"真正指的东西。

代码走 Apache 2.0 全开源,这点没什么争议。


架构拆开看:一台跑得快的车,配了一个跑不动的账本

网关用 Rust 写了原生数据面接公共端口,处理性能敏感的转发路径;Python 这边管鉴权、策略、预算和落盘,用 SQLite(WAL模式)记账——每次调用单独记一行,调度前先预留一笔保守成本,拿到真实用量后再替换,价格未知就保持未知,不当0处理。这个设计比很多网关粗暴写死价格表的做法更谨慎。

但账本这层,恰恰是团队自己benchmark里捅出来的窟窿:不管走Rust引擎还是Python引擎,最终都要撞上同一句话——同步fsync写入。每次请求大约走六次同步事务,单进程吞吐撞上天花板,大约每秒 30到50个请求

快车配了一个慢账本 Rust原生数据面 接公共端口 低并发~20ms Python策略层 鉴权/预算 落盘记账 SQLite记账(WAL) 同步fsync写入 天花板30-50/s 无论走哪条引擎,最终都撞同一个账本

19.9毫秒和7.2秒,哪个是真的

CI里挂着的延迟徽章显示网关代理延迟中位数 19.9毫秒,漂亮,但测试对象是本地mock,不是真实付费供应商。团队自己另发的一份深度benchmark(16-vCPU Azure VM)才是硬货:低并发下原生引擎首字节延迟约25毫秒,确实快;但拉到128并发流时,Python引擎中位首字节延迟飙到约 7.2秒,最长能到12.6秒。吞吐上,原生引擎每进程约21,000 tokens/s,Python引擎约2,000 tokens/s,差了一个数量级。接上真实供应商后,低并发下原生引擎首字节延迟约20毫秒、Python约150毫秒,但持续请求速率两者最终都被锁在每秒约30个请求上下——被前面说的SQLite同步写入天花板兜了底。

延迟徽章 vs 深度benchmark 19.9ms CI徽章·测试对象是mock 25ms 深度benchmark·原生引擎低并发 7.2s 深度benchmark·Python引擎128并发 30-50 真实供应商·请求/秒上限
好看的延迟徽章,挡不住账本天花板。
  • 风险.多租户或高并发coding agent场景下,单进程30-50请求/秒的写入天花板可能是真实瓶颈,团队尚未公开横向扩展路线图。

老子说"信言不美,美言不信",放这儿挺合适:好看的数字往往不是要紧的那个数字。19.9毫秒是讲给帖子听的,30到50请求/秒是讲给工程选型听的。

"喂流量,吐好模型"这句话,证据在哪

官方自己发布的W16路由器沙盒证据文档,用100条标准化traces做的是确定性的本地评测,并明确写清楚:这份证据不能证明托管供应商环境下的质量,也不能证明云端一致性。也就是说,"把用量变成更好的模型"目前唯一公开的证据,是一次可控条件下的沙盒模拟,不是真实客户在真实供应商上跑出来的效果。这跟Show HN标题的语气,差了一截。

卖点之外,还有几件没讲透的事

定价上,Free层 $0/月、0%代币加价,BYOK请求按供应商价格直通;Enterprise是定制价,包含SAML/SCIM、高级RBAC、私有网络、数据驻留、SOC1审计,以及"基于客户流量训练的模型"。跟LiteLLM完全免费自托管、OpenRouter靠交易抽成的打法比,这套免费引流、企业变现的模式能不能撑住,现在还看不清。

  • 结论.Free引流靠0加价换用户,护城河真正要考的是Enterprise那句"基于客户流量训练的模型"能不能兑现,这才是收入的落点。

README里还藏着一个容易读错的细节:默认开启的PostHog产品分析telemetry(声称不含prompt、trace、模型名),和用户主动上传的LLM traces,是完全不同的两套机制,却都叫"telemetry"。这种命名放到对隐私敏感的开源社区里,很容易被误读成"默默把调用记录传回服务器"。这条Show HN帖子在Hacker News上的真实讨论目前尚未找到索引,社区到底怎么反应,还不可考。

值得一提的是,即便是专业的横向检索工具,也很容易把"experiential AI gateway"理解成一种通用架构范式,而不是特指这家叫Experiential Labs的公司——说明这个项目的品牌辨识度还很低,离它自称的"开源版OpenRouter",还有一段路。

接下来该盯的三件事:SQLite瓶颈有没有解决路线图,W16证据能不能补上真实托管环境的数据,以及Hacker News上真正的讨论热度会不会印证它现在的定位。