Quail, fra Modal og CMU, hevder en milliard tokens i minuttet på én H100-GPU
Inferensmotorutvikleren Modal og databaseforskere ved Carnegie Mellon University har bygget Quail, en åpen kildekode-inferensmotor som utnytter kjent SQL-struktur til å omorganisere forespørsler for bedre KV-caching. Ifølge egen benchmark håndterer den over en milliard tokens i minuttet på én H100-GPU — over ti ganger raskere enn deres vLLM-referanse på én spørring. Alle tallene er imidlertid selvrapportert og venter på uavhengig verifisering.
Nyheten
- september 2026 publiserte Modal og Carnegie Mellon Universitys Full Stack Data Lab kunngjøringen av Quail — forkortelse for QUery-Aware Inference Layer. Utgivelsen består av tre deler: selve motoren, en ny benchmark for AI-SQL-spørringer, og en installabel pakke kalt
quail-engine(versjon 0.1.0 på Modal) som lar lesere replikere demonen selv. Demon bruker modellen qwen3-4b-fp8 på én H100-GPU.
Bak prosjektet står et samarbeid mellom inferensforskere hos Modal og databaseforskere ved CMUs Full Stack Data Lab. Blogginnlegget er skrevet av Charles Frye og Shreya Shankar.
Problemet: AI-SQL treffer feil optimaliserte motorer
Utgangspunktet for prosjektet er en arbeidsmengdetype forfatterne kaller AI-SQL: LLM-kall brukt i databasekall i stor skala, for eksempel klassifisering eller uttrekk over millioner av rader. En slik spørring kan bestå av potensielt millioner av sekvenser på tusenvis av tokens hver.
Ifølge forfatterne er dagens inferensmotorer optimalisert for et annet bruksmønster — agentic inferens, der hver forespørsel er lang, uforutsigbar og relativt sett uavhengig av de andre. Når man sender en massiv AI-SQL-arbeidsmengde rett inn i en slik motor, blir resultatet dårlig caching og høy overhead på vertsprosessen. Quail er bygget for å løse akkurat dette: «Så vi bygde en inferensmotor for å fikse dette: the QUery-Aware Inference Layer (Quail)», skriver forfatterne.
Mekanismen: struktur i forkant
Kjernteknikken bygger på at spørringsplanlegging og LLM-inferenssjiktet snakker sammen. Når planleggeren kjenner strukturen i en SQL-spørring på forhånd — for eksempel at mange rader skal gjennom samme template med delte prefikser — kan inferensmotoren utnytte det. Forfatterne peker på tre virkemekanismer:
- Spørringsbevisst rekkefølge av forespørsler. Med en strukturert spørring i hånden kan motoren sortere forespørsler slik at KV-cachen utnyttes bedre, og slik at eviksjon (hva som kastes ut av cachen) skjer planlagt. Det er ifølge forfatterne «den store gevinsten»: «with a structured query in hand, you can order requests to better cache (and evict) KV».
- Revidert kaskade-attention. Denne rekkefølgen krever en mindre revisjon av Hydragen-stil kaskade-attention, teknikken som deler beregning mellom forespørsler med felles prefiks.
- Redusert host-overhead. Store mengder små forespørsler til små modeller kan gi lav GPU-utnyttelse fordi verten ikke rekker å mate GPU-en. Når strukturen i forespørslene er kjent på forhånd, kan denne overheaden unngås, skriver forfatterne.
Poenget er altså ikke en ny modell eller ny maskinvare, men at spørringsplanleggingens kjennskap til arbeidsmengden gjør inferensmotorens planleggingsproblem vesentlig enklere.
Tallene — som egne påstander
Alle ytelsestallene under stammer fra Modal/CMU sitt eget blogginnlegg og deres egen benchmark. Ingen uavhengig replikering foreligger i tilgjengelig dekning.
- Over 1 milliard tokens per minutt per H100. På én multi-join-spørring der planlegging er spesielt viktig, hevder forfatterne at Quail oppnår over én milliard prosesserte tokens i minuttet (TPM/GPU) — over ti ganger raskere enn deres vLLM-referanse på samme maskinvare. Dette er altså topp-tallet på en konstruert spørring, ikke et gjennomsnitt.
- 1,84x geometrisk gjennomsnitt. På den nylanserte AI-SQL-benchmarken hevder de at Quail samlet sett er 1,84 ganger raskere enn vLLM, geometrisk gjennomsnittet over oppgavene. Merk at benchmarken bevisst inkluderer to spørringer designet for å vise forbedringsområder i AI-SQL-inferens — forfatterne sier selv at de er laget for å avsløre hvor motoren strever. Det betyr at gjennomsnittstallet delvis hviler på ugunstige tilfeller, noe som gjør det vanskelig å tolke uten per-oppgave-resultater, som ikke er detaljert i kunngjøringen.
- Under 6 cent per milliard tokens. Kjørt på Modal skal topp-ytelsen tilsvare en kostnad på under 6 cent per milliard tokens. Dette tallet kombinerer forfatternes egen ytelsesmåling med Modals egen prisliste — det er en selvmåling på egen plattform, ikke en markedspris.
Det er verdt å merke seg at det slående titallstallet gjelder én spørring valgt nettopp fordi planlegging betyr mye der, mens det mer konservative 1,84x-tallet er det bredere resultatet.
Hva du kan teste selv
Utgivelsen legger opp til reproduksjon: quail-engine-pakken (0.1.0) er installabel via Modal, og demon kjører qwen3-4b-fp8 på én H100. Benchmarken for AI-SQL-spørringer er også offentliggjort i forbindelse med utgivelsen, slik at andre kan kjøre sammenligningen mot vLLM eller andre motorer på samme vilkår.
Forbehold og åpne spørsmål
Flere forhold gjør at tallene bør behandles med forsiktighet inntil videre:
- Selvrapportert benchmark. Alle resultater er målt av utviklerne selv, på deres egen benchmark, mot en referanse (vLLM) konfigurert av dem. Uavhengig replikering foreligger ikke.
- Benchmarkens sammensetning er uklar. Kunngjøringen oppgir ikke per-oppgave-resultater eller fullstendig sammensetning, og to spørringer er bevisst utformet for å vise svakheter. Det gjør det vanskelig å vurdere hvor robust 1,84x-tallet er.
- Modell- og arbeidsmengdevalg. Demon bruker en liten modell (qwen3-4b-fp8), og mekanismene — spesielt host-overhead ved små forespørsler — er mest relevante for nettopp slike arbeidsmengder. Hvor godt resultatene generaliserer til større modeller eller andre AI-SQL-mønstre, er ikke dokumentert i kunngjøringen.
- Kostnadstallet er en selvmåling. «Under 6 cent per milliard tokens» forutsetter Modals plattform og priser, og følger direkte av ytelsestallet.
Flere spørsmål står åpne: hvordan Quail fungerer sammen med etablerte SQL-motorer i praksis, hvordan den skalerer utover demoen, og om uavhengige parter kan gjenskape titallstallet. Siden benchmarken og pakkene er offentlig tilgjengelige, er dette spørsmål som bør kunne besvares gjennom replikering i tiden som kommer — inntil da er det rimelig å lese utgivelsen som et lovende, men udokumentert av andre, resultat fra et team som kjenner både sine egne styrker og svakheter.

