大模型应用怎么按量收费？这套方案跑通了

你的AI智能体开始收费了，但很快会遇到一个头疼的问题：有人一天调用几百次，有人一周才发几条消息。统一月费要么亏死，要么把轻量用户吓跑。

按量计费是刚需，但实现起来比想象中麻烦。你需要追踪每一次调用来自哪个客户、消耗多少token、换算成多少钱，最终变成一张真实发票。这套从请求到账单的完整链路，今天用LangChain和Kong Konnect跑通了。

核心思路：LangChain埋点，Kong算账

这套方案的关键在于分层。LangChain作为模型之上的抽象层，无论底层接的是自研模型还是OpenAI、Anthropic、Gemini的API，计量代码都不用改。

具体实现靠一个小型回调（callback）。每次调用发生时，它记录输入token数和输出token数，同时打上客户ID标签。这些数据流向Kong Konnect的计量与计费模块，实时累加每个客户的用量，按你设定的价格（输入和输出可以分开定价），每月自动生成发票。

举个例子：用户输入"Hello world"，模型回复"Hello! How can I assist you today?"。两边都是9个token——输入不是2个，因为OpenAI会把提示包装成聊天格式，额外增加几个token。

系统会生成两条记录：一条标记输入9 token，一条标记输出9 token，都归属客户"acme"。如果定价设为输入$1/token、输出$2/token，这笔调用的账单就是$9 + $18 = $27。两边的数字完全一致，链路跑通。

技术实现：CloudEvents埋点，Kong聚合

每次大模型调用会产生两个CloudEvents事件。一个携带提示词的token数，一个携带回复的token数。两个事件的subject字段都设为客户的唯一标识。

Kong的处理逻辑很直接：按subject分组，累加token字段，乘以该客户套餐上的费率表，在账单周期结束时汇总成发票。

这里需要澄清一个常见误解：Kong不是来替代Stripe的。它做的是计量和开票层，把算好的账单数据喂给Stripe或其他支付网关。分工明确——Kong管用了多少、该收多少，Stripe管扣款。

为什么选这套组合

Kong Konnect适合这个场景有三个具体原因。第一，CloudEvents是行业标准，埋点代码通用性强。第二，支持输入输出分开定价，这对成本结构差异大的大模型应用很关键——通常输出比输入贵得多。第三，账单周期和费率表可配置，能适应不同的商业模型。

LangChain的回调机制则解决了多模型适配的问题。示例代码跑在OpenAI的gpt-4o-mini上，但换掉chat model，计量逻辑完全不动。这对需要同时支持多个模型供应商的产品很重要。

完整实现已经开源：github.com/tejakummarikuntla/llm-metering-langchian-kong。代码结构清晰，LangChain回调在应用层埋点，Kong在基础设施层算账，两边通过标准事件格式对接。

这套方案改变什么

大模型应用的定价模式正在从"卖座位"转向"卖用量"。但用量计费的基础设施一直是短板——要么自己造轮子，要么被云厂商的计费系统绑架。

LangChain + Kong的组合提供了一条中间路径：应用层保持灵活，可以换模型、换供应商；计费层标准化，不用重复开发发票、对账、价格策略这些通用能力。对想做按量计费又不想被某一家云厂商锁死的产品团队，这是值得试的架构。

如果你正在跑大模型应用的付费试点，建议拿这套代码跑一遍端到端流程。计量准确性、账单延迟、价格策略的灵活性，这三个指标直接决定按量计费能不能跑得通。开源仓库里有完整的Docker配置和测试脚本，半天就能搭起来验证。