작성자 Claude 모델 입력 및 출력 토큰 비용 차이와 이유
Claude의 출력 토큰 비용이 입력보다 5배 비싼 기술적 이유를 설명합니다. Prefill과 Decoding의 연산 구조 차이로 발생하는 메모리 대역폭 문제와, 실제 에이전트 작업 시 토큰 비율에 따른 월간 비용 변화를 구체적인 계산 사례로 확인해 보시기 바랍니다.
출력 토큰 비용이 입력 토큰보다 비싼 이유
현재 제공되는 모든 Claude 모델에서 출력 토큰은 입력 토큰보다 5배 더 비쌉니다. 이는 연산 구조 때문입니다. 프롬프트를 읽는 과정은 모델을 한 번 통과하는 것으로 끝납니다. 반면 답변을 작성하는 과정은 토큰당 한 번씩 모델을 통과해야 하며, 각 단계는 이전 단계가 완료될 때까지 대기해야 합니다.
이 비율은 가격표의 모든 항목에서 동일하므로, 어떤 모델을 선택하더라도 전체 비용에서 출력 토큰이 차지하는 비중은 변하지 않습니다. 이는 작업의 성격에 따라 결정됩니다. 60,000개의 토큰을 읽고 800개의 토큰으로 답변하는 에이전트 작업은 출력 비용이 거의 발생하지 않습니다. 반대로 2,000개의 토큰을 읽고 12,000개의 토큰을 작성하는 초안 작성 작업은 입력 비용이 거의 발생하지 않습니다. 두 사례 모두 아래에서 Anthropic의 2026년 8월 공시 요금을 기준으로 계산합니다.
Prefill은 한 번 실행되고, Decoding은 토큰당 한 번 실행됩니다
추론 서버는 비용 구조가 매우 다른 두 단계로 요청을 처리합니다. Prefill은 프롬프트를 읽고, Decoding은 응답을 작성합니다.
Prefill은 전체 프롬프트를 한 번에 처리합니다. 모든 프롬프트 토큰이 동일한 순전파(forward pass) 과정에서 네트워크로 입력되므로, 어텐션(attention)과 피드포워드(feed-forward) 작업은 한 번에 수천 개의 토큰을 처리하는 소수의 대규모 행렬 곱셈이 됩니다. 모델 가중치를 메모리에서 한 번 읽는 것으로 전체 프롬프트 처리가 가능합니다. 가속기의 행렬 연산 장치가 계속 작동하므로 Prefill은 연산 제한적(compute-bound)입니다. 즉, 칩이 얼마나 빨리 곱셈을 수행할 수 있는지가 성능을 결정합니다.
Decoding은 토큰 2가 토큰 1에 의존하기 때문에 이런 방식으로 작동할 수 없습니다. 모델이 방금 생성한 토큰이 다음 단계의 입력 일부가 되므로, 각 단계를 동시에 실행할 수 없습니다. 각 출력 토큰은 개별적인 순전파 과정을 거치며, 이 과정마다 단 하나의 토큰을 생성하기 위해 전체 모델 가중치를 고대역폭 메모리에서 읽어와야 합니다. 이로 인해 Decoding은 메모리 제한적(memory-bound)이 됩니다. 즉, 성능은 곱셈 속도가 아니라 가중치를 얼마나 빨리 이동시킬 수 있는지에 따라 결정됩니다. Prefill 단계에서 전체 프롬프트를 처리하는 데 사용된 것과 동일한 가중치 트래픽이 Decoding 단계에서는 단 하나의 토큰을 생성하는 데 소모됩니다.
서버 시스템은 배치(batching)를 통해 이에 대응합니다. 여러 요청을 함께 Decoding하면 가중치를 한 번 읽는 것으로 배치 내 각 요청에 대해 토큰을 하나씩 생성할 수 있습니다. 이것이 Decoding이 그나마 비용 효율적인 이유입니다. 여기서도 한계는 메모리입니다. 진행 중인 모든 요청은 KV 캐시(key/value cache, 지금까지 생성된 각 토큰의 어텐션 상태를 저장)를 유지하며, 이 캐시는 토큰이 생성될 때마다 커집니다. 캐시가 가속기를 가득 채우면 배치를 더 이상 늘릴 수 없습니다.
위 내용이 정확한 수치를 제공하는 것은 아니며, 5x라는 수치를 측정된 하드웨어 비율로 받아들여서는 안 됩니다. 이는 이러한 비대칭성을 고려하여 Anthropic이 책정한 가격입니다. 직접 확인할 수 있는 것은 방향성뿐이며, 확인하는 데는 약 1분 정도 소요됩니다.
입력과 출력의 간극을 직접 측정하기
Ubuntu 서버에 도구를 설치합니다.
sudo apt update && sudo apt install -y curl jq moreutils이제 긴 답변을 요구하는 짧은 프롬프트를 스트리밍하고, 각 줄이 도착한 시간을 기록합니다.
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
"messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
| ts -s '%.s'ts -s는 각 줄 앞에 명령 실행 후 경과된 시간을 표시합니다. 출력에서 확인해야 할 두 가지 사항이 있습니다. 첫 번째 content_block_delta 줄은 첫 번째 토큰이 생성되기까지 걸린 시간이며, 이 시간 내에 모든 prefill 과정이 완료됩니다. 그 이후의 모든 줄은 디코딩의 작은 단계들이며, message_stop이 도착할 때까지 시간 기록은 계속 증가합니다.
이제 상황을 반대로 설정합니다. 프롬프트에 긴 문서를 넣고 답변은 몇 개의 토큰으로 제한합니다.
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d "$(jq -n --rawfile doc ./long-document.txt \
'{model:"claude-sonnet-5", max_tokens:16, stream:true,
messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
| ts -s '%.s'첫 번째 델타 값은 짧은 프롬프트를 사용했을 때보다 더 오래 걸립니다. prefill 과정에서 읽어야 할 텍스트가 훨씬 많기 때문입니다. 첫 번째 토큰이 도착한 후에는 디코딩할 토큰이 거의 남지 않아 응답이 즉시 종료됩니다. 수만 개의 토큰이 입력될 때는 시간이 거의 흐르지 않지만, 수백 개의 토큰이 출력될 때는 전체 시간이 소요됩니다.
스트리밍하지 않는 모든 응답은 청구 대상이 되는 토큰 수와 함께 종료됩니다.
{
"usage": {
"input_tokens": 41283,
"output_tokens": 6,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 0
}
}요청당 네 가지 필드를 모두 기록하십시오. output_tokens에는 확장된 사고 과정이 포함되므로, 답변하기 전에 생각하는 모델은 해당 사고 과정에 대해서도 출력 요금으로 비용을 청구합니다. 프롬프트를 전송하기 전에 가격을 책정하려면, POST /v1/messages/count_tokens에 동일한 요청 본문을 전달하십시오. 모델을 실행하지 않고 {"input_tokens": N}를 반환하며, 이 과정은 무료입니다.
2026년 8월 기준 Claude의 백만 토큰당 비용
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_usd": 1,
"output_usd": 5,
"output_multiple": 5
},
{
"label": "Sonnet 5 (to 31 Aug)",
"input_usd": 2,
"output_usd": 10,
"output_multiple": 5
},
{
"label": "Sonnet 5 (from 1 Sep)",
"input_usd": 3,
"output_usd": 15,
"output_multiple": 5
},
{
"label": "Opus 5",
"input_usd": 5,
"output_usd": 25,
"output_multiple": 5
},
{
"label": "Fable 5",
"input_usd": 10,
"output_usd": 50,
"output_multiple": 5
}
]마지막 열은 출력 비용을 입력 비용으로 나눈 값이며, 모든 행에서 5로 표시됩니다. Haiku 4.5는 입력 시 $1, 출력 시 $5가 청구됩니다. Opus 5는 입력 시 $5, 출력 시 $25가 청구됩니다. 가장 비용이 높은 Fable 5는 입력 시 $10, 출력 시 $50가 청구됩니다. 상위 모델로 갈수록 양쪽 비용에 동일한 배수가 적용되므로, 전체 비용은 변하지만 입력과 출력의 비율은 그대로 유지됩니다.
Sonnet 5는 도입부 요율이 만료되기 때문에 두 번 나열되었습니다. 2026년 8월 31일까지는 입력 시 $2, 출력 시 $10가 청구됩니다. 2026년 9월 1일부터는 표준 요율인 입력 시 $3, 출력 시 $15가 적용되며, 이는 양쪽 모두 50% 인상된 금액입니다. 아래의 모든 작업 예시는 8월 요율을 기준으로 합니다.
요금은 변경될 수 있으며, 이 페이지는 요금을 확인하는 공식적인 장소가 아닙니다. claude.com/pricing이 신뢰할 수 있는 출처입니다. 가격 변동에도 변하지 않는 것은 계산 방식입니다.
가격표에 나타나지 않는 한 가지 주의 사항이 있습니다. Anthropic의 문서에 따르면 Claude 4.7 이후 모델은 더 새로운 토크나이저를 사용하며, 이는 Sonnet 4.6 이전 모델의 토크나이저보다 동일한 텍스트에 대해 약 30% 더 많은 토큰을 생성합니다. 백만 토큰당 가격만으로 두 모델을 비교하면 더 새로운 모델이 더 저렴해 보일 수 있는데, 이는 동일한 문서라도 새로운 모델에서는 더 많은 토큰으로 계산되기 때문입니다. 완료된 작업당 비용으로 비교하고, 실제로 사용할 모델을 기준으로 실제 프롬프트를 계산하십시오. Claude의 백만 토큰이 실제 텍스트로 어느 정도 분량인지에서 해당 분량이 실제로는 어느 정도인지 다룹니다.
출력 비용이 청구서에서 차지하는 비중이 커지는 시점은 언제입니까?
출력 비용이 입력 비용의 5배로 책정되므로, 손익분기점은 머릿속으로 쉽게 계산할 수 있습니다. 입력 토큰을 I, 출력 토큰을 O라고 합시다. 입력 비용은 I입니다. 출력 비용은 O의 5배입니다. 5배의 O가 I보다 커지면 출력 비용이 전체 지출의 절반을 넘어서게 되며, 이는 입력 대 출력 토큰 비율이 5 대 1일 때 발생합니다.
따라서 프롬프트가 응답보다 5배 이상 길다면 입력 비용이 더 큰 비중을 차지합니다. 그보다 짧다면 출력 비용이 더 큽니다.
The data behind this chart
[
{
"label": "100:1",
"input_share_pct": 95.2,
"output_share_pct": 4.8
},
{
"label": "75:1",
"input_share_pct": 93.75,
"output_share_pct": 6.25
},
{
"label": "20:1",
"input_share_pct": 80,
"output_share_pct": 20
},
{
"label": "10:1",
"input_share_pct": 66.7,
"output_share_pct": 33.3
},
{
"label": "5:1",
"input_share_pct": 50,
"output_share_pct": 50
},
{
"label": "1:1",
"input_share_pct": 16.7,
"output_share_pct": 83.3
},
{
"label": "1:6",
"input_share_pct": 3.2,
"output_share_pct": 96.8
}
]비율이 100 대 1일 때 출력 비용은 지출의 4.8%를 차지하며, 이때는 프롬프트를 줄이는 것만이 유일하게 가치 있는 작업입니다. 5 대 1일 때는 양쪽 비용이 동일합니다. 1 대 6일 때는 출력 비용이 96.8%를 차지하며 프롬프트 비용은 오차 범위 수준으로 줄어듭니다. 대부분의 사용자는 자신의 토큰 비율을 잘못 추측하므로, 최적화를 시작하기 전에 반드시 로그에서 실제 데이터를 확인하십시오.
에이전트 워크로드: 긴 컨텍스트 입력, 짧은 답변 출력
검색 에이전트 단계를 하나 수행해 보겠습니다. 검색된 문서와 대화 기록으로 구성된 60,000 토큰의 입력과 800 토큰의 답변이 있습니다. 이는 75 대 1의 비율로, 쓰기 전에 읽기가 선행되는 모든 작업에서 일반적인 수치입니다.
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_cost": 0.06,
"output_cost": 0.004,
"total_cost": 0.064
},
{
"label": "Sonnet 5 (Aug)",
"input_cost": 0.12,
"output_cost": 0.008,
"total_cost": 0.128
},
{
"label": "Opus 5",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "Fable 5",
"input_cost": 0.6,
"output_cost": 0.04,
"total_cost": 0.64
}
]모든 모델에서 출력은 해당 호출의 6.25%를 차지하며, 이는 전체 가격표에서 비율이 고정되어 있기 때문입니다. 이 호출 비용은 Opus 5에서 $0.32, 8월 요금 기준 Sonnet 5에서 $0.128, Haiku 4.5에서 $0.064입니다. Opus 5에서 하루에 이러한 단계를 200번 수행하면 하루 $64가 소요됩니다.
분할된 내역을 확인하면 무엇을 조정해야 할지 명확해집니다. 답변을 800 토큰에서 400 토큰으로 줄여도 호출 비용의 약 3%만 절감됩니다. 반면 프롬프트에서 불필요한 컨텍스트 20,000 토큰을 제거하면 비용의 약 3분의 1을 절감할 수 있습니다. 읽기 비중이 높은 에이전트에서 출력 길이를 줄이는 것은 거의 헛수고에 가깝습니다. 코딩 에이전트의 토큰이 실제로 소비되는 곳에서 프롬프트를 채우는 요소들을 상세히 분석합니다.
생성 워크로드: 짧은 프롬프트, 긴 초안
이제 형태를 뒤집어 보겠습니다. 2,000 토큰의 브리핑과 12,000 토큰의 초안, 즉 1 대 6의 비율입니다.
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_cost": 0.002,
"output_cost": 0.06,
"total_cost": 0.062,
"batch_total_cost": 0.031
},
{
"label": "Sonnet 5 (Aug)",
"input_cost": 0.004,
"output_cost": 0.12,
"total_cost": 0.124,
"batch_total_cost": 0.062
},
{
"label": "Opus 5",
"input_cost": 0.01,
"output_cost": 0.3,
"total_cost": 0.31,
"batch_total_cost": 0.155
},
{
"label": "Fable 5",
"input_cost": 0.02,
"output_cost": 0.6,
"total_cost": 0.62,
"batch_total_cost": 0.31
}
]출력은 이 비용의 96.8%를 차지합니다. Opus 5는 초안당 $0.31의 비용이 드는 반면, Haiku 4.5는 $0.062가 소요됩니다. 이 5배의 차이는 거의 전적으로 출력 측면에서 발생하며, 바로 이 지점이 저렴한 모델이 비용을 가장 크게 절감해 주는 부분입니다.
마지막 열은 Batch API를 통해 동일한 작업을 수행한 결과이며, 입력과 출력 비용을 50% 절감합니다. Opus 5의 비용은 초안당 $0.155로 낮아집니다. Batch는 즉시 결과가 나오는 대신 24시간 이내에 결과를 반환하므로, 야간 보고서 생성이나 대량 분류 작업에 적합합니다. 사용자가 앉아서 기다려야 하는 작업에는 적합하지 않습니다.
모델 라우팅은 에이전트 단계에서는 결코 얻을 수 없는 방식으로 여기서 비용 효율을 제공합니다. 작업의 장황한 부분이 텍스트 재형식화나 이미 승인된 개요를 확장하는 것과 같은 기계적인 작업이라면, 저렴한 모델은 해당 토큰을 5분의 1 가격으로 생성합니다. Opus, Sonnet, Haiku 선택하기에서 품질의 기준선이 실제로 어디에 위치하는지 다룹니다.
입력에만 적용되는 캐싱 할인
프롬프트 캐싱은 프롬프트의 접두사를 서버에 저장하며, 이를 다시 읽을 때 입력 요금의 일부만 부과합니다. 2026년 8월 기준으로 배율은 다음과 같습니다. 5분 캐시 작성 시 기본 입력 요금의 1.25배, 1시간 캐시 작성 시 2배가 적용되며, 캐시 적중 시 읽기 요금은 0.1배입니다.
출력은 이 할인 대상이 아닙니다. 캐시된 출력은 존재하지 않습니다. 프롬프트의 상당 부분이 캐시 적중으로 처리되더라도, 모델이 생성하는 모든 토큰은 매번 전체 출력 요금으로 청구됩니다.
Opus 5에서 동일한 에이전트 단계를 수행할 때, 60,000개의 입력 토큰 중 55,000개가 활성 캐시에서 제공되는 경우를 가정해 보겠습니다.
The data behind this chart
[
{
"label": "No cache",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "55k prefix cache read",
"input_cost": 0.0525,
"output_cost": 0.02,
"total_cost": 0.0725
}
]호출 비용은 $0.32에서 $0.0725(으)로 감소합니다. 출력 비용은 변하지 않습니다. 이전에는 $0.02였으며, 이후에도 $0.02입니다. 캐싱은 청구 금액을 줄이고 그 구성 비율을 바꿉니다. 해당 호출에서 출력 비용이 차지하는 비중은 6.25%였습니다. 이제는 전체의 4분의 1 이상을 차지하게 되었으며, 이는 다음에 어떤 비용 절감 요소를 우선적으로 고려해야 할지 결정하는 기준을 바꿉니다.
첫 번째 호출에서 작성 비용이 발생합니다. 5분 캐시 작성 비용은 기본 입력의 1.25배이므로, 단 한 번의 적중만으로도 비용을 상쇄합니다. 1시간 캐시 작성 비용은 2배이므로 두 번의 적중이 필요합니다. 작성 및 읽기 배율과 캐싱의 경제성이 멈추는 지점에서 해당 계산 과정을 확인할 수 있습니다.
제어 가능한 4가지 요소
max_tokens를 모델 최대치가 아닌 p95 출력 길이에 맞추어 설정하십시오.- 장황한 단계는 더 저렴한 모델로 라우팅하십시오.
- 즉시 응답이 필요하지 않은 작업은 배치(batch) 처리하십시오.
- 응답 길이를 늘리는 불필요한 지시사항을 삭제하십시오.
max_tokens은 엄격한 상한선이며, 이를 높게 설정한다고 해서 그 자체로 비용이 발생하지는 않습니다. 요금은 생성된 토큰에 대해서만 부과되며 상한선 설정과는 무관하기 때문입니다. 넉넉한 상한선은 응답이 비정상적으로 길어질 때 발생하는 제한을 제거하는 역할을 합니다. 로그에서 output_tokens 분포를 추출하여 95번째 백분위수보다 약간 높게 상한선을 설정하고, stop_reason: "max_tokens"은 응답을 이어가거나 재시도하는 방식으로 코드에서 처리하십시오. 감지된 잘림(truncation)은 비용을 지불하고 버려야 하는 4,000 토큰 분량의 장황한 응답보다 비용이 적게 듭니다. 확장된 사고(extended thinking) 역시 output_tokens에 포함되므로, 동일한 근거를 바탕으로 예산을 설정하십시오.
라우팅은 단계의 비용이 판단보다는 분량에서 발생할 때 효과적입니다. 의사결정은 강력한 모델에 맡기고, 텍스트 작성은 더 저렴한 모델에 위임하십시오. 저렴한 모델이 두 번의 시도를 거치게 되면 한 번의 비싼 모델 시도보다 비용이 더 많이 들 수 있으므로, 반드시 자체 평가 세트로 라우팅된 버전을 먼저 측정하십시오.
배치는 출력 비용을 할인받을 수 있는 유일한 수단입니다. 24시간 이내에 결과가 필요한 작업이나 일정에 따라 수행되는 모든 작업은 50% 할인 대상이 됩니다.
마지막 요소는 사람들이 흔히 간과하는 부분입니다. "철저하게 작성하라"거나 "추론 과정을 설명하라"와 같은 문구는 모든 호출에서 출력 길이를 결정짓습니다. 이를 원하는 형태로 대체하십시오. 예를 들어 "최대 3문장으로 답변하라"거나 "서론 없이 JSON 객체만 반환하라"와 같이 지시하십시오. 모든 응답에 300 토큰을 추가하는 시스템 프롬프트는 프롬프트 자체에 포함된 동일한 300 토큰보다 5배 더 많은 비용이 듭니다. 실행 중인 에이전트 비용 제어하기에서는 모니터링 측면을 다루며, 사용 패턴에 따라 API와 정액제 중 무엇이 더 저렴한지는 토큰당 비용을 일주일간 튜닝하기 전에 미리 결정하는 것이 좋습니다. 정액제라면 이러한 비용 고민을 해결할 수 있기 때문입니다.
FAQ
출력 토큰이 입력 토큰보다 비싼 이유는 무엇입니까?
토큰당 가속기 사용 시간이 훨씬 더 많이 소요되기 때문입니다. 프롬프트는 전체 내용을 한 번의 순방향 패스(forward pass)로 처리하므로, 모델 가중치를 한 번만 읽으면 수천 개의 토큰을 처리할 수 있고 하드웨어는 곱셈 처리량(multiply throughput)에 의해 제한됩니다. 반면 응답은 토큰을 하나씩 생성하며, 각 토큰마다 전체 모델 가중치를 다시 읽는 순방향 패스가 필요하므로 하드웨어는 메모리 대역폭에 의해 제한됩니다. Anthropic은 Haiku 4.5부터 Fable 5까지 현재 전체 카탈로그에 대해 출력 가격을 입력 가격의 5배로 책정하고 있습니다.
프롬프트 캐싱을 사용하면 출력 토큰이 저렴해집니까?
아니요. 프롬프트 캐싱은 입력에만 적용됩니다. 2026년 8월 기준으로 캐시 읽기 비용은 기본 입력 요금의 0.1배이며, 캐시 쓰기 비용은 5분 유지 시 1.25배, 1시간 유지 시 2배입니다. 출력은 캐시 사용 여부와 관계없이 모든 호출에서 정액으로 청구됩니다. 이것이 바로 캐싱이 청구서의 크기뿐만 아니라 구성 형태도 바꾸는 이유입니다. 입력 비용이 줄어들면, 전체 비용에서 출력 비용이 차지하는 비중이 커지기 때문입니다.
max_tokens을 높게 설정하면 응답이 짧게 돌아올 경우 비용이 더 발생합니까?
아니요. 모델이 실제로 생성한 토큰에 대해서만 비용이 청구되므로, max_tokens은 예약이 아닌 상한선일 뿐입니다. 하지만 응답이 무한정 길어지는 것을 막는 유일한 강제 제한이므로 여전히 중요합니다. 관찰된 output_tokens의 95분위수보다 약간 높게 설정한 다음, 답변이 조용히 잘리는 것을 방지하기 위해 코드 수준에서 stop_reason: "max_tokens"을 처리하십시오.
입력 대비 출력 토큰 비율은 어떻게 확인합니까?
모든 응답의 usage 객체에서 input_tokens, output_tokens, cache_read_input_tokens 및 cache_creation_input_tokens을 기록한 뒤, 일주일간의 총합을 나누어 계산하십시오. 입력 대 출력 비율이 5:1을 넘는다면 비용의 대부분이 프롬프트에서 발생하므로, 변하지 않는 부분을 캐싱하고 나머지를 줄이십시오. 그보다 낮다면 비용의 대부분이 응답에서 발생하므로, 응답 길이를 제한하고 응답을 많이 생성하는 단계를 더 저렴한 모델이나 Batch API로 옮기십시오.