Perché il monitoring tradizionale non funziona con i LLM

Diciamolo chiaro: se monitori la tua applicazione basata su LLM come monitoreresti delle semplici API, stai navigando alla cieca.

Lo vedo succedere in continuazione. Team che configurano il loro servizio AI, lo attaccano allo stack di observability esistente, guardano le spie verdi che lampeggiano, e poi si ritrovano con utenti scontenti per la qualità delle risposte oppure con fatture mensili triplicate. Gli strumenti dicono che tutto funziona. Non è vero.

Il punto è che gli AI system spezzano le assunzioni su cui è stata costruita tutta la nostra infrastruttura di monitoring.

Il modello dei web service non calza

Il monitoring tradizionale assume un segnale pulito: arriva una richiesta, succede qualcosa, esce una risposta. Successo o fallimento, binario. La latenza è latenza. Il tuo 99esimo percentile significa qualcosa.

I LLM distruggono ogni singola di queste assunzioni.

Una risposta non arriva tutta insieme: viene generata token dopo token, il che significa che "latenza" sono in realtà almeno tre numeri diversi a seconda di dove ti trovi nella timeline di generazione. Un 200 OK non dice nulla sulla qualità dell'output. Il costo scala con i token, non con le richieste. E i fallimenti più dannosi sono completamente silenziosi: il modello restituisce sciocchezze confidenti con un perfetto codice HTTP.

Time to First Token: il numero che gli utenti percepiscono

Quando qualcuno invia un prompt al tuo feature AI, la prima cosa che percepisce è l'attesa. Nello specifico, aspetta che il primo token appaia sullo schermo. Questo è il Time to First Token (TTFT), e rappresenta l'equivalente più vicino alla "latenza percepita" nel mondo dei LLM.

Il problema del TTFT è che cresce con la lunghezza del prompt. Se stai costruendo un sistema RAG che ci infila contesti enormi in ogni richiesta per migliorare l'accuratezza, stai contemporaneamente affossando le performance percepite. Questo è un tradeoff fondamentale che il monitoring tradizionale non ti farà emergere.

Inter-Token Latency: il fattore fluidità

Una volta che lo streaming inizia, gli utenti sviluppano aspettative sulla velocità di lettura. L'Inter-Token Latency (ITL) — lo spazio tra token consecutivi — determina se l'output sembra fluido o a scatti.

Gli utenti sono sorprendentemente tolleranti con uno stream lento ma costante. Odiano uno stream più veloce che freeze e balbetta. Il tuo monitoring dovrebbe distinguere tra queste esperienze, anche quando il throughput grezzo sembra accettabile.

Latenza end-to-end: il contesto è tutto

La metrica p99 che funziona benissimo per le tue REST API ti ingannerà completamente per le richieste AI. Perché? Perché un task di classificazione da 50 token e una generazione di report da 2000 token hanno profile di latenza completamente diversi, e mediarli insieme produce un numero che non rappresenta niente.

Segmenta la latenza per use case. Ogni metrica dovrebbe corrispondere a un workload con caratteristiche consistenti. Altrimenti stai ottimizzando per un'astrazione che non esiste.

Il problema dei fallimenti silenziosi

Ecco la parte più preoccupante: i problemi di produzione peggiori con i system AI spesso non producono alcun alert.

Il tuo modello inizia a generare allucinazioni confidenti. Il prompt drift introduce bias sottili. Il contesto recuperato viene ignorato in favore delle memorie di training. Tutto questo ritorna HTTP 200, completa in tempo accettabile, e sembra perfettamente sano nella tua dashboard.

Non li catturerai con uptime check. Ti serve output quality monitoring, e sebbene sia più difficile da instrumentare, è assolutamente essenziale.

Quello che conta davvero

Raggruppa le tue metriche AI attorno alle domande a cui rispondono:

È veloce? TTFT, ITL, percentili di latenza per use case

Può scalare? Throughput di token, profondità delle code, utilizzo del context

È corretto? Task completion rates, pattern di errori negli output

Regge economicamente? Costo per task, efficienza token, consistenza del modello

Come si comporta? (Per gli agent) Completion dei task, conteggio step, rilevamento loop

Alcuni di questi numeri li avrai gratis dalla tua infrastruttura. La maggior parte no. Costruire instrumentation custom per i workload AI non è opzionale — è l'unico modo per vedere cosa sta succedendo davvero.

I team che ci riescono non usano dashboard migliori. Fanno domande migliori.