[Paper] TableCache: 저지연 Text-to-SQL을 위한 Primary Foreign Key 기반 KV Cache 사전 계산

Source: arXiv - 2601.08743v1

개요

Text‑to‑SQL 시스템은 사용자가 자연어 질문을 하고 SQL 쿼리를 반환받을 수 있게 합니다. 최신 접근 방식은 전체 데이터베이스 스키마를 프롬프트에 포함해야 하는 대형 언어 모델(LLM)에 의존하는데, 이로 인해 프롬프트가 길어지고 추론의 “prefill” 단계가 느려집니다. TableCache는 개별 테이블에 대한 키‑값(KV) 캐시를 사전 계산하고 재사용하는 방법을 보여주어, 동일한 테이블을 참조하는 반복 쿼리들이 작업을 공유하고 사용자에게 더 빠르게 응답할 수 있게 합니다.

핵심 기여

• 각 데이터베이스 테이블에 대한 오프라인 KV‑캐시 사전 계산, 기본키‑외래키 관계 유지.
• 추론 시 올바른 테이블 캐시 조합을 O(1)로 조회할 수 있는 Table Trie 자료구조.
• 히트율을 높이기 위해 가장 캐시 친화적인 쿼리 순서를 선택하는 캐시 관리 및 쿼리 재정렬.
• 모델 추론과 캐시 가져오기를 겹쳐 GPU 유휴 시간을 줄이는 병렬 로딩 파이프라인.
• SQL 정확도는 < 1 % 감소하면서 **Time‑to‑First‑Token (TTFT)**을 최대 3.62× 감소시킨 실증적 증명.

방법론

1. Table Representation Extraction – 각 테이블마다 LLM은 짧은 “테이블 설명”(열 이름, 유형, 기본/외래 키)을 한 번 처리하고, 그 결과 KV 캐시(프롬프트마다 일반적으로 재계산되는 은닉 상태)를 저장합니다.

2. Preserving Relationships – 테이블이 외래 키를 통해 다른 테이블을 참조할 때, 자식 테이블의 캐시는 부모 캐시 이후에 구축되어 모델이 전체 프롬프트 시와 동일한 순서로 관계적 컨텍스트를 보게 합니다.

3. Table Trie Index – 가능한 모든 테이블‑순서 접두사가 트라이에 삽입됩니다. 런타임에 시스템은 사용자 쿼리에서 요구되는 테이블에 따라 트라이를 탐색하여 미리 계산된 KV 슬라이스를 즉시 가져옵니다.

4. Cache Management

   • Reranking: 사용자 쿼리가 주어지면 엔진은 몇 가지 테이블 순서(예: 알파벳 순, 스키마‑종속 순)를 시도하고 캐시 재사용을 최대화하는 순서를 선택합니다.
   • Loading Pipeline: 모델이 첫 토큰을 디코딩하는 동안 백그라운드 스레드가 GPU 메모리 또는 호스트 RAM에서 필요한 KV 블록을 스트리밍해오며, I/O와 연산을 겹칩니다.

5. Integration with Existing Engines – TableCache는 일반적인 “prefill” 단계를 조회‑복사 작업으로 교체함으로써 SGLang/vLLM에 삽입됩니다. 나머지 생성 파이프라인은 그대로 유지됩니다.

결과 및 발견

• 속도 향상은 동일한 소수의 테이블이 많은 쿼리에서 가장 두드러집니다 (예: 대시보드, 보고 도구).
• 정확도 손실은 미미합니다. 캐시된 KV 상태는 전체 프롬프트에서 생성되는 것과 동일하기 때문이며, 작은 감소는 테이블 순서가 가끔 일치하지 않는 데서 비롯됩니다.
• 메모리 오버헤드는 적당합니다: 일반적인 기업 스키마의 200개 테이블에 대한 KV 캐시를 저장하면 40 GB GPU에서 약 2 GB를 차지합니다.

실용적인 시사점

• 더 빠른 대화형 분석 – 개발자는 LLM‑기반 쿼리 어시스턴트를 BI 도구에 삽입하고 응답 시간을 1초 이하로 유지하여 사용자 경험을 향상시킬 수 있습니다.
• 비용 절감 – 프리필은 추론에서 가장 GPU‑집약적인 단계이며, KV 캐시를 재사용하면 연산 사이클을 줄여 클라우드 GPU 비용을 낮출 수 있습니다.
• 확장 가능한 다중 테넌트 서비스 – 단일 LLM 인스턴스가 스키마가 겹치는 다수의 고객(예: SaaS 플랫폼)을 테이블 캐시를 테넌트 간에 공유함으로써 지원할 수 있습니다.
• 간소화된 프롬프트 엔지니어링 – 스키마가 더 이상 프롬프트의 일부가 아니므로, 개발자는 프롬프트를 짧게 유지하고 자연어 의도에 집중할 수 있습니다.
• 호환성 – TableCache는 KV 캐시를 제공하는 모든 트랜스포머‑기반 디코더(예: LLaMA, Mistral)에 대해 즉시 적용 가능한 레이어로 작동하여 기존 파이프라인에 쉽게 도입할 수 있습니다.

제한 사항 및 향후 작업

• 스키마 변동 – 테이블을 추가, 삭제, 또는 수정하면 영향을 받는 캐시를 다시 계산해야 하며, 현재 시스템은 비교적 정적인 스키마를 전제로 합니다.
• 캐시 크기와 GPU 메모리 – 수천 개의 테이블을 포함하는 매우 큰 카탈로그는 GPU 메모리를 초과할 수 있어, 보다 스마트한 캐시 삭제 정책이나 계층형 저장소(CPU‑RAM → GPU)가 필요합니다.
• 쿼리 다양성 – 많이 사용되지 않는 테이블을 많이 포함하는 즉석(ad‑hoc) 쿼리의 경우 캐시 적중률이 낮아져 이점이 감소합니다.
• 향후 방향 – 저자들이 제시한 바에 따르면, 진화하는 스키마에 대한 동적 캐시 업데이트, 다중 데이터베이스 환경을 위한 계층형 캐싱, 그리고 다른 LLM‑기반 코드 생성 작업(예: API 호출 합성)으로 접근 방식을 확장하는 것이 포함됩니다.

저자

• Jinbo Su
• Yuxuan Hu
• Cuiping Li
• Hong Chen
• Jia Li
• Lintao Ma
• Jing Zhang

논문 정보

• arXiv ID: 2601.08743v1
• 분류: cs.CL, cs.AI
• 출판일: 2026년 1월 13일
• PDF: PDF 다운로드