Quail 如何用 roofline 模型估算 AI-SQL 过滤器的延迟成本
Quail 团队提出用 roofline 模型估算 AI-SQL 过滤器延迟，而不是为每个模型、GPU 或工作负载重新 profiling。在 H100 和 Qwen3-4B-fp8 上，5,000 条 IMDB 评论的单过滤器 SoL 下界为 6.64 秒，三过滤器最优顺序 F2→F1→F3 的 SoL 下界为 6.86 秒。这个模型把 LLM 查询计划从经验 profiling 变成可计算的硬件下界，核心不是 token 数，而是 FLOPs、HBM 流量、KV 复用和 filter 选择率。 成本模型把每个 filter 拆成 projection、attention 和 MLP，分别计算 FLOPs 与 HBM 流量，再取 max(FLOPs/峰值算力, bytes/HBM 带宽)。单过滤器 5,000 条评论需要 16 次 forward pass，projection 1.6778 秒、attention 0.1850 秒、MLP 4.7818 秒，全部 compute-bound。多过滤器时，共享 prefix 的 KV cache 可复用，HBM 容量把 batch 限制到约 1,200 条文档；排序规则用 ask cost/(1-selectivity) 给后续 filter 排名，并尝试每个 filter 作为第一个，例子中 F2 先执行比 F1 先执行低约 4.7%。 事实是 SoL 是硬件峰值下的下界，实际运行可能更长，因为峰值算力和跨 filter overlap 不一定达到。推断是 LLM 查询引擎的查询计划器必须把模型结构、量化格式、KV 复用和 filter selectivity 纳入成本，而不是只看 prompt token 数；GQA、FP8 权重和较小 KV footprint 会直接影响可批处理文档数。猜测是如果后续扩展到 AI JOIN、AI CLASSIFY 和 Blackwell FP4，硬件感知成本模型会成为 AI-SQL 产品差异化的关键。
推荐理由：它把 AI-SQL 过滤器的延迟估计从逐模型 profiling 转为 roofline 下界，并给出 filter ordering 与 KV 复用成本模型，能校正 LLM 查询引擎优化方向。