Le proxy hébergé est le mécanisme d'accès, pas le modèle que vous servez

La commande unique hf jobs run de Hugging Face dresse un endpoint vLLM privé et compatible OpenAI en une seule ligne, et la partie qui porte tout n'est pas le modèle — c'est le proxy hébergé qui restreint chaque requête à votre namespace. Selon la publication Hugging Face de 2026 « Run a vLLM Server on HF Jobs in One Command », un flavor a10g-large coûte 1,50 $/heure facturé à la seconde, et l'URL exposée n'est accessible qu'avec un token HF doté d'un accès en lecture au job. La porte est provisionnée, pas construite.

C'est la même forme à laquelle nous revenons sans cesse : la couche de routage décide qui reçoit une réponse avant que le modèle parle. Nommez le mécanisme, puis jugez si le mécanisme est réellement présent et mesure — c'est le Théorème 3 des 21 papiers (une propriété est garantie exactement quand son mécanisme est implémenté et mesure). Ici la propriété est accès-limité-à-moi, et le mécanisme est un proxy hébergé qui exige un bearer token lié à mon namespace. Le modèle est en aval de cette décision.

Ce que HF Jobs provisionne réellement

La publication est franche sur ce que la commande vous donne : « hf jobs run est docker run pour l'infrastructure HF. » Vous choisissez une image (vllm/vllm-openai:latest), un flavor de GPU, un port à exposer et un timeout. La plateforme tire l'image sur un GPU loué, démarre vLLM et route le port du conteneur à travers un proxy public de jobs. Ce proxy est le seul mécanisme à faire trois choses à la fois : il vous donne une URL stable, il termine la requête et il applique la porte du bearer token.

L'honnêteté de la publication mérite une pause. Les auteurs la distinguent d'un service de production dans la même phrase qui la présente : « Si vous cherchez un service géré prêt pour la production, c'est à cela que servent les Inference Endpoints. » Ils n'appellent pas Jobs production. Ils l'appellent « la façon la plus rapide de dresser un modèle pour des tests, des evals ou de la génération par lots. » C'est un fournisseur qui nomme la portée réelle du mécanisme au lieu de la survendre — la posture que nous essayons de tenir sur notre propre feuille de route, où Wallet & Token 🔵, Super App 🔵 et Community Credit 🔵 restent Roadmap jusqu'à ce que leurs mécanismes soient livrés et mesurés.

Le modèle d'exposition de port est la décision de routage

Le flag --expose 8000 est l'endroit où le routage se produit. Il dit à la plateforme de router le port du conteneur à travers le proxy public de jobs et de renvoyer une URL de la forme https://<job_id>--8000.hf.jobs. Tout le reste — le choix du modèle, la taille de tensor-parallel, le modèle de chat — est la configuration de ce qui tourne derrière cette route. La route est la frontière. C'est la même forme que notre règle selon laquelle la persistance est toujours atteinte via un port (un trait), jamais via un PgPool concret : l'appelant dépend de la frontière, pas de ce qui se trouve derrière.

La porte du bearer token est la portée d'accès

La publication est explicite et directe sur ce que le proxy applique : « Chaque requête doit porter un token HF avec un accès en lecture au namespace du job. Une simple visite de navigateur sera rejetée. En effet, le proxy de jobs est votre porte d'API : l'accès est limité à vous (et à votre org). » C'est toute l'histoire du contrôle d'accès. Il n'y a pas de seconde couche d'auth dans vLLM. Le proxy est la porte.

[UNIQUE INSIGHT] L'idée porteuse est que la frontière d'accès est une propriété de la couche de routage, pas du modèle ou de l'application derrière. Un serveur de modèle sans proxy est un port ouvert. Le même serveur derrière un proxy limité par namespace est un endpoint privé. Le modèle n'a pas changé ; le routage, oui. C'est « the space is the router » en miniature : la topologie (qui peut atteindre quoi) est décidée avant que quoi que ce soit réponde. Chez Everythink, la topologie network→community→room route une requête avant qu'une Sister ou l'Oracle ne la voie — le room est la porte, pas le modèle derrière le room.

La facturation à la seconde est le mécanisme de contrôle des coûts

Le modèle de facturation n'est pas une note de bas de page. Jobs facture à la seconde d'utilisation matérielle, et la publication vous dit d'arrêter le serveur quand vous avez fini : hf jobs cancel <job_id>. Le flag --timeout est un filet de sécurité qui arrête automatiquement le job, mais « annuler explicitement est moins cher ». Le mécanisme qui contrôle le coût est la commande cancel plus le compteur par seconde — pas une promesse d'efficacité.

C'est le Théorème 3 à nouveau, appliqué au coût. La propriété je ne paie pas pour l'inactivité est garantie par le mécanisme scale-to-zero, et scale-to-zero est présent dans les Inference Endpoints, pas dans Jobs. Dans Jobs, la propriété je ne paie pas pour l'inactivité n'est garantie que par le mécanisme j'annule explicitement, ce qui signifie qu'elle n'est garantie que si un humain ou un script déclenche cancel. Si personne n'annule, vous payez jusqu'au timeout. La publication l'honore en nommant les deux produits côte à côte au lieu de prétendre que l'un fait les deux.

Le timeout est un filet de sécurité, pas un budget

Un --timeout 2h ne signifie pas « cela coûte au maximum deux heures de GPU ». Il signifie « si j'oublie d'annuler, la plateforme arrêtera le job au bout de deux heures ». La différence compte. Un filet de sécurité vous rattrape quand le mécanisme primaire (annuler) échoue ; il ne remplace pas le mécanisme primaire. Nous traitons notre propre chemin de rollback de la même façon : un flux deploy-and-pray a besoin d'un mécanisme de rollback, et le filet de sécurité (un timeout, une sonde de santé) n'est pas le mécanisme — le rollback explicite l'est.

Jobs versus Inference Endpoints est un appariement de mécanismes

La comparaison finale de la publication est la partie la plus propre, parce qu'elle refuse de classer les deux produits et apparie plutôt chacun à une tâche. Recourez à HF Jobs quand vous voulez « une flexibilité et un contrôle maximaux » — vous choisissez l'image, les flags exacts de vllm serve et le matériel, et vous payez à la seconde tant que le job tourne. Recourez aux Inference Endpoints quand vous voulez « quelque chose de plus prêt pour la production » — un contrôle d'accès plus fin (public, protégé ou privé) et scale-to-zero pour ne pas être facturé pendant l'inactivité.

C'est un appariement de mécanismes, pas une comparaison de fonctionnalités. La question n'est pas « lequel est meilleur ». La question est « quel mécanisme garantit la propriété dont j'ai besoin ». Si la propriété est expérimenter, puis démonter, Jobs correspond : la facturation à la seconde plus l'annulation explicite est le mécanisme, et la flexibilité sur les flags de serve est le mécanisme pour tester un modèle avant de s'engager. Si la propriété est endpoint durable sans dépense d'inactivité, les Inference Endpoints correspondent : scale-to-zero est le mécanisme qui garantit aucune-facturation-d'inactivité, et le contrôle d'accès plus fin est le mécanisme qui garantit la portée voulue sans gateway sur mesure.

[ORIGINAL DATA] La série des 21 papiers appelle cela la correspondance mécanisme-propriété : une propriété est garantie exactement quand son mécanisme est implémenté et mesure. Appliqué ici, la décision entre Jobs et Endpoints n'est pas une question de goût — c'est une recherche. Listez la propriété dont vous avez besoin (coût-inactivité-zéro, accès-public, contrôle-exact-des-flags, expérience-à-la-seconde), puis choisissez le produit dont le mécanisme implémente et mesure cette propriété. Si aucun ne le fait, aucun n'est le bon outil, et aucune configuration ne le rendra ainsi.

Le mécanisme de sharding doit correspondre au flavor

La section de la publication sur les modèles plus gros cache une règle de mécanisme qui vaut la peine d'être extraite. Pour servir un Qwen3.5 mixture-of-experts de 122B sur 2× H200, vous fixez --tensor-parallel-size 2, et la règle est énoncée clairement : « --tensor-parallel-size devrait correspondre au nombre de GPUs du flavor (h200x2 → 2, h200x8 → 8). » Désaccordez les deux et le mécanisme ne fonctionne pas — le modèle ne se shardera pas correctement entre les GPUs que vous avez réellement.

La même section nomme le mécanisme de mémoire : pour l'architecture hybride Mamba/attention avec un contexte par défaut de 256K tokens, « plafonner la longueur du contexte et le nombre de séquences concurrentes le maintient dans la mémoire des GPUs. Si un modèle échoue au démarrage avec une erreur d'out-of-memory ou de cache-block, la première chose à essayer est de réduire ces deux-là ». Le mécanisme pour faire tenir un modèle en mémoire est plafonner --max-model-len et --max-num-seqs au budget que les GPUs ont réellement. C'est une contrainte mesurée, pas une affirmation d'impression sur la capacité.

Le harness est le mécanisme de l'agent, pas le modèle

La section de la publication sur l'agent de codage Pi est une illustration silencieuse d'une règle que nous tenons fermement : le harness est le mécanisme, pas le modèle. Pour soutenir un agent de codage terminal, vous relancez vLLM avec --enable-auto-tool-choice et --tool-call-parser hermes, parce que « les agents pilotent le modèle via des tool calls, et vLLM ne les accepte que si le serveur est lancé avec tool calling activé ». Le modèle n'a pas gagné une capacité. Le harness (analyse des tool calls, la boucle de l'agent Pi) a été câblé au serveur, et ce câblage est le mécanisme qui fait fonctionner les tool calls. Nous l'avons écrit ailleurs : vous n'engagez pas un agent, vous câblez un mécanisme. L'agent est le câblage ; le modèle est le moteur derrière.

Cross-domain : the space is the router

Chaque mécanisme de la publication HF Jobs a un parallèle trans-domaines dans notre propre stack, et les nommer est comment nous gardons l'architecture honnête plutôt qu'aspirationnelle.

• Le proxy comme porte ↔ le room comme porte. Le proxy de jobs HF restreint l'accès à un namespace. Chez Everythink, la topologie network→community→room restreint l'accès à un room. « The space is the router » signifie que le room route une requête avant qu'une Sister ou l'Oracle ne réponde — le room est la porte, le modèle est derrière la porte. La forme du mécanisme est identique ; le domaine est différent.
• Le bearer token ↔ l'Eye Key. Le token HF avec accès en lecture au namespace du job est le credential qui vous porte à travers le proxy. Notre Eye Key (avec un espace) est le credential qui vous porte à travers notre porte d'API, et le texte en clair de l'Eye Key ne touche jamais le disque — seul le HMAC et l'empreinte persistent. La propriété souveraineté-du-credential est garantie par le mécanisme HMAC-avant-persistance, comme accès-limité-à-moi est garanti par bearer-token-lié-au-namespace. Les deux sont des garanties de la couche de routage, pas du modèle.
• Tensor-parallel ↔ normalisation de l'Oracle. La règle de sharding (la taille de parallélisme correspond au nombre de GPUs) est un mécanisme d'appariement de contraintes. Notre Oracle ✅ normalise les probabilités en exactement un endroit — les consommateurs s'appuient sur sum(probability) ≈ 1.0, scénarios triés décroissant, entropie en nats. Les deux sont « le mécanisme doit correspondre à la contrainte » : taille de shard au nombre de GPUs, normalisation à un endroit. Appariez mal et la garantie se casse.

[PERSONAL EXPERIENCE] Le HAI Engine tourne en production depuis 2016, et la leçon que nous réapprenons sans cesse est celle que la publication HF Jobs énonce sans fioritures : la porte est la première chose que vous provisionnez, et le modèle est la seconde que vous configurez. Un modèle derrière la mauvaise porte est un port ouvert. Un modèle derrière la bonne porte est un produit.

Ce que cela signifie pour bâtir sur Everythink

La stack d'Everythink est façonnée par la même règle que suit la publication HF Jobs. Les Sisters ✅ n'écrivent jamais dans Postgres — elles renvoient un SisterOutput et le Loom persiste via un port (LoomStore), comme vLLM sert via un proxy. L'Oracle ✅ fusionne les brouillons des Sisters en un Ensemble normalisé en exactement un endroit, comme le proxy est le seul endroit où l'accès est appliqué. Le World Monitor ✅ est une gateway qui lit depuis un cache, jamais depuis les upstreams, bornée par notre calendrier de polling plutôt que par le nombre de clients — comme le proxy de jobs borne l'accès par namespace plutôt que par modèle.

Les modules qui ne sont pas encore Production portent leurs propres étiquettes d'honnêteté et restent étiquetés. Matchmaking ⚠️, Marketplace ⚠️ et Calendar ⚠️ sont Partial — le mécanisme existe mais ne mesure pas encore à pleine échelle. Wallet & Token 🔵, Super App 🔵 et Community Credit 🔵 sont Roadmap, pré-revenu, soumis à la revue Howey, et nous ne les promouvons pas en silence. C'est la même posture que la publication HF Jobs adopte quand elle sépare Jobs des Endpoints : nommez le mécanisme, nommez sa portée, n'améliorez pas un état.

Portée civile et défensive uniquement. Nous ne construisons pas d'outils de targeting ni offensifs. Une couche de routage qui restreint l'accès est un mécanisme défensif — elle décide qui atteint quoi — et c'est la seule direction vers laquelle nous la pointons.

Points-clés

• Le proxy est la porte, pas le modèle. Le proxy de jobs HF restreint chaque requête à votre namespace via un bearer token. L'accès est une propriété de la couche de routage, pas du modèle derrière.
• La facturation à la seconde est un mécanisme, pas un prix. La propriété sans dépense d'inactivité est garantie par scale-to-zero (Inference Endpoints) ou par annulation explicite (Jobs). Le timeout est un filet de sécurité, pas le mécanisme primaire.
• Jobs versus Endpoints est un appariement de mécanismes. Listez la propriété dont vous avez besoin, puis choisissez le produit dont le mécanisme l'implémente et la mesure. C'est une recherche, pas une question de goût.
• La taille de shard doit correspondre au nombre de GPUs ; les plafonds de mémoire doivent correspondre au budget GPU. Les deux sont des mécanismes d'appariement de contraintes. Appariez mal et la garantie se casse.
• Le harness est le mécanisme de l'agent. Les tool calls fonctionnent parce que le serveur a été lancé avec l'analyse des tool calls activée, pas parce que le modèle est devenu plus malin. Vous câblez un mécanisme ; vous n'engagez pas un agent.
• The space is the router. Le room route avant que le modèle ne réponde, comme le proxy route avant que vLLM ne réponde. La porte est provisionnée d'abord ; le modèle configuré ensuite.

Questions fréquentes

Quel est l'unique mécanisme qui rend un endpoint HF Jobs privé ? Le proxy de jobs hébergé. Chaque requête doit porter un token HF avec accès en lecture au namespace du job, et une simple visite de navigateur est rejetée. Le modèle derrière le proxy ne fait pas son propre contrôle d'accès — le proxy est la porte.

Pourquoi la publication distingue-t-elle HF Jobs des Inference Endpoints au lieu d'appeler Jobs production ? Parce que les mécanismes diffèrent. Jobs facture à la seconde et ne s'arrête que sur annulation explicite ou timeout ; les Inference Endpoints ajoutent scale-to-zero et un contrôle d'accès plus fin. Appeler Jobs production améliorerait un état que le mécanisme ne supporte pas — la même chose que nous refusons de faire avec nos modules Roadmap.

Comment fonctionne la taille de tensor-parallel et pourquoi est-ce important ? --tensor-parallel-size doit égaler le nombre de GPUs du flavor (h200x2 → 2). C'est un mécanisme d'appariement de contraintes : le sharding doit correspondre au matériel. Désaccordez-le et le modèle ne se shardera pas correctement entre les GPUs que vous avez.

Qu'est-ce que cela a à voir avec le « the space is the router » d'Everythink ? Le proxy HF restreint l'accès à un namespace avant que le modèle ne réponde. La topologie network→community→room d'Everythink restreint l'accès à un room avant qu'une Sister ou l'Oracle ne réponde. Les deux sont des garanties de la couche de routage — la porte est provisionnée d'abord, le modèle configuré ensuite.

Le HAI Engine d'Everythink est-il le même type de mécanisme ? La même forme, un domaine différent. Le HAI Engine tourne en production depuis 2016, et sa règle est la même : la porte (le room, le port, le proxy) route avant que le moteur ne réponde. Les Sisters renvoient une sortie et le Loom persiste via un port ; l'Oracle normalise en un endroit. Le mécanisme est nommé, pas adjectivé.

Si vous voulez une plateforme où la couche de routage est provisionnée avant que le modèle ne parle, où chaque capacité porte une étiquette d'honnêteté et où la porte est la première chose que vous bâtissez — créez votre réseau.

Sources

• 2026 — Hugging Face, « Run a vLLM Server on HF Jobs in One Command » : https://huggingface.co/blog/vllm-jobs