L'équipe Qwen publie en open source Qwen3.6-35B-A3B, modèle vision-langage MoE à 3 milliards de paramètres actifs

Premiers tests : Opus 4.7 coûte nettement plus cher que 4.6 malgré les tarifs identiques d'Anthropic

Anthropic a maintenu les tarifs d'Opus 4.7 au même niveau que ceux de son prédécesseur Opus 4.6, avec un prix identique par token. Pourtant, les premières mesures réelles effectuées par des utilisateurs de Claude Code révèlent que chaque requête revient en pratique bien plus cher. La raison : un nouveau tokenizer intégré à Opus 4.7 qui décompose le même texte en jusqu'à 47 % de tokens supplémentaires. Autrement dit, un prompt identique génère désormais un volume de tokens sensiblement plus élevé, ce qui fait mécaniquement grimper la facture à chaque appel à l'API. Pour les développeurs qui utilisent Claude Code de manière intensive, l'impact est immédiat et concret. Sans aucune modification de leurs usages ni de leurs prompts, leurs coûts opérationnels augmentent de façon significative, potentiellement de l'ordre de 30 à 47 % selon les cas. Cette hausse déguisée contourne la communication officielle sur les prix et complique la planification budgétaire des équipes techniques qui s'appuient sur l'API d'Anthropic. Ce phénomène illustre une tension croissante dans l'industrie des LLM : les annonces tarifaires en prix par token masquent souvent des évolutions architecturales qui modifient profondément le coût réel d'utilisation. Anthropic n'est pas la première entreprise à opérer ce type de changement discret via une mise à jour de tokenizer. La publication de ces mesures par la communauté Claude Code devrait pousser Anthropic à clarifier sa communication, alors que la concurrence entre OpenAI, Google et les acteurs open source s'intensifie sur le terrain des prix.

Tutoriel : faire tourner PrismML Bonsai LLM 1-bit sur CUDA avec GGUF, benchmarks, chat, JSON et RAG

PrismML a publié une pile de déploiement optimisée pour faire tourner Bonsai, un modèle de langage de 1,7 milliard de paramètres quantifié à 1 bit, sur GPU via accélération CUDA. Le modèle utilise le format GGUF avec une quantisation Q1\0\g128, et s'appuie sur une version personnalisée de llama.cpp distribuée par PrismML-Eng sur GitHub sous la balise de version prism-b8194-1179bfc. Un tutoriel complet détaille l'installation de l'environnement depuis Google Colab : vérification du GPU et de la version CUDA, installation des dépendances Python (huggingface\_hub, requests, tqdm, openai), téléchargement des binaires précompilés adaptés à la version CUDA détectée (12.4, 12.8 ou 13.1), puis chargement du modèle Bonsai-1.7B pour l'inférence. Le guide couvre ensuite sept cas d'usage concrets : inférence de base, benchmarking, conversation multi-tours, génération JSON structurée, génération de code, mode serveur compatible avec l'API OpenAI, et un pipeline RAG (retrieval-augmented generation) minimal. L'intérêt principal de Bonsai réside dans son empreinte mémoire extrêmement réduite grâce à la quantisation 1 bit : là où un modèle de 1,7 milliard de paramètres en FP16 occuperait environ 3,4 Go de VRAM, la version 1 bit descend bien en dessous de 1 Go, rendant le modèle utilisable sur des GPU d'entrée de gamme ou dans des environnements cloud à ressources limitées. La compatibilité avec le serveur OpenAI permet de brancher Bonsai directement sur des applications existantes sans modifier le code client. Pour les développeurs qui construisent des agents, des chatbots ou des pipelines RAG sur du matériel modeste, c'est une alternative sérieuse aux modèles quantifiés classiques en 4 ou 8 bits. La quantisation à 1 bit est une direction de recherche active depuis la publication de BitNet par Microsoft en 2023, qui avait montré qu'un modèle entraîné nativement en 1 bit pouvait conserver une qualité compétitive à faible coût computationnel. Bonsai s'inscrit dans cette lignée, et PrismML mise sur llama.cpp comme moteur d'inférence universel, bien implanté dans la communauté open source depuis sa création par Georgi Gerganov fin 2022. Le format GGUF, successeur de GGML, est aujourd'hui le standard de facto pour le déploiement local de LLMs quantifiés. La prochaine étape logique pour PrismML sera de proposer des modèles Bonsai dans des tailles supérieures (7B, 13B) pour mesurer si la qualité tient à plus grande échelle, et de valider les performances sur des benchmarks standardisés face à des modèles comme Phi-3 Mini ou Gemma 3.

💬 Moins d'1 Go de VRAM pour faire tourner un LLM complet, c'est le genre de chiffre qui change vraiment ce qu'on peut faire sur du matos lambda. La compatibilité API OpenAI en prime, ça veut dire qu'on branche ça sur un projet existant en cinq minutes. Bon, 1,7B de paramètres ça reste petit, reste à voir ce que ça vaut sur des tâches un peu exigeantes face à un Phi-3 Mini bien quantifié en 4 bits.

Anthropic lance Claude Opus 4.7 : une mise à jour majeure pour le codage par agents, la vision haute résolution et les tâches autonomes longues

Anthropic a lancé Claude Opus 4.7, successeur direct d'Opus 4.6, en le positionnant comme une amélioration ciblée plutôt qu'un saut générationnel complet. Le modèle se place au sommet de la gamme Anthropic, au-dessus de Haiku et Sonnet, juste en dessous du mystérieux Claude Mythos, encore en accès restreint. Sur un benchmark de 93 tâches de programmation, Opus 4.7 améliore le taux de résolution de 13 % par rapport à Opus 4.6, dont quatre tâches qu'aucun modèle précédent ne parvenait à résoudre. Sur CursorBench, référence populaire chez les développeurs, il atteint 70 % contre 58 % pour son prédécesseur. Les gains sont encore plus nets sur les workflows complexes : un testeur rapporte une amélioration de 14 % sur des tâches multi-étapes, avec moins de tokens consommés et un tiers des erreurs d'outils, et Opus 4.7 est le premier modèle à réussir leurs tests de "besoins implicites", continuant à exécuter même quand des outils échouent en cours de route. Ce qui rend cette version particulièrement significative pour les équipes engineering, c'est la capacité du modèle à vérifier ses propres sorties avant de rendre la main. Les versions précédentes produisaient des résultats sans validation interne ; Opus 4.7 intègre cette boucle de contrôle de façon autonome, ce qui a des implications directes pour les pipelines CI/CD et les workflows agentiques longue durée. En parallèle, la résolution des images passe à 2 576 pixels sur le grand côté, soit environ 3,75 mégapixels, plus de trois fois la capacité des modèles Claude précédents. L'impact en production est immédiat : un testeur travaillant sur des workflows "computer-use" rapporte un score de 98,5 % sur leur benchmark de précision visuelle, contre 54,5 % pour Opus 4.6. Les agents qui lisent des captures d'écran denses, extraient des données de diagrammes complexes ou travaillent sur des interfaces pixel-perfect bénéficient directement de cette amélioration, sans modifier leur code, les images sont simplement traitées avec une meilleure fidélité. Du côté de l'API, Anthropic introduit deux nouveaux leviers. Un niveau d'effort "xhigh" (extra high) s'intercale entre "high" et "max", offrant un contrôle plus fin sur le compromis entre qualité de raisonnement et latence. Claude Code passe d'ailleurs à xhigh par défaut pour tous les abonnements. Ces annonces s'inscrivent dans une course à l'agent autonome où Anthropic se positionne clairement : après les améliorations de Sonnet 4.6 sur les tâches longues durée, Opus 4.7 cible les cas les plus difficiles, ceux qui nécessitaient jusqu'ici une supervision humaine rapprochée. Avec Claude Mythos en coulisses et une gamme qui s'étoffe à tous les niveaux, Anthropic consolide son avance sur le segment des développeurs professionnels et des applications d'IA en production.

Mon approche pour comprendre les architectures de LLM

Sebastian Raschka, chercheur et auteur reconnu dans le domaine de l'apprentissage automatique, a publié un article détaillant sa méthode de travail pour comprendre et visualiser les architectures des grands modèles de langage (LLM). Sa démarche, qu'il applique pour produire les schémas et dessins publiés dans ses articles et sa LLM-Gallery, part toujours des rapports techniques officiels, avant de plonger dans les fichiers de configuration et les implémentations de référence disponibles sur Hugging Face. Concrètement, lorsque les poids d'un modèle sont accessibles sur le Model Hub et que le modèle est supporté par la bibliothèque Python transformers, il est possible d'inspecter directement le fichier config.json et le code source pour obtenir des informations précises sur l'architecture, là où les articles scientifiques restent souvent vagues. Cette approche répond à un problème croissant : les publications académiques des laboratoires industriels sont de moins en moins détaillées sur le plan technique, en particulier pour les modèles open-weight. En s'appuyant sur le code de référence plutôt que sur les papiers, on accède à une vérité que le code ne peut pas dissimuler. Cette méthode permet à quiconque, chercheur, ingénieur ou passionné, de reconstituer fidèlement l'architecture d'un modèle comme LLaMA, Mistral ou Qwen, sans dépendre de descriptions parfois incomplètes ou ambiguës. En revanche, elle ne s'applique pas aux modèles propriétaires comme ChatGPT, Claude ou Gemini, dont les poids et les détails d'implémentation restent confidentiels. Le processus reste volontairement manuel. Raschka insiste sur ce point : même si certaines étapes pourraient être automatisées, réaliser cet exercice à la main reste l'une des meilleures façons d'apprendre vraiment comment ces architectures fonctionnent. Dans un contexte où la complexité des LLM ne cesse de croître et où la transparence des laboratoires diminue, ce type de rétro-ingénierie pédagogique devient un outil précieux pour maintenir une compréhension technique rigoureuse de l'état de l'art. Raschka prévoit de documenter ce flux de travail de façon plus complète pour la communauté.

💬 Le code ment jamais, les papiers si. C'est exactement le problème que Raschka met le doigt dessus : les labos publient de moins en moins les vrais détails, et le seul moyen de savoir ce qui tourne vraiment sous le capot, c'est d'aller lire le config.json directement sur HuggingFace. La partie "volontairement manuel", bon, certains vont trouver ça old school, mais c'est probablement la seule façon de vraiment comprendre plutôt que de juste faire tourner un script.