Reducerea costului LLM fără reducerea calității

O factură de LLM crește pe tăcute. Un prototip care costa câțiva dolari pe zi ajunge în producție, traficul crește, iar într-o dimineață finanțele îți trimit o factură cu un număr pe care nu-l planificase nimeni. Reflexul e să pui peste tot un model mai ieftin și să speri că nimeni nu observă scăderea calității. E mișcarea greșită. De obicei poți reduce costul de inferență cu mai mult de jumătate fără să atingi calitatea — dacă ataci risipa, nu modelul.

Ierarhizează modelele, escaladează la îndoială

Majoritatea cererilor nu au nevoie de cel mai scump model al tău. Deci nu le trimite acolo. Rutează cazurile ușoare mai întâi către un model mic și ieftin și escaladează doar atunci când acesta semnalează încredere scăzută sau pică o verificare ieftină de validitate. Un pipeline ierarhizat — model mic, apoi mediu, apoi modelul de frontieră ca ultimă soluție — transformă un cost fix per apel într-o curbă înclinată spre nivelul ieftin, pentru că majoritatea traficului e ușor. Capcana e să escaladezi prea rar și să livrezi răspunsuri proaste. Așa că punem pragurile de rutare în spatele unui set de evaluare și le reglăm până când modelul mic rezolvă tot ce poate și nimic din ce nu poate.

Trimite mai puțin către model

Cel mai ieftin token e cel pe care nu-l generezi niciodată. Fă caching agresiv, pe două niveluri. Caching-ul cu potrivire exactă elimină cazul jenant în care plătești de două ori pentru o cerere identică la nivel de octet. Caching-ul semantic merge mai departe: încorporează cererea și, dacă o interogare din trecut e suficient de apropiată ca sens, servește răspunsul stocat în loc să apelezi modelul deloc. Pe volume de muncă cu întrebări repetitive, un cache semantic poate absorbi o mare parte din trafic înainte ca acesta să ajungă la inferență. Setează cu grijă pragul de similaritate — prea permisiv și servești, plin de încredere, răspunsul greșit al unui vecin.

Apoi taie din ce chiar trimiți. Majoritatea prompturilor sunt umflate — exemple few-shot învechite, instrucțiuni redundante, documente întregi lipite când trei paragrafe extrase ar fi de ajuns. Strânge system prompt-ul, extrage îngust în loc să îndeși context și reduci tokenii de intrare la fiecare apel. În final, fă batching. Acolo unde latența permite, grupează cererile ca modelul să proceseze multe deodată și să plătești tariful mai mic pe lot. Trimming-ul și batching-ul sunt neglamuroase și se compun — câteva procente per apel, pe milioane de apeluri, înseamnă bani reali.

Demonstrează cu evaluări că s-a menținut calitatea

Aici e partea pe care echipele o sar și e cea care contează cel mai mult. Fiecare dintre aceste schimbări este un pariu că supraviețuiește calitatea — și un pariu al cărui rezultat nu-l poți vedea uitându-te la câteva răspunsuri. Așa că întâi construiești un set de evaluare, cu cazuri notate care reflectă utilizarea reală, și îl rulezi după fiecare optimizare. Schimbare de model, prag de cache, prompt tăiat, lot mai mare — fiecare se livrează doar dacă scorul de evaluare se menține. Evaluarea transformă munca de cost dintr-o ghicire nervoasă într-o disciplină de inginerie: poți vedea factura scăzând și scorul rămânând neted pe același dashboard.

O reducere de cost pe care nu o poți măsura față de o evaluare nu e o reducere de cost. E un pariu pe care îl vei pierde încet, câte un răspuns tăcut mai slab pe rând.

— Protocore · Inginerie AI

Câștigul e că, în cele din urmă, costul și calitatea încetează să mai fie un compromis și devin două butoane pe care le reglezi independent. Pe un pipeline de documente straight-through care procesa peste un milion de documente, am tăiat cheltuiala de inferență cu mult peste jumătate — ierarhizare, caching și trimming stivuite — în timp ce scorul de evaluare nu s-a clintit, pentru că fiecare schimbare trebuia să treacă de evaluare înainte să se livreze. Mai ieftin e ușor. Mai ieftin, cu dovezile care arată că nu s-a stricat nimic, e adevărata treabă.