개요

LLM 비용은 단가만 보면 오해하기 쉽습니다. 같은 프롬프트라도 모델별 토큰화 방식이 달라 비용이 크게 달라질 수 있기 때문입니다.

대표적으로 Claude와 Gemini가 있습니다. 한국어 프롬프트 기준 Claude가 Gemini 보다 토큰을 더 많이 쓰는 것을 확인했으며 평균 20% 이상의 차이를 확인했습니다.

이러한 토큰 사용량의 차이는 토큰 단가보다 토큰 수가 실제 청구액을 더 크게 좌우할 수 있다는 점 때문에 왜 토큰이 더 많이 발생하는지, 이를 어떻게 하면 줄일 수 있는지 조사하고 정리했습니다.

Claude가 CJK(한국어/일본어/중국어) 토큰이 비효율적인 이유

CJK(한국어/일본어/중국어) 비중이 높아질수록 Claude 쪽 토큰 증가폭이 커졌습니다.

즉 Claude가 항상 비싸다고 하기 보다는 CJK 밀도 높은 워크로드(중국어/일본어/한국어가 많은 문서)에서 구조적으로 불리할 수 있다가 더 정확합니다.

Gemini의 경우 영어 <> 한국어 간 토큰 차이가 5~7% 내외인 반면 Claude의 경우 영어 <> 한국어간 차이가 평균 20%+인 것을 확인했습니다.

• https://brunch.co.kr/@230kimi/44

Write a Python function fibonacci(n) using dynamic programming and include three pytest tests.

• inputTokens = 24

동적 프로그래밍으로 fibonacci(n) 파이썬 함수를 작성하고 pytest 테스트 3개를 포함하세요.

• inputTokens = 55

이는 다시 정리하면 Claude에서 한국어를 비싸게 처리한다는 것을 알 수 있으며 품질의 차이가 없다면 더 저렴한 모델을 선택하여 내부 LLM 사용 비용을 줄일 수 있다는 것을 깨달았습니다.

기술적 원인

물론 영어 <> 한국어 간 입출력 비효율성도 존재합니다. 크게 4가지로 정리할 수 있습니다.

1. UTF-8 바이트 오버헤드

• 영어 ASCII는 1글자 1바이트인 반면 CJK 문자는 보통 3바이트입니다. 바이트 단위 분해 성향이 강한 토크나이저에서는 시작점부터 불리합니다.

2. Lexicon 비율

• 토크나이저의 어휘 크기는 모델과 비례해 제한적입니다. 학습 데이터에서 빈도가 높은 영어 혹은 코드 조각 등으로 어휘를 차지하게 된다면 CJK의 문자 및 어절이 덜 포함되거나 인식되기 위해 더 작은 단위로 분해됩니다. 이러한 구조 변화는 영어와 같은 의미를 포함하더라도 토큰 수가 늘어나게 됩니다.
• 병합 규칙은 학습 데이터 빈도에 좌우됩니다. 영어·코드 중심 코퍼스에서 학습되면 CJK 압축 효율이 낮아지기 쉽습니다.

3. 의미 단위와 토큰 단위 불일치

• 영어는 토큰 하나가 여러 글자/부분단어를 담기 쉬운 반면, CJK는 같은 의미를 표현할 때 더 많은 토큰이 필요해지는 경향이 있습니다.

이러한 특징들은 단순히 모델의 특징이 아닌 구조적인 다국어의 어려움으로 이를 해결하기 위한 방법들은 지금도 연구되고 있습니다.

• https://arxiv.org/abs/2305.15425
• https://tonybaloney.github.io/posts/cjk-chinese-japanese-korean-llm-ai-best-practices.html

비용 최적화

이러한 토큰 비용은 보고서를 많이 작성하는 내부 업무에서 크게 느껴지게 됩니다. 같은 프롬프트에서 토큰이 20~30% 토큰을 압축하게 되며 비용을 절감할 수 있기 때문입니다.

따라서 이를 위해 내부 MCP와 Research 프롬프트 묶음으로 토큰 벤치용 템플릿을 만들었습니다. 한국어 중심으로 구분해 모델을 비교하는 템플릿을 만들어 매번 새로운 모델이 출시되더라도 해당 모델이 실질적인 성능과 비용을 비교할 예정입니다.

결론

이번 비교의 요지는 Claude vs Gemini 단순 승패가 아닌 장기적으로 AI 서비스를 유지하기 위한 여러 방법들을 정리한 계기였으며 앞으로도 LLMOps를 위해 한계비용을 낮추기 위한 여러가지 방법들을 찾아보려고 하고 있습니다.