Comme chaque année, Amazon profite de sa conférence re:invent pour dévoiler des nouveautés tous azimuts. Nous vous proposerons comme toujours un compte rendu des principales annonces, mais voici déjà ce qu’il faut retenir sur la partie hardware. Le SoC maison Graviton (Arm) passe à la 4e génération, et on le retrouve dans les instances R8g. Pour l’IA, la puce Trainium2 débarque.
Graviton à Graviton3E : rapide rétrospective de 2018 à 2022
Amazon propose une petite rétrospective pour commencer. Le premier Graviton – avec une architecture Arm – a été lancé en novembre 2018, avec 16 Cortex A72. Il était disponible via les instances A1, de 1 vCPU avec 2 Go de mémoire à 16 vCPU et 32 Go. À cette époque, des instances R5 et M5 avec des puces AMD étaient aussi disponibles.
Un an plus tard, en décembre 2019, Graviton2 débarque. Arm est toujours aux commandes, avec 64 cœurs Neoverse N1 (64 bits) et une finesse de gravure en 7 nm. Amazon revendiquait alors des performances « jusqu'à sept plus élevées que sur des instances A1, dont deux fois en virgule flottante ». Cette fois-ci, ce sont les instances C6, M6 et R6 qui en profitent.
Il faudra laisser passer une année blanche (2020) avant de voir débarquer Graviton3, en novembre 2021 donc. Cette puce intègre toujours 64 cœurs Arm, mais cette fois des Neoverse V1 (bien plus rapides). On retrouve ces SoC sur des instances C7.
Là encore, Amazon revendique de fortes hausses des performances : « jusqu'à 25 % de plus sur le calcul, et jusqu'à deux fois plus en virgule flottante et en cryptographie ». Autre changement important : la prise en charge de bfloat16 et des performances jusqu'à trois fois supérieures pour le machine learning.
L’année dernière, pas de Graviton4, mais une puce Graviton3E à la place, qui n’est « qu’une » version un peu dopée du Graviton3, avec toujours des cœurs Neoverse V1. Amazon annonce tout de même des « performances de traitement d'instructions vectorielles jusqu'à 35 % supérieures ». Aujourd’hui, Amazon revendique pas moins de 150 instances différentes dans son catalogue avec un SoC Graviton aux commandes.
Graviton4 : 96 cœurs Neoverse V2
Voici maintenant Graviton4, qui se veut « économe en énergie ». Le géant du Net donne quelques détails techniques : 96 cœurs Neoverse V2 (« Jusqu'à x2 les performances de Neoverse V1 », selon Arm), 2 Mo de cache L2 par cœur et 12 canaux DDR5-5600.
Amazon indique que Graviton4 serait « jusqu'à 40 % plus rapide pour les bases de données, 30 % plus rapide pour les applications Web et 45 % plus rapide pour les grandes applications Java que le Graviton3 ». La densité augmente aussi de 50 % puisqu’on passe de 64 à 96 cœurs.
Instances R8g, avec jusqu’à 192 cœurs et 1,5 To de mémoire ?
Pour l’occasion, de nouvelles instances R8g seront proposées. Selon le communiqué, elles « offrent des performances jusqu'à 30 % supérieures et des instances bien plus grandes avec jusqu'à trois fois plus de processeurs virtuels (vCPU) et de mémoire que les instances R7g, basées sur AWS Graviton3 ».
Les actuelles R7g grimpent déjà jusqu’à 64 vCPU et 512 Go de mémoire. R8g devrait donc monter jusqu’à 192 cœurs et 1,5 To de mémoire vive. Les instances R8G sont accessibles en Preview, avec une disponibilité générale prévue pour les prochains mois.
Trainium2 met à terre Trainium pour l’entrainement des IA
Bien évidemment, l’intelligence artificielle s’invite dans la partie hardware de la conférence. AWS annonce en effet sa puce Trainium2. Elle prend la relève de Trainium premier du nom… qui est l'accélérateur de machine learning (ML) de deuxième génération d’AWS.
Amazon revendique des gains très importants : « Trainium2 est conçue pour offrir des performances d'entraînement jusqu'à quatre fois plus rapides et une capacité de mémoire multipliée par trois par rapport aux puces Trainium de première génération, tout en améliorant l'efficacité énergétique (performances/watt) jusqu'à deux fois ».
Une puce pour les (très) gros modèles de langage
Trainium2 sera disponible dans des instances Trn2, à l’instar des Trainium qui sont dans des Trn1. Par instance, on retrouve 16 puces Trn1 ou Trn2 suivant les cas. « Les instances Trn2 doivent permettre aux clients de grimper jusqu'à 100 000 puces Trainium2 dans les UltraClusters EC2 de nouvelle génération ». Amazon revendique « jusqu'à 65 Exaflops de calcul ».
Le changement d’échelle est important pour l’entrainement d’un grand modèle de langage avec 300 milliards de paramètres. On passe en effet de quelques mois à quelques semaines seulement, selon Amazon.
Commentaires (12)
#1
Pour l’occasion, de nouvelles instances R8g seront proposées. Selon le communiqué, elles « offrent des performances jusqu’à 30 % supérieures et des instances bien plus grandes avec jusqu’à trois fois plus de processeurs virtuels (vCPU) et de mémoire que les instances R7g, basées sur AWS Graviton3 »."
Cela ne serait pas plutôt 1,5 To de mémoire ?
#1.1
#1.2
Question à part, vous recevez les signalements pour erreurs ? Parce que je l'ai fait pour celle là et d'autres dans https://next.ink/118176/ovhcloud-summit-2023-secnumcloud-ia-et-local-zones/?utm_source=dlvr.it&utm_medium=twitter et c'est toujours pas corrigé.
Non pas que je critique ton boulot. C'est juste que si c'est pas utilisé, ça sert à rien que je me casse le cul à remplir les signalements.
#1.3
#1.4
Et tu peux continuer à signaler les erreurs, et commenter :)
#1.5
Et ici, c'est corrigé, mais les autres signalements ne l'ont pas été.
C'est ultra frustrant parce qu'on fait la relecture, et on corrige les fautes dans la demi-heure, l'heure, ou même les 24h après la publications, et faut attendre minimum 48h pour que ce soit corrigé, si ça l'est.
Du coup, on a (j'ai) l'impression de pisser dans un violon, alors qu'on (j') essaye de se décarcasser pour que le maximum de lecteurs voient l'article sous sa meilleure forme.
Et si c'est le nombre de notifications de corrections qui rend le travail difficile, y'a plusieurs solutions : soit corriger plus vite, soit afficher les demandes de correction publiquement (souligner le texte, avec un tooltip, par exemple), ou, relire les articles avant de les publier…
Bref, désolé de ma mauvaise humeur, c'est vraiment ultra frustrant de faire des efforts et de voir que ça n'a que peu d'effets :(
#1.6
La période de transition n'est pas facile, un peu bienveillance.
Et si toi aussi tu lisais plus les commentaires, tu aurais vu qu'ils avaient déjà dit plusieurs fois que les erreurs arrivaient bien chez eux après un soucis de redirection de mail au début.
#1.7
Je comprend la période de transition, mais là, ça a rien à voir : c'est juste éditer du texte pour retirer les erreurs, vu qu'ils reçoivent les notifications d'erreurs.
Un article est probablement le plus lu dans ses premières 24h. Si on fait la notification dans les 3 premières heures, attendre trois jours pour que ce soit corrigé, bah c'est presque inutile.
Surtout que c'est pas un problème récent. C'était déjà comme ça dans la v7.
On fait la Q/A gratos, on fait aussi la relecture gratos, et le tout rapidement. Le minimum, c'est que les coquilles soient corrigées (relativement) rapidement.
Ca me pose pas de problème de faire tout ça, mais uniquement si y'a des effets, sinon, ça sert à rien.
#1.8
#1.9
C'est juste que j'ai vu trop d'erreurs qui n'ont jamais été corrigées, et à force, ça fatigue, c'tout.
#2
#3