Cerebras Inference traite 969 tokens par seconde avec Llama 3.1 405B

 (cerebras.ai)
3 points par GN⁺ 2024-11-20 | 1 commentaires | Partager sur WhatsApp
  • Les grands modèles frontier sont généralement limités par la vitesse et la latence, mais Cerebras Inference a enregistré 969 tokens de sortie par seconde sur des charges de travail client avec Llama 3.1 405B
  • Avec un prompt de 1 000 tokens, les résultats sont 8 fois plus rapides que SambaNova, 12 fois plus rapides que le cloud GPU le plus rapide, et 75 fois plus rapides qu’AWS
  • Avec une entrée de 100 000 tokens, seuls 6 fournisseurs ont renvoyé un résultat ; Cerebras a été le seul fournisseur non-GPU à terminer le benchmark, atteignant 539 tokens par seconde
  • Le temps jusqu’au premier token était de 240 ms, et des clients passés de GPT-4 à Cerebras ont indiqué une réduction de 75 % de la latence totale
  • Cerebras Inference pour Llama 3.1 405B est actuellement disponible en essai client, avec une disponibilité générale prévue au 1er trimestre 2025 et un tarif de 6 $/M de tokens en entrée · 12 $/M de tokens en sortie

Record de performances de Llama 3.1 405B

  • Cerebras Inference a atteint 969 output tokens/s lors de l’exécution de Llama 3.1 405B
    • Résultat mesuré avec un prompt de 1 000 tokens
    • Selon les mesures d’Artificial Analysis, il établit des records en vitesse de sortie, en performances sur longs contextes et en temps jusqu’au premier token
  • Dans la même comparaison, Llama 3.1 405B sur Cerebras est présenté comme 12 fois plus rapide que GPT-4o et 18 fois plus rapide que Claude 3.5 Sonnet
  • Cerebras explique avoir porté cette année Llama 3.1 8B et 70B à plus de 2 000 tokens/s, tandis que des modèles frontier comme GPT-4o, Claude 3.5 Sonnet et Llama 3.1 405B n’ont dépassé 200 tokens/s ni sur GPU, ni sur ASIC, ni dans le cloud
  • La comparaison avec un prompt de 1 000 tokens est la suivante
    • 8 fois plus rapide que SambaNova
    • 12 fois plus rapide que le cloud GPU le plus rapide
    • 75 fois plus rapide qu’AWS
  • Avec un prompt d’entrée de 100 000 tokens, Cerebras a enregistré 539 tokens/s
    • Seuls 6 fournisseurs ont renvoyé un résultat
    • Cerebras a été le seul fournisseur non-GPU à terminer le benchmark
    • 11 fois plus rapide que Fireworks, 44 fois plus rapide qu’AWS

Latence, calendrier de disponibilité et prix

  • Cerebras Inference pour Llama 3.1 405B a enregistré un temps jusqu’au premier token de 240 ms
    • Le temps jusqu’au premier token est un indicateur clé de latence ressentie par l’utilisateur dans les applications réelles
    • Avec les solutions basées sur GPU, le temps de réponse initial peut atteindre plusieurs secondes
  • Des clients passés de GPT-4 à Cerebras Inference ont rapporté une réduction de 75 % de la latence totale
    • Cela se traduit par une meilleure expérience utilisateur dans les cas d’usage où les interactions en temps réel sont essentielles, comme les applications d’IA vocales et vidéo
  • Cerebras Inference pour Llama 3.1 405B est actuellement disponible en essai client
    • La disponibilité générale est prévue au 1er trimestre 2025
    • Le prix est de 6 $ par million de tokens en entrée et 12 $ par million de tokens en sortie
    • Le prix des sorties est 20 % inférieur à celui d’AWS, Azure et GCP
  • La combinaison de l’approche ouverte de Meta et de la technologie d’inférence de Cerebras est présentée comme permettant à Llama 3.1 405B de s’exécuter plus de 10 fois plus vite que les modèles frontier fermés
    • Elle est décrite comme une base adaptée aux applications vocales, vidéo et de raisonnement où une faible latence et de nombreuses étapes d’inférence sont importantes

À lire aussi

1 commentaires

 
GN⁺ 2024-11-20
Avis sur Hacker News

  • C’est vraiment incroyablement rapide. Même avec une implémentation maison de Llama 3.1 70B sur un cluster 8x H100, il est difficile de dépasser 100 tokens/s ; je me demande comment ils font.
    Les techniques habituelles, comme le décodage spéculatif ou FlashAttention, ne semblent pas pouvoir s’en approcher ; il faut probablement au minimum quelque chose comme de l’inférence multi-nœuds ou de l’attention clairsemée.

    • Cerebras fabrique un processeur d’environ 1 million de cœurs, et fait l’inférence dessus plutôt que sur GPU. C’est une architecture complètement différente, donc le réseau n’entre pas en jeu.
      Il est aussi possible qu’une bonne partie du traitement se fasse côté cache CPU plutôt que via la HBM. Pour comprendre la conception de la puce, je recommande les vidéos YouTube de TechTechPotato sur Cerebras.
    • Ils utilisent du silicium personnalisé dont la surface est plusieurs fois supérieure à celle de 8x H100. Il y a bien sûr aussi des optimisations d’exécution/runtime, mais la différence clé semble être le nombre écrasant de transistors.
      https://cerebras.ai/product-chip/
    • La puce a la taille d’une assiette. Les photos donnent une bonne idée : https://cerebras.ai/product-chip/
    • Cerebras est une entreprise de puces et n’utilise pas de GPU. Cette puce utilise l’intégration à l’échelle du wafer : physiquement, elle fait la taille d’un wafer entier, en quelque sorte l’équivalent de dizaines de GPU réunis en un seul.
      La mémoire on-chip est limitée et entièrement en SRAM ; on ne sait pas clairement quelle est la bande passante HBM par wafer. C’est un problème d’optimisation totalement différent d’une exécution sur un cluster de GPU.
    • Le grand secret tient à deux choses : la puce est énorme, et elle utilise de la SRAM comme mémoire, bien plus rapide que la HBM des GPU.
      En fait, c’est la principale raison de cette vitesse. Groq obtient aussi ses performances pour la même raison.

  • Je ne suis pas sûr qu’ils comparent réellement la latence dans les mêmes conditions. La latence se décompose grosso modo en trois parties : le débit de traitement du contexte/prompt, le temps d’attente en file pour accéder au matériel, et les surcoûts classiques d’API comme le réseau.
    D’après ce que je comprends, plusieurs des services comparés, peut-être même tous, ne reposent pas sur de la capacité réservée, donc leurs mesures incluent le temps d’attente en file. Pour les LLM, ce temps peut être assez important. À l’inverse, les chiffres de Cerebras ont probablement été obtenus avec un accès matériel garanti, donc avec très peu de temps de file d’attente susceptible de croître indéfiniment.
    Le débit lui-même est impressionnant, mais fournir ce débit à l’utilisateur final avec une faible latence nécessite du surprovisionnement, et on ne sait pas bien quel sera l’impact des files d’attente. Je me demande aussi si les mesures supposent que le modèle est déjà chargé sur la machine, ou si elles incluent le temps de chargement du modèle à la demande. Il faudrait aussi voir si l’utilisation d’un modèle fine-tuné change la latence.
    Cela semble clairement avantageux pour des traitements batch capables d’exploiter une machine Cerebras à 100 % tout en sortant continuellement 1 000 tokens/s.

    • Même en supposant que tout le monde soit dans des conditions idéales, c’est énorme. À taille de batch 1, un modèle de 405B paramètres à 1 000 tokens/s, c’est absurdement rapide.

  • Quand on voit ce qu’on peut faire avec les modèles de génération actuelle en y ajoutant du RAG, du multi-agent et un interpréteur de code, le mur n’est plus vraiment la précision, mais plutôt la latence du modèle.
    Avec un tel débit de tokens sur un modèle de classe 405B, beaucoup d’expériences interactives deviennent possibles.

    • Je ne vois pas bien en quoi un recueil de règles aide à résoudre des incidents. À mon sens, chaque incident devrait être nouveau, puisqu’on en corrige la cause racine.
      Donc il faut à chaque fois creuser dans le code, ou dans le code récemment déployé, et chercher des corrélations avec les métriques d’exploitation. À moins que ce recueil de règles ne soit simplement une procédure de rollback ?

  • Pour être clair, une seule puce Cerebras utilise un wafer entier, tout en n’ayant que 44 Go de SRAM dessus. Pour charger un modèle 405B en précision bf16, même sans compter le cache KV et la mémoire d’activation, il faut 19 de ces « puces ».
    À mesure que la longueur de séquence augmente, les besoins montent encore à cause du cache KV. D’après ce que j’ai trouvé, on peut mettre environ 60 à 80 puces H100 sur un wafer ; en termes de coût de fabrication de wafers, cela revient donc à quelque chose de comparable à plus de 1 500 H100.

    • Les budgets que ces entreprises consacrent à cette technologie dépassent vraiment l’imagination.
    • Je me demande si le coût du wafer représente une grande part du prix réel de la puce.

  • Les performances sont vraiment impressionnantes. Je pense qu’il y a de bonnes chances que Nvidia tente d’acquérir Cerebras.

    • Cerebras envisage une IPO. Une acquisition me paraît peu probable. Cela dit, s’ils étaient rachetés, ce serait sans doute plus précieux pour Facebook ou MS.

  • Pour essayer l’API, il faut s’inscrire sur une liste d’attente. Quand une entreprise avance ce genre de chiffres sans proposer le service à l’achat, il faut garder une certaine dose de scepticisme.

  • Parmi les startups de puces IA, Cerebras est probablement la vraie affaire.

    • Groq est aussi une vraie affaire. Cela dit, Cerebras ne semble pas encore s’être déployé aussi largement que Groq. À suivre.
    • Le timing tombe pile pour une IPO.

  • Aucune mention de Groq, leur concurrent direct ?

    • Je suis client payant de Groq et j’en suis satisfait, mais sur le segment 405B, ils ne rivalisent pas avec Cerebras.
      Groq a l’avantage d’accepter aussi des clients payants non enterprise, et de proposer largement divers modèles sans être aussi sélectif que Cerebras. Mais en vitesse pure et sur les plus grands modèles, Groq est difficilement comparable.
    • Sambanova n’est pas souvent mentionné non plus [0]. L’un des cofondateurs est connu comme le « père du processeur multicœur » [1].
      [0]: https://sambanova.ai/
      [1]: https://en.wikipedia.org/wiki/Kunle_Olukotun

  • Je me demande combien coûte un service avec une telle latence. Du point de vue client, le coût fixe dépendra de la stratégie tarifaire, mais au final c’est le coût qui déterminera la portée de diffusion de cette technologie.
    La question est de savoir si cela ne convient qu’aux activités qui ont vraiment besoin d’une faible latence, ou si c’est suffisamment abordable pour un déploiement plus général.

    • Est-ce que tout le monde pourrait finir par fabriquer d’énormes puces et utiliser de la SRAM comme standard ?
      Combien y a-t-il de fabricants de SRAM ? Ou bien faut-il nécessairement qu’elle soit entièrement intégrée dans la puce ?

  • Si un nouveau matériel peut apporter un tel gain de performance, je me demande jusqu’où on peut encore pousser les performances d’entraînement grâce au matériel.

    • S’il n’y a pas de grand changement côté machine learning, je ne pense pas que ce sera énorme. Il y a ici deux axes : les gains d’efficacité et les gains de calcul.
      Augmenter la quantité de calcul est la manière la plus évidente d’accélérer, mais pour un nœud de fabrication donné et une précision de type de données donnée, on semble assez proche des limites physiques. C’est difficile à prouver formellement, mais plusieurs éléments vont dans ce sens. L’opération de base des LLM, la multiplication de matrices, est très simple contrairement aux tâches CPU, si bien que beaucoup de logique comme le contrôle de flux est minimisée. La majeure partie de l’énergie est consacrée à la multiplication de matrices elle-même, et celle-ci est effectivement limitée par la puissance[1]. Changer de précision peut apporter des gains, mais c’est difficile ; on utilise déjà des précisions très basses comme fp8, et fp8 ne peut même pas représenter 17. Des recherches récentes montrent aussi ces limites.
      L’efficacité d’entraînement des LLM se mesure avec un critère très sévère appelé « model FLOPS utilization » (MFU). Il consiste à diviser les FLOPS théoriques que le matériel peut fournir par les FLOPS théoriques nécessaires pour implémenter les opérations mathématiques. Avec FSDP seul, atteindre 30 % est facile, et 50 à 60 % n’est ni impossible ni sans précédent. Les inefficacités viennent surtout du fait que 1) le matériel ne fournit pas réellement les FLOPS annoncés pour diverses raisons et 2) il faut synchroniser des téraoctets de données entre des dizaines de milliers de machines. La limite théorique est un facteur 2, mais en pratique il ne reste pas énormément à gratter.
      Les gains à venir se concentreront surtout sur les TPU qui réduisent les marges de Nvidia, l’amélioration des nœuds de fabrication, la réduction des types de données comme avec B100, ou l’augmentation de la taille des puces pour réduire les communications coûteuses entre puces. À précision et nœud de fabrication identiques, je ne vois pas de marge pour un gain 10x.
      [1]: https://www.thonking.ai/p/strangely-matrix-multiplications
    • La solution ultime sera probablement de transformer les LLM en pur ASIC.
      Les performances devraient augmenter d’environ 10x, mais ce serait une solution très coûteuse.