Cost per 1k token e p95: perché l’AI in produzione è un problema di SLO

Nel mio lavoro su AI “in produzione” vedo sempre lo stesso errore: l’azienda discute di modelli, e non discute di servizio. Ma l’AI in produzione è un servizio: ha un’esperienza utente, un costo operativo e un rischio.

Quando qualcuno mi chiede “quanto costa l’AI?”, io rispondo con una domanda: quanto costa un output utile al p95. Perché è lì che muore l’adozione: nel 5% dei casi lenti, instabili o che richiedono rework.

1) Perché le medie mentono: il p95 è la vera esperienza

Le medie sono comode perché “tornano”. Ma in produzione, l’utente non vive nella media: vive nel caso peggiore che gli capita oggi. Se quel caso è lento, si spezza la fiducia.

• p95 end‑to‑end: non solo modello—UI, rete, RAG, tool, storage.
• TTFT: la latenza percepita (se è alta, “sembra rotto”).
• Error rate: i fallimenti innescano retry, escalation e costo.
• Rework: se l’output non è affidabile, lo paghi due volte.

Se ottimizzi la media ma lasci esplodere il p95, stai costruendo un prodotto che sembra buono in demo e fragile in realtà.

2) SLO: definisci cosa “deve reggere” prima di ottimizzare costi

Uno SLO non è un grafico: è un patto operativo. Dice quanto puoi degradare prima che l’esperienza si rompa. Senza SLO, ogni ottimizzazione è casuale.

• Performance: p95 end‑to‑end ≤ X secondi.
• Affidabilità: error rate ≤ Y% su finestra mobile.
• Cost: costo per output ≤ Z€ su volume reale.
• Qualità: groundedness ≥ soglia e rework ≤ soglia.

Poi assegni un error budget: quanto degrado accetti prima di bloccare nuove feature e tornare a stabilizzare. È così che l’AI smette di essere “innovazione” e diventa servizio.

3) Cost per 1k token: utile, ma solo se lo colleghi a un output

Il cost per 1k token è una metrica infrastrutturale, non una metrica di business. La domanda che conta in boardroom è: quanto costa produrre un output utile.

• Costo per output: € per ticket chiuso / memo approvato / proposta inviata.
• Tempo per output: minuti uomo risparmiati o spostati su attività migliori.
• Qualità: riduzione errori e riduzione rework.

Quando colleghi token → output, i numeri smettono di essere “tecnici” e diventano firmabili: procurement e CFO possono decidere.

4) Perché il p95 alza i costi (anche se i token costano poco)

Il costo non esplode solo quando “paghi di più il modello”. Esplode quando il servizio degrada: timeout, retry, escalation, ticket, call inutili. E quello è costo industriale.

• Retry: raddoppi costi e peggiori la latenza.
• Escalation: sposti lavoro su umani (cost-to-serve).
• Over‑provisioning: compri GPU “per stare tranquillo” perché non hai metriche.
• Churn interno: quando l’esperienza è instabile, l’adozione cala e il ROI muore.

Ecco perché io ragiono sempre in termini di SLO: stabilità prima, ottimizzazione poi.

5) Le leve che abbassano costo e migliorano p95 (senza “magia”)

Ci sono leve che funzionano quasi sempre, perché sono ingegneria, non opinioni. Il trucco è usarle con misurazione e soglie.

• Caching: riduci token e latenza su richieste ripetute.
• Batching: migliori throughput e costo per output (se la UX lo consente).
• Routing: modello economico per casi facili, modello più forte solo quando serve.
• Context discipline: riduci input token, aumenti qualità, eviti “contesto rumoroso”.
• RAG solido: meno hallucination → meno rework → meno costo reale.

Se vuoi una base tecnica chiara su tracing, metriche e SLO, vedi la pagina LLM Observability Stack. Per una stima economica (cloud vs on‑prem), usa il TCO Calculator.

6) Runbook: cosa fai quando degrada (prima che il business se ne accorga)

In produzione non esiste “funziona/non funziona”. Esiste degradazione. Un runbook serve a togliere improvvisazione: soglie, azioni, owner, comunicazione.

• Soglie: p95, error rate, cost spike, backlog.
• Azioni: switch modello, riduzione contesto, fallback, kill switch.
• Controlli: blocco PII, policy su tool e data egress.
• Post‑mortem: una lezione, un fix, una metrica aggiornata.

Questo è il passaggio “premium”: non solo AI che sembra brillante, ma AI che regge un lunedì mattina con carico reale.

7) Piano 30 giorni: misurare → stabilizzare → ottimizzare

Se vuoi portare un sistema in produzione senza farti sorprendere, io uso un percorso breve e rigoroso. Non parte dall’ottimizzazione: parte dalla misurazione.

Giorni 1–7 — Baseline + SLO

• Scegli 1 workflow reale e definisci l’output (cosa vale).
• Strumenta: p95, TTFT, error rate, token, costo stimato.
• Definisci SLO e soglie go/no-go.

Giorni 8–14 — Stabilità + runbook

• Riduci variabilità: caching, limiti di contesto, fallback.
• Definisci runbook e owner (chi fa cosa quando degrada).
• Prima dashboard: trend p95 e cost per output.

Giorni 15–30 — Ottimizzazione controllata

• Batching/routing dove ha senso (senza rompere la UX).
• Test A/B su prompt e retrieval (misura qualità e rework).
• Consegna: SLO, runbook, cost model, e backlog tecnico.

8) Checklist: prima di chiamarlo “production”

Se uno di questi punti manca, l’AI diventa un costo imprevedibile. E i costi imprevedibili sono quelli che procurement taglia.

• SLO definiti e misurati (p95, error rate, costo per output).
• Tracing e logging minimi (audit trail operativo).
• Policy su dati e PII (cosa può entrare, cosa no).
• Fallback e kill switch (non improvvisare durante incident).
• Runbook con owner e soglie di intervento.
• Dashboard “difendibile” per leadership e procurement.

Se vuoi costruire SLO, osservabilità e cost model in modo serio, scrivimi: partiamo da una valutazione e portiamo un primo workflow in produzione in poche settimane.

Conclusione: l’AI in produzione è FinOps + SRE, non solo “AI”

Quando misuri p95 e costo per output, smetti di discutere di tool e inizi a discutere di servizio. È lì che l’AI diventa una capacità aziendale.

Se vuoi un’implementazione procurement‑ready (SLO, runbook, controlli, KPI), contattami: definisco baseline e roadmap e porto il primo use case “decision‑ready” in produzione.