AI 에이전트를 위한 봄날의 돌아오는 날: Amazon Bedrock에서 OpenAI 모델을 사용하기 위한 프롬프트 캐싱 패턴

에이전트를 실행할 때마다 행동을 수행하기 전에 자신의 인생 전체 이야기를 다시 읽어야 합니다. 동일한 컨텍스트를 다시 제공하지 않고도 기억하게 만드는 방법을 소개합니다.

영화 봄날의 돌아오는 날(Groundhog Day)에서 빌 머레이가 연기한 캐릭터는 매일 2월 2일을 반복해서 삽니다. 그는 같은 라디오 노래, 같은 여관, 같은 작은 마을에서 깨어나며, 일부 영화 팬들이 추정하기로는 무려 34년 동안 이를 되풀이합니다.

전날 이룬 성과는 처음부터 다시 해내지 않는 한 남지 않습니다. AI 에이전트는 봄날의 돌아오는 날의 한 버전 속에서 삽니다. 에이전트가 한 단계를 밟을 때마다(도구를 호출하고, 결과를 읽고, 다음에 무엇을 할지 결정할 때) 연속성을 유지하기 위해 지금까지의 전체 이야기를 모델에 보내야 합니다: 도구 정의, 지침, 이전의 모든 도구 호출, 모든 결과. 모델은 제공된 입력을 기반으로 다음 토큰만 예측합니다. 요청 간에 내부 메모리가 없기 때문에 모든 내용을 다시 읽어야 합니다. 코딩 세션의 20턴째가 되면 모델은 1–19턴을 다시 읽고, 그 모든 토큰에 대해 비용을 지불하는 것은 반복해서 여러분입니다.

프롬프트 캐싱은 이 순환을 끊습니다. 서비스는 입력 프롬프트(지침, 도구, 콘텐츠)를 저장하고 다음 요청에서 입력 가격의 일부 비용으로 이를 재사용합니다.

이 게시물에서는 에이전트의 첫 턴부터 새로운 도구를 받고 헬퍼를 생성할 때까지 에이전트의 삶을 살펴봅니다. 그 과정에서 프롬프트 캐싱이 비용을 낮추고 에이전트의 반응성과 일관성을 유지하는 방법을 보여드립니다.

에이전트가 LLM에 보내는 것

캐싱에 대해 이야기하기 전에, 일반적인 에이전트의 첫 대규모 언어 모델(LLM) 호출에 무엇이 포함되어 있는지 살펴보는 것이 도움이 됩니다:

• 도구 목록 – 에이전트가 호출할 수 있는 모든 함수의 정의. 새 릴리스를 배포할 때 변경됩니다.
• 지침 – 개발자 프롬프트: 규칙, 페르소나, 정책, 예시. 릴리스마다 변경됩니다.
• 기록 – 이 세션에서 지금까지 일어난 모든 것: 작업, 모델의 도구 호출, 도구 결과(매 턴마다 증가함).
• 새 턴 – 가장 최근의 도구 결과 또는 사용자 메시지(매번 다를 수 있음).

캐싱을 설정하지 않았을 때 에이전트가 매 턴마다 모델에 보내는 내용:

그림 1: 에이전트가 매 턴마다 모델에 보내는 내용

프롬프트 캐싱의 내부 동작 방식

모델이 프롬프트를 읽을 때, 먼저 prefill이라는 쓰기 작업을 수행합니다. prefill 동안 모델은 모든 입력 토큰을 처리하고 모델의 작업 상태를 형성하는 키(key)와 값(value) 벡터(key-value 또는 KV라고도 함)를 구축합니다. 이는 모델이 첫 토큰을 쓰기 전에 일어납니다.

프롬프트 캐싱은 시스템 프롬프트, 도구, 콘텐츠, 기록 등을 포함하는 이 상태를 저장합니다. 이후 요청이 동일한 입력 토큰(즉, 동일한 텍스트)으로 시작하면 프롬프트 캐싱 서비스는 다시 계산하는 대신 저장된 상태를 불러옵니다. 그런 다음 모델에 보내는 다음 페이로드에서 새로운 부분만 처리합니다. 프롬프트 캐싱은 Amazon Bedrock이 재사용 가능한 접두사의 끝을 선택하는 암시적 방식이거나, 코드가 해당 지점을 prompt_cache_breakpoint로 표시하는 명시적 방식일 수 있습니다. 두 방식을 함께 사용할 수 있으며, 함께 사용할 것을 권장합니다.

1턴과 2턴 비교

그림 2: 1턴은 중단점까지의 프롬프트 접두사를 저장하고, 2턴은 이를 재사용하며 새 질문에 대해서만 전체 가격을 지불합니다

암시적 방식과 명시적 방식, 그리고 왜 둘 다 필요한가?

에이전트형 워크로드의 경우, 암시적 캐싱을 통해 대화가 길어질 때 Bedrock이 캐싱할 내용을 선택하도록 할 수 있습니다. 명시적 캐싱을 사용하면 도구와 지침 같은 공유 콘텐츠를 세션 간에 그리고 헬퍼 에이전트를 시작할 때 재사용하도록 표시할 수 있습니다. 두 형태의 캐싱이 항상 모두 필요한 것은 아니지만, 이를 결합하면 Bedrock이 늘어나는 대화를 자동으로 관리하는 동시에 재사용 가능한 시작점을 확보할 수 있습니다.

새 세션도 이 공유된 시작점을 재사용할 수 있으며, 각 대화는 자체 캐시된 기록 위에 구축됩니다. 이 글에서는 첫 번째 턴부터 시작하여, 이후 턴과 새로운 도구, 그리고 서브에이전트 전반에 걸쳐 캐시된 콘텐츠를 전달하는 방법을 보여드립니다.

안녕하세요, 캐시된 세계

첫 번째 최적화는 프롬프트의 정적 부분을 캐싱하는 것입니다. 즉, 요청 간에 동일하게 유지되는 도구와 지침을 캐싱하는 것입니다. 이 예제들은 기존의 Amazon Bedrock 클라이언트를 사용합니다. TOOLS, 그리고 task. 다음을 교체하십시오: 축약된 INSTRUCTIONS 실제 정책과 예시가 담긴 문자열입니다. 재사용 가능한 접두사는 자격을 갖추기 위해 1,024 토큰에 도달해야 합니다.

정적 콘텐츠를 캐싱할 때는 explicit 모드를 사용하세요. 저장된 접두어가 끝나는 위치를 직접 지정합니다.

KEY = "support-agent:v7:gpt-6-astra"
INSTRUCTIONS = "Your full support policies and examples..."

# Rendered context: [provider context][TOOLS][INSTRUCTIONS] | [task]
# Cache starts at the beginning; the marker below chooses its end.
resp = client.responses.create(
    model="us.openai.gpt-6-astra",
    store=False,  # Response storage; prompt caching still works.
    include=["reasoning.encrypted_content"],
    prompt_cache_key=KEY,
    prompt_cache_options={"mode": "explicit", "ttl": "30m"},
    tools=TOOLS,  # Rendered before instructions; keep order stable.
    input=[
        {
            "role": "developer",
            "content": [{
                "type": "input_text",
                "text": INSTRUCTIONS,
                # Save through this whole block, including TOOLS.
                "prompt_cache_breakpoint": {"mode": "explicit"},
            }],
        },
        # User message is processed but not cached.
        {"role": "user", "content": task},
    ],
)

그 prompt_cache_key 해당 서비스에 어떤 요청이 캐시를 공유하는지 알려줍니다. 새 세션에서 캐시를 읽는 방법에 대해 다룰 때 이를 사용하는 방법을 다시 설명하겠습니다. 명시적 캐싱을 사용한 테스트 중 하나에서 약 4,000톤 분량의 도구 및 지침 접두어가 첫 요청에서 4,120토큰을 기록했고 이후 요청에서 그 4,120토큰을 읽었습니다. 그 task (또는 사용자 요청)은 캐시 경계 이후에 오므로, 캐시에 쓰기를 트리거하지 않습니다.

프롬프트 캐싱은 정확히 동일한 텍스트를 전달할 때만 작동한다는 점을 유의하세요. 에이전트의 지침과 도구 목록이 매번 같은 방식으로 직렬화되도록 하세요. Model Context Protocol (MCP) 서버 및 기타 형태의 도구 제공 방식은 일관성을 유지하도록 인덱싱해야 합니다. 날짜, 사용자 이름, 요청 ID처럼 변하는 내용은 캐시된 지침 뒤에 배치하세요.

콘텐츠가 늘어나고 다양해지면(서로 다른 도구와 콘텐츠), implicit 모드를 사용하여 서비스가 대화를 따라가도록 하세요. 여기서 첫 번째 요청에는 명시적 마커가 없습니다. 가장 최근의 적격 메시지가 사용자의 작업이므로, 자동 중단점은 해당 작업 뒤에 오며 도구, 지침, 작업을 함께 포함합니다. implicit이 기본값임에도 불구하고, 명확성을 위해 다음 예시에서는 모드를 명시적으로 표시했습니다. 설정 store=False 애플리케이션에 대화 기록을 남겨 둡니다. 캐싱을 비활성화하지는 않습니다.

def ask_with_implicit_cache(history):
    return client.responses.create(
        model="us.openai.gpt-6-astra",
        store=False,
        include=["reasoning.encrypted_content"],
        prompt_cache_key=KEY,
        prompt_cache_options={"mode": "implicit", "ttl": "30m"},
        tools=TOOLS,
        input=history,  # Everything gets cached
    )

history = [
    {"role": "developer", "content": INSTRUCTIONS},
    {"role": "user", "content": task},
]
# Automatic endpoint: the end of the user message.
resp = ask_with_implicit_cache(history)

다음 턴이 동일한 작업을 이어갈 때 이것이 유용합니다. 다른 작업은 이전 작업을 통해 접두어와 일치하지 않으며, 암시적 쓰기가 도구와 지침만을 위한 별도의 항목을 반드시 만들어주는 것은 아닙니다. 더 짧은 공유 접두어를 작업 간에 재사용할 수 있게 하려면 그런 경우 명시적 마커를 사용하세요.

에이전트가 공유된 시작점과 함께 커져 가는 히스토리가 필요할 때 두 가지를 모두 사용하십시오. 다음 코드 예제에서 표시된 개발자 블록으로 시작하여 함수를 호출하십시오. ask_with_implicit_cache. 요청 수준 모드는 암묵적으로 유지됩니다. 블록 수준 마커는 지침 뒤에 명시적인 저장 지점을 추가합니다. 서비스는 또한 가장 최근의 적격 메시지를 통해 저장할 수 있습니다. 이를 통해 대화가 길어지는 동안에도 공유 프리픽스를 계속 사용할 수 있습니다.

history = [
    {
        "role": "developer",
        "content": [{
            "type": "input_text",
            "text": INSTRUCTIONS,
            "prompt_cache_breakpoint": {"mode": "explicit"}, 
        }],
    },
    {"role": "user", "content": task},
]
# Still implicit mode, now with an explicit startup save point in the history.
resp = ask_with_implicit_cache(history)

대화 기록 및 도구 결과 캐싱

모델은 도구를 이름으로 요청하고 해당 인수를 전달합니다. 애플리케이션이 이를 실행해야 합니다. execute_function 해당 요청들을 일치하는 Python 함수로 라우팅하고 그 결과를 반환하기 위해 여러분이 만드는 헬퍼입니다. 다음 루프는 이 헬퍼를 사용하여 요청된 각 도구를 실행합니다. 이 루프는 모델의 출력과 모든 도구 결과를 history 목록을 다시 전송하고, 이 목록을 모델이 최종 답변을 반환할 때까지 반복해서 전송합니다. 암시적 모드에서 Amazon Bedrock은 변경되지 않은 접두사를 재사용하고 마지막 도구 결과까지 추가된 콘텐츠를 캐시할 수 있습니다. 이전 메시지와 초기 TOOLS 변경되지 않았습니다.

import json

# Map tool names to their Python implementations.
TOOL_HANDLERS = {
    "get_owner": get_owner,
    # Register your other initial tools here.
}

def execute_function(name, arguments):
    """Run the requested tool and return its result."""
    handler = TOOL_HANDLERS.get(name)
    if handler is None:
        return {"error": f"Unknown tool: {name}"}
    return handler(**arguments)

while True:
    # Preserve all output items, including encrypted reasoning.
    history.extend(resp.output)
    calls = [x for x in resp.output if x.type == "function_call"]
    if not calls:
        break
    for call in calls:
        result = execute_function(call.name, json.loads(call.arguments))
        history.append({
            "type": "function_call_output",
            "call_id": call.call_id,
            "output": json.dumps(result),
        })
    # The last result in this group supplies the automatic endpoint.
    resp = ask_with_implicit_cache(history)

후속 처리를 하려면 새 사용자 메시지를 추가하고 헬퍼를 다시 호출하세요. 캐시된 엔드포인트가 계속 사용 가능하도록 이전 메시지들은 그대로 두십시오.

롤링 브레이크포인트(Rolling breakpoints): 각 턴은 그 이전의 모든 것을 읽습니다

그림 3: 롤링 브레이크포인트, 각 턴은 이전의 모든 내용을 읽고 자신의 도구 결과만 기록함

별도의 explicit 전용 실행의 경우, 결합된 Hello cached world 예제에서 두 개의 메시지로 구성된 히스토리를 다시 만듭니다. 이 루프는 도구 결과를 input_text 각 배치에서 블록을 막고 최종 결과를 표시합니다. 이전 마커는 남아 있습니다. history. 다음을 참조하십시오 현재 조회 규칙 긴 대화를 위한.

import json

while True:
    resp = client.responses.create(
        model="us.openai.gpt-6-astra", store=False,
        include=["reasoning.encrypted_content"],
        tools=TOOLS, prompt_cache_key=KEY, input=history,
        prompt_cache_options={"mode": "explicit", "ttl": "30m"},
    )
    d = resp.usage.input_tokens_details
    print("read", d.cached_tokens, "write", d.cache_write_tokens)
    history.extend(resp.output)  # Includes encrypted reasoning.
    calls = [x for x in resp.output if x.type == "function_call"]
    if not calls:
        break
    batch = []
    for call in calls:
        result = execute_function(call.name, json.loads(call.arguments))
        batch.append({
            "type": "function_call_output", "call_id": call.call_id,
            "output": [{"type": "input_text", "text": json.dumps(result)}],
        })
    # Add the newest boundary; retain every earlier marker.
    batch[-1]["output"][-1]["prompt_cache_breakpoint"] = {"mode": "explicit"}
    history.extend(batch)

GPT-6 Astra는 이 6턴 워크로드에서 최고의 암시적 결과를 공동 기록했습니다: 캐싱 없이 실행할 때보다 입력 비용이 약 62퍼센트 낮았습니다. 명시적 롤링 중단점은 동일 모델에서 약 61퍼센트를 절약했습니다. 두 방식 모두 대화가 길어질수록 더 많은 기록을 재사용했습니다. 이것은 워크로드 결과입니다. 직접 자신의 에이전트의 절감액을 측정해 보십시오.

그림 4: GPT-6 Astra에서 캐싱 없음을 기준으로 한 모든 캐싱 구성의 입력 비용

주의할 점:

• 명시적 전용 모드에서는 정적 중단점만 지원됩니다. – 도구와 지침은 캐시되지만, 늘어나는 대화 기록은 매 턴마다 다시 처리됩니다 (0.61). 이 제한은 결합된 예시에는 적용되지 않으며, 이 예시는 적격한 대화 종결을 통한 절감 효과도 있습니다.
• 단일 중단점 이동 명시적(explicit-only) 모드에서 캐시 재사용을 방지하고 반복적인 쓰기를 유발할 수 있습니다. 이전 턴의 중단점도 유지하십시오.
• 변경되는 태스크를 통한 암묵적 쓰기만 – 새 작업은 도구와 지침은 공유하지만 이전에 저장된 엔드포인트는 공유하지 않을 수 있습니다. 서로 다른 작업이 더 짧은 해당 접두사를 재사용해야 하는 경우 공유 지침 뒤에 명시적인 마커를 추가하세요.

도구가 변할 때

때때로 에이전트의 도구 목록이 변경되거나 새로운 도구가 추가됩니다. 초기 목록은 안정적으로 유지하세요. 정의를 추가, 제거 또는 재정렬하면 캐시된 접두사가 무효화될 수 있습니다. 도구가 사용 가능해지는 방식에 맞는 접근 방식을 선택하세요.

에이전트 흐름의 서로 다른 단계에서 알려진 도구가 호출될 때: 동일하게 정렬된 TOOLS 그리고 사용 allowed_tools 모델이 호출할 수 있는 대상을 제한합니다. With allowed_tools, "mode": "auto" 는 모델이 허용된 도구를 호출할지 여부를 결정하게 하며, "mode": "required" 는 최소 하나의 허용된 도구 호출을 요구합니다. 이것을 다음과 같이 전달합니다 tool_choice. 이 제한은 캐시된 카탈로그를 변경하지 않습니다:

tool_choice={"type": "allowed_tools", "mode": "auto",
             "tools": [{"type": "function", "name": "get_owner"}]}

세션 중 새 도구. Amazon Bedrock Runtime과 Amazon Bedrock Mantle 엔드포인트 모두 다음과 같은 입력 항목 유형을 받습니다 additional_tools GPT-6 Astra, GPT-6.1 Sol, GPT-5.6 Luna의 경우. AWS 리전별 모델 가용성은 다음을 참조하세요 Amazon Bedrock의 AWS 리전별 지원 모델. 새 도구를 등록합니다 get_due_date 헬퍼 함수에서 execute_function그런 다음 에이전트 루프에서 완료된 기록에 해당 스키마를 추가합니다. 초기 TOOLS 는 변경하지 않고 그대로 둡니다:

TOOL_HANDLERS["get_due_date"] = get_due_date
NEW_TOOL = {
    "type": "function", "name": "get_due_date",
    "description": "Return the due date for a support case.",
    "strict": True,
    "parameters": {
        "type": "object",
        "properties": {"case_id": {"type": "string"}},
        "required": ["case_id"], "additionalProperties": False,
    },
}
history.append({
    "type": "additional_tools", "role": "developer",
    "tools": [NEW_TOOL],
})
history.append({
    "role": "user", "content": "Find the due date for case C-123.",
})
# Implicit mode saves through this new user message, including NEW_TOOL.
resp = ask_with_implicit_cache(history)
d = resp.usage.input_tokens_details
print("old prefix read", d.cached_tokens, "new write", d.cache_write_tokens)

# Example output:
# old prefix read 2048 new write 256

세션 중간에 새 도구가 도착함

그림 5: 도구를 추가해도 이전 접두사는 계속 재사용 가능하며, 예시 수치는 Amazon Bedrock Runtime의 GPT-6 Astra 기준입니다

새 응답으로 도구 실행 루프를 계속합니다. 이 루프는 모델의 출력을 history에 추가하고, 요청된 도구를 실행하며, 그 결과를 덧붙입니다. 이후 요청에서도 additional_tools 항목을 유지하여 새 도구를 계속 사용할 수 있도록 하십시오. 암시적 모드에서는 Amazon Bedrock이 해당 앞의 도구 정의를 포함하여 새 사용자 메시지까지 캐싱할 수 있습니다. 명시적 전용 모드에서는 이전 중단점을 유지하고 해당 사용자 메시지의 input_text 블록에 하나를 추가하십시오. additional_tools 항목 자체는 중단점을 가질 수 없습니다.

역할이 다르면 카탈로그도 다릅니다. 서로 다른 에이전트 역할에 서로 다른 도구가 필요한 경우, 각 세션 시작 시 지원이나 청구 같은 안정적인 도구 프로필을 선택하십시오. 각 프로필은 자체 캐시 접두어를 갖습니다. 공유 지침을 표시해 두면 해당 프로필을 사용하는 이후 작업이 이를 재사용할 수 있으며, 대화가 길어짐에 따라 어느 모드든 사용할 수 있습니다.

캐시된 도구 프로필

그림 6: 각 도구 프로필은 자체 캐시 접두어를 가지며, 일치하는 세션에서 재사용할 수 있습니다

서브에이전트와 사이드 호출

작업 위임 시 모든 헬퍼가 동일한 배경 지식을 다시 읽게 해서는 안 됩니다. 접두어를 공유한 다음 각 헬퍼의 작업을 끝에 추가하십시오. AI 에이전트에서 캐싱을 사용할 때 도구와 시스템 프롬프트가 유출되거나 악용될 수 있음에 유의하십시오. 프롬프트 캐싱 구현을 거버넌스의 일부로 포함하는 책임 있는 AI 관행을 수립하십시오.

한 번 워밍업한 후 확산하십시오. 먼저 일반 요청을 보내고 완료를 기다린 후 헬퍼를 시작하십시오. 모드가 암시적이더라도 모든 요청에서 공유 컨텍스트를 명시적으로 표시하십시오:

shared = {"role": "developer", "content": [{
    "type": "input_text", "text": INSTRUCTIONS,
    "prompt_cache_breakpoint": {"mode": "explicit"},
}]}
warm = client.responses.create(
    model="us.openai.gpt-6-astra", store=False,
    tools=TOOLS, prompt_cache_key=KEY,
    prompt_cache_options={"mode": "implicit", "ttl": "30m"},
    max_output_tokens=16,
    input=[shared, {"role": "user", "content": "Reply READY."}],
)
d = warm.usage.input_tokens_details
if not (d.cache_write_tokens or d.cached_tokens):
    raise RuntimeError("Shared prefix was not cached.")
from concurrent.futures import ThreadPoolExecutor

# helper_tasks contains the task text for each helper.
helper_inputs = [
    [shared, {"role": "user", "content": task}]
    for task in helper_tasks
]
with ThreadPoolExecutor(max_workers=4) as pool:
    helpers = list(pool.map(ask_with_implicit_cache, helper_inputs))

헬퍼는 워밍업과 동일한 TOOLS, 모델, KEY 를 사용합니다. 출력 한도에서 끝난 워밍업도 캐시를 채울 수 있습니다. 헬퍼를 시작하기 전에 사용량 확인으로 캐시 활동을 확인합니다.

서브에이전트: 공유 접두어를 한 번 워밍업한 후 확산

그림 7: 헬퍼를 시작하기 전에 공유 접두어를 워밍업하고, 각 헬퍼는 자체 작업을 추가합니다

사이드 호출에 동일한 시작 부분을 부여하십시오. 에이전트 루프는 암호화된 추론을 포함하여 모든 history 과 그에 일치하는 도구 결과를 덧붙여 resp.output 를 구성합니다. 부모가 완료된 후, 요약기나 판정기용으로 해당 완전한 목록을 복사하십시오. 동일한 헬퍼가 도구, 모델, 키를 변경하지 않고 유지합니다:

from copy import deepcopy

# history is the completed history built by the agent loop above.
# Copy it so the helper can add instructions without changing the parent.
helper_history = deepcopy(history)
helper_history.append({
    "role": "developer",
    "content": "Summarize this conversation in one sentence. Do not call tools.",
})
summary = ask_with_implicit_cache(helper_history)
d = summary.usage.input_tokens_details
print("history read", d.cached_tokens, "write", d.cache_write_tokens)
print(summary.output_text)

# Example output (assumed values and conversation):
# history read 4096 write 32
# Case C-123 is due on October 31, 2026.

헬퍼는 history의 캐시된 부분을 재사용할 수 있지만, 덧붙여진 개발자 메시지가 캐시를 자동으로 확장하여 요약 지침을 포함하지는 않습니다. 이후 요청이 동일한 기록과 지침을 재사용하는 경우, 지침을 input_text 가 있는 prompt_cache_breakpoint블록에 배치하십시오. 일회성 요약이라면 추가 표시가 필요하지 않습니다.

일시 중지, 재시작, 캐시 키

일시 중지. 캐시된 접두어는 최소 30분의 time to live(TTL)를 가지며, 성공적인 재사용으로 갱신되고 더 오래 유지될 수도 있습니다. 세션이 곧 재개된다면 만료되기 전에 일반 워밍업으로 접두어를 갱신할 수 있습니다. 캐시가 만료되도록 두는 것과 해당 요청의 비용을 비교하십시오. TTL 규칙은 Amazon Bedrock 문서를 참조하십시오.

새 세션. 접두어를 공유하도록 의도된 요청에서는 prompt_cache_key 를 안정적으로 유지하십시오. 세션 전용 키는 프롬프트가 동일하더라도 세션을 격리합니다. 다음 예에서는 공유 키로 전환하여 세션이 접두어를 재사용할 수 있게 되었습니다.

새 세션은 키를 공유하는 경우에만 캐시를 재사용합니다

그림 8: 세션 전용 키는 캐시 항목을 분리하며, 공유 키는 일치하는 세션이 이를 재사용할 수 있게 합니다

기존 캐시 콘텐츠를 재사용하려면 동일한 모델, AWS 계정 및 Region, 그리고 사용 가능한 일치하는 접두사가 필요합니다. 다음 예시는 명시적 시작 마커와 암시적 모드를 결합합니다. 각 세션은 동일한 지침으로 시작하며 자체 작업을 가집니다. 둘 다 동일한 계산된 키를 사용합니다:

import hashlib

def cache_key(app, model, prompt_version, instructions):
    digest = hashlib.sha256(instructions.encode()).hexdigest()[:12]
    return f"{app}:{prompt_version}:{model}:{digest}"

KEY = cache_key("support-agent", "us.openai.gpt-6-astra", "v7", INSTRUCTIONS)
prefix = {"role": "developer", "content": [{
    "type": "input_text", "text": INSTRUCTIONS,
    "prompt_cache_breakpoint": {"mode": "explicit"},
}]}
for label, question in [
    ("session A", "Explain the refund policy without calling tools."),
    ("session B", "Explain the escalation policy without calling tools."),
]:
    # A fresh conversation for each session; the startup prefix matches.
    session_history = [prefix, {"role": "user", "content": question}]
    result = ask_with_implicit_cache(session_history)
    d = result.usage.input_tokens_details
    print(label, "read", d.cached_tokens, "write", d.cache_write_tokens)

콜드 스타트 시 세션 1이 공유 접두사를 기록합니다. 세션 2는 자신의 작업이 다르더라도 그것을 읽을 수 있습니다. 각 작업은 암묵적으로 캐시될 수도 있습니다. 사용 카운터를 확인하세요. 일치하는 키와 마커가 있으면 재사용이 가능하지만, 캐시 항목이 여전히 사용 가능한 상태여야 합니다.

프롬프트 캐싱이 제공하는 것

비용. 8,000토큰의 시작 프리픽스와 각 2,000토큰을 추가하는 6개 턴을 사용하는 GPT-6 Astra 기반 에이전트의 경우, 일회성 정적 캐싱으로 비용이 $0.50로 감소했고, 롤링 브레이크포인트는 모델링된 입력 비용을 64퍼센트, 즉 세션당 $0.87에서 $0.32로 줄였습니다.

그림 9: 지원 에이전트 예시의 세션당 누적 입력 비용, GPT-6 Astra에 대한 Amazon Bedrock 온디맨드 가격 기준

캐싱이 작동하고 있는지 확인하는 방법

응답 사용법부터 시작하세요. cached_tokens 캐시에서 읽은 입력을 보고하며, cache_write_tokens 여기에 기록된 입력을 보고합니다. 대화가 길어짐에 따라 이후 턴이 이전 히스토리를 재사용하는지, 그리고 새로운 기록이 추가되는 내용을 반영하는지 확인하십시오.

Amazon Bedrock Runtime 엔드포인트에 대한 프로덕션 모니터링을 위해서는 다음을 사용하십시오: CacheReadInputTokenCount 그리고 CacheWriteInputTokenCount Amazon CloudWatch 지표입니다. 개별 요청 기록이 필요할 때는 모델 호출 로깅을 활성화한 후 Amazon CloudWatch Logs Insights로 조회하십시오. Amazon Bedrock Mantle 엔드포인트의 경우 애플리케이션 로그에 응답 사용량 필드를 기록하십시오. 해당 Amazon CloudWatch 네임스페이스에는 현재 별도의 캐시 카운터가 없습니다.

비용을 확인하려면 필터를 적용하세요 AWS Cost Explorer Amazon Bedrock로 전송한 후 다음 기준으로 그룹화 사용 유형`. 캐시 읽기, 캐시 쓰기, 그리고 캐시되지 않은 입력은 모델별로 별도의 항목으로 표시됩니다. 입력 비용에서 이들의 비율을 계산할 때는 출력 토큰 항목을 제외하십시오.`

간단한 체크리스트

• 재사용 가능한 접두어를 안정적으로 유지하십시오. 공유 도구와 지침을 먼저 배치한 다음, 대화 기록과 새 턴을 뒤에 덧붙이세요. 타임스탬프, 메시지 또는 도구 정의를 변경하면 해당 변경 부분을 넘어선 재사용이 불가능해집니다. 더 짧은 접두사는 자체 저장된 엔드포인트가 있는 경우 여전히 재사용할 수 있습니다.
• 재사용하려는 콘텐츠 주변의 경계를 선택하세요. 성장하는 히스토리에는 암시적 캐싱을, 공유 접두사에는 명시적 마커를 사용하거나 둘 다 사용하세요. 명시적 전용 모드는 일회용 접미사를 쓰지 않아도 됩니다. 명시적 전용 대화를 확장할 때는 이전 마커를 유지하여 이후 요청이 저장된 접두사를 찾을 수 있도록 하세요.
• 처음의 도구 카탈로그는 변경하지 않고 그대로 유지하십시오. 사용법 allowed_tools 호출 가능한 도구를 제한합니다. 알려진 정의를 다음과 함께 추가합니다: additional_tools하거나 네임스페이스가 지정된 클라이언트 측을 통해 이를 찾아보세요 tool_search. 각 에이전트 역할마다 다른 카탈로그가 필요할 때는 안정적인 도구 프로필을 선택하세요.
• 접두어 크기와 수명을 확인하십시오. 캐시 가능한 프리픽스는 최소 1,024개의 토큰을 포함해야 합니다. 캐시된 프리픽스는 마지막 쓰기 또는 성공적인 재사용 후 최소 30분 동안 재사용 자격이 유지됩니다.
• 헬퍼를 실행하기 전에 공유된 콘텐츠를 워밍업하십시오. 웜업 및 헬퍼 요청 모두에서 공유 접두사를 표시하되, 암시적 모드를 사용할 때도 포함됩니다. 병렬 호출을 시작하기 전에 웜업 요청을 마무리하십시오.
• 각 공유 그룹 내에서 캐시 키를 안정적으로 유지하십시오. 접두사를 재사용하려는 요청은 동일한 키를 사용해야 합니다. 별도의 키를 사용하면 고객 또는 사용자 간에 캐시 회계를 구분할 수 있습니다.
• 워크플로 전반의 절감액을 측정합니다. 캐시 쓰기 비용은 일반 입력 요금의 1.25배입니다. 읽기 가격은 모델에 따라 다릅니다. 개발 중에는 응답 사용량을, 프로덕션에서는 모니터링 및 청구 데이터를 활용하여 읽기 절감액과 함께 쓰기 비용을 추적하세요.

2월 3일 아침에 눈을 뜨다

Bill Murray는 같은 실수를 반복하는 것을 멈추고 하루 동안 얻은 교훈을 다음 날로 가져가기 시작할 때 비로소 Groundhog Day에서 벗어납니다. 에이전트도 덜 낭만적이긴 하지만 비슷한 방식으로 거기에 도달합니다. 프롬프트의 시작 부분을 바이트 단위로 그대로 유지하고, 대화 기록이 늘어남에 따라 자동 또는 명시적 캐시 경계를 사용하는 것입니다.

이 글에서는 공유 도구와 지침을 캐싱하는 방법, 에이전트 턴이 진행됨에 따라 캐시를 확장하는 방법, 그리고 도구를 추가하거나 헬퍼를 실행하거나 새 세션을 시작할 때 재사용을 유지하는 방법을 다루었습니다. 공유 접두사를 안정적으로 유지하고 워크플로가 진행됨에 따라 새 정보를 덧붙이세요. 대화가 점점 길어지는 경우에는 암시적 캐싱을, 공유 콘텐츠에는 명시적 브레이크포인트를 사용하세요. 두 가지가 모두 필요하면 함께 조합하고, 변경되는 접미사가 재사용될 가능성이 낮다면 명시적 전용 모드를 선택하세요. 캐시 읽기, 캐시 쓰기, 총 입력 비용, 지연 시간을 비교하여 에이전트에 가장 적합한 방식을 찾아보세요. 이러한 패턴을 적용하려면 다음을 따르세요. OpenAI 모델을 위한 Amazon Bedrock 프롬프트 캐싱 문서 및 확인 AWS 리전 및 엔드포인트별 모델 가용성. 워크플로우 하나로 시작하고 대화가 늘어남에 따라 절감 효과를 측정해 보세요.

저자 소개