Wie ElephantPool funktioniert

1. Die Form des Systems

Drei Parteien, ein Vertrag zwischen ihnen.

Der Host pollt nach außen; nichts verbindet sich zu ihm. Diese eine Entscheidung erklärt, warum eine GPU hinter einem Heimrouter ohne jede Konfiguration funktioniert — und warum ein Host nie einen Port ins Internet öffnet.

2. Was mit einem Request passiert

1. Ihr Aufruf erreicht das Gateway mit einem API-Schlüssel. Wir prüfen den Schlüssel, schätzen die Kosten und bestätigen, dass Guthaben und Ausgabenlimit sie decken.
2. Der Job wird eingereiht für das angefragte Modell. Er trägt Ihre Nachrichten und nichts über Sie.
3. Ein Host übernimmt ihn — einer, der per Benchmark auf genau dieser Maschine bewiesen hat, dass er das Modell bedienen kann.
4. Die GPU produziert Tokens, gestreamt durch das Gateway zu Ihnen, während sie entstehen.
5. Der Job wird abgerechnet. Tokens werden gezählt, Ihr Guthaben auf den Mikro-Cent belastet, der Host bekommt 80% gutgeschrieben, und der Prompt fällt aus dem Protokoll. Was bleibt: Zähler und Zeitstempel — kein Text.
6. Der Host signiert eine Quittung mit einem Schlüssel, der seine Maschine nie verlässt: Modell, exakter Build, Token-Zahlen, Timing.

Prompts leben im Speicher, solange der Job dauert. Sie werden nicht auf Platte geschrieben, nicht geloggt und nicht fürs Training verwendet — weder von uns noch von Hosts.

3. mahout — der Agent auf dem Host

mahout ist ein einzelnes Open-Source-Rust-Binary von rund 5 MB, benannt nach der Person, die den Elefanten reitet. Es läuft als gewöhnlicher Benutzer, braucht kein Root und tut sechs Dinge:

• Sondiert die Maschine — CPU, RAM, GPUs und ihr VRAM.
• Registriert sich mit einem Einmal-Code aus dem Dashboard und erzeugt lokal eine ed25519-Identität; der private Schlüssel verlässt die Maschine nie.
• Lädt und verifiziert Modellgewichte und Engine in einen inhaltsadressierten Cache — geprüft gegen gepinnte SHA-256-Digests beim Download und bei jedem Laden erneut.
• Beaufsichtigt die Engine: startet sie, überwacht ihre Gesundheit, startet sie einmal neu, wenn sie stirbt, stoppt sie sauber.
• Pollt und bedient Jobs, Tokens in Batches zurückgestreamt.
• Signiert eine Quittung pro Job, angehängt an ein lokales Protokoll, das Sie offline mit mahout receipts verify nachprüfen können.

Es pausiert von selbst, während Sie die Maschine benutzen, und mahout uninstall zeigt einen Löschplan, bevor es irgendetwas entfernt. Quelltext und Installer sind öffentlich.

4. Modelle sind Builds, keine Dateien

Ein Modell ist, was ein Kunde anfragt (qwen3.8-27b). Ein Build ist ein konkretes Artefakt: eine Quantisierung, eine Engine, eine exakte Datei aus einer exakten Upstream-Revision, mit veröffentlichtem SHA-256.

Diese Trennung lässt ein Modell jede GPU-Klasse erreichen. Qwen3.8 27B kommt in fünf Builds, von Q5_K_M für eine 24-GB-Karte bis IQ2_XXS für eine 8-GB-Karte. Die Anfrage des Kunden ändert sich nie; der Host wählt den Build, den seine Karte wirklich fahren kann.

Ein Build wird auf einer Maschine erst beanspruchbar, nachdem diese Maschine ihn geladen und gebenchmarkt hat. Schätzungen entscheiden, was sich zu laden lohnt; Messungen entscheiden, was sich zu routen lohnt.

5. Engines — und die Container-Frage

mahout rechnet nicht selbst. Es steuert eine Inferenz-Engine, und die Engine gehört zum Build, nicht zum Host — deshalb ist eine neue Engine ein Zusatz statt einer Neuschreibung.

Was sind die Images denn nun genau?

Heute, auf einer Host-Maschine: keine. Kein Docker-Image zu ziehen, kein Daemon zu installieren, kein Root zu gewähren. Ein 5-MB-Binary und eine per Checksumme geprüfte Modelldatei sind der gesamte Fußabdruck. Für einen Gaming-PC im Wohnzimmer halten wir das für die richtige Form — und wollten nichts anderes vorgeben, nur um cloud-native zu klingen.

Container zählen am anderen Ende des Markts. Wenn die vLLM-Stufe kommt, werden Engine-Images Upstream-Images per Digest sein — vllm/vllm-openai@sha256:…, kein wandernder Tag — und die Liste der Images, die ein Host fahren darf, ist in das mahout-Release selbst kompiliert. Die Kontrollebene kann Ihrer Maschine sagen, welches erlaubte Image sie starten soll; ein neues einführen kann sie nie. Der Container bekommt keinen Netzwerkausgang und ein Nur-Lese-Mount der verifizierten Gewichte.

Drei Regeln regieren diese Stufe — dieselben, die auch Modellgewichte regieren:

• Per Digest gepinnt. Ein Digest ist unveränderlich und wird vom Runtime geprüft; ein Tag ist ein Versprechen, das jemand anderes ändern kann.
• Allow-List im Client. Ein Host fährt, was sein eigenes Binary erlaubt — nicht, was ein Server verlangt.
• Opt-in pro Host. Niemand wacht auf und hostet eine neue Engine.

Und die Registry?

Für Upstream-Engines hosten wir gar keine Images — ein öffentliches Image zu spiegeln kostet Terabytes an Speicher und bringt null Sicherheit, denn der Digest beweist bereits, was ankam. Eine eigene Registry betreiben wir für genau einen Fall: Images, die wir bauen. Das erste ist der Verifikations-Hook — ein Engine-Build, der ein kryptografisches Commitment über seine eigenen Aktivierungen ausgibt, damit die Ausgabe eines Jobs geprüft statt geglaubt werden kann. Dieses Image muss unseres sein: veröffentlicht aus unserer eigenen EU-Registry, signiert und per Digest gepinnt wie alles andere.

Kurz: heute keine Images auf Hosts; Upstream-Images per Digest, wenn die vLLM-Stufe landet; eine eigene Registry nur für Images, die wir selbst herstellen.

6. Was verifiziert wird, und von wem

Eine fehlgeschlagene Prüfung ist keine Warnung: das Artefakt wird verworfen und der Job läuft nicht. Lieber bedient ein Host nichts, als etwas, das wir nicht exakt benennen können.

7. Das Geld

Kunden zahlen pro Token, in Euro, je Modell, ohne Abo und ohne Minimum: Sie laden ein Prepaid-Guthaben auf, und jeder API-Schlüssel trägt ein Ausgabenlimit, damit eine außer Kontrolle geratene Schleife es nicht leeren kann. Hosts erhalten 80% des Umsatzes der Jobs, die sie bedienen, per SEPA-Überweisung ab 50 €.

Das Dashboard nennt die Einnahmen eines Hosts in Euro pro Bedienstunde, berechnet aus der Dekodier-Rate, die seine eigene Karte gemessen hat — nie eine Projektion, und nie eine Monatszahl, denn das hieße Nachfrage zu versprechen, die wir nicht versprechen können.

8. Wo wir ehrlich über Grenzen sind

• Die Engine läuft heute als unprivilegierter Kindprozess an localhost gebunden, nicht in einer Syscall-Sandbox. Härtung (seccomp, Landlock, Container ohne Egress) ist geplant und noch nicht gebaut.
• Linux und Windows x86_64 sind die einzigen veröffentlichten Host-Plattformen. macOS ist im Prinzip portierbar und in der Praxis nicht ausgeliefert.
• Ausgabe-Verifikation (Aktivierungs-Commitments) ist entworfen und noch nicht erzwungen; die heutigen Garantien sind Quittungen und Reputation.

Die technische Spezifikation unterscheidet durchgehend zwischen dem, was heute läuft, und dem, was entworfen ist. mahouts eigenes AGENTS.md im öffentlichen Repository tut dasselbe.