Baseten gjør Serverless Loops allment tilgjengelig for ettertrening

Baseten kunngjorde 6. november 2026 at Serverless Loops er allment tilgjengelig, og åpner dermed sin administrerte SDK for veiledet finjustering og forsterkningslæring på åpne modeller for alle. Tjenesten fakturerer trening per token og gir en direkte vei fra kontrollpunkter til Baseten Dedicated Inference.

Loops bygger på en arbeidsdeling: Brukerne leverer treningssignalet, mens Baseten drifter GPU-ene, kjernene, modellarkitekturene og infrastrukturen for distribuert trening. Python-SDK-en trener LoRA-adaptere mens vektene i grunnmodellen holdes frosset. Brukerne velger grunnmodell, LoRA-rang, læringsrate, tapsfunksjon, data eller miljø og algoritme; Baseten kjører treneren og sampleren og håndterer vektsynkronisering og tilhørende infrastruktur.

En kompatibilitetspakke bevarer Tinker-importer og sentrale kall for trening og sampling for team som migrerer eksisterende skript. Migreringsveiledningen endrer likevel autentiseringen til en Baseten API-nøkkel, returnerer kontrollpunkter som paginerte fil-URL-er, krever bildeb输入data direkte i kallet og fastsetter LoRA-moduldekningen for hver modellfamilie. Kompatibiliteten omfatter trenings-API-et, men lar teamene selv justere flere infrastruktursærskilte detaljer.

Serverløse modeller og fakturering

Katalogen over serverløse modeller inneholder tre modeller: Qwen/Qwen3.6-35B-A3B og zai-org/GLM-5.3-Flash for tekst og bilder, og zai-org/GLM-5.3 for bare tekst. Hver modell støtter en maksimal sekvenslengde på 262 144 token. Langkontekstkonfigurasjonen til GLM-5.3 støtter ikke cross_entropy eller dpo tap. Dedikert modus dekker den bredere modellkatalogen, fakturerer GPU-tid og gir kontroll over replikaer, gjenbruk av oppvarmede instanser og spotkapasitet.

Serverløse kjøringer bruker delt kapasitet uten krav om GPU-reservasjoner og fakturerer token brukt til trening og sampling. Det påløper ingen tokenkostnader mens man leser resultater, endrer en belønningsfunksjon eller lar tjenesten stå ubrukt. Standard valg av modus kan falle tilbake på dedikert kapasitet hvis en modell, LoRA-rang eller sekvenslengde ikke støttes, eller hvis en kjøring gjenbruker distribusjoner fra en annen kjøring. Hvis omfanget settes til serverløs, mislykkes en forespørsel som ikke støttes.

At en modell er aktivert, er ingen garanti for at den kan klargjøres. Tilgang som er spesifikk for arbeidsområdet, utilgjengelige GPU-er og organisasjonens begrensninger på antall trenere kan fortsatt hindre en kjøring. Dermed har modellen med betaling per token praktiske kapasitetsgrenser utover den publiserte katalogen.

Kontrollpunkter og inferens i produksjon

Hurtigstarten viser fire kjerneoperasjoner: forward_backward for arbeid med tap og gradienter, optim_step for oppdateringer av adaptere, sample for generering og save_state for trening som kan gjenopptas. Publisering av samplerens vekter oppretter et kontrollpunkt som kan distribueres, samt en samplingklient som er låst til dette kontrollpunktet. En separat save_state operasjon bevarer modellens og optimalisatorens tilstand. Den første samplingsforespørselen kan ta flere minutter mens serverløs kapasitet starter opp, noe det er verdt å ta hensyn til ved korte eksperimenter.

Et samplerkontrollpunkt distribueres som grunnmodellen med den trente LoRA-adapteren lastet inn. Kontrollpunktene varer lenger enn kjøringene de ble opprettet i, og kan distribueres via CLI, REST API eller dashbordet ved hjelp av et Hugging Face-tilgangstoken, fordi distribusjonen laster ned vektene til grunnmodellen. Det resulterende OpenAI-kompatible endepunktet fakturerer GPU-en så lenge det er aktivt. Hvis distribusjonen slettes, stopper GPU-kostnaden uten at kontrollpunktet slettes; deaktivering av Loops-kjøringen fjerner ikke distribusjonen.

Til den generelle lanseringen forbedret Baseten håndteringen av midlertidige nettverksfeil og GPU-feil, reduserte oppstartskostnadene og økte hastigheten på vektoverføringer mellom trenere og samplere. Baseten sier at disse endringene gjør det mulig å håndtere flere samtidige kundeoppgaver, og at selskapets inferensløsning i produksjon behandler mer enn 15 milliarder forespørsler daglig. Produksjonsløsningen omfatter automatisk skalering, administrasjon av distribusjoner og inferensmålinger, og brukerne kan laste ned vekter i Hugging Face Safetensors-format.

Validering og tidlige kundearbeidsoppgaver

Baseten sier at selskapet validerte tjenesten med numeriske tester og ende-til-ende-eksperimenter med forsterkningslæring ved bruk av τ-bench-oppgaver innen detaljhandel, flyselskaper og bankvirksomhet, etterfulgt av evaluering på vanskelige oppgaver som var holdt utenfor treningen. τ-bench-prosjektet beskriver en referansetest for å undersøke om agenter kan føre samtaler med brukere, kalle verktøy, hente fram kunnskap og følge retningslinjer på tvers av bedriftsområder. Resultatene kontrolleres mot verifiserbare databaseopplysninger.

Baseten opplyser at NVIDIA ettertrente Nemotron Super 3.5 VL på tekst- og synsoppgaver, forbedret nøyaktigheten i intensjonsklassifisering fra 76,8 % til 94 % og oppnådde en validerings-F1 på 87 % for uttrekk av informasjon fra kvitteringer. Arbeidet omfattet også forsterkningslæring for visuell telling av objekter. Datadog bruker flerrunders, agentbasert forsterkningslæring til å teste treningsideer for sin SRE-agent, og Ambience Healthcare ettertrente modeller for å korrigere feil i klinisk transkripsjon og gjengi medisinsk terminologi og formatering nøyaktig.

LangChain Labs ettertrener modeller på agentspor for LangSmith Engine. Dette omfatter arbeid der en GitHub-repositorium leses for å diagnostisere et problem og utarbeide et utkast til en prompt eller kodeendring for en pull request. Arbeidsflyten kan bytte til en mindre modell med åpne vekter for å klassifisere spor etter feiltype og alvorlighetsgrad, eller knytte dem til eksisterende problemer. LangChains arbeidsflyt viser hvordan atferden i en applikasjon blir treningsmålet, og hvordan modellstørrelse og spesialisering velges ut fra oppgaven.

Kundehistoriene dokumenterer bruk før kunngjøringen om generell tilgjengelighet og viser den tiltenkte infrastruktursyklusen: Data fra applikasjonen blir treningsgrunnlag, kontrollpunkter evalueres, og utvalgte modeller tas videre mot produksjon. For infrastrukturteam er kostnadsgrensene like tydelige. Serverløse kjøringer som støttes, unngår GPU-reservasjoner og tokenkostnader for inaktiv tid, mens et aktivt inferensendepunkt fortsatt fakturerer for GPU-en det bruker. Den serverløse katalogen og kapasiteten i arbeidsområdet avgjør hvor det serverløse alternativet kan brukes.