생성형 AI 비용 최적화
생성형 AI 운영 비용을 체계적으로 절감하는 전략
생성형 AI 비용 최적화
비용 구조 · 모델 라우팅 · 토큰 최적화 · RAG·에이전트 비용 · 모니터링
가장 비싼 모델이 항상 최선은 아니다
비용 발생 지점을 파악하고, 모델 선택부터 모니터링까지 체계적으로 절감
비용 구조와 과금 체계
4대 비용원 · 토큰 단가 · On-demand · Provisioned · Batch
비용 구조와 과금
어디서 발생하고 어떤 과금 모델로 지불하는가 — 비용 통제의 출발점
4대 비용원 · 3가지 과금 모델
LLM 토큰·인프라·도구 호출·벡터 스토어에서 비용이 발생하고, On-demand·Provisioned·Batch로 지불합니다.
- 4대 비용원 — LLM 토큰이 통상 최대
- 출력 토큰 — 입력보다 통상 5~6배 비쌈
- On-demand · Provisioned · Batch
- Service Tiers 4단계 — Reserved · Priority · Standard · Flex
출력 토큰이 입력보다 통상 5~6배 비쌉니다 — 출력 제어가 가장 큰 지렛대입니다.
비용이 발생하는 4곳
LLM 토큰이 통상 최대 — 규모에 따라 나머지 3곳도 무시 못 할 비중
LLM 토큰
입력+출력 토큰 과금. 출력이 입력보다 통상 5~6배 비쌈 — 가장 큰 지렛대
인프라
AgentCore Runtime 세션, Lambda, Fargate — 스케일링 전략으로 최적화
도구 호출
외부 API, Browser, Code Interpreter — 호출 횟수와 캐싱이 핵심
벡터 스토어
OpenSearch OCU, 임베딩 호출, S3 Vectors — Top-K와 Managed Knowledge Base로 절감
네 곳 모두 점검하되, 통상 가장 큰 LLM 토큰 — 특히 출력 제어부터 시작합니다.
모델별 토큰 단가
같은 질문이라도 모델에 따라 입력 단가가 수십 배 차이 — 라우팅이 최대 지렛대
| 모델 | 입력 ($/MTok) | 출력 ($/MTok) | 포지션 |
|---|---|---|---|
| GPT OSS 20B | $0.07 | $0.30 | 오픈웨이트 초저가 · 분류/추출 |
| GPT-5.4 | $2.75 | $16.50 | 비용 효율 · 272K 컨텍스트 |
| GPT-5.5 | $5.50 | $33.00 | GPT 상위 모델 · 272K 컨텍스트 |
| Sonnet 4.6 | $3.00 | $15.00 | 균형 · 대부분 적합 |
| Opus 4.8 | ~$5.00 | ~$25.00 | 이전 세대 플래그십 · 복잡 추론 |
| Opus 5 | ~$5.00 | ~$25.00 | 최신 플래그십 · 4.8과 동일가 |
| Fable 5 | $10.00 | $50.00 | 최상위 · 멀티데이 자율 |
입력 단가가 모델에 따라 수십 배 차이 — 태스크에 맞는 모델 선택이 최대 지렛대입니다.
과금 모델 — 비용 렌즈 요약
On-demand · Batch · Provisioned — 방식별 비용 특성과 판단 요점
| 방식 | 비용 특성 | 비용 관점 요점 |
|---|---|---|
| On-demand (기본) | 사용한 토큰만 과금 | Service Tiers 4단계(Reserved · Priority · Standard · Flex)로 가용성-비용 조절 |
| Batch Inference | On-demand 대비 50% 할인 | 비실시간 대량 작업은 Batch부터 검토 — 가장 쉬운 절감 |
| Provisioned Throughput (레거시) | 시간당 고정 과금 (약정) | 구모델 전용 · 유휴 시간에도 과금 — 신모델 예약 용량은 Reserved 티어 |
여기서는 비용 렌즈의 요점만 봅니다 — Inference Profile · Service Tiers · Batch · Provisioned의 판단 기준은 Amazon Bedrock 추론 인프라 모듈에서 다룹니다.
모델 선택 최적화
라우팅 · Prompt Router · Distillation · 유스케이스별 권장
모델 선택
태스크에 맞는 모델을 고르는 세 가지 방법
라우팅 · Prompt Router · Distillation
태스크 복잡도를 분류해 적합한 모델로 분기하면 품질을 유지하면서 비용을 절감합니다.
- 모델 라우팅 — 단순→Haiku · 중간→Sonnet · 복잡→Opus
- Bedrock Prompt Router — 관리형 라우팅
- Distillation — 동일 프로바이더 Teacher→Student
- 유스케이스별 권장 — 분류는 소형 모델로 충분
작은 모델로 충분한 태스크를 Opus에 보내면 돈 낭비 — 태스크 복잡도 분류가 절감의 시작입니다.
모델 라우팅 전략
태스크 복잡도를 분류하여 적합한 모델로 분기 — 품질 유지·비용 절감
Bedrock Prompt Router의 동작 원리·라우팅 설정·지원 모델 조합은 Amazon Bedrock 추론 인프라 모듈(운영 전략 파트)에서 다룹니다 — 여기서는 비용 레버로서의 효과만 봅니다.
분류기가 처음부터 완벽할 필요는 없습니다 — 품질 추적으로 분류 기준을 계속 조정하는 루프가 핵심입니다.
유스케이스별 권장 모델
작은 모델로 충분한 태스크를 Opus에 보내면 돈 낭비 — 절감률은 모델 단가 비율 기준 추정
| 유스케이스 | 권장 모델 | 비용 절감 (단가 비율 추정) | 이유 |
|---|---|---|---|
| 분류/라벨링 | Haiku · Nova Lite | ~95% | 짧은 출력, 단순 판단 |
| 데이터 추출 (JSON) | Haiku · Sonnet | ~80% | 스키마 기반 추출 |
| FAQ 응답 | Sonnet | ~60% | 검색 결과 요약 |
| 복잡한 추론/계획 | Opus | 기준 | 멀티스텝 판단 필요 |
| 코드 생성 | Sonnet · Opus | 상황별 | 복잡도에 따라 |
분류·추출처럼 짧은 출력 태스크는 Haiku로도 충분 — 단가 비율 기준 최대 ~95% 절감(추정)입니다.
Distillation — 소형 모델의 품질 끌어올리기
동일 프로바이더 Teacher→Student 페어링만 지원(Nova→Nova · Llama→Llama) — Anthropic 모델은 현재 비가용
-
1
Teacher 수집
Nova Pro/Premier로 태스크 N건 실행 → 고품질 응답 데이터셋 구축
-
2
Student 학습
Nova Lite/Micro를 해당 데이터로 SFT(Supervised Fine-tuning)
-
3
품질 검증
평가 메트릭으로 Teacher 대비 품질 비교 — 정확도 손실 2% 미만이 공식 기준
-
4
배포
품질 충분하면 Student로 교체 → 최대 75% 절감 · 500% 고속화
품질 검증을 통과해야 교체합니다 — 평가 메트릭 없는 Student 배포는 금물입니다.
토큰 최적화
Prompt Caching · maxTokens · ConversationManager · context_manager
토큰 최적화
입력 · 출력 · 컨텍스트 — 세 방향에서 토큰을 줄이는 기법
Caching · maxTokens · context_manager
반복 입력은 캐시하고, 출력은 한도를 정하고, 컨텍스트는 자동으로 관리합니다.
- Prompt Caching — 캐시 히트 시 입력 90% 절감
- cachePoint — 최대 4개 체크포인트
- maxTokens — 태스크별 출력 한도
- context_manager="auto" — Summarizing + ContextOffloader
반복 프리픽스는 캐시, 출력은 한도, 히스토리는 자동 요약 — 세 방향을 동시에 적용합니다.
Prompt Caching — 90% 입력 절감
반복되는 시스템 프롬프트·컨텍스트를 캐시하여 재계산 비용 제거
캐시 동작 원리·cachePoint 적용 코드·모델별 최소 토큰과 TTL 지원 범위는 Amazon Bedrock 추론 인프라 모듈(운영 전략 파트)에서 다룹니다.
모델별 최소 캐시 토큰(512~4,096)을 넘겨야 캐시가 성립합니다 — 캐시 쓰기는 1.25× 할증(1시간 TTL은 2×)이라 두 번째 호출부터 이득입니다.
maxTokens 태스크별 설정
출력 한도를 태스크에 맞게 설정 — 불필요한 생성을 방지
| 태스크 | 권장 maxTokens | 이유 |
|---|---|---|
| 분류/라벨링 | 10~50 | "긍정/부정" 한 단어면 충분 |
| JSON 추출 | 200~500 | 구조화된 짧은 출력 |
| 요약 | 300~800 | 원문의 10~20% |
| QA | 500~1,500 | 설명 포함 답변 |
| 코드 생성 | 2,000~4,000 | 함수 단위 |
분류에 코드 생성용 한도를 쓰면 낭비 — 태스크별로 출력 한도를 다르게 설정합니다.
context_manager="auto"
Strands SDK의 자동 컨텍스트 관리 — 비용 55% 절감 · 정확도 68%→98% (코드 조사 태스크, Strands 자체 벤치마크)
수동 설정
- SlidingWindowConversationManager 직접 설정
- ContextOffloader 별도 구성
- threshold, window_size 튜닝 필요
- 잘못 설정하면 정확도 저하
context_manager="auto"
- SummarizingCM + ContextOffloader 자동 결합
- summary_ratio=0.3, compression_threshold=0.85 기본값
- max_result_tokens=1,500 자동 오프로딩
- 코드 1줄 — Agent(context_manager="auto")
수동 튜닝 대신 코드 1줄의 auto로 요약과 오프로딩이 자동 결합됩니다.
RAG와 에이전트 비용
Top-K · 청크 최적화 · 반복 상한 · 도구 캐싱
RAG · 에이전트 비용
검색은 입력 토큰, 에이전트는 루프 — 새는 비용을 막는 두 지점
Top-K · 반복 상한 · 결과 캐싱
RAG는 입력 토큰을 줄이고, 에이전트는 루프와 도구 호출을 통제합니다.
- Top-K 축소 · Reranking — 입력 토큰 절감
- 반복 상한 — Hooks · Swarm · Harness
- 도구 결과 캐싱 — DynamoDB TTL
- 모델 분리 — 오케스트레이터만 Opus
통제 없는 에이전트 루프는 수백 달러를 수 분 안에 과금할 수 있습니다 — 반복 상한 설정이 최우선입니다.
RAG 비용 최적화
임베딩 · 벡터 스토어 · LLM 입력 — 3곳 동시 절감
| 기법 | 효과 | 구현 |
|---|---|---|
| Top-K 축소 | 입력 토큰 감소 — 청크 수에 비례 | numberOfResults로 반환 청크 수 제한 |
| 청크 크기 최적화 | 불필요한 컨텍스트 제거 | 300~500 토큰 권장 |
| 메타데이터 필터링 | 검색 범위 축소 | 카테고리/날짜 필터 |
| Reranking | 상위만 LLM에 전달 | Top-K=20 검색 → Rerank → Top-3만 사용 |
| Managed Knowledge Base | 인프라 비용 제거 | Bedrock Managed Knowledge Base 사용 |
Top-K=20으로 검색하고 Rerank로 Top-3만 전달 — 검색은 넓게, LLM 입력은 좁게가 원칙입니다.
에이전트 비용 폭증 시나리오
통제가 없으면 수 분 안에 수백 달러 — 과금 폭주 위험
세 시나리오 모두 사후 대응이 아니라 상한·요약·라우팅의 사전 설정으로 막습니다.
에이전트 비용 억제 체크리스트
도구 호출 1회 = LLM 왕복 2회 — 루프 5회면 10회+ 호출
-
1
반복 상한 설정
Strands Agent 생성자에는 상한 파라미터 없음 — 호출 시 limits(turns·output_tokens·total_tokens)가 1차 수단, 보조로 Hooks cancel_tool·Swarm max_iterations·Harness maxIterations
-
2
도구 선택 최적화
불필요한 도구를 제거하면 시스템 프롬프트 토큰 감소 + 잘못된 호출 방지
-
3
결과 캐싱
같은 도구 호출 결과를 단기 캐시 (DynamoDB TTL) — 동일 질문 반복 시 모델 호출 0
-
4
경량 도구 우선
비용 높은 도구(Browser, Code Interpreter)는 필요 시에만 활성화
-
5
모델 분리
오케스트레이터만 Opus, 실행 워커는 Haiku/Nova — 멀티에이전트 비용 최적화
도구 호출 1회가 LLM 왕복 2회 — 반복 상한과 도구 축소만으로도 루프 비용이 크게 줄어듭니다.
비용 모니터링
IAM Principal · CloudWatch · Budget Actions · FinOps
비용 모니터링
귀속 · 계층 감시 · 자동 차단 — 비용을 놓치지 않는 체계
귀속 · 4계층 · 자동 차단
IAM Principal로 비용을 귀속하고, 4계층으로 감시하며, Budget Actions로 자동 차단합니다.
- IAM Principal — 팀·에이전트별 비용 귀속
- 4계층 — 실시간 · 일일 · 월간 · 예방
- CloudWatch 알람 + Budget Actions
- 즉시 적용 체크리스트 6항목
측정할 수 없으면 최적화할 수 없습니다 — 비용 귀속과 알람이 통제 루프의 시작입니다.
IAM Principal 비용 귀속
어떤 팀·에이전트가 얼마나 쓰는지 IAM 역할 기반으로 자동 분류 — 대시보드 시각화와 예산 알람까지
-
1
에이전트 호출
IAM 역할 기반 Bedrock API 호출
-
2
자동 귀속
IAM 사용자/역할별 비용 자동 분류
-
3
대시보드
팀별·에이전트별·모델별 비용 시각화
-
4
알람
예산 초과 시 CloudWatch 알람 → SNS 알림
누가 얼마나 쓰는지 모르면 통제할 수 없습니다 — IAM 역할 기반 자동 귀속이 FinOps의 출발점입니다.
4계층 모니터링 체계
실시간부터 예방까지 — 비용을 놓치지 않는 계층 설계
실시간 — CloudWatch 메트릭
Invocations, InputTokenCount, OutputTokenCount 실시간 모니터링 + 알람
일일 — Cost Explorer
일별 비용 추이, 서비스별 분해, 이상 탐지
월간 — CUR 2.0 (Cost & Usage Report)
상세 비용 분석, 팀별 배분, 트렌드 파악
예방 — Budget Actions
임계값 도달 시 IAM 정책 적용·SNS 알림 등 사전 정의 액션 실행
즉시 적용 체크리스트
오늘 바로 적용할 수 있는 6가지 최적화
-
1
maxTokens 설정
태스크별 출력 한도 지정 — 분류 10~50, 요약 300~800 등 불필요한 생성 방지
-
2
Prompt Caching 활성화
반복되는 시스템 프롬프트에 캐시 적용 — 캐시 히트 시 입력 토큰 90% 절감
-
3
모델 라우팅
단순 태스크는 Haiku로 자동 분기 — 복잡한 추론만 Opus 사용
-
4
RAG Top-K 축소
반환 청크를 Top-K=3 수준으로 제한 — LLM 입력 토큰 즉시 감소
-
5
반복 상한
호출 시 limits + Swarm·Harness maxIterations로 에이전트 루프 통제 — 과금 폭주 차단
-
6
비용 태그
팀·에이전트별 비용 귀속 태그 적용 — 측정이 통제의 시작
비용 최적화 실습
모델 라우팅, Prompt Caching, 비용 알람을 직접 구현합니다
학습 목표
- 태스크별 모델 라우팅 구현
- Prompt Caching 적용과 캐시 히트 확인
- CloudWatch 비용 알람 설정
- 반복 상한(호출 시 limits·Swarm·Harness maxIterations)으로 에이전트 비용 제한
비용 구조 파악 → 모델 라우팅 → 토큰 절감 → 모니터링 = 비용 통제 루프