Compartir a través de

Límites y cuotas de las API de Foundation Model

En esta página se describen los límites y cuotas de las cargas de trabajo de las API de Databricks Foundation Model.

Las API del modelo de Databricks Foundation aplican límites de velocidad para garantizar un rendimiento confiable y una asignación de recursos justa en todos los usuarios. Estos límites varían en función del nivel de plataforma del área de trabajo, el tipo de modelo de base y cómo se implementa el modelo de base.

Límites de velocidad de punto de conexión de pago por token

Los puntos de conexión de pago por token se rigen por límites de velocidad basados en tokens y basados en consultas. Los límites de velocidad basados en tokens controlan el número máximo de tokens que se pueden procesar por minuto y se aplican por separado para los tokens de entrada y salida.

  • Tokens de entrada por minuto (ITPM): el número máximo de tokens de entrada (desde las indicaciones) que se pueden procesar en una ventana de 60 segundos. Un límite de velocidad de ITPM controla el rendimiento del token de entrada de un punto de conexión.
  • Tokens de salida por minuto (OTPM): el número máximo de tokens de salida (de las respuestas del modelo) que se pueden generar en una ventana de 60 segundos. Un límite de velocidad de OTPM controla el rendimiento del token de salida de un punto de conexión.
  • Consultas por hora: el número máximo de consultas o solicitudes que se pueden procesar en un período de 60 minutos. En el caso de las aplicaciones de producción con patrones de uso sostenidos, Databricks recomienda puntos de conexión de rendimiento aprovisionados, que proporcionan capacidad garantizada.

Cómo se realiza el seguimiento y aplicación de los límites

El límite de velocidad más restrictivo (ITPM, OTPM, QPH) se aplica en cualquier momento dado. Por ejemplo, aunque no haya alcanzado el límite de ITPM, migh seguirá estando limitado por la velocidad si supera el límite de QPH o OTPM. Cuando se alcanza el límite de ITPM o OTPM, las solicitudes posteriores reciben un error 429 que indica que se han recibido demasiadas solicitudes. Este mensaje persiste hasta que se restablece la ventana de límite de velocidad.

Databricks realiza un seguimiento y aplica los límites de velocidad de tokens por minuto (TPM) mediante las siguientes características:

Característica Detalles
Contabilidad de tokens y comprobaciones previas a la admisión
  • Recuento de tokens de entrada: los tokens de entrada se cuentan desde el mensaje real en el momento de la solicitud.
  • Estimación del token de salida: si proporciona max_tokens en la solicitud, Databricks usa este valor para calcular y reservar la capacidad del token de salida antes de que se admita la solicitud para su procesamiento.
  • Validación previa a la admisión: Databricks comprueba si la solicitud superaría los límites de ITPM o OTPM antes de que comience el procesamiento. Si max_tokens fuera necesario superar los límites de OTPM, Databricks rechaza la solicitud inmediatamente con un error 429.
  • Salida real frente a estimada: después de generar la respuesta, se cuentan los tokens de salida reales. Importantemente, si el uso real del token es menor que el reservado max_tokens, Databricks acredita la diferencia a la asignación de límite de velocidad, lo que hace que esos tokens estén disponibles inmediatamente para otras solicitudes.
  • No max_tokens especificado: si no especifica max_tokens, Databricks usa una reserva predeterminada y el recuento de tokens real se reconcilia después de la generación. Nota: Claude Sonnet 4 establece específicamente 1000 tokens de salida cuando max_tokens no se establece, devolviendo el motivo de finalización "longitud" cuando se alcanza. Esta no es la longitud máxima del contexto del modelo. Claude 3.7 Sonnet no tiene este valor predeterminado.
Capacidad de ráfaga y suavizado
  • Búfer de ráfagas: el limitador de velocidad incluye un búfer pequeño para dar cabida a ráfagas cortas de tráfico por encima de la velocidad nominal.
  • Ventana deslizante: se realiza un seguimiento del consumo de tokens mediante un algoritmo de ventana deslizante que proporciona una limitación de velocidad más suave que límites de velocidad duros por minuto.
  • Algoritmo de cubo de tokens: Databricks usa una implementación del cubo de tokens que permite cierta capacidad de ráfaga mientras se mantiene el límite medio de velocidad a lo largo del tiempo.

A continuación se muestra un ejemplo de cómo funcionan las comprobaciones previas a la admisión y el comportamiento de devolución de crédito.

# Request with max_tokens specified
request = {
    "prompt": "Write a story about...",  # 10 input tokens
    "max_tokens": 500  # System reserves 500 output tokens
}

# Pre-admission check:
# - Verifies 10 tokens against ITPM limit
# - Reserves 500 tokens against OTPM limit
# - If either would exceed limits, returns 429 immediately

# If admitted, actual response uses only 350 tokens
# The systen credits back 150 tokens (500 - 350) to your OTPM allowance
# These 150 tokens are immediately available for other requests

Límites de velocidad por modelo

En las tablas siguientes se resumen los límites de velocidad de ITPM, OTPM y QPH para los puntos de conexión de la API de modelo de Foundation de pago por token para las áreas de trabajo de nivel Enterprise:

Nota:

A partir del 15 de febrero de 2026, se retirará Meta-Llama-3.1-405B-Instruct. Consulte Modelos retirados para ver el modelo de reemplazo recomendado e instrucciones sobre cómo migrar durante el desuso.

Modelos de lenguaje grandes Límite de ITPM Límite de OTPM Límite de QPH Notas
Qwen3-Next 80B A3B Instrucción (Beta) 200 000 10 000 LLM de uso general
GPT OSS 120B 200 000 10 000 LLM de uso general
GPT OSS 20B 200 000 10 000 Variante DE GPT más pequeña
Gemma 3 12B 200 000 10 000 7,200 Modelo gema de Google
Llama 4 Maverick 200 000 10 000 2,400 Última versión de Llama
Llama 3.3 70B Indicación 200 000 10 000 2,400 Modelo llama de tamaño medio
Llama 3.1 8B Indicación 200 000 10 000 7,200 Modelo de llama ligero
Llama 3.1 405B Indicación 5.000 500 1,200
  • Modelo de llama más grande: límites reducidos debido al tamaño
Modelos antrópicos de Claude Límite de ITPM Límite de OTPM Notas
Claude 3.7 Sonnet 50,000 5.000 Modelo de Claude equilibrado
Claude Sonnet 4 50,000 5.000
Claude Opus 4.1 50,000 5.000
Claude Opus 4.5 200 000 20,000 Última versión de Opus
Claude Sonnet 4.5 50,000 5.000 Versión más reciente de Sonnet
Claude Haiku 4.5 50,000 5.000 Última versión de Haiku
Inserción de modelos Límite de ITPM Límite de OTPM Límite de QPH Notas
GTE Large (En) N/A N/A 540,000 Modelo de inserción de texto: no genera incrustaciones normalizadas
BGE large (En) N/A N/A 2,160,000 Modelo de inserción de texto

Administración de los procedimientos recomendados de límites de velocidad de TPM

Paso 1. Supervisión del uso de tokens

Realice un seguimiento de los recuentos de tokens de entrada y salida por separado en las aplicaciones:

# Example: Track token usage
response = model.generate(prompt)
input_tokens = response.usage.prompt_tokens
output_tokens = response.usage.completion_tokens
total_tokens = response.usage.total_tokens

# Check against limits
if input_tokens > ITPM_LIMIT or output_tokens > OTPM_LIMIT:
    # Implement backoff strategy
    pass

Paso 2. Implementación de la lógica de reintento

Agregue un retroceso exponencial cuando encuentre errores de límite de velocidad:

import time
import random

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

    num_retries = 0
    delay = initial_delay

    while num_retries < max_retries:
        try:
            return func()
        except Exception as e:
            if "rate_limit" in str(e) or "429" in str(e):
                num_retries += 1

                if jitter:
                    delay *= exponential_base * (1 + random.random())
                else:
                    delay *= exponential_base

                time.sleep(delay)
            else:
                raise e

    raise Exception(f"Maximum retries {max_retries} exceeded")

Paso 3. Optimización del uso de tokens

  • Minimizar la longitud de la solicitud: usar avisos concisos y bien estructurados
  • Longitud de salida del control: use max_tokens el parámetro para limitar el tamaño de la respuesta.
  • Establecer max_tokens explícitamente para Claude Sonnet 4: especifique max_tokens siempre al usar Claude Sonnet 4 para evitar el límite predeterminado de 1000 tokens
  • Batch de forma eficaz: agrupa las solicitudes relacionadas siempre que sea posible mientras se mantiene dentro de los límites

Paso 4. Considerar la selección de modelos

  • Modelos más pequeños para tareas de gran volumen: use modelos como Llama 3.1 8B para tareas que requieran un mayor rendimiento.
  • Modelos grandes para tareas complejas: Reserve Llama 3.1 405B para tareas que requieren la capacidad máxima

Supervisión y solución de problemas

Supervise los patrones de uso de tokens para optimizar el rendimiento:

# Example: Log token usage for monitoring
import logging

logger = logging.getLogger(__name__)

def log_token_usage(response):
    usage = response.usage
    logger.info(f"Input tokens: {usage.prompt_tokens}")
    logger.info(f"Output tokens: {usage.completion_tokens}")
    logger.info(f"Total tokens: {usage.total_tokens}")

    # Alert if approaching limits
    if usage.prompt_tokens > ITPM_LIMIT * 0.8:
        logger.warning("Approaching ITPM limit")
    if usage.completion_tokens > OTPM_LIMIT * 0.8:
        logger.warning("Approaching OTPM limit")

Control de errores de límite de velocidad

Cuando se superan los límites de velocidad, la API devuelve un 429 Too Many Requests error:

{
  "error": {
    "message": "Rate limit exceeded: ITPM limit of 200,000 tokens reached",
    "type": "rate_limit_exceeded",
    "code": 429,
    "limit_type": "input_tokens_per_minute",
    "limit": 200000,
    "current": 200150,
    "retry_after": 15
  }
}

La respuesta de error incluye:

  • limit_type: qué límite específico se superó (ITPM, OTPM, QPS o QPH)
  • limit: valor de límite configurado.
  • current: uso actual
  • retry_after: tiempo de espera sugerido en segundos

Problemas comunes y soluciones

Cuestión Solución
Errores frecuentes 429 Implementación de retroceso exponencial, reducción de la tasa de solicitudes y límites de velocidad de solicitud más altos
Se alcanzó el límite de ITPM Optimizar la longitud del símbolo del sistema
Se alcanzó el límite de OTPM Uso max_tokens para limitar la longitud de respuesta
Se alcanzó el límite de QPH Distribuir solicitudes de forma más uniforme con el tiempo

Límites de rendimiento aprovisionados

En el caso de las cargas de trabajo de producción que requieren límites más altos, los puntos de conexión de rendimiento aprovisionados ofrecen:

  • Sin restricciones de TPM: capacidad de procesamiento basada en recursos aprovisionados
  • Límites de velocidad más altos: hasta 200 consultas por segundo por área de trabajo
  • Rendimiento predecible: los recursos dedicados garantizan una latencia coherente.

Límites del token de salida

Nota:

A partir del 15 de mayo de 2026, se retirará el Meta-Llama-3.1-405B-Instruct. Consulte Modelos retirados para ver el modelo de reemplazo recomendado e instrucciones sobre cómo migrar durante el desuso.

En la tabla siguiente se resumen los límites del token de salida para cada modelo admitido:

Modelo Límite de tokens de salida
GPT OSS 120B 25 000
GPT OSS 20B 25 000
Gemma 3 12B 8,192
Llama 4 Maverick 8,192
Llama 3.1 405B 4 096
Llama 3.1 70B 8,192
Llama 3.1 8B 8,192

Límites adicionales

Las siguientes son limitaciones para las cargas de trabajo de rendimiento aprovisionado:

  • Para implementar un modelo de Meta Llama desde system.ai en el catálogo de Unity, debe elegir la versión de indicación aplicable. Las versiones base de los modelos Meta Llama no se admiten para la implementación desde el catálogo de Unity. Consulte Implementación de puntos de conexión de rendimiento aprovisionados.
  • Para cargas de trabajo de rendimiento aprovisionadas que usan Llama 4 Maverick:
    • La compatibilidad con este modelo en cargas de trabajo de rendimiento aprovisionadas está en versión preliminar pública.
    • No se admite el escalado automático.
    • No se admiten paneles de métricas.
    • La división de tráfico no se admite en un punto de conexión que sirva a Llama 4 Maverick. No puede atender varios modelos en un punto de conexión que sirva a Llama 4 Maverick.

Disponibilidad regional y procesamiento de datos

Para obtener disponibilidad de la región del modelo de base hospedado en Databricks, consulte Introducción a Foundation Model.

Para obtener información sobre el procesamiento de datos y la residencia, consulte Procesamiento y residencia de datos.

Recursos adicionales

  • Last updated on