Mettere un modello in produzione non è mettere un modello dietro un endpoint. Nel 2026, fare inference seria significa gestire latenza, costi GPU, throughput, versioning e incidenti — contemporaneamente, in produzione, con utenti reali.
Kubernetes rimane la piattaforma più pragmatica per questa complessità. Ma devi progettarla bene, altrimenti ti ritrovi con GPU costose e servizi instabili.
L’architettura che funziona
Gateway/API: autenticazione, rate limiting, routing per tenant. Il traffico non tocca mai i modelli senza passare da questo layer.
Orchestrator agenti: gestisce sessioni, tool calls, policy. È il cervello che coordina le richieste.
Model serving: runtime specializzato — vLLM, Triton, TGI — per sfruttare batching e KV cache in modo efficiente.
RAG layer: vector DB + cache + retrieval. Separato dal serving, con policy di accesso proprie.
Observability: tracing con OpenTelemetry, metrics con Prometheus, log correlati per ricostruire qualsiasi incidente.
Cosa cambia rispetto ai microservizi classici
Le GPU sono una risorsa rara e costosa. Frammentarle è il modo più rapido per sprecare budget. MIG e GPU sharing possono migliorare l’utilizzo, ma aggiungono complessità operativa — valuta il trade-off caso per caso.
Il batching è il fattore singolo più impattante sui costi: una buona strategia può ridurre la spesa drasticamente mantenendo latenza accettabile. Investi tempo qui prima di comprare più hardware.
Il warm start — caricare pesi e KV cache — è costoso. Pre-warming e una replica minima sempre attiva sono spesso necessari per mantenere SLA decenti su workload interattivi.
Pattern di scaling
HPA basato su QPS e latenza p95 non basta — hai bisogno di segnali specifici: lunghezza della coda, token/sec, utilizzo GPU, pressione di memoria.
Scale-to-zero funziona solo per modelli “cold tolerant”. Per agenti e chat interattivi, mantieni sempre una base calda.
Per modelli grandi: multi-node e multi-GPU funzionano, ma se puoi scegliere modelli più piccoli con più repliche, fallo. È quasi sempre più robusto operativamente.
La parte che viene ignorata: la governance
Chi può usare quale modello? Con quali limiti di token? Con quale egress di rete consentito? Con quale retention dei log?
Se non hai risposte a queste domande prima di deployare, Kubernetes ti scalerà l’incidente più velocemente del servizio. La governance non è burocratica — è ciò che rende gestibile un sistema di questa complessità a lungo termine.