LLM API 출력 토큰이 입력 토큰보다 4~8배 비싼 이유

주요 LLM API의 가격 페이지를 아무거나 열어 보세요. OpenAI든 Anthropic이든 Google이든 상관없이 매번 같은 모양이 보입니다. 출력 토큰이 입력 토큰보다 몇 배 비쌉니다. 그것도 소소한 웃돈이 아닙니다. 현행 모델들에서 이 비율은 일관되게 4배에서 8배 사이입니다. 특정 벤더만의 가격 책정 버릇이 아니라, 이 모델들이 실제로 동작하는 방식의 직접적인 결과입니다.

진짜 이유: 입력은 병렬, 출력은 순차

입력 토큰 — 프롬프트, 시스템 메시지, 대화 기록 — 의 처리는 단일 순전파 한 번으로 끝납니다. 모델이 전체 입력을 한 번에 읽고 그 전체에 걸친 어텐션을 병렬로 계산합니다. 현대 GPU는 이런 배치·병렬 연산에 극도로 뛰어나서, 3,000토큰 프롬프트와 300토큰 프롬프트의 연산 시간이 토큰 수 비율만큼 차이 나지 않습니다. 지배적인 비용은 읽는 내용의 길이가 아니라 모델을 한 번 돌리는 오버헤드입니다.

출력 토큰 생성은 근본적으로 다릅니다. 새 토큰 하나하나가 그 앞의 모든 토큰 — 모델이 방금 생성한 것들 포함 — 에 의존합니다. 응답의 500번째 토큰은 499번째 토큰이 존재하기 전에는 계산될 수 없습니다. 이것이 순차 루프를 강제합니다. 출력 토큰 하나당 순전파 한 번씩, 차례대로, 시퀀스 방향으로는 병렬화할 방법 없이요. 출력 토큰 500개를 만든다는 건 모델을 한 번이 아니라 연달아 500번 돌린다는 뜻입니다.

이 연산의 비대칭 — 입력은 병렬 패스 한 번, 출력 토큰 N개에는 순차 패스 N번 — 이 바로 회사, 모델 아키텍처, 지역과 무관하게 모든 주요 제공사의 가격표가 같은 모양인 이유입니다. 사업적 결정이라기보다는 밑단 연산 비용의 직접적인 전가에 가깝습니다.

프롬프트에 갖는 의미

실용적인 교훈은 직설적입니다. 장황한 모델 응답은, 총 토큰 수가 비슷해 보여도 긴 프롬프트에 짧은 답변보다 불균형하게 비쌉니다. API 지출을 줄이려 한다면, 입력 길이를 줄이는 것보다 출력 길이를 줄이는 쪽이 대개 토큰당 절감액이 큽니다.

구체적인 손잡이 몇 가지:

• 응답 길이를 명시적으로 제한하세요. “answer in one paragraph” 같은 시스템 프롬프트 지시나 max_tokens 제한이 자기 프롬프트를 줄이는 것보다 비용에 더 효과적입니다.
• 산문 대신 구조화된 출력을 요청하세요. 필드 세 개짜리 JSON 객체는 같은 내용을 문장으로 풀어 쓴 것보다 훨씬 짧은 경우가 많고, 후속 처리에도 똑같이 유용합니다.
• 출력을 아끼려고 시스템 프롬프트 설명을 아끼지 마세요. 짧고 정확한 답변(비싼 출력)을 안정적으로 끌어내는 길고 정밀한 시스템 프롬프트(싼 입력)가, 모델이 긴 응답으로 얼버무리게 만드는 짧고 모호한 프롬프트보다 대개 나은 거래입니다.
• 대량·저복잡도 출력에는 더 싼 모델을 쓰세요. 분류, 추출, 짧은 답변처럼 프런티어 모델의 추론이 필요 없는 작업이라면, 저가 티어 모델의 출력 단가는 자릿수가 다르게 낮은 경우가 많습니다.

실제 금액 계산하기

이 비율은 출력이 왜 더 비싼지를 설명하지만, 정확한 금액은 어떤 모델을 쓰는지와 요청의 양쪽이 실제로 몇 토큰을 소비하는지에 달려 있습니다. 입력/출력 단가 — 그리고 둘 사이의 배율 — 는 모델마다 정말로 다르기 때문에(저가 모델과 플래그십 모델이 같은 비율을 적용하지 않습니다), 실제 비용을 아는 유일하게 믿을 만한 방법은 모델별로 자신의 실제 숫자를 넣어 보는 것입니다.

CodeKitHub의 LLM API 가격 계산기가 정확히 그 일을 합니다. 모델을 고르고 입력·출력 토큰 수를 넣으면 입력 비용, 출력 비용, 합계를 보여 주고, 대략적인 요청 횟수를 안다면 월간 추정치도 알려 줍니다. 실제 프롬프트가 몇 토큰인지 확실하지 않다면 Token Counter 도구가 대략적인 글자 수 기반 추측이 아니라 실제 토크나이저로 정확한 개수를 알려 줍니다.

두 도구 모두 브라우저 안에서만 동작합니다 — API 키도, 계정도 필요 없고 아무것도 어디로도 전송되지 않습니다.