AISubHub/Noticias de IA
Desarrolladores

Análisis en profundidad · Unos 4 min de lectura

Laplace 3B en Trainium2: estado fijo no significa memoria perfecta

El informe de i14 y AWS separa ahorro de estado, comunicación del optimizador y costes de compilación.

Publicado aquí
Fecha de la fuente
Fuente revisada

Un artículo de AWS del 20 de octubre explica el entrenamiento y servicio de Laplace 3B de i14 mediante PyTorch nativo en Trainium2. La diferencia arquitectónica es un estado recurrente fijo frente a una caché KV que crece con el contexto. Interesa identificar qué límite cambia y qué preguntas de calidad y operación siguen abiertas.

Escucha las noticias

Escucha este artículo o continúa con las noticias.

Laplace 3B en Trainium2: estado fijo no significa memoria perfecta

Preparando la lectura…

Voz del dispositivo

El navegador o dispositivo procesa la voz. AISubHub no envía el texto a una API de audio. Las voces y la reproducción con pantalla bloqueada dependen del dispositivo.

Al continuar puede repetirse una frase breve.

Resumen

  • Se informan 29.5 MB de estado por secuencia y 11544 tokens de salida por segundo agregados entre 1280 secuencias en una trn2.48xlarge; no son memoria total ni velocidad por usuario.
  • La receta apunta a 100 mil millones de tokens, pero el resultado descrito llega a unos 44 mil millones. Reducir comunicación 24 veces no equivale a la mejora de rendimiento de 1.63 veces.

La historia se comprime, no se conserva sin pérdida

La atención softmax suele guardar claves y valores crecientes durante inferencia. Laplace 3B actualiza una matriz recurrente con Gated Linear Attention y comprime el pasado en 29.5 MB por secuencia. El cálculo de atención durante entrenamiento pasa de crecimiento cuadrático a lineal con la longitud. Eso no elimina pesos, activaciones, procesamiento de entrada ni otros búferes. Además, la compresión cambia qué información se recupera. La fuente pide evaluar recuperación según la carga: que una conversación quepa en memoria no demuestra que todos sus detalles antiguos sobrevivan con la precisión necesaria.

La adaptación al chip y la comunicación son mejoras distintas

El equipo sustituyó un kernel Triton específico de GPU por operadores PyTorch. Dieciséis bloques de 128 tokens encajan con 128 particiones del búfer; el informe atribuye a esa alineación una mejora del 14%. Muon afrontaba otro problema: gradientes repartidos necesitaban información entre fragmentos. Dos intercambios all-to-all distribuyen matrices completas y devuelven resultados. El tráfico por rango baja de 10.87 GB a 0.45 GB, mientras el rendimiento sube de 73378 a 119934 tokens por segundo. La reducción de tráfico de 24 veces no debe venderse como aceleración de entrenamiento de 24 veces.

El plan no es el resultado completado

La configuración describe 3.028 mil millones de parámetros, 24 capas y una receta FineWeb-Edu de 100 mil millones de tokens. Los gráficos llegan al paso 84210, unos 44 mil millones de tokens, no a los 190735 pasos planeados. Los aproximadamente 120000 tokens por segundo y la pérdida descendente pertenecen a ese tramo. La estabilidad ayuda a valorar la implementación, pero no prueba calidad en aplicaciones, superioridad frente a todo transformer ni recuerdo factual. Nuestra lectura separa la adaptación del sistema de la utilidad que aún debe demostrarse en una tarea concreta.

El rendimiento total depende de la concurrencia

La inferencia usa una trn2.48xlarge con 64 NeuronCores lógicos, 20 secuencias por réplica y 1280 en total. Los 11544 tokens de salida por segundo se comparten entre esa carga. El estado aproximadamente 82 veces menor se compara con una caché KV equivalente a 8192 tokens, no con la factura completa. Ampliar entradas de 2048 a 8192 tokens añadió 0.5% al coste por token de salida en ese experimento. Procesamiento de entrada, asignación de hardware, calidad y utilización siguen contando en cualquier presupuesto real.

Las llegadas reales exponen compilaciones ocultas

Cada ancho nuevo de lote de decodificación costó inicialmente unos 11 segundos de compilación. Esos pasos eran solo 1.1% del total, pero consumieron 47.5% del tiempo de decodificación. El relleno a anchos fijos eliminó ese coste, y las mejoras con llegadas escalonadas difirieron de los lotes fijos. La fuente también advierte que reasociaciones BF16 pueden cambiar ligeramente la salida compilada frente a eager; para reproducción exacta propone eager. Un piloto debería combinar llegadas reales, colas de latencia, tolerancia numérica y recuperación de información. Son recomendaciones nuestras, no ahorros o servicio desplegado por AISubHub.

Por qué importa

Nuestro análisis: el estado fijo facilita planificar sesiones largas, pero exige probar recuperación de información y llegadas realistas. Arquitectura y ejecución deben evaluarse juntas.

Límites y disponibilidad

Leímos texto y pies de figuras sin ejecutar código. Los resultados pertenecen al proyecto i14/AWS, no a pruebas nuestras. No establecen precio de suscripción, hardware gratuito, superioridad universal ni garantía de producción. TorchNeuron Native se utilizó en beta.

Fuentes y pruebas

AWS · i14 Laplace 3B engineering report

Fecha de la fuente: · Fuente revisada:

Contenido editorial asistido por IA y contrastado con fuentes primarias. Las afirmaciones del proveedor se atribuyen; la inclusión no implica recomendación.