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.
Gateway pricing models compared - $10k/mo spend
Monthly all-in cost ($) across three billing architectures
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: Markup BYOK degresivo (estilo HiWay)
Cómo funciona. Pagas a los proveedores directamente al wholesale (BYOK). Pagas a la gateway un markup degresivo sobre tu gasto API mensual - por ej. Free para empezar, Scale con markup 9-12,5% según volumen (12,5% bajo 500 $/mes, 11% entre 500 y 5.000 $/mes, 10% entre 5.000 y 20.000 $/mes), Enterprise negociado por encima. La misma estructura de markup se aplica independientemente del modelo al que routees.
Para qué está optimizado. Coste proporcional al valor. Tu coste de gateway evoluciona con tu gasto real, pero se mantiene en una proporción conocida de antemano. Cuanto más routeas inteligentemente a modelos más baratos, menor es el coste absoluto del markup.
El incentivo. El revenue de la gateway es proporcional a tu gasto en tokens, pero los ahorros de routing te benefician al 100% en el lado del proveedor. Las features que reducen tu gasto en tokens (routing a modelos más baratos, caching, alertas burn-rate) reducen tu coste total - gateway incluida - así que la gateway tiene incentivo a hacer ship correctamente de ellas.
Dónde funciona. Equipos en producción con gasto variable que quieren una estructura de coste simple y transparente. Equipos UE que también quieren BYOK + hosting UE. Workloads mixtos donde el smart routing (40-85% de ahorro) cubre con creces el markup.
Dónde se rompe. Para volúmenes muy predecibles y estables, una suscripción flat puede ser más fácil de presupuestar. Para hobby projects o tráfico mínimo, el plan Free cubre las funcionalidades básicas sin coste adicional.
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 |
| Markup BYOK degresivo | Tú (BYOK) | Markup % degresivo sobre gasto API | Sí - ahorros de routing reducen coste proveedor y gateway |
| OSS self-host | Tú (BYOK) | Ninguno | N/A - no hay vendor |
La tercera fila es la que cambia las cosas. Con markup BYOK degresivo, los ahorros de routing reducen simultáneamente tu factura de proveedor y el coste de gateway. 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 markup BYOK degresivo HiWay (plan Scale, 10% para 500-5.000 $/mes de gasto)
- Tokens wholesale (BYOK, pagados a los proveedores): 4.000 €
- Markup HiWay (10% sobre 4.000 €): 400 €
- Total: 4.400 €/mes
A este nivel de gasto los dos modelos son comparables. El diferenciador clave es lo que pasa cuando entra el smart routing.
Con smart routing: routea el 60% a modelos del tier Haiku
La factura wholesale cae a 2.000 €/mes.
- Markup de proveedor (5%, calculado sobre gasto antes del routing): ~200 € o más sin cambios
- Markup BYOK degresivo (10% sobre 2.000 €): 200 €
Con markup BYOK degresivo, el markup de gateway baja proporcionalmente con tu gasto. El 100% de los ahorros del proveedor te beneficia - y el markup sobre la base reducida también es más bajo. 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 + markup degresivo a 10M req/mes. Iban a 8.000 €/mes con markup 4% incluido. Pasan a markup BYOK degresivo Enterprise + BYOK. Su markup residual está alineado con el gasto real. Más importante, el flip de incentivos se dispara - empiezan a activar smart routing agresivo porque cada euro ahorrado en el proveedor también reduce el markup de gateway. 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 BYOK markup degresivo (plan Scale). Su capacidad de ingeniería para trabajo de producto sube ~25 horas/mes. Las features hacen ship más rápido. El markup 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.