Límites de solicitudes

Los límites de solicitudes son restricciones que nuestra API impone a la cantidad de veces que un usuario o cliente puede acceder a nuestros servicios en un período determinado.

¿Por qué tenemos límites de solicitudes?

Los límites de solicitudes son una práctica común en las API y se establecen por varios motivos:

• Ayudan a proteger la API contra el abuso o el uso indebido. Por ejemplo, un actor malicioso podría inundar la API con solicitudes para intentar sobrecargarla o provocar interrupciones en el servicio. Al establecer límites de solicitudes, OpenAI puede prevenir este tipo de actividad.
• Los límites de solicitudes ayudan a garantizar que todos tengan acceso equitativo a la API. Si una persona u organización realiza una cantidad excesiva de solicitudes, podría ralentizar la API para los demás. Al restringir la cantidad de solicitudes que puede realizar un solo usuario, OpenAI garantiza que la mayor cantidad posible de personas pueda usar la API sin experimentar demoras.
• Los límites de solicitudes pueden ayudar a OpenAI a gestionar la carga total de su infraestructura. Un aumento drástico de las solicitudes a la API podría sobrecargar los servidores y causar problemas de rendimiento. Al establecer límites de solicitudes, OpenAI puede ayudar a mantener una experiencia fluida y uniforme para todos los usuarios.

¿Cómo funcionan estos límites de solicitudes?

Los límites de solicitudes usan métricas como RPM (solicitudes por minuto), RPD (solicitudes por día), TPM (tokens por minuto), TPD (tokens por día), IPM (imágenes por minuto) y minutos de audio por minuto para algunos modelos de audio en streaming. Puedes alcanzar cualquiera de estos límites, según cuál se agote primero. Por ejemplo, podrías enviar 20 solicitudes con solo 100 tokens al punto de acceso ChatCompletions y agotar tu límite (si tu límite de RPM fuera 20), aunque no hubieras enviado 150 000 tokens (si tu límite de TPM fuera 150 000) en esas 20 solicitudes.

Los límites de la cola de la Batch API se calculan a partir de la cantidad total de tokens de entrada en cola para un modelo determinado. Los tokens de los trabajos por lotes pendientes se contabilizan para el límite de la cola. Una vez que se completa un trabajo por lotes, sus tokens dejan de contabilizarse para el límite de ese modelo.

Otros aspectos importantes que debes tener en cuenta:

• Los límites de solicitudes se definen a nivel de organización y de proyecto, no de usuario.
• Los límites de solicitudes varían según el modelo que se use.
• Para los modelos de contexto largo, como GPT-5.5, hay un límite de solicitudes independiente para las solicitudes de contexto largo. Puedes consultar estos límites en la consola para desarrolladores.
• OpenAI establece un límite de uso mensual aprobado para cada organización. Este es independiente de los límites de gasto que puedes configurar para una organización o un proyecto.
• Algunas familias de modelos tienen límites de solicitudes compartidos. Los modelos que aparecen bajo un “límite compartido” en la página de límites de tu organización comparten un mismo límite de solicitudes. Por ejemplo, si el límite de TPM compartido indicado es de 3,5 millones, todas las llamadas a cualquier modelo de esa lista de “límite compartido” se contabilizarán para esos 3,5 millones.
• La ingesta en almacenes vectoriales también está sujeta a límites de solicitudes por ID de almacén vectorial. /vector_stores/{vector_store_id}/files y /vector_stores/{vector_store_id}/file_batches comparten un límite de 300 solicitudes por minuto para cada almacén vectorial. Para ingestas de mayor volumen, usa preferentemente /vector_stores/{vector_store_id}/file_batches.

Niveles de uso

Puedes consultar los límites de solicitudes y de uso de tu organización en la sección límites de la configuración de tu cuenta. A medida que aumenta tu gasto en nuestra API, te pasamos automáticamente al siguiente nivel de uso. Esto suele aumentar los límites de solicitudes de la mayoría de los modelos.

Para consultar un resumen general de los límites de solicitudes por modelo, visita la página de modelos.

Límites de solicitudes en los encabezados

Además de consultar tu límite de solicitudes en la página de tu cuenta, puedes ver información importante sobre tus límites, como las solicitudes y los tokens restantes, junto con otros metadatos, en los encabezados de la respuesta HTTP.

Las respuestas pueden incluir los siguientes campos de encabezado:

Los encabezados de tokens del proyecto pueden estar presentes cuando se aplica un límite de tokens específico del proyecto. Retry-After puede estar presente en las respuestas 429 causadas por un límite temporal de solicitudes y en las respuestas 503 causadas por una sobrecarga temporal del modelo. Esto no significa que los errores de cuota, facturación u otros que requieren una acción del usuario se puedan resolver con reintentos.

Límites de solicitudes de ajuste fino

También puedes consultar en el panel los límites de solicitudes de ajuste fino de tu organización, así como obtenerlos mediante la API:

curl https://api.openai.com/v1/fine_tuning/model_limits \
  -H "Authorization: Bearer $OPENAI_API_KEY"

Mitigación de errores

Gestionar los aumentos rápidos del tráfico y la sobrecarga del modelo

La API puede devolver slow_down cuando tu tasa de solicitudes aumenta demasiado rápido, o server_is_overloaded cuando el modelo solicitado está sobrecargado temporalmente. Revisa el estado HTTP y error.code para distinguir estas situaciones:

Si Retry-After no está presente, aumenta el tiempo de espera entre reintentos y agrega una pequeña demora aleatoria.

Puede producirse un error slow_down incluso cuando tu tráfico está dentro de sus límites de solicitudes por minuto y tokens por minuto. Este error refleja la rapidez con la que aumentó el tráfico, no si agotaste esos límites.

Como regla general, una vez que tu tráfico alcance 1 millón de tokens de entrada por minuto (TPM), auméntalo como máximo un 50 % cada 15 minutos. El punto exacto en el que se aplica el límite de velocidad de aumento puede variar según el modelo y las condiciones del tráfico.

Los clientes empresariales cuyo tráfico de pago por uso alcanza habitualmente los límites de velocidad de aumento pueden considerar el Nivel de capacidad para obtener una capacidad más predecible en los modelos elegibles. Para GPT-5.6 y modelos posteriores, consulta Reserved Tier. Los niveles de capacidad no cambian la forma en que debes gestionar una respuesta slow_down: respeta Retry-After cuando esté presente, reduce el tráfico y auméntalo gradualmente.

Actualizar los manejadores de errores existentes

Si tu aplicación manejaba las respuestas anteriores de limitación de tráfico y sobrecarga, revisa tanto el estado HTTP como error.code:

• En los puntos de acceso que antes devolvían 503 con el código slow_down para ambas situaciones, los aumentos rápidos del tráfico ahora devuelven 429 con slow_down. La sobrecarga del modelo sigue devolviendo 503, pero usa server_is_overloaded.
• Las solicitudes de video rechazadas antes de crear un trabajo antes devolvían 429 con el tipo invalid_request_error y el código rate_limit_exceeded en estas situaciones. Los aumentos rápidos del tráfico ahora devuelven 429 con rate_limit_error y slow_down; la sobrecarga del modelo devuelve 503 con service_unavailable_error y server_is_overloaded. Los errores que se notifican en el estado de un trabajo de video son un caso aparte.

Maneja tanto 429 como 503 en tus manejadores de errores del SDK. Por ejemplo, Python, TypeScript y Ruby usan RateLimitError para 429 y InternalServerError para 503; Java usa RateLimitException y InternalServerException. Mantén la compatibilidad con los códigos de respuesta anteriores mientras tu aplicación aún pueda recibirlos. Otros errores pueden usar los mismos estados HTTP, así que examina el cuerpo del error antes de elegir una acción de recuperación.

Para las solicitudes de streaming, estas respuestas de error HTTP se aplican antes de que comience el flujo. Un error que ocurra después de que comience el streaming puede llegar como un evento del flujo; no vuelvas a enviar automáticamente una solicitud después de haber consumido datos de salida.

¿Qué medidas puedo tomar para mitigar esto?

El Cookbook de OpenAI incluye un notebook de Python que explica cómo evitar los errores de límite de solicitudes, así como un script de Python de ejemplo para mantenerse dentro de los límites al procesar solicitudes a la API por lotes.

También debes tener cuidado al ofrecer acceso programático, funciones de procesamiento masivo y publicación automatizada en redes sociales. Considera habilitar estas funciones solo para clientes de confianza.

Para protegerte contra el uso indebido automatizado y de gran volumen, establece un límite de uso por usuario para un período determinado (diario, semanal o mensual). Considera implementar un límite estricto o un proceso de revisión manual para los usuarios que lo superen.

Reintentos con espera exponencial

Cuando una solicitud supera un límite temporal de solicitudes, la API devuelve un error 429. La respuesta puede incluir un encabezado Retry-After que indica cuántos segundos debes esperar antes de volver a intentarlo. Trata este valor como un mínimo: espera al menos ese tiempo y agrega una pequeña demora aleatoria para que varios clientes no vuelvan a intentarlo al mismo tiempo.

Cada SDK oficial de OpenAI reintenta automáticamente las solicitudes con respuestas 429 y 503 que admiten reintentos, según su configuración de reintentos. El manejo de Retry-After, especialmente de los tiempos de espera largos, varía según la versión y la configuración del SDK. Revisa cómo gestiona los reintentos la versión que tienes instalada en lugar de suponer que admite cualquier tiempo de espera indicado por el servidor.

Si un tiempo de espera válido indicado por el servidor supera el tiempo máximo de espera entre reintentos admitido o configurado, detén los reintentos y pospón la solicitud en lugar de reintentar antes de lo indicado. Un SDK puede devolver el error HTTP original cuando rechaza un tiempo de espera que supera su límite. Sigue manejando por separado los errores de cancelación y de tiempo de espera agotado: una solicitud cancelada o un plazo vencido pueden detener los reintentos sin devolver ese error HTTP. Un tiempo de espera máximo para cada intento no implica necesariamente un plazo para toda la operación.

Si usas tu propio cliente HTTP, respeta Retry-After cuando el encabezado esté presente y contenga un valor válido. Si falta o no es válido, usa una espera exponencial con variación aleatoria como alternativa. Limita tanto la cantidad de intentos como el tiempo total dedicado a reintentar. Si gestionas los reintentos en tu aplicación, desactiva los reintentos del SDK o inclúyelos en esos límites para que los bucles de reintentos anidados no multipliquen las solicitudes. No reintentes las solicitudes con errores de cuota, facturación u otros que requieran que tomes alguna medida.

La espera exponencial consiste en esperar brevemente después de una solicitud fallida y luego aumentar el tiempo de espera tras cada reintento fallido. Esto continúa hasta que la solicitud se completa correctamente o se alcanza el límite de reintentos configurado.

Este enfoque tiene muchos beneficios:

• Los reintentos automáticos permiten recuperarse de los errores de límite de solicitudes sin que la aplicación falle ni falten datos
• La espera exponencial permite realizar los primeros reintentos rápidamente y aprovechar tiempos de espera más largos si esos primeros reintentos fallan
• Agregar una variación aleatoria al tiempo de espera ayuda a evitar que todos los reintentos ocurran al mismo tiempo.

Ten en cuenta que las solicitudes fallidas cuentan para tu límite por minuto, por lo que reenviar una solicitud continuamente no funcionará.

Los siguientes ejemplos de Python muestran cómo usar la espera progresiva como alternativa. No examinan Retry-After: antes de usarlos, agrega el manejo de las indicaciones válidas del servidor para que las funciones contenedoras no reintenten antes de lo indicado. Desactiva los reintentos del SDK o inclúyelos en los límites de reintentos de tu aplicación.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19from openai import OpenAI
from tenacity import (
    retry,
    stop_after_attempt,
    wait_random_exponential,
)  # for exponential backoff

client = OpenAI()


@retry(wait=wait_random_exponential(min=1, max=60), stop=stop_after_attempt(6))
def completion_with_backoff(**kwargs):
    return client.completions.create(**kwargs)


completion_with_backoff(
    model="gpt-3.5-turbo-instruct",
    prompt="Once upon a time,",
)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16import backoff
import openai
from openai import OpenAI

client = OpenAI()


@backoff.on_exception(backoff.expo, openai.RateLimitError)
def completions_with_backoff(**kwargs):
    return client.completions.create(**kwargs)


completions_with_backoff(
    model="gpt-3.5-turbo-instruct",
    prompt="Once upon a time,",
)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59# imports
import random
import time

import openai
from openai import OpenAI

client = OpenAI()

# define a retry decorator


def retry_with_exponential_backoff(
    func,
    initial_delay: float = 1,
    exponential_base: float = 2,
    jitter: bool = True,
    max_retries: int = 10,
    errors: tuple = (openai.RateLimitError,),
):
    """Retry a function with exponential backoff."""

    def wrapper(*args, **kwargs):
        # Initialize variables
        num_retries = 0
        delay = initial_delay

        # Loop until a successful response or max_retries is hit or an exception is raised
        while True:
            try:
                return func(*args, **kwargs)

            # Retry on specific errors
            except errors:
                # Increment retries
                num_retries += 1

                # Check if max retries has been reached
                if num_retries > max_retries:
                    raise Exception(
                        f"Maximum number of retries ({max_retries}) exceeded."
                    )

                # Increment the delay
                delay *= exponential_base * (1 + jitter * random.random())

                # Sleep for the delay
                time.sleep(delay)

            # Raise exceptions for any errors not specified
            except Exception:
                raise

    return wrapper


@retry_with_exponential_backoff
def completions_with_backoff(**kwargs):
    return client.completions.create(**kwargs)

Reduce max_tokens para que coincida con el tamaño de tus respuestas

Tu límite de solicitudes se calcula tomando el mayor de estos dos valores: max_tokens y la cantidad estimada de tokens según el número de caracteres de tu solicitud. Intenta que el valor de max_tokens se acerque lo más posible al tamaño de respuesta que esperas.

Agrupar solicitudes en lotes

Si tu caso de uso no requiere respuestas inmediatas, puedes usar la API de procesamiento por lotes para enviar y ejecutar grandes conjuntos de solicitudes con mayor facilidad, sin afectar tus límites de solicitudes síncronas.

Para los casos de uso que sí requieren respuestas síncronas, la API de OpenAI tiene límites separados para las solicitudes por minuto y los tokens por minuto.

Si alcanzas el límite de solicitudes por minuto, pero aún tienes capacidad disponible de tokens por minuto, puedes aumentar el rendimiento agrupando varias tareas en cada solicitud. Esto te permitirá procesar más tokens por minuto, especialmente con nuestros modelos más pequeños.

Enviar un lote de prompts funciona exactamente igual que una llamada normal a la API, salvo que pasas una lista de cadenas al parámetro prompt en lugar de una sola cadena. Obtén más información en la guía de la API de procesamiento por lotes.