使用前缀缓存可以提高大语言模型应用的效率并降低成本。它预先存储常用文本前缀,只需将提示中独特的部分发送给模型,从而加快响应速度并降低使用成本,尤其适用于具有重复提示或标准化开头文本的应用。
前缀缓存邀测中,如需使用,请工单申请。
您可以在以下场景中使用前缀缓存。
场景 | 场景细分 | 描述 |
---|---|---|
大规模信息传递中的标准化文本元素: | 这些输出包含重复出现的元素,如免责声明、签名或引言。 | 将这些重复元素存储为前缀可以显著减少冗余处理。例如,系统可以检索缓存的前缀,而不是为每封邮件都生成相同的法律免责声明,从而节省处理时间并确保一致性。这种方法在处理大量输出时非常高效,其主要优势在于大规模信息传递的可扩展性和效率。 |
使用动态字段生成模板化内容: | 内容遵循标准结构,但模板中的特定字段会根据上下文而变化(例如,产品名称、职位名称、用户名)。 | 将模板存储为前缀,系统可以快速生成基本结构。然后,用特定信息填充动态字段,将预写模板的效率与个性化数据的灵活性相结合。这有利于内容丰富的平台,确保格式一致性的同时允许自定义。 |
标准化的开头和结尾: | 开头和结尾的句子或段落通常遵循特定的风格或结构。 | 通过将这些标准化的开头和结尾存储为前缀,您可以确保所有生成内容的风格和语气一致。这对于保持专业或品牌声音特别有价值,并且通过避免重复生成这些元素来节省处理时间。 |
预先计算或预先格式化的信息: | 某些信息是静态的,不会经常更改。 | 将这些静态元素缓存为前缀可以防止冗余计算或格式化。例如,系统可以从缓存中检索预先计算的结果,而不是每次需要时都重新计算复杂的公式。这可以缩短响应时间并减少计算开销。 |
前缀缓存通过将常用文本前缀存储在KV存储中,极大地提高了大型语言模型的效率和响应速度。当大语言模型收到请求时,应用程序只需提供与所需前缀关联的键。前缀缓存检索该前缀并将其添加到用户输入的开头,从而减少大语言模型的冗余处理。这将显著加快响应速度并降低总体成本,尤其是在高并发场景下。 虽然输入、输出、缓存命中和存储仍会产生计费,但性能的显著提升和处理标记数量的减少通常会超过这些成本,使前缀缓存成为一种非常有效的优化策略。
计费单价请参见:上下文缓存计费。
与 Session 缓存类似,前缀缓存采用透明的计费方式,基于以下四个关键因素:
您使用前缀键发起请求需要支付
每次调用计费用量可在返回的usage
结构体看到。
{ ... "usage": { "prompt_tokens": 20, "completion_tokens": 8, "total_tokens": 28, "prompt_tokens_details": { "cached_tokens": 10 } }
其中,各个字段含义:
prompt_tokens
:此次请求输入给模型处理的总的 token 数。completion_tokens
:此次请求模型回复的 token 数,即输出的token量,对应的计费项为 输出。total_tokens
:此次请求,总共使用的 token 数。prompt_tokens_details.cached_tokens
:此次请求模型命中的缓存大小,即缓存命中的 token 量,对应计费项缓存命中。其中费用计算重要数据
prompt_tokens
- cached_tokens
来获得。cache_tokens
的最大值。1个小时调用费用计算公式如下:
= 输入花费 + 命中花费 + 输出花费 + 存储花费 = (prompt_tokens-cached_tokens) * 输入单价 + cached_tokens * 命中单价 + completion_tokens * 输出单价 + Max(cache_window_tokens) * 存储单价
成本优化技巧:有效管理前缀及其生存时间是优化存储成本的关键。分析前缀的使用频率并相应地设置生存时间,以平衡缓存收益和存储支出。定期检查并删除未使用的前缀,以最大程度地减少不必要的存储费用。
当前支持前缀缓存的模型有:
模型名称 | 版本 | 上下文长度 | Max Tokens | TPM | RPM | 模型说明 |
---|---|---|---|---|---|---|
Doubao-pro-32k | 241215 | 32k | 4k | 120w | 15k | 旗舰模型,拥有强大的模型能力 |
使用 前缀缓存前,您需要调用ContextCreate-创建上下文缓存接口创建缓存,并写入初始信息。后续只要在ContextChatCompletions-上下文缓存对话接口中引入此缓存,即可让方舟为您保留初始信息以及享受缓存命中带来的性能加速和费用折扣。
curl --location 'https://ark.cn-beijing.volces.com/api/v3/context/create' \ --header 'Authorization: Bearer <YOUR_API_KEY>' \ --header 'Content-Type: application/json' \ --data '{ "model":"<YOUR_ENDPOINT_ID>", "messages":[ {"role":"system","content":"你是李雷,你只会说“我是李雷”"} ], "ttl":3600, "mode: "common_prefix" }'
其中:
<YOUR_API_KEY>
替换为您的API Key。<YOUR_ENDPOINT_ID>
替换为您的推理接入点ID。"ttl":3600
代表前缀缓存 TTL,当前为 3600 秒。"mode": "common_prefix"
代表使用的前缀缓存模式。模型回复预览:
{ "id": "<YOUR_CONTEXT_ID>", "model": "<YOUR_ENDPOINT_ID>", "ttl": "259200", "mode": "common_prefix", "usage": { "prompt_tokens": 18, "completion_tokens": 0, "total_tokens": 18, "prompt_tokens_details": { "cached_tokens": 0 } } }
返回的创建的前缀缓存的基本信息,其中<YOUR_CONTEXT_ID>
是创建的 Session 缓存的ID,格式类似ctx-****
,需要记录并在后面请求模型推理服务时使用。
我们使用接口ContextChatCompletions-上下文缓存对话,来进行使用前缀缓存的对话。
curl --location 'https://ark.cn-beijing.volces.com/api/v3/context/chat/completions' \ --header 'Authorization: Bearer <YOUR_API_KEY>' \ --header 'Content-Type: application/json' \ --data '{ "context_id": "<YOUR_CONTEXT_ID>", "model": "<YOUR_ENDPOINT_ID>", "messages":[ { "role":"user", "content": "你好" } ] }'
其中
<YOUR_API_KEY>
替换为您的API Key。<YOUR_CONTEXT_ID>
替换为之前创建的缓存 ID。<YOUR_ENDPOINT_ID>
替换为您的推理接入点ID。模型回复预览
{ "id": "****", "object": "chat.completion", "created": 167765****, "model": "<YOUR_ENDPOINT_ID>", "choices": [{ "index": 0, "message": { "role": "assistant", "content": "我是李雷。", }, "logprobs": null, "finish_reason": "stop" }], "usage": { "prompt_tokens": 28, "completion_tokens": 5, "total_tokens": 33, "prompt_tokens_details": { "cached_tokens": 18 } }
messages
数组中的最后一条消息role
可以是user
或system
,而不能为assistant
。