Down-to-Zero (DTZ) a toujours eu pour objectif de faire plus avec moins de watts et moins d’octets. Du scheduling de conteneurs en scale-to-zero aux runners de build alimentés à l’énergie solaire, chaque service que nous livrons est évalué selon une base impitoyable : est-ce que cela pourrait tourner heureusement sur un CPU de notebook sans ventilateur en plein soleil ?
Aujourd’hui, nous sommes ravis d’annoncer la prochaine étape de ce parcours - des serveurs distants Model Context Protocol (MCP) que vous pouvez lancer en tant que conteneurs Docker légers dans n’importe quel contexte DTZ.
MCP est une norme ouverte qui permet aux hôtes de modèles de langage de solliciter des « serveurs » spécifiques à une tâche pour obtenir des données, des outils ou des actions, via un simple flux JSON authentifié. Pensez-y comme à un port USB-C pour les agents IA : une prise, de nombreux périphériques. En exécutant un serveur MCP à proximité de vos données, vous évitez de transférer des ensembles de données entiers via un appel API LLM. Cela correspond parfaitement à notre mantra « déporter le calcul en périphérie, pas au cœur ».
Jusqu’à présent, le load balancer multi-tenant de DTZ ne terminait que les connexions HTTP/1 et HTTP/2. MCP, en revanche, repose sur les Server-Sent Events (SSE) pour son flux événementiel long et unidirectionnel. SSE fonctionne parfaitement sur HTTP/2, mais les navigateurs limitent strictement les connexions SSE concurrentes lorsqu’ils retombent sur HTTP/1 — généralement six par origine.
Nous avons donc étendu le load balancer avec un support natif SSE :
Cette amélioration déverrouille les serveurs MCP à distance en priorité : vous pouvez désormais déployer le composant serveur en image conteneur et permettre à n’importe quel client LLM de se connecter en retour via SSE sécurisé, sans proxies supplémentaires.
Construisez (ou téléchargez) une image de serveur MCP.
Poussez-la dans 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 cette image. Notre scheduler tire les images uniquement à la demande et passe à l’échelle zéro quand aucun hôte n’est connecté.
Puisque le registre réside dans le même maillage économe en énergie, les pulls d’image se font via le backbone local, maintenant ainsi l’egress proche de zéro et accélérant les démarrages à froid.
Les serveurs MCP distants ont typiquement besoin d’un binaire unique en Rust ou Go plus une petite couche de base Alpine. Dans nos propres tests, un serveur d’intégration GitHub complet consomme 15 MiB de RAM au démarrage et moins de 2 W au repos sur nos nœuds travailleurs DTZ. Cela laisse largement de 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 pic, l’isolation cgroup de DTZ permet au kernel de récupérer la mémoire dès que le travail est terminé. Associée à l’hibernation SSE du load balancer, votre contexte revient à zéro quelques secondes après que le dernier jeton est envoyé à votre modèle.
Nous intégrons activement le DTZ Identity Server via OAuth 2.1 dans l’écosystème MCP, garantissant que chaque flux est 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.