Skip to content
ca es en

← Modelos y routing

Provider routing y preferencias

El objeto "provider" controla qué backend sirve un modelo — orden, fallbacks, parámetros requeridos, ordenación por precio o throughput y política de datos.

6 slides 5 min de lectura

  1. OpenRouter · Models i routing

    Provider routing y preferencias

    Decide tú qué backend sirve cada modelo.

    OpenRouter · Modelos y routing arlaf.dev

  2. Un modelo, muchos backends

    Recuerda que un modelo open-weight lo pueden servir varios proveedores. El objeto "provider" de la petición es cómo eliges cuál de ellos, en qué orden y con qué condiciones.

    OpenRouter · Modelos y routing arlaf.dev

  3. Las preferencias clave

    Dentro de "provider" caben varias preferencias:

    • order — lista ordenada de proveedores preferidos.
    • allow_fallbacks — si se permite caer a otro proveedor.
    • require_parameters — descarta backends que no admitan los parámetros que envías.
    • sort — ordena por precio o por throughput.
    • data_collection — excluye proveedores que recojan datos.
    OpenRouter · Modelos y routing arlaf.dev

  4. Un objeto provider completo

    {
  "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!" }
  ]
}
    OpenRouter · Modelos y routing arlaf.dev

  5. Precio, velocidad o privacidad

    Estas preferencias te dejan optimizar lo que importe en cada caso: el coste más bajo, la respuesta más rápida o no enviar datos a backends que las retengan.

    OpenRouter · Modelos y routing arlaf.dev
  6. El slug elige QUÉ modelo; el objeto provider elige QUIÉN lo sirve.
    OpenRouter · Modelos y routing arlaf.dev
Leer 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.