趋近智
有效部署LangChain应用不仅意味着管理性能,还需管理运营开支。大型语言模型虽然强大,但会消耗计算资源,其用量通常直接转化为金钱成本,主要通过按令牌计费的API调用产生。忽视成本管理可能导致不可持续的运营开支,特别是当你的应用扩展时。这里介绍了理解、追踪和控制LangChain应用相关成本的方法,主要关注令牌用量,这是LLM开支的主要因素。
大多数商业LLM提供商(如OpenAI、Anthropic、Google)采用基于处理“令牌”数量的按用量付费模式。一个令牌大致对应一个单词或单词的一部分。掌握这些成本是如何累积的,这很必要:
了解这种定价结构是实现有效成本管理的第一步。你需要清楚地知道你的应用消耗了多少令牌以及在哪里消耗。
LangChain提供了便捷的方式来追踪令牌用量,特别是对于通过OpenAI等标准API接口的模型。主要机制涉及使用回调函数。
get_openai_callback 上下文 (context)管理器是一种直接的方法,用于追踪执行OpenAI调用的代码块的用量:
from langchain_openai import ChatOpenAI
from langchain_community.callbacks import get_openai_callback
from langchain_core.messages import HumanMessage
# 假设 OPENAI_API_KEY 已在环境中设置
llm = ChatOpenAI(model="gpt-3.5-turbo")
messages = [HumanMessage(content="Explain the concept of tokenization in LLMs in about 50 words.")]
# 使用回调上下文管理器
with get_openai_callback() as cb:
response = llm.invoke(messages)
print(response.content)
print("\n--- 用量统计 ---")
print(f"总令牌数: {cb.total_tokens}")
print(f"提示令牌数: {cb.prompt_tokens}")
print(f"完成令牌数: {cb.completion_tokens}")
print(f"总成本 (美元): ${cb.total_cost:.6f}")
当你运行此代码时,get_openai_callback 上下文管理器 (cb) 会捕获在 with 块内进行的LLM调用的令牌计数和预估成本。它提供诸如 total_tokens、prompt_tokens、completion_tokens 和 total_cost 的属性。
对于涉及链或代理的更复杂情况,或者处理异步操作时,你可能需要更精密的追踪方法:
BaseCallbackHandler 的自定义回调处理器,以汇总多个步骤或异步任务中的令牌计数。这些处理器可以将数据记录到数据库、监控系统或自定义仪表板中。verbose=True 运行链或代理通常会打印每个步骤的令牌用量信息,这在开发期间可能有用,但在生产日志记录中不太实用。尽管内置回调函数很有用,LangSmith为生产监控(包括成本追踪)提供了一个更集成、功能更强的解决方案。当你配置LangChain应用使用LangSmith时(详见第五章),它会自动捕获应用执行的详细追踪,包括:
使用LangSmith将成本追踪从手动日志记录或简单回调函数变为一个持久化、可搜索和可汇总的系统,明显提高了生产环境中的可见性。
简化流程图,演示了在一个RAG应用中,令牌用量和成本通常在哪里被追踪(在LLM调用处)和记录(例如,到LangSmith)。
一旦你清楚地掌握了令牌用量和成本,你就可以实施策略来减少开支:
战略性模型选择: 这通常是最具影响力的手段。评估是否更便宜的模型(例如,GPT-3.5-Turbo、Claude Haiku)能充分完成某些任务,而非默认选择最强大(且昂贵)的选项(例如,GPT-4、Claude Opus)。如果你有特定、重复的任务,可以考虑微调 (fine-tuning)更小的开源模型,尽管这会涉及前期训练成本。
提示优化: 简洁很重要。优化你的提示,使其尽可能简洁,同时仍能达到预期输出。删除多余的指令或例子。分析小样本示例是否总是必需的。
上下文 (context)窗口管理: 在RAG或对话系统中,发送过多上下文会显著增加输入令牌计数。采用以下技术:
LLM响应缓存: 如果你的应用经常收到相同的请求,缓存LLM响应可以带来显著的节省和延迟改进。LangChain提供了多种缓存实现(InMemoryCache、SQLAlchemyCache、RedisCache等)。如果底层数据或预期响应可能改变,请注意缓存失效问题。
from langchain.globals import set_llm_cache
from langchain_openai import OpenAI
from langchain_community.cache import InMemoryCache
# 全局启用缓存
set_llm_cache(InMemoryCache())
llm = OpenAI(model="gpt-3.5-turbo-instruct")
# 第一次调用(将请求API并缓存结果)
print("第一次调用:")
result1 = llm.invoke("Why is the sky blue?")
# print(result1) # 为简洁省略输出
# 第二次调用,提示完全相同(将从缓存返回)
print("\n第二次调用 (已缓存):")
result2 = llm.invoke("Why is the sky blue?")
# print(result2) # 为简洁省略输出
# 注意:get_openai_callback 不会显示缓存调用的成本/令牌
控制输出长度: 在LLM调用中使用 max_tokens 参数 (parameter)来限制生成响应的长度。当你只需要一个简短答案、摘要或分类时,这很有用,可以防止模型生成过长(且昂贵)的文本。
批量请求: 一些LLM API支持批量处理,允许你在单个请求中发送多个独立的提示。尽管这通常不会改变每令牌成本,但它可以减少网络开销并可能提高整体吞吐量 (throughput),间接影响基础设施成本。查阅你的提供商文档以了解批量处理能力和定价。
月度成本的示意性对比,展示了使用不同模型或技术处理相同工作负载的情况。与未缓存的GPT-4用量相比,缓存显著降低成本,如果某些请求需要GPT-4的质量,这可能使其比始终使用更便宜的GPT-3.5模型更可行。
在生产环境中,特别是在多功能或多租户应用中,仅仅知道总成本是不够的。你需要将成本归因于特定的活动:
积极的成本管理需要持续的监控、分析和优化。通过精细追踪令牌用量,运用LangSmith等工具,并应用成本节约策略,你可以确保你的LangChain应用在扩展时保持经济可行。这种积极主动的方法是负责任地运营生产级LLM系统的重要组成部分。
简洁的语法。内置调试功能。从第一天起就可投入生产。
为 ApX 背后的 AI 系统而构建
这部分内容有帮助吗?
get_openai_callback。© 2026 ApX Machine LearningAI伦理与透明度•