토큰 비즈니스의 숨겨진 실타래: 비용을 결정하는 것은 처리량이 아닌 KV Cache Hit이다

최근 토큰 비즈니스 (token business)를 공부할수록, 계속해서 간과되고 있는 관점이 하나 있다는 느낌을 받습니다.

지난 1년 동안 사람들이 추론 성능 (inference performance)을 벤치마킹할 때, 주로 세 가지 수치를 주시해 왔습니다. 절대적인 처리량 (throughput), TTFT (Time To First Token), 그리고 TPOT (Time Per Output Token)입니다. 얼마나 많은 요청을 배치 (batch) 처리할 수 있는지, 첫 번째 토큰이 얼마나 빨리 나오는지, 그리고 각 출력 토큰이 얼마나 빨리 생성되는지 말이죠. 이것이 오늘날의 표준적인 논점입니다.

하지만 실제로 서빙 (serving) 단계에 들어가 보면, 토큰 비용을 실제로 결정짓는 것은 처리량이 아니라는 것을 알게 됩니다. 그것은 바로 KV 캐시 히트 (KV cache hits) 여부입니다.

I. 가격표에 새겨진 10배의 격차

최근 여러 모델 API들이 가격을 인하했습니다. 어떤 가격표를 열어보더라도, 얼마 전부터 입력 (input) 열이 두 개로 나뉘어 있는 것을 볼 수 있을 것입니다: 캐시 히트 (cache hit)와 캐시 미스 (cache miss)입니다.

그 격차는 얼마나 클까요?

Anthropic은 캐시 읽기 (cache reads)에 대해 기본 입력 가격의 0.1배를 부과하여, 10배 더 저렴하게 만듭니다. DeepSeek V4 Flash의 경우 캐시 히트는 100만 토큰당 $0.0028이며, 캐시 미스는 100만 토큰당 $0.14로, 50배의 차이가 납니다. Anthropic은 또한 캐시를 쓰기 (write) 위해 1.25배(5분 버전) 또는 2배(1시간 버전)를 부과합니다. 4월 26일, DeepSeek는 모든 모델에 대해 캐시 히트 가격을 추가로 10배 인하했습니다.

머신 레벨 (machine level)에서 이 차이는 연산 (compute)의 문제로 귀결됩니다. 히트 (hit)가 발생하면 프리필 (prefill) 단계를 건너뛰고 머신은 디코드 (decode)만 수행합니다. 미스 (miss)가 발생하면 처음부터 다시 계산해야 하며, 머신의 시간과 연산을 소모하게 됩니다. 이 격차는 몇 퍼센트 수준이 아닙니다. 최대 10배에 달하는 배수 차이입니다.

흥미로운 점은 이것입니다: 일단 캐시 히트와 미스가 별도로 가격이 책정되면, 비용의 일부는 설계를 통해 사용자가 직접 제어할 수 있게 되고, 나머지는 전적으로 벤더 (vendor)에 달려 있게 됩니다. 이렇게 분리되면

가장 명확한 사례는 Claude Code입니다. 사용자가 300K의 컨텍스트 (context)를 쌓아둔 상태에서, 작업 중간에 Opus가 이 단계에는 너무 비싸다고 판단하여 Sonnet으로 전환한다고 가정해 봅시다. 그러면 Claude Code는 다음과 같이 명시적으로 경고를 띄웁니다: 전환 후에는 이전의 모든 캐시 (cache)가 무효화되며, 다음 단계는 콜드 스타트 (cold-start) 및 재계산 (recalculate)을 수행해야 합니다. 이전에는 이런 경고가 없었습니다. 수많은 불만이 제기된 후에야 그들은 이 기능을 추가했습니다.

왜 무효화되는 것일까요? 각 모델의 KV 표현 (KV representation) 방식이 다르기 때문에, 모델 간에 캐시를 재사용할 수 없습니다. Opus의 캐시와 Sonnet의 캐시는 서로 다른 것입니다. 세션 (session)은 변하지 않았고, 캐시 키 (cache key)도 이동하지 않았지만, 재계산 비용 측면에서는 단 한 푼도 절약되지 않습니다.

수치를 계산해 봅시다. 현재 Opus 4.7은 백만 토큰당 $5/$25이며, Sonnet 4.6은 $3/$15입니다. Sonnet은 과거의 5배 차이가 아니라 Opus보다 대략 40% 저렴합니다. 하지만 앞서 입력된 300K의 입력값은 캐시 히트 (cache hit, 가격의 0.1배)에서 콜드 계산 (cold calculation, 가격의 1배)으로 바뀌므로, 해당 입력 비용 하나만으로도 10배가 급증합니다. 모델 자체에서는 40%를 절약할지 모르지만, 이를 정산해 보면 전체 비용은 실제로 5배 이상 높아집니다.

게다가 에이전트 (agent) 워크로드에서 토큰은 거의 항상 입력 중심적 (input-heavy)이고 출력 경량적 (output-light)입니다. 프리필 (Prefill)은 보통 초당 수천 개의 토큰을 처리하지만, 디코드 (Decode)는 수십 개에서 100여 개를 처리합니다. 이는 두 자릿수(two orders of magnitude)의 차이입니다. 돈은 기본적으로 입력 단계에서 소비됩니다. 모델 라우팅 (model routing)은 입력 측면의 절약 메커니즘을 정확히 파괴해 버립니다.

따라서 오늘날 주류 에이전트 설계는 "컨텍스트 안정성 (context stability)"을 중심으로 돌아갑니다. 모델을 가볍게 교체하지 말고, 도구 구조 (tool structures)를 변경하지 마세요. 작업 중간에 CLAUDE.md와 같은 핵심 프롬프트 (core prompts)를 건드리지 마세요. 단 한 번의 움직임만으로도 히트율 (hit rates)은 실제로 90%에서 5%로 떨어질 수 있습니다.

III. Claude Code의 해결책: 서브 에이전트 (Sub-Agents) 생성

그렇다면 작업의 일부가 정말로 더 저렴한 모델에 더 적합하다면 어떻게 해야 할까요?

Claude Code의 해결책은 서브 에이전트 (sub-agents)를 생성하는 것입니다.

메인 세션은 Opus에 머물며 히트율 (hit rate)을 유지합니다. 탐색, 배치 처리 (batch-process), 또는 특정 서브 태스크 (sub-task)를 실행해야 할 때, Task 도구를 호출하여 새로운 에이전트를 생성합니다. 새로운 에이전트는 자신만의 격리된 컨텍스트 (context) 내에서 실행되며, 더 저렴한 모델을 선택할 수 있고, 자신만의 히트율을 유지합니다. 작업이 완료되면 요약본만이 메인 세션으로 전달됩니다. 메인 세션의 캐시 (cache)에는 아무런 영향을 주지 않습니다.

이 메커니즘의 전제 조건은 서브 태스크의 컨텍스트 요구 사항이 메인 태스크와 충분히 달라야 한다는 점입니다. 만약 서브 태스크가 메인 세션 콘텐츠의 대부분을 그대로 입력받게 된다면, 이는 서브 에이전트 내부에서 또 다른 콜드 스타트 (cold start)를 유발하며, 프리필 (prefill) 과정이 절약한 비용을 모두 잡아먹게 됩니다. 이를 위해서는 상당히 세밀한 판단이 필요합니다.

IV. 서버 측 KV 캐시 엔지니어링 (Server-Side KV Cache Engineering)

서버 측의 격차는 얼마나 클까요? 엄청납니다.

가장 조잡한 구현 방식들은 캐시를 전혀 고려하여 설계하지 않습니다. 사용자 간의 재사용도 없습니다. 라우팅 (routing)은 엉망이 됩니다. 캐시를 보유한 머신에 도달해야 할 요청이 엉뚱한 곳으로 떨어집니다. VRAM이 모든 캐시 용량을 뒷받침합니다. 그런 시스템에서는 사용자 측에서 아무리 주의를 기울여도 구제받을 수 없습니다.

성숙한 사례로는 Moonshot AI, 칭화 대학교 (Tsinghua University), 그리고 Qijing Technology가 개발한 KV 캐시 중심의 분리형 아키텍처 (disaggregated architecture)인 Mooncake 프레임워크가 있습니다. 프리필 (prefill) 클러스터와 디코드 (decode) 클러스터가 분리되어 있으며, GPU 노드에서 활용도가 낮은 CPU, DRAM, SSD 리소스를 분산 KV 캐시 풀 (distributed KV cache pool)로 재용도화합니다. KV 캐시 스케줄러 (KV cache scheduler)가 큐잉 (queuing)과 라우팅을 처리합니다. 논문에 따르면 시뮬레이션상 525%의 처리량 (throughput) 이득을 기록했으며, 실제 부하 상황에서는 처리되는 요청 수가 75%에서 115%까지 증가했습니다.

그 반례가 바로 Openclaw입니다. 이 오픈 소스 에이전트(agent)는 많은 비판을 받았는데, 주로 이 계층(layer)에서 문제를 일으키기 때문입니다. 이들의 플러그인 아키텍처(plugin architecture)는 기본적으로 promptCacheKey를 설정하지 않습니다. 이를 제3자 프록시(third-party proxy)를 통해 전달하면 노드 어피니티(node affinity)를 잃게 되어, 캐시 히트율(cache hit rate)이 거의 0%에 수렴하게 됩니다. 전체 토큰 볼륨(token volume)이 실제로 그렇게 높은 것은 아니지만, 모든 입력이 캐시 미스(cache-miss) 요율로 책정되기 때문에 청구 금액이 터무니없이 높게 나옵니다. 약 한 달 전 제가 그 트레이스(trace)를 살펴보았을 때, 한 요청에 60K 이상의 입력 토큰이 있었고 히트율은 0%였으며, 건당 0.12달러가 청구되었습니다. 이것이 바로 서버 측 캐시(server-side cache)에 타겟팅된 설계가 없을 때 발생하는 현상입니다.

V. 모델 계층 또한 이러한 방향으로 밀어붙일 수 있다

한 계층 더 깊이 들어가 봅시다. 모델 자체가 KV 캐시(KV cache)를 위한 거대한 공간을 확보해 줄 수 있습니다.

DeepSeek가 이 분야에서 가장 체계적이었습니다. MLA (Multi-head Latent Attention)는 KV를 잠재 벡터(latent vector)로 투영했다가 다시 되돌림으로써, KV 캐시 볼륨을 90% 이상 압축합니다. V3는 이 메커니즘을 유지했습니다. 이후 그들은 Native Sparse Attention을 추가했는데, 이는 긴 컨텍스트(long contexts)에서 KV 캐시의 증가를 거의 평탄하게 만듭니다. 오직 이 단계에 이르러서야 추론 시스템(inference system)이 백만 단위의 컨텍스트 길이에서 캐시 풀(cache pool)을 구축할 수 있습니다.

하지만 모델이 바뀌면 캐시 히트(cache hit) 판정 로직도 함께 바뀝니다. 이전에는 "접두사 중첩(prefix overlap)"으로 인식되었던 일부 입력들이 희소 어텐션(sparse attention) 하에서는 다르게 동작하므로, 히트 여부를 재조정해야 합니다. 추론 시스템 또한 수정되어야 합니다. 이것이 제가 추론 엔지니어(inference engineers)들이 더 이상 처리량(throughput)만 쳐다보고 있어서는 안 된다고 말하는 이유입니다. 그들은 모델 아키텍처(model architecture)를 중심으로 캐시를 재설계해야 합니다.

VI. 이를 측정하는 것은 어렵다

전체 체인에서 가장 좌절스러운 부분은 서버 측만 평가하는 것도 무용지물이며, 사용자 측만 평가하는 것 또한 무용지물이라는 점입니다.

서버 측 캐시가 아무리 강력하더라도, 사용자 측이 Openclaw처럼 설계되어 있다면 히트율은 여전히 올라가지 않습니다. 반대로 사용자 측이 아무리 주의를 기울이더라도, 혼란스러운 라우팅(routing), 불충분한 용량, 그리고 사용자 간 재사용(cross-user reuse) 기능이 없는 조잡한 서버를 만난다면 비용은 여전히 새어나가게 됩니다.

따라서 토큰과 관련하여 "어떤 API가 더 저렴한가"는 단일 차원만으로는 비교될 수 없습니다. 동일한 하드웨어와 동일한 목표를 가지고 있더라도, 양측 간의 긴밀한 협업이 이루어지는 경우와 각자 제각각 행동하는 경우의 전체 비용은 5배에서 10배까지 차이 날 수 있습니다.

맺음말

토큰 가격표에서 캐시 히트/미스(cache hit/miss) 비율은 이 모든 논의에서 가장 중요한 실타래입니다. 이는 사용자에게 명확한 동기를 부여합니다. 즉, 높은 히트율(hit rate)이 비용을 절감해 준다는 것입니다. 동시에 이는 제공업체에게 압박으로 작용합니다. 만약 당신의 캐시 시스템이 충분히 강력하지 않다면, 비즈니스를 확보할 수 없을 것입니다.

저는 벤더들이 캐시 히트 메커니즘 자체를 공개하기를 바랍니다. 그렇지 않으면 사용자들은 그것이 존재한다는 사실만 알 뿐, 어떻게 최적화해야 하는지는 알지 못하게 됩니다. 모델, 서버 측 캐시(server-side cache), 그리고 사용자 측 사용량(user-side usage)을 엔드 투 엔드(end-to-end)로 연결할 수 있는 벤더는 여전히 많지 않습니다.

엣지(edge) 측면은 여전히 가공되지 않은 성능(raw performance)으로 경쟁하고 있습니다. 하지만 앱 밀도가 높아지고 에이전트(agent)가 본격적으로 실행되기 시작하면, KV 캐시(KV cache)는 그곳에서도 핵심적인 이슈가 될 것입니다. 클라우드에서 엣지까지, 이를 피할 방법은 없습니다.

참고 문헌

참고 문헌

• Prompt caching — Claude API Docs
• Anthropic Pricing — Claude API Docs
• How Claude Code uses prompt caching
• Claude Code Sub-Agents Docs
• Context Caching — DeepSeek API Docs
• DeepSeek API Pricing
• Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving (arXiv:2407.00079)
• Mooncake on GitHub (kvcache-ai/Mooncake)
• DeepSeek-V2 paper — introduces MLA
• Fixing OpenCode prompt cache misses with third-party proxy
• Plugin architecture prevents prompt caching — oh-my-opencode issue

원문 링크: [https://guanjiawei.ai/en/blog/token-business-kv-cache]