L'Era del Routing Dinamico: Perché le PMI non devono scegliere un modello, ma un Orchestratore
Il mercato dei modelli LLM ha smesso di essere una corsa al "chi è più intelligente". Chi guida la classifica su MMLU o GPQA oggi viene superato domani. La competizione si è spostata su un asse che le PMI ignorano a proprio rischio: il rapporto tra qualità erogata e costo marginale per task.
I dati recenti lo confermano: i modelli near-frontier (Gemini 1.5 Pro, Claude 3.5 Sonnet, GPT-4o) offrono performance a un soffio dai modelli reasoning (o1, DeepSeek-R1) con latenza da modello fast e costi drasticamente inferiori. Non esiste un "modello migliore in assoluto". Esiste il modello che costa meno per unità di intelligenza utile per quel task specifico.
Il paradosso: la maggior parte delle aziende continua a hardcodare un singolo provider. Firma un contratto annuale, incolla la chiave API in `config.yaml` e spera che il pricing non cambi. Intanto, il mercato si muove: Qwen2.5-Coder a ~0.10$/M input, Nemotron 3 Ultra (550B MoE, 55B attivi) a 300+ tok/s su endpoint NIM, DeepSeek-V2.5 a ~0.28$/M. Ogni settimana emerge un nuovo "best value" per coding, reasoning, summarization, extraction.
La soluzione non è cambiare modello. È smettere di sceglierne uno.
L'Architettura Liquida: Routing per Task, non per Fedeltà
Il pattern non richiede kernel proprietari. Espone un'interfaccia `think(input, policy) -> Result` dove la `RoutingPolicy` decide in runtime dove inviare la richiesta.
La policy è un grafo di vincoli:
- Budget max per richiesta (es. 0.003€)
- Qualità minima richiesta (benchmark score su task-type specifico: SWE-bench per coding, GPQA per reasoning, MMLU per knowledge)
- Latenza massima tollerata (p95 < 2s per UX conversazionale, < 10s per batch)
- Compliance (dati EU-only? no training data retention?)
L'orchestratore interroga un registry prezzi/benchmark live — un server MCP, un JSON aggiornato via CI, o un endpoint dedicato — che espone pricing, benchmark aggiornati, disponibilità per ogni endpoint configurato. L'agente chiede: "Ho un task di code-review su 500 righe Rust. Budget 0.01€. Qualità minima: SWE-bench > 65%. Chi serve?" Il registry risponde: "Qwen2.5-Coder-32B su OpenRouter a ~0.008€ stimati. Fallback: Gemini 1.5 Pro a ~0.012€."
Il modello diventa un dettaglio di implementazione. La policy è l'asset strategico.
Un Insight Applicabile Subito: Il "Cost-Aware Router" in 50 Righe
Qualsiasi team può implementare oggi un router minimo usando LiteLLM (proxy universale) + un registry JSON aggiornato quotidianamente via GitHub Action.
```python
from litellm import completion
import json, os
PRICING = json.load(open("pricing_snapshot.json")) # aggiornato daily via CI
def estimate_tokens(text: str) -> int:
return len(text) // 4 # approssimazione grezza
def route(task_type: str, prompt: str, budget_eur: float, min_quality: float):
candidates = [m for m in PRICING
if m["task_scores"].get(task_type, 0) >= min_quality
and m["cost_per_1k_tokens"] * estimate_tokens(prompt) / 1000 <= budget_eur]
if not candidates:
raise ValueError("Nessun modello soddisfa vincoli. Alza budget o abbassa quality.")
best = min(candidates, key=lambda m: m["cost_per_1k_tokens"])
return completion(model=best["litellm_name"], messages=[{"role": "user", "content": prompt}])
```
Il punto non è il codice. È il cambiamento mentale: smetti di chiedere "qual è il modello migliore?" e inizia a chiedere "qual è la policy ottimale per questo task, oggi?"
Perché le PMI Possono Muoversi Prima
Le enterprise hanno contratti pluriennali, procurement da 6 mesi, compliance rigida. Le PMI no. Una PMI può domani mattina:
1. Attivare 5 endpoint su OpenRouter / Together / Fireworks / locale (vLLM, Ollama)
2. Definire 3-4 policy per i propri task ricorrenti (coding, extraction, reasoning, chat)
3. Misurare costo/qualità reale per task, non per benchmark generico
4. Iterare la policy, non il fornitore
Il vantaggio competitivo non è scegliere il modello migliore. È avere l'architettura per cambiare modello domani mattina senza riscrivere una riga di codice applicativo.