같은 모델이라도 어떻게 호출하느냐에 따라 비용, 지연 시간, 처리량이 크게 달라집니다. AIP-C01은 도메인 4(운영 효율성과 최적화, 12%)와 도메인 2의 배포·API 통합 항목에서 "이 요구사항에는 어떤 추론 방식이 맞는가"를 반복해서 묻습니다. 앞선 "Bedrock 비용 최적화와 모델 평가" 글에서 Provisioned Throughput과 온디맨드를 비교했다면, 이번 포스팅에서는 배치 추론, 교차 리전 추론, Intelligent Prompt Routing, 프롬프트 캐싱과 시맨틱 캐싱까지 한 번에 고를 수 있도록 정리합니다.
한눈에 보는 Bedrock 추론 방식
| 방식 | 과금 | 이럴 때 고른다 | 주의할 점 | |------|------|---------------|-----------| | 온디맨드 | 입력·출력 토큰 수만큼 | 트래픽을 예측하기 어렵거나 개발·테스트 단계 | 모델·리전별 분당 요청 수와 토큰 수 할당량 | | Provisioned Throughput | Model Unit 단위 시간당 요금 | 꾸준한 대량 트래픽, 처리량 보장 필요 | inference profile과 함께 쓸 수 없음 | | 배치 추론 | 지원 모델 기준 온디맨드보다 낮은 단가(약 50%) | 실시간 응답이 필요 없는 대량 처리 | 도구 호출·구조화 출력·프롬프트 캐싱 미지원 | | 교차 리전 추론 | 호출한 리전 단가, 추가 라우팅 비용 없음 | 피크 시간 스로틀링, 처리량 확보 | 요청이 다른 리전에서 처리됨 | | Intelligent Prompt Routing | 라우팅된 모델의 토큰 요금 적용 | 쉬운 질문과 어려운 질문이 섞인 트래픽 | 같은 모델 계열 2개, 영어 프롬프트에 최적화 | | 프롬프트 캐싱 | 캐시에서 읽은 토큰은 낮은 단가 | 긴 시스템 프롬프트·문서를 반복 사용 | 앞부분이 바뀌면 캐시 미스 |
시험 문제는 이 표의 "이럴 때 고른다" 열을 시나리오로 바꿔 출제합니다. "매일 밤 10만 건의 상담 기록을 요약한다"는 배치 추론, "점심시간마다 ThrottlingException이 난다"는 교차 리전 추론, "같은 500페이지 매뉴얼을 질문마다 붙여 보낸다"는 프롬프트 캐싱입니다.
온디맨드 할당량과 ThrottlingException 줄이기
온디맨드 호출에는 계정·리전·모델별로 분당 요청 수(RPM)와 분당 토큰 수(TPM) 할당량이 있습니다. 한도를 넘으면 이 발생하며, 대응 순서는 다음과 같습니다.
AWS SDK의 지수 백오프와 지터로 재시도합니다. 일시적인 초과는 대부분 여기서 해결됩니다. 요청을 Amazon SQS에 넣고 Lambda의 예약된 동시성(reserved concurrency)으로 소비 속도를 제한하면, 갑자기 몰린 요청을 한도 안에서 순서대로 처리할 수 있습니다. API Gateway 사용량 계획(usage plan)으로 고객·테넌트별 호출량을 제한해 한 고객이 전체 할당량을 소진하지 않게 합니다. 교차 리전 추론으로 여러 리전의 처리 용량을 함께 씁니다. 그래도 꾸준히 한도를 넘으면 Service Quotas에서 증가를 요청하거나 Provisioned Throughput을 검토합니다.
를 필요 이상으로 크게 잡지 않는 것, 대화 기록을 그대로 누적하지 말고 요약해서 넘기는 것도 토큰 소비를 줄이는 기본 습관입니다.
배치 추론: 실시간이 필요 없으면 먼저 검토
배치 추론은 여러 요청을 JSONL 파일로 모아 S3에 올리고 으로 한 번에 처리하는 방식입니다. 각 줄은 레코드 ID와 모델 입력으로 구성되며, InvokeModel 또는 Converse 요청 형식을 그대로 씁니다.
결과는 지정한 S3 경로에 파일로 저장되고, 작업 상태 변화는 EventBridge 이벤트로 받을 수 있어 완료 여부를 계속 확인할 필요가 없습니다. 레코드가 서로 독립적으로 처리되기 때문에 도구 호출이나 여러 번 주고받는 대화가 필요한 작업에는 쓸 수 없고, Provisioned Throughput 모델에도 사용할 수 없습니다.
비슷한 선택지와의 구분도 알아 둡니다. 영상 생성처럼 요청 한 건이 오래 걸리는 작업은 비동기 호출을, 직접 만든 컨테이너 모델로 대량 추론을 해야 한다면 SageMaker Batch Transform을, 항목마다 여러 서비스를 거쳐야 한다면 Step Functions Distributed Map을 고릅니다.
교차 리전 추론과 inference profile
교차 리전 추론은 inference profile로 호출합니다. 모델 ID 앞에 , , 같은 지역 접두사가 붙은 지리적 프로필은 해당 지역 안의 리전으로만 요청을 보내고, 접두사의 글로벌 프로필은 전 세계 상용 리전으로 보냅니다.
| 구분 | 지리적(Geographic) 프로필 | 글로벌(Global) 프로필 | |------|--------------------------|-----------------------| | 처리 리전 | 같은 지역(US, EU, APAC 등) 안 | 전 세계 상용 리전 | | 비용 | 표준 단가 | 약 10% 저렴 | | SCP 조건 | 프로필의 모든 대상 리전 허용 필요 | 이 "unspecified"인 요청 허용 필요 | | 적합한 조직 | 데이터 처리 위치 규정이 있는 조직 | 비용 최적화가 우선인 조직 |
추가 라우팅 비용은 없고 호출한 리전의 단가로 계산되며, 데이터는 AWS 네트워크 안에서 암호화되어 이동합니다. CloudTrail에는 호출한 리전에 기록되고 필드로 실제 처리 리전을 확인할 수 있습니다. "EU 밖에서 데이터를 처리하면 안 된다"는 조건이 있으면 글로벌이 아니라 EU 지리적 프로필이 정답입니다.
사용자가 직접 만드는 애플리케이션 inference profile도 있습니다. 팀이나 애플리케이션별로 프로필을 만들고 태그를 붙이면 같은 모델을 쓰더라도 비용과 사용량을 따로 집계할 수 있습니다.
Intelligent Prompt Routing과 모델 캐스케이딩
Intelligent Prompt Routing은 하나의 서버리스 엔드포인트 뒤에 같은 계열의 모델 두 개를 두고, 요청마다 각 모델의 응답 품질을 예측해 더 적합한 쪽으로 보냅니다. 기본으로 제공되는 라우터를 쓰거나, 폴백 모델과 응답 품질 차이(response quality difference) 기준을 직접 정한 라우터를 만들 수 있습니다. 응답에는 실제로 처리한 모델 정보가 함께 돌아옵니다.
제약도 시험에 나옵니다. 영어 프롬프트에 최적화되어 있고, 애플리케이션 고유의 성능 데이터를 반영해 라우팅을 바꾸지는 못합니다. 그래서 서로 다른 계열의 모델을 섞거나, 한국어 트래픽이 많거나, 업무 기준(예: 계약서 관련 질문은 무조건 상위 모델)으로 나눠야 한다면 애플리케이션에서 직접 모델 캐스케이딩을 구현합니다.
경량 모델이 먼저 답합니다. 형식 검증이나 신뢰도 점수로 답변을 확인합니다. 기준에 못 미치면 같은 요청을 상위 모델로 다시 보냅니다.
어떤 모델을 쓸지는 AWS AppConfig에 설정값으로 두면 코드 배포 없이 바꿀 수 있습니다. 공식 가이드 1.2.2가 말하는 "코드 수정 없이 모델과 공급자를 전환하는 구조"가 이 패턴입니다.
!어떤 Bedrock 추론 방식이 맞을까?
프롬프트 캐싱 vs 시맨틱 캐싱
두 캐싱은 이름이 비슷하지만 재사용하는 대상이 다릅니다.
| 구분 | 프롬프트 캐싱 (Bedrock 기능) | 시맨틱 캐싱 (직접 구현) | |------|-----------------------------|------------------------| | 재사용 대상 | 요청 앞부분(도구 정의·시스템 프롬프트·문서)의 처리 결과 | 이전 질문에 대한 최종 응답 | | 모델 호출 | 여전히 호출하고 나머지 부분만 새로 처리 | 캐시 히트 시 호출 자체를 생략 | | 일치 조건 | 앞부분이 정확히 같아야 함 | 질문의 의미가 비슷하면 됨 (임베딩 유사도) | | 구현 | 지정, 기본 TTL 5분 | 임베딩 + 벡터 검색 저장소 + TTL |
프롬프트 캐싱은 캐시 체크포인트를 지정해 그 앞부분을 저장합니다. 처리 순서가 도구 정의 → 시스템 프롬프트 → 메시지이므로, 바뀌지 않는 내용을 앞에 두고 사용자 질문처럼 매번 바뀌는 내용을 뒤에 둬야 히트율이 올라갑니다. 체크포인트마다 모델별 최소 토큰 수가 있고, 응답의 와 로 실제 히트 여부를 확인합니다. 배치 추론에서는 쓸 수 없습니다.
시맨틱 캐싱은 질문을 임베딩으로 바꿔 MemoryDB나 OpenSearch 같은 벡터 저장소에서 비슷한 이전 질문을 찾고, 유사도가 기준 이상이면 저장된 답을 돌려줍니다. 기준이 너무 낮으면 다른 의도의 질문에 엉뚱한 답이 나가고, 사용자별 개인화 답변을 공용 캐시에 넣으면 정보가 섞일 수 있습니다. 질문이 글자 그대로 같은 경우가 많다면 요청을 정규화해 해시값으로 찾는 정확 일치 캐시(DynamoDB, ElastiCache)가 더 단순하고, 모두에게 같은 공개 FAQ 응답은 CloudFront 엣지 캐싱도 쓸 수 있습니다.
지연 시간과 처리 우선순위 옵션
응답 속도가 특히 중요한 서비스라면 다음 옵션도 알아 둡니다.
응답 스트리밍(): 전체 생성 시간은 같아도 첫 글자가 빨리 보여 체감 지연이 줄어듭니다. 지연 최적화 추론: 의 를 로 지정합니다. 일부 모델과 리전에서 미리 보기로 제공되며, 할당량을 넘으면 표준 처리로 돌아갑니다. 서비스 티어: 요청의 로 Priority(더 빠르고 비쌈), Standard(기본), Flex(저렴하지만 혼잡 시 후순위), Reserved(예약 용량)를 고릅니다. 지원 모델이 제한적이므로 사용 전에 확인합니다. 예측 가능한 질문은 미리 생성해 두는 사전 계산(pre-computation)으로 호출 자체를 없앨 수 있습니다.
시험 핵심 정리
"실시간 응답이 필요 없는 대량 처리" -- Bedrock 배치 추론 (S3의 JSONL, CreateModelInvocationJob) "배치 작업 완료 알림" -- EventBridge 이벤트 "피크 시간 스로틀링, 처리량 확보" -- 교차 리전 추론 (inference profile) "데이터를 특정 지역 안에서만 처리" -- 지리적 inference profile (글로벌 아님) "팀별 모델 사용 비용 분리" -- 애플리케이션 inference profile + 태그 "꾸준한 대량 트래픽에 처리량 보장" -- Provisioned Throughput "갑자기 몰리는 요청을 한도 안에서 처리" -- SQS 버퍼 + Lambda 예약된 동시성 "쉬운 질문은 작은 모델, 어려운 질문은 큰 모델 자동 배분" -- Intelligent Prompt Routing "다른 계열 모델 혼합, 비영어, 업무 기준 라우팅" -- 애플리케이션 모델 캐스케이딩 "코드 배포 없이 사용 모델 교체" -- AWS AppConfig "긴 고정 프롬프트 반복 사용" -- 프롬프트 캐싱 (cachePoint, 고정 내용을 앞에) "비슷한 질문이 반복되어 모델 호출 자체를 줄이고 싶음" -- 시맨틱 캐싱 (임베딩 + 벡터 검색)