Baseten pone Serverless Loops a disposición general para el postentrenamiento

Baseten anunció el 6 de noviembre de 2026 que Serverless Loops ya está disponible de forma general, y abrió a todo el mundo su SDK gestionado para el ajuste fino supervisado y el aprendizaje por refuerzo con modelos abiertos. El servicio cobra por token durante el entrenamiento y ofrece una vía directa desde los puntos de control hasta Baseten Dedicated Inference.

Loops se basa en una división de tareas: los usuarios aportan la señal de entrenamiento, mientras que Baseten gestiona las GPU, los kernels, las arquitecturas de modelos y el backend de entrenamiento distribuido. El SDK de Python entrena adaptadores LoRA con los pesos del modelo base congelados. Los usuarios eligen el modelo base, el rango LoRA, la tasa de aprendizaje, la función de pérdida, los datos o el entorno y el algoritmo; Baseten ejecuta el entrenador y el muestreador, sincroniza los pesos y gestiona la infraestructura de soporte.

Un paquete de compatibilidad conserva las importaciones de Tinker y las llamadas principales de entrenamiento y muestreo para los equipos que migran scripts existentes. La guía de migración todavía exige cambiar la autenticación por una clave de API de Baseten, devuelve los puntos de control como URL paginadas de archivos, requiere entradas de imagen en línea y establece la cobertura de los módulos LoRA según la familia del modelo. La compatibilidad abarca la API de entrenamiento, pero deja varios detalles específicos de la infraestructura para que los equipos los ajusten.

Modelos sin servidor y facturación

El catálogo sin servidor incluye tres modelos: Qwen/Qwen3.6-35B-A3B y zai-org/GLM-5.3-Flash para texto y visión, y zai-org/GLM-5.3 solo para texto. Cada uno admite una longitud máxima de secuencia de 262.144 tokens. La configuración de contexto largo de GLM-5.3 no admite cross_entropy o dpo pérdidas. El modo dedicado abarca un catálogo de modelos más amplio, cobra por el tiempo de uso de la GPU y añade controles para las réplicas, la reutilización en caliente y la capacidad bajo demanda.

Las ejecuciones sin servidor utilizan capacidad compartida sin exigir reservas de GPU y cobran por los tokens usados en el entrenamiento y el muestreo. El tiempo dedicado a leer resultados, cambiar una función de recompensa o permanecer inactivo no genera cargos por tokens. La selección del modo predeterminado puede recurrir a capacidad dedicada si un modelo, un rango LoRA o una longitud de secuencia no son compatibles, o si una ejecución reutiliza los despliegues de otra. En cambio, al establecer el ámbito como sin servidor, una solicitud no compatible genera un error.

Habilitar un modelo no garantiza que se aprovisione. El acceso específico del espacio de trabajo, la falta de GPU disponibles y los límites de entrenamiento de la organización aún pueden impedir una ejecución, lo que establece límites prácticos de capacidad para el modelo de pago por token que van más allá del catálogo publicado.

Puntos de control e inferencia en producción

La guía de inicio rápido presenta cuatro operaciones principales: forward_backward para calcular pérdidas y gradientes, optim_step para actualizar adaptadores, sample para generar y save_state para reanudar el entrenamiento. Publicar los pesos del muestreador crea un punto de control que se puede desplegar y un cliente de muestreo asociado a él. Una operación independiente save_state conserva el estado del modelo y del optimizador. La primera solicitud de muestreo puede tardar varios minutos mientras se inicia la capacidad sin servidor, algo que conviene tener en cuenta en experimentos breves.

Un punto de control del muestreador se despliega como modelo base con el adaptador LoRA entrenado cargado. Los puntos de control sobreviven a sus ejecuciones y pueden desplegarse mediante la CLI, la API REST o el panel de control con un token de acceso de Hugging Face, ya que el despliegue descarga los pesos base. El endpoint resultante, compatible con OpenAI, cobra por el uso de la GPU mientras está activo. Eliminar ese despliegue detiene el cargo de la GPU sin borrar el punto de control; desactivar la ejecución de Loops no elimina el despliegue.

Para la disponibilidad general, Baseten mejoró la gestión de errores transitorios de red y fallos de GPU, redujo la sobrecarga de inicio y aceleró las transferencias de pesos entre entrenadores y muestreadores. Según Baseten, esos cambios permiten atender más cargas de trabajo simultáneas de clientes, y su infraestructura de inferencia en producción procesa más de 15.000 millones de solicitudes al día. La ruta de producción incluye escalado automático, gestión de despliegues y métricas de inferencia; además, los usuarios pueden descargar los pesos en formato Safetensors de Hugging Face.

Validación y primeras cargas de trabajo de clientes

Baseten afirma que validó el servicio con pruebas numéricas y experimentos de aprendizaje por refuerzo de extremo a extremo que utilizaron tareas de τ-bench en los sectores minorista, aéreo y bancario, seguidos de una evaluación con tareas difíciles reservadas para las pruebas. El proyecto τ-bench describe un benchmark para evaluar si los agentes pueden conversar con usuarios, usar herramientas, recuperar conocimientos y seguir políticas en distintos ámbitos empresariales; los resultados se contrastan con datos verificables de bases de datos.

Baseten informa que NVIDIA realizó el postentrenamiento de Nemotron Super 3.5 VL con tareas de texto y visión, y mejoró la precisión de la clasificación de intenciones del 76,8 % al 94 %, además de alcanzar una puntuación F1 de validación del 87 % en la extracción de datos de recibos; el trabajo también incluyó aprendizaje por refuerzo para contar objetos visuales. Datadog utiliza aprendizaje por refuerzo agéntico de varios turnos para probar ideas de entrenamiento para su agente de SRE, y Ambience Healthcare realizó el postentrenamiento de modelos para corregir errores de transcripción clínica y captar con precisión la terminología y el formato médicos.

LangChain Labs entrena modelos posteriormente con trazas de agentes para LangSmith Engine. Entre otros usos, estos modelos leen un repositorio de GitHub para diagnosticar un problema y redactan el prompt o el cambio de código para una solicitud de incorporación de cambios. Pueden cambiar a un modelo más pequeño de pesos abiertos para clasificar las trazas según el tipo y la gravedad del fallo, o vincularlas con incidencias existentes. El flujo de trabajo de LangChain muestra cómo el comportamiento de una aplicación se convierte en el objetivo del entrenamiento, y cómo el tamaño del modelo y su especialización se eligen en función de la tarea.

Los relatos de los clientes documentan el uso previo al anuncio de disponibilidad general (GA) y muestran el ciclo de infraestructura previsto: los datos de la aplicación se convierten en datos de entrada para el entrenamiento, se evalúan los puntos de control y los modelos seleccionados avanzan hacia la producción. Para los equipos de infraestructura, el límite de los costos también está claro. Las ejecuciones sin servidor admitidas evitan las reservas de GPU y los cargos por tokens durante el tiempo de inactividad, mientras que un endpoint de inferencia activo sigue generando cargos por su GPU; el catálogo sin servidor y la capacidad del espacio de trabajo determinan dónde se aplica la opción sin servidor.