Cómo evaluar un AI API Gateway: checklist para producción

Evalúa un AI API gateway ejecutando tu contrato de protocolo real, forzando los modos de fallo importantes y revisando la evidencia por request. Una lista de funcionalidades o un “hello world” exitoso no demuestra streaming correcto, Tools compatibles, fallback seguro, coste exacto, aislamiento ni una salida viable.

El proceso más sólido separa dos tipos de criterio: gates no negociables que eliminan un candidato y cualidades operativas puntuables que solo se comparan cuando todos los gates han pasado.

Definir primero el contrato del workload

No empieces con una tabla de vendors. Selecciona un workload representativo y documenta sus invariantes:

• endpoint exacto: Responses, Chat Completions, embeddings, images u otra API;
• Model IDs exactos y si se permiten aliases;
• modos streaming y non-streaming;
• Structured Outputs, Function Calling, hosted tools, reasoning u otros campos necesarios;
• longitudes normales y de percentil alto de input y output;
• concurrency, request rate, region y deadline visible para el usuario;
• campos obligatorios de usage, cache, cost y correlación;
• rutas fallback permitidas y si se prohíbe sustituir el modelo;
• requisitos de data retention, access, residency y deletion;
• operaciones de aplicación que producen Side Effects.

Un gateway puede aprobar para un asistente interno de texto y fallar para un coding agent en streaming. “OpenAI-compatible” tampoco define el workload: la compatibilidad varía por endpoint, Event Type, Tool, Schema Keyword y Provider Route.

Si aún se decide entre proxy y control plane consciente del modelo, empieza por LLM Proxy vs AI Gateway. Esta checklist supone que la categoría gateway ya está justificada y comprueba si una implementación puede asumir las responsabilidades.

Aplicar descalificadores rápidos antes de un trial largo

La primera revisión debe retirar candidatos incapaces de cumplir una frontera obligatoria. Pide comportamiento reproducible, no promesas de roadmap.

Gate	Condición de fallo inmediato	Evidencia requerida
Protocol	Se pierde o reescribe mal un Request Field, Output Item o Stream Event necesario	Request/response redactados y Parser Result
Model identity	El gateway cambia el modelo en silencio	Attempt Record con modelo solicitado y real
Streaming	Buffer completo, cancelación perdida o Tool Argument Fragments corruptos	Secuencia de eventos con timestamps y cancel trace
Authentication	Browser o workload recibe credenciales del proveedor	Credential Flow y ejercicio real de key rotation
Tenant isolation	Un proyecto usa o inspecciona keys, usage o logs de otro	Comprobaciones con cuentas realmente aisladas
Cost evidence	Un charge no se conecta con modelo, ruta, price basis y usage	Ledger reconciliado de una request
Failure safety	Se repite un Partial Stream o cancelar inicia otro attempt	Traces forzados de partial stream y cancelación
Export and exit	No puede recuperarse configuration y contract sin reescribir la app	Export sample y rollback hacia endpoint nativo

Un fallo obligatorio no se compensa con una puntuación total alta. Un dashboard atractivo no corrige Tenant Isolation, ni un precio bajo corrige un Tool Contract incorrecto.

Construir un corpus pequeño de conformidad de protocolo

Usa inputs deterministas y no sensibles, y versiona el wire behavior esperado. El corpus debe llamar al endpoint real; no debe mockear el provider ni reimplementar la conversión del gateway como Test Oracle.

Caso	Request	Observación obligatoria
Texto non-streaming	Modelo fijado y prompt estable	Status, Model Identity, text location, usage y Request ID correctos
Texto streaming	Mismo prompt con streaming	Eventos ordenados, first effective output, final event y cancelación
Structured output	Strict Schema con required y additionalProperties: false	Output válido o Unsupported Error explícito, sin Silent Downgrade
Function Calling	Función read-only y resultado devuelto	Function Name, JSON arguments, Call ID y respuesta final
No-tool path	Tools declaradas pero no necesarias	Texto normal sin Tool Call inventada
Invalid field	Campo no soportado o request malformada	Client Error estable; ningún fallback oculta el defecto
Long input boundary	Inputs por debajo y encima del límite	Aceptación documentada o rechazo explícito, nunca truncado silencioso
Usage detail	Request que active cache o reasoning usage	Campos conservados y reconciliados con Billing Record
Cancellation	Cancelación después de conectar y tras first output	Upstream Work se detiene y no comienza un fallback nuevo
Partial stream	Fallo después de effective output	Un Partial Failure explícito, sin segunda respuesta invisible

Ejecuta cada caso en todas las rutas que pueden servir el workload. Aprobar la primaria no cualifica el fallback. La guía de Structured Outputs y la comparación de Function Calling aportan casos a nivel de campo.

Registra Gateway Version, Route Configuration Version, Model ID, Provider, Region, Timestamp y Sanitized Result Hash. Repite antes del rollout y después de cambios materiales de ruta.

Probar routing y fallos, no solo éxito

Una afirmación de fiabilidad solo vale si su Failure Policy es visible. Fuerza antes de producción:

• Primary Route no disponible antes de headers;
• Rate Limit con y sin Retry-After;
• fallo de Authentication o Account upstream;
• headers lentos y first effective output lento;
• Provider Response malformada;
• cancelación mientras el upstream sigue pendiente;
• pérdida de conexión tras comenzar output visible;
• agotamiento de todas las rutas elegibles.

Para cada caso captura Attempt Order, Selected Route, Status, Timing, si comenzó el output, Terminal Reason, Usage y Cost. Confirma que se conserva el modelo y protocolo solicitados salvo que exista una política explícita de sustitución.

Mide Attempt Amplification entre SDK, aplicación, gateway y provider. Una capa debe poseer el same-contract fallback inmediato y la aplicación debe decidir si repetir la User Action completa. AI API Fallback Strategy ofrece la matriz por fases y el modelo de budget.

La latencia requiere la misma precisión: compara upstream headers, first SSE event, first effective output, first visible text, completion y visible output speed con concurrency realista. Rechaza un único promedio sin definición. Consulta AI API Latency Metrics.

Reconciliar usage y coste desde una request

Sigue varias requests completadas por toda la cadena:

application request ID
  → gateway attempt sequence
  → selected model and route
  → provider or normalized usage
  → applicable price basis
  → final recorded charge

La evaluación debe responder:

• ¿Se representan input, output, cached, reasoning y tool-related units cuando aplican?
• ¿Qué cifras vienen del provider y cuáles se estiman?
• ¿Cuándo se selecciona el precio y queda fijado para la request?
• ¿Cómo alteran el charge un group, Service Tier, discount o surcharge?
• ¿Qué attempts fallidos generan coste del provider y cómo se registran?
• ¿Un fallback final exitoso oculta attempts facturables anteriores?
• ¿Currency Conversion y Rounding Rule son explícitos?
• ¿Finance puede reproducir el total diario desde registros inmutables?

Prueba completion normal, same-contract fallback, request cancelada y upstream error. Un dashboard total no basta: hace falta un registro defendible por request. AI API Cost Tracking separa Provider Usage, Platform Pricing, Customer Charge y Supplier Cost.

No compares ahorro si no mantienes constantes modelo, workload, cache behavior, output length, failure rate y Provider Price Basis. Un coste aparente menor puede deberse a usage ausente o sustitución silenciosa.

Verificar la frontera de seguridad y datos

Dibuja el Data Flow real desde el client al gateway y a cada provider. Para cada salto, identifica quién lee credentials, request/response content, metadata y administrative configuration.

Como mínimo verifica:

• Provider Credentials server-side, cifradas at rest y nunca devueltas a clientes normales;
• Application Keys con scope por proyecto/workload y revocación independiente;
• Authorization server-side en todos los management y log endpoints;
• logs sin API Keys completas y controles explícitos de Prompt/Response Retention;
• Support Access atribuible y limitado;
• cambios con Actor, Time, Before/After y Rollback Evidence;
• traces exportadas sin Secrets ni contenido personal o propietario;
• deletion y retention demostrables, no solo descritos;
• Region y Subprocessor Claim coherentes con la ruta usada;
• Abuse Limits antes de trabajo upstream costoso cuando sea posible.

Pregunta qué ocurre en key rotation, salida de un operador, compromiso de Application Key o filtración de Provider Key. Ejecuta rotación y revocación con Test Credentials aisladas; no copies Production Secrets.

El gateway no vuelve seguras Tools inseguras. Authorization, transactionality, approval e idempotency de Tool siguen siendo responsabilidad de aplicación. AI API Key Security and Cost Controls separa credentials y límites de workload.

Evaluar el control plane operativo

El data plane puede funcionar mientras el control plane crea riesgo.

Área	Preguntas obligatorias
Versioning	¿Cada cambio de route, price, policy y key tiene versión o Actor?
Validation	¿Se rechazan route inválida o modelo incompatible antes de activar?
Rollout	¿Puede limitarse un cambio a un workload o porcentaje pequeño?
Rollback	¿Se restaura rápido la Last-known-good Configuration?
Availability	¿Qué ocurre con requests existentes y nuevas sin control plane?
Health	¿Channel Health usa evidencia actual y puede auditarse el auto-disable?
Incidents	¿Puede reconstruirse una request sin buscar en sistemas inconexos?
Limits	¿Rate y Quota Decision siguen correctas con concurrency?
Change ownership	¿Emergency Edits están separados de Product Configuration?

Completa un Configuration Rollback y una retirada de ruta no saludable. Mide pasos y comprueba el comportamiento del data plane. Una captura de un botón no sustituye el drill.

Probar la salida antes de firmar

Un gateway puede crear dependencias de Model Aliases, Custom Headers, route names propietarios, Log APIs, Normalized Error Shapes o Hosted Prompt/Tool Configuration. Lista cada una y decide si es valor intencional o lock-in accidental.

Un Exit Drill práctico debe:

1. exportar route, key policy, price y audit configuration en formato documentado;
2. mover un workload a un endpoint nativo de prueba;
3. sustituir headers o aliases exclusivos por configuration de aplicación explícita;
4. conservar request correlation y usage reconciliation durante el cambio;
5. documentar funcionalidades que requieren rediseño;
6. estimar Exit Engineering desde el trabajo observado, no desde una promesa comercial.

No se exige intercambiabilidad con todos los providers. Se exige saber qué posee el equipo, qué posee el gateway y cómo recuperar el Protocol Contract subyacente.

Puntuar solo después de aprobar los gates

Usa pass/fail para fronteras duras y una escala pequeña para evidencia operativa:

Puntuación	Significado
0	No soportado o contradicho por el test
1	Afirmado o demostrado manualmente una vez, con evidencia débil
2	Demostrado de forma repetible con evidencia por request
3	Repetible, monitorizado y recuperable con un control probado

Puntúa Protocol Coverage, Route Reliability, Attempt Evidence, Latency Diagnostics, Usage Accuracy, Cost Reconciliation, Key Isolation, Auditability, Configuration Rollback, Supportability y Exit Effort según el workload. Mantén Raw Evidence junto a cada fila.

Evita falsa precisión como 87.4/100 si hay criterios subjetivos. Registra gates y resultados, score con links, gaps aceptados y owner, remediation deadline, supuestos de coste/contrato, candidatos elegidos y rechazados, y fecha de revisión tras el primer mes.

Comparar build y buy por responsabilidad

La pregunta no es si la solución interna evita una licencia, sino qué responsabilidades puede mantener el equipo.

Responsabilidad	Build interno	Producto comprado o managed
Protocol updates	Seguir schemas y regressions del provider	Verificar updates del vendor y compatibility
Routing and retry	Diseñar state machine y Failure Evidence	Configurar policy y auditar attempts reales
Usage and billing	Normalizar usage y mantener pricing logic	Reconciliar vendor records con Finance Truth
Security	Guardar Secrets, aislar tenancy y auditar access	Validar Vendor Boundary y Least Privilege
Reliability	Operar data plane, control plane y on-call	Monitorizar vendor e integración y conservar exit path
Product support	Diagnosticar cada interacción app/provider	Separar fallos de gateway, provider y aplicación

No uses cifras genéricas de salarios o “horas ahorradas”. Estima con tu On-call Load, historial de Protocol Changes, Incident Frequency, Finance Requirements y Compliance Work. Un producto managed sigue necesitando un owner interno.

Aplicar la checklist a Modelflare con precisión

El alcance actual de Modelflare debe ser explícito. Proporciona Workload API Keys, routing del Requested Model por Groups y Channels elegibles, Ordered Group Fallback para keys normales, selección por estrategia para Smart API Keys, Group RPM Admission antes del upstream y registros por request de Usage, Cost, Status y Timing.

GPT, Codex y tráfico OpenAI son el objetivo de compatibilidad adaptada completa. Otras familias OpenAI-compatible deben evaluarse como Raw Chat Completions Pass-through salvo capacidad verificada. Una Base URL común no demuestra Responses, Hosted Tools, Structured Outputs o Function Calling idénticos en cada ruta.

El fallback de Modelflare debe buscar una ruta elegible para el Requested Model, no escoger otro modelo en silencio. Channel Failover se detiene después de comenzar Downstream Output. Comprueba estas afirmaciones con el corpus y los failure drills.

Usa Models & Pricing para conocer modelos y groups actuales, y Modelflare Docs para crear una Test Key aislada. Mantén requests no sensibles, fija el modelo exacto y conserva Request IDs para inspeccionar attempts.

La decisión final debe ser reproducible: otro ingeniero puede ejecutar el mismo corpus, revisar las mismas clases de evidencia y comprender por qué aprobó el candidato. Es más lento que leer una página comparativa, pero mucho más rápido que descubrir un Tool Contract incompatible, una factura sin trazabilidad o un fallback inseguro cuando el gateway ya sirve producción.