추론 최적화
Batch Inference · Provisioned Throughput · Prompt Routing
추론 최적화
Batch Inference · Provisioned Throughput · Prompt Routing
모델 호출의 비용·성능·가용성을 제어하는 인프라 계층
추론 프로파일부터 서비스 티어, 비용 최적화까지 프로덕션 운영 설계
Batch Inference
50% 할인 · S3 비동기 대량 처리
실시간 vs Batch
실시간이 필요한데 저비용이면 Flex, 비동기가 가능하면 Batch가 더 저렴
실시간 (On-Demand)
Standard · Priority · Flex
- 요청 즉시 응답
- 토큰당 정가 (Flex는 할인)
- 동시성 한도 적용
- 챗봇 · 에이전트 · 대화형 앱
Batch
비동기 Job
- S3 JSONL → Job → S3 출력
- On-Demand 대비 50% 할인
- 동시성 한도와 무관
- 요약 · 라벨링 · 정기 보고서
실시간이면서 저비용이면 Flex, 비동기가 가능하면 Batch가 항상 더 저렴합니다.
Batch = 50% 할인 비동기 처리
S3 입력 → Job → S3 출력 — 앱은 제출과 수신만
50% 할인의 대가는 SLA 없음입니다 — 마감이 있는 작업은 On-Demand에 남깁니다.
Batch Job 생성
문서 요약 5만 건을 절반 가격으로 — 야간 파이프라인에 최적
bedrock = boto3.client('bedrock', region_name='us-east-1')
response = bedrock.create_model_invocation_job(
jobName='document-summary-batch',
modelId='us.anthropic.claude-sonnet-4-6',
roleArn='arn:aws:iam::123456789012:role/BedrockBatchRole',
inputDataConfig={
's3InputDataConfig': {
's3Uri': 's3://my-bucket/batch-input/requests.jsonl',
},
},
outputDataConfig={
's3OutputDataConfig': {
's3Uri': 's3://my-bucket/batch-output/',
},
},
)
job_arn = response['jobArn']
- 입력은 S3의 JSONL — 한 줄이 요청 1건: {"recordId": "1", "modelInput": {"messages": [...]}}
- create_model_invocation_job — 실시간 API가 아닌 비동기 Job 제출
- roleArn — 입력·출력 S3 버킷을 읽고 쓸 IAM 역할
- 출력도 S3 — 결과 JSONL이 지정 경로에 저장
- jobArn으로 상태 폴링 — Completed 후 출력 경로 확인
Provisioned Throughput
MU 전용 용량 · 레거시 모델 전용 예약 방식
전용 용량 예약
MU(Model Unit) 단위 구매 — 다른 고객 트래픽의 영향을 차단
Model Unit 단위 시간당 과금 — 사용하지 않아도 계속
1·3개월 커밋 · 99.5% uptime 목표 · Cross-Region 프로파일과 조합 불가 (단일 리전 전용)
- 전용 용량
- 일관된 지연 시간
- 초과 트래픽은 429 — 자동 폴백 없음
쓰지 않아도 과금되는 전용 용량입니다 — 트래픽이 증명되기 전에는 계약하지 않습니다.
도입 판단과 설계
트래픽이 증명되기 전에는 On-Demand가 답
판단 신호
데이터로 확인
- break-even — 월간 On-Demand 토큰 비용 vs MU 시간당 비용
- InvocationThrottles — CloudWatch에서 스로틀링 지속 발생
- 두 신호가 겹칠 때만 커밋 검토
설계 원칙
커밋은 최소로
- 안정적 기저 트래픽만 전용 용량으로
- 스파이크는 Standard/Priority로 흡수
- PoC·신규 워크로드는 On-Demand 유지
전환 신호는 데이터로 확인합니다 — break-even 분석과 InvocationThrottles 지표가 판단 기준입니다.
Provisioned 생성과 호출
provisionedModelArn을 modelId에 그대로 전달
Provisioned Throughput은 Claude 3.5 Sonnet v2까지의 레거시 모델 전용입니다 — 신형 모델은 Service Tiers를 사용하세요(지원 티어는 모델별 상이 — Reserved는 Sonnet 4.6·Opus 4.6 지원, Opus 4.8·Sonnet 5·Opus 5는 Standard만). 사용 여부와 무관하게 시간당 과금됩니다. Reserved 예약 해지는 셀프서비스가 아니라 AWS 계정팀 요청이 필요합니다 — PoC는 On-Demand로 진행하세요.
import boto3
bedrock = boto3.client('bedrock', region_name='us-east-1')
# 최소 1개월 커밋 — modelUnits 단위로 전용 용량 확보
# PT는 레거시 모델 전용 — Claude 3.5 Sonnet v2가 지원 상한
response = bedrock.create_provisioned_model_throughput(
modelUnits=1,
provisionedModelName='prod-sonnet-legacy',
modelId='anthropic.claude-3-5-sonnet-20241022-v2:0',
commitmentDuration='OneMonth',
)
provisioned_arn = response['provisionedModelArn']
# 호출은 동일 — modelId에 프로비저닝 ARN 전달
runtime = boto3.client('bedrock-runtime', region_name='us-east-1')
response = runtime.converse(
modelId=provisioned_arn,
messages=[{'role': 'user', 'content': [{'text': '안녕하세요'}]}],
)
운영 전략
적용 순서 · 캐싱 · 에러 핸들링 · VPC · 모니터링
최적화 적용 순서
무료·즉시 효과부터 — 커밋이 필요한 것은 마지막에
-
1
Cross-Region 프로파일
무료, 즉시 효과 — 스로틀링·가용성 개선
-
2
Prompt Caching
반복 시스템 프롬프트가 있으면 입력 토큰 즉시 절감
-
3
서비스 티어 조정
비실시간 요청을 Flex로 분리
-
4
Batch 전환
대량 파이프라인 식별 후 50% 할인 적용
-
5
전용 용량 검토
안정 트래픽 + break-even 도달 시에만 — Reserved(신형) · PT(레거시)
순서 원칙은 무료·무커밋 먼저, 커밋은 마지막입니다 — Cross-Region과 캐싱만으로도 대부분 해결됩니다.
Prompt Caching 원리
한 번 계산한 프리픽스는 KV Cache로 호출 간 재사용 — 새 부분만 계산
시스템 프롬프트 + 매뉴얼 150KB
질문 A "배송 기간은?"
→
전체 계산
→
🗄️ 캐시 기록 — 쓰기 1.25×
🗄️ 같은 프리픽스 — 캐시 읽기 0.1×
질문 B "환불 규정은?"
← 새 부분만 계산
→
입력 비용 최대 90% 절감
최소 캐시 토큰은 모델마다 다릅니다 — Sonnet 4.6 = 1,024 · Opus 5 = 512 · Opus 4.8 · Sonnet 5 · Haiku 4.5 = 4,096 (Bedrock 기준, 프리픽스가 미만이면 캐시 미적용)
Prompt Caching 적용
cachePoint 한 줄이 전부 — 시스템 프롬프트·문서를 캐시 지점 앞에
# System Prompt Caching — cachePoint 블록으로 캐시 지점 지정
system_prompt = """당신은 고객 서비스 전담 AI입니다.
[매뉴얼: 100KB 정책 문서]
[FAQ: 50KB 자주 묻는 질문]
"""
response = bedrock_runtime.converse(
modelId='us.anthropic.claude-sonnet-4-6',
system=[
{'text': system_prompt},
{'cachePoint': {'type': 'default'}}, # ← 여기까지 캐싱
],
messages=[
{'role': 'user', 'content': [{'text': '배송 기간은?'}]}
]
)
# 첫 요청: 매뉴얼 + FAQ를 전부 읽고 캐시에 기록
# 두 번째 요청부터: 캐시 재사용 — 입력 토큰 비용 최대 90% 절감
# Bedrock의 Sonnet 4.6은 최소 1,024 토큰부터 캐싱 적용
- cachePoint 블록 앞까지가 캐시 대상 — 시스템 프롬프트·문서를 앞쪽에 배치
- 두 번째 요청부터 캐시 재사용 — 입력 토큰 비용 최대 90% 절감
- Sonnet 4.6은 최소 1,024 토큰부터 캐싱 적용
Intelligent Prompt Routing — 레거시 전용
복잡도 기반 자동 모델 선택 — 단, 최신 모델은 미지원
Claude 3.x/3.5, Nova Lite/Pro, Llama 3.x만 지원합니다. Claude 4.x 이상(Sonnet 4.6 · Opus 4.8 · Fable 5 등 신형)에서는 사용할 수 없습니다.
Prompt Routing
레거시 모델 전용
- 같은 패밀리 내 모델 쌍만
- Claude 3 Haiku ↔ 3.5 Sonnet
- Nova Lite ↔ Pro · Llama 3.1 8B ↔ 70B
- Claude 4.x 이상 미지원
AgentCore Gateway 라우팅
최신 대안
- Gateway Inference Target으로 라우팅
- 여러 모델을 하나의 엔드포인트 뒤에
- Claude 4.x 포함 전 모델
- 모델 패밀리 제한 없음
Prompt Routing은 레거시 모델 전용입니다 — 최신 모델 라우팅은 AgentCore Gateway가 대안입니다.
운영 아키텍처
프라이빗 네트워크 · 재시도 · 캐싱 · 모니터링을 함께 구성
네트워크·재시도·캐싱·모니터링은 호출 코드와 함께 처음부터 설계해야 하는 운영 4요소입니다.
에러 핸들링
프로덕션 안정성 — ThrottlingException 재시도 전략
단일 리전 한계 도달 시 발생. 지수 백오프(exponential backoff)로 재시도: 1초 → 2초 → 4초 → 8초. 최대 5회 재시도 권장 (boto3 standard 재시도 모드 기본은 최대 3회 시도). 프로덕션에는 추론 프로파일(Cross-Region) 사용으로 근본 해결.
boto3 재시도 설정
import boto3
from botocore.config import Config
# boto3 재시도 설정 — standard 모드는 지수 백오프 + 지터 적용
config = Config(
retries={
'max_attempts': 5, # 총 시도 횟수 (standard 모드 기본 3)
'mode': 'standard',
}
)
bedrock_runtime = boto3.client('bedrock-runtime', config=config)
# ThrottlingException은 재시도 대상 — 설정만으로 자동 처리
response = bedrock_runtime.converse(
modelId='us.anthropic.claude-sonnet-4-6',
messages=[
{'role': 'user', 'content': [{'text': '안녕하세요'}]}
],
)
VPC Endpoint
PrivateLink로 인터넷을 거치지 않고 Bedrock 접근 — 데이터 주권
퍼블릭 엔드포인트
- bedrock-runtime.{region}.amazonaws.com
- NAT Gateway 등 퍼블릭 경로 경유
- 프라이빗 연결 요건이 있는 규제 환경에서는 VPC 엔드포인트 권장
- 구성은 간단, 네트워크 경로 통제는 제한적
언제 — 개발 환경, 테스트용
VPC Endpoint
- com.amazonaws.{region}.bedrock-runtime
- PrivateLink로 프라이빗 서브넷에서 직접 접근
- 데이터가 AWS 내부 네트워크에서만 이동
- 규정 준수 (HIPAA, PCI-DSS, FedRAMP)
언제 — 프로덕션, 규정 준수 필요
규제 환경의 갈림길입니다 — 데이터가 AWS 내부망을 벗어나면 안 되면 VPC Endpoint를 씁니다.
워크로드별 추론 방식
레이턴시 요구 · 트래픽 패턴 · 비용 목표로 결정
| 시나리오 | 추론 방식 | 이유 |
|---|---|---|
| 고객 대면 챗봇 (24/7) | Reserved 티어 | SLA · 일관된 응답 시간 |
| 변동 트래픽 서비스 | On-Demand + Cross-Region | 유연성 + 스로틀링 방지 |
| 간헐적 긴급 분석 | On-Demand Priority | 예약 없이 우선 처리 |
| 야간 대량 문서 처리 | Batch | 50% 할인, 시간 무관 |
| 에이전트 도구 호출 | On-Demand Standard/Priority | 불규칙 호출 패턴 |
정답은 조합입니다 — 레이턴시 요구와 트래픽 패턴이 워크로드별 추론 방식을 정합니다.
CloudWatch 모니터링
전환 시점을 알려주는 지표들
- InvocationThrottles
- 지속 발생 = Priority/전용 용량(Reserved·PT) 전환 신호
- InvocationLatency
- 응답 시간 — P95 추적으로 티어 효과 확인
- InputTokenCount · OutputTokenCount
- 토큰 사용량 — break-even 분석의 입력값
- ServiceTier · ResolvedServiceTier
- 요청 티어 vs 실제 서빙 티어 차원
- inferenceRegion (CloudTrail)
- Cross-Region이 실제 처리한 리전 확인
지표가 전환 타이밍을 알려줍니다 — 스로틀 · 지연 · 토큰 · 티어 네 축을 상시 추적합니다.
실습 — 추론 최적화
워크로드에 맞는 추론 방식을 직접 설정하고 비용을 비교합니다
학습 목표
- Batch Inference — JSONL 준비부터 잡 생성 · 결과 회수까지
- 처리량 확보 — Service Tiers와 레거시 PT 비교
- Prompt Routing 설정과 비용 확인
Inference Profile · Service Tiers · Batch · Provisioned — 워크로드에 맞는 조합이 답입니다.