如何监控OpenAI API和ChatGPT的使用情况 - OpenMeter

AI功能的兴起与基于使用的定价模式

近年来，人工智能（AI）技术在各行业中迅速普及，新产品和现有产品纷纷集成了各种AI功能。然而，将AI技术集成到产品中需要支付一定的成本，例如使用OpenAI API时需支付调用费用，或为计算资源买单。为了确保盈利，越来越多的企业开始采用基于使用的定价模式，尤其是针对这些新增的AI功能。

尽管目前部分企业为了保持竞争力，暂时未向客户收取AI功能的费用，但从长期来看，这种做法可能会影响盈利能力。因此，预计未来大多数企业都会采用透明的基于使用的定价策略，将AI使用成本合理地转嫁给客户。

准确计量AI使用情况的重要性

为了能够准确地将AI使用情况归因于特定用户，企业需要实施高效的使用计量系统。这样的系统不仅可以支持基于使用的计费，还能触发应用内的使用报告功能，为优化定价策略提供有价值的见解。

以OpenAI为例，其API的计费基于令牌（Token）的使用量。令牌可以理解为一段文本，其成本因所使用的AI模型（如GPT-3.5或GPT-4）而异。通过查看OpenAI API的响应数据，可以轻松获取令牌的使用量，例如data.usage.total_tokens字段中记录了每次调用的令牌数量。

多租户环境下的使用计量挑战

在生产环境中，多个客户可能同时在不同服务器实例上执行大量的OpenAI API调用。为了准确归因和计费，企业需要一个高效的解决方案来收集这些调用数据，并将其归因到具体用户，同时进行汇总以支持计费和分析。

这种场景通常被称为多租户退款用例，不仅适用于OpenAI使用情况的归因，还可以扩展到其他共享资源的计量，例如存储、网络传输和计算资源。

使用计量的实现方法

数据库记录法

一种简单的方法是将每次使用记录写入数据库（如MongoDB或PostgreSQL），记录内容包括时间戳、总令牌使用量和用户ID。例如，可以通过SQL查询轻松检索特定时间段的使用数据：

SELECT user_id, SUM(total_tokens)
FROM usage_records
WHERE timestamp BETWEEN 'start_time' AND 'end_time'
GROUP BY user_id;

然而，这种方法在大规模使用场景下可能会变得昂贵。频繁的数据库写入会增加成本，延长故障转移时间，扩大备份大小，并可能导致复制延迟。

指标系统的局限性

虽然指标系统（如Prometheus）在大规模跟踪使用数据方面具有吸引力，但它们通常缺乏计费场景所需的一致性保证。例如，数据可能在传输过程中丢失，或者在重试时被重复计数。因此，指标系统并不适合作为计费用途的使用计量解决方案。

消息队列与流处理

一种更可扩展的解决方案是预先聚合使用数据并批量写入数据库。这通常通过一个消息队列（如Kafka）来实现，用于收集跨进程的使用事件，并通过流处理器（如Kafka Streams、Flink或ksqlDB）进行实时聚合。

这种方法的优势在于：

大幅减少数据库的写入频率，从而降低成本。
提供缓冲能力，在流量激增时确保数据不会丢失。
实现准确的使用归因和计费。

例如，对于每秒发送数百万个使用事件的应用程序，可以将数据聚合到逐分钟的时间窗口中，然后仅将聚合结果写入长期存储。

OpenMeter：开源的使用计量解决方案

尽管流处理系统功能强大，但其管理复杂性可能对没有流处理经验的企业构成挑战。为了解决这一问题，OpenMeter应运而生。OpenMeter是一个开源项目，旨在帮助工程师快速实现准确且实时的使用计量。

OpenMeter的核心基于Kafka和流处理技术，能够在保证数据准确性的同时，支持大规模使用场景。通过OpenMeter，企业无需担心复杂的技术实现，即可轻松完成AI使用情况的归因和计费。

总结

AI功能的普及推动了基于使用的定价模式的兴起。为了实现盈利并合理转嫁成本，企业需要准确地将AI使用情况归因于用户。然而，传统的数据库记录法和指标系统在大规模场景下存在诸多局限性。

通过结合消息队列和流处理技术，企业可以构建高效的使用计量系统，而开源工具OpenMeter则为这一过程提供了简化的解决方案。借助OpenMeter，企业能够快速实现准确的使用计量，为计费、退款和分析等场景提供支持。

原文链接: https://openmeter.io/blog/how-to-meter-openai-and-chatgpt-api-usage