Come instradare le richieste al modello LLM giusto per ogni attività

Risposta breve: instrada le richieste nella tua applicazione, poi usa un’unica chiave CometAPI e la base URL compatibile con OpenAI https://api.cometapi.com/v1 per chiamare il modello selezionato. Invia il lavoro ripetitivo e facile da verificare a un livello a basso costo; le interazioni con i clienti sensibili alla latenza a un livello veloce; e il lavoro ambiguo o ad alto impatto a un livello ad alta accuratezza. Mantieni queste etichette come tua politica, non come una classifica universale dei modelli, e misura ogni livello sullo stesso set di test.

Questa guida costruisce quel router a tre livelli con un esempio Python compatto, fallback con limiti e un modello di costo che conteggia i retry e gli output rifiutati. L’esempio usa ID di modelli correnti dal catalogo CometAPI, ma la logica di instradamento resta separata in modo che i modelli possano essere sostituiti senza riscrivere l’applicazione.

Che cos’è il routing LLM?

Il routing LLM è il processo di inviare ogni richiesta al modello o al livello di servizio che si adatta meglio al suo compito, obiettivo di latenza, requisito di qualità e budget.

Come instradare le richieste LLM in base all’attività?

Al 20 agosto 2026, i seguenti ID modello e campi di prezzo del catalogo erano disponibili tramite la CometAPI Models API pubblica. Le tariffe al consumo stimate di seguito applicano il valore di ratio attuale del catalogo ai prezzi base di input e output, secondo la guida ai prezzi di CometAPI. Conferma la tariffa finale mostrata per il tuo account prima dell’uso in produzione.

“Veloce” significa che la rotta ha un obiettivo di latenza; “alta accuratezza” significa che ha un obiettivo di qualità più rigoroso. Nessuna etichetta prova che un modello sia sempre il più veloce o il più accurato. Effettua benchmark su p50 e p95 di latenza, tasso di successo del compito e costo per output accettato sul tuo traffico prima di rendere permanente la mappatura.

Come configurare CometAPI per un router LLM?

Ti serve una chiave CometAPI, Python 3.10 o successivo e il pacchetto OpenAI per Python. Conserva la chiave lato server invece che nel codice sorgente.

pip install openaiexport COMETAPI_KEY="your-key-here"

L’esempio usa POST /v1/chat/completions. CometAPI documenta questa interfaccia come condivisa tra più provider, ma il comportamento dei parametri può comunque variare per modello. Controlla la voce di modello attuale e la reference di Chat Completions prima di aggiungere campi specifici del provider.

Di cosa hai bisogno per creare un router LLM?

• Mappa attività stabili ai livelli di servizio. Non chiedere a un altro LLM di classificare ogni richiesta a meno che segnali applicativi semplici non siano sufficienti. Un tag di supporto è prevedibilmente lavoro da livello economico; una risposta live è sensibile alla latenza; una revisione di policy merita il gate di qualità più rigoroso.
• Valida l’output. Uno status HTTP di successo non significa che il risultato sia utilizzabile. Passa al router un validatore specifico per il compito. Un validatore di classificazione può verificare un’etichetta consentita; un validatore per risposte ai clienti può imporre lunghezza e divieti; un flusso strutturato può validare uno schema JSON.
• Fai fallback in modo mirato. Prova la rotta approvata successiva dopo un timeout, 408, 429, 5xx temporaneo o un fallimento del gate di qualità entro limiti definiti. Non usare un altro modello per nascondere input malformati, una chiave non valida o parametri non supportati.

Come costruire un router LLM in Python?

import osimport time​from openai import APIError, OpenAI​client = OpenAI(    api_key=os.environ["COMETAPI_KEY"],    base_url="https://api.cometapi.com/v1",    max_retries=0,    timeout=20,)​MODELS = {    "cheap": "deepseek-v4-flash",    "fast": "gemini-3.7-flash",    "accurate": "claude-opus-5",}​# Put the preferred tier first; later tiers are fallbacks.ROUTES = {    "tag": ["cheap", "fast", "accurate"],    "reply": ["fast", "cheap", "accurate"],    "policy_review": ["accurate", "fast", "cheap"],}​​def retryable(error):    status = getattr(error, "status_code", None)    return status is None or status in {408, 429} or (status and status >= 500)​​def route(task, prompt, validate=lambda text: True):    attempts = []    for tier in ROUTES.get(task, ROUTES["reply"]):        model = MODELS[tier]        started = time.perf_counter()        try:            response = client.chat.completions.create(                model=model,                messages=[{"role": "user", "content": prompt}],                max_tokens=400,            )            text = response.choices[0].message.content or ""            attempts.append({                "tier": tier,                "model": model,                "latency_ms": round((time.perf_counter() - started) * 1000),                "accepted": validate(text),            })            if attempts[-1]["accepted"]:                return {                    "text": text,                    "route": tier,                    "model": model,                    "usage": response.usage.model_dump() if response.usage else None,                    "attempts": attempts,                }        except APIError as error:            attempts.append({"tier": tier, "model": model, "status": error.status_code})            if not retryable(error):                raise​    raise RuntimeError(f"No route passed: {attempts}")​​if __name__ == "__main__":    result = route(        "reply",        "Reply to a customer asking when their refund will arrive. Do not promise a date.",        validate=lambda text: 30 <= len(text) <= 600 and "guarantee" not in text.lower(),    )    print(result)

Come limitare i retry prima del fallback?

Mantieni i retry dell’SDK a zero e incapsula ogni chiamata al modello con un limite esplicito. L’helper seguente ritenta solo i fallimenti API ripetibili una volta, poi solleva un’eccezione così che la rotta esterna possa passare al livello approvato successivo.

MAX_ATTEMPTS_PER_MODEL = 2​def call_model(model, prompt):    for attempt in range(1, MAX_ATTEMPTS_PER_MODEL + 1):        try:            return client.chat.completions.create(                model=model,                messages=[{"role": "user", "content": prompt}],                max_tokens=400,            )        except APIError as error:            if not retryable(error) or attempt == MAX_ATTEMPTS_PER_MODEL:                raise            time.sleep(min(0.5 * (2 ** (attempt - 1)), 2.0))

In route(), sostituisci la chiamata diretta a client.chat.completions.create(...) con call_model(model, prompt). Con tre livelli, una richiesta si ferma dopo al massimo sei chiamate al provider; i fallimenti di validazione continuano a scalare una volta per livello invece di ritentare lo stesso output.

Eseguila con python3 llm_task_router.py. Per cambiare provider o generazioni di modelli in seguito, aggiorna MODELS; la policy del compito e il contratto di risposta restano in un unico punto.

L’esempio usa solo parametri condivisi dai modelli selezionati. Aggiungi controlli di token specifici del modello tramite un livello di adattamento dopo aver verificato la compatibilità del modello.

Come testare una policy di routing LLM?

Per prima cosa verifica che la policy deterministica selezioni il livello primario previsto. Queste sono aspettative di instradamento, non risultati di performance del provider:

Un smoke test live riuscito restituisce la risposta più il livello selezionato, l’ID del modello, l’uso di token e ogni tentativo. I valori reali di token e latenza varieranno:

{  "text": "...",  "route": "fast",  "model": "gemini-3.7-flash",  "usage": {    "prompt_tokens": "measured value",    "completion_tokens": "measured value"  },  "attempts": [    {      "tier": "fast",      "model": "gemini-3.7-flash",      "latency_ms": "measured value",      "accepted": true    }  ]}

Per un confronto reale, esegui le stesse richieste etichettate su tutti e tre i modelli. Registra tasso di passaggio del compito, latenza p50 e p95, tasso di errore, token di input e output, tasso di fallback e tasso di revisione umana. La metrica che conta di solito è il costo per output accettato, non il costo per chiamata API.

Quanto costa il routing multi‑modello?

Usa un’unica forma di workload per un confronto equo. Supponi 1 milione di token totali: 800.000 token di input e 200.000 token di output. Usando le tariffe derivate dal catalogo verificate il 20 agosto 2026:

Se il traffico è 60% economica, 30% veloce e 10% alta accuratezza, il costo composito previsto è circa $1.19 per 1 milione di token totali. Inviare lo stesso mix interamente alla rotta ad alta accuratezza sarebbe circa $7.20 in queste ipotesi. Questo è un calcolo di prezzo, non la prova che la policy mista soddisferà il tuo obiettivo di qualità.

Retry e rifiuti cambiano il risultato. Un tasso di retry una tantum del 5% alza la proiezione da $1.19 a circa $1.25. Se un output a basso costo fallisce la validazione e l’intera richiesta viene ripetuta sul livello ad alta accuratezza, conta entrambe le chiamate. Traccia gli output accettati così che un modello apparentemente economico non nasconda costi di revisione o rigenerazione.

Quali sono i fallimenti di routing LLM più comuni?

La guida a errori e retry raccomanda di ritentare i rate limit e i fallimenti temporanei della piattaforma con backoff, mentre le richieste malformate e i fallimenti di autenticazione vanno corretti. La guida al fallback allo stesso modo mantiene il fallback dei modelli ordinato ed esplicito.

Instradamento applicativo vs. CometAPI Auto: quale dovresti usare?

Usa l’instradamento applicativo quando contano controllo e riproducibilità. Mantieni la decisione nel tuo codice quando i compiti sono stabili e ti servono identità di modello fisse, budget per livello, validatori personalizzati e un ordine di fallback verificabile. Questo approccio rende anche più semplice confrontare la stessa mappa di modelli tra release.

Usa CometAPI Auto quando ridurre la manutenzione del routing conta di più. Imposta model=auto per un default bilanciato o model=auto-high quando la qualità ha priorità più alta. CometAPI seleziona dinamicamente un modello idoneo dalle caratteristiche della richiesta e dal pool di instradamento corrente, quindi il modello sottostante può variare; questo rende Auto meno adatto quando ogni esecuzione deve usare lo stesso modello o parametri specifici del modello.

Come eseguire il routing LLM in produzione?

• Aggiorna il registro dei modelli. Chiama GET https://api.cometapi.com/api/models durante il deployment o all’avvio e fallisci la release se manca un ID configurato o un endpoint richiesto. ID modello, prezzi e capacità possono cambiare.
• Tieni le opzioni specifiche del provider fuori dal router. Un’interfaccia Chat Completions comune non rende ogni parametro identico. Ad esempio, il supporto per logprobs, controlli di reasoning o più candidati può differire. Metti queste differenze in adapter testati.
• Limita traffico e output. Limita la concorrenza prima che le richieste escano dall’applicazione, usa backoff esponenziale con jitter per 429 e imposta un tetto ai token di output. La guida ai rate limit di CometAPI raccomanda gli stessi controlli lato applicazione.
• Registra la decisione. Annota tipo di compito, versione della policy, livello scelto, ID modello, latenza, uso di token, risultato della validazione, conteggio dei retry, motivo del fallback e stima dei costi. Evita di registrare segreti o contenuti dei clienti non necessari.
• Promuovi le rotte con evidenze. Mantieni un set di valutazione etichettato per ogni compito. Distribuisci i cambi di mappatura gradualmente, confrontali con la policy precedente e conserva una via di rollback rapida.

Domande frequenti

CometAPI decide automaticamente quale modello è economico, veloce o accurato?

Questo tutorial mantiene quella policy nel codice applicativo. CometAPI fornisce la chiave condivisa, la base URL, il catalogo dei modelli, l’interfaccia Chat Completions e i mattoni documentati per costruire il fallback. Il tuo team definisce cosa significa ogni livello e quale modello ha superato i test.

Una singola chiave CometAPI può chiamare modelli di provider diversi?

Sì. Per i percorsi di testo compatibili con OpenAI, usa https://api.cometapi.com/v1 e cambia il valore di model. Il catalogo corrente dovrebbe essere verificato prima del deployment.

Perché non inviare ogni richiesta al modello più economico?

La tariffa più bassa per token può diventare costosa se gli output falliscono la validazione, richiedono retry o generano lavoro di revisione umana. Confronta il costo per risultato accettato e mantieni i compiti ad alto impatto dietro gate di qualità più rigorosi.

Un fallimento di qualità dovrebbe attivare il fallback?

Solo quando il fallimento è rilevabile automaticamente e l’escalation è limitata. Un errore di schema, un campo richiesto mancante o una promessa vietata possono giustificare un’escalation. Un’insoddisfazione vaga dovrebbe diventare dati di valutazione, non un loop di retry illimitato.

Quanto spesso dovrebbe cambiare la mappa dei modelli?

Cambiala quando dati attuali del catalogo e una valutazione ripetibile mostrano un compromesso migliore. Non ruotare i modelli solo perché appare un nuovo nome nel catalogo.

Posso aggiungere un modello OpenAI in seguito?

Sì. Aggiungi un ID di modello compatibile con OpenAI aggiornato a MODELS, testa lo stesso contratto di richiesta e risposta e posizionalo nell’ordine delle rotte. Il client, la chiave e la base URL restano invariati.

Come mantenere gestibile una policy di routing LLM?

Il router multi‑provider più semplice non è una scatola nera autonoma. È una policy di compito breve e versionata supportata da accesso API condiviso, metadati di modello aggiornati, un validatore di qualità e una catena di fallback ristretta. CometAPI riduce il lavoro di connessione a una chiave e una base URL compatibile con OpenAI; la tua applicazione mantiene il controllo su decisioni di costo, latenza e qualità.