Down-to-Zero (DTZ) a toujours visé à faire plus avec moins de watts et moins d’octets. De la planification des conteneurs en scale-to-zero aux runners de build alimentés par solaire, chaque service que nous livrons est mesuré selon une référence impitoyable : cela pourrait-il fonctionner correctement sur un CPU de notebook sans ventilateur au soleil ?
Aujourd’hui, nous sommes ravis d’annoncer la prochaine étape de ce parcours — des serveurs Model Context Protocol (MCP) distants que vous pouvez lancer comme conteneurs Docker légers dans n’importe quel contexte DTZ.
MCP est une norme ouverte qui permet aux hébergeurs de modèles de contacter des « serveurs » spécifiques à une tâche pour des données, des outils ou des actions, en utilisant un flux JSON simple et authentifié. Pensez-y comme un port USB-C pour les agents d’IA : une prise, de nombreux périphériques. En exécutant un serveur MCP à côté de vos données, vous évitez de transférer des jeux de données entiers via un appel d’API LLM. Cela s’aligne parfaitement avec notre mantra « déplacer le calcul vers la périphérie, pas vers le cœur ».
Jusqu’à présent, le load balancer multi-tenant de DTZ terminait uniquement HTTP/1 et HTTP/2. MCP, cependant, s’appuie sur les Server-Sent Events (SSE) pour son flux d’événements unidirectionnel et de longue durée. Les SSE fonctionnent très bien sur HTTP/2, mais les navigateurs limitent strictement les connexions SSE simultanées lorsqu’ils retombent sur HTTP/1 — généralement six par origine.
Nous avons donc étendu le balancer avec un support natif des SSE :
Cette amélioration débloque des serveurs MCP à priorité distante : vous pouvez maintenant déployer le composant serveur sous forme d’image de conteneur et permettre à n’importe quel client LLM de se connecter en retour via des SSE sécurisés sans proxies supplémentaires.
Build (ou téléchargez) une image de serveur MCP.
Poussez-la vers votre registre DTZ privé :
docker push {context-id}.cr.dtz.dev/my-mcp-server:latest
Créez un nouveau service dans votre contexte et pointez-le vers l’image. Notre ordonnanceur ne récupère les images qu’à la demande et passe à l’échelle zéro lorsqu’aucun hôte n’est connecté.
Parce que le point de terminaison du registre vit à l’intérieur du même maillage économe en énergie, les pulls d’images se font sur le backbone local, maintenant l’egress proche de zéro et accélérant les cold starts.
Les serveurs MCP distants nécessitent typiquement un seul binaire en Rust ou en Go plus une petite couche de base Alpine. Dans nos propres tests, un serveur d’intégration GitHub riche en fonctionnalités consomme 15 Mio de RAM au démarrage et reste en dessous de 2 W en veille sur nos nœuds workers DTZ. Cela laisse largement la marge pour des dizaines de serveurs par nœud avant que les panneaux solaires ne s’en aperçoivent.
Pour les charges de travail qui picquent, l’isolation cgroup de DTZ permet au noyau de récupérer la mémoire dès que le travail est terminé. Combinée à l’hibernation SSE du balancer, votre contexte retourne à zéro quelques secondes seulement après que le dernier token ait été streamé vers votre modèle.
Nous intégrons activement le DTZ Identity Server via OAuth 2.1 dans l’écosystème MCP, garantissant que chaque flux soit servi uniquement aux clients authentifiés et que vos serveurs distants restent à la fois minimaux et sécurisés.
Moins d’énergie, moins de tracas - juste le contexte là où vous en avez besoin.