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, Modo rápido —antes denominado Procesamiento prioritario— o Nivel de capacidad), filtra siempre por el nivel que estés investigando.
Motivos:
Los niveles tienen distintas características de rendimiento
El Modo rápido y el Nivel de capacidad tienen SLA definidos
Mezclar niveles oculta el rendimiento de los niveles de pago
Esto es especialmente importante al analizar la latencia.
En los modelos existentes, el tráfico del Modo rápido sigue apareciendo como prioritario en el panel de uso.
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 resulta más significativo en los niveles Modo rápido y Nivel de capacidad, que tienen SLA definidos. El nivel estándar puede presentar una mayor variación de latencia y no ofrece una 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 el equipo de asistencia (si es necesario)
Si contactas con el equipo de asistencia, incluye lo siguiente:
ID de las organizaciones afectadas (importante)
Endpoints afectados, como Chat Completions o Responses (importante)
Modelos afectados (importante)
Si sucede en el Modo rápido o en el Nivel de capacidad (importante)
Intervalos de tiempo con zona horaria para la latencia o los errores (importante)
Valores de x-request-id o X-Client-Request-Id relevantes, si están disponibles
Marcas de tiempo con zona horaria, o al menos la fecha, de las solicitudes que proporciones
Si están disponibles, 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
Según el tipo de problema, incluye:
Errores: porcentaje aproximado de solicitudes que fallan o devuelven errores, códigos de respuesta, mensajes de error y tiempo transcurrido hasta recibir la respuesta de error.
Latencia: percentiles afectados (P50/P90/P95/P99), cuánto superan el valor de 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 con 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 Modo rápido o el Nivel de capacidad parecen lentos
Posible causa: se mezclan métricas de distintos niveles, por lo que el tráfico del nivel estándar oculta el rendimiento de los niveles de pago.
Comprueba lo siguiente:
Los filtros están restringidos a un único nivel y modelo.
Comparación de la 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.