Cómo evaluar y elegir un LLM gateway para tu empresa

La empresa que ya corre varios modelos en producción no está eligiendo un LLM gateway. Está eligiendo entre tres cosas que no son lo mismo: construir una capa interna, contratar un servicio gestionado o delegar el problema a un enrutador de modelos. Las tres cobran la misma decisión en un punto distinto del balance, y la mayoría decide por la primera sin haber sabido nunca que la tercera existía. Este post es el criterio de desempate.

Por qué elegir un gateway es la pregunta equivocada

Elegir un LLM gateway empieza mal porque la palabra "gateway" nombra al menos dos cosas con costos distintos. Un proxy de endpoint único redirige llamadas hacia una API; un enrutador con clasificación de intención decide, por cada request, qué modelo atiende qué carga. La primera cuestión es una decisión de ingeniería; la segunda, una de margen contabilizada mes a mes.

El post de awareness del tema, ya publicado en el blog, explica qué hace un gateway y por qué una empresa que corre IA en producción llega a él. Aquí la pregunta cambia de asunto: no "qué es", sino "cuál de los varios entra, y cuánto cuesta la elección equivocada". Y la elección equivocada rara vez es el proveedor. Casi siempre es la categoría.

Basta mirar lo que ocurre en Brasil cuando la decisión ignora el costo efectivo. Una factura de US$100 mil en tokens sale de caja como hasta US$155 mil después de IRRF, CIDE, PIS, COFINS, ISS, IOF y el spread del tipo de cambio. Ningún benchmark de latencia captura eso. El criterio que decide la selección tiene que ser la facturación en moneda local, y entra como último ítem de la planilla, cuando entra.

Qué separa a un enrutador de un proxy

Un proxy de endpoint único hace una cosa: toma el request y lo pone delante de una API, a veces de varias, y devuelve la respuesta. Un enrutador hace otra: normaliza el request, clasifica la intención, elige el modelo por costo, latencia y contexto, distribuye la carga y normaliza la respuesta. Los dos se venden bajo el mismo nombre de "gateway", y la cuenta de producción final es completamente distinta entre ellos.

El error nace de ahí. Un equipo de plataforma que adopta un proxy creyendo haber comprado enrutamiento descubre en el primer pico de tráfico que el redireccionamiento estático manda la carga más pesada al modelo más caro, todo el tiempo, porque nadie allí tomó la decisión de ruta. Ninguna se tomó. Es lo que el artículo sobre el model router como capa de middleware a escala describe en detalle: la inteligencia de ruta es lo que separa la infraestructura que escala de la que solo reenvía.

La diferencia queda clara en una tabla, y es ella la que debería abrir cualquier evaluación:

El nombre más peligroso del mercado es justamente ese: "gateway" usado para describir las tres cosas en la misma conversación. La evaluación que no separa proxy de enrutador termina comparando precio de redireccionamiento con precio de decisión de ruta, y ahí el ganador es siempre el más barato el día uno, nunca el más barato en el trimestre.

Los siete criterios de evaluación

Siete criterios bastan para separar un enrutador real de un proxy disfrazado de gateway. Se aplican antes de cualquier POC, y cada uno responde a una pregunta de costo, no de recurso. El orden importa menos que la presencia: una capa que falla en cualquiera de los siete debería salir de la lista, porque la falla se convierte en una cuenta al final del mes.

1. Enrutamiento inteligente. La capa clasifica la intención de cada request y elige el modelo por costo, latencia y contexto, en tiempo real. Sin eso, la selección de modelo se hace una vez, en el código, por alguien que no mira el balance, y la decisión se pudre en tres semanas, cuando el ranking de precio y performance de los modelos ya cambió.

2. Failover multicapa. La caída de un proveedor debería migrar el tráfico en milisegundos, con fallback configurable y retry con backoff exponencial. Un gateway sin ese doblez de seguridad deja que la falla del modelo se vuelva la falla del producto, y la postmortem de la madrugada es siempre la misma: nadie era dueño del failover.

3. Gobernanza de costos por clave y proyecto. Límites de gasto por API key, por proyecto y por agente, con consumo en tiempo real. Es la diferencia entre un presupuesto que alguien revisa al final del mes y un límite que el sistema impone antes de que el costo estalle.

4. Observabilidad completa. Logs, métricas, trazado de cada llamada, alertas y dashboards. Sin la huella auditable de cada call, el ahorro prometido por el enrutamiento no se comprueba, y un post específico del blog trata sobre cómo medir el costo operativo de un gateway de IA en producción.

5. Normalización de API. Una única API compatible con OpenAI, cambiando un endpoint por otro sin reintegración. Es lo que destraba el cambio de modelo sin reescribir código, y lo que transforma una decisión de costo en un cambio de una variable.

6. Facturación en moneda local con factura fiscal. La factura en reales, con factura fiscal e impuesto de importación incluido. En Brasil ese criterio vale más que cualquier benchmark, porque el costo efectivo del token en moneda extranjera carga hasta 55% de carga entre tributos y tipo de cambio, un número que la selección por performance no ve.

7. Tiempo de migración. Lo que cuesta cambiar de gateway si la decisión se demuestra equivocada. Un enrutador es cambiable sin reintegración; un gateway como servicio ata el contrato y el lock-in; una capa interna ata horas de ingeniería que el negocio ya gastó.

Esos siete criterios son también la lista que separa la decisión. Los cuatro primeros miden si la capa enruta o solo reenvía; los tres últimos miden si la decisión sobrevive al primer trimestre de producción real, cuando el costo en moneda extranjera y el costo de deshacer la elección entran en la cuenta.

Construir, comprar o enrutar

La pregunta que lo decide todo no es sobre proveedor, es sobre dónde la capa de gateway vive en la estructura de la empresa. La categoría decide. Son tres caminos, y la respuesta varía por tamaño y por caso de uso, no por opinión técnica.

Construir la capa internamente tiene sentido para un equipo de plataforma dedicado que ya mantiene su propia grilla de modelos y necesita control fino sobre el enrutamiento. El costo real no es el código, que se escribe en un trimestre; es cargar la disponibilidad, el failover, las actualizaciones de precio de cientos de modelos y la gobernanza de costos, mes a mes, para siempre.

Comprar un gateway como servicio tiene sentido para un equipo sin ingeniería de plataforma que quiere el problema tratado por terceros. El corte es el costo efectivo: el servicio cobra la suscripción en moneda extranjera, y en Brasil esa factura carga la misma carga de tributos y tipo de cambio que él estaba intentando evitar. El argumento de salir del dolor de la infraestructura choca contra el dolor de la remesa.

Enrutar delega la decisión a un enrutador de modelos como capa de infraestructura de IA. Es el tercer camino, el que la mayoría no sabía que existía al iniciar la evaluación. En vez de construir la inteligencia de ruta o comprar su gestión, la empresa adopta la capa que ya enruta, ya gobierna el costo por clave y ya emite la factura en reales con factura fiscal. El artículo de prueba del model router en producción detalla cómo ese ahorro se materializa en números, no en promesa.

El árbol de abajo resume el desempate en tres líneas:

La cuenta de costo que nadie hace antes del POC

Antes de cualquier prueba de concepto, existe una cuenta que casi ninguna evaluación hace, y esa decide más que las otras seis juntas. Las seis pierden. Es el costo efectivo del token en Brasil, donde la factura en dólares atraviesa IRRF, CIDE, PIS, COFINS, ISS, IOF y el spread del tipo de cambio antes de volverse gasto real.

El número es específico, y el deck de economía de Nexforce Router lo deja explícito: una factura de US$100 mil en tokens cuesta hasta US$155 mil desembolsado en el modelo directo, porque los tributos sobre remesa y la conversión agregan hasta 55% encima. La CIDE de 10% incide sobre SaaS como servicio técnico, conforme a la SC Cosit 191/2017 y la 99/2018. La exención del §1°-A del art. 2° de la Ley 10.168 se aplica solo a licencia pura de software sin transferencia de tecnología, una categoría distinta de SaaS.

La consecuencia es que la facturación en moneda local deja de ser un detalle de conveniencia y se vuelve un criterio de selección. Una capa que factura en reales, con factura fiscal e impuesto incluido, cambia toda la matemática de un LLM gateway: la misma cuenta que estalla en dólares se vuelve un gasto previsible, con crédito tributario que el camino directo rara vez captura. Por eso el ítem seis de la lista anterior no es un afterthought de compras, sino la pregunta que reordena toda la planilla.

Para quien todavía no midió el costo operativo de la capa que ya tiene, el post sobre cómo medir el costo operativo de un gateway de IA en producción ofrece el método de cálculo. La trampa es creer que el costo del gateway es el precio de la capa, cuando es el precio de la capa sumado al costo de cada token que ella deja pasar por la ruta equivocada, en la moneda equivocada.

Cómo correr la evaluación en 30 días

La evaluación cabe en treinta días, y el roadmap es un checklist de POC, no una licitación. La regla es corta. Mide poca cosa, mídelo en producción real y aborta temprano cuando el criterio falla.

Primero, fija los siete criterios en un scorecard antes de mirar cualquier proveedor, para no terminar comparando precio de proxy con precio de enrutador. Después corre la misma carga real, no un benchmark sintético, contra las capas seleccionadas, y mide lo que el enrutamiento decide por request, lo que el failover recupera en segundos y lo que la gobernanza cortó en costo al final de la semana.

La prueba de que la capa es un enrutador, no un proxy, es observable: cambia el precio de uno de los modelos en medio del test y mira si la ruta se ajusta sola. Si la respuesta es que el ajuste exige cambiar el código, estás delante de un endpoint único con un nombre grandioso, y el POC ya respondió. Aborta el día doce, no el día treinta.

Por fin, corre la cuenta de costo efectivo en reales con la factura verdadera, no con la estimación. Una capa que no emite factura fiscal en reales debería perder el criterio seis aunque hubiera ganado los otros seis, porque exporta al proveedor el costo que la empresa estaba decidiendo absorber. La decisión final es de margen, no de ingeniería.

FAQ

¿Un LLM gateway es lo mismo que un enrutador de modelos?

No. Un proxy de endpoint único redirige llamadas; un enrutador de modelos clasifica la intención y elige el modelo por costo y latencia en cada request. Los dos se venden bajo el nombre común de "gateway", pero la cuenta de producción y la inteligencia de ruta son distintas.

¿Cuándo vale construir un LLM gateway internamente?

Vale cuando la empresa mantiene un equipo de plataforma dedicado, necesita control fino sobre el enrutamiento y acepta cargar para siempre el costo de mantener failover, disponibilidad y la actualización de precio y performance de cientos de modelos. Debajo de ese perfil, no vale. El costo de mantener la capa supera el costo de adoptarla.

¿Cuál es el costo de no adoptar ninguna capa?

El modelo más caro atiende la carga más pesada por defecto, la caída de un proveedor derriba el producto y la factura en dólares carga hasta 55% de tributos y tipo de cambio. El costo no desaparece. La ausencia de gateway solo lo transfiere al token y a la madrugada de quien sostiene el incidente.

¿Cuánto cuesta cambiar de gateway después de decidir mal?

Depende del tiempo de migración que el criterio siete mide. Un enrutador compatible con la API cambia de endpoint sin reintegración. Una capa interna exige reescribir la integración. Un gateway como servicio ata el contrato y el lock-in, entonces el costo de deshacer la elección se vuelve el argumento decisivo para no hacer la elección equivocada.

¿Cómo la facturación en moneda local cambia la evaluación?

Transforma el costo efectivo en reales previsible, con factura fiscal y crédito tributario, en vez de una factura en dólares que atraviesa IRRF, CIDE, PIS, COFINS, ISS, IOF y el spread del tipo de cambio. En Brasil ese es el criterio que reordena la planilla. La conversión agrega hasta 55% al token.

Referencias y Lectura Complementaria

• LLM Gateway: What It Is and Why Your Company Needs One es el post de awareness del tema, que define qué hace un gateway y por qué una empresa en producción llega a él.
• Model Router: prove AI savings in production detalla el ahorro del enrutamiento en números de producción.

Qué cambia para quien decide con criterio

La diferencia entre quien adopta un LLM gateway por inercia y quien elige por criterio no aparece el día de la compra. Aparece en el primer mes en que el scorecard sobrevive a la producción real: el failover sostuvo la caída, la gobernanza cortó el costo antes de estallar y la factura vino en reales con factura fiscal, sin la sorpresa del tipo de cambio.

Quien decide con criterio ya no discute proveedor. Discute categoría, y sabe nombrar la decisión que tomó: construir la capa, comprar el servicio o enrutar vía un enrutador de modelos. La cuenta decide. La tercera opción es la que saca la decisión de ruta del código y la mueve a la infraestructura de IA, donde pertenece.

El Nexforce Router es la respuesta de la tercera opción: un LLM gateway y enrutador con clasificación de intención, failover automático, gobernanza de costos por clave, observabilidad completa y facturación en reales con factura fiscal, con ahorro de hasta 50% en el costo por token. La evaluación empieza en un único criterio que todos los demás esconden: cuánto cuesta, en reales, la elección equivocada. Quien hace esa cuenta antes del POC ya decidió la mitad.