Baseten face disponibilă pe scară largă platforma Serverless Loops pentru post-antrenare

Baseten a anunțat pe 6 noiembrie 2026 că Serverless Loops este disponibilă pe scară largă, deschizând tuturor accesul la SDK-ul său gestionat pentru ajustarea fină supravegheată și învățarea prin consolidare pe modele cu ponderi deschise. Serviciul facturează antrenarea în funcție de numărul de tokenuri și oferă o cale directă de la punctele de control la Baseten Dedicated Inference.

Loops se bazează pe o împărțire a responsabilităților: utilizatorii furnizează semnalul de antrenare, iar Baseten gestionează GPU-urile, nucleele, arhitecturile modelelor și infrastructura de antrenare distribuită. SDK-ul Python antrenează adaptoare LoRA cu ponderile modelului de bază înghețate. Utilizatorii aleg modelul de bază, rangul LoRA, rata de învățare, funcția de pierdere, datele sau mediul și algoritmul; Baseten gestionează antrenorul, eșantionatorul, sincronizarea ponderilor și infrastructura de suport.

Un pachet de compatibilitate păstrează importurile Tinker și apelurile de bază pentru antrenare și eșantionare, pentru echipele care migrează scripturi existente. Ghidul de migrare schimbă totuși metoda de autentificare, care va folosi o cheie API Baseten, returnează punctele de control sub formă de URL-uri paginate către fișiere, impune furnizarea inline a imaginilor și stabilește acoperirea modulelor LoRA în funcție de familia de modele. Compatibilitatea acoperă API-ul de antrenare, lăsând echipelor să ajusteze mai multe detalii specifice infrastructurii.

Modele serverless și facturare

Catalogul serverless cuprinde trei modele: Qwen/Qwen3.6-35B-A3B și zai-org/GLM-5.3-Flash pentru text și viziune, iar zai-org/GLM-5.3 doar pentru text. Fiecare acceptă o lungime maximă a secvenței de 262.144 de tokenuri. Configurația cu context lung a modelului GLM-5.3 nu acceptă cross_entropy sau dpo funcții de pierdere. Modul dedicat acoperă un catalog mai larg de modele, facturează timpul de utilizare a GPU-ului și oferă controale pentru replici, reutilizare la cald și capacitatea spot.

Execuțiile serverless folosesc capacitate partajată fără a necesita rezervări de GPU și facturează tokenurile utilizate la antrenare și eșantionare. Timpul petrecut pentru consultarea rezultatelor, modificarea unei funcții de recompensă sau așteptarea fără activitate nu este taxat în tokenuri. Selectarea implicită a modului poate reveni la capacitatea dedicată dacă modelul, rangul LoRA sau lungimea secvenței nu sunt acceptate ori dacă o execuție reutilizează implementările altei execuții. Setarea domeniului la serverless face ca o solicitare neacceptată să eșueze în schimb.

Activarea unui model nu garantează alocarea resurselor. Accesul specific spațiului de lucru, GPU-urile indisponibile și limitele organizației privind antrenorii pot împiedica în continuare o execuție, ceea ce stabilește limite practice de capacitate pentru modelul de plată per token, dincolo de catalogul publicat.

Puncte de control și inferență în producție

Ghidul de pornire rapidă prezintă patru operațiuni de bază: forward_backward pentru calcularea pierderii și a gradientului, optim_step pentru actualizarea adaptorului, sample pentru generare și save_state pentru antrenare reluabilă. Publicarea ponderilor eșantionatorului creează un punct de control care poate fi implementat și un client de eșantionare fixat la acesta. O operațiune separată save_state păstrează starea modelului și a optimizatorului. Prima solicitare de eșantionare poate dura câteva minute, cât timp pornește capacitatea serverless, un aspect practic de luat în calcul pentru experimentele de scurtă durată.

Un punct de control al eșantionatorului este implementat ca model de bază, cu adaptorul LoRA antrenat încărcat. Punctele de control rămân disponibile după încheierea execuțiilor și pot fi implementate prin CLI, API-ul REST sau tabloul de bord, folosind un token de acces Hugging Face, deoarece implementarea descarcă ponderile modelului de bază. Cât timp este activ, punctul final compatibil cu OpenAI facturează utilizarea GPU-ului. Ștergerea acelei implementări oprește costurile pentru GPU fără a șterge punctul de control; dezactivarea execuției Loops nu elimină implementarea.

Pentru disponibilitatea generală, Baseten a îmbunătățit gestionarea erorilor temporare de rețea și a defecțiunilor GPU, a redus timpul suplimentar de pornire și a accelerat transferurile de ponderi între antrenori și eșantionatori. Baseten afirmă că aceste modificări permit gestionarea simultană a mai multor sarcini ale clienților și că infrastructura sa de inferență pentru producție deservește zilnic peste 15 miliarde de solicitări. Fluxul de producție include scalare automată, gestionarea implementărilor și indicatori de inferență, iar utilizatorii pot descărca ponderile în formatul Safetensors de la Hugging Face.

Validare și primele sarcini ale clienților

Baseten afirmă că a validat serviciul prin teste numerice și experimente de învățare prin consolidare de la un capăt la altul, folosind sarcini τ-bench din domeniile comerțului cu amănuntul, transportului aerian și serviciilor bancare, urmate de evaluări pe sarcini dificile păstrate separat. Proiectul τ-bench descrie un test comparativ care evaluează dacă agenții pot purta conversații cu utilizatorii, apela instrumente, recupera informații și respecta politici în diferite domenii de activitate, rezultatele fiind verificate în raport cu date verificabile din baze de date.

Baseten relatează că NVIDIA a post-antrenat modelul Nemotron Super 3.5 VL pentru sarcini de text și viziune, îmbunătățind acuratețea clasificării intențiilor de la 76,8% la 94% și obținând un scor F1 de validare de 87% la extragerea informațiilor de pe bonuri; activitatea a inclus și învățare prin consolidare pentru numărarea obiectelor vizuale. Datadog folosește învățarea prin consolidare agentică în mai multe runde pentru a testa idei de antrenare destinate agentului său SRE, iar Ambience Healthcare a post-antrenat modele pentru a corecta erorile de transcriere clinică și a reda cu acuratețe terminologia și formatarea medicală.

LangChain Labs antrenează ulterior modelele folosind traseele agenților pentru LangSmith Engine, inclusiv pentru activități în care un agent citește un depozit GitHub pentru a diagnostica o problemă și redactează solicitarea de modificare a promptului sau a codului pentru o cerere de integrare. Poate trece la un model mai mic, cu ponderi deschise, pentru a clasifica traseele după tipul și gravitatea erorii sau pentru a le asocia problemelor existente. Fluxul de lucru al LangChain arată cum comportamentul aplicației devine ținta antrenării, iar dimensiunea modelului și specializarea sarcinii sunt alese în funcție de activitatea respectivă.

Conturile clienților documentează utilizarea anterioară anunțului privind disponibilitatea generală și arată bucla de infrastructură avută în vedere: datele aplicației devin date de intrare pentru antrenare, punctele de control sunt evaluate, iar modelele selectate avansează spre producție. Pentru echipele de infrastructură, limita de cost este la fel de clară. Execuțiile serverless acceptate evită rezervările de GPU și costurile pentru tokenii generați în perioadele de inactivitate, în timp ce un punct final de inferență activ continuă să factureze utilizarea GPU-ului; catalogul serverless și capacitatea spațiului de lucru determină unde se aplică opțiunea serverless.