Wie ein Request eine GPU findet

Ihr Request geht nicht an einen Server von uns. Er geht in eine Warteschlange, und eine Maschine irgendwo in Europa holt ihn ab. Diese Indirektion ist das Produkt — es lohnt sich also zu wissen, wie sie genau funktioniert.

Der Weg, Schritt für Schritt

Das Gateway authentifiziert Sie und schätzt die Kosten. Reichen Guthaben oder Schlüssellimit nicht, bekommen Sie ein 402, bevor irgendetwas eingereiht wird — nie eine Überraschungsrechnung.
Der Job wird für ein Modell eingereiht. Er trägt Ihre Nachrichten und nichts über Sie: kein Name, keine E-Mail, kein Schlüssel jenseits einer internen Abrechnungs-ID.
Ein Host übernimmt ihn. Hosts pollen nach außen über HTTPS und nehmen Arbeit für die Modelle, die sie bedienen. Ein Host kann nur ein Modell übernehmen, das er auf genau dieser Maschine gebenchmarkt hat — die Katalogmeinung, dass ein Build passt, genügt nicht.
Tokens strömen zurück durch das Gateway, während sie entstehen. Sie sehen sie ankommen; wir warten nicht auf die ganze Antwort.
Der Job wird abgerechnet. Tokens gezählt, Guthaben auf den Mikro-Cent belastet, der Host mit 80% gutgeschrieben, der Prompt aus dem Protokoll entfernt.

Warum Hosts pollen statt angerufen zu werden

Jeder Host steht hinter einem Heimrouter. Müsste der Pool hinein, bräuchte jeder Host Portweiterleitung, eine feste Adresse oder einen Tunnel — und jedes davon ist ein Support-Ticket und ein Sicherheitsloch. Nach außen zu pollen heißt: eine Maschine funktioniert in dem Moment, in dem mahout startet, ohne Konfiguration und ohne offenen Port. Es ist die eine Entscheidung, die Consumer-Hardware praktikabel macht.

Was entscheidet, welcher Host Ihren Job bekommt

Heute: die Modelle, die ein Host qualifiziert hat, ob er frei ist, und ob er pausiert. Eine Maschine, die ihr Besitzer gerade aktiv nutzt, pausiert sich und hört schlicht auf zu übernehmen.

Was bewusst noch fehlt: reputationsgewichtetes Routing und Latenzklassen. Sie sind entworfen (siehe technische Spezifikation, §5) und nicht gebaut. Das sagen wir lieber, als einen klügeren Scheduler zu suggerieren als den, der läuft.

Wenn etwas schiefgeht

Kein Host übernimmt den Job — Sie bekommen einen Timeout und der Job gilt als fehlgeschlagen. Tokens, die niemand produziert hat, werden nicht berechnet.
Ein Host stirbt mitten in der Antwort — der Stream wird einer anderen Maschine übergeben, die exakt am bereits empfangenen Text weiterschreibt (einmal je Request). Eine halbe Antwort tritt nie als ganze auf, und ein doppelt glückloser Request scheitert ehrlich.
Ihr Guthaben endet mitten im Stream — der laufende Job wird beendet und abgerechnet; der nächste bekommt ein 402.

Was Sie das an Latenz kostet

Eine gepollte Warteschlange kostet einen Sekundenbruchteil, bevor die Arbeit beginnt. Dafür besteht der Pool aus Hardware, die sonst brachläge — darum ist der Token-Preis, was er ist. Für Chat und Batch ist der Tausch unsichtbar. Für harte Echtzeit ist es nicht die richtige Architektur, und das sagen wir Ihnen lieber, als es Ihnen zu verkaufen.