Kubernetes al centro del learning loop per agenti AI basati su modelli open-weight

A marzo 2026 il miglior modello chiuso superava il miglior modello open del 3,3% sulla Arena leaderboard, secondo lo Stanford AI Index. Per molte attività, il collo di bottiglia si è spostato: conta come si serve, si addestra e si integra il modello nel ciclo di apprendimento, non solo il punteggio in classifica¹.

Il ciclo si chiude in casa. Qwen e GLM-5 si scaricano da Hugging Face, spesso con licenza Apache 2.0. Si caricano in motori open source come vLLM e SGLang. Servire il modello è il punto di partenza. Il valore arriva quando lo si cambia: fine-tuning sui propri dati o reinforcement learning sui propri compiti, poi rollout della nuova versione dietro lo stesso endpoint¹.

Un esempio concreto: un agente interno che corregge build CI in errore. Quando fallisce un build, clona il repository in una sandbox, legge i log, scrive una patch, esegue i test. Ogni tentativo produce una traiettoria, la traccia completa di una corsa. I test passano o falliscono, così il segnale di ricompensa è chiaro. Le traiettorie alimentano il learning loop. A intervalli il team fa fine-tuning sulle correzioni riuscite o lancia un job di RL, valuta il nuovo checkpoint e lo pubblica dietro l’endpoint esistente. Col tempo il modello impara come si rompe quel codice e come si ripara¹.

Qui si incastrano tre carichi diversi che stressano la piattaforma. L’inference chiede repliche long-running che scalano con il traffico e partono in fretta. Fine-tuning e RL chiedono job su GPU con gang scheduling e completamento garantito. Gli agenti eseguono codice non affidabile in ambienti effimeri. Tenere infrastrutture separate porta GPU ferme da una parte e code dall’altra, con passaggi costosi tra sistemi¹.

La proposta è un solo control plane per tutto il ciclo. Kubernetes riconcilia stato dichiarato e pianifica lavoro. Si estendono queste primitive a modelli, agenti e acceleratori. Nel livello modello, KServe, llm-d e il Kubernetes AI Toolchain Operator (KAITO) espongono serving, tuning ed evaluation come workload dichiarativi. KAITO rappresenta modello e requisiti GPU come custom resource, così un aggiornamento è un cambio di desired state, non uno script¹.

Per il training, Kueue gestisce il queueing e il gang scheduling. KubeRay orchestra job distribuiti. TauGrid, open source da Microsoft nell’agosto 2026, impacchetta questi pezzi con monitoraggio della salute delle GPU e osservabilità in una sola installazione Helm. Per ridurre i cold start, il Run:ai Model Streamer, supportato in vLLM, legge i tensori dall’object storage direttamente nella memoria GPU, evitando lo staging su disco locale¹.

Il livello di esecuzione degli agenti punta all’isolamento senza pagare l’idle. Kata Containers e gVisor isolano dal kernel host. agent-sandbox, sviluppato nei SIG di Kubernetes, gestisce agenti sandbox come risorse del cluster. Agent Substrate costruisce sopra quella base per impacchettare molti agenti su pochi worker. Hyperlight agisce all’interno dell’applicazione¹.

Con Kata ogni pod gira in una VM leggera con kernel proprio, senza cambiare l’API dei pod. Si opta via runtime class. Kata supporta vari monitor di VM, incluso Cloud Hypervisor, che Agent Substrate usa per la sua classe microVM. Agent Substrate mappa molti agenti stateful su un pool di worker preriscaldati, assegna lavoro in tempo reale e sospende gli agenti inattivi su object storage per riattivarli a richiesta. Isola con gVisor di default, con opzione microVM su Kata e Cloud Hypervisor¹.

Hyperlight incorpora un gestore di micro-VM nell’applicazione. Esegue codice guest senza kernel o sistema operativo nella VM. Avvia VM in uno o due millisecondi, con snapshot e restore della memoria. È entrato nella CNCF Sandbox come donazione di Microsoft nel 2024¹.

KubeCon + CloudNativeCon si tiene a Salt Lake City dal 9 al 12 novembre. L’agenda punta a far convivere i tre carichi sullo stesso control plane: modelli che si aggiornano in modo dichiarativo, agenti isolati ma densi, replica di inference con cold start ridotti. Il banco di prova resta quello citato nelle fonti: capacità sparsa tra regioni e on-prem, tempi di avvio, sicurezza a kernel condiviso. È lì che si gioca il 3,3% residuo¹.