AI mai rapid, cu resurse controlate: cache, batching și cuantizare

Seria II: De la infrastructură la proiecte agentice în producție. Episodul 19 din 20.

Un răspuns AI lent poate ține utilizatorul în fața unui formular, dar un răspuns rapid și greșit nu rezolvă problema. Pentru un IMM, decizia utilă este să optimizeze componenta care consumă efectiv timp și resurse. Propunerea acestui episod: testați reutilizarea prefixelor înainte de a schimba simultan modelul, hardware-ul și precizia numerică.

Continuăm portalul B2B fictiv pentru solicitări și documente. După accesibilitatea și descoperirea conținutului, analizăm agentul integrat în aplicație, care pregătește un rezumat pentru operator. Agenții care dezvoltă portalul au alt rol: pot implementa experimentul și testele. Scenariul de mai jos nu descrie rezultate măsurate la un client.

Unde se consumă timpul

Inferența este folosirea unui model deja antrenat pentru a produce un rezultat. Într-un model lingvistic, intrarea și ieșirea sunt procesate în tokenuri, unități care pot reprezenta cuvinte sau fragmente de cuvinte. Durata unei cereri poate include așteptarea în coadă, procesarea intrării și generarea continuării.

Procesarea intrării se numește prefill, iar generarea tokenurilor noi, decode. TTFT, Time To First Token, măsoară timpul până la primul token; nu reprezintă durata răspunsului complet. Pentru un formular care afișează rezultatul numai la final contează latența integrală. Pentru text afișat progresiv contează și ritmul continuării.

Înaintea oricărui reglaj, verificați dacă întârzierea apare în model, în citirea documentelor sau într-un serviciu extern. Un cache al modelului nu repară o interogare lentă în baza de date. Păstrăm instrumentarea discutată în episodul despre observabilitate și măsurăm separat aceste componente.

Ce reutilizează cache-ul de prefix

Un cache păstrează informații pentru reutilizare. Prefixul este partea de început a intrării. În vLLM, un motor pentru servirea modelelor, Automatic Prefix Caching reutilizează stările intermediare KV, prescurtarea de la key/value, pentru prefixe comune. Nu reutilizează automat răspunsul final.

Ghidul vLLM, actualizat la 13 octombrie 2026, delimitează beneficiul: reutilizarea scurtează prefill, fără să accelereze direct generarea tokenurilor noi. Dacă intrările nu împart un prefix sau domină generarea unui răspuns lung, avantajul poate fi redus ori absent. Potrivirea privește tokenurile și mecanismul de blocuri al motorului, nu simpla asemănare a ideilor.

În portal propunem instrucțiuni comune stabile la început, urmate de solicitarea specifică. Nu mutăm documente între firme pentru a fabrica reutilizare. Schimbarea regulilor comune primește o versiune nouă, astfel încât experimentul să poată fi urmărit.

Separarea datelor rămâne obligatorie

Într-un portal folosit de mai multe companii, reutilizarea trebuie delimitată după acces. Documentația vLLM oferă cache_salt, o valoare suplimentară per cerere care permite partajarea blocurilor numai între cereri cu aceeași valoare. Sunt discutate inclusiv riscurile deducerii informațiilor din diferențe de latență.

Pentru scenariul nostru propunem ca aplicația să atribuie pe server delimitarea grupului de încredere, fără să accepte arbitrar valoarea trimisă de vizitator. Verificăm izolarea între firme și regulile de retenție aplicabile. Această măsură completează autorizarea, nu o înlocuiește. Nu copiem documentele confidențiale în jurnalele experimentului.

Batching: capacitate și așteptare

Batching înseamnă procesarea mai multor cereri în loturi. Continuous batching permite motorului să actualizeze grupul cererilor active pe parcurs. Capacitatea de a procesa mai multe cereri nu înseamnă automat că fiecare utilizator primește primul rezultat mai repede.

Ghidul de optimizare vLLM explică influența concurenței și a memoriei KV asupra execuției. Insuficiența acestei memorii poate conduce la întreruperi și recalculare. Lucrarea PagedAttention, prezentată la SOSP 2023, documentează rolul administrării memoriei pentru servirea modelelor. Rezultatele sale comparative aparțin experimentelor din 2023, nu portalului nostru.

În portal, cererile interactive au un obiectiv de răspuns diferit de rezumatele care pot aștepta în fundal. Le măsurăm separat. Nu creștem concurența doar pentru a obține un debit mai mare, ignorând așteptarea celorlalți utilizatori.

Cuantizarea este un experiment separat

Cuantizarea reprezintă folosirea unei precizii numerice reduse pentru anumite valori ale modelului sau ale stărilor intermediare. Poate reduce memoria necesară, dar efectul depinde de metodă, hardware și implementare. Documentația vLLM publică o matrice de compatibilitate; un format disponibil pe un accelerator nu este automat potrivit pe altul.

Pentru memoria KV în FP8, un format numeric în virgulă mobilă pe 8 biți, documentația recomandă calibrarea pe un set de date, adică estimarea parametrilor conversiei folosind exemple. Există și limitări ale componentelor de execuție. Mai puțină memorie nu dovedește singură o latență mai bună sau o calitate acceptabilă.

Pentru portal reverificăm identificatorii, sumele, datele calendaristice și omisiunile din rezumat. Păstrăm configurația inițială pentru revenire. Nu activăm cuantizarea în același test cu prefix caching, deoarece nu am mai putea atribui clar efectele observate.

Ce controlăm în cloud și on-prem

On-prem înseamnă infrastructură administrată în mediul propriu. Echipa controlează motorul, configurația și resursele, dar răspunde și de operare. Un serviciu cloud gestionat poate expune alte opțiuni și alte limite; nu presupunem că permite reglajele vLLM.

De exemplu, documentația Google Cloud distinge cache-ul implicit de cel creat explicit, cu politici de retenție, modele suportate și costuri de stocare pentru cache-ul explicit. Verificați serviciul și contractul concret. Economia la anumite tokenuri nu reprezintă automat economia întregului proces, iar o funcție disponibilă nu garantează reutilizarea pentru traficul firmei.

Fișa unui singur experiment

Rezultatul practic al episodului este această fișă propusă pentru portal:

1. Ipoteză: prefixul comun poate reduce timpul până la primul token și, dacă procesarea intrării contribuie suficient, durata rezumatului complet. Stabilim dinainte pragul relevant pentru operator și condițiile de oprire.
2. Configurație fixă: notăm modelul, versiunea motorului, hardware-ul, șablonul intrării, limita ieșirii și setările generării. Comparăm aceeași intrare, cu reutilizarea oprită și pornită, fără alte schimbări.
3. Trafic reprezentativ: folosim cereri anonimizate ori sintetice, în română, cu documente scurte și lungi. Includem prefixe repetate și diferite, încărcare concurentă și probe între firme separate.
4. Cache rece și cald: distingem pornirea fără prefix disponibil de rulările care îl pot reutiliza. Repetăm și alternăm condițiile; nu raportăm numai cea mai favorabilă execuție.
5. Indicatori: înregistrăm TTFT și durata integrală, inclusiv p50, mediana, și p95, valoarea la care sau sub care se încadrează 95% dintre măsurători. Urmărim timpul în coadă, reutilizarea, memoria, erorile și calitatea pe aceleași criterii.
6. Decizie: documentăm configurația acceptată, limitele, responsabilul și revenirea. Dacă reutilizarea nu ajută traficul real sau afectează izolarea ori calitatea, oprim schimbarea.

Rata reutilizării nu se deduce doar din scurtarea timpului. Verificăm indicatorii oferiți de motor și consemnăm separat memoria rezervată și cea efectiv utilizată. Dacă schimbăm modelul sau șablonul conversației, reluăm măsurarea de referință. Câteva răspunsuri identice nu demonstrează capacitatea sistemului la orele de vârf.

Această fișă transformă o promisiune de viteză într-o decizie verificabilă. Episodul final va lega optimizarea de arhitectura completă a portalului, cu responsabilități și criterii de acceptare pentru întregul flux.

Surse

Surse consultate la 19 octombrie 2026. Documentația latest evoluează; configurația implementată trebuie verificată în versiunea instalată. Exemplul portalului și fișa experimentului sunt propuneri, fără rezultate sau economii pretinse.

• vLLM: Automatic Prefix Caching, actualizat la 13 octombrie 2026
• vLLM: mecanismul și izolarea cache-ului de prefix
• vLLM: optimizare și reglaje
• vLLM: cuantizare și compatibilitate hardware
• vLLM: cuantizarea memoriei KV și calibrare
• vLLM: indicatori de producție
• Google Cloud: prezentarea cache-ului de context
• Kwon și colaboratorii: PagedAttention, SOSP 2023, lucrare depusă la 12 septembrie 2023