Comment fonctionne ElephantPool

1. La forme du système

Trois parties, un seul contrat entre elles.

L'hôte interroge vers l'extérieur ; rien ne se connecte vers lui. Cette seule décision explique pourquoi un GPU derrière un routeur domestique fonctionne sans aucune configuration, et pourquoi un hôte n'expose jamais un port à Internet.

2. Ce qui arrive à une requête

1. Votre appel arrive à la gateway avec une clé API. Nous vérifions la clé, estimons le coût, et confirmons que votre solde prépayé et le plafond de la clé le couvrent.
2. Le job est mis en file pour le modèle demandé. Il transporte vos messages et rien sur vous.
3. Un hôte le réclame — un hôte qui a prouvé, par benchmark, sur cette machine, qu'il peut servir ce modèle.
4. Le GPU produit des tokens, streamés vers vous à travers la gateway au fur et à mesure de leur génération.
5. Le job se solde. Les tokens sont comptés, votre solde est débité au micro-centime, l'hôte est crédité de 80%, et le prompt disparaît du registre. Ce qui reste : des comptes et des horodatages — pas de texte.
6. L'hôte signe un reçu avec une clé qui ne quitte jamais sa machine : modèle, build exact, comptes de tokens, chronométrage.

Les prompts vivent en mémoire le temps du job. Ils ne sont ni écrits sur disque, ni journalisés, ni utilisés pour l'entraînement — ni par nous, ni par les hôtes.

3. mahout — l'agent sur l'hôte

mahout est un unique binaire Rust open source d'environ 5 Mo, nommé d'après la personne qui conduit l'éléphant. Il tourne comme un utilisateur ordinaire, n'a pas besoin de root, et fait six choses :

• Sonde la machine — CPU, RAM, GPU et leur VRAM.
• S'enrôle avec un code à usage unique depuis le dashboard, en générant localement une identité ed25519 ; la clé privée ne quitte jamais la machine.
• Télécharge et vérifie les poids des modèles et le moteur dans un cache adressé par contenu — contrôlés contre des empreintes SHA-256 épinglées pendant le téléchargement, puis à chaque chargement.
• Supervise le moteur : le démarre, surveille sa santé, le relance une fois s'il meurt, l'arrête proprement.
• Réclame et sert des jobs, en streamant les tokens par lots.
• Signe un reçu par job, ajouté à un journal local que vous pouvez revérifier hors ligne avec mahout receipts verify.

Il se met en pause de lui-même quand vous utilisez la machine, et mahout uninstall affiche un plan de suppression avant de rien effacer. La source et l'installeur sont publics.

4. Les modèles sont des builds, pas des fichiers

Un modèle est ce qu'un client demande (qwen3.8-27b). Un build est un artefact concret : une quantisation, un moteur, un fichier exact d'une révision amont exacte, avec son SHA-256 publié.

Cette séparation est ce qui permet à un même modèle d'atteindre chaque classe de GPU. Qwen3.8 27B est livré en cinq builds, du Q5_K_M pour une carte de 24 Go jusqu'à l'IQ2_XXS pour une carte de 8 Go. La requête du client ne change jamais ; l'hôte choisit le build que sa carte peut réellement faire tourner.

Un build ne devient réclamable sur une machine qu'après que cette machine l'a chargé et benchmarké. Les estimations décident de ce qui vaut la peine d'être téléchargé ; les mesures décident de ce qui vaut la peine d'être routé.

5. Les moteurs — et la question des conteneurs

mahout ne fait pas l'arithmétique lui-même. Il pilote un moteur d'inférence, et le moteur appartient au build, pas à l'hôte — c'est ce qui fait d'un nouveau moteur un ajout plutôt qu'une réécriture.

Alors, les images, c'est quoi exactement ?

Aujourd'hui, sur une machine hôte : aucune. Pas d'image Docker à tirer, pas de démon à installer, pas de root à accorder. Un binaire de 5 Mo et un fichier de modèle vérifié par checksum, c'est toute l'empreinte. Nous pensons que c'est la bonne forme pour un PC gamer dans un salon, et nous n'avons pas voulu prétendre le contraire pour sonner « cloud-native ».

Les conteneurs comptent à l'autre bout du marché. Quand le tiers vLLM arrivera, les images moteur seront des images amont référencées par digest — vllm/vllm-openai@sha256:…, pas un tag mouvant — et la liste des images qu'un hôte peut lancer est compilée dans la release de mahout elle-même. Le plan de contrôle peut dire à votre machine laquelle des images autorisées démarrer ; il ne peut jamais en introduire une nouvelle. Le conteneur n'a aucune sortie réseau et un montage en lecture seule des poids vérifiés.

Trois règles gouvernent ce tiers, et ce sont les mêmes qui gouvernent les poids des modèles :

• Épinglé par digest. Un digest est immuable et vérifié par le runtime ; un tag est une promesse que quelqu'un d'autre peut changer.
• Sur liste blanche dans le client. Un hôte lance ce que son propre binaire permet, pas ce qu'un serveur demande.
• Opt-in par hôte. Personne ne se réveille en train d'héberger un nouveau moteur.

Et le registre ?

Pour les moteurs amont, nous n'hébergeons aucune image — re-héberger une image publique ajoute des téraoctets de stockage et aucune sécurité, puisque le digest prouve déjà ce que vous avez reçu. Nous exploitons notre propre registre pour exactement un cas : les images que nous construisons. La première est le hook de vérification — un build du moteur qui émet un engagement cryptographique sur ses propres activations, pour que la sortie d'un job puisse être vérifiée plutôt que crue sur parole. Cette image doit être la nôtre : elle sera publiée depuis notre registre européen, signée et épinglée par digest comme tout le reste.

En bref : aucune image sur les hôtes aujourd'hui ; des images amont épinglées par digest quand le tiers vLLM arrivera ; notre propre registre uniquement pour les images que nous produisons nous-mêmes.

6. Ce qui est vérifié, et par qui

Un contrôle échoué n'est pas un avertissement : l'artefact est jeté et le job ne tourne pas. Nous préférons qu'un hôte ne serve rien plutôt qu'il serve quelque chose que nous ne pouvons pas nommer exactement.

7. L'argent

Les clients paient au token, en euros, par modèle, sans abonnement et sans minimum : vous rechargez un solde prépayé, et chaque clé API porte un plafond de dépense pour qu'une boucle emballée ne puisse pas le vider. Les hôtes reçoivent 80% des revenus des jobs qu'ils servent, versés par virement SEPA dès 50 €.

Le dashboard exprime les gains d'un hôte en euros par heure de service, calculés à partir du débit que sa propre carte a mesuré — pas d'une projection, et jamais en chiffre mensuel, car cela promettrait une demande que nous ne pouvons pas promettre.

8. Là où nous sommes honnêtes sur les limites

• Le moteur tourne aujourd'hui comme processus enfant non privilégié lié à localhost, pas dans un bac à sable d'appels système. Le durcissement (seccomp, Landlock, conteneurs sans egress) est prévu et pas encore fait.
• Linux et Windows x86_64 sont les seules plateformes hôtes publiées. macOS est portable en principe et pas livré en pratique.
• La vérification des sorties (engagements d'activations) est conçue et pas encore imposée ; les garanties d'aujourd'hui sont les reçus et la réputation.

La spécification technique distingue partout ce qui tourne aujourd'hui de ce qui est conçu. Le fichier AGENTS.md de mahout, dans le dépôt public, fait de même.