[Paper] TableCache：主外键引导的 KV 缓存预计算，实现低延迟 Text-to-SQL

Source: arXiv - 2601.08743v1

概述

文本到SQL系统让用户可以用自然语言提问，并返回SQL查询。现代方法依赖大型语言模型（LLM），它们需要在提示中包含完整的数据库模式，这会导致提示变长，并减慢推理的“预填充”阶段。TableCache 展示了如何为单个表预先计算并复用键值（KV）缓存，从而使涉及相同表的重复查询能够共享工作并更快地响应用户。

关键贡献

• 离线 KV‑缓存预计算 对每个数据库表进行，保留主键‑外键关系。
• 表 Trie 数据结构，使在推理期间能够 O(1) 查找正确的表缓存组合。
• 缓存管理与查询重新排序，选择最友好的查询顺序以提升命中率。
• 并行加载流水线，将模型推理与缓存获取重叠，减少 GPU 空闲时间。
• 实证展示在 SQL 准确率下降 < 1 % 的情况下，TTFT（首次令牌时间）降低最高达 3.62 倍。

方法论

1. 表表示提取 – 对于每个表，LLM 只处理一次简短的“表描述”（列名、类型、主键/外键），并存储生成的 KV 缓存（通常在每次提示时重新计算的隐藏状态）。
2. 保持关系 – 当一个表通过外键引用另一个表时，子表的缓存在父表缓存之后构建，确保模型以与完整提示相同的顺序看到关系上下文。
3. 表 Trie 索引 – 将所有可能的表顺序前缀插入 Trie。运行时，系统根据用户查询所需的表在 Trie 中遍历，即可瞬间检索预计算的 KV 切片。
4. 缓存管理
   • 重新排序：给定用户查询，引擎尝试几种表顺序（例如字母顺序、模式依赖顺序），并选择能够最大化缓存复用的方案。
   • 加载流水线：在模型解码第一个 token 时，后台线程从 GPU 内存或主机 RAM 中流式传输所需的 KV 块，实现 I/O 与计算的重叠。
5. 与现有引擎集成 – TableCache 通过用查找加拷贝操作替代常规的“prefill”步骤，插入到 SGLang/vLLM 中，其余生成流水线保持不变。

结果与发现

• 加速效果在同一批表在大量查询中频繁出现的工作负载（例如仪表盘、报表工具）中最为显著。
• 准确率下降几乎可以忽略不计，因为缓存的 KV 状态与完整提示生成的状态完全相同；微小的下降来源于表顺序偶尔不匹配。
• 内存开销适中：为典型企业模式的 200 张表存储 KV 缓存约占 2 GB（在 40 GB GPU 上）。

实际影响

• 更快的交互式分析 – 开发者可以在 BI 工具中嵌入基于 LLM 的查询助手，并将响应时间保持在一秒以内，提升用户体验。
• 降低成本 – Prefill 是推理中最耗 GPU 的阶段；复用 KV 缓存可以减少计算周期，降低云 GPU 费用。
• 可扩展的多租户服务 – 单个 LLM 实例可以通过在租户之间共享表缓存，为许多模式重叠的客户（例如 SaaS 平台）提供服务。
• 简化提示工程 – 由于模式不再是提示的一部分，开发者可以保持提示简短，专注于自然语言意图。
• 兼容性 – TableCache 作为即插即用层，适用于任何暴露 KV 缓存的基于 Transformer 的解码器（如 LLaMA、Mistral），便于在现有流水线中采用。

限制与未来工作

• Schema churn – 添加、删除或修改表需要重新计算受影响的缓存；当前系统假设模式相对静态。
• Cache size vs. GPU memory – 非常大的目录（数千个表）可能超出 GPU 内存，需要更智能的驱逐或分层存储（CPU‑RAM → GPU）。
• Query diversity – 对于涉及许多很少使用的表的临时查询，缓存命中率下降，收益减小。
• Future directions suggested by the authors include: dynamic cache updating for evolving schemas, hierarchical caching for multi‑database environments, and extending the approach to other LLM‑driven code generation tasks (e.g., API call synthesis).

作者

• 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