每日AI简报

OpenRouter + Langfuse:一个接口收口所有模型,再把每一分钱记成台账

6 个部分约 15 分钟本文 5839 字
PART 01

今天这两个工具能接成一条线。OpenRouter 把各家模型收成一个接口,Langfuse 把每次调用的 token 与成本记成可查明细。

选它们是因为账能算清:前者的抽成不在调用上,在充值上;后者的计费单位不是请求数,是三个计数相加。两个主角本期均未在你的账号部署或实测。

PART 02

主角一 · OpenRouter:一个 OpenAI 兼容入口,抽成藏在充值环节

段 1 · 是什么

它替你把接模型收成一次配置。你只维护一个 base_url 和一份模型 slug,换模型不用换 SDK,也不用在十几个控制台各开一个 key。

省掉的动作很具体:上游某家机房抖动时,它在同一个请求里换 provider 重试,你的代码不用写重试分支。

段 2 · 多少钱

全球统一美元标价,核验日期 2026-10-07。官方原话是推理不加价,只转发上游定价。

它稳定收的钱在充值环节:

| 项目 | 费率 | 说明 ||---|---|---|| 充值手续费 | 5.5%,最低 $0.80 | 按充值额收,不按调用收 || 加密货币充值 | 5% | USDC || 自带 key(BYOK)超额度后 | 5% | 按同模型同 provider 在 OpenRouter 上本应付的价计,从余额扣 || 推理本身 | 0% | 转发上游标价 |

免费额度要把 FAQ 与限速文档拼起来读:

  1. 有免费模型变体,slug 以 :free 结尾,也有 openrouter/free 自动选免费模型的路由。
  2. 免费模型限速看历史累计充值额:不足 10 credits 是每分钟 20 次、每天 50 次;满 10 credits 是每天 1000 次。
  3. 限速文档补充:为吸收手续费与取整,实际 9 credits 就按高档算。
  4. BYOK 免费额度按等效标价成本算,不按请求数算,按量付费档每月 $25,000 等效成本内不收那 5%。

新账号有一点免费额度可先试,但免费模型档不适合放进生产。坑逐条写:

  1. 5.5% 只在充值时收一次。很多人以为按调用抽成,于是把成本估高。真实算法是上游标价乘 token 数,再摊充值手续费。
  2. BYOK 的 5% 从余额扣,余额为 0 时怎么处理,官方页没正面写。
  3. credits 有过期条款,官方保留在购买满一年后清掉未使用额度的权利。
  4. 退款窗口只有 24 小时,逾期额度与平台手续费不退,加密货币一律不退。支付方式为信用卡、支付宝、USDC。

段 3 · 适合谁

只固定用一个模型、每月调用几百次,直接找官方开 key 更省事。

段 4 · 局限

  1. 免费模型只有每分钟 20 次。付费模型没有平台级请求上限,免费变体一律卡在这个数。
  2. 余额低会撞「在途额度」。请求发出时按输入 token 加 max_tokens 先预扣估算,并发多处就可能凑不满。没设 max_tokens 时按固定上限估,更容易被拒。
  3. 报错要按来源分支。error.metadata.limit_source 为 openrouter_in_flight_budget 就等 Retry-After 重试;为 openrouter_credits 是单个请求太贵,重试没用。
  4. 上游 429 会被自动吃掉。provider 限流时系统换一家重试,成功请求背后可能已换过机房,延迟与缓存命中都和首选不同。
  5. 流式请求的限速不走 HTTP 状态码,错误以 SSE 事件里的 finish_reason: "error" 送达,按 429 抓抓不到。

段 5 · 今天怎么开始

  1. base_url 指向 https://openrouter.ai/api/v1,协议与 OpenAI 一致,model 传它的 slug,形如 openai/gpt-oss-20b。
  2. 先充 10 credits,把免费模型日限从 50 次抬到 1000 次。
  3. 把 GET /api/v1/key 挂进监控。它返回 limit_remaining、usage_daily、byok_usage_monthly 与 free_model_daily_requests.remaining。
  4. 用 slug 后缀选路由,三者对所有模型生效::floor 按价格排序,:nitro 按吞吐排序,:exacto 按工具调用可靠性排序。
  5. 配 fallback 模型列表与 provider 路由偏好,前者在首选模型全部 provider 挂掉时兜底。
  6. 上量前先算成本:上游每百万 token 标价乘 token 数,再叠加充值的 5.5%。这是按官方费率算的,未实测。

段 6 · 来源

02 / 配图
PART 03

主角二 · Langfuse:把「这一跑花了多少」变成能对账的数字

段 1 · 是什么

它替你把每次模型调用的花费记成结构化明细。你在代码里打点,它把输入输出、token 数、耗时、成本按 trace 归好,可以逐条翻。

省掉的动作是不用自己写调用日志表,也不用从供应商后台导 CSV 再拼。它还带提示词版本管理,改一版提示词跑同一批数据集,结果并排看。

段 2 · 多少钱

Cloud 版按美元标价,核验日期 2026-10-07,官方定价页不按地区切币种:

| 方案 | 月费 | 包含 units | 超出单价 | 数据保留 | 摄取吞吐 | 用户数 ||---|---|---|---|---|---|---|| Hobby | $0 | 50k / 月 | 定制 | 30 天 | 1,000 请求/分钟 | 2 || Core | $29 | 100k / 月 | $8 / 100k | 90 天 | 4,000 请求/分钟 | 不限 || Pro | $199 | 100k / 月 | $8 / 100k | 3 年 | 20,000 请求/分钟 | 不限 || Enterprise | $2,499 | 100k / 月 | 定制 | 3 年 | 定制 | 不限 |

超量单价是阶梯的:0 到 100k units 免费,100k 到 1M 是 $8/100k,1M 到 10M 是 $7/100k,10M 到 50M 是 $6.5/100k,50M 以上 $6/100k。Teams 可加购,$300/月。

自托管是另一套逻辑。核心是 MIT 许可,官方原话是核心功能全部免费自托管,不计量不收费;需 license key 的只剩 SCIM、审计日志、保留策略、组织级 RBAC 与 SSO 强制等企业功能。企业版为定制报价,且官方页写明价格叠加在你的 ClickHouse 商业订阅之上。

unit 的定义是全文最值钱的一条。官方计费单位文档原话:units 等于 trace 数加 observation 数加 score 数。还补了一句,由 Langfuse 自身功能生成的 trace、observation、score 同样计费,包括模型裁判的自动评分和标注队列的标注。官方样例:20,070 个 trace 加 119,500 个 observation 加 561 个 score,等于月度 140,131 units。

段 3 · 适合谁

只做单次调用、不回溯历史,现有日志加一张表就够了。

段 4 · 局限

  1. 计费单位不是请求数。一个 agent 跑一次可能产生 1 个 trace 加十几个 observation 再加两个评分,按请求数估成本会低好几倍,这是最容易算错的一处。
  2. Hobby 只有 2 个用户、数据只留 30 天。团队一进来要么升 Core,要么换自托管。
  3. 免费档摄取吞吐限 1,000 请求/分钟。批量回灌历史数据时上限先到,超限是排队还是丢弃,官方页没写明。
  4. 多模态 trace 在 beta 期免费,这句话不承诺之后的计费方式,长期按它排预算不稳。
  5. 自托管不是零成本。官方架构页写明要自己跑 Postgres、ClickHouse、Redis 或 Valkey、对象存储四个组件,外加两个应用容器。

段 5 · 今天怎么开始

  1. 先测自己的 units 比率,别按请求数估。官方给的方法是在项目里打开 Dashboards,进 Langfuse Usage Management,时间范围选最近 30 天,把 Total Trace Count、Total Observation Count、Total Score Count 三个数加起来。2. 接法有三条:Python 或 JS SDK 直接打点;Java、Go 或自研栈走 OpenTelemetry;已有 LiteLLM 网关就开它的代理日志转发。
  2. 关键细节是 flush。短生命周期进程必须显式 flush,否则进程退出时缓冲区里的 trace 直接丢。
  3. 打点时把模型名和 token 数带上,成本才自动算得出来。只记耗时,台账里就没有钱。
  4. 先在 Hobby 跑两周拿到真实 units,再对比 $29 的 Core、$199 的 Pro 和自托管三条路。

段 6 · 来源

03 / 配图
PART 04

一条能跑起来的最小流程

输入是一批真实调用,产出是按模型、按天、按项目分好的成本台账。

  1. 入口收口:所有调用改走 https://openrouter.ai/api/v1,散落的 base_url 与 key 全删掉。
  2. 定路由:离线批处理用 :floor,实时接口用 :nitro,需要工具调用用 :exacto,同时配一份 fallback 模型列表。
  3. 过一层网关:已有 LiteLLM 就让它转发,没有就直连。注意限速是账号级,多开 key 不会扩容。
  4. 打点:每次调用外套一层 Langfuse 的 generation 记录,带上模型 slug、输入输出 token 数与耗时。脚本与 Serverless 退出前显式 flush。
  5. 每日对账:拉 GET /api/v1/key 拿 usage_daily 与 byok_usage_monthly,和 Langfuse 当天成本汇总做差,两条对上才算可信。
  6. 算 units 比率:跑满两周后从看板取三数相加除以请求数,这个数决定你该买哪一档。
  7. 异常分支:402 先读 error.metadata.limit_source 再决定重试还是加钱,429 先看 error.metadata.provider_code。

第 5、6 步是关键:两边数不对上,说明有调用没打点。

04 / 配图
PART 05

可以直接复制的提示词

你是 LLM 成本对账器。我给你两组数据:Langfuse 的某月用量(trace 数、observation 数、score 数),以及 OpenRouter 的某月用量(usage_monthly、byok_usage_monthly、充值金额)。 只输出一个 Markdown 表格加三行结论,不要引言,不要建议清单。 表格列固定为:项目、数值、来源、口径说明。数据里没有的项,数值列填 null,不要估算,不要编造。 三行结论分别回答:一,Langfuse 的 units 与请求数换算比率,算式写出来;二,OpenRouter 的 credited 用量与 BYOK 用量各占多少;三,两组数据是否对不上,对不上就指出可能漏记的那一类调用。 所有数字必须与输入完全一致,不得改写或换算单位。

怎么判断这次输出合格:抽三条逐项回原始数据核对。一是三个计数相加等于 units 合计;二是所有数字与原始导出一字不差;三是「对不上」那条结论具体到调用类型。三项都满足才算过。

PART 06

边界声明