Testarea de sarcină a LLM-urilor îți epuizează bugetul API

Echipele de inginerie care construiesc pe baza API-urilor Large Language Model (LLM) se confruntă cu o provocare financiară semnificativă în timpul testării de sarcină. Problema principală provine din absența unui mod de testare nativ oferit de furnizorii de API-uri LLM. Aceasta înseamnă că fiecare cerere efectuată, chiar și în scopuri de validare, cum ar fi verificarea stabilității cozii sau a logicii de reîncercare, implică costuri reale de calcul și consumă token-uri. În consecință, efectuarea validării volumului devine prohibitiv de scumpă, rezultând adesea în facturi substanțiale greu de justificat, mai ales când bug-urile de infrastructură identificate ar fi putut fi remediate cu efort minim.

Implicațiile financiare sunt considerabile, așa cum este ilustrat de un scenariu care implică 1.000 de utilizatori concurenți, fiecare declanșând o conductă cu trei apeluri LLM, cu o medie de 800 de token-uri de intrare și 200 de token-uri de ieșire. Acest lucru duce la 3.000 de apeluri pe secundă, generând potențial milioane de apeluri API într-o perioadă scurtă și costuri semnificative. Problema este exacerbată de instrumentele care injectează cantități mari de conținut web în fereastra de context, dublând costurile estimate. Acest lucru este deosebit de problematic, deoarece validarea infrastructurii, care vizează testarea unor elemente precum adâncimea cozii, backoff-ul de reîncercare și întrerupătoarele de circuit, nu necesită inferență reală și ar trebui, în mod ideal, să fie un proces cu costuri reduse.

Au apărut mai multe soluții de evitare, inclusiv utilizarea proxy-urilor locale cu răspunsuri predefinite, redarea traficului înregistrat sau configurarea conturilor de test dedicate cu limite de cheltuieli. Cu toate acestea, fiecare metodă are dezavantaje: proxy-urile s-ar putea să nu simuleze cu precizie latența rețelei sau limitarea ratei, redările înregistrate necesită întreținere constantă pe măsură ce prompt-urile și schemele se modifică, iar conturile dedicate sunt costisitoare și s-ar putea să nu ofere o validare completă. Acestea sunt măsuri compensatorii pentru o primitivă lipsă, subliniind necesitatea ca furnizorii să ofere o soluție de testare dedicată și eficientă din punct de vedere al costurilor, care să separe validarea infrastructurii de inferența reală.