Baseten gör Serverless Loops allmänt tillgängligt för efterträning

Baseten meddelade den 6 november 2026 att Serverless Loops är allmänt tillgängligt, vilket öppnar företagets hanterade SDK för övervakad finjustering och förstärkningsinlärning av öppna modeller för alla. Tjänsten debiterar per token under träningen och ger en direkt väg från kontrollpunkter till Baseten Dedicated Inference.

Loops bygger på en arbetsfördelning: användarna tillhandahåller träningssignalen, medan Baseten hanterar GPU:erna, kärnorna, modellarkitekturerna och infrastrukturen för distribuerad träning. Python SDK tränar LoRA-adaptrar med basmodellens vikter frysta. Användarna väljer basmodell, LoRA-rang, inlärningshastighet, förlustfunktion, data eller miljö och algoritm; Baseten kör tränaren, samplaren, viktsynkroniseringen och den stödjande infrastrukturen.

Ett kompatibilitetspaket bevarar Tinker-importer och grundläggande anrop för träning och sampling för team som flyttar över befintliga skript. Migreringsguiden ändrar fortfarande autentiseringen till en Baseten API-nyckel, returnerar kontrollpunkter som paginerade fil-URL:er, kräver bildinmatning direkt i anropet och fastställer vilka LoRA-moduler som omfattas för varje modellfamilj. Kompatibiliteten täcker tränings-API:t, men lämnar flera infrastrukturspecifika detaljer som teamen behöver anpassa.

Serverlösa modeller och fakturering

Katalogen med serverlösa modeller innehåller tre modeller: Qwen/Qwen3.6-35B-A3B och zai-org/GLM-5.3-Flash för text och bild, och zai-org/GLM-5.3 för enbart text. Varje modell stöder en maximal sekvenslängd på 262 144 token. GLM-5.3:s konfiguration för lång kontext stöder inte cross_entropy eller dpo förluster. Dedikerat läge omfattar den bredare modellkatalogen, debiterar för GPU-tid och ger fler kontroller för repliker, återanvändning av varma instanser och spotkapacitet.

Serverlösa körningar använder delad kapacitet utan krav på GPU-reserveringar och debiteras för de token som används vid träning och sampling. Tid som läggs på att läsa resultat, ändra en belöningsfunktion eller vänta utan att arbeta medför inga tokendebiteringar. Det automatiska lägesvalet kan växla till dedikerad kapacitet om en modell, LoRA-rang eller sekvenslängd inte stöds, eller om en körning återanvänder en annan körnings driftsättningar. Om omfånget ställs in på serverlöst misslyckas i stället en begäran som inte stöds.

Att en modell är aktiverad garanterar inte att resurser kan tilldelas. Åtkomst som är specifik för en arbetsyta, otillgängliga GPU:er och organisationens begränsningar för tränare kan fortfarande hindra en körning, vilket innebär att modellen med betalning per token har praktiska kapacitetsgränser utöver den publicerade katalogen.

Kontrollpunkter och inferens i produktion

Snabbstarten visar fyra grundläggande åtgärder: forward_backward för arbete med förlust och gradienter, optim_step för uppdatering av adaptrar, sample för generering och save_state för träning som kan återupptas. När samplarens vikter publiceras skapas en driftsättningsbar kontrollpunkt och en samplingsklient som är låst till den. En separat save_state åtgärd bevarar modellens och optimerarens tillstånd. Den första samplingsbegäran kan ta flera minuter medan den serverlösa kapaciteten startar, vilket är värt att beakta vid korta experiment.

En samplarkontrollpunkt driftsätts som basmodellen med den tränade LoRA-adaptern inläst. Kontrollpunkter finns kvar när körningarna har avslutats och kan driftsättas via CLI, REST API eller kontrollpanelen med en åtkomsttoken från Hugging Face, eftersom driftsättningen hämtar basvikterna. Den resulterande OpenAI-kompatibla slutpunkten debiteras för GPU:n så länge den är aktiv. Om driftsättningen tas bort upphör GPU-debiteringen utan att kontrollpunkten raderas; om Loops-körningen inaktiveras tas driftsättningen inte bort.

Inför den allmänna tillgängligheten förbättrade Baseten hanteringen av tillfälliga nätverksfel och GPU-fel, minskade startkostnaderna och snabbade upp viktöverföringarna mellan tränare och samplare. Baseten uppger att ändringarna gör det möjligt att hantera fler samtidiga kundarbetsbelastningar och att företagets inferensstack i produktion hanterar mer än 15 miljarder förfrågningar per dag. Produktionslösningen omfattar automatisk skalning, hantering av driftsättningar och inferensmätvärden, och användarna kan ladda ner vikter i Hugging Face Safetensors-format.

Validering och tidiga kundarbetsbelastningar

Baseten uppger att företaget validerade tjänsten med numeriska tester och förstärkningsinlärningsexperiment från början till slut, där uppgifter från τ-bench användes inom detaljhandel, flyg och bankverksamhet. Därefter utvärderades den på svåra uppgifter som inte ingick i träningen. τ-bench-projektet beskriver ett riktmärke för att bedöma om agenter kan samtala med användare, anropa verktyg, hämta kunskap och följa policyer inom olika företagsområden, med resultat som kontrolleras mot verifierbara databasresultat.

Baseten uppger att NVIDIA eftertränade Nemotron Super 3.5 VL på text- och bilduppgifter, vilket förbättrade träffsäkerheten för avsiktsklassificering från 76,8 % till 94 % och gav ett validerings-F1-värde på 87 % för kvittoextraktion. Arbetet omfattade också förstärkningsinlärning för visuell objekträkning. Datadog använder flerstegs agentisk RL för att testa träningsidéer för sin SRE-agent, och Ambience Healthcare eftertränade modeller för att korrigera fel i klinisk transkribering och återge medicinsk terminologi och formatering korrekt.

LangChain Labs eftertränar modeller på agentspår för LangSmith Engine. Arbetet omfattar bland annat att läsa ett GitHub-arkiv för att diagnostisera ett problem och ta fram ett utkast till prompten eller kodändringen för en pull request. Tjänsten kan växla till en mindre modell med öppna vikter för att klassificera spår efter felläge och allvarlighetsgrad eller koppla dem till befintliga ärenden. LangChains arbetsflöde visar hur applikationens beteende blir målet för träningen och hur modellstorlek och specialisering väljs utifrån uppgiften.

Kundberättelserna dokumenterar användning före tillkännagivandet om allmän tillgänglighet och visar det avsedda infrastrukturflödet: applikationsdata blir träningsunderlag, kontrollpunkter utvärderas och utvalda modeller förs vidare mot produktion. För infrastrukturteam är kostnadsgränsen lika tydlig. Serverlösa körningar som stöds kräver varken reserverad GPU-kapacitet eller tokenavgifter för inaktiv tid, medan en aktiv inferensslutpunkt fortsätter att debiteras för sin GPU. Serverlöskatalogen och arbetsytans kapacitet avgör var det serverlösa alternativet kan användas.