Spunto: OpenRouter, stesso modello, provider molto diversi

La tesi

Su OpenRouter lo stesso modello open cambia prestazioni in base al provider che lo serve, e i filtri dell'API — quantizzazione dichiarata, reasoning.effort — non proteggono da sorprese: senza misurazioni per-provider si naviga alla cieca.

Come la argomenta

1. Autorità pratica: l'autore gestisce Olly, un assistente AI su iMessage, e racconta nel saggio oltre 18 milioni di messaggi transatti, di cui circa un terzo su modelli open via OpenRouter.
2. Premessa lessicale: il model sono i pesi, il provider è chi li ospita con la sua precisione, le sue ottimizzazioni e i suoi parser XML/tool — quindi la sua lista di bug proprietaria. Una richiesta a deepseek/deepseek-v4-flash finisce su una di circa 20 aziende, per lo più sconosciute.
3. Benchmark per-provider: OpenRouter pubblica GPQA Diamond e TAU-Bench Airline separati per host. Sui medesimi pesi di DeepSeek V4 Flash 0731, il first-party segna 90,2% GPQA e 81,3% TAU, DigitalOcean 75,3% e 58,4%. La maggioranza degli host sta 5-7 punti sotto il first-party su tool calling; a luglio Fireworks era al 46% di TAU. Consiglio operativo: guardare il benchmark più vicino al proprio carico e riverificare a ogni cambio di modello.
4. Provider "ciechi" su vision: tre immagini minuscole passate su ogni host di Qwen3.5 122B e MiniMax M3. DeepInfra legge la K come R e scambia il rosso per il blu; Venice e Together non vedono proprio le immagini di MiniMax ma rispondono comunque 200 OK. Il difetto sui colori di MiniMax invece è del modello, perché fallisce anche sul first-party.
5. reasoning.effort è accettato ovunque ma non ovunque fa qualcosa: stesso prompt a low/high/max da una macchina di produzione, tre volte per livello. La maggior parte dei provider rispetta l'impostazione; digitalocean, gmi-cloud, mancer e venice no, e il proxy usato sono i reasoning token emessi.
6. Il filtro per quantizzazione non compra qualità: dopo un mese col filtro fp8, il confronto tra board e quantizzazione dichiarata mostra gli host fp4 in mezzo al pacchetto fp8, e i tre peggiori punteggi GPQA su DeepSeek sono uno per categoria: un fp4, un fp8, uno che non dichiara nulla. L'estratto si tronca qui, durante l'analisi su GLM 5.3.

I punti più forti

• Volume da produzione vera, non da playground: 18 milioni di messaggi rendono ragionevole la pretesa di aver incontrato ogni edge case almeno una volta.
• I dati centrali — le board per-provider — vengono da OpenRouter stesso, non dalle misure dell'autore: difficile liquidarli come selezione opportunistica.
• L'autore distingue ciò che può dimostrare da ciò che non può: il difetto colore di MiniMax lo attribuisce al modello perché ricade anche sul first-party, i buchi immagine di Venice e Together al provider.
• Ogni sezione chiude con un'azione concreta: controllare il benchmark più vicino al proprio workload, riverificare quando cambia il modello, tracciare i reasoning token per provider.

Dove è discutibile

• L'estratto termina a metà del punto 4: la conclusione sul caso GLM 5.3 — dove Sail Research (fp8) segna 50,7% di GPQA e Wafer senza quantizzazione dichiarata arriva a 90,2% — non è leggibile.
• Nessuna spiegazione causale dei crolli: perché DigitalOcean fa 58,4% di TAU sugli stessi pesi? Quantizzazione non dichiarata, ottimizzazioni, parser? Il saggio documenta il sintomo, non la causa.
• I test vision usano tre immagini minuscole, due modelli, un solo giorno (2026-07-31): dimostrano che il problema esiste, non darebbero una classifica di affidabilità.
• Il test su reasoning.effort prevede tre chiamate per livello, senza stima della varianza.
• Costi e latenza restano fuori: la scelta del provider non passa solo dalla qualità, e gli host peggiori potrebbero anche essere i più economici.
• Le board sono medie mobili a 32 giorni su una singola data; la variabilità temporale è mostrata solo con l'aneddoto di Fireworks a luglio.

Domande aperte

1. In produzione come blocchi il routing su un provider specifico e cosa succede quando quell'host va giù: fallback, retry, secondo fornitore?
2. Quali metriche metteresti sotto allarme per accorgerti che un host è degradato prima dei tuoi utenti — un TAU-like sul workload reale, i reasoning token, la latenza?
3. I provider che non dichiarano la quantizzazione vanno esclusi a priori, o il caso di Wafer (90,2% GPQA da "unknown") dice il contrario?
4. Quanto costa ripetere questi controlli a ogni rilascio di modello, e li automatizzeresti o li faresti a campione?

Citazioni utili

"They're the same model on paper, but very different models in real life."

"The model page says it supports image input, but two of its providers don't and even worse they'll pretend everything is 200 OK."

Fonte: So you want to use OpenRouter? · discussione su Hacker News