BTB, LLM 추론 병목을 캐시 예측으로 밀어내다

버스트는 평균 요청이 아니다

JW Labs의 Biting the Bullet은 LLM 서빙 비용 논의를 모델 가격표에서 GPU 메모리 운영으로 옮긴다. 이 글의 핵심은 단순하다. 데이터 라벨링, 문서 일괄 추출, 서브에이전트 팬아웃처럼 같은 긴 prefix를 가진 요청이 몇 초 안에 몰리면 일반 라우터는 두 가지 중 하나를 택한다. 캐시가 있는 노드에 몰아 보내서 큐를 만들거나, 부하를 나누느라 차가운 노드에서 prefill을 반복한다.

BTB는 이 상황을 버스트로 감지하고, 이미 만들어진 prefix KV 캐시를 RDMA로 다른 GPU HBM에 미리 복제한다. 공개 글은 Bursted-ART 데이터셋과 Infer-Sim 실험에서 SGLang 기본 cache-aware 라우터 대비 평균 TTFT를 1060%, 좋은 조건의 p95 TTFT를 최대 8082% 줄였다고 설명한다. GPT-5.6 가격 인하, 에이전트 원가 전쟁의 신호가 토큰 단가를 봤다면, 이 연구는 같은 토큰을 기다리는 시간을 본다.

KV 캐시는 사실상 운영 자산이다

LLM 생성에서 KV 캐시는 이전 토큰의 attention 상태를 저장해 재계산을 줄인다. JW Labs는 Llama 3.3 70B 기준으로 1토큰당 약 320 KiB의 KV를 가정했고, 1,000토큰 prefix는 약 320 MiB가 된다고 설명한다. 이 정도 크기면 단순한 캐시가 아니라 HBM, 호스트 RAM, RDMA, NVMe 사이를 움직이는 운영 자산이다.

NVIDIA의 speculative decoding 설명은 디코딩이 순차 의존성 때문에 GPU를 놀리는 구조라고 짚는다. AWS Trainium과 vLLM 사례도 KV 메모리 왕복이 비용과 지연의 큰 축이라고 설명한다. BTB의 차별점은 토큰을 더 빨리 맞히는 speculation이 아니라, 반복될 가능성이 큰 prefix를 미리 가까운 곳으로 옮기는 speculation이다.

라우터보다 계측이 먼저다

BTB가 흥미로운 이유는 알고리즘보다 데이터 가정이다. 연구진은 공개 trace가 실제 기업의 배치 추론, PDF 파싱, 서브에이전트 팬아웃을 충분히 담지 못한다고 본다. 그래서 Bursted-ART 데이터셋과 bite-the-bullet 코드를 함께 공개했다. 이는 좋은 라우팅 정책이 평균 QPS가 아니라 prefix 반복률, 버스트 폭, 감지 지연, RDMA 대역폭에 달려 있다는 주장이다.

한국 기업이 에이전트를 운영할 때도 비슷하다. 사내 문서 요약, 입찰서 비교, 고객상담 로그 분석은 사용자 수보다 작업 단위가 더 중요하다. 한 사람이 버튼을 누르면 수십 개 에이전트가 같은 지침과 같은 문서 조각을 들고 분기할 수 있다. Cursor 에이전트 스웜, 비용 단위가 바뀐다가 말한 비용 단위 변화가 바로 이런 곳에서 나온다.

한국 팀의 체크리스트

당장 BTB를 그대로 배포할 필요는 없다. 먼저 production trace에서 같은 prefix가 몇 초 안에 몇 번 반복되는지, TTFT가 prefill인지 queue인지, cache hit가 실제 사용자 지연을 줄이는지 봐야 한다. Infer-Sim처럼 라우팅과 캐시 정책을 재생하는 시뮬레이터가 중요한 이유도 여기에 있다.

또 하나의 함정은 모델 라우팅과 캐시 라우팅을 섞어 생각하는 것이다. 모델을 바꾸면 cache stickiness가 깨지고, 같은 prefix라도 provider와 tokenizer 차이로 재사용이 어려워질 수 있다. Codex 272K 축소, 긴 컨텍스트의 가격표에서 본 긴 컨텍스트 비용 문제는 결국 캐시와 스케줄러 설계로 돌아온다.

자주 묻는 질문

Q1: BTB는 speculative decoding인가요?

A: 일반적인 speculative decoding은 다음 토큰을 미리 제안하고 검증한다. BTB는 같은 prefix 요청이 몰릴 것을 감지해 KV 캐시를 미리 복제한다는 점에서 더 인프라 쪽 speculation에 가깝다.

Q2: RDMA가 없으면 의미가 없나요?

A: 효과는 줄 수 있다. 하지만 BTB의 강점은 원격 GPU 메모리에서 빠르게 캐시를 옮기는 데 있으므로 네트워크와 메모리 계층 성능이 중요하다.

Q3: 모든 LLM 서비스에 필요한가요?

A: 아니다. 같은 긴 prefix가 반복되는 배치성 요청, 에이전트 팬아웃, 문서 처리 서비스에서 먼저 검토할 만하다.

Q4: 가장 먼저 계측할 지표는 무엇인가요?

A: prefix 재사용률, TTFT 분해, p95 큐 대기, cache hit 위치, burst fanout을 함께 봐야 한다.

Q5: 비용 절감과 지연 감소 중 무엇에 가깝나요?

A: 직접 목표는 TTFT와 tail latency 감소다. 다만 prefill 재계산이 줄면 GPU 효율과 단가에도 영향을 준다.