Baseten gør Serverless Loops generelt tilgængelig til eftertræning

Baseten annoncerede den 6. november 2026, at Serverless Loops nu er generelt tilgængelig, og åbner dermed sin administrerede SDK til superviseret finjustering og forstærkningslæring på åbne modeller for alle. Tjenesten fakturerer pr. træningstoken og giver en direkte vej fra checkpoints til Baseten Dedicated Inference.

Loops bygger på en arbejdsdeling: Brugerne leverer træningssignalet, mens Baseten driver GPU’er, kerner, modelarkitekturer og backend til distribueret træning. Med Python SDK trænes LoRA-adaptere, mens grundmodellens vægte forbliver låste. Brugerne vælger grundmodel, LoRA-rang, læringsrate, tabsfunktion, data eller miljø samt algoritme; Baseten står for træneren, sampleren, vægtsynkroniseringen og den understøttende infrastruktur.

En kompatibilitetspakke bevarer Tinker-importer og centrale kald til træning og sampling for teams, der migrerer eksisterende scripts. Migreringsvejledningen ændrer dog stadig godkendelsen til en Baseten API-nøgle, returnerer checkpoints som sideinddelte fil-URL’er, kræver indlejrede billedinput og fastlægger, hvilke LoRA-moduler der dækkes, for hver modelfamilie. Kompatibiliteten omfatter trænings-API’et, men lader teams tilpasse flere infrastrukturspecifikke detaljer.

Serverløse modeller og fakturering

Det serverløse modelkatalog indeholder tre modeller: Qwen/Qwen3.6-35B-A3B og zai-org/GLM-5.3-Flash til tekst og syn, og zai-org/GLM-5.3 til kun tekst. Hver model understøtter en maksimal sekvenslængde på 262.144 tokens. GLM-5.3’s konfiguration med lang kontekst understøtter ikke cross_entropy eller dpo tabsfunktioner. Dedikeret tilstand dækker det bredere modelkatalog, fakturerer for GPU-tid og giver mulighed for at styre replikaer, genbrug af opvarmede ressourcer og kapacitet på spotmarkedet.

Serverløse kørsler bruger delt kapacitet uden krav om GPU-reservationer og fakturerer for de tokens, der bruges til træning og sampling. Tid brugt på at læse resultater, ændre en belønningsfunktion eller vente inaktivt udløser ingen tokengebyrer. Standardvalget af tilstand kan skifte til dedikeret kapacitet, hvis en model, LoRA-rang eller sekvenslængde ikke understøttes, eller hvis en kørsel genbruger en anden kørsels udrulninger. Hvis omfanget sættes til serverløst, mislykkes en anmodning, der ikke understøttes.

At en model er aktiveret, er ingen garanti for, at den kan klargøres. Adgang, der er specifik for arbejdsområdet, utilgængelige GPU’er og organisationens begrænsninger for trænere kan stadig forhindre en kørsel og sætter dermed praktiske grænser for modellen med betaling pr. token ud over det offentliggjorte katalog.

Checkpoints og inferens i produktion

Hurtigstarten viser fire centrale handlinger: forward_backward til arbejde med tab og gradienter, optim_step til opdatering af adaptere, sample til generering og save_state til træning, der kan genoptages. Når samplerens vægte offentliggøres, oprettes et checkpoint, der kan udrulles, samt en samplingklient, der er knyttet til det. En separat save_state handling bevarer model- og optimeringstilstanden. Den første samplinganmodning kan tage flere minutter, mens den serverløse kapacitet starter op, hvilket er værd at tage højde for ved korte eksperimenter.

Et sampler-checkpoint udrulles som grundmodellen med den trænede LoRA-adapter indlæst. Checkpoints overlever deres kørsler og kan udrulles via CLI, REST API eller betjeningspanelet ved hjælp af et adgangstoken fra Hugging Face, fordi udrulningen henter grundmodellens vægte. Det resulterende OpenAI-kompatible slutpunkt fakturerer for sin GPU, så længe det er aktivt. Hvis udrulningen slettes, stopper GPU-betalingen, uden at checkpointet slettes; deaktivering af Loops-kørslen fjerner ikke udrulningen.

I forbindelse med den generelle tilgængeliggørelse forbedrede Baseten håndteringen af forbigående netværksfejl og GPU-fejl, reducerede opstartstiden og fremskyndede overførsler af vægte mellem trænere og samplere. Baseten oplyser, at ændringerne understøtter flere samtidige kundearbejdsbelastninger, og at virksomhedens inferensstak i produktion håndterer mere end 15 milliarder anmodninger dagligt. Produktionsforløbet omfatter automatisk skalering, styring af udrulninger og inferensmålinger, og brugerne kan downloade vægte i Hugging Face Safetensors-format.

Validering og tidlige kundearbejdsbelastninger

Baseten oplyser, at virksomheden validerede tjenesten med numeriske tests og end-to-end-eksperimenter med forstærkningslæring, hvor τ-bench-opgaver inden for detailhandel, luftfart og bankvæsen blev fulgt op af evaluering på vanskelige opgaver, der ikke indgik i træningen. τ-bench-projektet beskriver et benchmark, der undersøger, om agenter kan føre samtaler med brugere, kalde værktøjer, hente viden og følge politikker på tværs af erhvervsområder, hvor resultaterne kontrolleres mod verificerbare data fra databaser.

Baseten oplyser, at NVIDIA eftertrænede Nemotron Super 3.5 VL til tekst- og synsopgaver, hvilket forbedrede nøjagtigheden af intent-klassificering fra 76,8 % til 94 % og gav en validerings-F1-score på 87 % ved udtræk af kvitteringsdata; arbejdet omfattede også forstærkningslæring til optælling af visuelle objekter. Datadog bruger agentbaseret forstærkningslæring i flere runder til at afprøve træningsidéer for sin SRE-agent, og Ambience Healthcare eftertrænede modeller til at rette fejl i klinisk transskription og gengive medicinsk terminologi og formatering korrekt.

LangChain Labs eftertræner modeller på agentspor til LangSmith Engine. Arbejdet omfatter blandt andet at læse et GitHub-arkiv for at diagnosticere et problem og udarbejde et forslag til en prompt eller kodeændring til en pull request. Systemet kan skifte til en mindre model med åbne vægte for at klassificere spor efter fejltype og alvorlighed eller knytte dem til eksisterende problemer. LangChains arbejdsgang viser, hvordan applikationens adfærd bliver målet for træningen, mens modellens størrelse og specialisering til opgaven vælges ud fra det konkrete behov.

Kundernes beskrivelser dokumenterer brug før annonceringen af den generelle tilgængelighed og viser det tilsigtede infrastrukturløb: Applikationsdata bliver til træningsinput, checkpoints evalueres, og udvalgte modeller bevæger sig mod produktion. For infrastrukturteams er omkostningsgrænsen lige så tydelig. Understøttede serverløse kørsler kræver hverken reservation af GPU’er eller betaling for tokens i inaktive perioder, mens et aktivt inferensendepunkt fortsat fakturerer for sin GPU. Det serverløse katalog og kapaciteten i arbejdsområdet afgør, hvor den serverløse løsning kan anvendes.