SLM vs LLM in Produzione: Perché la Specializzazione Batte la Scala nei Sistemi AI B2B

La scelta tra Large Language Models (LLM) generalisti via API e Small Language Models (SLM) specializzati in-house diventa inevitabile quando entri in produzione B2B a volumi significativi. Il punto di rottura economico si situa tipicamente intorno ai 50-100K token mensili processati: al di sotto, le API pay-per-token rimangono efficienti; al di sopra, il Total Cost of Ownership (TCO) di un SLM self-hosted su GPU dedicate diventa inferiore. Ma il valore della specializzazione va oltre il semplice arbitraggio dei costi — include latenza prevedibile, compliance normativa, e controllo completo sul ciclo di vita dei dati aziendali.

SLM vs LLM: Quando conviene abbandonare le API generaliste nel B2B?

Il dilemma Build vs Buy nel 2024 non e piu una domanda binaria. La ricerca di Hugging Face ha documentato come la specializzazione — cioè l'addestramento mirato di modelli piu piccoli su dati di dominio — batte la pura scala per quasi tutti i compiti industriali pratici. Un LLM da 70 miliardi di parametri via API genera risposte "mediamente valide" su 100 task diversi; un SLM da 8 miliardi fine-tuned sulla tua ontologia specifica genera risposte "ottimali" su quel singolo task.

Il break-even point economico emerge quando confronti:

• Opzione A (API): GPT-4 Turbo a 0.03$ per 1K token di input, con picchi di 0.06$ per output. Su 10 milioni di token/mese: ~3000$ in fatture.
• Opzione B (SLM self-hosted): Un modello 8B su NVIDIA L4 (24GB VRAM, ~0.35$/ora on-demand su cloud) processa circa 150-200 token/s in batch inference. 10 milioni di token richiedono ~14-16 ore di GPU, per un costo mensile di ~150-200$, piu overhead infrastrutturale (~300-500$).

A questo volume, il self-hosting costa 1/5 rispetto alle API. Ma esiste un secondo ordine di benefici:

• Latenza controllata: Un SLM in-house raggiunge Time To First Token (TTFT) sotto i 100ms; via API sei a 500-2000ms per rete + coda server.
• Nessun vendor lock-in: I pesi rimangono tua proprietà. Se domani OpenAI cambia pricing o API contract, non sei esposto.
• Privacy dei dati: I token non escono dal tuo datacenter.

Come calcolare e ridurre i costi di inferenza LLM in produzione a volume

L'economia dell'inferenza a scala non e lineare. Ogni decisione architetturale impatta il TCO mensile in modo sproporzionato.

Il costo nascosto delle API generaliste si manifesta in tre forme:

1. Token overhead: Prompt engineering generico richiede contesto piu verboso per ottenere la stessa qualita di una risposta specializzata. Un SLM fine-tuned su 2000 esempi di ticket customer service comprende implicitamente il tuo formato e richiede prompt piu brevi (~50 token vs 300 token con GPT-4). Su scala, questo e un moltiplicatore di costo.

2. Latency penalities: Se il tuo use case e un batch job notturno, la latenza non importa. Se e una API che risponde a query user real-time, ogni 200ms di latenza aggiuntiva aumenta il bounce rate. Questo non ha un costo diretto in token, ma ha un costo di business.

3. Re-evaluation drift: Ogni mese OpenAI aggiorna i suoi modelli "invisibilmente". I tuoi test e benchmark rimangono validi, ma l'output puo divergere lentamente. Un SLM in-house rimane deterministico fino a quando tu non la ritrai.

Intersezione linee astratte per break-even point

Calcolo pratico del TCO mensile:

Supponiamo: 5 milioni di token/mese, inference batch ogni notte, SLA di latenza non critico.

• GPU on-demand: NVIDIA L4 su AWS = 0.35$/ora. Carico: 5M token ÷ 170 token/s = ~8.2 ore/mese = $2.87.
• Networking + storage: ~$100/mese.
• DevOps + monitoring: ~$200/mese (stipendio parte-time del tuo ML engineer).
• Fine-tuning annuale (ammortizzato): 1-2 GPU-week/anno = ~$300/anno = $25/mese.
• TCO totale: ~$330/mese.

Con GPT-4 a 0.03$/1K input token: 5M ÷ 1000 × 0.03 = $150/mese di sola API, piu il 30% di overhead per retry/logging = ~$195. Ma questo numero non scala linearmente — a 20M token/mese, il self-hosting rimane a ~$1200 (piu GPU), mentre GPT-4 sale a ~$800. Il break-even reale dipende dalla tua curva di crescita e dal costo opportunita del tuo tempo di engineering.

Ottimizzazione della latenza introduce trade-off hardware:

Scegli la riga in base al tuo SLA. Se il latency budget per una richiesta user e 500ms total, e la rete consuma 100ms, l'SLM deve fare il suo lavoro in 400ms; una L4 e sufficiente. Se il budget e 100ms, servir un A10.

Fine-tuning SLM: architettura e deploy di modelli specializzati open source

Il fine-tuning inizia con la scelta del modello base. Tre opzioni dominano oggi:

• Llama 3 8B: 8B parametri, 8K context window, addestrato su 15 trilioni di token. Buona base per iniettare conoscenza di dominio. E il "cavallo di battaglia" per il 70% dei nostri progetti.
• Mistral v0.3 7B: Piu compatto, 32K context, routing consapevole (MoE su versioni piu grandi). Leggermente inferiore in comprensione vs Llama su compiti di ragionamento, ma piu veloce in inferenza.
• Phi-3 mini 3.8B: Estremo opposto della scala. Addestrato su dati sintetici ad alta qualita, occupa solo 3.8GB. Se il tuo use case e semplice (classificazione, extraction), spesso basta.

La scelta dipende da:

1. Dimensione del dataset di fine-tuning: <1K esempi? Phi-3 suffice. >5K? Llama 3. >50K? Valuta anche i 13B, se l'infrastruttura lo supporta.
2. Latency requirement: Phi-3 → 50ms. Llama 8B → 120ms. Misura sempre in produzione con batch reali.
3. Budget GPU: Phi-3 allena su una L4 in ~2 ore per epoch. Llama 8B in ~6 ore.

Una volta scelto il modello, il fine-tuning efficiente si fa con LoRA (Low-Rank Adaptation) o QLoRA (Quantized LoRA):

• LoRA: Allena solo matrici di rango basso (tipicamente rango 8-16) aggiunte ai layer attention e feedforward. Riduce i parametri trainabili da 8B a ~67M (0.8% del modello). Memory requirement: ~24GB per Llama 8B su precisione full (bfloat16).
• QLoRA: Quantizza il modello base a 4-bit e allena solo su LoRA. Memory requirement: ~6GB per Llama 8B. Trade-off: convergenza leggermente piu lenta (20-30% epoch in piu), ma il costo GPU cala da $200/epoch a $50/epoch.

# Pseudo-codice LoRA fine-tuning con HuggingFace Transformers
from peft import get_peft_model, LoraConfig, TaskType
from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer

model_id = "meta-llama/Llama-2-8b-hf"
model = AutoModelForCausalLM.from_pretrained(model_id, load_in_8bit=True)

lora_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=8,
    lora_alpha=32,
    lora_dropout=0.1,
    target_modules=["q_proj", "v_proj"],  # attention layers
)
model = get_peft_model(model, lora_config)

# 2000 esempi di (prompt, completion) nel dataset
training_args = TrainingArguments(
    output_dir="./lora_output",
    num_train_epochs=3,
    per_device_train_batch_size=16,  # ridotto grazie a LoRA
    learning_rate=2e-4,
)
trainer = Trainer(model=model, args=training_args, train_dataset=dataset)
trainer.train()

Deploy in produzione richiede un inference engine ottimizzato. Non usare transformers.pipeline() in produzione — e troppo lento. Usa:

• vLLM: Inference server specializzato con paged attention, batch rewriting dinamico, continuous batching. Riduce latency di 3-5x vs transformers nativo.
• Text Generation Inference (TGI) di Hugging Face: Scritto in Rust, GPU-accelerated, buon supporto per quantizzazione (AWQ, GPTQ, bfloat16).

Un stack di deployment tipico:

# docker-compose per inference SLM
version: '3'
services:
  vllm-server:
    image: vllm/vllm-openai:latest
    environment:
      MODEL_NAME: "meta-llama/Llama-2-8b-instruct-hf"
      TENSOR_PARALLEL_SIZE: 1
      GPU_MEMORY_UTILIZATION: 0.9
    ports:
      - "8000:8000"
    gpus:
      - device: 0
        capabilities: [compute, utility]
    volumes:
      - ./models:/root/.cache/huggingface/hub  # cache modelli

Questo server espone un'API /v1/completions compatibile con OpenAI. Il throughput tipico: 150-200 request/sec su L4 con batch size 32-64.

L'integrazione dei dati aziendali avviene in tre momenti:

1. Pre-training di contesto (opzionale): Se hai 100GB di documenti proprietari, training da zero e overkill. Continua il pre-training del modello base su 1-2 epoch sui tuoi dati accelera convergenza in fine-tuning.
2. Fine-tuning supervisionato (obbligatorio): 500-2000 coppie (prompt, expected_output) raccolte da casi reali o sintesi di procedure interne.
3. RAG (Retrieval-Augmented Generation) (raccomandato): Il modello non "memorizza" il 100% della tua knowledge base. Invece, per ogni query, recupera i documenti rilevanti da un vector store e li mette in context. Un SLM 8B con RAG spesso batte un LLM generico senza RAG.

Procurement AI e AI Act: la governance di mantenere i pesi in-house

Qui il calcolo economico si estende oltre il solo costo computazionale. La complianza normativa e la data governance diventano fattori decisivi.

L'AI Act europeo (in vigore dal 2025 per i provider, 2026 per gli adopter) introduce obblighi specifici su:

• Tracciabilità dei dati di training: Se il modello e fornito via API esterna, la responsabilita di auditability ricade formalmente sul provider. Se gestisci il modello in-house, la responsabilita e tutt pienamente tua — ma hai il controllo totale.
• Nessun bias ingiustificato: Un LLM generico e addestrato su miliardi di token internet, quindi rispecchia biases sistemici. Un SLM fine-tuned su tuoi dati aziendali riflette le tue scelte di selezione dati e puoi correggere proattivamente.
• Diritto di contestazione: Se un sistema AI nega un prestito o un'assunzione basato su un modello, l'interessato ha diritto a spiegazioni. Con un SLM in-house, puoi registrare esattamente quali dati di training hanno influito sulla decisione (tramite attention analysis). Con una API remota, sei opaco.

Nodi geometrici protetti per governance in-house

L'implicazione pratica sulla sicurezza dei dati e ancora piu diretta:

• Dati industriali sensibili: Se il tuo use case e anomaly detection su dati SCADA di impianti, controllati farmaceutici, formulazioni proprietarie, l'invio di questi dati a server terzi introduce un rischio di conformita GDPR/HIPAA/industria-specifico non negligibile. Anche se il provider promette crittografia, il fatto che i token transiti per reti pubbliche e sufficiente a triggare audit di compliance.
• Vendor lock-in mitigato: Le API cambiano. ChatGPT Plus costa $20/mese oggi, domani potrebbe costare $50. I modelli vengono deprecati. Un SLM che possiedi rimane usabile indefinitamente, anche se il provider originale chiude shop.
• Ciclo di vita prevedibile: In produzione, devi essere in grado di rollback a una versione precedente del modello se una release introduce regressioni. Con API, non hai controllo. Con SLM self-hosted, ogni versione e nel tuo git repo.

Le aziende B2B "mature" — banche, pharma, automotive — ormai considerano il self-hosting non come un'opzione ma come un requirement architetturale. Il costo di sviluppo di un SLM specializzato e rapidamente ammortizzato dal valore della compliance e della riduzione del rischio.

Dalla POC alla produzione: architetture AI scalabili con Jungletech

La transizione dalla Proof of Concept al sistema in produzione introduce una frattura spesso sottovalutata.

Una