Analyse approfondie · Environ 4 min de lecture
Laplace 3B sur Trainium2 : un état fixe ne garantit pas une mémoire parfaite
Le retour i14/AWS distingue état récurrent, communication de l’optimiseur et compilation sous trafic réel.
- Publié ici
- Date de la source
- Source vérifiée
Un article AWS du 20 octobre décrit l’entraînement et le service de Laplace 3B d’i14 sur Trainium2 avec PyTorch natif. Son état récurrent fixe remplace un cache KV croissant. L’enjeu est de comprendre quelle contrainte change, sans oublier qualité, compilation et conditions de déploiement.
Écouter les actualités
Écoutez cet article ou poursuivez la lecture des actualités.
Préparation de la lecture…
Voix de l’appareil
La voix est traitée par votre navigateur ou appareil. AISubHub n’envoie pas le texte à une API audio. Les voix et la lecture écran verrouillé dépendent de l’appareil.
La reprise peut répéter une courte phrase.
En bref
- Le rapport donne 29.5 MB d’état par séquence et 11544 tokens de sortie par seconde agrégés sur 1280 séquences dans une trn2.48xlarge : ni mémoire totale ni débit par utilisateur.
- La recette vise 100 milliards de tokens, mais les résultats concernent environ 44 milliards. Communication divisée par 24 et débit multiplié par 1.63 sont deux mesures.
Un historique comprimé, pas une mémoire sans perte
L’inférence softmax conserve habituellement des clés et valeurs dont la taille augmente. Laplace 3B actualise une matrice récurrente par Gated Linear Attention et comprime l’historique en 29.5 MB par séquence. Le calcul d’attention à l’entraînement devient linéaire plutôt que quadratique en longueur. Cela n’efface pas poids, activations, traitement des entrées et autres tampons. La compression change aussi ce qui reste récupérable. La source demande explicitement d’évaluer le rappel sur la charge visée : faire tenir une longue conversation ne prouve pas que chaque ancien détail reste accessible avec la précision nécessaire.
Deux optimisations aux effets différents
L’équipe remplace un noyau Triton spécifique aux GPU par des opérateurs PyTorch. Seize blocs de 128 tokens s’alignent sur les 128 partitions du tampon ; le rapport y attribue un gain de 14%. Muon rencontrait une autre difficulté : les gradients partitionnés nécessitent des relations entre fragments. Deux échanges all-to-all distribuent des matrices complètes puis rapportent les résultats. Le trafic par rang passe de 10.87 GB à 0.45 GB, le débit de 73378 à 119934 tokens par seconde. Une communication divisée par 24 ne signifie pas un entraînement 24 fois plus rapide.
Distinguer recette et entraînement accompli
La configuration comporte 3.028 milliards de paramètres, 24 couches et une recette FineWeb-Edu de 100 milliards de tokens. Les résultats s’arrêtent toutefois au pas 84210, soit environ 44 milliards, pas aux 190735 pas prévus. Les quelque 120000 tokens par seconde et la baisse de perte concernent cet intervalle. La stabilité renseigne sur l’implémentation, pas sur toutes les applications, tous les transformers ou le rappel factuel. Notre lecture sépare donc la réussite du portage et l’utilité du modèle qui doit encore être démontrée sur une tâche concrète.
Un débit agrégé avec des hypothèses précises
Le test utilise une trn2.48xlarge, 64 NeuronCores logiques et 20 séquences par réplique, soit 1280 au total. Le débit de 11544 tokens de sortie par seconde est partagé entre elles. L’état environ 82 fois plus petit est comparé à un cache KV équivalent à 8192 tokens, pas à la facture complète. Passer de 2048 à 8192 tokens d’entrée n’ajoute que 0.5% au coût par token de sortie dans cette expérience. Traitement d’entrée, allocation matérielle, qualité et utilisation restent des facteurs du budget réel.
Les arrivées variables dévoilent la compilation
Chaque nouvelle largeur de lot de décodage exigeait initialement environ 11 secondes de compilation. Ces étapes n’étaient que 1.1% du total, mais prenaient 47.5% du temps de décodage. Un remplissage à largeurs fixes a supprimé ce coût ; les gains sous arrivées décalées différaient des lots fixes. La source avertit aussi que la réassociation BF16 peut produire de petites différences entre mode compilé et eager, à privilégier pour une reproduction exacte. Un pilote devrait tester arrivées réelles, latences extrêmes, tolérance numérique et rappel. Ce sont nos recommandations, pas un service ou des économies mesurées par AISubHub.
Pourquoi cela compte
Notre analyse : un état fixe facilite la planification des longues sessions, mais exige des tests de rappel et d’arrivées réalistes. Architecture et exécution doivent être évaluées ensemble.
Limites et disponibilité
Nous avons lu tout le texte et les légendes sans exécuter le code. Les résultats sont ceux d’i14/AWS, pas nos mesures. Aucun tarif d’abonnement, matériel gratuit, avantage universel ou service garanti n’en découle. TorchNeuron Native était en bêta.
Sources et preuves
Date de la source: · Source vérifiée:
Articles assistés par IA, vérifiés avec les sources primaires citées. Les affirmations des fournisseurs sont attribuées ; la présence ne vaut pas recommandation.