1만 개의 실제 프롬프트를 토큰화해 보니: '문자 4개 = 토큰 1개' 규칙은 10개 중 4개에서 20% 이상 오차가 발생합니다

3개월 동안 저는 모든 LLM 기능을 하나의 숫자로 가격을 매겼습니다. 바로 문자 4개 ≈ 토큰 1개입니다.

이 공식은 어디에나 존재합니다. 블로그 게시물, 가격 계산기, 그리고 누군가 '대략 비용이 얼마나 들까요?'라고 물어볼 때 머릿속에서도 존재하죠. 이 규칙은 보수적이기 때문에 안전하다고 느껴집니다. 토큰 수를 올림 하기 때문에 추정치가 실제 청구액보다 높게 나오거든요.

지난주 저는 이 공식에 대한 신뢰를 멈추고 직접 측정해봤습니다. 1만 개의 실제 샘플, 실제 토크나이저, 그리고 합성된 텍스트는 전혀 사용하지 않았습니다.

결론적으로, 이 규칙은 프롬프트 단위로 보면 잘못되었습니다. 하지만 월별 총합으로 보면 괜찮을 수 있습니다. 어느 쪽을 적용할지 아는 것이 핵심입니다.

측정 방법

저는 합성 텍스트를 원하지 않았는데, 왜냐하면 합성 텍스트는 벤치마크가 거짓말하기 좋은 곳이기 때문입니다. 코퍼스는 ai, webdev, python, programming, javascript, opensource 등 다양한 주제의 dev.to 공개 API에서 가져온 521개의 실제 게시물로 구성되었습니다.

각 게시물은 프론트 매터(front matter)를 제거한 후 다음 세 가지 유형으로 분할되었습니다:

• prose: 코드 블록을 제외한 단락
• code: 코드 블록의 내용
• structured: JSON 형태 또는 로그 형태의 블록

이를 통해 1만 개의 샘플을 추출할 수 있는 풀(pool)이 만들어졌습니다: prose 7,055개, code 2,669개, structured 275개. 모든 샘플은 tiktoken을 사용하여 cl100k_base로 한 번에 하나씩 인코딩되었고, 실제 토큰 수와 len(text) / 4의 값을 비교했습니다.

숫자를 보기 전에 두 가지 솔직한 주의사항이 있습니다:

1. 이것은 영어 기술 글쓰기입니다. 전체 코퍼스에서 CJK 샘플을 정확히 하나만 얻었으므로, 중국어, 일본어, 한국어 또는 이모지 위주의 텍스트에 대해서는 어떠한 주장도 할 수 없습니다. 만약 트래픽이 다국어라면, 여기서 나온 모든 숫자는 규칙이 얼마나 틀렸는지에 대한 하한선으로 간주해야 합니다.
2. 샘플 구성이 prose가 많은 편입니다. 왜냐하면 dev.to 게시물이 대부분 단락(prose) 형태이기 때문입니다. 따라서

예상치 못했던 부분: 월별 청구액은 기본적으로 정확했다

다음은 10,000개 샘플 전체에 대한 집계 결과입니다:

• 2,715,542 문자(characters)
• 646,092 실제 토큰(real tokens)
• → 토큰당 4.203 문자

전체 데이터를 대상으로 chars / 4를 실행하면 678,885개의 토큰이 나오는데, 이는 실제 값인 646,092개와 비교했을 때 **+5.08%**입니다.

이 두 섹션을 함께 읽어보세요. 서로 모순되는 것처럼 보이지만 그렇지 않습니다:

• 프롬프트당: 샘플의 40%는 20% 이상 오차가 있습니다.
• 집계 기준: 배치(batch) 전체의 오차는 5%입니다.

오류들이 상쇄됩니다. 짧은 샘플과 긴 샘플, 산문과 코드가 모두 평균을 다른 방향에서 4.2로 끌어당깁니다. 따라서 이 규칙은 사람들이 말하는 것처럼 "잘못된" 방식이 아닙니다. 이는 호출(call) 단위로는 사용하기 어렵지만, 월별(month)로는 허용 가능한 수준입니다. 만약 기능을 예산 책정한다면, chars / 4는 약 5% 높은 수치를 제공할 것이며, 이는 괜찮습니다. 하지만 특정 프롬프트가 128k 창에 들어맞는지 결정하는 경우라면, 세 번 중 한 번은 틀린 수치를 얻게 될 것입니다.

Chars per token by sample length and content type

길이에 따라 그룹화하여 분석했고, 제가 가장 중요하게 생각하는 발견은 다음과 같습니다:

이것은 직관에 반대되는 결과입니다. 작은 문자열을 추정하기 쉬울 것이라고 생각할 수 있습니다. 하지만 그렇지 않습니다. 단 하나의 희귀한 단어, 특이한 식별자 또는 이모지 하나가 수십 개의 문자를 세 토큰으로 압축할 수 있으며, 이를 평균화하여 상쇄시킬 방법은 없습니다.

콘텐츠 유형에 따라 상수값이 달라진다

이는 다음과 같은 의미입니다. 만약 귀하의 애플리케이션이 JSON을 출력하고 문자 수를 네로 나누어 하드 토큰 제한을 설정한다면, 대략 5분의 1에 해당하는 경우 이 제한을 너무 낮게 설정하는 것입니다. 이는 비용을 지불할 수 있었던 응답(response)마저 거부하게 만듭니다. 이것은 잘림 버그(truncation bug)의 거울상과 같으며, 아무도 언급하지 않는 부분입니다.

그렇다면 어떤 숫자를 사용해야 할까요?

저는 동일한 10,000개 샘플에 대해 다양한 상수값을 테스트해 보았습니다:

저의 규칙은 다음과 같습니다:

1. 4.5로 예산을 책정하고, 실제 토크나이저를 사용해 청구하세요. 스프레드시트에는 4.5를 사용하되, 비용이 발생하거나 한도에 도달하기 전에 반드시 실제 encode() 함수를 사용해야 합니다.
2. 구조화된 출력(structured output)의 경우 '문자 수 / 4'로 절대적인 상한선을 설정하지 마세요. 이 규칙은 안전하기보다는 저렴할 때 실패하는 유일한 방향입니다.
3. 200자 미만인 내용은 추정하지 마세요. 한 번 측정하고 그 숫자를 캐시하세요. 이 샘플들이 규칙이 가장 잘못 적용되는 경우이며, 또한 수백만 번 재사용하는 경우이기도 하므로, 단 한 번의 측정이 즉시 비용을 상쇄합니다.

실제 계산해 보기

토크나이저가 텍스트를 실제로 어디서 분할하는지 보고 싶다면 — 'résumé'와 'resume'가 같은 가격이 아닌 이유에 대한 직관을 얻는 유일한 방법입니다 — 단어별 분할 경계를 보여주는 작은 카운터를 만들었습니다: LLM 토큰 카운터. 브라우저에서 실행되며 업로드 과정이 필요 없습니다.

만약 직접 Python이나 Node로 실행하고 싶다면, 방법 설명은 여기를 참고하세요: GPT 토큰 계산 방법.

그리고 만약 실제로 신경 쓰는 단위가 '문자'인 경우라면: 단어 및 문자 카운터.

한 가지 질문이 있습니다

저는 영어 기술 문체에 대해서는 이야기할 수 있지만, 여러분의 내용에 대해서는 할 수 없습니다.

만약 여러분이 직접 트래픽(traffic)을 측정했다면 — 특히 비영어권 챗 로그나 에이전트 추적 기록이라면 — 어떤 상수를 얻었나요? dev.to 외부에서도 4.2가 유효한지, 아니면 이 모든 것이 제가 생각하는 것보다 훨씬 더 코퍼스 의존적인지 알고 싶습니다.

원시 데이터(10,000행: kind, chars, tokens, ratio, error)는 해당 스크립트와 함께 레포에 있습니다. 직접 여러분의 텍스트로 다시 실행해 보세요. 5분이면 충분하며, 제 상수를 믿는 것보다 훨씬 정확합니다.