gnostral.rs

La machine de référence n'est pas un serveur de datacenter : une RTX 3070 de 8 Go de mémoire graphique, 32 Go de mémoire centrale. C'est une configuration de station de travail personnelle — et c'est précisément ce qui rend la recherche intéressante.

Le résultat principal : en gardant sur la carte les parties toujours sollicitées et en empruntant les experts quantifiés depuis la mémoire centrale, le débit passe de 9,51 à 20,18 jetons par seconde, soit 2,12 fois plus vite. Mesuré localement, trois répétitions par condition, réponses identiques octet pour octet.

Un « 2,12× » est une médiane. Derrière, il y a douze réponses mesurées : trois processus sans correctif et trois avec, chacun interrogé avec une réponse de 128 puis de 512 jetons. Les deux nuages ne se touchent jamais : la plus lente des réponses corrigées (19,48 jetons/s) reste deux fois plus rapide que la plus rapide des autres (10,12).

Le jalon Q-012 pose une autre question : le même exécutable sait-il servir des modèles de natures différentes ? Trois familles, l'une après l'autre : un modèle dense qui écrit du texte, un modèle d'embeddings qui transforme des phrases en vecteurs, et le gros MoE quantifié. Les trois répondent juste — le modèle d'embeddings, par exemple, juge deux phrases liées bien plus proches (0,78) que deux phrases sans rapport (0,17).

Le graphique montre surtout où chaque modèle pose ses poids. Le MoE de 30 milliards de paramètres occupe 2,4 Go sur la carte et 19 Go en mémoire centrale : c'est l'astuce du dossier, mesurée. Le premier essai, compilé sans la fonction de résidence d'experts, montait à 6,8 Go sur la carte et a dépassé son délai ; il reste au dossier, et un garde refuse désormais un binaire qui l'oublie.

Un « 2,12× plus vite » ne veut rien dire sans son point de comparaison. Ici, la référence n'est pas un autre logiciel : c'est le même moteur, une version plus tôt.

Concrètement, « Strata » est la révision de mistral.rs utilisée au laboratoire : la version publique 0.9.3, plus une intégration de résidence d'experts. Les 9,51 jetons/s mesurent ce moteur avant le patch ; les 20,18 mesurent le même binaire, recompilé avec une seule fonction changée — les poids d'experts quantifiés sont empruntés au lieu d'être recopiés à chaque appel.

Face à llama.cpp, en revanche, la comparaison existe et elle est défavorable : 34,54 jetons/s pour llama.cpp contre 20,18 pour gnostral, sur le même modèle et la même carte. Le rapport du dépôt l'écrit explicitement : ces gains n'établissent pas une supériorité sur les options CPU-MoE de llama.cpp.

Quant à mistral.rs, ce n'est pas un adversaire : c'est le moteur dans lequel le patch est appliqué. gnostral n'est pas un moteur concurrent — c'est un ensemble de patches, de contrats typés et d'outils de mesure autour de mistral.rs. Se comparer à lui reviendrait à comparer une voiture à son propre moteur.

La contribution la plus solide du projet n'est peut-être pas le gain de vitesse, mais la méthode. Six étapes, toujours les mêmes, et aucune ne peut être sautée.

Concrètement : on identifie le code et le modèle par une empreinte (SHA), on écrit un plan qui décrit exactement ce qui sera exécuté, on lance un seul processus dans un cadre limité, on vérifie une réponse précise, on arrête, on vérifie que la mémoire est revenue, puis un programme indépendant refait les contrôles.

L'ordre compte. Un serveur peut répondre à une requête de contrôle alors que les poids ne sont pas encore chargés. gnostral.rs distingue donc huit états, du simple fait « déclaré dans la documentation » jusqu'à « qualifié par un audit indépendant ».

La sixième étape de la boucle — l'arrêt et la récupération — est celle qui fait échouer le plus d'essais. Après chaque arrêt, on mesure ce qui reste occupé sur la carte graphique. La porte est fixée avant l'essai : ±128 Mio. Un essai rapide qui laisse de la mémoire derrière lui est refusé.

Le premier essai de Q-010 a échoué : la mémoire graphique n'était pas revenue dans la marge attendue (+196 Mio contre une tolérance de ±128 Mio). Le premier essai de Q-012 a échoué aussi : une fonctionnalité de compilation manquait, et le modèle MoE a dépassé le délai.

Les deux échecs sont toujours dans le dossier. C'est un choix méthodologique, pas une coquetterie : un résultat dont on ne connaît pas les ratés n'est pas réutilisable. Et un chiffre qui ne peut pas être contredit n'est pas une mesure, c'est une affirmation.

Le même principe s'applique au benchmark Bonsai : la référence retenue est 35,2 jetons par seconde, pas la revendication plus flatteuse de 40 — faute de preuve suffisante.

gnostral.rs avance par quêtes : chacune ouvre une question précise et se ferme par une décision écrite, y compris quand la décision est « non qualifié ». Le journal public en compte quinze entre le 7 et le 21 octobre 2026.

Une part du travail consiste à examiner d'autres moteurs avant d'y toucher. Le dépôt garde les refus aussi soigneusement que les adoptions :

La toute première quête, Q-001, n'a rien mesuré de nouveau : elle a retiré un chiffre. Un banc Bonsai annonçait 40 jetons par seconde ; faute de preuve suffisante, le dépôt a conservé 35,2 et n'a jamais publié le 40. Le projet commence donc par une correction — c'est un choix de méthode.

La cible est écrite en une phrase : un plan de contrôle d'inférence locale, inspectable et écrit d'abord en Rust, pour du matériel contraint — choisir le bon moteur pour chaque modèle, borner les ressources, prouver qu'il est prêt, l'arrêter proprement, rendre compte de sa performance. Les noyaux de calcul et le placement des experts restent l'affaire de chaque moteur.