Inferenza IA distribuita: cosa devono sapere i leader dei fornitori di servizi di telecomunicazione

Ogni provider di servizi di telecomunicazione sta rendendo operativa l'IA. Gli scenari di utilizzo includono bot per l'assistenza clienti, copiloti per le operazioni di rete e l’AI-as-a-Service (AIaaS) gestito per i clienti aziendali esterni. 

Il rapporto tra scenario di utilizzo e business case è un aspetto scomodo. Il fattore chiave è il costo dell'acceleratore dell’IA, che si tratti di un'unità di elaborazione grafica (GPU), un'unità di elaborazione tensoriale (TPU) o un'unità di elaborazione neurale (NPU). Il costo per inferenza determina se questi acceleratori di IA migliorano i margini di profitto o li erodono. Per contenere i costi, il modello di IA scelto è importante quanto il modo in cui lo si implementa e lo si utilizza su una scala geografica distribuita.

In un recente articolo, gli esperti di Red Hat hanno affrontato le sfide della distribuzione dell'inferenza come un problema di architettura determinato dal traffico e dalla scalabilità, non solo dalle dimensioni del modello. Questo articolo del blog riassume le conclusioni.

L’impatto del costo per inferenza su profitti e perdite

Ogni richiesta di IA richiede due processi distinti sullo stesso hardware. 

• Per prima cosa legge il prompt o l'input. La richiesta può riguardare la cronologia della fatturazione, ticket di assistenza, log di rete o altri dati da elaborare. 
• Quindi genera la risposta all'input, un token alla volta.

La fase di lettura determina quanto tempo l'utente deve attendere per la prima parola; la fase di scrittura decide se la conversazione è fluida o se presenta frequenti interruzioni. Le due fasi richiedono profili di risorse e ottimizzazioni differenti e, quando condividono le risorse dell'acceleratore di IA, entrano in competizione.

Questa tensione incide su profitti e perdite in modo diverso a seconda degli scenari di utilizzo dell'IA e dei tipi di carico di lavoro. Ad esempio, con i chatbot per l'assistenza clienti, il costo per contatto aumenta quando i bot si bloccano e le sessioni passano agli agenti. Le offerte di IA per le aziende prevedono penali in base agli accordi sul livello del servizio (SLA) quando non rispettano i tempi di latenza previsti. Inoltre, il margine sui prodotti di IA business-to-business (B2B) si riduce quando il costo per query supera il prezzo stabilito nel contratto. 

La maggior parte degli errori di distribuzione deriva da compromessi e si verifica quando un team ottimizza una metrica non funzionale alla vendita del prodotto. L'analisi di alcuni modi specifici in cui l'IA genera fatturato può illustrare la distribuzione corretta per ogni tipo di carico di lavoro.

Assistenza clienti

L'assistenza clienti è il caso più emblematico. Il traffico di assistenza è costituito da migliaia di brevi sessioni di chat simultanee che riutilizzano la stessa tariffa e lo stesso preambolo della policy per ogni chiamata. Gli esperti Red Hat hanno identificato quanto segue dai benchmark vLLM di Red Hat.

• La suddivisione e il corretto dimensionamento dei pool di lettura e scrittura hanno ridotto i costi del 25-40% per questa tipologia di traffico.
• Il routing cache-aware, l'approccio di pianificazione implementato dal progetto open source llm-d, ha generato un numero di token per GPU da due a tre volte superiore e un costo per token da tre a cinque volte inferiore nei casi di elevato riutilizzo dei prompt.

I sistemi di produzione non otterranno lo stesso livello di miglioramento, ma la tendenza è stata confermata per ogni carico di lavoro misurato. Con decine di milioni di interazioni di assistenza al mese, ridurre i costi di inferenza anche di pochi punti può far risparmiare abbastanza da finanziare il ciclo di prodotto successivo senza nuove spese in conto capitale (CapEx) per gli acceleratori.

Operazioni di rete

Le operazioni di rete hanno caratteristiche opposte: gli utenti sono pochi e i documenti elaborati sono molto lunghi. L'analisi degli incidenti rilegge costantemente gli stessi runbook, record di topologia e manuali dei fornitori, quindi la leva principale per ridurre i costi è la memorizzazione nella cache di quanto già elaborato. Il vantaggio consiste in tempi di diagnosi più brevi e in un minor numero di inoltro agli ingegneri senior.

IA gestita venduta alle aziende

La vendita dell'IA ai clienti enterprise introduce una terza variabile: molti tenant, SLA a più livelli e picchi di domanda. Due meccanismi possono proteggere il margine in diversi scenari.

• Il cascading dei modelli invia le query di routine a un modello di piccole dimensioni e inoltra solo quelle complesse, riducendo i costi del cluster del 40-60% laddove prevalgono le query semplici.
• Il controllo degli accessi legato agli obiettivi del livello di servizio (SLO) rifiuta le richieste che violerebbero uno SLA invece di metterle nella coda degli errori, proteggendo così la credibilità del contratto in caso di carico elevato.

Come mostrato nella Tabella 1, questi tre scenari di utilizzo possono fungere da modello per i livelli di prezzo gold, silver e bronze, invece di costringere i clienti a fare affidamento su un unico pool condiviso di acceleratori di IA. Tuttavia, esistono altri due vincoli che completano il quadro per i provider di servizi e illustrano come personalizzare i servizi di IA per clienti specifici. 

IA sovrana con capacità di cloudbursting

Le regole sulla sovranità richiedono che i dati dei sottoscrittori rimangano nel paese di origine. Il modello che meglio risponde a questa esigenza è una baseline on premise regolamentata con cloudbursting, che rimane inattivo tra i picchi di traffico. Un unico piano di controllo come Red Hat OpenShift AI mantiene allineati i due ambienti, affinché la conformità non dipenda solo dalla disciplina di configurazione.

Edge computing

Considerando l'edge della rete, con circa 100 sessioni simultanee o meno, la risposta corretta è un modello per ogni acceleratore, senza pool intelligenti.  Le query complesse devono essere inoltrate tramite backhaul affinché la spesa per il trasporto segua la complessità anziché il volume.

Tabella 1. In che modo i tipi di carico di lavoro portano a risultati aziendali tangibili

Ecco le domande che i provider devono porsi quando prendono in considerazione ciascuno degli scenari di utilizzo.

• Assistenza clienti: quanto costa oggi una conversazione di assistenza completamente automatizzata e quale singola modifica influisce maggiormente su questo valore? Una risposta valida considera il costo per contatto gestito misurato sul traffico reale, con una leva testata e i relativi dati prima e dopo l'intervento.
• Operazioni di rete: quanto tempo attende un ingegnere per ottenere una risposta utile dai record degli incidenti? Gli stessi documenti vengono rielaborati ogni volta? Una risposta valida mostra la frequenza con cui i runbook e i record dei siti vengono recuperati dalla cache rispetto alla rilettura, e la tendenza dei tempi per la prima risposta.
• Servizi B2B: quale SLA aziendale non viene rispettato per primo in presenza di un picco? La soluzione consiste in un potenziamento dell'hardware o in un routing migliore? Una risposta valida indica il livello critico emerso da un test di carico e dimostra che è stata tentata una correzione del routing o degli accessi prima di richiedere un acquisto.
• Sovranità e picchi: quanta capacità rimane inutilizzata tra i picchi di traffico solo per soddisfare le regole di residenza dei dati? Una risposta valida riporta l'utilizzo di base e un burst design a costo zero durante i periodi di inattività.
• Operazioni all’edge e su campo: quale percentuale di query sul campo viene inoltrata a un cluster centrale e quanto costa il trasporto? Una risposta valida fornisce il tasso di risoluzione locale per sito, con l'escalation riservata alle query che il modello in loco non è in grado di gestire.

Percorso di investimento

Una volta definito uno scenario di utilizzo dell'IA, il passaggio successivo consiste nel realizzarlo in modo efficiente ed economico. La sequenza conta più della destinazione. Ogni fase viene attivata da una misurazione, non da una data prefissata, e si ripaga da sola prima che inizi la successiva:

1. Inizia con un nodo: esegui una singola istanza di servizio sul traffico reale di assistenza o di rete per una settimana. Questo valore di riferimento è il parametro per ogni decisione successiva; il traffico di laboratorio sintetico risulterebbe fuorviante.
2. Aggiungi il routing intelligente: una seconda replica offre un throughput inferiore di 1,8 volte rispetto a quello di una singola replica. Questa discrepanza indica che le richieste giungono a server che devono rileggere un contesto già presente in un altro server. Si tratta di uno spreco dovuto al routing, non di mancanza di capacità, quindi risolvi il problema prima di acquistare nuovo hardware.
3. Separa i pool di lettura e scrittura: esegui questa operazione solo quando le misurazioni mostrano che una fase sottrae troppe risorse all'altra, giustificando la complessità operativa aggiuntiva.
4. Adotta la griglia multitenant: Quando più prodotti e clienti B2B condividono la piattaforma, la complessità dei meccanismi che proteggono gli SLA a più livelli diventa giustificata. Al di sotto di tale scala, questi meccanismi rappresentano solo uno spreco di energie.

Ogni passaggio reimposta la baseline. La strategia di inferenza dell'IA è una serie di scelte misurate, non un'approvazione una tantum dell'architettura. I provider di servizi applicano già questa strategia con lo spettro wireless: assegna la capacità ai prodotti che generano un ritorno sull'investimento (ROI, Return on Investment), esegui misurazioni continue e recupera le risorse inutilizzate. Gli acceleratori di IA meritano la stessa disciplina.

Conclusione

L'inferenza distribuita dell'IA determina se i prodotti di IA dei provider di servizi mantengono i propri margini. Nulla di quanto descritto in questo articolo del blog richiede un impegno di budget rischioso. Ogni meccanismo è un passaggio misurato che dimostra la propria efficacia sul traffico del provider di servizi prima di passare a quello successivo; la tabella 1 indica da dove iniziare.

Quando sarà il momento giusto per affrontare questo percorso per il tuo portafoglio nell’ambito di assistenza, di rete o B2B, presenta i tuoi dati sul traffico al team di Red Hat dedicato al tuo account. Oggi, con i provider di servizi utilizziamo vLLM, llm-d e Red Hat OpenShift AI. La conversazione sarà più proficua se partirà dalle tue esigenze anziché da un modello generico.