Pourquoi Composer est-il plus rapide de 250 jetons/seconde ?

Pour être honnête, lorsque j'ai vu pour la première fois que Composer pouvait atteindre une vitesse de génération de 250 jetons/seconde, j'étais intérieurement un peu sceptique - ce n'est pas le sacrifice de la précision pour la vitesse, n'est-ce pas ? Mais après une compréhension plus approfondie, j'ai réalisé que cette vitesse élevée cachait un support technique solide.

Code de vitesse réelle : MXFP8 Entraînement de faible précision

Composer utilise MXFP8, un format de faible précision pour l'entraînement et l'inférence, ce qui est en fait assez rare dans l'industrie. Les modèles traditionnels utilisent généralement le format FP16 ou même FP32, qui est très précis mais nécessite beaucoup de calculs et de mémoire, alors que le format MXFP8 permet de multiplier par plusieurs fois l'efficacité des calculs, sans presque aucune perte de précision. C'est comme si l'on passait de la voiture au train à grande vitesse : on voyage de la même manière, mais la vitesse et l'efficacité ne sont pas du tout du même ordre de grandeur.

Et surtout, il peut raisonner à grande vitesse sans la quantification et la compression des autres modèles. J'ai vu trop de modèles "optimisés" avec toutes sortes de problèmes bizarres une fois qu'ils ont été quantifiés, mais Composer utilise cette optimisation directement à partir de la phase d'apprentissage, ce qui peut être considéré comme la cause première du goulot d'étranglement de la vitesse.

La puissance d'un cluster de GPU à mille cartes

L'équipe de Cursor a construit un système de formation basé sur PyTorch et Ray, capable de programmer des milliers de GPU NVIDIA pour travailler en parallèle. Cette échelle est définitivement considérée comme une configuration de pointe dans l'industrie. Imaginez des milliers de cartes graphiques de pointe fournissant simultanément de la puissance de calcul pour l'entraînement de modèles, ce type d'investissement en ressources n'est pas à la portée de n'importe quelle équipe.

Mais la pile matérielle n'est que la base, ce qui est vraiment impressionnant, c'est leur architecture de formation distribuée. Pour autant que je sache, de nombreuses équipes ne sont pas en mesure de concevoir un système de formation aussi efficace, même si elles disposent du même matériel. C'est comme si on vous donnait les mêmes ingrédients, mais que le plat préparé par un grand chef n'était pas le même.

Avantages uniques de la modélisation experte hybride

Composer utilise l'architecture MoE, ce qui signifie qu'il active différents réseaux d'experts pour différentes tâches. Par exemple, il fait appel à un expert pour le code Python et à un autre pour le JavaScript. Cette conception évite le fardeau du "modèle unique" et permet à chaque expert d'exceller dans son domaine de compétence.

Ce type d'architecture est particulièrement adapté aux scénarios de génération de code - pensez-y, lorsque nous écrivons du code, cela implique de multiples langages et de multiples cadres, donc si nous laissons des professionnels faire des choses professionnelles, l'efficacité augmentera naturellement.

Mais la vitesse n'est qu'un chiffre, et ce qui m'a vraiment impressionné, ce sont ses performances dans un environnement de développement réel. Après tout, qui refuserait un assistant de programmation à la fois rapide et fiable ?