Enlaces importantes
Panel de estado del servicio (actualmente solo disponible para clientes de Enterprise API)
Empezar con los valores predeterminados adecuados
Al abrir el panel de estado del servicio, usa de forma predeterminada:
Todos los proyectos
Últimos 30 días
Resolución horaria
Esta vista solo es útil para orientarse. Para una solución de problemas significativa, siempre hay que filtrar.
Filtrar antes de investigar
El filtrado correcto es el paso más importante. La mayoría de las interpretaciones erróneas se deben a mezclar modelos, niveles o proyectos.
Filtrar por modelo (uno cada vez)
Filtra siempre a un único modelo.
Por qué:
Los problemas en modelos con poco tráfico pueden quedar ocultos por tráfico de mayor volumen
Los modelos de gran volumen pueden hacer que problemas localizados parezcan globales
Los distintos modelos tienen objetivos de rendimiento diferentes
Nota: seleccionar varios modelos los agrega; no cambia de uno a otro.
Filtrar por nivel de servicio
Si usas más de un nivel (estándar, prioridad, capacidad), filtra siempre al nivel que estás investigando.
Por qué:
Los niveles tienen distintas características de rendimiento
Los niveles de prioridad y capacidad 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, estado del servicio muestra todos los proyectos.
Para solucionar problemas, filtra por los proyectos donde se observó el problema.
Por qué:
Un solo proyecto de gran volumen puede dominar las métricas.
Los proyectos afectados más pequeños pueden quedar enmascarados por tráfico no relacionado.
Deja seleccionado «Todos los proyectos» solo si crees que el problema afecta realmente a toda la organización.
Solucionar 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 el recuento de errores por código de estado HTTP. Amplía hasta una resolución de minutos para identificar picos o cambios granulares.
Interpretar las tasas de error, no los recuentos
En cualquier sistema de producción se esperan algunos errores. Céntrate en el porcentaje de errores, no en los totales brutos.
Cuanto mayor sea el volumen total, mayor será el número potencial de errores incluso con una tasa de error extremadamente baja.
Cuando faltan errores en estado del servicio
Si ves errores del lado del cliente pero no datos correspondientes en estado del servicio:
Es probable que las solicitudes no llegaran a OpenAI.
El problema suele estar en componentes ascendentes (tiempos de espera, proxies, redes).
Esto es común con tiempos de espera del lado del cliente agresivos.
Solucionar problemas de latencia
El análisis de latencia es más significativo en los niveles prioridad y capacidad, que tienen SLA definidos. El nivel estándar puede mostrar una variación de latencia mayor 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; 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; muy afectado por el tamaño del prompt de entrada no almacenado en caché y el razonamiento.
Revisa siempre los percentiles P50 / P75 / P95. Las medias pueden ocultar el impacto real en los usuarios.
6. Correlacionar la latencia con el uso de tokens
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 que estás viendo los datos relevantes para tu vista en el panel de estado del servicio:
Filtra por el mismo proyecto y modelo.
Agrupa por nivel de servicio, si procede.
Céntrate en los tokens de salida, que son los que más afectan a 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 contactas con soporte, incluye:
ID de organización afectados (importante)
Puntos de acceso afectados, como Chat Completions o Responses (importante)
Modelos afectados (importante)
Si esto ocurre en el nivel de capacidad o de prioridad (importante)
Intervalos 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 de proyecto relacionado con las solicitudes
Si las solicitudes de residencia de datos están afectadas, y cuáles
Descripciones de las tendencias que estás viendo
Para el tipo de problema, incluye:
Errores: porcentaje aproximado de solicitudes fallidas o con error, 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), cuánto han aumentado respecto a la referencia 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 eran superiores a lo esperado.
Escenarios comunes de solución de problemas
Se producen tiempos de espera, pero estado del servicio parece normal
Posible causa: las solicitudes agotan el tiempo de espera antes de llegar a OpenAI.
Comprueba:
Configuración de tiempo de espera del cliente o del proxy
Cambios en la red local o en el equilibrador 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 un despliegue
Posible causa: aumentó el tamaño de los tokens de salida o el uso de razonamiento, o el tráfico cambió entre niveles de servicio.
Comprueba:
Tokens de salida medios 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 de prioridad o el Nivel de capacidad parecen lentos
Posible causa: 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.
Comprueba:
Los filtros están restringidos a un único nivel y modelo.
Comparación de velocidad de tokens entre niveles.
Aumento de errores 5XX
Causa probable: fallos transitorios que afectan a un pequeño porcentaje del tráfico.
Comprueba:
Porcentaje de tasa de errores
Si el volumen de tráfico cambió al mismo tiempo
El problema afecta a un solo proyecto
Causa probable: configuración o patrón de uso específico del proyecto.
Comprueba:
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 medias, para el análisis de latencia.
Es esperable que haya tasas de error pequeñas.
La falta de datos suele indicar problemas ascendentes.
Los datos de uso pueden ayudar a explicar por qué cambió la latencia; estado del servicio muestra cuándo cambió el comportamiento.