Down-to-Zero (DTZ) è sempre stato incentrato su come fare di più con meno watt e meno byte. Dallo scheduling dei container scale-to-zero ai runner di build alimentati a energia solare, ogni servizio che rilasciamo è misurato rispetto a un criterio inflessibile: potrebbe questo funzionare felicemente su una CPU di un portatile senza ventola al sole?
Oggi siamo entusiasti di annunciare il prossimo passo in quel percorso - server Model Context Protocol (MCP) remoti che puoi avviare come container Docker leggeri all’interno di qualsiasi contesto DTZ.
MCP è uno standard aperto che permette agli host di modelli linguistici di contattare “server” specifici per compiti per ottenere dati, strumenti o azioni, usando un semplice stream JSON autenticato. Pensalo come una porta USB-C per agenti AI: una presa, molte periferiche. Eseguendo un server MCP vicino ai tuoi dati, eviti di trasferire interi dataset tramite una chiamata API all’LLM. Questo si adatta perfettamente al nostro mantra “sposta il calcolo verso il bordo, non verso il core”.
Finora il bilanciatore multi-tenant di DTZ terminava solo HTTP/1 e HTTP/2. MCP, però, si basa su Server-Sent Events (SSE) per il suo stream di eventi a lunga durata e unidirezionale. SSE funziona molto bene su HTTP/2, ma i browser limitano rigorosamente le connessioni SSE concorrenti quando ricadono su HTTP/1 — di solito sei per origine.
Abbiamo quindi esteso il bilanciatore con supporto SSE nativo:
Questo miglioramento sblocca i server MCP remote-first: ora puoi distribuire il componente server come immagine container e permettere a qualsiasi client LLM di connettersi tramite SSE sicure senza proxy aggiuntivi.
Builda (o scarica) un’immagine del server MCP.
Pushala al tuo registro DTZ privato:
docker push {context-id}.cr.dtz.dev/my-mcp-server:latest
Crea un nuovo service nel tuo contesto e puntalo sull’immagine. Il nostro scheduler effettua il pull solo su richiesta e scala a zero quando nessun host è connesso.
Poiché l’endpoint del registro risiede all’interno della stessa mesh a basso consumo energetico, i pull delle immagini avvengono sul backbone locale, mantenendo l’egress vicino allo zero e accelerando i cold start.
I server MCP remoti tipicamente necessitano di un singolo binario in Rust o Go più un piccolo layer base Alpine. Nei nostri test un server di integrazione GitHub completo consuma 15 MiB di RAM al boot e resta sotto i 2 W in idle sui nostri nodi worker DTZ. Questo lascia ampio margine per dozzine di server per nodo prima che i pannelli solari se ne accorgano.
Per carichi di lavoro che scalano di volume, l’isolamento tramite cgroup di DTZ permette al kernel di recuperare la memoria non appena il lavoro è terminato. Combinato con l’ibernazione SSE del bilanciatore, il tuo contesto torna a zero pochi secondi dopo che l’ultimo token è stato streammato al modello.
Stiamo attivamente integrando il DTZ Identity Server via OAuth 2.1 nell’ecosistema MCP, assicurando che ogni stream sia servito solo a client autenticati e che i tuoi server remoti rimangano sia minimali che sicuri.
Meno energia, meno complicazioni - solo il contesto dove ne hai bisogno.