Wenn ein Job schiefgeht

Die Maschinen, die Ihren Request bedienen, sind jemandes Desktop. Sie werden ausgeschaltet, verlieren WLAN, ihr Besitzer startet ein Spiel. Ein Netzwerk auf dieser Basis muss Ausfall als gewöhnlich behandeln statt als Ausnahme — und klar sagen, was berechnet wird, wenn er eintritt.

Ein Host nimmt einen Job und verschwindet

Jeder übernommene Job hat eine Frist für die erste Ausgabe. Verstreicht sie, wird der Job zurückgenommen und für eine andere Maschine neu eingereiht — einmal. Sie sehen eine langsamere Antwort; Sie sehen keinen Fehler, und Sie zahlen nicht doppelt.

Stirbt der Host, nachdem Ausgabe Sie erreicht hat — Absturz mitten in der Antwort, oder ein Stream, der länger als das Stillstandsfenster schweigt — geht der Job in eine Fortsetzung über: eine andere Maschine erhält das ursprüngliche Gespräch plus den exakten Text, den Sie schon gesehen haben, und derselbe Stream macht dort weiter, wo er stehen blieb. Die Engine setzt am Präfix an — mitten im Wort, wenn es dort starb — nichts Empfangenes wird widersprochen oder wiederholt. Höchstens einmal je Request: eine Flotte, die zwei Hosts auf einer Antwort verliert, scheitert laut statt sich festzubeißen.

Der tote Host wird für sein Segment nicht bezahlt (keine signierte Quittung), und der erneut verarbeitete Prompt wird Ihnen nicht berechnet — eine Fortsetzung berechnet nur ihre neuen Tokens. Ein Ausfall, der nie Ihrer war, darf nie zweimal auf Ihrer Rechnung stehen.

Nichts kann ihn bedienen

Trägt der Request eine Platzierungsanforderung, die kein lebender Host erfüllt, bekommen Sie sofort ein 503, das die Anforderung nennt. Hat die Warteschlange schlicht keine freie Maschine, wartet der Request, und eine Wanduhr — standardmäßig zwei Minuten — beendet ihn mit einem Timeout, statt ihn hängen zu lassen.

Was Sie zahlen

Produzierte Tokens. Ein Job, der vor jeder Ausgabe scheitert, kostet nichts. Ein Job, der unterwegs scheitert, berechnet die Tokens, die Sie wirklich erhalten haben — wovon der Host seine 80% bekommt. Kein Fehlschlag-Zuschlag, kein Minimum. Wie der Preis selbst entsteht, steht in was Sie zahlen und warum.

Was der Host sieht

Ein Modell, das auf einer Maschine nicht lädt, wird als fehlgeschlagene Fähigkeit für diesen Build festgehalten, mit dem Fehler, auf der Seite der Maschine — nicht still verworfen. Die ehrliche Antwort ist meist, dass die Karte nicht das VRAM hat, das der Katalog schätzte — weshalb nur ein Benchmark auf Ihrer eigenen Hardware vom Dashboard als real behandelt wird.

Ein Host, der wiederholt Arbeit übernimmt und nicht liefert, verdient an diesen Jobs nichts: die Bezahlung folgt produzierten Tokens.

Was noch fehlt

• Eine Fortsetzung je Request. Stirbt auch der Fortsetzungs-Host, scheitert der Request endgültig. Zwei tote Maschinen auf einer Antwort sind ein Flottenproblem — nichts, das ein dritter Versuch übertünchen sollte.
• Eine Fortsetzung ist eine andere Maschine, die Ihren Text weiterschreibt — kohärent mit allem bereits Empfangenen, aber nicht der byte-gleiche Stream, den die erste Maschine produziert hätte. Für deterministische Pipelines: behandeln Sie einen failed_over-Job in Ihren Logs als das Signal, das er ist.

Steht hier, weil eine Zuverlässigkeitsseite, die nur das Funktionierende beschreibt, keine Zuverlässigkeitsseite ist. (Die alten Lücken dieses Abschnitts — keine Alarme, keine Fortsetzung — sind geschlossen: eine stille Maschine schreibt ihrem Besitzer, und ein Tod mitten in der Antwort läuft auf einem anderen Host weiter.)