Gigatoken : un tokeniseur BPE en Rust qui encode le texte à 24,53 Go/s, jusqu'à 989 fois plus vite que HuggingFace Tokenizers

Perplexity AI publie en open source un tokeniseur Unigram avec une latence p50 5 fois inférieure au tokeniseur de Hugging Face

L'équipe de recherche de Perplexity AI a réécrit de zéro son tokeniseur Unigram en Rust et publié le code en open source dans son dépôt pplx-garden, dédié à ses technologies d'inférence. Le résultat est saisissant : à des longueurs d'entrée typiques de production, la nouvelle implémentation divise par 5 la latence médiane (p50) par rapport à la bibliothèque tokenizers de Hugging Face, par 2 par rapport à SentencePiece en C++, et par 1,5 par rapport au tokeniseur IREE en C. En conditions réelles, Perplexity a mesuré une réduction de 5 à 6 fois de l'utilisation CPU dans sa pile d'inférence, et un gain de plusieurs dizaines de millisecondes sur la latence de ses modèles de reranking. La solution atteint zéro allocation sur le tas en régime permanent, ce qui change fondamentalement la courbe de performance à grande échelle. Ce gain n'est pas anecdotique : il révèle un angle mort souvent ignoré de l'inférence LLM. La conversation autour des coûts se concentre presque exclusivement sur les GPU, les caches KV et les noyaux d'attention. Mais des modèles plus compacts, comme les encodeurs d'embeddings, les classifieurs et les modèles de reranking, présentent un profil radicalement différent. Un reranker tel que XLM-RoBERTa, doté d'un vocabulaire Unigram de 250 000 tokens, peut terminer son calcul GPU en quelques millisecondes seulement. La tokenisation côté CPU devient alors le vrai goulot d'étranglement, surtout lorsqu'il faut traiter des centaines de documents par requête. Pour des systèmes à fort trafic comme celui de Perplexity, optimiser cette étape revient à réduire directement les coûts d'infrastructure et la latence perçue par l'utilisateur final. La lenteur de l'implémentation de Hugging Face tenait à trois problèmes structurels : chaque correspondance dans le trie déclenchait une allocation mémoire via String::from_utf8, générant jusqu'à 299 000 allocations pour une entrée de 16 000 tokens ; chaque nœud du trie reposait sur une HashMap entraînant quatre chargements mémoire dépendants par octet ; enfin, les buffers de la table de programmation dynamique étaient réalloués à chaque appel, saturant le cache L2 à mesure que les entrées s'allongent. Perplexity a d'abord validé un portage sans allocation avec la même structure de trie, réduisant déjà la latence de 326 µs à 155 µs, avant d'introduire un Double-Array Trie pour éliminer le coût résiduel du parcours de pointeurs. L'algorithme de Viterbi, introduit en 1967 pour la segmentation probabiliste, reste au cœur du tokeniseur Unigram formalisé par Kudo en 2018 et intégré à SentencePiece. En publiant leur implémentation, Perplexity offre à l'ensemble de l'écosystème open source un composant critique dont les bénéfices dépassent largement leur propre infrastructure.

L'outil open-source pxpipe cache du texte dans des PNG pour réduire jusqu'à 70% les coûts en tokens de Claude Code et Fable 5

Steven Chong, développeur indépendant, a mis en ligne un outil open source baptisé pxpipe qui convertit de longs prompts textuels destinés à Claude Code en fichiers PNG compacts. L'astuce repose sur un détail de la tarification d'Anthropic : les images sont facturées selon leur taille en pixels, et non selon le contenu textuel qu'elles encodent. Résultat, Chong annonce des économies de 59 à 70 pour cent sur les coûts de tokens, au prix toutefois d'une perte de précision et de vitesse dans les réponses générées. Cette découverte illustre à quel point les modèles de tarification des API d'intelligence artificielle peuvent être détournés dès qu'une faille de calcul apparaît entre différents types d'entrées, texte ou image. Pour les développeurs qui utilisent massivement des outils comme Claude Code au quotidien, la facture peut vite grimper, et une réduction de 70 pour cent des coûts représente un argument concret, surtout pour des usages intensifs ou automatisés. Mais le compromis sur la fiabilité des réponses limite l'intérêt de la méthode aux tâches où l'exactitude n'est pas critique. Cet épisode s'inscrit dans une tendance plus large de contournement des grilles tarifaires des fournisseurs de modèles de langage, où chaque nouvelle méthode de facturation, par token, par pixel ou par requête, finit par générer ses propres optimisations créatives côté utilisateurs. Anthropic, comme ses concurrents, devra probablement ajuster sa politique de prix pour combler cette faille, un exercice d'équilibriste récurrent entre simplicité de facturation et résistance aux détournements techniques.

💬 Cacher du texte dans une image pour payer moins cher, c'est malin, mais ça révèle surtout qu'Anthropic facture au pixel sans vraiment regarder ce qu'il y a dedans. Bon, sur le papier, 70% d'économie ça fait rêver, sauf que tu perds en précision, donc cette astuce, oublie-la dès que la réponse doit être fiable. Ce genre de bidouille dit une chose simple : dès qu'une API facture différemment texte et image, quelqu'un trouve la faille avant l'entreprise elle-même.

Le Marker 2 de Datalab face à MinerU, Docling et LiteParse : 76,0 sur olmOCR-bench avec un débit 5 fois supérieur à MinerU

Datalab a publié Marker 2, une réécriture complète de son pipeline open source de conversion de documents, le 21 juillet 2026. Marker convertit les fichiers PDF, images, PPTX, DOCX, XLSX, HTML et EPUB en markdown, JSON, HTML ou en chunks. Cette nouvelle version s'appuie sur trois composants développés ces derniers mois par l'équipe de Datalab : Surya OCR 2, un modèle de détection de mise en page rapide de 20 millions de paramètres, et une version reconstruite de pdftext trois fois plus rapide que la précédente. Sur le benchmark olmOCR-bench d'Allen AI, référence tierce composée de 1403 PDF et d'environ 8400 tests, le mode équilibré de Marker 2 obtient un score global de 76,0% et 83,5% sur les documents PDF nativement numériques, tout en traitant 2,9 pages par seconde sur un seul GPU B200. À titre de comparaison, MinerU plafonne à 72,7% avec seulement 0,54 page par seconde, et Docling atteint 50,3% à 2,1 pages par seconde sur le même test. Cette avancée change concrètement la donne pour les équipes qui doivent extraire et structurer de grands volumes de documents, un besoin central dans l'entraînement de modèles de langage, l'indexation documentaire ou l'automatisation de flux d'entreprise. Un gain de vitesse supérieur à 5 fois par rapport à MinerU, à qualité égale voire supérieure sur les documents natifs, réduit directement les coûts d'infrastructure et les délais de traitement à grande échelle. Marker 2 propose désormais trois modes selon les besoins : le mode équilibré qui mobilise le modèle Surya pour les documents complexes, un mode rapide combinant un détecteur léger et un usage minimal du modèle de vision pour un coût réduit, et un mode sans OCR fonctionnant uniquement sur CPU, à 43,6% de score mais 23,7 pages par seconde. La sélection automatique du mode selon le matériel disponible facilite l'adoption par des équipes aux ressources GPU limitées. Cette évolution s'inscrit dans une course plus large entre plusieurs outils open source de conversion documentaire, tous confrontés au même défi : concilier fidélité d'extraction et rapidité de traitement à l'échelle industrielle. L'architecture de Marker 2 repose sur un changement structurel clé, plusieurs processus légers tournant sur CPU partagent un seul serveur d'inférence Surya, ce qui permet au débit de suivre la capacité du serveur plutôt que d'être limité par la mémoire GPU de chaque processus. Datalab revendique une amélioration notable par rapport au traitement en flux unique. La mise à jour s'accompagne toutefois de changements majeurs à anticiper avant toute migration : Python 3.10 minimum désormais requis, passage de Poetry à uv pour le packaging, et suppression du convertisseur d'extraction structurée, les utilisateurs étant désormais orientés vers l'API hébergée ou un usage combiné avec un LLM.

💬 Sur le papier, c'est le genre de bond qu'on n'a pas vu souvent : 5 fois plus rapide que MinerU sans sacrifier la qualité sur les PDF natifs, c'est rare. Ce qui change vraiment la donne, c'est le mode CPU sans GPU, ça ouvre l'extraction documentaire à masse aux équipes qui n'ont pas de cluster à disposition. Reste que la casse côté migration (Python 3.10, uv, convertisseur structuré supprimé) va faire râler pas mal de monde qui tournait déjà en prod avec l'ancienne version.

Depuis Hugging Face vers Amazon SageMaker Studio en un clic

Amazon a annoncé une intégration directe entre Hugging Face et Amazon SageMaker AI, permettant aux développeurs de passer de la découverte d'un modèle à son expérimentation dans SageMaker Studio en un seul clic. Concrètement, sur les pages de modèles compatibles sur Hugging Face, deux nouveaux boutons apparaissent : "Customize on SageMaker AI", qui ouvre directement la page de personnalisation dans Studio avec le modèle préchargé pour du fine-tuning, et "Deploy on SageMaker AI", qui ouvre la page de déploiement avec le modèle préconfiguré pour un endpoint d'inférence. Un nouveau rôle géré, nommé AmazonSageMakerModelCustomizationCoreAccess, est créé et attaché automatiquement, couvrant les permissions nécessaires aux tâches de fine-tuning supervisé (SFT), d'optimisation directe des préférences (DPO), et d'apprentissage par renforcement avec récompenses vérifiables (RLVR) ou retours d'IA (RLAIF), avec déploiement possible vers SageMaker AI ou Amazon Bedrock. L'interface affiche aussi désormais la disponibilité des quotas GPU (instances G5 et G6) directement dans la liste de sélection, sans navigation supplémentaire. Cette intégration supprime une friction bien connue des développeurs : auparavant, passer de la découverte d'un modèle sur Hugging Face à son utilisation effective sur SageMaker nécessitait d'ouvrir la console AWS, de créer un domaine, de configurer manuellement les permissions IAM, et parfois de demander un quota GPU spécifique, autant d'étapes qui ralentissaient le passage de l'idée à l'expérimentation concrète. Désormais, un nouveau domaine Studio est provisionné automatiquement en quelques secondes avec les permissions déjà configurées, et le contexte du modèle sélectionné est conservé tout au long du parcours. Pour les environnements Studio existants, des messages d'action avec liens vers la documentation guident les utilisateurs pour ajouter les permissions nécessaires. Ce gain de temps profite en particulier aux équipes qui itèrent rapidement sur des modèles open source et souhaitent les déployer dans un environnement cloud sous leur contrôle, sans dépendre d'une configuration manuelle lourde. Cette annonce s'inscrit dans une tendance plus large de rapprochement entre les plateformes de modèles ouverts et les fournisseurs cloud, qui cherchent à réduire les barrières techniques entre l'écosystème open source et l'infrastructure d'entreprise. Mark McQuade, fondateur et PDG d'Arcee AI, entreprise spécialisée dans les modèles ouverts, a salué cette intégration comme la dernière étape manquante pour permettre aux entreprises de posséder réellement les poids de leurs modèles tout en les exécutant dans un environnement cloud maîtrisé. Cette combinaison de poids ouverts et d'infrastructure contrôlée répond à une demande croissante des entreprises soucieuses de souveraineté sur leurs déploiements d'intelligence artificielle. À mesure que de plus en plus de modèles Hugging Face deviendront compatibles avec ce flux, cette intégration pourrait redessiner la manière dont les équipes techniques choisissent et déploient leurs modèles, en abaissant significativement la barrière entre expérimentation et mise en production.

💬 Un bouton en moins entre l'idée et le prototype, ça compte plus qu'on croit. Amazon rend l'open source consommable en mode SaaS, ce qui est un peu paradoxal mais très malin : le vrai verrou du cloud, ce n'est plus le modèle, c'est la friction de configuration. Reste que "posséder ses poids" tout en dépendant d'IAM et de quotas AWS, ça reste une souveraineté à moitié, mais bon, c'est déjà mieux qu'avant.