토큰의 비용: 모델 요금은 어떻게 매겨지는가

API로 모델을 쓸 때, 요청당이나 단어당으로 청구되지 않습니다. 토큰당으로 청구됩니다. 토큰은 모델이 실제로 읽고 쓰는 단위이며, 모델 청구서의 거의 모든 깜짝 놀랄 일은 토큰이 무엇이고 어느 것에 비용을 내는지 이해하지 못한 데서 옵니다. 좋은 소식은, 요금 체계의 모양을 한번 보고 나면 단순하며, 몇 가지 습관만으로 비용을 예측 가능하게 유지할 수 있다는 것입니다. 나쁜 소식은, 청구서를 끌어올리는 부분이 화면에 보이는 텍스트에서는 흔히 보이지 않는다는 것입니다.

이 글은 토큰이 무엇인지, 입력과 출력의 가격이 왜 다른지, 숨은 토큰이 어디에 도사리는지, 그리고 쓸 비용을 어떻게 추정하고 통제할지를 설명합니다 — 모두 어느 제공사나 모델을 쓰든 통하는 원리로요.

토큰이 실제로 무엇인가

토큰은 텍스트의 한 덩어리입니다 — 대략 한 단어이지만, 정확히 그렇지는 않습니다. 모델은 글자나 온전한 단어를 읽지 않고, 텍스트를 그 중간 어딘가에 놓인 조각들로 쪼갭니다. 흔한 짧은 단어는 토큰 하나일 수 있고, 더 길거나 덜 흔한 단어는 둘이나 셋으로 쪼개질 수 있습니다. 공백, 문장부호, 서식도 셈에 들어갑니다. 사람들이 쓰는 대략적인 어림짐작은 토큰이 평균적으로 한 단어보다 조금 짧다는 것이지만, 정확히 아는 유일한 방법은 모델의 토크나이저가 세게 두는 것뿐입니다.

중요한 결과는, 토큰 수가 길이에 대한 내 직관과 깔끔하게 맞아떨어지지 않는다는 점입니다. 빽빽하거나 기술적이거나 비영어 텍스트는 단어당 토큰을 더 많이 쓸 수 있습니다. 문장부호와 기호가 많은 코드는 토큰이 무거울 수 있습니다. 그러니 "내 텍스트가 얼마나 긴가"는 잘못된 질문이고, "내 텍스트가 몇 토큰인가"가 청구서가 신경 쓰는 질문이며, 둘은 예상보다 더 벌어질 수 있습니다.

입력 토큰과 출력 토큰은 가격이 다르다

모델과의 모든 상호작용에는 두 갈래의 토큰 흐름이 있고, 이 둘은 거의 항상 다른 값이 매겨집니다. 입력 토큰은 내가 보내는 모든 것입니다 — 프롬프트, 지시, 포함한 문서나 예시. 출력 토큰은 모델이 되돌려 생성하는 모든 것입니다. 제공사들은 이 둘에 따로 가격을 매기며, 출력 토큰이 대개 둘 중 더 비쌉니다.

이유는 생성이 작동하는 방식에 뿌리를 둡니다. 입력을 읽는 것은 한 번의 패스입니다. 모델이 전부 받아들여 처리하죠. 출력을 만드는 것은 한 번에 한 토큰씩 일어나며, 각 단계는 지금까지 생성된 모든 것에 의존하는 새로운 연산입니다. 그 단계별 생성이 비싼 부분이며, 그래서 생성된 출력은 보통 그것이 응답한 입력보다 더 높은 값을 답니다. 이를 알면 최적화 방식이 바뀝니다. 긴 출력이 흔히 긴 입력보다 청구서에 더 큰 지렛대입니다.

청구서를 끌어올리는 숨은 토큰들

가장 흔한 청구상의 놀라움은 내가 명시적으로 입력한 적 없는 토큰에서 옵니다. 세 가지 출처가 두드러집니다.

첫째, 다시 보내는 시스템 지시와 맥락. 대화에서 모델은 턴 사이에 기억이 없습니다 — 그래서 연속성을 유지하려고, 애플리케이션은 앞선 대화와 모든 상시 지시를 매 요청마다 다시 보냅니다. 그 이력의 비용은 매 턴마다 다시 지불됩니다. 긴 대화는 늘어날수록 메시지당 더 비싸집니다. 새 메시지마다 전체 기록을 입력으로 함께 끌고 오기 때문이죠.

둘째, 검색되거나 첨부된 콘텐츠. 모델에 작업할 문서를 주면, 그 모든 토큰이 내가 비용을 내는 입력입니다. 큰 문서를 프롬프트에 욱여넣는 기능은 사용자의 짧은 질문이 시사하는 것보다 호출당 훨씬 더 많은 비용을 조용히 잡아먹을 수 있습니다.

셋째, 모델 자신의 중간 작업. 어떤 모델은 최종 답변에 앞서 내부 추론을 만들어 내며, 그 중간 텍스트는 사용자에게 보이지 않더라도 대개 비용이 청구되는 생성된 출력입니다. 짧게 보이는 답변이 훨씬 큰 분량의 유료 생성 위에 얹혀 있을 수 있습니다.

컨텍스트 윈도가 비용에 중요한 이유

모든 모델에는 한 번에 고려할 수 있는 텍스트의 최대량 — 컨텍스트 윈도 — 이 있습니다. 큰 컨텍스트 윈도를 모든 것을 들이부을 공짜 공간처럼 여기고 싶어지지만, 윈도는 예산이 아니라 수용량입니다. 그 안에 넣는 모든 토큰에 여전히 비용을 냅니다. 큰 윈도를 가장자리까지 채운다는 것은 매 호출마다 큰 입력에 비용을 낸다는 뜻입니다.

윈도는 분명 단단한 천장을 매깁니다. 입력 더하기 출력이 그것을 넘을 수 없죠. 하지만 실용적 규율은 최대치보다 훨씬 적게 쓰는 것입니다. 작업을 해내는 데 보내는 토큰이 적을수록 호출당 비용이 줄고, 흔히 응답도 더 빨라집니다. 큰 윈도는 가끔 있는 큰 작업을 위한 편의이지, 일상적인 작업에서 헤프게 굴어도 된다는 면허가 아닙니다.

비용 추정과 통제

출시 전에 비용을 예측할 수 있습니다. 산수는 간단합니다. 호출당 통상적인 입력 토큰과 출력 토큰을 추정하고, 각각에 해당 단가를 곱한 뒤, 예상 호출 횟수를 곱합니다. 빌드 전에 봉투 뒷면에서 이걸 해 보면, 비싼 설계가 아직 바꾸기 값쌀 때 잡아낼 수 있습니다.

일단 운영에 들어가면, 비용 통제는 몇 가지 습관이 대부분을 해냅니다. 보내는 것을 다듬으세요 — 필요 없는 대화 이력은 버리고, 긴 맥락은 그대로 다시 보내는 대신 요약하며, 중요한 문서만 포함하세요. 작업이 허락하면 출력 길이에 상한을 두세요. 출력이 더 비싼 흐름이니까요. 일상적인 일에는 더 작고 값싼 모델을 꺼내고, 진짜로 필요한 호출에만 비싼 모델을 아껴 두세요. 그리고 추정을 믿기보다 실제 사용량을 측정하세요. 실제 트래픽의 실제 토큰 수만이 청구서를 갚는 유일한 숫자이기 때문입니다.

빠른 직관 예제

지원 어시스턴트를 떠올려 보세요. 사용자가 한 줄짜리 질문을 입력합니다 — 자그마한 입력이죠. 하지만 시스템은 한 페이지짜리 상시 지시, 지난 여러 턴의 대화, 검색된 도움말 글 세 편도 함께 보냅니다. 사용자에게 보이는 단어는 반올림 오차이고, 진짜 입력은 지시, 이력, 글들이며, 매 턴마다 반복됩니다. 그런 다음 어시스턴트가 꼼꼼한 여러 문단짜리 답장을 쓴다면, 그 출력은 모든 입력을 합친 것보다 더 비쌀 수 있습니다. 호출을 이렇게 보는 것 — 비용 대부분이 사용자는 결코 보지 못하는 곳에 있다는 것 — 이 통찰의 전부입니다. 보이는 질문을 최적화하면 한 푼도 아끼지 못합니다. 보이지 않는 맥락과 출력 길이를 다듬는 곳에 돈이 있습니다.

정리

단어나 요청이 아니라 토큰이 내가 비용을 내는 대상이며, 청구서를 끌어올리는 토큰은 대개 내가 보지 못하는 것들입니다. 다시 보낸 대화 이력, 첨부된 문서, 상시 지시, 그리고 모델 자신의 중간 생성이죠. 입력과 출력은 따로 가격이 매겨지고, 출력이 대개 더 비쌉니다. 큰 컨텍스트 윈도는 채우는 데 비용을 내는 수용량이지 공짜 공간이 아닙니다. 빌드 전에 간단한 산수로 추정하고, 보내는 것을 다듬고 생성하는 것에 상한을 두며, 실제 사용량을 측정하세요. 토큰 요금제는 자신이 정확히 무엇을 보내는지 아는 사람에게 보상하고, 모르는 사람에게 벌을 줍니다.