你如何确认长共享前缀确实被缓存了？

Reddit r/AI_Agents 新闻
caching prompt-engineering llm infrastructure token-costs optimization ai-providers

摘要

作者描述了提示中易变的请求标识符如何干扰前缀缓存，导致高流量用户的成本和延迟增加，并询问缓存改进的验证方法。

说实话，我原以为我们的长共享前缀会缓存得很好。然后我们发现一个请求标识符被插入在提示的顶部，在稳定的指令、工具模式和检索的策略之前。那个小字段每次调用都变化，所以提供商重新处理了数千个共享令牌。平均成本看起来可以接受，因为轻度账户主导了图表，而高流量群体支付了重复的前缀成本，并等待更长时间才获得第一个令牌。易变的元数据被推后，缓存键被稳定，令牌现在根据提示段和群体进行归因。情况有所改善，但我仍需要一些证据证明缓存命中是收益的原因，而不是流量构成的变化。你验证前缀缓存的方法是什么，除了令牌账单和第一个令牌的时间外，你还更信任哪些指标？
查看原文

相似文章

混合与循环大语言模型服务中的稀疏前缀缓存

arXiv cs.LG

本文针对混合和循环大语言模型提出了稀疏前缀缓存方法，该方法在有限的检查点位置存储循环状态，从而避免密集缓存，同时最小化重计算量。在真实数据上，该方法优于标准启发式方法，尤其是在请求共享大量但非完全相同的前缀时。