Provider routing i preferències

L'objecte "provider" controla quin backend serveix un model — ordre, fallbacks, paràmetres requerits, ordenació per preu o throughput i política de dades.

29 de maig del 2026 6 slides 5 min de lectura

OpenRouter · Models i routing

Provider routing i preferències

Decideix tu quin backend serveix cada model.
Un model, molts backends

Recorda que un model open-weight el poden servir diversos proveïdors. L'objecte "provider" de la petició és com tries quin d'ells, en quin ordre i amb quines condicions.
Les preferències clau

Dins de "provider" hi caben diverses preferències:
- order — llista ordenada de proveïdors preferits.
- allow_fallbacks — si es permet caure a un altre proveïdor.
- require_parameters — descarta backends que no admetin els paràmetres que envies.
- sort — ordena per preu o per throughput.
- data_collection — exclou proveïdors que recullin dades.
OpenRouter · Models i routing arlaf.dev

Un objecte provider complet

{
  "model": "meta-llama/llama-3.1-70b-instruct",
  "provider": {
    "order": ["together", "fireworks"],
    "allow_fallbacks": true,
    "require_parameters": true,
    "sort": "throughput",
    "data_collection": "deny"
  },
  "messages": [
    { "role": "user", "content": "Hola!" }
  ]
}

Preu, velocitat o privacitat

Aquestes preferències et deixen optimitzar el que importi a cada cas: el cost més baix, la resposta més ràpida o no enviar dades a backends que les retinguin.
El slug tria QUIN model; l'objecte provider tria QUI el serveix.

Llegir la nota completa

Has vist que un mateix model pot estar servit per diversos backends. Per defecte OpenRouter en tria un per tu, però quan necessites control fi, l’objecte provider de la petició decideix qui serveix el model — no quin model, que això ja ho fa el slug.

Què pots configurar

Dins de provider hi caben diverses preferències que, combinades, descriuen la teva política de routing:

order — una llista ordenada dels proveïdors que prefereixes. OpenRouter els prova en aquest ordre.
allow_fallbacks — si es permet o no caure a un proveïdor que no estigui a la teva llista quan cap dels preferits respon.
require_parameters — descarta els backends que no admetin els paràmetres que envies (per exemple tools o response_format).
sort — ordena els candidats per criteri, típicament preu o throughput.
data_collection — exclou proveïdors segons la seva política de recollida de dades.

Un exemple complet

{
  "model": "meta-llama/llama-3.1-70b-instruct",
  "provider": {
    "order": ["together", "fireworks"],
    "allow_fallbacks": true,
    "require_parameters": true,
    "sort": "throughput",
    "data_collection": "deny"
  },
  "messages": [
    { "role": "user", "content": "Hola!" }
  ]
}

Optimitzar pel que importa

La gràcia és que cada cas d’ús té una prioritat diferent. Un batch nocturn voldrà el preu més baix; un xat interactiu, el throughput més alt; i un projecte amb dades sensibles, no enviar res a backends que les retinguin. L’objecte provider cobreix els tres sense canviar de model.

Nota: els noms exactes dels camps, els valors admesos de sort o data_collection i el comportament de allow_fallbacks poden canviar. Verifica’ls sempre a la documentació vigent d’OpenRouter abans de dependre’n.