un GPU est mort au milieu d'une phrase. la phrase s'est terminée.

Notre pool a une faiblesse structurelle assumée : il est fait d'ordinateurs qui ont le droit de s'en aller. La machine d'un hôte se met en pause dès que son propriétaire s'assoit devant, parce que c'est le contrat — la machine reste la sienne. Les disjoncteurs sautent. Le Wi-Fi tombe. Un PC gamer dans un salon n'est pas un datacenter, et nous n'avons jamais prétendu le contraire.

Jusqu'à cette semaine, cette honnêteté avait un angle coupant. Si la machine qui servait votre requête mourait avant le premier token, nous remettions le job en file et vous n'en saviez rien. Si elle mourait après le premier token — en pleine réponse, en plein mot — votre stream se terminait sur une erreur. Réessayer vous-même signifiait repayer le prompt et perdre tout ce qui était déjà généré.

Cette semaine, un GPU est mort au milieu d'une phrase sur notre banc de test, et la phrase s'est terminée quand même. Voici comment.

terminer la phrase de quelqu'un d'autre

Le correctif repose sur une propriété des modèles de chat qu'on oublie facilement : une conversation qui se termine par un message assistant inachevé est un prompt parfaitement valide. Donnez au modèle sa propre réponse à moitié écrite comme dernier message, et il ne recommence pas — il continue d'écrire, à partir du caractère exact où le texte s'arrête.

Alors quand un hôte disparaît en plein stream, le gateway construit un job de continuation : les messages d'origine, plus tout ce qui vous a déjà été livré, en message assistant final. N'importe quelle machine servant ce modèle peut le réclamer. Le moteur reprend la phrase là où elle s'est brisée — nous avons vérifié qu'il continue proprement depuis un demi-mot — et ne streame que les nouveaux tokens.

Votre connexion ne se ferme jamais. Les deux moitiés arrivent sur le même stream, recousues dans l'ordre, et la réponse se lit comme une seule réponse, parce que c'en est une.

comment le gateway s'en aperçoit

Deux déclencheurs. L'évident : l'hôte signale que le job a échoué. Le subtil : il cesse de signaler quoi que ce soit. Un stream qui n'a produit aucun token depuis 20 secondes est considéré comme mort — un moteur sain émet plusieurs tokens par seconde, donc vingt secondes de silence, ce n'est pas de la réflexion, c'est de l'absence.

Une continuation par requête, délibérément. Si la deuxième machine meurt aussi, vous recevez une erreur honnête, pas un relais sans fin qui masque un pool malade. Le failover sert à survivre à la malchance ; il ne doit jamais devenir une façon de ne pas voir la mauvaise santé.

qui paie la moitié morte

La comptabilité est l'endroit où une place de marché montre son caractère, alors nous l'avons écrite en règles :

• L'hôte mort ne gagne rien. Un versement adossé à un reçu exige un job terminé ; un stream abandonné n'en est pas un.
• Vous ne payez jamais le prompt deux fois. La continuation relit le prompt d'origine plus la réponse partielle, mais ces tokens d'entrée sont facturés zéro. Vous payez la sortie — chaque token exactement une fois, quelle que soit la machine qui l'a produit.
• La machine qui sauve gagne sa propre sortie. Elle est payée pour les tokens qu'elle a générés, pas au rabais pour être arrivée deuxième.

Si vous intégrez l'API et voulez savoir quand c'est arrivé, le dernier chunk porte x_elephant: { resumed: true } (les réponses non streamées reçoivent un en-tête x-elephant-resumed). La plupart des utilisateurs ne regarderont jamais. Le but de la fonctionnalité, c'est précisément qu'ils n'aient jamais à le faire.

ce que ça ne répare pas

Un modèle ne peut pas dé-dire des tokens. Si la première machine a émis la moitié d'une réponse, ces mots sont déjà sur votre écran ; la continuation écrit la suite, elle ne révise pas. Et un pool avec une seule machine qui sert garde un point de défaillance unique — c'est exactement pourquoi le prochain jalon de notre liste est de la redondance ennuyeuse et délibérée.

La disparition du matériel grand public n'est pas un cas limite pour nous ; c'est le substrat. Le travail n'a jamais été de faire semblant que les machines sont fiables. C'était de rendre la réponse fiable malgré tout.

Quand un job tourne mal · Comment une requête trouve un GPU · Essayer l'API