Los modelos de pricing de las gateways LLM explicados: por token, por request, BYOK, flat
Cuatro modelos de pricing, cuatro estructuras de incentivos — elige el alineado con tu uso
Las gateways LLM cobran de cuatro maneras: markup de proveedor, metered, flat por request y OSS self-host. Cada modelo alinea los incentivos de forma distinta. Aquí cómo elegir.
La mayoría de equipos eligen una gateway LLM por las features. Es el filtro inicial equivocado. El primer filtro debería ser el modelo de pricing, porque el modelo de pricing determina qué está estructuralmente incentivada a optimizar la gateway — y por tanto qué hace ship, qué deprecia, y a qué resiste silenciosamente con el tiempo.
Hay cuatro modelos de pricing en el mercado de gateways LLM. Cada uno crea una alineación distinta entre tú y tu gateway. Una vez que ves el patrón, las diferencias de features empiezan a tener sentido.
Modelo 1: Markup de proveedor (estilo OpenRouter)
Cómo funciona. Envías tus requests a la gateway. La gateway llama a los proveedores desde su cuenta. La gateway te factura los tokens con un pequeño markup por encima de las tarifas wholesale. Tus claves de proveedor no entran — de hecho, ni siquiera necesitas cuentas de proveedor.
Para qué está optimizado. Facilidad de onboarding. Una tarjeta, un signup, ya estás live. Catálogo de modelos masivo porque la gateway pre-negocia con cada proveedor.
El incentivo. El revenue de la gateway crece con tu gasto en tokens. Cada token ahorrado es un token de revenue perdido. Las features que reducen tu gasto — routing agresivo a modelos más baratos, caching avanzado, alertas burn-rate — son features que la gateway tiene una desincentiva estructural a hacer ship correctamente.
Dónde funciona. Prototipado. Side projects. Casos de uso donde el gasto total es pequeño y la conveniencia domina. A unos cientos de dólares al mes, un markup de 5% es ruido.
Dónde se rompe. A escala. Una vez que tu gasto pasa unos miles de dólares al mes, el markup acumula en un line item real. 5% sobre 10K €/mes son 500 €/mes, recurrentes. Y la gateway no tiene ningún motivo estructural para ayudarte a reducir los otros 10K €.
Modelo 2: Metered / usage-based (estilo Vercel AI Gateway)
Cómo funciona. Pagas al proveedor por los tokens directamente (BYOK, normalmente). La gateway te cobra una tarifa metered — por request, por token routeado, por MB procesado — encima. A veces hay un tier gratuito.
Para qué está optimizado. Plataformas donde la gateway está embebida en un producto más amplio. Vercel la bundlea con su plataforma. Cloudflare la bundlea con su edge. El medidor está diseñado para escalar suavemente con tu uso para no parecer punitivo a bajo volumen.
El incentivo. Más suave que el markup de proveedor, pero todavía alineado con el crecimiento del uso. La gateway gana más dinero cuando tu volumen de requests sube. El routing basado en inteligencia hacia modelos más baratos sigue reduciendo su revenue, aunque menos dramáticamente que con el markup de proveedor.
Dónde funciona. Cuando la tarifa metered es pequeña frente a tu gasto en proveedor y valoras la integración con la plataforma. Para equipos ya comprometidos con Vercel o Cloudflare, encaja naturalmente.
Dónde se rompe. A volúmenes muy altos, donde incluso un pequeño medidor por request se acumula. Y cuando la desalineación de incentivos empieza a notarse — la gateway podría hacer ship de observability y fallbacks antes que features que recortan tus costes.
Modelo 3: Suscripción flat por request (estilo HiWay)
Cómo funciona. Pagas a los proveedores directamente al wholesale (BYOK). Pagas a la gateway una suscripción mensual flat basada en el tier de volumen de requests — por ej. Free a 2.500 req/mes, Build a 15 € por 100K, Scale a 39 € por 500K, Business a 249 € por 5M, enterprise custom. La misma suscripción cubre cualquier modelo al que routees.
Para qué está optimizado. Coste predecible. Tu coste de gateway es un line item conocido para el mes, independiente de cómo routees el tráfico.
El incentivo. El revenue de la gateway está desacoplado de tu gasto en tokens. No importa si routeas a Haiku o a Opus — la suscripción es la misma. Las features que reducen tu gasto en tokens (routing a modelos más baratos, caching, alertas burn-rate) no le cuestan nada a la gateway, así que la gateway tiene un incentivo estructural a hacer ship correctamente de ellas.
Dónde funciona. Equipos en producción con un gasto no trivial que se preocupan por los controles de coste y los márgenes predecibles. Equipos UE que también quieren BYOK + hosting UE junto a este modelo de pricing.
Dónde se rompe. A volúmenes casi nulos donde el Free (2.500 req/mes) sobra y donde incluso el tier Build a 15 €/mes pesa para un hobby project. Para esos, el Free o las APIs directas del proveedor son más simples.
Modelo 4: OSS self-hosted (estilo LiteLLM)
Cómo funciona. Te bajas el software, lo despliegas tú mismo, le pagas al proveedor directamente. La gateway en sí no tiene coste de runtime más allá de la infra sobre la que la haces correr.
Para qué está optimizado. Control, coste a escala (si ya tienes la plataforma), evitar el vendor lock-in.
El incentivo. Ninguno — no hay vendor que incentivar. La roadmap del software la dirigen los mantenedores y las contribuciones de la comunidad. Las features llegan cuando alguien las escribe.
Dónde funciona. Equipos con platform engineers e infra ops existente. Entornos regulados donde correr tu propia gateway es la única opción compliant.
Dónde se rompe. Equipos pequeños sin capacidad de platform engineering. La etiqueta "gratis" esconde 4-8 horas/semana de ops, on-call, carga de upgrade. Mira nuestro post separado sobre la economía del self-host.
La matriz de alineación
Aquí va la misma información en matriz:
| Modelo | Quién paga los tokens | Modelo de revenue gateway | ¿Alineado para ayudarte a ahorrar? |
|---|---|---|---|
| Markup de proveedor | Gateway (luego te factura) | % del gasto en tokens | No — el revenue crece con el gasto |
| Metered | Tú (BYOK) | Medidor por request | Parcialmente — atado al volumen |
| Flat por request | Tú (BYOK) | Suscripción flat | Sí — revenue independiente del gasto |
| OSS self-host | Tú (BYOK) | Ninguno | N/A — no hay vendor |
La tercera fila es la que cambia las cosas. Cuando el revenue de la gateway está desconectado de tu gasto en tokens, las features que hace ship empiezan a verse distintas. No es magia; es solo alineación de incentivos.
Sin tarjeta de crédito
El razonamiento del break-even
Hagamos un break-even realista entre las dos opciones gestionadas — markup de proveedor y flat por request — a distintos niveles de gasto.
Escenario: 500K requests/mes, workload mixto
Supón que cada request tiene un perfil de tokens medio que te cuesta 0,008 € a tarifas wholesale del proveedor. Gasto wholesale total: 4.000 €/mes.
Modelo markup de proveedor (5% markup)
- Tokens wholesale: 4.000 €
- Markup: 200 €
- Total: 4.200 €/mes
Modelo flat por request (tier Scale a 39 €, que cubre hasta 500K requests)
- Tokens wholesale (BYOK, pagados a los proveedores): 4.000 €
- Suscripción gateway: 39 €
- Total: 4.039 €/mes
Flat por request gana por 161 €/mes a esta escala — y eso es antes incluso de que entre el smart routing en juego.
Scale up: 5M requests/mes, 40.000 € de gasto en proveedor
- Markup de proveedor (5%): 42.000 €/mes
- Flat por request (tier Business a 249 €, 5M requests): 40.249 €/mes
Flat por request gana por 1.751 €/mes. Más de 21.000 €/año, totalmente por la ausencia de markup porcentual.
Añade smart routing al segundo escenario — routea el 60% del tráfico a modelos del tier Haiku en vez de Sonnet — y tu factura wholesale puede caer un 40-85%, acumulando los ahorros. Bajo markup de proveedor, el 30% de ese ahorro todavía se va a la gateway en markup. Bajo flat por request, el 100% del ahorro es tuyo. El smart routing es independiente del volumen — se aplica a cada request, hagas 5K o 5M al mes.
Cómo se ve esto en la práctica
Tres patrones concretos que veo cuando los equipos cambian de modelo de pricing:
Patrón 1: Equipo en markup prueba BYOK + flat por request a 10M req/mes. Iban a 8.000 €/mes con markup 4% incluido. Pasan a flat por request en un tier Enterprise custom + BYOK. Su markup porcentual desaparece. Su factura de proveedor se queda en 7.700 €/mes al principio. Pero más importante, el flip de incentivos se dispara — empiezan a activar smart routing agresivo porque la gateway les ayuda activamente a routear más barato. Seis meses después su factura de tokens es un 35% más baja. Ahorro anual total: unos 38.000 €.
Patrón 2: Equipo self-hosted de 4 ingenieros pasa a gestionado. "Ahorraban" en gateway haciendo self-host de LiteLLM, pero dedicaban 6 horas/semana de ingeniería a ello. Pasan a gateway flat por request en el tier Business a 249 €/mes. Su capacidad de ingeniería para trabajo de producto sube ~25 horas/mes. Las features hacen ship más rápido. La suscripción se paga con el primer retraso evitado — más el smart routing que empieza a recortar la factura del proveedor por encima.
Patrón 3: Solo founder se queda en markup. Gasto mensual total 80 €. Un modelo markup con signup instantáneo es la elección correcta para él. El markup del 5% son 4 €. La fricción del setup BYOK + suscripción no compensa los 4 €. Migrará en 18 meses si el negocio crece.
Las tres decisiones son correctas para sus contextos. El error es elegir la equivocada para tu contexto, normalmente porque solo miraste las features y no el modelo de pricing por debajo.
Cuidado con estos anti-patterns
"Cobramos un pequeño porcentaje sobre el uso de tokens" + "Tenemos features brutales de reducción de coste"
Esas dos cosas están en tensión. Si el revenue de la gateway crece cuando gastas más, hacer ship de features que te hacen gastar menos es un contra-incentivo. Algunas empresas las hacen ship igual porque su brand lo exige; la mayoría las despriorizan en silencio.
Estructuras de tiers que parecen generosas abajo y aprietan arriba
Particularmente común en modelos metered. Las primeras 100K requests son gratis, las siguientes 400K baratas, y de algún modo por encima de 1M/mes el coste por request triplica. Mira siempre la curva sobre tus 12 meses de uso proyectado, no solo el bucket de hoy.
Markup opaco
Algunas gateways no divulgan abiertamente su markup. Tú les pagas, ellas pagan al proveedor, nunca ves la tarifa wholesale. Si no puedes saber cuál es el markup, probablemente es más amplio de lo que adivinarías.
Tiers "gratis para siempre" que atrapan tus datos
Un tier gratis que no te deja exportar tus logs de requests, el historial de prompts, o los datos de observability es un foso de lock-in disfrazado de generosidad. Verifica siempre las condiciones de exportación.
Cómo elegir tu modelo de pricing
Tres preguntas:
1. ¿Cuál es tu gasto y a qué velocidad crece? Pequeño y plano → el markup va bien. Crece rápido → BYOK + pricing flat acumula a tu favor.
2. ¿Quieres features de reducción de coste? Si quieres smart routing, caching, alertas burn-rate — quieres una gateway cuyo revenue no baje cuando esas features funcionan. Eso es BYOK + flat, o OSS self-hosted.
3. ¿Tienes capacidad de platform engineering? Si sí, OSS self-host está sobre la mesa. Si no, descártalo y elige entre las opciones gestionadas.
Responde a esas tres y tendrás tu respuesta en 30 segundos.
El takeaway
Las gateways LLM no se diferencian solo por features. Se diferencian por la forma de los incentivos cocinados en su pricing. Sobre 12-24 meses de uso, esa estructura de incentivos pesa más que cualquier feature concreta, porque determina qué features siguen mejorando y cuáles se estancan en silencio.
Elige primero el modelo de pricing. Las features correctas vienen detrás.
Próximo: Vercel AI Gateway en producción — fortalezas, límites, alternativas.
Was this useful?
Comments
Be the first to comment.