llama.cpp zrýchľuje streamovanie v llama-serveri: renderovanie na token výrazne kleslo

Projekt llama.cpp zlúčil do hlavnej vetvy zmenu, ktorá cieli na menej nápadnú, no pre používateľa veľmi viditeľnú časť lokálnej AI: vykresľovanie odpovedí vo webovom rozhraní llama-servera počas streamovania. Nejde o nový model ani o zrýchlenie výpočtu tokenov na CPU či GPU. Úprava odstraňuje náklady v používateľskom rozhraní, ktoré sa opakovali pri každom prijatom tokene a pri dlhších odpovediach mohli prekryť časť výkonu získaného rýchlejšou inferenciou. Zmena bola zlúčená 24. júla ako pull request číslo 26053 a v histórii projektu je priradená k zostaveniu b10121.

Autor najprv pridal výkonnostný testovací rámec, aby sa optimalizácia neopierala iba o subjektívny pocit plynulosti. Všetky zverejnené čísla vyjadrujú čas na jeden streamovaný token. Najväčší rozdiel sa objavil pri zbaliteľných blokoch obsahu a terminálu: nameraná hodnota klesla z 210,36 na 2,67 milisekundy. Spracovanie Markdownu a pomocných funkcií pre kód sa znížilo z 11,58 na 0,62 milisekundy, ochrana zápisu LaTeXu z 22,02 na 3,33 milisekundy a aktualizácia úložiska konverzácie pri 40 správach z 3,07 na 1,36 milisekundy. Sú to merania autora z konkrétneho testovacieho prostredia, nie univerzálny prísľub pre každý prehliadač a zariadenie.

Dôležité je rozlíšiť dve vrstvy latencie. Inferenčný server vytvára tokeny podľa možností modelu a hardvéru, zatiaľ čo webové rozhranie ich prijíma, spracúva a priebežne zobrazuje. Ak klient pri každom tokene opakovane prerába drahý strom komponentov, analyzuje celý Markdown alebo zbytočne spracúva skrytý obsah, používateľ môže vidieť trhaný text aj vtedy, keď backend generuje rýchlo. Optimalizácia preto nezvyšuje počet tokenov za sekundu na strane modelu, ale znižuje pravdepodobnosť, že sa úzkym miestom stane samotný prehliadač.

Najväčší zásah sa týka zbaliteľných blokov. Po novom sa ich vnútorný obsah nevykresľuje, keď je blok zatvorený. Pri agentických odpovediach je to praktické najmä pre terminálové výstupy, volania nástrojov, dlhé úryvky kódu alebo pomocné sekcie, ktoré používateľ práve nepozerá. Predchádzajúce správanie mohlo udržiavať a aktualizovať aj skrytú časť rozhrania. Zdanlivo malá podmienka tak odstraňuje opakovanú prácu z najčastejšej cesty, ktorou prechádza každý nový token.

Ďalšie úpravy obmedzujú opakované spracovanie textu. Markdown komponent dostal lacnejšie cesty pre obsah, ktorý nevyžaduje všetky ochranné transformácie, a spracovanie LaTeXu používa rýchlu vetvu, ak text neobsahuje znaky naznačujúce matematický zápis. Súčasťou zmeny sú aj testy, ktoré kontrolujú, že obyčajný text, zoznamy, tabuľky či kód bez spúšťacích znakov zostanú nezmenené. Optimalizácia teda nie je iba vypnutím kontroly; projekt sa snaží oddeliť jednoduchý obsah od prípadov, kde je plná transformácia naozaj potrebná.

Zmenilo sa aj ukladanie priebehu konverzácie. Namiesto drahšieho postupu pri každom prírastku sa stav aktualizuje cielenejšie priamo na mieste. Prínos je menší než pri zbaliteľných blokoch, ale rastie s dĺžkou rozhovoru a počtom priebežných aktualizácií. Pri lokálnych agentoch, ktorí v jednej relácii vykonajú desiatky nástrojových krokov, sa malé náklady opakované stovky alebo tisíce ráz môžu premeniť na citeľné zaťaženie hlavného vlákna prehliadača.

Pre prevádzkovateľov llama-servera z toho vyplýva, že po aktualizácii môžu očakávať najväčší rozdiel pri dlhých streamovaných odpovediach s Markdownom, matematickým zápisom, kódom a zbaliteľnými blokmi. Na krátkej odpovedi bez nástrojov nemusí byť rozdiel nápadný. Rovnako platí, že zmena nevyrieši pomalé generovanie spôsobené nedostatkom pamäte, nevhodnou kvantizáciou alebo slabým akcelerátorom. Odstraňuje však klientsku réžiu, ktorá mohla skresľovať hodnotenie celého lokálneho AI stacku.

Pre vývojárov je užitočný aj spôsob, akým bola zmena pripravená. Pull request pridal merací rámec ešte pred samotnými optimalizáciami a výsledky uvádza po jednotlivých komponentoch. Takýto postup pomáha odlíšiť reálne úzke miesto od náhodného zrýchlenia a vytvára základ pre regresné testovanie. Zverejnené porovnania však treba čítať ako mikrobenchmarky konkrétnych operácií. Celkové zrýchlenie používateľského zážitku bude závisieť od rýchlosti modelu, dĺžky odpovede, typu obsahu, prehliadača aj výkonu klientského zariadenia.

Zaujímavý je aj rozsah zásahu: autor výslovne uvádza, že ide o čistú opravu používateľského rozhrania bez zmien v súboroch C++. Commit pritom mení 18 súborov a pridáva rozsiahlejšie testovacie zázemie. To ukazuje, že výkon lokálnej generatívnej AI už nemožno posudzovať iba podľa jadra inferencie. Keď sa modely a backendy zrýchľujú, väčší podiel oneskorenia sa môže presúvať do serializácie, sieťovej vrstvy, správy stavu a vykresľovania.

Praktickým krokom po nasadení novej verzie je sledovať nielen serverové tokeny za sekundu, ale aj plynulosť hlavného vlákna prehliadača, čas spracovania jedného streamovaného prírastku a rast spotreby pamäte pri dlhom chate. Ak sa problém prejavuje iba pri otvorených terminálových alebo matematických blokoch, nové merania pomôžu určiť, či ostáva úzke miesto v konkrétnom komponente. Projekt zároveň naznačuje ďalšiu nadväzujúcu optimalizáciu, jej podobu však zatiaľ nemožno považovať za hotovú súčasť vydania.

Zmena v b10121 je teda technicky úzka, no významná pre používateľov, ktorí llama.cpp používajú ako interaktívny lokálny server a nie iba ako príkazový inferenčný nástroj. Prudký pokles nameraných nákladov pri najpomalšom bloku môže odstrániť trhanie v situáciách, kde rozhranie doteraz nestíhalo za backendom. Najdôležitejším výsledkom nie je nové marketingové číslo pre model, ale čistejšie oddelenie výkonu inferencie od výkonu klienta a lepšia merateľnosť oboch vrstiev.