Comment une requête trouve un GPU

Votre requête ne va pas vers un serveur à nous. Elle va dans une file, et une machine quelque part en Europe la ramasse. Cette indirection est le produit — autant savoir exactement comment elle fonctionne.

Le chemin, étape par étape

1. La gateway vous authentifie et estime ce que l'appel coûtera. Si votre solde prépayé ou le plafond de la clé ne le couvre pas, vous recevez un 402 avant que rien ne soit mis en file — jamais de facture surprise.
2. Le job est mis en file pour un modèle. Il transporte vos messages et rien sur vous : pas de nom, pas d'e-mail, pas de clé au-delà d'un identifiant interne pour la facturation.
3. Un hôte le réclame. Les hôtes interrogent vers l'extérieur en HTTPS et prennent du travail pour les modèles qu'ils servent. Un hôte ne peut réclamer qu'un modèle qu'il a benchmarké sur cette machine — l'avis du catalogue qu'un build tient ne suffit pas.
4. Les tokens reviennent en stream à travers la gateway au fur et à mesure. Vous les voyez arriver ; nous n'attendons pas la réponse entière.
5. Le job se solde. Les tokens sont comptés, votre solde est débité au micro-centime, l'hôte est crédité de 80%, et le prompt disparaît du registre.

Pourquoi les hôtes interrogent au lieu d'être appelés

Chaque hôte est derrière un routeur domestique. Si le pool devait entrer, chaque hôte aurait besoin d'une redirection de port, d'une adresse fixe ou d'un tunnel — et chacun de ces trois est un ticket de support et un trou de sécurité. Interroger vers l'extérieur, c'est une machine qui fonctionne dès que mahout démarre, sans rien configurer et sans port entrant. C'est la décision unique qui rend le matériel grand public praticable.

Ce qui décide quel hôte reçoit votre job

Aujourd'hui : les modèles qu'un hôte a qualifiés, s'il est libre, et s'il est en pause. Une machine que son propriétaire utilise activement se met en pause et cesse simplement de réclamer.

Ce que cela n'inclut délibérément pas encore : le routage pondéré par réputation et les classes de latence. Ils sont conçus (voir la spécification technique, §5) et pas construits. Nous préférons le dire que laisser croire à un scheduler plus malin que celui qui tourne.

Quand quelque chose tourne mal

• Aucun hôte ne réclame le job — vous recevez un timeout et le job est marqué échoué. Vous n'êtes pas facturé pour des tokens que personne n'a produits.
• Un hôte meurt en pleine réponse — le stream passe à une autre machine, qui continue depuis le texte exact que vous avez déjà reçu (une fois par requête). Une demi-réponse n'est jamais présentée comme entière, et une requête doublement malchanceuse échoue honnêtement.
• Votre crédit s'épuise en plein stream — le job en cours se termine et se solde ; le suivant reçoit un 402.

Ce que cela vous coûte en latence

Une file interrogée ajoute une fraction de seconde avant que le travail commence. En échange, le pool est fait de matériel qui autrement dormirait — c'est pourquoi le prix au token est ce qu'il est. Pour le chat et le batch, l'échange est invisible. Pour du temps réel dur, ce n'est pas la bonne architecture, et nous préférons vous le dire que vous le vendre.