我们不知道哪个团队在推高LLM账单,这里是我们的解决方案。
摘要
本文描述了一家公司如何通过先实施代理以获得可见性,然后使用Orqai进行实时预算执行来解决跨团队追踪LLM成本的问题。
财务部门询问哪个团队花了多少钱,这是一个尴尬的时刻,因为没有人能够回答,就像6个团队直接使用自己的API密钥访问供应商。发票上每个供应商只有一行项目,没有按团队、项目或用例细分。第一个解决方案是手动的:每个团队负责人标记使用情况并每月报告。这持续了6周后变得不可靠。第二个解决方案是一个轻量级代理,为每个请求添加团队头信息。这提供了可见性,但告诉我们事情发生后的情况。团队可能在一周内耗尽预算,而我们在月底才知道。我们某种程度上需要的是执行而非报告。知道超支与超支前被阻止。看几种方法:AWS和Azure的成本分配 => 在账户或标签级别操作,粒度不够细,比如对于跨内部团队共享同一部署的LLM使用。自定义中间件 => 上面的代理方法,可见性有了。在其上构建预算执行逻辑本身会成为维护负担。Orqai => 在网关处为每个团队每个项目设置上限,在请求发出前执行,财务实时看到支出,而无需等待月底。较新,因此缺乏团队在大规模运行预算执行方面的经验。目前还在弄清楚如何处理突发使用,当团队合法需要暂时超过上限时。其他人如何处理这个例外。
相似文章
@LangChain: 管理LLM支出变得更难,一旦你的团队开始使用多个代理调用多个模型。没有……
本文提供了一个指南,介绍如何使用LangSmith LLM Gateway来设置和执行成本控制,以管理使用多个LLM代理时的开支。
如何阻止失控的LLM API支出在调用发出之前(调用前预算执行)
一份实用指南,介绍如何为LLM API调用实施调用前预算执行,涵盖估算、对账、故障开放决策、范围预算和并发处理,以防止失控成本。
当我的API账单不再合理后,我构建了一个代理来压缩智能体的LLM请求
一位独立创始人介绍了Orqen,这是一个位于你的SDK和LLM提供商之间的代理,通过压缩工具结果、管理历史记录和降低token成本来优化出站请求,而无需更改智能体代码。
花数月研究LLM评估与可观测性平台,针对250人规模部署——分享我们的发现
基于数月研究,针对250人公司部署的LLM评估与可观测性平台详细对比,涵盖全栈平台、可观测性工具和开源框架。
利用LLMs来衡量LLMs的成本以及为什么更小的模型并不总是更便宜
使用更小、更便宜的LLMs可能因审查时间和错误纠正等隐藏费用而增加整个工作流的成本,这突显了进行全面成本追踪的必要性。