LiteLLM项目中Anthropic流式响应缓存使用量统计问题分析

问题背景

在LiteLLM项目(v1.67.0-stable版本)中，当使用Anthropic的流式API响应并启用缓存功能时，系统对token使用量的统计存在不准确的问题。这个问题主要影响缓存相关指标的聚合计算，导致最终返回的用量统计信息丢失了关键的缓存使用数据。

问题现象

当Anthropic API以流式方式返回响应时，系统会分多个chunk发送数据。其中第一个chunk包含了输入缓存的使用统计信息，而最后一个chunk则包含了输出token的统计信息。然而，当前的实现方式导致最后一个chunk的统计信息会覆盖第一个chunk中的缓存使用数据。

具体表现为：

• 第一个chunk包含cache_creation_input_tokens和cache_read_input_tokens等缓存相关指标
• 最后一个chunk包含完整的completion_tokens等输出token统计
• 最终聚合结果中丢失了缓存使用信息

技术分析

问题的根源在于calculate_usage函数中的聚合逻辑。该函数遍历所有chunk时，简单地用后续chunk的usage数据覆盖之前的数据，而没有对特定字段进行累加或保留。

在Anthropic的响应模式中：

1. 第一个chunk包含输入token和缓存使用情况
2. 中间chunk包含部分输出token
3. 最后一个chunk包含完整的输出token统计

当前的实现无法正确处理这种分布式的统计信息，特别是对于缓存相关指标的处理不够细致。

解决方案

针对这个问题，社区提出了以下改进方向：

1. 非零值检查：在处理缓存相关字段时，不再简单地覆盖，而是检查是否为非零值后再更新

2. 字段级聚合：对不同类别的统计信息采用不同的聚合策略：

   • 对于completion_tokens等输出token采用累加方式
   • 对于缓存相关指标保留首次出现的非零值
   • 对于prompt_tokens需要特殊处理，因为它可能包含缓存读取的token

3. 明确统计口径：需要统一prompt_tokens的计算方式，明确是否包含缓存读取的token。根据项目维护者的说明，prompt_tokens应该包含总输入token，然后在prompt_token_details中细分缓存读取和实际输入的token。

影响范围

这个问题不仅影响Anthropic的流式响应，也可能影响其他类似行为的API提供商，如Deepseek。虽然初始修复针对Anthropic，但需要考虑更通用的解决方案。

最佳实践建议

对于使用LiteLLM处理流式响应并启用缓存的开发者，建议：

1. 关注统计信息的完整性，特别是缓存相关指标
2. 在成本计算时，注意区分实际输入token和缓存token的成本差异
3. 对于关键业务，建议实现自己的用量监控作为双重校验
4. 及时更新到包含修复的版本

总结

LiteLLM项目中Anthropic流式响应的缓存使用量统计问题展示了在分布式响应场景下指标聚合的复杂性。通过分析问题本质和讨论解决方案，不仅解决了当前问题，也为类似场景的处理提供了参考模式。这种问题在流式API和缓存功能结合使用时尤为常见，值得开发者特别关注。