Motor de inferência Quail atinge 1 bilhão de tokens por minuto por GPU

O problema: inferência para AI-SQL

Pesquisadores da Modal e do Full Stack Data Lab da Carnegie Mellon University apresentaram o Quail (QUery-Aware Inference Layer), um motor de inferência voltado a consultas AI-SQL - extensões do SQL em que funções como AI.IF e AI_JOIN passam as linhas do banco por um LLM. Diferente do NL2SQL (que usa IA para gerar SQL), no AI-SQL o SQL constrói e consome prompts programaticamente; plataformas como Snowflake Cortex, Databricks AI Functions e BigQuery já têm versões próprias.

Essas consultas podem gerar milhões de sequências de milhares de tokens. Como geralmente exigem pouca inteligência, modelos pequenos de pesos abertos bastam - mas entregá-las diretamente a um motor otimizado para inferência de agentes é muito ineficiente. O trabalho também explica por que essa carga precisa de GPU: filtros e joins comuns têm baixa intensidade aritmética, mas cada byte passado por um LLM passa por bilhões de operações de multiplicação de matrizes.

Resultados

Em uma consulta com múltiplos joins onde o planejamento importa, o Quail processa mais de 1 bilhão de tokens por minuto por GPU H100, mais de 10 vezes mais rápido que o baseline vLLM no mesmo hardware - o que, na Modal, custa menos de 6 centavos por bilhão de tokens. No benchmark recém-lançado para consultas AI-SQL, o Quail roda 1,84 vezes mais rápido que o vLLM em média geométrica, incluindo duas consultas criadas justamente para mostrar limitações (como o caso de traços de agentes, em que perde para o vLLM por não modelar compartilhamento de prefixos entre documentos).

Como funciona

A arquitetura combina componentes de banco de dados e de inferência: parser SQL via sqlglot, um planejador de consultas customizado, um motor de execução derivado dos forward passes do vLLM (com kernels do DeepGEMM e Flash Attention 3 e fusão de kernels escrita em Triton) e armazenamento em Arrow/pyarrow.

As principais contribuições voltadas à inferência:

• Cache KV consciente da consulta: como o motor conhece o plano inteiro de antemão, pode prever acessos, fazer prefetch e evicionar entradas sem arrependimentos - ao contrário de cargas de agentes, em que o intervalo entre acessos é imprevisível.
• Zero decode: para classificação booleana (AI.IF, que fundamenta os joins), basta o passe final de prefill, que emite um único token. Isso elimina as fases de decode, sampling, CUDA Graphs e decodificação especulativa.
• Busca de ordem de joins com consciência de KV: a busca mantém múltiplos candidatos e descarta planos dominados no sentido de Pareto (mais tokens, mais pares de atenção e mais cache), escolhendo pelo modelo de custo.
• Modelo de custo "speed-of-light": baseado no modelo roofline, superestima deliberadamente o pico do hardware, servindo como guia de otimização.
• Atenção em cascata simplificada: para joins, os sufixos atendem à âncora (cross-attention), depois a si mesmos, e os resultados são combinados com reescalação LSE, técnica semelhante à cascade attention do Flash Infer e ao Hydragen. O vocabulário também é reduzido a 8 opções no cabeçalho de saída, encolhendo a matrícula final de unembedding.

Futuro e método

Os autores listam trabalhos futuros: caches KV em múltiplas camadas, otimização entre consultas, suporte a conjuntos maiores que a memória, índice radix para compartilhamento de prefixos, melhor sobreposição entre kernels e fine-tuning em plena execução.

Grande parte do código foi escrita com agentes de programação; segundo os autores, o difícil deixou de ser executar ideias e passou a ser definir problemas e medir resultados. Eles esperam que o mundo dos motores de inferência convergeça para um núcleo reutilizável, como ocorreu com bancos de dados após o DataFusion, mantendo o benefício da colaboração em código aberto - sem que todo motor seja escrito do zero por aplicação.