Prompt lookup i llama.cpp får 42 ganger raskere utkast, men endringene ligger i en fork

«En veldig dum utkastmodell» er hvordan Hayder Tirmazi beskriver n-gram-modellen bak prompt lookup decoding, varianten av spekulativ dekoding som llama.cpp, vLLM og Hugging Face Transformers støtter. I et blogginnlegg 26. september viser han hvordan han gjorde utkastfasen i llama.cpp opptil 42 ganger raskere med opptil 2,6 ganger mindre minne, uten å endre algoritmen. En ekstra optimalisering fra Daniel Lemire løfter den samlede forbedringen til opptil 140 ganger.

Prompt lookup gjetter de neste tokenene ved å slå opp hvilke tokens som oftest har fulgt de siste én til fire tokenene. llama.cpp bruker tre cacher til det: konteksten, tidligere kjøringer og en statisk cache bygget fra et tekstkorpus med llama-lookup-create. Cachene var nestede std::unordered_map, og Tirmazi fant at de indre mapene ble kopiert unødvendig på hvert utkaststeg. Bare å lese dem via referanse ga 4,5 til 25,6 ganger raskere utkast. Deretter byttet han til Martin Ankerls unordered_dense for den ytre mapen, sorterte vektorer med binærsøk av fast lengde for de indre, og Lemires constmap for den statiske cachen, som aldri endres etter lasting.

Med hele WikiText-103 (541 MB) som statisk korpus falt tiden per utkasttoken fra 165,48 til 6,47 mikrosekunder med den første endringen alene. Constmap-steget kuttet lastetiden for den statiske cachen fra 3,76 til 0,23 sekunder og toppminnet fra 1,71 til 1,31 GB. Akseptraten, andelen utkast modellen godtar, er i praksis uendret. Alt er målt med llama-lookup-stats på en Apple M4 Pro med 48 GB minne.

Tallene gjelder utkastfasen, ikke tokens per sekund. Selv den gamle koden brukte mikrosekunder per utkasttoken, mens et fremoverpass i en lokal modell typisk tar millisekunder. Gevinsten merkes derfor mest når den statiske cachen er stor: raskere oppstart og rundt 400 MB mindre toppminne.

Endringene ligger som fem åpne pull requests i Tirmazis egen fork, ikke i ggml-org/llama.cpp. På Hacker News skriver han at han står i en personlig konflikt og ber om råd:

«På grunn av dette kan jeg ikke opprette en PR eller en issue i llama.cpp-repoet» — Hayder Tirmazi, på Hacker News

Bakgrunn

Spekulativ dekoding lar en billig utkastmodell foreslå flere tokens som den store modellen sjekker i ett pass. Prompt lookup bruker ingen nevral utkastmodell i det hele tatt, bare tellinger av n-gram, og passer best når svaret gjentar mye av prompten, som ved koderedigering. Den statiske cachen kom inn i llama.cpp via en pull request fra Johannes Gaessler, og det er målemetoden derfra Tirmazi har lånt.

Hva bør du gjøre?

1. Kjør llama-lookup-stats på dine egne prompter med og uten statisk cache, slik at du vet hvor mye av tiden som faktisk går til utkast.
2. Bruker du en stor statisk cache, bygg Tirmazis fork og sammenlign oppstartstid og minne. Benchmarkkoden ligger i repoet ngram-cache-bench.
3. Hold produksjonsoppsettet på upstream-llama.cpp inntil endringene er gjennomgått der, siden ingen av vedlikeholderne har vurdert koden.