利用 Amazon Bedrock 提示词缓存优化成本与延迟

在大语言模型（LLM）应用迈向规模化落地的过程中，开发团队面临的核心瓶颈已经从模型基础能力的探索，转向推理成本的精细化控制与响应延迟的优化。在企业级智能体（AI Agent）、检索增强生成（RAG）系统以及复杂 Copilot 助手的实际运行中，API 请求往往需要反复发送庞大的上下文前缀——包括系统角色设定、合规性框架、长文档知识库以及数十个工具的 JSON Schema 定义。

Amazon Bedrock 推出的提示词缓存（Prompt Caching）功能通过在 Converse API 层面上实现前缀复用，能够将重复输入的 Token 成本大幅降低高达 90%，同时显著缩短首 Token 响应时间（TTFT）。无论开发者是直接基于 AWS 部署推理任务，还是利用 n1n.ai 等 API 聚合平台进行多模型调度与成本对照，掌握提示词缓存的设计模式都是构建高性能 AI 架构的重要一环。

Amazon Bedrock 提示词缓存的底层原理

Amazon Bedrock 提示词缓存是在大模型推理计算层实现的内存与状态复用机制。当开发者通过 Converse API 发起请求并在指定节点插入缓存检查点（Cache Checkpoint）时，Bedrock 推理引擎会自动检查最近的计算状态是否存在匹配的前缀缓存。

理解该机制需要关注以下关键要素：

1. 最小 Token 门槛：提示词前缀必须达到特定的 Token 数量要求才能触发缓存。例如 Anthropic Claude 3.5 Sonnet 模型通常要求缓存前缀至少包含 1024个 Token。
2. 缓存检查点设置：开发者需要在 API 调用的 JSON 结构中通过 cachePoint 显式标记缓存终止节点。
3. 生存时间（TTL）与自动刷新：缓存创建后默认具有 5分钟的生存时间。每次发生缓存命中（Cache Hit）时，生存时间会自动刷新扩展，保证高频调用的应用能够持续复用缓存。
4. 计费模型差异：输入 Token 被划分为“缓存写入（Cache Write）”与“缓存读取（Cache Read）”。缓存写入的单价略高于标准输入，而缓存读取单价仅为标准输入的 10%（即降低 90% 成本）。

下面我们将深入剖析在 AWS Python SDK（boto3）与 Converse API 下的六大实战应用场景。

场景一：系统提示词缓存（System Prompt Caching）

企业级 Agent 通常包含极为详尽的 System Directive，涵盖角色行为准则、安全边界以及输出格式约定。当系统提示词超过 1000个 Token 时，缓存系统提示词可以避免在多轮对话中重复为静态规则付费。

import boto3

bedrock_runtime = boto3.client('bedrock-runtime', region_name='us-east-1')

system_prompt = [
    \{
        "text": "你是一个专业的企业合规审计 Agent。请根据以下详细合规规则审查交易数据... [此处包含超过 1500 字的详细行业合规条款]