Ce sa întâmplat
Într-o postare de inginerie din 28 august 2026, Databricks a descris API-urile AI Runtime pentru a face joburile mari de antrenament PyTorch mai rezistente la defecțiunile GPU-ului și a conductelor de intrare mai lente. Compania recomandă puncte de control distribuite, salvări asincrone, recuperare automată, stocarea în cache locală și preîncărcarea și verificarea stării conductei de date și a generatorului de numere aleatoare alături de greutățile modelului.
Postarea recomandă apoi operația de salvare asincronă a lui PyTorch. În acest design, antrenamentul plătește pentru o copie rapidă într-un tampon de pregătire, în timp ce încărcarea continuă în fundal. Databricks spune că UCVolumeWriter și UCVolumeReader de la AI Runtime folosesc staging NVMe local și marchează un punct de control finalizat numai după ce toate datele au ajuns la destinație. Prin urmare, abordarea separă punctul în care antrenamentul poate continua de finalizarea ulterioară a lucrărilor de stocare, în același timp legând finalizarea punctului de control de destinație, mai degrabă decât doar de copia locală. Această distincție este esențială pentru descrierea postării a antrenamentului tolerant la erori și a fluxului său de lucru de recuperare.
În comparațiile raportate de companie, un model de limbaj DDP cu 2,8 miliarde de parametri pe 32 de GPU-uri H100 a durat 36 de secunde cu async_save față de 66 de secunde cu torch.save sau de 1,8 ori mai rapid. Pentru un model cu 20 de miliarde de parametri pe 32 de GPU-uri H100, tabelul raportează 9 secunde față de 522 de secunde sau de 58 de ori mai rapid. Aceste cifre descriu comparația punct de control-timp prezentată de Databricks pentru modelele și hardware-ul menționate. Acestea sunt oferite ca dovezi pentru valoarea economisirii asincrone, rămânând în același timp legate de configurațiile și contextul de măsurare descris în postare.
Postarea spune că comparația exclude timpul de stocare în rețea al lui torch.save. Această calificare definește ceea ce acoperă și ce nu acoperă comparația de timp raportată. Prin urmare, recomandarea este mai amplă decât o singură cifră de viteză: punctele de control distribuite, salvarea în fundal, recuperarea automată, punerea în scenă locală, stocarea în cache și preluarea preliminară sunt prezentate ca părți conexe ale designului rezilienței. Împreună, detaliile arată modul în care Databricks conectează mecanicii punctelor de control cu problema practică de a menține în mișcare un job de formare mare după întreruperi sau livrare lentă a intrării, fără a modifica măsurătorile raportate în sursă.
Detalii sursa: databricks.com ↗
De ce contează
Sesiunile mari de antrenament AI pot pierde timp substanțial de accelerare atunci când o lucrare eșuează, așteaptă date sau reia din locul greșit dintr-un set de date. Databricks prezintă măsurători specifice care sugerează că abordarea sa poate îmbunătăți timpul punctului de control și debitul de formare a imaginilor, deși cifrele sunt raportate de companie și depind de hardware-ul testat, volumul de lucru și calea de stocare.
Databricks identifică, de asemenea, un risc de corectitudine care poate să nu producă o defecțiune evidentă. Dacă o lucrare salvează modelul, optimizatorul și pasul de antrenament, dar nu și poziția încărctorului de date, o repornire poate repeta exemplele deja văzute și să omite exemplele care nu au fost încă procesate. Postarea spune că repornirile repetate pot modifica, în consecință, distribuția efectivă a datelor fără a produce o eroare. Preocuparea este așadar legată de ceea ce procesează jobul reluat, nu doar dacă jobul repornește cu succes. Un punct de control poate apărea utilizabil în timp ce relația dintre starea de antrenament salvată și poziția datelor este incompletă.
Remediile sale propuse includ înregistrarea eșantioanelor sau a decalajelor fragmentelor, serializarea poziției setului de date sau verificarea punctelor de control la granițele epocii. Aceste remedii abordează informațiile despre poziție lipsă descrise în postare, făcând conducta de date parte a stării recuperabile. Alegerea dintre ele rămâne în ghidul de implementare prezentat de Databricks, iar cerința de bază este ca un loc de muncă reluat să păstreze relația dorită între progresul instruirii și progresul setului de date. Acesta este motivul pentru care postarea tratează punctul de control al conductei de date ca parte a corectitudinii recuperării, mai degrabă decât ca un detaliu opțional de performanță.
Mai mult, se spune că semințele de amestecare și creștere și stările generatoare de numere aleatoare trebuie salvate, astfel încât ordinea reluată a datelor să rămână reproductibilă. Salvarea acestor stări extinde punctul de control dincolo de greutățile modelului, informațiile de optimizare și pasul de antrenament. În cadrul sursei, reproductibilitatea depinde de păstrarea poziției încărctorului de date împreună cu starea care guvernează ordonarea și creșterea. Implicația practică este că recuperarea trebuie evaluată atât pentru continuitate, cât și pentru corectitudine: jobul trebuie să revină la o stare utilizabilă, iar procesarea reluată trebuie să reflecte starea care a fost intenționată să fie salvată.
Mecanism interactiv: cum funcționează de fapt
Explorați tehnologia care stau la baza acestei dezvoltări în mod interactiv.
crm_get_transaction(id='4092').Which component of an AI application is the machine-learning model itself?
Ce să urmărești în continuare
Urmărirea importantă este dacă aceste rezultate se mențin în afara configurațiilor declarate de Databricks și dacă API-urile sunt disponibile pe scară largă cu compatibilitate clară, prețuri și îndrumări operaționale. Utilizatorii ar trebui, de asemenea, să caute teste independente de corectitudine a recuperării, durabilitatea punctelor de control, redimensionarea clusterului și păstrarea ordinii datelor, nu doar rulări mai rapide ale -ului.
Databricks spune că DataLoader-ul său înregistrează fetch_seconds în MLflow, oferind operatorilor o modalitate de a identifica loturile care lasă GPU-urile în așteptare. Această măsurătoare ar putea face sistemul mai ușor de diagnosticat, dar ea însăși nu stabilește un cost total mai mic sau o calitate mai bună a modelului. Oferă o observație despre timpul de preluare și posibila așteptare GPU, în timp ce rezultatul mai mare depinde de restul căii de antrenament și stocare. Prin urmare, metrica este utilă ca semnal operațional în cadrul sistemului propus, dar nu este prezentată ca o măsură completă a valorii sistemului.
Utilizatorii vor avea nevoie de contabilitate end-to-end care să includă capacitatea NVMe locală, încălzirea cache-ului, transferul de rețea, taxele de stocare, frecvența lucrărilor eșuate și costul de calcul al oricăror date de antrenament duplicate sau modificate. Aceste considerații leagă discuția privind performanța cu problema corectitudinii descrisă mai sus. Activitatea mai rapidă a punctelor de control sau întârzierile de intrare mai vizibile nu ar rezolva, prin ele însele, întrebările despre resurse, comportamentul de recuperare și manipularea datelor. Contabilitatea solicitată ar trebui, în consecință, să acopere întregul flux de lucru reprezentat în sursă, inclusiv costurile și efectele care se află în afara intervalelor de referință individuale.
Sursa oferă o teză operațională puternică și îndrumări utile pentru implementare, lăsând în același timp acele comparații mai ample necunoscute. Urmărirea importantă este, prin urmare, să examinăm configurațiile declarate, disponibilitatea și condițiile de funcționare alături de măsurătorile raportate. Utilizatorii ar trebui să caute teste independente de corectitudine a recuperării, durabilitatea punctelor de control, redimensionarea clusterului și păstrarea ordinii datelor, nu doar rulări mai rapide ale -ului. Aceste verificări ar ajuta la stabilirea dacă API-urile descrise oferă același comportament dincolo de configurațiile raportate de Databricks, păstrând în același timp incertitudinile identificate în sursă.