Arquitectura de confiabilidad

Tratamos la "estabilidad" como la característica número uno del producto. Esta página explica cómo lo logramos y qué sucede cuando algo sale mal.

¿Por qué es tan difícil la confiabilidad?

Los desarrolladores que se conectan directamente a la API oficial se topan con cosas como:

• Limitación de tasa / indisponibilidad regional
• Un único canal de pago o cuenta que se bloquea
• Problemas de compatibilidad durante los cambios de versión de modelo
• Colas en horas pico y picos en la latencia del primer token

Si un servicio de relay es solo un proxy simple, estos problemas se transmiten tal cual a los usuarios, o incluso empeoran. Nuestro enfoque es diseñar el sistema bajo la premisa de que "los upstreams son inestables", en lugar de tratar eso como una excepción.

Nuestra arquitectura de enrutamiento multiorigen

Para cada llamada a la API, la solicitud se maneja a lo largo de la siguiente ruta:

Mecanismos centrales:

• Grupo multi-upstream: múltiples canales independientes se ubican detrás del mismo modelo, evitando puntos únicos de falla
• Sondeo de salud: monitoreamos continuamente la tasa de éxito, la latencia del primer token y la tasa de limitación de cada upstream, y los canales no saludables se reducen de peso o se eliminan automáticamente
• Conmutación por error automática: cuando el canal principal devuelve 5xx / limitación de tasa / tiempos de espera, la solicitud cambia a un canal de respaldo en milisegundos, normalmente sin impacto de tu lado
• Reconexión de interrupción de streaming: cuando una respuesta en streaming se corta a mitad de camino, intentamos reanudarla en los protocolos que lo admiten

Nivel de servicio (SLA)

Nuestros compromisos externos se basan en "lo que realmente podemos entregar"; no hacemos promesas vacías.

El nivel Economy es para desarrolladores individuales que quieren la mejor relación valor-precio y pueden tolerar fluctuaciones ocasionales; si tu negocio tiene requisitos estrictos de confiabilidad, elige el nivel Enterprise o contacta a nuestro equipo de ventas para un plan personalizado.

Cómo se mide la disponibilidad:

• Contamos solo la tasa de éxito de las solicitudes "del lado de LMU AI", excluyendo los problemas de red del lado del usuario, los errores de parámetros y los rechazos de contenido del propio modelo upstream
• Una falla individual que dure < 60 segundos no se cuenta
• El informe mensual incluye tasas de éxito y latencia P95 desglosadas por modelo y por período de tiempo

Qué sucede durante un incidente

Fluctuación breve (< 5 minutos)

• La capa de enrutamiento cambia de upstream automáticamente, sin aviso
• La página de estado registra el evento

Interrupción de un solo upstream (< 1 hora)

• La capa de enrutamiento completa el cambio; si es visible para algunos usuarios/modelos, lo publicamos en la página de estado
• Los usuarios Standard y Enterprise reciben notificación por correo electrónico

Impacto regional o simultáneo en múltiples upstreams

• El evento se fija en la página de estado con actualizaciones periódicas
• Los usuarios Enterprise reciben actualizaciones de progreso por correo electrónico en tiempo real
• Se publica un análisis post mortem dentro de las 48 horas posteriores al fin del evento

Lo que no hacemos

Para evitar confundir a los usuarios, actualmente no prometemos lo siguiente:

• Cambio fluido y sin latencia: la conmutación por error introduce latencia adicional de milisegundos a segundos, por lo que nunca será completamente fluida
• Compensación de compatibilidad entre modelos: si un modelo upstream en sí se retira (por ejemplo, si el proveedor descontinúa una versión de modelo), lo anunciamos en lugar de cambiar silenciosamente a un modelo diferente
• Reintentos ilimitados: las solicitudes fallidas se reintentan un número limitado de veces según la política, para que no pagues por llamadas repetidas inesperadas

Preguntas frecuentes

Última actualización: 2026-09-10