Down-to-Zero (DTZ) a toujours consisté à 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 énergie solaire, chaque service que nous livrons est mesuré selon une base implacable : pourrait-il tourner heureux sur un CPU de notebook sans ventilateur exposé au soleil ?
Aujourd’hui, nous sommes ravis d’annoncer la prochaine étape de ce parcours - des serveurs distants du Model Context Protocol (MCP) que vous pouvez lancer comme des conteneurs Docker légers dans n’importe quel contexte DTZ.
MCP est un standard ouvert qui permet aux hôtes de modèles linguistiques de contacter 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 à côté de vos données, vous évitez de transférer des jeux de données entiers via un appel API LLM. Cela s’inscrit parfaitement dans notre mantra « déplacer les calculs vers la périphérie, pas le cœur ».
Jusqu’à présent, le load balancer multi-tenant de DTZ ne terminait que HTTP/1 et HTTP/2. MCP, cependant, s’appuie sur les Server-Sent Events (SSE) pour son flux d’événements unidirectionnel de longue durée. SSE fonctionne très bien sur HTTP/2, mais les navigateurs limitent strictement les connexions SSE simultanées lorsqu’ils se replient sur HTTP/1 — généralement six par origine.
Nous avons donc étendu le balancer avec un support natif de SSE :
Cette amélioration débloque les serveurs MCP en remote-first : vous pouvez désormais déployer le composant serveur en image de conteneur et laisser n’importe quel client LLM se connecter via SSE sécurisé sans proxies supplémentaires.
Construisez (ou téléchargez) une image de serveur MCP.
Poussez-la dans votre registre privé DTZ :
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 scheduler tire l’image uniquement à la demande et passe à zéro lorsque aucun hôte n’est connecté.
Puisque le point d’accès du registre se trouve dans le même maillage énergétique efficace, les pulls d’image se font sur le backbone local, gardant la sortie quasi nulle et accélérant les démarrages à froid.
Les serveurs MCP distants nécessitent typiquement un unique binaire 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 reste en dessous de 2 W en veille sur nos nœuds DTZ workers. Cela laisse largement de la marge pour plusieurs dizaines de serveurs par nœud avant que les panneaux solaires ne s’en aperçoivent.
Pour les charges qui montent en pic, l’isolation cgroup de DTZ permet au noyau de récupérer la mémoire dès que le travail est terminé. Combiné à l’hibernation SSE du balancer, votre contexte revient à zéro quelques secondes seulement après que le dernier jeton a été streamé à 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 à des 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.