Autor: Laboratoarele invergent.ai
Surogate este un framework open-source pentru antrenarea modelelor mari de limbaj, construit ca motor nativ C++/CUDA, cu suport real pentru BF16, FP8, QFP8, FP4 și QFP4, cu execuție multi-GPU predictibilă și cu obiectivul explicit de a folosi cât mai aproape de limită hardware-ul modern.
Când am început să lucrăm la el, ne-am lovit de o problemă simplă: în ecosistemul actual, „mai rapid” nu înseamnă același lucru pentru toată lumea. În multe cazuri, viteza este evaluată pe bucăți izolate din pipeline sau pe ferestre de timp foarte scurte. În realitate, training-ul unui LLM nu este un sprint de 30 de secunde, ci un proces care rulează ore sau zile, sub presiune constantă de memorie, sincronizare și I/O.
Pentru noi, performanța relevantă a fost întotdeauna aceasta: cât progres real face un model într-o oră de rulare continuă, pe un anumit hardware.
De aceea, benchmark-urile Surogate nu sunt demo-uri. Ele rulează workload-uri complete, cu modele reale, batch size-uri reale și cicluri de training întregi. Nu măsurăm doar forward pass-ul. Măsurăm întregul pas de training: forward, backward, optimizer, sincronizări între GPU-uri, mutări de date, tot.
În aceste condiții am ales să folosim Unsloth ca reper. Nu pentru că ar fi „inamic”, ci pentru că este, în mod legitim, standardul open-source de viteză în acest moment. Este cadrul în care comunitatea a învățat să vorbească despre eficiență.
Am rulat aceleași modele, cu aceleași setări, pe același hardware. Am comparat throughput-ul susținut, nu vârfurile de câteva secunde. Rezultatele sunt consistente pe toate dimensiunile de modele testate:
- în BF16, Surogate este în medie cu aproximativ 36% mai rapid
- în FP8, câștigul mediu este de aproximativ 78%
- în QFP8, de aproximativ 61%
- în FP4, diferența ajunge între 107% și 128%
- în QFP4, în jur de 68%
Aceste cifre nu vin dintr-un truc punctual. Ele apar din comportamentul întregului pipeline pe perioade lungi de rulare.
Un exemplu concret: într-un training de câteva sute de mii de pași, un overhead de 5–10 ms între batch-uri pare neglijabil. Dar la 200.000 de pași, acea pierdere înseamnă zeci de minute de GPU idle. În multe stack-uri Python-first, aceste pierderi sunt distribuite în:
- lansări de kernel prea frecvente
- sincronizări inutile
- mutări de date greu de observat
- logică de orchestrare care trăiește în bucle Python
În Surogate, aceste zone au fost tratate ca probleme de arhitectură, nu ca oportunități de micro-optimizare. Kernelurile sunt compuse. Scheduling-ul este controlat din engine. Mișcarea datelor este explicită. Mixed precision este aplicată end-to-end, nu doar într-un punct al fluxului.
De aceea, când rulăm același model, cu același batch size, pe același GPU, diferența nu se vede în primele iterații. Se vede după o oră. După două. După o zi. Se vede în numărul total de token-uri procesate.
Un alt punct unde diferențele devin clare este multi-GPU. Multe framework-uri arată bine pe un singur GPU și se degradează pe măsură ce adaugi plăci. În testele noastre, ne uităm explicit la eficiența de scalare: dacă dublăm numărul de GPU-uri, cât din throughput se dublează efectiv.
În benchmark-urile Surogate, măsurăm nu doar viteza absolută, ci și pierderea relativă la fiecare pas de scalare. Când două GPU-uri produc semnificativ mai puțin decât dublu față de unul singur, problema nu mai este de kernel, ci de arhitectură.
Același principiu se aplică și în mixed precision. FP4 este interesant doar dacă întregul pipeline îl poate exploata. Dacă doar un fragment rulează în FP4, iar restul rămâne în BF16, câștigul real este limitat. În Surogate, aceste moduri sunt tratate ca „rețete” complete de training, nu ca flag-uri izolate.
De aceea, când vorbim despre performanță, nu vorbim despre un grafic frumos. Vorbim despre câți pași de training finalizezi într-o zi de rulare. Despre cât din timpul plătit pentru GPU se transformă în progres real al modelului.
Într-un context în care costul de calcul crește, iar modelele devin tot mai mari, diferența nu este dată de cine pornește mai repede un script, ci de cine transformă mai mult timp de GPU în antrenare efectivă.
Acolo se vede, în practică, ce înseamnă „mai rapid”.
https://github.com/invergent-ai/surogate
| Știri BVB