Gestione dell'inference operativa: strumenti cluster e pratiche operative per evitare guasti in produzione

Un agente AI può funzionare il giorno della consegna e smettere dopo sei mesi, senza che nessuno abbia toccato il codice. Succede quando cambia la versione del modello, si sposta un alias, muta un campo in un’API a monte o i documenti in produzione non assomigliano più a quelli di test¹. La tesi: i nuovi runtime per l’inferenza distribuita aiutano a reggere carico e complessità, ma non bastano. Servono runbook, evaluation set di proprietà del cliente e checkpoint umani dentro la pipeline per tenere il sistema in piedi nel tempo.

1. Cosa risolvono llm-d e DeepInfer

Google ha presentato llm-d 1.0 come stack open source, Kubernetes‑native, per l’inferenza distribuita di modelli linguistici. L’annuncio, firmato da Mark Lohmeyer e Sean Horgan sul blog di Google Cloud, è arrivato al PyTorch Conference. llm-d entra nella Cloud Native Computing Foundation come Sandbox. Red Hat e IBM compaiono come co‑fondatori. Contribuiscono oltre 500 persone da più di 25 organizzazioni².

Il progetto attacca tre punti pratici: routing consapevole della cache, controllo del traffico tra tenant e alta disponibilità. Punta a unire due comunità che oggi lavorano separate. Da un lato PyTorch, con strumenti che servono i modelli. Dall’altro Kubernetes, dove si orchestrano e si scalano i sistemi distribuiti in produzione. llm-d coordina componenti che devono parlarsi mentre aumentano i passaggi per richiesta. Il carico non assomiglia più alla chat lineare. Gli agent riusano lunghi prefissi, invocano più strumenti, orchestrano step multipli².

DeepSeek, sul fronte dei motori, ha pubblicato su GitHub DeepInfer, il framework di inference usato in produzione e ora in open source. La release copre l’inferenza offline e include le funzioni considerate core per il serving su larga scala. Il repository indica il supporto a DeepSeek‑V4.1‑Flash, con un runtime ottimizzato per il modello e uno per il sampler. Tra le proprietà operative compaiono batch‑invariant inference, deterministic sampling e structured outputs⁴.

La documentazione elenca i kernel inclusi: FlashMLA, DeepGEMM, DeepEP, TileKernels, DeepSelect e kernel scritti con TileLang. Le ottimizzazioni si muovono su tre livelli, kernel, runtime del modello e runtime del sampler. Per la parallelizzazione compaiono tre modalità: Attention DP, balanced CP e MoE EP con EPLB. Sul decoding, DeepInfer integra DSpark e una verifica schedulata in base alla confidenza, con token di bozza e stime di confidenza per decidere quando verificare⁴.

In sintesi, llm-d e DeepInfer toccano corde diverse ma compatibili: orchestrazione su cluster e ottimizzazioni di runtime e kernel. Entrambi si posizionano sulla produzione, non sul laboratorio^2,4.

2. Perché le migliori tecnologie non bastano

I guasti che bruciano la fiducia degli utenti spesso arrivano da fuori. Il provider del modello rimuove una versione, un alias punta a un’altra build, un’API upstream rinomina un campo. I documenti che l’agente legge cambiano sigle e formati. Il codice resta uguale, ma il comportamento si rompe. Il cliente lo vede come errore, e chi sta davanti non sa spiegare cosa sia successo¹.

I benchmark non coprono questi scarti. Un modello può segnare l’88% su MMLU, stare nel top percentile su GSM8K e risultare impeccabile su HumanEval. In produzione, dopo poche settimane, può inventare regole di reso, inviare payload fuori schema o rispondere con documenti superati ma con tono sicuro. Non è degradazione. È progettazione fuori contesto. La verifica deve restare accesa lungo tutto il ciclo di vita, non fermarsi prima del rilascio⁵.

llm-d punta a coordinare componenti distribuiti su carichi multi‑step. DeepInfer mette a disposizione funzioni e kernel per il serving su larga scala. Non risolvono, da soli, le rotture introdotte da versioni, alias, API e fonti informative che cambiano^1,2,4.

3. Tre pratiche operative da mettere in produzione

Primo, un runbook che esca con il sistema. Deve dire cosa l’agente può fare, cosa non deve mai fare, in quali sistemi può scrivere e cosa fare quando si comporta in modo strano. Va scritto per la persona di turno, non per chi ha costruito l’agente¹.

Secondo, un evaluation set di proprietà del cliente. Le domande e le risposte attese devono restare disponibili e aggiornabili da chi usa il sistema. Vanno eseguite in modo periodico. La verifica non è un controllo una tantum. Serve una guardia continua che rifletta i casi reali del cliente^1,5.

Terzo, un checkpoint umano dentro la pipeline. ServiceNow presenta Autonomous Engineer con una scelta netta: pianifica, costruisce e testa in autonomia, poi blocca la pipeline e chiede un’approvazione esplicita prima della messa in produzione. La validazione non resta fuori banda. Entra nel flusso e lascia una decisione tracciata, con una persona che se ne assume la responsabilità⁶.

Queste tre pratiche si parlano. Il runbook guida cosa fare quando un check fallisce. L’evaluation set misura il drift che i benchmark non vedono. Il checkpoint umano ferma il rilascio automatico quando emergono scarti che richiedono giudizio^1,5,6.

4. Handover e responsabilità

Un agente si guasta anche senza modifiche. Chi risponde ha bisogno di strumenti e informazioni in mano. L’handover è parte del progetto, non un incontro finale. Senza responsabilità chiare e materiali operativi, gli errori emergono davanti al cliente e restano senza una spiegazione pronta¹.

Qui entrano in gioco i materiali che escono insieme al sistema. Il runbook descrive confini e azioni di risposta. L’evaluation set di proprietà del cliente consente verifiche ripetibili e aggiornabili. Il checkpoint umano inserito nella pipeline rende tracciabili le decisioni sulle modifiche. Questi elementi non sostituiscono orchestrazione e ottimizzazioni, le completano^1,5,6.

5. Implicazioni per chi progetta agenti per la PA e servizi critici

Google Cloud ha presentato “Gemini for government services” in preview. L’agente riceve una consegna, pianifica i passi, attiva skill e tool, si collega ai sistemi dell’organizzazione. Risponde a domande, svolge attività di knowledge work, crea media, scrive ed esegue codice. Include funzioni di sicurezza, amministrazione e governance pensate per l’uso aziendale. Tre elementi spiccano: skill focalizzate sui processi di governo, collegamenti ai sistemi già in uso nelle agenzie, agenti sviluppati da partner³.

Il settore pubblico lavora tra statuti, regolamenti e linee guida. I dati abitano sistemi legacy a silos. Sovranità, conformità e riservatezza impongono limiti rigidi. Ne nasce lavoro manuale di inserimenti, controlli e revisioni che rallentano i servizi ai cittadini³.

Dentro questi vincoli, gli strati tecnici e operativi si incontrano. llm-d porta funzioni per orchestrare inferenza distribuita su carichi multi‑step in Kubernetes. DeepInfer offre ottimizzazioni per il serving su larga scala. Runbook, evaluation set di proprietà del cliente e checkpoint umani tengono il sistema allineato quando cambiano regole, alias o formati^1,2,4,6.

Il messaggio per chi costruisce servizi critici è concreto. Investire in orchestrazione e ottimizzazione dell’inference senza definire come si gestiscono le deviazioni produce sistemi che si guastano in silenzio. L’equilibrio tra cluster, test vivi e decisioni umane è la condizione perché l’agente che funziona alla consegna continui a funzionare quando cambia ciò che gli sta intorno¹.