Latenza e tempi di risposta: cosa cambia tra AI in sede e API cloud

La latenza di un sistema di intelligenza artificiale — il tempo tra la tua richiesta e una risposta utilizzabile — dipende da tre cose: il percorso che i dati fanno sulla rete, il tempo di attesa prima dell'elaborazione e il tempo di calcolo vero e proprio. Con un'installazione nel tuo CED (centro elaborazione dati) il percorso di rete è breve ma il calcolo dipende dal tuo hardware; con le API (interfacce di programmazione delle applicazioni) cloud in Europa il calcolo è affidato al fornitore ma la rete attraversa tratte più lunghe e condizioni che non controlli. Non esistono valori validi per tutti: questo articolo spiega i fattori in gioco e un metodo per misurare i tempi sul tuo caso prima di decidere.

Da cosa nasce la latenza nei due modelli

Conviene scomporre l'attesa in tre componenti, perché si affrontano in modi diversi.

• Trasmissione. Il tempo che la richiesta impiega a viaggiare dal tuo dispositivo al sistema che elabora, e che la risposta impiega a tornare. In una rete interna è un percorso breve, tra apparati dell'azienda. Verso un servizio cloud il traffico esce dalla sede, attraversa la connessione Internet o il collegamento dedicato e segue l'instradamento del fornitore fino al data center che elabora.
• Attesa. Prima di essere elaborata, una richiesta può restare in coda: su un server locale quando il carico supera la capacità disponibile, su un servizio cloud per politiche di gestione del carico o limiti concordati. L'attesa cresce nei momenti di punta e spesso è la componente meno visibile.
• Elaborazione. Il tempo di calcolo del modello. In sede dipende interamente dal dimensionamento del server AI aziendale: hardware insufficiente si traduce direttamente in risposte lente. In cloud la capacità di calcolo è del fornitore, ma il luogo in cui avviene l'elaborazione dipende dalla configurazione scelta, come vedremo.

La tabella seguente riassume dove si collocano i fattori nei due modelli. È una mappa qualitativa: i pesi effettivi vanno misurati sul proprio caso.

In quali processi pochi secondi di ritardo contano davvero

La domanda giusta non è «quanto è veloce» ma «veloce rispetto a cosa». Un ritardo conta quando una persona o un processo restano fermi in attesa della risposta.

I secondi contano nei processi interattivi, quelli in cui il passo successivo dipende dalla risposta: un operatore che deve decidere mentre il pezzo è sulla linea, un tecnico al telefono con un cliente che consulta un assistente durante la chiamata, un responsabile che valuta una segnalazione prima di autorizzare un'operazione. Qui alcuni secondi in più, ripetuti decine di volte al giorno, diventano attrito concreto o tentazione di aggirare lo strumento.

I secondi contano molto meno nei processi differibili: sintesi di fine turno, classificazione di documenti, analisi programmata dei registri, preparazione di evidenze per una verifica. Se il risultato serve entro la mattina successiva, la differenza tra pochi secondi e qualche minuto non cambia alcuna decisione.

Questa distinzione ha una conseguenza pratica: non serve un'unica architettura «veloce» per tutto. Si può decidere processo per processo, tenendo in sede ciò che richiede risposte immediate e continuità senza Internet, e valutando le API per i carichi differibili. Il confronto tra i due modelli è sviluppato nell'articolo su AI locale nel CED o API cloud.

Come influisce la distanza dal data center

Sul percorso di rete pesano due elementi: la distanza fisica, che pone un limite inferiore al tempo di propagazione del segnale, e il numero di passaggi intermedi, che aggiunge elaborazione a ogni attraversamento. Una risposta elaborata nel tuo CED percorre metri; una risposta elaborata in un'altra regione o in un altro continente percorre molta più strada, su tratte che non governi. Nessuna delle due condizioni, da sola, dice quanto attenderai: conta la misura, non la distanza sulla mappa.

C'è poi un punto spesso trascurato: «regione europea» non fissa il luogo dell'elaborazione. La documentazione Microsoft su dati, privacy e sicurezza dei modelli in Azure Foundry spiega che il tipo di deployment determina dove avviene l'elaborazione: i deployment standard restano nella geografia indicata, quelli «DataZone» possono elaborare in qualsiasi geografia della data zone e quelli «Global» in qualsiasi geografia del mondo in cui il modello è distribuito. In modo analogo, la guida AWS sull'inferenza cross-region di Amazon Bedrock distingue i profili geografici — che instradano la richiesta verso una regione dentro la geografia scelta, senza garantirne una specifica — dai profili globali, che possono elaborarla in qualsiasi regione supportata nel mondo.

Due chiamate identiche possono quindi viaggiare su percorsi molto diversi a seconda della configurazione, con tempi differenti e variabili. Se i tempi di risposta contano per un tuo processo, la configurazione del servizio — tipo di deployment o profilo di inferenza — fa parte delle cose da verificare, insieme alla qualità del tuo collegamento verso il fornitore.

Esempio illustrativo: il controllo etichette sulla linea

Esempio illustrativo. Lo scenario seguente serve a ragionare sul metodo; non descrive un caso reale né risultati misurati.

Un'azienda confeziona prodotti alimentari su tre linee. Vuole usare un assistente AI per due compiti: aiutare l'operatore a decidere se un'etichetta non conforme blocca il lotto, e preparare la sintesi dei turni per il responsabile qualità. Il primo compito è interattivo: l'operatore attende la risposta con il prodotto fermo davanti a sé, e un'attesa lunga ripetuta centinaia di volte al giorno rallenta la linea o spinge a saltare il controllo. Il secondo è differibile: che la sintesi arrivi in un minuto o in dieci non cambia nulla.

L'azienda misura entrambi i compiti nelle due configurazioni candidate — server nel CED e API in regione europea — negli orari reali di lavoro, inclusi i picchi di cambio turno. Scopre, nel suo caso, che il compito interattivo tollera l'attesa solo nella configurazione che misura tempi stabili sotto carico, mentre per la sintesi entrambe sono adeguate. La decisione architetturale segue la misura, non il preventivo più basso.

Misurare sul proprio perimetro: un metodo semplice

Non esistono valori di latenza dichiarabili a priori: né OverZeus né altri fornitori possono promettere tempi senza averli misurati sul tuo perimetro, e questa guida non ne riporta. Il metodo seguente si esegue con strumenti ordinari e, per la configurazione in sede, durante la prova in modalità di sola osservazione (Oracle), che non modifica la produzione.

1. Scegli da tre a cinque operazioni reali e rappresentative, separando quelle interattive da quelle differibili. Per ciascuna definisci che cosa conta come «risposta utilizzabile»: non l'inizio del caricamento, ma il momento in cui chi lavora può proseguire.
2. Stabilisci una soglia accettabile per ogni processo, decisa da chi quel processo lo possiede, non dalla sola IT. Una soglia scritta evita discussioni successive sul «sembra lento».
3. Misura dal gesto dell'utente alla risposta utilizzabile, ripetendo le prove in orari e condizioni diverse: ore di punta, carichi concorrenti, connessione in condizioni normali. Il singolo tentativo andato bene non è una misura.
4. Registra le condizioni di ogni misura: data, orario, numero di utenti attivi, stato del collegamento, configurazione del servizio. Senza contesto, un tempo non è confrontabile con un altro.
5. Ripeti la stessa procedura nelle configurazioni candidate — installazione nel CED e configurazione API europea — con le stesse operazioni e le stesse soglie, e confronta gli esiti.
6. Decidi con le evidenze alla mano, conservando misure e condizioni: serviranno se in futuro i tempi peggioreranno e dovrai capire che cosa è cambiato.

Due avvertenze. La prima: misura anche le condizioni sfavorevoli, perché sono quelle che incontrerai; la media gentile di un martedì tranquillo non descrive il picco del fine mese. La seconda: distingui la latenza dell'inferenza da quella dei canali di notifica. In OverZeus l'app dei responsabili si collega al server locale tramite VPN (rete privata virtuale) su connessione 5G cifrata proprietaria: la tempestività con cui una segnalazione arriva sullo smartphone dipende da quel canale remoto e dalla sua connettività, ed è una misura a sé rispetto ai tempi di elaborazione. Ne parliamo nell'articolo sul canale remoto tra CED e smartphone.

Il ruolo di Argus nella misura continua

Nel progetto OverZeus l'osservazione dei tempi non si esaurisce nella prova iniziale. Argus, l'agente dedicato al monitoraggio continuo, osserva eventi, servizi, rete e dispositivi collegati ed evidenzia anomalie e scostamenti dalla situazione attesa: se i tempi di risposta di un servizio peggiorano nel tempo, lo scostamento diventa un segnale visibile da valutare, non una sensazione riferita dagli utenti. Mnemosyne conserva fonti, proposte ed esiti, così le misure raccolte in prova e le variazioni successive restano ricostruibili. Come per ogni intervento attivo, eventuali azioni correttive seguono il percorso di proposta e approvazione previsto: l'assenza di risposta non autorizza alcuna modifica.

Le integrazioni disponibili e i punti esatti di misura vanno definiti per il progetto: chiedi in fase di offerta quali fonti e quali tempi la configurazione proposta è in grado di osservare.

Decidere con i propri numeri

La latenza non è una caratteristica dell'AI ma del tuo caso: processi, rete, carichi e configurazione. In sede controlli il percorso e paghi il calcolo con il tuo hardware; in cloud deleghi il calcolo e accetti un percorso di rete più lungo e variabile, che dipende anche da scelte di configurazione come il tipo di deployment. L'unica risposta affidabile viene dalla misura sul tuo perimetro, con soglie decise da chi possiede i processi.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus