Groq fait tourner Mixtral 8x7B-32k à 500 T/s

• Alors que la vitesse de réponse et le coût d’inférence deviennent des goulets d’étranglement pour les services d’IA, Groq met en avant une infrastructure d’inférence rapide et économique
• Son facteur différenciant est qu’au lieu d’une approche centrée sur les GPU, l’entreprise utilise une stack basée sur les LPU, développée depuis 2016 spécifiquement pour l’inférence
• GroqCloud exploite cette stack LPU dans des datacenters du monde entier afin d’offrir une faible latence, et l’entreprise affirme être utilisée par 3 millions de développeurs et d’équipes
• Les développeurs peuvent l’intégrer assez facilement via un client compatible OpenAI en ne changeant que base_url et GROQ_API_KEY
• Après l’adoption de GroqCloud, Fintool a vu la vitesse de son chat multipliée par 7,41 et ses coûts baisser de 89 %, tandis que McLaren Formula 1 Team a également choisi Groq comme partenaire d’inférence

---

Une plateforme d’inférence rapide et économique

• Groq considère l’inférence comme le moteur clé de l’IA et met en avant une plateforme d’inférence rapide et économique, capable de fonctionner de manière fiable sur des charges réelles
• Le message central de la page d’accueil se rapproche de « une inférence rapide et économique qui ne flanche pas en conditions réelles »
• Fondée en 2016, l’entreprise se présente comme ayant été créée avec l’objectif de se concentrer uniquement sur l’inférence

Une stack dédiée à l’inférence construite autour des LPU

• Contrairement à d’autres acteurs qui dépendent des GPU, Groq fait de son propre silicium son principal atout
• L’entreprise indique avoir ouvert la voie au LPU en 2016, qu’elle présente comme la première puce conçue exclusivement pour l’inférence
• Les choix de conception du LPU visent à maintenir des réponses de modèles intelligents rapides et peu coûteuses
• Avec le message « ce ne sont pas les benchmarks qui sont déployés, ce sont les workloads », Groq insiste sur les environnements de déploiement réels

Des datacenters mondiaux et GroqCloud

• La stack basée sur les LPU fonctionne dans des datacenters du monde entier, avec un accent mis sur des réponses à faible latence
• En partant du principe que l’inférence est meilleure lorsqu’elle fonctionne au plus près du local, Groq met en avant une architecture qui rapproche les réponses des modèles des utilisateurs
• GroqCloud est le service cloud qui permet aux développeurs d’utiliser une inférence rapide et économique
• Groq affirme être utilisé par 3 millions de développeurs et d’équipes

Intégration développeur compatible OpenAI

• Groq met en avant une intégration compatible OpenAI et explique qu’il est possible de basculer en « deux lignes »
• L’exemple Python configure les valeurs suivantes dans le client openai.OpenAI
  • base_url="https://api.groq.com/openai/v1";
  • api_key=os.environ.get("GROQ_API_KEY")
• Les développeurs peuvent démarrer depuis la console Groq ou obtenir une clé API gratuite pour l’utiliser

Cas clients et partenariats

• McLaren Formula 1 Team est présenté comme un exemple de partenaire ayant choisi Groq pour l’inférence à l’échelle mondiale
• McLaren F1 Team a choisi Groq pour la prise de décision, l’analyse, le développement et les insights en temps réel
• Kevin Scott, CTO de PGA of America, déclare utiliser Groq pour les tâches où les performances comptent davantage
• Nicolas Bustamante, CEO de Fintool, dit avoir constaté les changements suivants après l’adoption de GroqCloud
  • vitesse du chat multipliée par 7,41
  • coûts réduits de 89 %
  • consommation de tokens multipliée par 3
• Abhigyan Arya, CTO d’Opennote, indique que Groq a permis de réduire les coûts et la charge opérationnelle, tout en aidant à maintenir un prix raisonnable pour les offres premium destinées aux étudiants

Actualités publiées en parallèle

• Groq Raises $750 Million as Inference Demand Surges : article du 17 septembre 2025
• Day Zero Support for OpenAI Open Models : article du 5 août 2025
• From Speed to Scale: How Groq Is Optimized for MoE & Other Large Models : article du 27 mai 2025

[GN⁺]

Avis de Hacker News

• C’est l’une des démos techniques les plus impressionnantes que j’aie vues de ma vie, et j’apprécie que ce soit une vraie démo publique que n’importe qui peut essayer immédiatement, sans inscription.
  Voir les tokens déferler à une vitesse folle paraît presque irréel, et c’est d’autant plus surprenant qu’on est habitué à des vitesses qui n’atteignent même pas le cinquième de celle-ci. Je suis étonné qu’une entreprise comme Microsoft, Apple ou Google ne les ait pas déjà rachetés à prix fort.

  • Si j’ai bien compris, chaque puce n’a que 200 Mo de RAM, ce qui veut dire qu’il faut plusieurs racks pour faire tourner un seul LLM ; ça ne ressemble pas vraiment à un progrès.
    Il faudrait une carte PCIe unique avec plusieurs dizaines, voire centaines, de Go de RAM et un processeur capable de bien les exploiter.
  • Perplexity Labs propose aussi une démo publique de Mixtral 8x7b, mais elle n’est pas aussi rapide.
    https://labs.perplexity.ai/
  • Je ne comprends vraiment pas pourquoi c’est si incroyable, et je suis curieux.
    Les points essentiels sont les TFLOPS/$ et les TFLOPS/W, et la comparaison avec Nvidia, AMD et les TPU. En cherchant rapidement, Groq semble faire des affirmations similaires depuis 2020, mais les gens paient toujours une grosse prime pour Nvidia et Groq ne semble pas vraiment bousculer ce marché. Faire tourner un modèle bien plus petit que ChatGPT sur du matériel comparable ou plus puissant peut être rapide, mais cela ne veut pas dire qu’il s’agit d’une percée pour la plupart des modèles ou des cas d’usage où la latence n’est pas l’indicateur clé.
  • Pourquoi vendre ? Les battre à leur propre jeu semble bien plus amusant.

• Le principal problème du LPU de Groq, c’est qu’il n’a aucune HBM, seulement une minuscule SRAM ultrarapide de 230 Mio.
  Elle est bien 20 fois plus rapide que la HBM3, mais cela signifie qu’il faut environ 256 LPU, soit l’équivalent de 4 racks de serveurs, pour servir un seul modèle. À l’inverse, un seul H200 peut servir ce genre de modèles de façon assez raisonnable. Cela peut très bien convenir à un modèle unique avec beaucoup de clients, mais dès qu’il faut plusieurs modèles, beaucoup de fine-tuning et des LoRA de rang élevé, ça devient difficile à utiliser. Ce n’est pas non plus adapté aux déploiements on-premise, car son avantage central consiste à regrouper de nombreux utilisateurs sur le même modèle.
  https://wow.groq.com/groqcard-accelerator/
  https://twitter.com/tomjaguarpaw/status/1759615563586744334

  • Du point de vue d’un ingénieur Groq, je ne vois pas bien pourquoi le fait de pouvoir étendre le calcul au-delà d’une seule carte ou d’un seul nœud serait un problème.
    J’aime bien l’analogie de l’usine automobile : on peut fabriquer une voiture avec une ou deux perceuses, mais une usine automatisée moderne en a des centaines. Avec une seule perceuse, on pourrait fabriquer plusieurs types de voitures, alors qu’une chaîne d’assemblage d’usine ne peut produire que des voitures d’une configuration donnée. Cela ne veut pas dire pour autant que l’usine est inefficace. Dire que le H200 fonctionne assez bien peut aussi être raisonnable pour des interactions humaines synchrones, mais c’est discutable. J’aimerais voir chez Nvidia un exemple d’un modèle de plus de 30B paramètres qui effectue du RAG pendant une conversation et produit aussi une réponse vocale en moins d’une seconde.
  • Groq indique dans l’article avoir utilisé 576 puces pour obtenir ce résultat.
    Il faut aussi tenir compte du fait qu’il faut un cache KV distinct par utilisateur, ce qui peut ajouter plusieurs Go par utilisateur. Selon mon jugement professionnel d’observateur indépendant, le coût des ventes nécessaire pour atteindre de tels chiffres de performance semble très probablement dépasser plusieurs millions de dollars, et il paraît irréaliste de l’amortir sur l’usage prévu tout en respectant le prix théorique publié. Du point de vue des performances réelles par dollar, cela semble peu viable, mais si l’on ignore le coût, c’est bien une démo très impressionnante avec des performances délirantes.
    https://www.nextplatform.com/2023/11/27/groq-says-it-can-dep...
  • Si l’objectif est une faible latence, il faut être très prudent avec la HBM. Le problème n’est pas seulement la latence elle-même, mais aussi le non-déterminisme.
    L’un des grands avantages de l’architecture LPU est qu’elle permet de construire des systèmes de centaines de puces avec une interconnexion rapide, tout en connaissant le timing exact de l’ensemble du système jusqu’au niveau du ppm. Dès qu’on commence à introduire des composants non déterministes, les garanties de latence disparaissent très vite.
  • Les dispositifs Groq sont très bien adaptés à l’inférence en petits lots grâce à leur SRAM.
    En revanche, je ne suis pas certain qu’ils aient un avantage en tokens/seconde/dollar, surtout pour les utilisateurs de lots moyens à grands qui peuvent acheter beaucoup de silicium. Du point de vue architectural, Groq ne semble pas devenir plus rapide au-delà d’une taille de lot de 1, tandis que les cartes Nvidia devraient voir leur débit s’améliorer sensiblement quand la taille de lot atteint les centaines.
  • Il pourrait être possible de charger un modèle de base et plusieurs LoRA tout en consommant à peine plus de RAM que le modèle de base seul.
    On pourrait faire le fine-tuning en ne modifiant qu’environ 0,1 % des poids et, à chaque calcul, calculer non pas l’écart des poids mais l’écart des activations de la couche de sortie.

• À première vue, c’est très impressionnant. Mais sans benchmarks, mieux vaut garder une certaine dose de scepticisme.
  Il existe beaucoup de contournements, comme une quantification agressive, qui sacrifient la qualité pour augmenter la vitesse. Si ce n’est pas le cas, j’aimerais voir les progrès en tokens/seconde pour les LLM se poursuivre comme ceux des instructions/seconde des CPU il y a quelques décennies.

  • Je suis d’accord avec cette attitude scientifique qui consiste à rester sceptique par défaut.
    L’application de chat et l’API sont ouvertes pour que chacun puisse les tester et comparer la qualité des sorties avec d’autres fournisseurs.
  • Comme tome l’a dit plus haut, nous ne faisons pas de quantification, et toutes les valeurs d’activation sont en FP16.
    Il existe aussi un benchmark indépendant : https://artificialanalysis.ai/models/llama-2-chat-70b
  • Pour la démo Llama 70B précédente, ils affirmaient l’exécuter sans quantification.
    https://twitter.com/lifebypixels/status/1757619926360096852
    Cela dit, dans ce commentaire, il est indiqué que « certaines données sont stockées en FP8 lorsqu’elles sont enregistrées », mais je ne sais pas exactement ce que cela signifie : https://news.ycombinator.com/item?id=39432025
  • Lors du processus de benchmark de Groq, j’ai demandé s’il y avait de la quantification, et on m’a confirmé que le modèle était exécuté en FP-16 complet.
    C’est un bon point à vérifier, et un élément important. Lien du benchmark : https://artificialanalysis.ai/
    La question portait sur l’API, pas sur la démo de chat.
  • Je pousse peut-être l’analogie trop loin, mais les LLM sont-ils déjà entrés dans l’ère du transistor ?
    Quand on voit un monstre de 70 milliards de paramètres, on a encore un peu l’impression de construire ENIAC avec des tubes à vide. Autrement dit, je me demande si nous sommes désormais prêts à améliorer régulièrement, année après année, les tokens/seconde des LLM, ou s’il faut encore une ou deux grandes percées avant cela.

• Je travaille chez Groq. Vous pouvez me poser n’importe quelle question.
  Si vous regardez mon historique de posts sur HN, je parle beaucoup de Haskell, et oui : une partie du pipeline de compilation de Groq est écrite en Haskell.

  • C’est peut-être un bug de l’interface web, mais après avoir envoyé un prompt au modèle Mixtral et reçu une réponse, j’ai changé le menu déroulant vers Llama puis envoyé le même prompt, et j’ai obtenu exactement la même réponse.
    Cela peut être du caching, le modèle interrogé qui n’a en réalité pas changé, ou autre chose.
  • Haskell semble assez atypique dans le domaine du machine learning.
    Je me demande si ce choix présente des avantages particuliers et si vous le recommanderiez à d’autres équipes. J’aimerais aussi savoir quelles parties du projet utilisent Haskell et lesquelles ne l’utilisent pas.
  • Si je comprends bien, vous accélérez la génération de tokens avec du matériel spécialisé, et la génération de tokens est fortement liée à la latence de calcul.
    Mais la génération de tokens ne nécessite généralement qu’une multiplication matricielle unidimensionnelle. Quand on fournit un prompt d’environ 100 tokens, le service devient beaucoup plus lent, sans doute parce qu’il faut multiplier une matrice bidimensionnelle. Je me demande ce que vous faites pour accélérer la vitesse de calcul du traitement du prompt.
  • Vous semblez être l’une des très rares entreprises à viser l’inférence à faible latence, sans vous concentrer uniquement sur le débit et donc sur le coût par inférence.
    Je me demande quel marché principal vous visez.
  • Merci pour l’AMA. Je me demande combien de GroqCard sont utilisées pour faire tourner la démo, et si vous utilisez une nouvelle version avec plus de SRAM que les 230 Mo visibles en ligne.
    Ce chiffre devrait avoir un impact sur l’utilisation du traitement par lots et sur la réduction des coûts. Par ailleurs, si un pipeline TTS pouvait être intégré à la stack, cela permettrait des appels à très faible latence. Je suppose que le produit utilisé est celui-ci : https://www.bittware.com/products/groq/

• Démo impressionnante.
  Cela dit, les exigences matérielles et le coût semblent la rendre difficilement accessible en dehors des grandes entreprises. Je me demande quand une gamme de prix abordable pour les développeurs hobbyistes pourrait devenir possible. La démo CNN Vapi était également impressionnante, mais https://smarterchild.chat/, partagé il y a quelques semaines, permettait aussi des conversations naturelles avec une latence vocale très faible. D’après cette discussion, cela semble avoir été créé par https://www.sindarin.tech/, et je me demande s’ils utilisent un LPU Groq ou autre chose. À mon avis, autour de 50 t/s, l’interaction en temps réel devient possible. Au-delà, c’est utile pour accélérer la génération de données en masse, mais comme on dépasse largement ce que les humains peuvent traiter, le gain perçu diminue. Cela peut être utile pour la communication entre IA, le transfert de connaissances et de contexte, etc. Dans ce cas, un produit LPU concentré uniquement sur l’interaction IA-humain ne pourrait-il pas être possible avec des performances bien plus faibles et un coût bien inférieur ?
  https://news.ycombinator.com/item?id=39180237

  • L’accès à une API de tokens en tant que service garantit un coût par token inférieur à celui de tous les autres fournisseurs.
    Voir https://wow.groq.com. Côté vente de matériel, nous nous concentrons sur la vente de systèmes complets, et en pratique cela ne convient qu’aux entreprises ou aux organismes de recherche.
  • Pour interagir en temps réel avec des systèmes d’IA, une vitesse bien supérieure à 50 t/s est absolument nécessaire.
    La majeure partie des sorties des LLM servira au monologue interne, à la planification, au RAG, aux résumés, etc., et seule la sortie finale sera transmise à l’utilisateur. Il suffit d’imaginer un GPT-5 extrêmement rapide qui, en quelques clignements d’yeux, planifie plusieurs fois sa réponse, recherche sur le Web, rédige un compte rendu de lecture, débat avec lui-même, affine ce qu’il a trouvé, critique sa réponse puis la réécrit.
  • Vu que l’équipe de Sindarin semble compter environ trois personnes, cela ressemble davantage à une combinaison très ingénieuse de technologies existantes.
    Il existe des API vocales qui fournissent de la transcription en temps réel mot par mot, et Google en propose aussi. Le secret principal est probablement un pipeline très bien conçu entre reconnaissance vocale → LLM → TTS. Je ne cherche pas à minimiser leur réussite ; au contraire, cela m’intéresse parce que je me demande comment reproduire ce résultat.

• Ce n’est pas toujours rapide : si l’on pose une question complexe ou si l’on ajoute un pré-prompt demandant de répondre dans un autre ton, le chargement prend encore du temps
  C’est intéressant, mais au final cela semble avoir de fortes chances d’être un échec

• Si la page n’arrive pas à accéder à certaines polices, elle échoue et réessaie la requête en boucle
  Je l’ai découvert parce que le navigateur bloque par défaut ce qui est, de fait, un traceur
  https://fonts.gstatic.com/s/notosansarabic/[...]
  https://fonts.gstatic.com/s/notosanshebrew/[...]
  https://fonts.gstatic.com/s/notosanssc/[...]

  • Ça ressemble à une façon de montrer à Google à quel point on est populaire et intéressant comme cible d’acquisition, sans installer directement de traceur Google sur le site
  • Même si l’on essaie d’utiliser la substitution de polices avec une extension de protection de la vie privée, on rencontre le même problème
    C’est assez étrange d’avoir une telle dépendance

• Je suis un peu naïf sur ce domaine, donc je me pose la question : pourquoi est-ce impressionnant ?
  Pour répondre plus vite, ne suffit-il pas d’ajouter plus de calcul ? Le fait qu’une file d’attente se forme en cas de charge ne montre-t-il pas simplement le compromis entre le nombre de requêtes traitables par unité de temps et la quantité de calcul à mobiliser pour répondre plus vite ? Ce graphique de NVIDIA semble indiquer qu’un H100 fait tourner llama v2 70B à plus de 500 tok/s
  https://raw.githubusercontent.com/NVIDIA/TensorRT-LLM/rel/do...

  • Ajouter du calcul peut améliorer le débit, mais cela n’améliore pas facilement la latence entre les tokens
    En génération, le goulot d’étranglement est généralement le temps nécessaire pour traverser le réseau à chaque token. Pour accélérer cela, il faut rendre le calcul lui-même plus rapide, et une fois utilisées les options évidentes comme les accélérateurs les plus rapides ou le cache, cela devient un problème difficile
  • L’inférence des LLM est par nature un problème séquentiel
    Faire davantage de choses en parallèle ne la rend pas plus rapide. On ne peut pas produire le 101e token avant d’avoir produit le 100e
  • Le débit en tokens et la latence sont deux choses différentes
    Le débit en tokens est le débit de l’ensemble du GPU ou du système, tandis que la latence correspond au débit en tokens du point de vue d’un utilisateur individuel. Groq offre une latence extrêmement faible, c’est-à-dire un débit en tokens très élevé par utilisateur, mais on ne dispose pas encore du chiffre de débit total en tokens pour l’ensemble du système. À l’inverse, la métrique Nvidia ici montre le débit en tokens de l’ensemble du GPU ou du système. Même si l’on peut réellement obtenir 1,5k t/s sur un H100, le débit en tokens par utilisateur du point de vue de la latence peut être beaucoup plus bas, par exemple 20 t/s. La métrique vraiment importante est le coût par token. Le fait que Groq puisse fonctionner avec une faible latence ne signifie pas que cela peut être fait à bas coût. Une approximation utile consiste à diviser le coût du système par le débit en tokens par seconde de l’ensemble du système ; mais comme on n’a pas le débit total en tokens par seconde du système Groq, il est difficile de parler d’efficacité, et ils pourraient très bien subventionner le coût du système pour les besoins de la communication, puis augmenter les prix plus tard
  • Au final, cela semble dépendre du coût de l’infrastructure mentionnée dans l’article
    Le H100 ne coûte qu’environ 3 300 dollars à produire, mais se vend en moyenne autour de 30 000 dollars
    https://www.hpcwire.com/2023/08/17/nvidia-h100-are-550000-gp...
  • Nvidia semble avoir indiqué le débit maximal en traitement par lots. Par exemple, 50 tok/s chacun pour 10 prompts différents en parallèle
    Le LPU de Groq dépasse clairement le H100 en vitesse brute. Mais fondamentalement, c’est un système dont le prix est 500 fois plus élevé pour une vitesse 10 fois supérieure, et on dirait qu’une entreprise qui exploite une blockchain markete agressivement pour l’inférence LLM une puce initialement conçue pour le minage de cryptomonnaies. C’est aussi une coïncidence assez amusante de voir, chaque semaine, quelqu’un poster ce lien avec étonnement pendant que des ingénieurs de Groq attendent dans les commentaires, prêts à répondre à tout

• Cela n’a donc rien à voir avec le modèle Grok fourni par x.ai ?
  Je l’ai essayé, et la vitesse est très impressionnante

  • Ça n’a rien à voir avec Elon, et nous, Groq, avons utilisé ce nom en premier
    Dans le domaine de l’IA, c’est un choix de nom naturel en raison du lien avec l’esprit hacker, mais la marque nous appartient, pas à Elon
    https://wow.groq.com/hey-elon-its-time-to-cease-de-grok/
  • Sans ce commentaire, j’aurais probablement cru que ça venait de Twitter
  • Il existe aussi un jouet pour enfants appelé Grok, qui utilise un LLM pour parler avec un enfant

• Groq et Mixtral sont tous les deux à couper le souffle
  J’ai essayé le prompt suivant : générer un fichier YAML GitLab CI pour un projet hybride frontend/backend, avec sous /frontend un frontend Node packagé avec yarn et buildé avec vite vers /backend/public, et un backend qui est un serveur Python Flask

  • Et pourtant, il a fait une erreur dans du code Python simple
    particles = np.zeros((2, 3)) # position, velocity, and acceleration
particles[:, 0] = [0.0, 0.0, 0.0] # initial position