Billing LLM usage per token: the pitfalls nobody warns you about

개요

대규모 언어 모델(LLM)의 토큰 기반 사용량 과금 방식은 예측하기 어려운 복잡성을 내포하며, 프로덕션 환경에서 이를 정확히 구현하는 데는 여러 난관이 존재한다.

주요 내용

* 단일 요청은 단일 가격이 아니다: 일반적인 LLM 요청은 텍스트 입력, 캐시 입력, 캐시 쓰기, 출력, 추론 토큰, 도구 사용량(API 호출, 이미지 생성 등)과 같이 최대 6가지의 가격 책정 요소를 생성하며, 각 요소별로 별도의 요율을 적용해야 한다.
* 스트리밍 사용량 집계의 어려움: 스트리밍 응답의 마지막 부분에서만 사용량을 읽으면 과소 집계될 수 있다. OpenAI는 stream_options 설정 시 마지막 청크에 사용량을 포함시키며, Anthropic은 message_start에서 입력 및 캐시 토큰을, message_delta에서 나머지 토큰을 보고한다. 따라서 스트리밍 과정에서 발생하는 모든 사용량 페이로드를 누적하고, 캐시된 입력과 캐시되지 않은 입력을 분리하여 최종적으로 합산하여 가격을 책정해야 한다.
* 클라이언트 중단 시 발생하는 비용 손실: 사용자가 '중지'를 누르거나 탭을 닫아 프록시가 상위 응답 읽기를 중단해도 LLM 제공업체는 여전히 비용을 청구하지만, 최종 사용량 프레임은 수신하지 못해 0으로 기록될 수 있다. 이를 방지하기 위해 클라이언트 연결이 끊긴 후에도 제공업체 스트림을 계속 draining하여 사용량을 캡처해야 한다.
* 요청 전 잔액 확인 및 요청 후 정산: 후불 방식과 스트리밍 사용량 집계를 결합하면 예상치 못한 비용이 발생할 수 있다. 따라서 요청 전에 예상되는 최대 비용(프롬프트 토큰 + max_tokens * 출력 요율)을 추정하고, 잔액이 이를 충당할 수 없는 경우 요청을 거부한 후, 실제 사용량을 기준으로 정산하는 방식이 필요하다. max_tokens를 전역적으로 제한하거나 에이전트 재귀 제한을 비용 제어 수단으로 활용하는 것이 중요하다.
* 통화 처리의 복잡성: 여러 통화로 고객이 결제하는 경우, 부여 시점의 환율을 저장하고 USD를 기준으로 표시 비용을 산출해야 한다. 환율 계산 오류로 인해 표시 비용이 잘못 계산될 수 있으므로, 모든 배치에 대해 granted - consumed == balance를 검증하는 정산 작업을 수행해야 한다.

시사점

LLM 사용량의 복잡한 과금 메커니즘을 정확히 파악하고 구현하는 것은 프로덕션 환경에서 비용 관리의 핵심이며, 명확한 가이드라인 없이 진행할 경우 예상치 못한 재정적 손실을 초래할 수 있다.