AI locale o cloud? Perché probabilmente il futuro sarà ibrido
Per utilizzare un modello di intelligenza artificiale oggi abbiamo due possibilità principali.
Possiamo utilizzare un servizio cloud e inviare le nostre richieste attraverso un'applicazione o un'API.
Oppure possiamo eseguire il modello direttamente sulla nostra infrastruttura.
Sono due approcci spesso presentati come alternativi.
Cloud contro locale.
Da una parte modelli enormi, infrastrutture praticamente illimitate e nessun hardware da gestire.
Dall'altra controllo dei dati, privacy e possibilità di mantenere tutto all'interno della propria infrastruttura.
Ma credo che questa contrapposizione sia destinata a diventare sempre meno importante.
Perché probabilmente la domanda corretta non sarà:
È meglio utilizzare l'AI locale o quella cloud?
Sarà:
Qual è il posto migliore in cui eseguire questa specifica richiesta?
Ed è qui che iniziano a diventare interessanti le architetture AI ibride.
Due modi molto diversi di utilizzare l'intelligenza artificiale
Quando utilizziamo un servizio AI nel cloud, il funzionamento è relativamente semplice.
Invieremo una richiesta a un provider, il modello verrà eseguito sulla sua infrastruttura e riceveremo il risultato.
Non dobbiamo preoccuparci della GPU.
Non dobbiamo scaricare modelli.
Non dobbiamo dimensionare la memoria.
Non dobbiamo gestire aggiornamenti o infrastrutture dedicate.
Possiamo inoltre accedere a modelli estremamente potenti che sarebbe difficile, costoso o semplicemente impossibile eseguire localmente.
È uno dei motivi per cui il cloud ha reso l'intelligenza artificiale generativa accessibile praticamente a chiunque.
L'AI locale segue invece una filosofia differente.
Il modello viene eseguito su hardware che controlliamo direttamente: una workstation, un server, un piccolo cluster o, in alcuni casi, persino un normale computer.
La richiesta non deve necessariamente lasciare la nostra infrastruttura.
E questo apre possibilità completamente diverse.
Perché eseguire un modello localmente?
La prima risposta che viene in mente è quasi sempre la stessa:
privacy.
Ed è certamente uno dei motivi principali.
Se un modello viene eseguito interamente all'interno della nostra infrastruttura, possiamo progettare processi nei quali determinati dati non devono essere inviati a un servizio esterno.
Documenti interni.
Informazioni commerciali.
Dati provenienti da sistemi aziendali.
Procedure.
Conoscenza interna.
Ma la privacy non è l'unico vantaggio.
Un modello locale ci offre un livello di controllo molto diverso.
Possiamo decidere quale modello utilizzare.
Quando aggiornarlo.
Come configurarlo.
Quali sistemi può raggiungere.
Dove vengono conservati i dati.
Possiamo creare un ambiente AI che faccia realmente parte della nostra infrastruttura informatica, invece di essere semplicemente un servizio esterno che consumiamo.
E in alcuni scenari possiamo continuare a utilizzarlo anche senza dipendere costantemente dalla disponibilità di un provider remoto.
Locale, però, non significa gratuito
È facile cadere nell'idea che un modello open source eseguito localmente equivalga ad avere intelligenza artificiale gratuita.
Non è proprio così.
L'hardware costa.
L'energia costa.
Lo storage costa.
La manutenzione costa.
E soprattutto esiste un limite fisico molto concreto alla quantità di calcolo e memoria che abbiamo a disposizione.
Possiamo eseguire modelli sorprendentemente capaci su hardware relativamente accessibile, soprattutto grazie alla quantizzazione e ai continui miglioramenti dei modelli più piccoli.
Ma non possiamo ignorare la differenza tra una workstation e l'infrastruttura di un grande provider cloud.
Se cento richieste arrivano contemporaneamente, il nostro server non diventa magicamente cento volte più potente.
L'AI locale ci dà controllo, ma quel controllo porta con sé anche la responsabilità di gestire le risorse.
Il cloud risolve un problema enorme: la scala
Il cloud parte praticamente dal problema opposto.
Non dobbiamo acquistare una macchina sufficientemente potente per il modello che vogliamo utilizzare.
Possiamo semplicemente richiamarlo quando serve.
Questo rende possibile accedere a capacità che localmente potrebbero richiedere investimenti enormi.
E soprattutto permette di adattarsi molto più facilmente al carico.
Dieci richieste oggi.
Mille domani.
Nessuna per alcune ore.
Paghiamo normalmente in funzione dell'utilizzo senza dover dimensionare l'infrastruttura sul picco massimo che potrebbe verificarsi.
Per molte applicazioni è una soluzione estremamente efficiente.
C'è poi un altro vantaggio importante.
I modelli più avanzati evolvono rapidamente.
Utilizzando un provider possiamo accedere a nuove generazioni di modelli senza dover continuamente riprogettare la nostra infrastruttura.
Quindi perché non utilizzare sempre il cloud?
Perché non tutte le richieste sono uguali.
Ed è questo, secondo me, il punto centrale.
Immaginiamo un agente AI utilizzato all'interno di un'azienda.
Durante la giornata potrebbe ricevere richieste molto diverse.
Riassumi questo documento pubblico.
Scrivimi una descrizione per questo prodotto.
Analizza questi dati interni.
Interroga il database delle vendite.
Confronta questi documenti riservati.
Fai una ricerca sul web e costruisci una sintesi.
Trattare tutte queste operazioni nello stesso modo significa ignorare completamente il loro contesto.
Alcune possono richiedere capacità di ragionamento molto elevate.
Altre sono semplicissime.
Alcune utilizzano informazioni pubbliche.
Altre coinvolgono dati che preferiremmo mantenere all'interno della nostra infrastruttura.
Perché dovrebbero essere elaborate necessariamente dallo stesso modello e nello stesso luogo?
L'AI ibrida
Un'architettura ibrida parte da un'idea diversa.
Non scegliamo un modello per tutto. Scegliamo il modello più appropriato per ogni attività.
Potremmo avere uno o più modelli locali utilizzati come prima destinazione delle richieste.
Per attività quotidiane, classificazioni, estrazione di informazioni, analisi di documenti o processi che coinvolgono dati sensibili, l'elaborazione potrebbe rimanere completamente all'interno dell'infrastruttura.
Quando invece una richiesta richiede capacità superiori, un contesto particolarmente grande o un modello specializzato, il sistema potrebbe utilizzare un provider cloud.
L'utente non dovrebbe necessariamente conoscere tutto ciò che accade dietro le quinte.
Potrebbe semplicemente formulare la propria richiesta.
È l'infrastruttura a decidere dove quella richiesta deve essere elaborata.
Il routing diventa parte dell'intelligenza
A questo punto compare un componente particolarmente interessante: il router.
Il suo compito non è necessariamente rispondere alla domanda.
Deve decidere chi dovrebbe farlo.
Una richiesta semplice potrebbe essere inviata a un piccolo modello locale.
Una richiesta che contiene determinate categorie di dati potrebbe essere obbligata a rimanere on-premise.
Un problema complesso potrebbe essere inviato a un modello cloud più potente.
Un'attività di programmazione potrebbe utilizzare un modello specializzato nel codice.
Un'altra potrebbe richiedere un modello particolarmente efficace nel ragionamento.
In questo scenario non abbiamo più semplicemente:
utente → modello.
Abbiamo qualcosa di più simile a:
utente → routing → modello appropriato → strumenti → risultato.
E improvvisamente la scelta del modello diventa dinamica.
Non tutto deve arrivare al modello più potente
C'è una tendenza comprensibile a pensare che il modello migliore debba essere utilizzato per qualsiasi attività.
Ma spesso sarebbe come utilizzare un supercomputer per fare una somma.
Se dobbiamo classificare poche righe di testo, estrarre alcuni campi da un documento o trasformare dei dati secondo uno schema preciso, un modello relativamente piccolo può essere più che sufficiente.
E può avere alcuni vantaggi.
È veloce.
Costa poco.
Può essere eseguito localmente.
Possiamo utilizzarlo moltissime volte.
Possiamo riservare i modelli più potenti alle attività nelle quali la loro capacità produce realmente una differenza.
Questo approccio può diventare particolarmente importante quando gli agenti iniziano a eseguire decine o centinaia di operazioni per completare un singolo processo.
Non ogni passaggio di un agente necessita della stessa intelligenza.
I dati possono determinare il percorso
C'è poi un'altra possibilità ancora più interessante.
Il routing può dipendere non soltanto dalla complessità della richiesta, ma anche dal tipo di informazione coinvolta.
Immaginiamo di definire alcune regole.
Le informazioni pubbliche possono utilizzare servizi cloud.
I documenti interni possono essere elaborati localmente.
Determinati dati sensibili non possono mai lasciare l'infrastruttura.
Alcune richieste possono utilizzare il cloud soltanto dopo che determinate informazioni sono state rimosse o anonimizzate.
Il sistema non sceglie quindi soltanto il modello migliore.
Sceglie il percorso consentito.
Questo significa che sicurezza e privacy possono diventare parte dell'architettura stessa invece di essere affidate esclusivamente al comportamento dell'utente.
E qui tornano gli agenti
Nei due articoli precedenti abbiamo introdotto prima gli agenti e poi MCP.
A questo punto i pezzi iniziano a collegarsi.
Un agente riceve un obiettivo.
Un sistema di routing può decidere quale modello utilizzare.
Il modello può scoprire attraverso MCP quali strumenti sono disponibili.
I server MCP possono controllare quali capacità e quali dati rendere accessibili.
Determinati processi possono essere eseguiti localmente.
Altri possono utilizzare servizi cloud.
E nei punti più delicati possiamo mantenere una persona nel processo per autorizzare l'azione.
Non stiamo più parlando semplicemente di utilizzare un chatbot.
Stiamo iniziando a parlare di progettare un'infrastruttura AI.
Il modello diventa un componente, non il sistema
Questo è probabilmente il cambiamento che trovo più interessante.
Quando abbiamo iniziato a utilizzare l'intelligenza artificiale generativa, gran parte dell'attenzione era concentrata sul modello.
Oggi credo che progressivamente inizieremo a guardare ciò che esiste intorno al modello.
Quali dati può utilizzare?
Quali strumenti possiede?
Quali azioni può eseguire?
Quali permessi ha?
Quando deve chiedere conferma?
Quale modello deve essere utilizzato per quella specifica attività?
Dove deve essere eseguito?
Il modello rimane fondamentale.
Ma diventa un componente dell'architettura, non necessariamente l'intera architettura.
E questo rende anche il sistema meno dipendente da un singolo fornitore o da una singola tecnologia.
Locale e cloud non sono avversari
Per questo faccio fatica a vedere AI locale e AI cloud come due filosofie necessariamente contrapposte.
Hanno caratteristiche differenti.
E proprio per questo funzionano bene insieme.
Il locale può offrirci controllo, riservatezza e prevedibilità.
Il cloud può offrirci scala, varietà e accesso a capacità computazionali difficili da replicare internamente.
Un'architettura intelligente può utilizzare entrambe.
La vera sfida diventa stabilire quando utilizzare l'una e quando utilizzare l'altra.
E questa decisione può essere automatizzata.
Il futuro potrebbe essere molto meno visibile
Forse tra qualche anno chiederci quale modello stiamo utilizzando sarà meno importante di quanto lo sia oggi.
Potremmo utilizzare un'interfaccia unica senza sapere che dietro una richiesta sono intervenuti tre modelli differenti.
Uno locale per classificare la richiesta.
Uno specializzato per analizzare alcuni dati.
Uno cloud per risolvere la parte più complessa.
Un agente potrebbe utilizzare diversi strumenti attraverso MCP e infine restituirci un unico risultato.
Tutto questo potrebbe avvenire senza che l'utente debba scegliere manualmente nulla.
Ed è probabilmente così che dovrebbe essere.
La tecnologia dovrebbe occuparsi della complessità.
La persona dovrebbe potersi concentrare sull'obiettivo.
Non scegliere tra locale e cloud. Progettare il confine.
Nel primo articolo di questa serie ho parlato del rapporto tra persone e intelligenza artificiale.
Nel secondo siamo passati dall'AI che risponde all'AI che agisce.
Nel terzo abbiamo visto come MCP possa creare un ponte tra l'intelligenza artificiale, i dati e gli strumenti.
Questo quarto passaggio riguarda il luogo nel quale quell'intelligenza viene eseguita.
E forse la risposta più interessante è che non dobbiamo necessariamente sceglierne uno.
Possiamo costruire sistemi nei quali ogni richiesta viene elaborata nel luogo più appropriato.
A volte sarà un server che controlliamo direttamente.
A volte sarà un servizio cloud.
A volte saranno entrambi all'interno dello stesso processo.
Il vero valore non sarà avere tutto locale.
E nemmeno avere tutto nel cloud.
Sarà avere la possibilità di decidere.
Il futuro dell'intelligenza artificiale potrebbe essere ibrido non perché locale e cloud siano compromessi l'uno dell'altro, ma perché sono strumenti diversi per problemi diversi.
E quando iniziamo a considerarli in questo modo, la domanda smette di essere dove vogliamo eseguire l'AI?
Diventa:
dove ha più senso eseguirla, per questa specifica richiesta?
← Torna al blog
