对比
FluxMeter 与 Orb
Orb 是面向 AI 的用量计费平台,文档描述的流程是:事件 → 指标 → 价格 → 订阅 → 发票,并支持可划扣的预付 credits、commitments 和阈值开票。FluxMeter 是开源 LLM token 计量层,带可选的请求前预算闸,并把每客户用量导出到 Orb 等计费系统。两者处在不同层,通常互补使用。
审阅日期:
方法
将 2026-11-03 查阅的 Orb 官方文档与 Orb 自有公开资料,与 FluxMeter 的 claim 注册表、`llms-full.txt` 和引擎集成文档对照。本页不做定价、规模或延迟方面的优势声明,也不因 Orb 解决的是更广的计费问题而说它有所不足。
1. 摘要
Orb 公开资料描述的是面向 AI 的用量计费:原始事件不可变地存储,指标是在事件上的查询,价格、方案和订阅把指标变成费用,最后生成发票。计价单位可以是 token、Agent 运行次数、结果或 credits。
FluxMeter 公开资料描述的是 LLM token 计量、客户级用量成本归因、可选的请求前硬门控,以及向计费系统导出。FluxMeter 不是计费 UI、不是发票记录系统,也不是计费引擎。
2. 范围与方法
本页只对比产品类别与集成边界。Orb 一栏只引用 Orb 官方文档或 Orb 自有公开页面;核实不了的写"未在本次审阅的公开资料中核实"。
一方缺少另一方的某项能力,通常是类别差异,不是质量评判。本页不比较价格、规模、延迟或市场份额。
3. 产品类别差异
Orb 是计费平台,用量摄入与计量是其计费能力的一部分;FluxMeter 是计量 + 控制层。两边都讲 metering:Orb 的计量服务于定价和发票,FluxMeter 的计量服务于 LLM 调用路径上的客户级归因与准入。
FluxMeter 与计费平台互补,而不是替代:它负责计量、归因 token 用量并可拦截请求(不保证零超支),Stripe、Lago、Orb、Metronome 或 Zuora 负责把用量变成价格、发票和收款。
解读:Orb 把用量变成价格、credits 与发票;FluxMeter 产出可信的每客户 token 用量,并提供可选的请求路径控制。
FluxMeter 是 Orb 的替代品吗? 不是。两者处在不同层,FluxMeter 会把用量导出到 Orb。
4. 事件摄入与计量
Orb 文档描述:带时间戳的事件发送到其摄入 API,以不可变方式存入列式存储,摄入时不做聚合。指标(billable metric)是在原始事件上的查询,新定义的指标可以直接对历史数据计算,无需重新摄入。Orb 还文档化了 SQL 定义的指标,以及事件回填与修正。
FluxMeter 文档描述的是 LLM token 事件的单一路径:SDK 或 Gateway → HTTP Custody → Kafka 确认 → Flink 用量聚合 → Redis 查询状态 → Usage API。可按客户、周期、日、模型、会话和 Agent span 查询。
5. 定价与开票
Orb 文档描述了价格(含阶梯、套餐、按量等模型)、方案、带客户专属覆盖条款的订阅、多维定价,以及逐项列明的发票。它还文档化了阈值开票:订阅的用量费用一达到设定金额就立即开票。
FluxMeter 用定价目录做用量成本归因,算的是每个客户的 token 在上游花了多少钱。这是成本归因,不是按客户价格方案做 usage rating。FluxMeter 不开票、不收款、不做收入确认。
6. 预付 Credits、Commitments 与划扣
Orb 资料描述的预付 credits 是让客户"预先购买余额,并随使用逐步划扣",还包括预付账本、充值(top-up)以及可设不同生效 / 过期时间的 credit 块。
Orb 文档描述两种 commitments。后付 commitment 按最低消费划扣,不足部分由 Orb 以 true-up 补收;预付 commitment 是预先开票的 credit 池。Orb 文档写明 commitments"目前仅向部分客户开放"。
FluxMeter 不维护这套账本。在 预付划扣 和 commitment 场景里,FluxMeter 提供每客户用量和可选的预算信号;划扣账本和 true-up 在你的计费系统里。在这个组合中,计费系统就是 Orb。
7. 预算 / 控制路径
FluxMeter 的可选控制发生在 LLM 调用之前或调用过程中:
- 请求前预算检查(
GET /budget/{id}/check),即 硬门控 - 流式响应的 预留 / 对账
- 按客户、按 key、按 Agent span / 会话的预算
- Gateway 编排:估算 → 门控 → 预留 → 上游
FluxMeter 的预算检查能降低超支风险,但不保证零超支:缓存回退、流式估算和并发请求仍可能超出上限。预算检查本身不产生预占,生产加固由运营方负责。
计费侧:Orb 文档描述了阈值开票和支出管理告警(余额耗尽、费用超限、分组费用告警),由你的应用在收到告警后阻止产品访问或使用。Orb 的指南也提到余额耗尽与告警之间有短暂延迟,并给出了处理方式。位于 LLM 请求路径上、逐次放行或拒绝调用的门控,未在本次审阅的公开资料中核实。两者作用的位置不同,可以叠加使用。
8. 部署与运维
FluxMeter 采用 Apache 2.0 许可、自托管,文档描述的是经 make demo 启动的单一 HTTP Custody 路径。演示环境的鉴权可能是可选的,公开暴露前请启用 API key。本页不声称存在由 FluxMeter 运营的 SaaS。
Orb 资料把自己描述为托管计费平台。Orb 自托管部署未在本次审阅的公开资料中核实。
背景:Orb 表示其被 Adyen 收购一事已于 2026 年 7 月 1 日完成,产品"继续作为独立平台运营",客户可继续选择自己的支付处理商。
9. 集成边界(导出)
FluxMeter 内置 Orb 导出器,与 Stripe、Metronome 导出器同级:
- 设置
BILLING_EXPORT_TARGETS=orb,并用POST /admin/billing/{id}/link把每个 FluxMeter 客户映射到 Orb 外部客户 ID。 - 每个导出周期(默认每小时)把用量增量发送到 Orb 的 ingest 端点。每个客户、周期和 token 类型使用稳定的幂等键,重跑同一周期不会重复计数。
- events 模式发送带
token_type(input / output)和tokens的token_usage事件。你在 Orb 中配置指标求和,由 Orb 套用价格。 - cost 模式发送 FluxMeter 按定价目录归因的用量成本。请慎重选择:若定价由 Orb 负责,就导出原始 token 数。
FluxMeter 向 Orb 导出什么? 去重后的每客户、每周期 token 用量增量(输入 / 输出 token,或归因后的用量成本)。指标、定价、credit 划扣、commitments 和开票由 Orb 完成。
字段映射以引擎集成文档(docs/integrations/orb.md)为准。这是 FluxMeter 自带的导出器,不暗示任何合作、认证或官方集成关系。背景阅读:Metronome / Orb 用量导出:保留账单系统,前置预算准入。
10. 何时 Orb 可能更合适
当 AI 产品的计费是主要问题时,Orb 更合适:
- 你需要按 token、Agent 运行次数、结果或 credits 为 AI 产品定价并开票,并使用预付 credits、充值和 commitments。
- 你需要用查询(含 SQL)在原始事件上定义指标,调价时无需重新埋点,并需要托管的发票记录系统。
- 计费侧控制(例如 Orb 文档中的阈值开票和支出告警)已能满足你的风控需求。
11. 何时 FluxMeter 可能更合适
当 token 归因和请求路径控制很重要时,FluxMeter 更合适:
- 需要在 LLM 调用前或调用中按客户、key 或 span 做允许 / 拒绝,并接受"降低超支风险、不保证零超支"。
- 需要开源、可自托管的每客户 token 用量与成本归因查询,且不依赖数据仓库。
- 上游 provider 账单与客户用量对不上。参见 上游账单 vs 客户用量。
- 计费仍放在 Orb 或其他计费系统。
12. 互补使用
FluxMeter 负责计量、归因和可选拦截(不保证零超支),内置导出器把用量写入 Orb,再由 Orb 负责指标定价、credits 划扣、commitments 和开票。
LLM 请求
→ FluxMeter 请求前检查(可选)
→ LLM provider
→ FluxMeter 计量 + 按客户归因用量成本
→ 内置导出(幂等,按小时增量)
→ Orb:事件 → 指标 → 价格 / 订阅 → 预付 credits 划扣与 commitments → 发票 用 FluxMeter 计量 token 用量并可选拦截(不保证零超支);用 Metronome/Orb 定价、跑 credits/commitments 并开票。
对照表
状态为文字标签,不依赖勾选图标。竞争方单元格尽量附来源。
左右滑动查看全部列
| 维度 | FluxMeter | Orb |
|---|---|---|
| 产品类别 | LLM token 计量 + 可选请求前控制;导出到计费系统 内置 | 面向 AI 的用量计费平台 公开资料中已记录的品类能力 |
| 用量摄入与计量 | 经 SDK/Gateway → HTTP Custody 的 token 事件;Flink 按客户做用量聚合 内置 | 原始事件不可变存储;指标即查询(已文档化 SQL 定义指标) 内置 |
| 成本归因 vs 定价 | 用定价目录归因用量成本(成本归因,不是客户价格 rating) 内置 | 价格、方案与带覆盖条款的订阅把指标变成费用 内置 |
| 预付 credits 与划扣 | 每客户用量 + 可选预算信号;无划扣账本 未声称 | 预付 credits 划扣、充值、带过期时间的 credit 块 内置 |
| Commitments | 仅提供每客户用量;无 true-up 未声称 | 后付 true-up 或预付 credit 池;目前仅向部分客户开放 公开资料中已记录的品类能力 |
| 开票与收款 | 不是计费记录系统;不开票、不收款、不做收入确认 外部或示例 | 发票与阈值开票;客户可选择支付处理商 内置 |
| LLM 调用路径上的请求前预算闸 | 可选 check / reserve / reconcile;Gateway 控制 可选 | 告警驱动的支出管理(由你的应用根据告警阻止访问);请求路径门控 未在本次审阅的公开资料中核实 |
| 自托管 | HTTP Custody 路径( 内置 | 未在本次审阅的公开资料中核实 |
| 云 / 托管 | 不声称由 FluxMeter 运营的 SaaS 未声称 | 托管计费平台 公开资料中已记录的品类能力 |
| 许可证 | Apache 2.0 内置 | 未在本次审阅的公开资料中核实 |
| 导出 / 集成 | 内置 Orb 导出器(幂等增量; 内置 | 通过摄入 API 接收用量事件 公开资料中已记录的品类能力 |
审阅日期:2026-11-03
在以下情况 Orb 可能更合适…
- 为 AI 产品定价与开票(token、Agent 运行次数、结果、credits)是核心工作。
- 你希望在托管的计费记录系统中运行预付 credits、充值和 commitments。
- 计费侧的阈值开票和支出告警已能满足风控需求。
在以下情况 FluxMeter 可能更合适…
- 预付式的允许 / 拒绝必须在 LLM 调用前或调用中发生。
- 主要需求是原生 token 的客户级用量与成本归因。
- 开票仍在 Orb(或其他计费系统),通过内置导出器衔接。
选型前核实
- 你需要请求路径控制,还是计费侧告警和阈值开票就够了?
- 核实你的账户能否使用 Orb commitments(Orb 文档写明目前仅向部分客户开放)。
- 核实 Adyen 收购后 Orb 当前的支付处理商选项,只以 Orb 官方表述为准。
- 核实 FluxMeter 导出器版本及其与 Orb 指标的映射,并决定定价放在 Orb(events 模式)还是放在导出的成本里(cost 模式)。
13. 来源与审阅日期
公开资料审阅日期:2026-11-03
- Orb:Usage-based billing built for AI ↗ orb-ai
- How Orb works ↗ orb-how
- Orb 博客:OpenAI's credits model in 100 lines of code ↗ orb-credits
- Orb 文档:Commitments ↗ orb-commitments
- Orb 文档:Spend management ↗ orb-spend
- Orb 文档:Threshold invoicing ↗ orb-threshold
- Orb 博客:Usage-based billing software for AI companies(含 Adyen 收购背景) ↗ orb-ubb-ai
- FluxMeter 引擎:Orb 集成 ↗ fm-engine-orb
- FluxMeter llms-full.txt ↗ fm-llms-full
- FluxMeter claims.yml ↗ fm-claims
相关: 对比 · FluxMeter 与 Metronome · FluxMeter 与 Lago · FluxMeter 与 OpenMeter · 术语表 · 架构 · 文档 · FAQ · 市场地图