Un moteur open source s'ajuste à votre puce et revendique un gain de 92 % en vitesse

Magnitude, une entreprise issue de Y Combinator (promotion S25), a publié un moteur d'inférence open source qui, selon elle, exécute des modèles à poids ouverts jusqu'à 2 fois plus vite que llama.cpp. Les chiffres de l'entreprise : un décodage plus rapide de 92 % sur Metal d'Apple et de 19 % sur CUDA de NVIDIA. Le logiciel est distribué sous licence Apache 2.0 et se présente sous la forme d'une application de bureau pour macOS, Windows et Linux. Il s'agit des benchmarks de l'entreprise, pas de résultats indépendants, et l'écart entre 92 % et 19 % est la première chose qu'un opérateur doit remarquer.

Ce que signifie réellement « s'ajuster sur votre appareil »

Un moteur d'inférence est le programme qui exécute un modèle entraîné et transforme votre prompt en réponse. À l'intérieur, le gros du travail est assuré par des noyaux (kernels) : de petites routines très spécialisées qui effectuent les calculs essentiels sur un GPU ou un CPU. La vitesse d'un noyau dépend des particularités de la puce concernée, comme l'organisation de sa mémoire et le nombre de calculs qu'elle peut mener en parallèle.

L'argument de Magnitude est que des outils populaires comme llama.cpp, Ollama et LM Studio livrent des noyaux précompilés pour de grandes catégories de matériel. C'est pratique, mais un noyau conçu pour une catégorie de puces est rarement le meilleur pour votre puce en particulier. Magnitude affirme au contraire compiler et ajuster ses noyaux sur votre machine réelle avant l'exécution d'un modèle, afin qu'ils épousent exactement votre silicium. L'entreprise indique aussi écrire à la main des noyaux optimisés pour les familles de modèles à poids ouverts les plus répandues, ce qui expliquerait ses meilleures performances face aux moteurs généralistes.

Le compromis mérite d'être compris. Les noyaux précompilés démarrent instantanément et se comportent de la même façon partout. Une approche d'ajustement sur l'appareil ajoute une étape de préparation et fait dépendre les performances de la machine utilisée, ce qui explique en partie pourquoi les gains de l'entreprise diffèrent autant entre Metal et CUDA.

Ce que l'entreprise revendique d'autre

L'entreprise cite plusieurs autres fonctionnalités. Elle affirme que les agents consomment 27 % de mémoire en moins, la mémoire étant libérée à l'arrêt des agents. Elle indique que les sessions simultanées partagent des caches de préfixe, c'est-à-dire que le moteur réutilise le travail déjà effectué sur une partie d'ouverture commune d'un prompt, de sorte que l'exécution de plusieurs agents en parallèle ne ralentit pas l'ensemble. Il se connecte en un clic à des agents tels que Pi, OpenCode, Hermes, OpenClaw, Codex, Claude Code, Oh My Pi et Cline, et tout autre outil peut s'y raccorder via une API compatible OpenAI. Tout s'exécute en local : prompts, fichiers et modèles restent sur votre machine, et aucune connexion Internet n'est nécessaire une fois un modèle téléchargé. Il prend en charge Apple Silicon, NVIDIA, AMD, ou un CPU seul, sans configuration minimale imposée ; les machines plus modestes exécutent des modèles plus petits.

Un plan raisonnable sur un mois

Traitez cela comme un banc d'essai comparatif, pas comme une migration. Choisissez une machine que votre équipe utilise réellement, installez Magnitude à côté de votre configuration actuelle, puis exécutez le même modèle sur les mêmes prompts avec les deux. Mesurez ce qui compte pour vous : le délai avant le premier jeton, la vitesse de sortie soutenue, ou le nombre de sessions d'agents qui tiennent avant que les performances ne se dégradent. Si votre parc est surtout composé de machines NVIDIA, c'est le chiffre CUDA de 19 % fourni par l'entreprise qu'il faut tester, pas le « 2x » mis en avant.

L'erreur serait de réécrire votre infrastructure autour d'un benchmark éditeur, ou de supposer que la vitesse obtenue sur une puce se retrouve sur une autre. À l'inverse, l'écarter d'emblée serait aussi une erreur : une licence Apache 2.0 et une conception 100 % locale font que l'essai comporte peu de risques de dépendance ou de fuite de données.

Les questions à vous poser

• Sur quels modèles, niveaux de quantification et longueurs de prompt les chiffres de 92 % et de 19 % ont-ils été mesurés, et le benchmark correspond-il au comportement réel de nos agents ?
• Combien de temps dure l'étape d'ajustement sur l'appareil, et que devient la vitesse la première fois qu'on utilise un nouveau modèle ou une nouvelle machine ?
• Le « jusqu'à 2x » affiché est bien au-dessus des 19 % annoncés pour CUDA. De quel matériel disposons-nous, et quel chiffre s'applique à lui ?
• Lesquels des modèles pris en charge bénéficient de noyaux optimisés à la main, et de combien un modèle hors de cette liste est-il plus lent ?
• Quelqu'un en dehors de l'entreprise peut-il reproduire ces résultats, et l'a-t-on déjà fait ?

Ce qu'il faut surveiller ensuite

Le signal à guetter, ce sont des benchmarks indépendants et reproductibles sur du matériel NVIDIA et AMD, là où le chiffre de l'entreprise est le plus faible, ainsi que la rapidité avec laquelle la liste des modèles pris en charge s'étend au-delà des familles que l'équipe optimise à la main. Si les tests tiers se rapprochent des chiffres annoncés et que la liste des modèles suit le rythme des nouvelles sorties à poids ouverts, l'ajustement par appareil deviendra un sérieux concurrent des moteurs précompilés ; si les gains s'amenuisent hors des puces d'Apple, il restera un avantage de niche.