rtk, headroom, 그리고 caveman을 통한 LLM 토큰 비용 절감 - 실제 워크로드 기반 절감액 측정

누군가가 토큰 비용을 60-90% 절감했다는 게시물을 올릴 때마다 rtk, headroom, 그리고 caveman이 계속해서 등장합니다. 저는 벤치마크 대신 실제 청구서에서 얼마나 절약되는지 알고 싶었고, 그래서 제 Claude Code 기록을 바탕으로 세 가지 도구를 모두 다시 실행해 보았습니다.

제 코퍼스(Corpus)는 500개의 개인 Claude Code 세션, 6억 1,400만(614M) 토큰, 그리고 기준 지출액 926달러였으며, 매 턴(turn)마다 비용을 재계산했습니다. headroom는 압축기(compressor)가 페이로드(payload)의 순수 함수이므로 직접 실행했습니다. rtk와 caveman은 각자 발표된 요율을 바탕으로 추정하였으며, 가능한 가장 관대한 수치를 적용했습니다.

실제 트래픽에서 절감된 내역은 다음과 같습니다.

headroom: 지출의 2.8% ($25.61)
rtk: 0.5% ($4.94)
caveman: 0.4% ($3.58)
합계: 3.7% ($34.12)

광고된 수치들이 틀린 것은 아닙니다. 각 도구가 설계된 정확한 페이로드에 대해서는 동일한 결과를 얻었습니다. headroom는 grep 및 diff 덤프를 중앙값 기준 54% 절감했고, rtk는 인식된 쉘(shell) 출력을 33-99% 절감했으며, caveman은 산문(prose)을 절반으로 줄였습니다. 모두 실제적이고, 격리된 상태에서는 모두 재현 가능합니다.

그렇다면 왜 실제 청구서는 거의 변하지 않을까요? 세 가지 이유가 중첩되어 있습니다.

첫 번째는 분모입니다. 광고된 퍼센트(%)는 절감액을 하나의 페이로드로 나눕니다. 하지만 귀하의 청구서는 동일한 절감액을 수백 번의 턴에 걸쳐 분산시킵니다.

두 번째는 워크로드(workload)입니다. 고압축 기술은 grep 결과나 JSON 배열과 같이 중복되고 구조화된 덤프에서만 작동합니다. 제 실제 트래픽에서 headroom는 페이로드의 45%에서 활성화되었고 중앙값 기준 25%를 절감했는데, 이는 트래픽의 대부분이 일반 텍스트와 소스 코드였기 때문입니다.

세 번째는 가격 책정(pricing)이며, 이것이 가장 큰 이유입니다. 프롬프트 캐싱(Prompt caching)은 매 턴마다 저렴한 cache_read 요율로 컨텍스트를 다시 보냅니다. 제 청구서는 cache_create가 42%, 출력이 29%를 차지했는데, 이 도구들 중 어느 것도 해당 스트림(stream)을 건드리지 않습니다. 이들은 청구서에서 가장 저렴한 토큰을 압축하는 것입니다.

예상치 못한 커버리지 격차(coverage gap)도 있었습니다. rtk는 제 도구 출력 토큰의 22%에만 도달했습니다. 나머지 78%는 Read, Grep, Glob을 통해 전달되었으며, 이는 rtk의 쉘 훅(shell hook)에 전혀 걸리지 않았습니다.

또한 우리는 보안 위험을 고려해야 하며, 절감액이 잠재적인 미래의 보안 침해를 감수할 가치가 있는지 결정해야 합니다.

각 도구는 사용자의 코드, 프롬프트(prompts), 그리고 출력(output)을 읽을 수 있는 위치에 배치됩니다. 잘못된 headroom 배포는 API 키를 노출시키고, 잘못된 rtk는 임의의 셸 명령(shell commands)을 실행하며, 잘못된 caveman은 모든 메시지마다 node를 실행합니다.
제출자: /u/noninertialframe96
[link] [comments]