Répliques ouvertes et l’écosystème systemone
Les autres pages de ce guide portent sur comment utiliser ces modèles. Celle-ci porte sur lequel choisir — et pourquoi cette question est à la fois plus facile à trancher qu’il y a un an et plus facile à se tromper.
Une interface devenue le standard de fait
POST /v1/systemone n’est plus un simple détail du SDK officiel. Elle est devenue un standard
parce que le coût de migration côté client est proche de zéro : changer de backend revient à
modifier une variable d’environnement d’URL de base, sans toucher à la forme des requêtes ni des réponses.
Il en est résulté des dizaines de projets implémentant la même interface — de « transformer n’importe quel modèle ouvert en modèle de décision » (lire les logits, ne générer aucun texte), aux ajustements fins sur des bases ouvertes, jusqu’aux runtimes purement locaux, et aux ponts qui adaptent d’autres écosystèmes.
Où se situent les alternatives locales
Les répliques ouvertes couvrent cinq ordres de grandeur en nombre de paramètres, de quelques centaines de milliers à 27B :
| Implémentation | Échelle | Licence | À noter |
|---|---|---|---|
| Laya | non autorégressif, ~35 ms par passe avant | Apache-2.0 | Non autorégressif avec probabilités calibrées par RLCD ; sur PyPI / Hugging Face |
| von | 395M | — | moins de 15 ms par passe avant |
| TinyJev | 596M | — | tête de type pointeur, renvoie une confiance calibrée destinée à passer un seuil |
| NanoJev | 0.6B | — | distribution de probabilité complète en une passe, livré avec la chaîne d’entraînement, les poids et le jeu de données |
| Verdict | 118M | Apache-2.0 | mise à l’échelle par température + ensemble d’abstention split-conformal ; indique perdre face à Laya sur les décisions typées |
| jevos | 1B (MiniCPM5 coupé à 17 couches) | MIT | GGUF q4_k_m à 619 MB ; 54 ms court / 220 ms long sur CPU |
| CLM | 8B | — | annonce jusqu’à 9× moins de latence |
| Jebadiah | 27B / 9B / 4B | Apache-2.0 | distribué en bf16 / GGUF / MLX |
Quelques chiffres assez concrets pour être vérifiés :
- Une implémentation CPU de 1B (GGUF, 619 MB) prend 54 ms sur les requêtes courtes et 220 ms sur les longues, contre 344 / 345 ms pour le service hébergé — mais obtient 0.815 contre 0.927, et ne répond qu’aux questions oui/non.
- Un autre poids ouvert obtient 33.1% contre 36.7% sur 308 décisions scellées (environ 13 ms).
- Un modèle spécialisé de remplissage de formulaires (706,048 paramètres, 2.8 MB) atteint 99.7% sur sa propre tâche là où le modèle général obtient 83.6% — et les auteurs disent explicitement que c’est un avantage à domicile, pas une victoire générale.
Ce que ce tableau doit transmettre, ce sont des ordres de grandeur, pas un classement. « Six fois plus rapide mais onze points moins précis » et « précision comparable mais un seul type de question » sont des compromis complètement différents, et tous deux peuvent se décrire comme « un remplacement local ».
La conformité : le chiffre à ne pas sauter
Quand un écosystème s’agite, la question à poser est de savoir si tout le monde honore vraiment la même interface.
Un projet a transformé la sémantique de /v1/systemone en 48 exigences vérifiables
(par exemple : les probabilités des options d’un Choice somment à 1 par définition ; l’espérance d’un Score
égale la somme pondérée par les probabilités ; le nombre d’options va de 2 à 255 ; les réponses
ne changent pas quand l’ordre des questions change) et livre une suite qui teste tout serveur se déclarant
compatible.
Son résultat mesuré :
Sur les huit ports ouverts les plus étoilés, deux seulement étaient pleinement conformes.
Cela coupe dans les deux sens. Pour les clients, cela signifie que « il suffit de changer l’URL de base » doit être confirmé par la suite, pas présumé. Pour qui construit un remplacement, cela désigne un axe de différenciation plus facile à atteindre que la précision et bien moins encombré.
Ce que cela implique pour choisir
Tout bien pesé, le centre de gravité s’est déplacé : il ne s’agit plus de « quel modèle obtient le meilleur score » :
- L’interface est partagée et le modèle est remplaçable. Ces 48 exigences sont la définition de la remplaçabilité — confirme-les d’abord avec la suite, puis parlons du reste.
- Le fossé s’est déplacé hors du modèle. Une fois la couche des modèles banalisée, ce qui est difficile à copier, c’est le contrat d’interface + la politique de seuil + la calibration sur tes propres données. C’est exactement ce dont parlent les autres pages d’ici, et les trois vivent dans ton dépôt, pas chez ton fournisseur.
- Mets les écarts de précision dans les bonnes coordonnées. « 83.6% vs 99.7% » est un spécialiste à domicile ; « 0.815 vs 0.927 » est un petit modèle qui tourne sur CPU et ne répond qu’aux questions oui/non. Dis les deux moitiés, sinon le tableau trompe.
La taille de l’écosystème
L’empreinte publique de l’écosystème est d’environ 1,100 projets (septembre 2026).
Le volume n’est pas la qualité, et ce n’est pas la maturité. Ce total inclut
un grand nombre de projets à un seul commit partageant un même échafaudage : un auteur publiant une série
de dépôts le même jour, partageant un AGENTS.md, un historique à un commit, et
bien plus de prose que de code. Ils peuvent être parfaitement légitimes — ils sont simplement
non éprouvés. Filtre sur « y a-t-il quelque chose qui s’exécute », pas sur « est-ce apparu dans une liste ».
En une phrase
La couche des modèles devient un consommable ; l’interface, les seuils et la calibration, non. Consacre ton effort à ces trois derniers — le premier est remplaçable à tout moment.