4/4 Infrastructure physique pour l'entraînement du modèle Composer de Cursor. Ils affirment avoir entraîné (et continuent d'entraîner) leurs modèles sur des milliers de GPU. Ils les entraînent avec une faible précision et utilisent l'apprentissage par renforcement asynchrone (voir le tweet suivant pour plus d'explications). Citation : « Nous avons construit une infrastructure de formation personnalisée tirant parti de PyTorch et Ray pour alimenter l'apprentissage par renforcement asynchrone à grande échelle. » Nous entraînons nativement nos modèles à faible précision en combinant nos noyaux MXFP8 MoE avec un parallélisme expert et un parallélisme de données fragmenté hybride, ce qui nous permet d'étendre l'entraînement à des milliers de GPU NVIDIA avec un coût de communication minimal. De plus, l'entraînement avec MXFP8 nous permet d'obtenir des vitesses d'inférence plus rapides sans nécessiter de quantification post-entraînement. »
5/5 Qu'est-ce que l'apprentissage par renforcement asynchrone utilisé par l'entraînement du modèle Customer Composer ? Il utilise l'exécution asynchrone à plusieurs niveaux pour éviter d'attendre les opérations lentes, par exemple une longue génération de déploiement. Comme vous le savez, pour un problème donné, en apprentissage par renforcement comme GRPO, nous générons plusieurs trajectoires. Cependant, certaines trajectoires peuvent prendre trop de temps à se réaliser. Une fois qu'ils disposent de suffisamment de trajectoires, ils lancent l'entraînement. Les déploiements partiels reprennent ultérieurement avec un modèle mis à jour. Il en résulte une situation où certains jetons sont générés par l'ancien modèle/la nouvelle politique et d'autres par le nouveau. Cependant, cela est acceptable. Si vous souhaitez en savoir plus sur l'apprentissage par renforcement asynchrone, veuillez consulter la documentation d'APRIL, un projet dédié à l'apprentissage par renforcement asynchrone.
