Eine GPU starb mitten im Satz. Der Satz wurde fertig.

Unser Pool hat eine ehrliche strukturelle Schwäche: Er besteht aus Computern, die jederzeit gehen dürfen. Die Maschine eines Hosts pausiert sich selbst, sobald ihr Besitzer sich davorsetzt, denn genau das ist die Abmachung — die Maschine bleibt seine. Sicherungen fliegen. WLAN bricht ab. Ein Gaming-PC im Wohnzimmer ist kein Rechenzentrum, und wir haben nie etwas anderes behauptet.

Bis diese Woche hatte diese Ehrlichkeit eine scharfe Kante. Starb die Maschine, die Ihre Anfrage bediente, vor dem ersten Token, stellten wir den Job neu in die Warteschlange, und Sie merkten nichts. Starb sie nach dem ersten Token — mitten in der Antwort, mitten im Wort —, endete Ihr Stream mit einem Fehler. Selbst neu anzufragen hieß, den Prompt noch einmal zu bezahlen und alles bereits Generierte zu verlieren.

Diese Woche starb auf unserem Teststand eine GPU mitten im Satz, und der Satz wurde trotzdem fertig. So geht das.

Den Satz eines anderen zu Ende schreiben

Der Fix beruht auf einer Eigenschaft von Chat-Modellen, die man leicht vergisst: Eine Konversation, die mit einer unvollendeten Assistant-Nachricht endet, ist ein völlig gültiger Prompt. Geben Sie dem Modell seine eigene halb geschriebene Antwort als letzte Nachricht, und es fängt nicht von vorn an — es schreibt weiter, exakt ab dem Zeichen, an dem der Text aufhört.

Verschwindet also ein Host mitten im Stream, baut das Gateway einen Fortsetzungs-Job: die ursprünglichen Nachrichten, plus alles, was Ihnen bereits geliefert wurde, als abschließende Assistant-Nachricht. Jede Maschine, die dieses Modell bedient, kann ihn beanspruchen. Die Engine nimmt den Satz dort auf, wo er abriss — wir haben geprüft, dass sie sauber ab einem halben Wort weiterschreibt — und streamt nur die neuen Token.

Ihre Verbindung wird nie geschlossen. Die beiden Hälften kommen auf demselben Stream an, in der richtigen Reihenfolge zusammengefügt, und die Antwort liest sich wie eine einzige Antwort, weil sie eine ist.

Woran das Gateway es merkt

Zwei Auslöser. Der offensichtliche: Der Host meldet den Job als fehlgeschlagen. Der subtile: Er meldet gar nichts mehr. Ein Stream, der 20 Sekunden lang keinen Token produziert hat, gilt als tot — eine gesunde Engine liefert viele Token pro Sekunde, zwanzig Sekunden Stille sind also kein Nachdenken, sondern Abwesenheit.

Eine Fortsetzung pro Anfrage, mit Absicht. Stirbt auch die zweite Maschine, bekommen Sie einen ehrlichen Fehler, keinen endlosen Staffellauf, der einen kranken Pool kaschiert. Failover ist dafür da, Pech zu überleben; es darf nie zur Methode werden, schlechte Gesundheit zu übersehen.

Wer die tote Hälfte bezahlt

An der Abrechnung zeigt ein Marktplatz seinen Charakter, also haben wir sie als Regeln festgeschrieben:

• Der tote Host verdient nichts. Eine quittungsgestützte Auszahlung setzt einen abgeschlossenen Job voraus; ein Stream, den er im Stich gelassen hat, ist keiner.
• Sie zahlen den Prompt nie zweimal. Die Fortsetzung liest den ursprünglichen Prompt plus die Teilantwort erneut ein, aber diese Eingabe-Token werden mit null berechnet. Sie zahlen für Ausgabe — jeden Token genau einmal, egal welche Maschine ihn produziert hat.
• Die rettende Maschine verdient ihre eigene Ausgabe. Sie wird für die Token bezahlt, die sie generiert hat — ohne Abschlag dafür, als Zweite gekommen zu sein.

Wenn Sie gegen die API integrieren und wissen wollen, wann das passiert ist: Der letzte Chunk trägt x_elephant: { resumed: true } (gepufferte Antworten bekommen einen x-elephant-resumed-Header). Die meisten werden nie nachsehen. Der Sinn des Features ist genau, dass sie es nie müssen.

Was es nicht repariert

Ein Modell kann Token nicht zurücknehmen. Hat die erste Maschine eine halbe Antwort ausgegeben, stehen diese Worte bereits auf Ihrem Bildschirm; die Fortsetzung schreibt, was folgt, sie revidiert nicht. Und ein Pool mit einer einzigen bedienenden Maschine hat weiterhin einen einzelnen Ausfallpunkt — genau deshalb ist der nächste Meilenstein auf unserer Liste langweilige, bewusste Redundanz.

Dass Consumer-Hardware verschwindet, ist für uns kein Randfall; es ist das Substrat. Die Aufgabe war nie, so zu tun, als wären die Maschinen zuverlässig. Sie war, die Antwort trotzdem zuverlässig zu machen.

Wenn ein Job schiefgeht · Wie ein Request eine GPU findet · Die API ausprobieren