Down-to-Zero (DTZ) a toujours été axé sur le fait d’en faire plus avec moins de watts et moins d’octets. De l’ordonnancement des conteneurs en scale-to-zero aux runners de build alimentés par panneau solaire, chaque service que nous livrons est mesuré par une norme impitoyable : est-ce que cela pourrait fonctionner joyeusement sur un CPU de portable sans ventilateur au soleil ?
Aujourd’hui, nous sommes ravis d’annoncer la prochaine étape de ce voyage — des serveurs Model Context Protocol (MCP) distants que vous pouvez lancer comme des 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 contacter des « serveurs » spécifiques à une tâche pour obtenir 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 IA : une prise, de nombreux périphériques. En exécutant un serveur MCP à côté de vos données, vous évitez d’acheminer des jeux de données entiers via un appel d’API LLM. Cela correspond parfaitement à notre mantra « déplacer le calcul vers la périphérie, pas vers le cœur ».
Jusqu’à présent, l’équilibreur multi-tenant de DTZ ne terminait que HTTP/1 et HTTP/2. MCP, en revanche, repose sur les Server-Sent Events (SSE) pour son flux d’événements unidirectionnel et longue durée. Les SSE fonctionnent très bien sur HTTP/2, mais les navigateurs limitent strictement les connexions SSE concurrentes lorsqu’ils basculent sur HTTP/1 — généralement six par origine.
Nous avons donc étendu l’équilibreur avec un support SSE natif :
Cette amélioration débloque des serveurs MCP “remote-first” : vous pouvez maintenant déployer le composant serveur en tant qu’image de conteneur et permettre à n’importe quel client LLM de se reconnecter via des SSE sécurisés sans proxies supplémentaires.
Build (or download) an MCP server image.
Push it to your private DTZ registry:
docker push {context-id}.cr.dtz.dev/my-mcp-server:latest
Create a new service in your context and point it at the image. Our scheduler pulls only on demand and scales to zero when no host is connected.
Parce que le point de terminaison du registre se trouve à l’intérieur du même maillage écoénergétique, les pulls d’images se font via le backbone local, maintenant le trafic sortant proche de zéro et accélérant les cold starts.
Les serveurs MCP distants nécessitent typiquement un 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 sur nos nœuds workers 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 qui pètent effectivement, 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 de l’équilibreur, votre contexte revient à zéro quelques secondes seulement après que le dernier token a été streamé à votre modèle.
Nous intégrons activement le DTZ Identity Server via OAuth 2.1 dans l’écosystème MCP, en veillant à ce 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.