LLM 사용량 파일을 분석하는 방법

모든 LLM 청구서 뒤에는 파일이 있습니다: 제공업체가 건네주는 사용량 내보내기로, 행마다, 모델마다, 날짜마다입니다. 대부분의 사람들은 그것을 열지 않습니다. 원시 내보내기는 합계도 결론도 없는 토큰 수의 벽이기 때문입니다. 이 가이드는 그 파일을 어디서 얻는지, 그 안에 실제로 무엇이 있는지, 명확히 볼 수 있게 되었을 때 찾을 가치가 있는 세 가지 패턴을 보여줍니다 — 이 사이트의 LLM 사용량 분석기를 사용하며, 파일은 브라우저 안에서만 읽히고 다른 어디에서도 읽히지 않습니다.

사용량을 어디서 내보내는지

제공업체가 수치를 보관하는 곳에서 시작하세요. OpenAI는 사용량을 두 곳에서 공개합니다: 제공업체 콘솔의 사용량 페이지는 현재 청구 기간에 대해 날짜별·모델별로 활동을 요약합니다. 사용량 API는 동일한 데이터를 JSON으로 반환합니다 — 시간 버킷으로, 각 버킷은 컨텍스트 토큰, 생성 토큰, 요청 수와 함께 모델별 결과를 담습니다. 그 JSON 형태는 알 가치가 있습니다. 스크린샷 없이 보관하고, 비교하고, 도구에 공급할 수 있는 형태이기 때문입니다. 오늘 시작할 가치가 있는 습관: 한 달에 한 번 API 응답을 가져와 보관하세요. 제공업체는 콘솔에 제한된 기간의 기록만 유지합니다. 당신 자신의 보관본이 당신이 실제로 지출한 것에 대한, 월별 유일한 완전한 기록입니다.

Anthropic은 콘솔과 보고 API를 통해 같은 정신으로 사용량 및 비용 보고를 공개합니다: 날짜별·모델별로 집계되고 표 형식 데이터로 내보낼 수 있습니다. 다른 제공업체는 완성도는 다르지만 종류는 같습니다 — 사용량 또는 청구 페이지에서 CSV 다운로드, 또는 날짜가 있는 행을 반환하는 API 엔드포인트. 일반적인 형태가 모든 분석에 필요한 전부입니다: 날짜, 모델 이름, 입력 토큰, 출력 토큰, 운이 좋으면 캐시 토큰, 요청 수, 비용 열. 제공업체가 여러 내보내기를 제공하면 가장 세분화된 것을 선택하세요 — 날짜별 모델별이 월별 프로젝트별을 이깁니다. 직접 한 집계는 언제든 되돌릴 수 있지만, 제공업체가 한 집계는 되돌릴 수 없기 때문입니다.

파일에 실제로 들어 있는 것

사용량 행은 작고 밀도 높은 주장입니다: 이 날짜에, 이 모델은 이만큼의 요청을 처리했고, 이만큼의 입력 토큰을 읽었으며 — 그중 이만큼이 캐시되었고 — 이만큼의 출력 토큰을 썼습니다. 그런 열이 있는 파일을 읽으면 워크로드의 형태에 대해 거의 모든 것을 재구성할 수 있습니다: 프롬프트가 긴지 짧은지, 답변이 장황한지, 트래픽이 안정적인지 버스트적인지, 어떤 모델이 실제 일을 하는지. 파일이 의도적으로 포함하지 않는 것도 그만큼 중요합니다: 프롬프트 텍스트 없음, 완성 없음, 사용자 콘텐츠 없음. 그것은 수와 이름이며, 그래서 그것이 설명하는 트래픽보다 더 자유롭게 다룰 수 있습니다 — 다만 마지막 섹션이 주장하듯, “더 자유롭게”가 “어디서든”이라는 뜻은 아닙니다.

두 열은 어떤 분석보다 먼저 의심할 가치가 있습니다. 첫 번째는 비용: 일부 내보내기는 청구된 비용을, 일부는 정가 추정치를, 일부는 전혀 아무것도 담지 않으며, 파일은 어느 것인지 거의 표시하지 않습니다. 비용 열은 제공업체의 수치로 취급하되, 합계를 신뢰하기 전에 날짜 범위와 건너뛴 행이나 부분적인 행을 확인하세요. 두 번째는 캐시 토큰 열로, 제공업체는 최소 다섯 가지 다른 이름을 붙이며 때로는 나누어 표시하지 않고 입력 수에 접어 넣습니다. 입력 토큰이 그 모델치고는 믿기 어려울 정도로 싸거나 비싸 보이면 헤더가 가장 먼저 볼 곳입니다 — 그래서 분석기는 헤더에서 감지한 열 매핑을 보여주고, 무엇이든 계산되기 전에 수정할 수 있게 합니다.

찾아야 할 것: 세 가지 패턴

첫 번째, 캐시 토큰 비율. 캐시된 입력을 전체 입력으로 나누어 모델별로 계산하세요. 반복 구조가 있는 워크로드 — 시스템 프롬프트, 문서 접두사, 고정된 도구 스키마 — 는 그 접두사가 호출마다 동일하므로 입력의 큰 부분을 캐시해야 합니다. 그런 워크로드에서 비율이 0에 가깝다면 캐싱이 꺼져 있거나, 호출 사이에 캐시가 만료되거나, 접두사의 무언가가 요청마다 변하고 있다는 뜻입니다 — 타임스탬프, 무작위 id, 재정렬된 필드 — 그리고 조용히 그것을 패배시킵니다. 그 하나의 수치를 고치는 것은 일상적으로 모델을 재협상하는 것보다 더 가치가 있습니다. 모든 주요 제공업체에서 캐시된 입력은 전체 요금의 일부로 청구되기 때문입니다.

두 번째, 모델 구성. 모델을 요청 수가 아니라 비용으로 정렬하세요: 구성은 비싼 등급의 비용 점유율이 그것을 진정으로 필요로 하는 작업의 점유율과 대략 일치할 때 건강합니다. 지켜봐야 할 드리프트는 플래그십 모델의 비용 점유율이 월마다 상승하는데 그 요청 점유율은 평평한 것입니다 — 더 긴 프롬프트, 더 긴 출력, 또는 아무도 설정한 것을 기억하지 못하는 기본값에 의해 큰 모델로 조용히 라우팅되는 새 트래픽. 세 번째, 집중과 급증: 하나의 API 키, 프로젝트 또는 모델이 파일을 지배하는 것은 비용 사실인 만큼 폭발 반경 사실이며, 날짜별 급증 — 특히 주말이나 밤, 아무도 일하지 않던 시간 — 은 재시도 루프, 폭주한 에이전트, 또는 행사되고 있는 유출된 키의 서명입니다. 날짜별 표는 그 급증을 놓칠 수 없게 하기 위해 존재합니다.

비용이 없는 파일의 가격 매기기

많은 내보내기에는 비용 열이 전혀 없으며, 그 경우 분석은 파일 자체의 가격을 매겨야 합니다. 분석기는 투명한 방식으로 합니다: 각 행은 이 사이트의 LLM 가격 표에서 가격이 매겨집니다 — 비용 계산기도 사용하는 검증된 정가로, 제공업체 자체의 공식을 씁니다: 캐시되지 않은 입력은 입력 요금, 캐시된 입력은 존재할 경우 캐시 요금, 출력은 출력 요금. 모델 이름은 엄격히 대조됩니다: 정확히, 제공업체 접두사를 제거한 뒤, 또는 말미의 날짜나 “latest” 접미사를 제거한 뒤. 그 엄격함이 요점입니다. 더 느슨한 퍼지 대조는 결국 파인튜닝을 그 베이스 모델로, 또는 프리뷰를 릴리스로 가격을 매기게 되고, 합계는 얻지 못한 자신감을 얻게 됩니다.

그래서 어떤 것과도 일치하지 않는 모델은 나열되며, 추측되지 않습니다. 그것들의 토큰과 요청은 여전히 셉니다 — 그 볼륨을 보고 빈틈이 중요한지 판단할 수 있습니다 — 하지만 그 비용은 비워 두며, 결과에는 그 돈이 어디서 왔는지 표시됩니다: 파일 자체, 표에서 계산, 혼합, 또는 없음. 계산된 합계를 읽을 때는 그 기준으로 유지하세요: 그것은 당신의 할인, 크레딧, 배치 요금, 계층형 긴 컨텍스트 가격을 모르는 정가 산술이므로 청구서와 센트 단위까지 일치하지 않습니다. 그것이 신뢰성 있게 하는 것은 순위 매기기입니다: 어떤 모델, 어떤 날짜, 어떤 패턴이 청구서를 지배하는지. 비용 작업에서 순위는 대개 결정과 관련된 부분입니다.

프라이버시, 그리고 월간 루틴

사용량 파일에는 프롬프트 텍스트가 없지만, 운영상으로는 여전히 민감합니다: 당신이 실행하는 모든 모델, 날짜별 볼륨, 성장 곡선, 지출을 이름으로 지목합니다 — 시스템이 어떻게 구축되었는지를 보여주는 경쟁적·보안 관련 지문입니다. 그래서 LLM 사용량 분석기는 파일을 브라우저 안에서 로컬로 분석하고 절대 업로드하지 않습니다. 일반적인 규칙은 이 하나의 도구를 훨씬 넘어 적용됩니다: 파일이 인프라를 요약할수록, 파일이 문자 그대로의 의미에서 비밀을 담고 있지 않더라도, 그것을 호스팅된 채팅이나 알 수 없는 변환기에 붙여넣는 것은 나쁜 생각입니다. 집계도 샙니다. 단지 더 조용히 샐 뿐입니다.

실제로 일어날 만큼 작은 루틴으로 마무리하세요. 한 달에 한 번: 파일을 내보내고, 분석하고, 네 가지 수치를 적으세요 — 전체 비용과 그 출처, 최상위 모델의 비용 점유율, 캐시 토큰 비율, 가장 큰 단일 날짜. 지난달의 네 수치와 비교하세요. 그 5분간의 차이는 드리프트, 급증, 패배한 캐시를 아직 저렴할 때 잡아내며, 1년에 걸쳐 어떤 제공업체 콘솔도 당신을 위해 보관해 주지 않을 보관본을 만듭니다. 청구서는 청구서만 읽는 사람을 놀라게 합니다. 사용량을 읽는 사람을 놀라게 하는 경우는 드뭅니다.

자주 묻는 질문

어떤 내보내기를 써야 하나요 — 콘솔 CSV인가요, 사용량 API JSON인가요?

둘 중 어느 것이든, 동일한 활동을 설명합니다. 콘솔 CSV는 가장 빨리 얻을 수 있고 한 번 보는 데 충분합니다. API JSON이 더 좋은 습관입니다: 완전하고, 스크립트 가능하고, 보관 가능하며, 모델별 토큰 필드(컨텍스트, 생성, 있을 경우 캐시, 요청 수)를 안정적인 형태로 담습니다. 둘이 일치하지 않으면 먼저 날짜 범위와 시간대를 확인하세요 — 콘솔 보기는 대개 현지 시간으로 표시되는 반면 API 버킷은 UTC라서, 날짜 경계가 이동하고 합계는 바뀌지 않은 채 인접한 날짜 사이에서 지출이 이동합니다.

캐시 토큰 비율이 0에 가깝습니다. 무엇이 프롬프트 캐싱을 깨뜨리나요?

일반적인 원인은 순서대로: 트래픽이 지나는 경로에서 캐싱이 활성화되지 않았거나 제공되지 않는 것. 호출 간 간격이 캐시 수명을 초과해 모든 항목이 재사용 전에 만료되는 것. 또는 프롬프트 접두사가 호출 간에 실제로 동일하지 않은 것 — 주입된 타임스탬프, 요청별 id, 섞인 도구 목록, 사용자별 첫 메시지는 모두 접두사를 바꾸고 캐시를 빗나가게 합니다. 처음 부분에서 두 원시 요청을 바이트 단위로 비교하세요: 가장 먼저 다른 것이 캐시가 일치를 멈추는 지점입니다. 수정은 변하는 모든 것을 안정적이고 공유되는 접두사 뒤로 옮기는 것입니다.

도구가 내 모델 중 일부의 가격을 추정하지 않는 이유는 무엇인가요?

그 이름에 대해 그 표에 정직한 가격이 존재하지 않기 때문입니다. 파인튜닝은 베이스 모델의 엔진을 상속하지만 그 가격을 반드시 상속하지는 않으며, 프리뷰는 릴리스와 다르게 청구되는 경우가 많고, 타사 배포는 자체 계약을 따릅니다 — 그중 어느 하나라도 추측하면 합계는 틀리면서도 완전해 보일 것입니다. 대신 도구는 그 모델들을 볼륨과 함께 나열하므로, 계약이나 청구서에서 그 부분을 직접 가격 매기고, 각 수치의 출처를 명확히 유지하면서 계산된 합계에 더할 수 있습니다.