Enlaces importantes
Panel de estado del servicio (actualmente solo disponible para clientes de la API Enterprise)
Comenzar con los valores predeterminados correctos
Cuando abres el panel de estado del servicio, los valores predeterminados son:
Todos los proyectos
Últimos 30 días
Resolución por hora
Esta vista solo es útil para orientarte. La solución de problemas significativa siempre requiere filtrar.
Filtrar antes de investigar
El filtrado correcto es el paso más importante. La mayoría de las interpretaciones erróneas provienen de mezclar modelos, niveles o proyectos.
Filtrar por modelo (uno a la vez)
Filtra siempre a un solo modelo.
Por qué:
Los problemas en modelos con poco tráfico pueden quedar ocultos por tráfico de mayor volumen
Los modelos de alto volumen pueden hacer que problemas localizados parezcan globales
Los distintos modelos tienen diferentes objetivos de rendimiento
Nota: seleccionar varios modelos los agrega; no alterna entre ellos.
Filtrar por nivel de servicio
Si usas más de un nivel (estándar, Priority, Scale), filtra siempre al nivel que estás investigando.
Por qué:
Los niveles tienen distintas características de rendimiento
Los niveles Priority y Scale tienen SLA definidos
Mezclar niveles oculta el rendimiento del nivel de pago
Esto es especialmente importante para el análisis de latencia.
Filtrar por proyecto
De forma predeterminada, el estado del servicio muestra todos los proyectos.
Para solucionar problemas, filtra a los proyectos donde se observó el problema.
Por qué:
Un solo proyecto de alto volumen puede dominar las métricas.
Los proyectos afectados más pequeños pueden quedar ocultos por tráfico no relacionado.
Deja seleccionado “Todos los proyectos” solo si crees que el problema realmente afecta a toda la organización.
Solución de problemas de errores
Usar la vista de solicitudes HTTP
Para investigar errores:
Filtra por modelo y nivel de servicio.
Abre la pestaña Solicitudes HTTP en lugar de la pestaña Tiempo de actividad.
Esta vista muestra el total de solicitudes y los recuentos de errores por código de estado HTTP. Amplía a resolución por minuto para identificar picos o cambios granulares.
Interpretar tasas de error, no recuentos
Se esperan algunos errores en cualquier sistema de producción. Enfócate en el porcentaje de errores, no en los totales sin procesar.
Cuanto mayor sea tu volumen total, mayor será la cantidad potencial de errores incluso con una tasa de error extremadamente baja.
Cuando faltan errores en el estado del servicio
Si ves errores del lado del cliente, pero no datos correspondientes en el estado del servicio:
Es probable que las solicitudes no hayan llegado a OpenAI.
El problema suele estar en un componente anterior (tiempos de espera, proxies, red).
Esto es común con tiempos de espera agresivos del lado del cliente.
Solución de problemas de latencia
El análisis de latencia es más significativo en los niveles Priority y Scale, que tienen SLA definidos. El nivel estándar puede mostrar una variación de latencia más amplia y no tiene latencia garantizada.
Métricas clave
Para ver cada métrica, haz clic en la pestaña correspondiente:
Velocidad de tokens: tokens generados por segundo; independiente del tamaño del prompt.
Tiempo de solicitud: duración total de la solicitud; se ve muy afectada por el tamaño de la salida y el razonamiento.
Tiempo hasta el primer token (TTFT): tiempo hasta que se genera el primer token; se ve muy afectado por el tamaño del prompt de entrada no almacenado en caché y el razonamiento.
Revisa siempre los percentiles P50 / P75 / P95. Los promedios pueden ocultar el impacto en usuarios reales.
6. Correlacionar la latencia con el uso de tokens
El estado del servicio muestra cuándo cambió el comportamiento. Los datos de uso ayudan a explicar por qué.
En el panel de uso, haz lo siguiente para asegurarte de estar viendo los datos relevantes para tu vista en el panel de estado del servicio:
Filtra al mismo proyecto y modelo.
Agrupa por nivel de servicio, si corresponde.
Enfócate en los tokens de salida, que son los que más afectan la latencia.
Para un análisis más profundo, exporta los datos de actividad y examina los tokens por solicitud a lo largo del tiempo.
7. Qué compartir con soporte (si es necesario)
Si te comunicas con soporte, incluye:
ID de organizaciones afectadas (importante)
Puntos de acceso afectados, como Chat Completions o Responses (importante)
Modelos afectados (importante)
Si esto ocurre en el nivel Scale o Priority (importante)
Rangos de tiempo con zona horaria para latencia o errores (importante)
x-request-id o X-Client-Request-Id relevantes, si están disponibles
Marcas de tiempo con zona horaria, o al menos la fecha, para las solicitudes que proporciones
Si está disponible, incluye también:
ID del proyecto relacionado con las solicitudes
Si las solicitudes de residencia de datos se ven afectadas y cuáles
Descripciones de las tendencias que observas
Para el tipo de problema, incluye:
Errores: porcentaje aproximado de solicitudes que fallan o presentan errores, códigos de respuesta, mensajes de error y cuánto tardó en recibirse la respuesta de error.
Latencia: qué percentiles están afectados (P50 / P90 / P95 / P99), qué tan altos son en comparación con la línea base del cliente y ejemplos de solicitudes lentas con marcas de tiempo de envío y recepción.
Ambos: capturas de pantalla o una tabla de datos de errores o latencia, además de cómo determinaste que las tasas de error o la latencia fueron más altas de lo esperado.
Escenarios comunes de solución de problemas
Se producen tiempos de espera, pero el estado del servicio parece normal
Causa posible: las solicitudes agotan el tiempo de espera antes de llegar a OpenAI.
Verifica:
Configuración de tiempo de espera del cliente o proxy
Cambios en la red local o el balanceador de carga
Presencia de errores 499 en el panel de estado del servicio (pueden aparecer como errores 5xx en tus propios sistemas).
La latencia aumentó sin una implementación
Causa posible: aumentó el tamaño de los tokens de salida o el uso de razonamiento, o el tráfico cambió entre niveles de servicio.
Verifica:
Tokens de salida promedio por solicitud en el panel de uso (requiere descargar datos y dividir los tokens de salida entre el total de solicitudes).
Percentiles de tiempo de solicitud y TTFT en el panel de estado del servicio.
El nivel Priority o Nivel de capacidad parece lento
Causa posible: las métricas están mezcladas entre niveles, lo que significa que el tráfico del nivel estándar oculta el rendimiento del nivel de pago.
Verifica:
Los filtros están restringidos a un solo nivel y modelo.
Comparación de velocidad de tokens entre niveles.
Aumento repentino de errores 5XX
Causa probable: fallas transitorias que afectan un pequeño porcentaje del tráfico.
Verifica:
Porcentaje de tasa de errores
Si el volumen de tráfico cambió al mismo tiempo
El problema afecta solo a un proyecto
Causa probable: configuración o patrón de uso específico del proyecto.
Verifica:
Filtrado a nivel de proyecto
Comparación con proyectos no afectados
Conclusiones finales
Filtra por modelo, nivel y proyecto cuando corresponda antes de interpretar las métricas.
Usa percentiles, no promedios, para el análisis de latencia.
Se esperan tasas de error pequeñas.
Los datos faltantes suelen indicar problemas ascendentes.
Los datos de uso pueden ayudar a explicar por qué cambió la latencia; el estado del servicio muestra cuándo cambió el comportamiento.