Quand un job tourne mal

Les machines qui servent votre requête sont le desktop de quelqu'un. On les éteint, elles perdent le Wi-Fi, leur propriétaire lance un jeu. Un réseau bâti là-dessus doit traiter la panne comme ordinaire plutôt qu'exceptionnelle — et être clair sur ce qui vous est facturé quand elle arrive.

Un hôte prend un job et disparaît

Chaque job réclamé a une échéance pour produire sa première sortie. Manquée, le job est repris et remis en file pour une autre machine — une fois. Vous voyez une réponse plus lente ; vous ne voyez pas d'erreur, et vous n'êtes pas facturé deux fois.

Si l'hôte meurt après qu'une sortie vous a atteint — crash en pleine réponse, ou stream silencieux au-delà de la fenêtre de décrochage — le job passe en continuation : une autre machine reçoit la conversation d'origine plus le texte exact que vous avez déjà vu, et le même stream reprend là où il s'était arrêté. Le moteur continue depuis le préfixe — en plein mot si c'est là qu'il est mort — donc rien de ce que vous avez reçu n'est contredit ni répété. Au plus une fois par requête : une flotte qui perd deux hôtes sur une même réponse échoue franchement plutôt que de s'acharner.

L'hôte mort n'est pas payé pour son segment (aucun reçu signé), et le prompt retraité ne vous est pas facturé — une continuation ne facture que ses nouveaux tokens. Une panne qui n'est pas la vôtre ne doit jamais apparaître deux fois sur votre facture.

Rien ne peut le servir

Si la requête porte une exigence de placement qu'aucun hôte vivant ne satisfait, vous recevez un 503 immédiat, nommant ce qui était requis. Si la file n'a simplement aucune machine libre, la requête attend, et une horloge murale — deux minutes par défaut — la termine en timeout plutôt que de la laisser pendre.

Ce que vous payez

Les tokens produits. Un job qui échoue avant de rien produire ne coûte rien. Un job qui échoue en cours facture les tokens que vous avez réellement reçus — c'est aussi ce dont l'hôte est payé 80%. Pas de surcoût d'échec, pas de minimum. La façon dont le prix lui-même est fixé est dans ce que vous payez et pourquoi.

Ce que voit l'hôte

Un modèle qui ne charge pas sur une machine est enregistré comme capacité échouée pour ce build, avec l'erreur, sur la page de la machine — pas abandonné en silence. La réponse honnête est généralement que la carte n'a pas la VRAM que le catalogue estimait, et c'est pourquoi seul un benchmark sur votre propre matériel est traité comme réel par le dashboard.

Un hôte qui réclame du travail à répétition sans le livrer ne gagne rien sur ces jobs : le paiement suit les tokens produits.

Ce qui n'y est pas encore

• Une continuation par requête. Si l'hôte de continuation meurt aussi, la requête échoue pour de bon. Deux machines mortes sur une réponse, c'est un problème de flotte — pas quelque chose à maquiller d'une troisième tentative.
• Une continuation, c'est une autre machine qui poursuit votre texte — cohérente avec tout ce qui est déjà reçu, mais pas le stream octet pour octet que la première machine aurait produit. Pour un pipeline déterministe, traitez un job failed_over dans vos logs comme le signal qu'il est.

Nommé ici parce qu'une page de fiabilité qui ne décrit que ce qui marche n'est pas une page de fiabilité. (Et les anciens trous que cette section avouait — pas d'alerte, pas de continuation entre hôtes — sont comblés : une machine silencieuse écrit à son propriétaire, et une mort en pleine réponse continue sur un autre hôte.)