AI cette semaine : GLM-5.2, Fable 5, Diffusion Gemma
Trois choses sont arrivées dans ma boîte de réception en environ 72 heures, et chacune a silencieusement brisé une hypothèse que je portais depuis des mois.
Un laboratoire chinois a livré une fenêtre de contexte d'un million de tokens avec les poids sous licence MIT. Google a sorti un modèle de langage qui ne génère pas le texte un token à la fois. Et une usine de robots humanoïdes en Californie a cessé d'être un rendu pour devenir un bâtiment avec 200 personnes dedans. N'importe lequel de ces événements ferait la une d'une semaine normale. Ce tour d'horizon AI hebdomadaire est ma tentative de donner du sens à tout cela en même temps — pas comme un relais de communiqués de presse, mais comme un ingénieur en activité qui trie ce qui change réellement mon lundi et ce qui est du bruit déguisé en signal.
Je serai franc sur ce que j'ai testé versus ce que j'ai lu. Certaines sorties de cette semaine j'ai pu les prendre en main. Certaines — comme les poids ouverts de GLM-5.2 — ne sont littéralement pas encore téléchargeables au moment où j'écris. Je le signalerai à chaque fois, parce que le moyen le plus rapide de perdre votre confiance est de prétendre que j'ai benchmarké quelque chose dont je n'ai lu que la fiche technique. Parcourons la semaine comme je l'ai réellement traitée : dans l'ordre de combien chaque chose a fait bouger ma réflexion.
GLM-5.2 et la fenêtre de contexte de 1M que personne n'a vu venir
Commençons par celui qui m'a fait relire l'annonce deux fois.
Le 13 juin 2026, Z.ai (la scission de Zhipu AI) a annoncé GLM-5.2 avec une fenêtre de contexte utilisable d'un million de tokens — un bond de 5x par rapport aux 200K de GLM-5.1. Le mot « utilisable » fait un vrai travail dans cette phrase, et j'y reviendrai. Le modèle est devenu disponible immédiatement pour les utilisateurs du GLM Coding Plan, avec accès API, chatbot, et des poids ouverts sous licence MIT tous promis pour « la semaine prochaine. »
Arrêtez-vous un instant sur la licence. MIT. Pas une licence communautaire personnalisée avec une clause de revenus. Pas « poids ouverts, usage commercial restreint. » MIT — la même licence permissive sous laquelle votre package npm préféré est distribué. Un modèle proche de la frontière avec une fenêtre d'un million de tokens, libre à télécharger, modifier et déployer commercialement, avec le laboratoire qui absorbe le coût d'entraînement. Cet arrangement n'existait pas en open source il y a dix-huit mois. Il existait à peine il y a dix-huit jours.
Voici pourquoi la fenêtre de contexte importe spécifiquement, et pourquoi je suis prudent avec le chiffre du titre en même temps. La plupart des revendications de « contexte long » sont un tour de magie. Le modèle accepte une entrée énorme mais cesse de réellement prêter attention au milieu — vous collez 400 pages, demandez à propos de la page 230, et il répond en se basant sur la page 12 avec une confiance totale. J'ai couvert exactement ce mode de défaillance dans mon premier aperçu de MiniMax M3, qui revendique aussi une fenêtre de 1M. Ce qui est intéressant dans le cadrage de GLM-5.2, c'est que Z.ai revendique explicitement la rétention sur toute la fenêtre, pas seulement l'acceptation — et ils disent l'avoir entraîné avec un nouvel algorithme asynchrone de reinforcement learning d'agents sur plus de 10 000 environnements vérifiables dans neuf langages de programmation.
Ce détail d'entraînement est la partie que je crois réellement tiendra, plus que n'importe quel benchmark individuel. Le travail d'agent à long horizon — le genre où le modèle tourne pendant une heure, fait une centaine d'appels d'outils et doit se souvenir de ce qu'il a décidé à l'étape 4 quand il arrive à l'étape 90 — vit et meurt par la rétention de contexte. Si GLM-5.2 maintient genuinement la compréhension sur toute la fenêtre, c'est ça la percée, pas le nombre brut de tokens.
Les démos qui circulaient cette semaine s'appuyaient sur le développement web et, de toutes les choses, un clone de Minecraft avec génération infinie de terrain à partir d'un seul prompt. J'admets que les démos de terrain infini me rendent sceptique par réflexe — elles sont visuellement impressionnantes et faciles à cherry-picker. Mais la logique de génération procédurale dans un bac à sable voxel fonctionnel est une tâche de codage agentique genuinement difficile : gestion d'état, chargement de chunks, mathématiques de coordonnées qui doivent rester cohérentes. Ce n'est pas rien.
Sur quoi je réserve mon jugement jusqu'à l'arrivée des poids : la vraie multimodalité (il n'y a pas de vision native au lancement), et comment les deux réglages d'« intensité de réflexion » se comportent sous charge. Deux niveaux de raisonnement est une décision produit intelligente — la plupart de mes prompts n'ont pas besoin de raisonnement profond, et payer la taxe de latence sur tous est du gaspillage — mais je veux voir si le réglage plus léger reste cohérent ou devient simplement rapide et bâclé.
Voici la boucle ouverte que je résoudrai plus loin dans ce tour d'horizon : GLM-5.2 passant sous MIT est l'un des trois mouvements de cette semaine qui pointent tous vers le même changement dans le contrôle de la capacité de frontière. Gardez cette pensée.
Claude Fable 5 : le benchmark est un match nul, la facture non
C'est celui avec lequel j'ai le plus de temps pratique réel, parce que je vis dans Fable 5 pour le travail de codage depuis son lancement.
Si vous avez lu mon journal de construction sur la production vidéo autonome avec Fable 5 ou mon build du connecteur Clay pour l'outreach, vous savez déjà que je le considère comme le modèle de codage agentique le plus puissant que j'ai utilisé. Cette semaine, les chiffres de benchmark ont rattrapé ce ressenti instinctif, et une comparaison en particulier mérite qu'on s'y attarde.
Sur SWE-bench Pro — le benchmark de codage agentique plus difficile d'Anthropic, pas le set Verified plus indulgent — Fable 5 affiche 80,3 %, le meilleur score de tous les modèles testés, devant les 69,2 % d'Opus 4.8. Sur SWE-bench Verified, il atteint 95,0 %. Ce sont des chiffres réels, rapportés indépendamment, pas le deck marketing d'Anthropic.
Mais le cadrage de la source qui a lancé ce tour d'horizon est ce sur quoi je reviens sans cesse. Sur un benchmark approfondi d'ingénierie logicielle pour des tâches genuinement complexes, Fable 5 atterrit à peu près à égalité avec le meilleur modèle de classe GPT-5.5 — même taux de réussite — à un coût par tâche radicalement différent. On parle de la différence entre environ dix dollars et plusieurs centaines de dollars pour résoudre la même tâche. Même si vous traitez les montants exacts en dollars comme des approximations (le coût par tâche varie avec l'utilisation de tokens, donc je ne m'engage pas sur un chiffre précis), l'écart d'un ordre de grandeur est l'histoire.
Laissez-moi traduire ça en une décision que vous devrez réellement prendre. Quand deux modèles sont à égalité sur la capacité, tout le choix se réduit à l'économie et l'ergonomie. Fable 5 est tarifé à 10 $ par million de tokens d'entrée et 50 $ par million de sortie — le double des 5 $/25 $ d'Opus 4.8, et pas bon marché en termes absolus. Donc ce n'est pas « Fable 5 est l'option budget. » C'est plus subtil : sur les tâches les plus difficiles, où une exécution autonome ratée gaspille plus d'argent en tokens brûlés que l'écart de prix, le modèle plus capable est le moins cher. Un modèle qui réussit votre refactoring de nuit du premier coup à 10 $ bat un modèle qui a besoin de trois tentatives à 4 $ et vous remet quand même quelque chose de cassé.
C'est le modèle mental avec lequel je veux que vous quittiez cette section : sur du travail de difficulté frontière, la capacité est un outil de contrôle des coûts. Les exécutions ratées sont la vraie dépense, et elles sont invisibles jusqu'à ce que vous totalisiez un mois entier.
Si vous essayez de choisir un modèle de codage en ce moment, voici la version compacte : utilisez le modèle moins cher pour les éditions routinières où un nouvel essai ne coûte rien, et réservez Fable 5 pour les grands refactorings, les exécutions autonomes de nuit et les bugs de difficulté frontière où une mauvaise réponse se propage en cascade. La comparaison prix-par-token est un piège ; la comparaison prix-par-tâche-accomplie est la vérité.
Encore une mise à jour à signaler, parce que c'est une décision de valeurs déguisée en fonctionnalité. Fable 5 a reçu une mise à jour qui rend ses protections visibles — quand le modèle refuse ou se replie sur une demande, vous voyez maintenant l'événement de repli au lieu d'obtenir un comportement silencieux et mystérieux. J'aime sincèrement ça. Le nombre d'heures que j'ai perdues à « pourquoi le modèle est soudainement devenu moins bon à ça » pour découvrir qu'une protection invisible s'était déclenchée… la transparence là est un vrai gain de qualité de vie. Le compromis honnête : des protections visibles signifient probablement plus de faux positifs visibles. Vous le verrez refuser des choses qu'il n'avait pas besoin de refuser. Je préfère voir le faux positif que déboguer un fantôme. Votre tolérance peut différer, et c'est un désaccord légitime.
Si vous préférez que quelqu'un construise un workflow de codage agentique autour de modèles comme celui-ci plutôt que de le régler vous-même, c'est le type de travail d'intégration que j'accepte — vous pouvez voir ce que j'ai livré sur fiverr.com/s/EgxYmWD.
DiffusionGemma : Google a construit un modèle qui n'écrit pas de gauche à droite
Maintenant l'architecturalement bizarre, que je trouve plus intéressant que tout le reste cette semaine même si je ne peux pas encore le faire tourner complètement.
Le 10 juin 2026, Google DeepMind a sorti DiffusionGemma sous Apache 2.0, avec les poids sur Hugging Face. La raison pour laquelle ça compte n'a rien à voir avec les benchmarks et tout à voir avec comment il génère du texte. Chaque modèle de type GPT que vous avez utilisé écrit un token à la fois, de gauche à droite, chaque token conditionné par le précédent. DiffusionGemma ne fait pas ça. Il utilise la diffusion discrète — débruitage de blocs de 256 tokens en parallèle, la même famille de techniques qui alimente les générateurs d'images, appliquée au langage.
Pourquoi la génération de texte basée sur la diffusion est-elle importante ?
La génération de texte basée sur la diffusion produit plusieurs tokens simultanément au lieu d'un à la fois, ce qui explique pourquoi DiffusionGemma peut atteindre des vitesses qu'un modèle autorégressif ne peut structurellement pas atteindre. Google rapporte plus de 1 000 tokens par seconde sur un seul Nvidia H100 — jusqu'à 4x plus rapide que des modèles autorégressifs comparables — et 700+ tokens par seconde sur une RTX 5090 grand public. Le modèle est un 26B mixture-of-experts qui n'active que 3,8B de paramètres à l'inférence, donc il se quantifie pour tenir dans un budget VRAM de 18 Go.
Relisez cette dernière phrase, parce que c'est la partie qui devrait vous faire dresser l'oreille : un modèle aussi rapide, tournant sur une carte qu'un hobbyiste sérieux peut réellement posséder.
Voici où je dois être honnête plutôt que de faire du battage. Je n'ai pas réussi à faire tourner DiffusionGemma localement, et la raison est instructive : le module drafter personnalisé dont il a besoin pour l'inférence locale n'existe dans aucun runtime public encore. Ni dans mlx-lm, ni dans LM Studio. À l'heure actuelle, il est effectivement inexécutable sur la plupart des configurations grand public malgré le fait que les poids soient publics. Donc quand vous voyez des posts essoufflés genre « faites tourner un modèle à 1000 tok/s sur votre PC gaming ce soir », c'est aspirationnel, pas factuel. Je m'attends à ce que le support runtime arrive — il y a trop de demande pour que ça n'arrive pas — mais aujourd'hui la vitesse est une spécification, pas une expérience que je peux vérifier pour vous.
Et il y a un vrai coût à la vitesse, intégré dans l'architecture. La génération de texte par diffusion échange la précision contre le débit. DiffusionGemma hallucine plus que le Gemma 4 standard. Le propre positionnement de Google est d'une franchise rafraîchissante à ce sujet : utilisez-le pour des tâches critiques en vitesse et non factuelles — édition de code, reformatage de texte, transformation en masse — et ne l'utilisez pas là où la précision factuelle compte. Je respecte un lancement qui vous dit en quoi son modèle est mauvais. Si vous faites tourner des modèles locaux, vous connaissez déjà ce calcul en configurant des outils comme Gemma 4 dans LM Studio — choisir le bon modèle pour la bonne tâche bat la course après un modèle qui fait tout médiocrement.
Mon avis honnête : DiffusionGemma est la sortie architecturale la plus importante de la semaine et simultanément le produit le moins immédiatement utile de la semaine. C'est une déclaration de recherche que le monopole autorégressif sur la génération de langage a une fissure. La première fois qu'un modèle de langage par diffusion sera à la fois rapide et suffisamment précis pour un usage général, toute la conversation sur les coûts d'inférence sera remise à zéro. Ce jour n'est pas aujourd'hui. Mais il est maintenant visiblement inscrit au calendrier.
OpenAI Codex a obtenu un superpouvoir de débogage (et un programme de fidélité)
Deux mises à jour Codex cette semaine, et elles visent des parties complètement différentes de votre cerveau — une technique, une comportementale.
La technique m'enthousiasme sincèrement. Codex a ajouté un mode développeur qui donne un accès contrôlé au Chrome DevTools Protocol (CDP). En termes simples : Codex peut maintenant atteindre une session Chrome en direct et lire le trafic réseau, la sortie console, les erreurs runtime, l'état du DOM et les styles appliqués — exactement les choses que vous inspecteriez à la main quand un bug front-end refuse d'avoir un sens. C'est désactivé par défaut (Paramètres → Navigateur → « Enable full CDP access » sous Developer mode), ce qui est la bonne valeur par défaut pour quelque chose d'aussi puissant.
Pourquoi c'est plus important que ça en a l'air : le débogage front-end a été le talon d'Achille des agents de codage AI. Un modèle peut écrire un composant React magnifiquement et être ensuite inutile pour comprendre pourquoi il s'affiche en blanc dans le navigateur, parce que la défaillance vit dans l'état runtime que le modèle ne peut pas voir. L'accès CDP ferme cette boucle. L'agent peut maintenant observer le symptôme — l'erreur console réelle, la requête réseau réellement échouée — au lieu de deviner uniquement à partir du code source. C'est la différence entre un agent qui écrit du code et un agent qui le débogue.
La mise à jour comportementale est plus rusée. OpenAI a lancé l'accumulation de resets de rate-limit : les utilisateurs Plus et Pro obtiennent des resets qu'ils peuvent accumuler et dépenser quand ils veulent (les resets accumulés durent 30 jours), plus un programme de parrainage — parrainez jusqu'à trois amis entre le 11 et le 24 juin, et quand un ami envoie son premier message Codex, vous recevez tous les deux un reset accumulé.
Je vais dire la partie silencieuse à voix haute, parce que prétendre ne pas la remarquer serait malhonnête. Le mécanisme de parrainage est de l'ingénierie de stickiness d'écosystème. Les resets accumulés sont une fonctionnalité intelligente, sincèrement conviviale — le contrôle sur le moment où vous brûlez votre capacité est une vraie valeur, surtout si vous regroupez du travail lourd. Mais superposer une boucle de fidélité par parrainage d'amis sur un outil de développement est un jeu de rétention emprunté directement aux apps grand public. Ce n'est pas mauvais. Ça vaut juste la peine d'être vu clairement : les laboratoires de modèles sont maintenant en compétition sur les coûts de changement, pas seulement sur la capacité. Le débogage CDP est le fossé ; le programme de parrainage est la clôture.
Deux mises à jour qui changent silencieusement le fonctionnement des agents
Un schéma que je continue de remarquer en 2026 : les changements les plus conséquents ne sont pas de nouveaux modèles, ce sont de nouvelles structures de permissions autour des modèles. Deux cette semaine.
Premièrement, le codage autonome est devenu plus sûr par défaut. Le mode auto de Claude Code et le classificateur d'auto-revue de Cursor convergent vers le même design : pré-approuver les actions sûres, bloquer les risquées. Au lieu soit de surveiller chaque commande soit de tout approuver en mode YOLO, l'outillage fait maintenant du triage — lire un fichier, lancer un test, formater du code ? Allez-y. Supprimer un répertoire, frapper un endpoint de production, réécrire une migration ? Arrêtez et demandez. J'ai déjà écrit sur pourquoi devenir agent-native en 2026 est surtout une question de trouver exactement ce bon gradient. Un agent que vous devez approuver constamment n'est pas autonome ; un agent que vous ne pouvez pas arrêter est dangereux. La couche classificateur est le compromis, et elle mûrit vite.
Deuxièmement — et c'est l'histoire d'infrastructure peu sexy qui, je pense, comptera le plus dans un an — l'authentification des agents AI devient une vraie catégorie de produit. Descope a livré Agentic Identity Hub 2.5 cette semaine (la version 2.0 remonte à janvier), et il résout un problème que la plupart des gens qui construisent des agents n'ont pas encore rencontré mais rencontreront absolument : comment un agent autonome prouve-t-il qui il est et ce qu'il a le droit de faire, sans que vous lui donniez les identifiants d'un humain ?
Cette dernière partie est le nœud du problème. En ce moment, un nombre déprimant de configurations d'agents fonctionnent en donnant à l'agent un token API d'un humain et en espérant que tout aille bien. C'est un désastre de sécurité en attente — pas de scoping, pas de piste d'audit, pas de moyen de révoquer uniquement l'accès de l'agent. La proposition de Descope, c'est les agents comme identités de première classe : OAuth 2.1, scopes au niveau des outils, application de politiques sur quels serveurs MCP un agent peut toucher, et flux d'approbation avec humain-dans-la-boucle pour les actions sensibles. Les magic links et les flux de mot de passe à usage unique vous donnent un contrôle granulaire sur ce qu'un agent peut faire au nom d'un utilisateur.
Je ne prétendrai pas l'avoir déployé en production. Mais j'ai ressenti l'absence de exactement cela. Chaque fois que j'ai connecté un agent à un système avec de vraies permissions, l'histoire de l'authentification a été la partie que j'ai bricolée et dont je me suis senti mal. Un plan de contrôle construit à dessein pour l'identité non-humaine est le genre d'infrastructure ennuyeuse et porteuse que l'AI agentique a manqué — et c'est un sujet qui se situe exactement à l'intersection de l'AI et de la sécurité, ce qui est exactement le type de travail que mes collègues chez xCyberSecurity gèrent pour les équipes qui déploient des agents sur des données sensibles.
Les deux paris de frontière : modèles d'interaction et robots humanoïdes à grande échelle
Prenons du recul maintenant, parce que deux développements cette semaine ne concernent pas ce trimestre — ils concernent la direction de l'ensemble.
Le premier sont les modèles d'interaction de Thinking Machines Lab. Le labo de Mira Murati (elle est l'ancienne CTO d'OpenAI) a publié un aperçu de recherche de TML-Interaction-Small, et l'architecture est un vrai départ du schéma chatbot que nous avons tous internalisé. Au lieu de la boucle requête-réponse — vous parlez, il attend, il répond — le modèle traite l'audio, la vidéo et le texte en micro-tours de 200 millisecondes, en continu, comme deux personnes collaborent réellement. Il peut parler pendant que vous parlez, réagir à ce qu'il voit avant que vous ne finissiez une phrase, et appeler des outils en pleine conversation.
Le détail structurel malin : il se divise en deux modèles qui partagent le contexte complet. Un modèle d'interaction rapide reste en direct avec vous pour des réponses instantanées, tandis qu'un modèle d'arrière-plan gère le raisonnement lent et profond et l'utilisation d'outils de manière asynchrone. C'est une vraie réponse architecturale à la tension centrale de l'AI conversationnelle — on veut à la fois de la réactivité et de la profondeur, et celles-ci se compensent habituellement. C'est un mixture-of-experts de 276B paramètres avec 12B actifs, et c'est en aperçu de recherche limité sans API publique, donc tempérez vos attentes. Mais l'idée — la collaboration plutôt que la requête-réponse — est le recadrage le plus intéressant de l'interaction humain-AI que j'ai vu cette année.
Le second est concret au sens le plus littéral. 1X Technologies a commencé la production de masse de son robot humanoïde Neo dans une usine de 58 000 pieds carrés à Hayward, en Californie. L'installation emploie actuellement plus de 200 personnes et a une capacité de 10 000 robots par an, avec une montée en puissance vers 100 000+ unités d'ici 2027. La première série de production se serait vendue en quelques jours. Ce ne sont pas que des bots logistiques d'usine — Neo est fortement positionné comme robot domestique, avec des livraisons aux clients prévues pour 2026.
J'ai des sentiments compliqués ici, et je les partagerai honnêtement plutôt que de jouer les supporters. La transition d'une démo sur scène à une usine verticalement intégrée — 1X fabrique ses propres moteurs, batteries, capteurs et transmissions en interne — est le saut le plus difficile en robotique, et la plupart des entreprises ne le font jamais. Cette partie mérite un réel respect. Le sceptique en moi se souvient aussi que « livrer » et « utile dans votre cuisine » sont des jalons très différents, et la robotique humanoïde a une longue histoire de démos éblouissantes qui s'effondrent face au désordre des environnements réels. Mais une usine avec une ligne annuelle de 10 000 unités n'est pas un rendu. Quelque chose est réellement en train d'être construit. Nous verrons en 2026 si ce qui est livré est un véritable assistant ou un proof of concept très coûteux.
Ce que cette semaine signifie réellement (la boucle ouverte, résolue)
Vous vous souvenez du fil que je vous ai demandé de garder en tête au début — que GLM-5.2 passant sous MIT était l'un de trois mouvements pointant tous dans la même direction ? Voici la résolution.
Regardez le schéma sur toute la semaine. GLM-5.2 plaçant un modèle de frontière à 1M de contexte sous MIT. DiffusionGemma distribuant une architecture genuinement nouvelle sous Apache 2.0. Même Descope construisant des standards ouverts (OAuth 2.1, MCP) pour l'identité des agents. Le centre de gravité en AI glisse de louer de l'intelligence fermée vers posséder et contrôler de l'intelligence ouverte. Pas complètement — la frontière absolue vit encore dans des labos fermés, et la domination de Fable 5 dans les benchmarks prouve que les leaders propriétaires ne restent pas immobiles. Mais l'écart entre « le meilleur modèle fermé » et « le meilleur modèle que vous pouvez réellement télécharger et posséder » est le plus étroit qu'il ait jamais été.
Cela change la question que vous devriez vous poser. Il y a dix-huit mois la question était « quelle API est-ce que je loue ? » De plus en plus, la vraie question est « quelles capacités dois-je posséder — pour le coût, pour la vie privée, pour le contrôle — et lesquelles puis-je continuer à louer ? » Les équipes qui s'enrichiront en répondant correctement à cette question seront celles qui auront cessé de traiter ouvert et fermé comme un test de loyauté et auront commencé à le traiter comme une décision de portefeuille.
Alors voici votre unique action concrète pour cette semaine. Choisissez la seule dépendance AI dans votre stack qui ferait le plus mal si son prix triplait ou ses conditions changeaient du jour au lendemain. Une seule. Puis allez trouver le modèle open-weight le plus proche qui pourrait la remplacer — GLM-5.2 quand les poids sortiront, ou ce qui correspond à votre tâche — et passez un après-midi à le tester réellement sur votre charge de travail réelle, pas un prompt jouet. Vous n'avez pas besoin de migrer. Vous devez juste savoir que la porte existe avant que quelqu'un d'autre ne la ferme pour vous. C'est la différence, cette année, entre être locataire et être propriétaire.
Foire aux questions
Quelle est la taille de la fenêtre de contexte de GLM-5.2 ?
GLM-5.2 possède une fenêtre de contexte utilisable d'un million de tokens, une augmentation de 5x par rapport aux 200K de GLM-5.1. Z.ai affirme que le modèle conserve la compréhension sur toute la fenêtre plutôt que de simplement accepter l'entrée, et les poids ouverts sous licence MIT sont prévus pour publication peu après l'annonce du 13 juin 2026.
Claude Fable 5 vaut-il son prix plus élevé pour le codage ?
Claude Fable 5 en vaut la peine pour les tâches de difficulté frontière où une exécution ratée gaspille plus en tokens brûlés que la prime de prix. Il domine SWE-bench Pro avec 80,3 % et égale les meilleurs modèles de classe GPT-5.5 sur les benchmarks difficiles pour une fraction du coût par tâche. Pour les éditions routinières, un modèle moins cher est généralement le choix le plus judicieux. Voir la section Fable 5 ci-dessus pour l'analyse complète.
En quoi DiffusionGemma diffère-t-il du Gemma standard ?
DiffusionGemma génère du texte en utilisant la diffusion discrète — débruitage de blocs de 256 tokens en parallèle — au lieu d'un token à la fois, atteignant plus de 1 000 tokens par seconde comparé aux modèles autorégressifs standard. Le compromis est un taux d'hallucination plus élevé, c'est pourquoi Google le recommande uniquement pour les tâches critiques en vitesse et non factuelles comme l'édition de code et le formatage de texte.
DiffusionGemma peut-il tourner sur un GPU grand public ?
DiffusionGemma est conçu pour tenir dans 18 Go de VRAM et atteindrait 700+ tokens par seconde sur une RTX 5090, mais en juin 2026, le module drafter personnalisé nécessaire pour l'inférence locale n'est supporté dans aucun runtime public comme LM Studio ou mlx-lm, le rendant effectivement inexécutable sur la plupart des configurations grand public aujourd'hui.
Quand le robot humanoïde 1X Neo sera-t-il livré ?
1X Technologies a commencé la production de masse dans son usine de Hayward, en Californie, avec des livraisons aux clients prévues pour 2026. L'installation peut produire 10 000 unités par an, avec une montée en puissance vers plus de 100 000 d'ici 2027, et la première série de production se serait vendue en quelques jours après le lancement.
Travaillons ensemble
Vous cherchez à construire des systèmes AI, automatiser des workflows ou faire évoluer votre infrastructure technologique ? J'adorerais vous aider.
- Fiverr (constructions et intégrations sur mesure) : fiverr.com/s/EgxYmWD
- Portfolio : mejba.me
- Ramlit Limited (solutions entreprise) : ramlit.com
- ColorPark (design et branding) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
