Quail：让查询计划直接调度 LLM 推理的 AI-SQL 引擎
Quail 把 LLM 推理纳入查询计划控制，在自建 QUAIL-B 基准上整体较 vLLM 快 1.84 倍，BIO-…
AI-SQL 正在让数据库直接消费非结构化数据：用户用自然语言写一个 AI 函数，引擎就可以在每行数据上调用 LLM 来分类、过滤甚至做连接。然而这条路径非常昂贵——一个普通的过滤条件就要为每一行发起一次模型调用，一次朴素连接则要为左右两表每一对行都发起调用，整体规模往往达到数十万乃至上百万次推理。Snowflake Cortex AISQL、BigQuery AI Functions、Databricks AI Functions 以及 MotherDuck 等数据库厂商都已经支持类似能力。
围绕降低成本，学术圈已经出现了 DocETL（UC Berkeley）、LOTUS（Stanford）、Palimpzest（MIT）、ThalamusDB（Cornell）等开源系统，主要思路仍是减少 LLM 调用次数或换用更便宜的模型。但即使经过优化，单条查询计划仍可能涉及海量推理调用。
核心思路：让查询计划掌控推理
Quail 的关键观点是：与其把上百万次相关的模型调用交给通用推理引擎去排程，不如让查询计划本身直接控制 LLM 推理的执行方式。文章以 BIO-4 查询为例：给定 5000 份长篇医学报告与 4144 个不良反应术语，要找出同时提及心血管与神经系统反应的事件。其逻辑计划是先在三个输入上做过滤，再做两次连接。
如果用 vLLM 0.26.0 + Qwen3 4B FP8 在单卡 H100 上按「一次请求一个 prompt」的方式跑：
- 由于输出被约束为 TRUE/FALSE 单 token，所有模型工作都集中在 prefill 阶段。
- 即便 batch 足够大、能压满 H100，PyTorch profiler 抓取的 3.5 秒窗口显示，CPU 主线程在调度器与 execute_context 之间来回切换，H100 实际处于大量空转状态。
- 最终在 scale factor 1.0 下，vLLM 跑完这条查询耗时约 6.84 小时，是「速度上限」（speed-of-light，SoL）估算值 894 秒的 27.55 倍。
基准 QUAIL-B 与 Quail 表现
为了系统评估 AI-SQL 引擎，研究团队正在构建 QUAIL-B 基准。在已公布的对比中：
- 整体表现：Quail 在 QUAIL-B 上比 vLLM 快约 1.84 倍。
- BIO-4 查询：Quail 比 vLLM 快 14.04 倍，把「Jev 级速度与智能」带到了数据库规模的工作负载上。
- AGENT-1 查询：Quail 反向落后，耗时是 vLLM 的 2.32 倍，提示在某些 agent 类负载下通用推理引擎的批处理策略仍有优势。
文章指出，Quail 的实现细节（如完整的 roofline 计算与执行计划）将在后续博文中展开。
价值与边界
Quail 揭示了一个被通用推理框架忽略的事实：在 AI-SQL 这类「上百万次结构化、彼此相关」的推理场景下，由数据库查询计划主导调度，能够显著减少 host 开销并提升 KV cache 复用率，把 GPU 利用率拉向 SoL 估算值。但它并非全面优于 vLLM——AGENT-1 上的反超说明，推理引擎之间的优劣高度依赖查询结构与负载形态。对需要在数据库内大规模调用 LLM 的团队而言，Quail 提供了一种值得关注的工程路径：把推理调度权从「通用引擎」交还给「理解数据的查询计划」。