LLM으로 개발하는 대부분의 사람들은 월간 청구서가 나올 때까지 특정 호출이 얼마의 비용이 드는지 모릅니다. 그리고 그때쯤이면 상세 내역 없이 무서운 단일 숫자로만 나타납니다. 해결책은 간단합니다. 모든 응답에는 이미 사용한 토큰 수가 나와 있습니다. 클라이언트를 한 번 감싸고, 그 사용량을 표와 비교하여 가격을 매긴 다음, 호출당 한 줄씩 기록하면 됩니다. 이제 개발하는 동안 청구서가 쌓이는 것을 보고, 어떤 경로가 비용을 많이 쓰고 있는지 찾을 수 있습니다.

사용량은 이미 응답에 포함되어 있다

시작하기 위해 프록시나 대시보드가 필요하지 않습니다. 응답 객체에는 토큰 카운트가 담긴 usage 블록이 있으며, Claude API의 경우 input_tokens, output_tokens, 그리고 프롬프트 캐시에 접근하거나 작성한 내용에 대한 별도의 cache_read_input_tokens와 cache_creation_input_tokens가 있습니다. 추가해야 할 유일한 것은 가격표와 곱셈입니다.

import json, time

# 100만 토큰당 $ — 제공업체의 현재 가격을 사용하세요.
...

이것이 전부입니다. 원본 create 대신 `logged_call(client,

캐시된 토큰은 별도로 카운트하세요. 모든 입력 토큰을 전체 요율로 가격 책정하면 프롬프트 캐싱을 사용하는 어떤 앱에서도 비용을 과대평가하게 됩니다. 왜냐하면 캐시 읽기는 가격의 약 10분의 1 수준이기 때문입니다. 위에서 제시된 Wrapper는 cache_read_input_tokens를 분리하여 낮은 가격으로 책정하는데, 이것이 유용한 수치와 오해를 불러일으키는 수치의 차이를 만듭니다.

입력(Input)보다는 출력(Output)을 확인하세요. 대부분의 모델에서 출력 토큰은 입력보다 몇 배 더 비싸기 때문에, 긴 답변을 반환하는 호출이 긴 프롬프트를 읽는 호출보다 비용이 많이 드는 경우가 일반적입니다. 절약을 찾으려면 큰 프롬프트가 아니라 장황한 응답(verbose responses)부터 확인해야 합니다.

이것은 첫날 오후에 그 가치를 증명할 만한 도구입니다. 청구서가 더 이상 놀라움이 아니게 되고, 비싼 경로가 미스터리가 아니게 되며, API가 이미 제공하고 있던 사용량 수치만으로도 당신은 이 두 가지를 모두 진실하게 만들었습니다.

만약 다른 방식으로 자체 지출을 추적한다면, 저는 그것을 보고 싶습니다. 왜냐하면 실제로 이것을 측정하는 사람들은 우리 대부분이 추측하는 것보다 무언가를 발견한 경향이 있기 때문입니다.