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 tasa para el extremo de pago por token

Los puntos de conexión de pago por token se rigen por límites de tasa basados en tokens y 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 (de sus solicitudes) que se pueden procesar en un periodo de 60 segundos. Un límite de velocidad de ITPM controla el flujo de tokens de entrada de un endpoint.
• 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 los puntos de conexión con rendimiento garantizado, 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, incluso si no ha alcanzado el límite de ITPM, es posible que todavía esté limitado por 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:

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 system 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

Las siguientes tablas resumen los límites de ITPM, OTPM y QPH para los puntos de conexión de la API del modelo Foundation de pago por token para los área de trabajo del nivel de la plataforma del espacio de trabajo Enterprise:

Niveles de cuota de tokens del modelo de socio

La escala de cuotas de tokens del modelo de socio tiene tres niveles numerados. Los modelos asociados se asignan por defecto al nivel 1, a menos que una restricción de capacidad específica del proveedor requiera un límite inferior. Estos niveles de cuota son independientes de tu nivel de la plataforma del espacio de trabajo.

Los límites de tokens personalizados requieren una revisión de la capacidad por parte de Databricks y quedan fuera de estos tres niveles. Los niveles de cuota de tokens solo modifican los límites de ITPM y OTPM; los límites de RPS, QPS, RPH y QPH siguen siendo específicos de cada modelo. Un modelo de partner mantiene un valor por defecto inferior solo para una restricción de capacidad de proveedor específica del modelo. Los modelos abiertos conservan los valores predeterminados mostrados en las siguientes tablas.

Prácticas recomendadas para administrar los límites de tasa 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. Implementar lógica de reintentos

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
• Controlar la longitud de salida: utilice el parámetro max_tokens para limitar el tamaño de la respuesta.
• Creación de lotes 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 alto volumen: Utiliza modelos como GPT OSS 20B para tareas que requieren mayor rendimiento.
• Modelos grandes para tareas complejas: Reserva GPT OSS 120B para tareas que requieren la máxima capacidad.

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")

Manejo de errores de límite de tasa

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 1,000,000 tokens reached",
    "type": "rate_limit_exceeded",
    "code": 429,
    "limit_type": "input_tokens_per_minute",
    "limit": 1000000,
    "current": 1000150,
    "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

Gestionar errores de capacidad de servicio

Un error 429 Too Many Requests significa que tu carga de trabajo superó un límite de velocidad bajo tu control. Un error 503 Service Unavailable es diferente: significa que las APIs de Foundation Model están temporalmente al límite y no pudieron atender tu solicitud. Un 503 no cuenta ni indica que hayas alcanzado tus propios límites de tarifa.

Trata las respuestas 503 como transitorias y vuelve a intentarlo con retroceso exponencial, siguiendo el mismo patrón que en el Paso 2. Implementa lógica de reintentos. Para cargas de trabajo de producción que requieren capacidad constante, se utiliza el throughput aprovisionado, que proporciona capacidad dedicada en lugar de capacidad compartida de pago por token. Consulta la documentación sobre el rendimiento provisionado reservado y el rendimiento provisionado bajo demanda para modelos fundacionales.

Problemas comunes y soluciones

Límites de rendimiento aprovisionados

En el caso de cargas de trabajo de producción que requieren límites más elevados, los puntos de conexión con rendimiento aprovisionado 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

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

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 Unity Catalog, debe elegir la versión Instruct aplicable. Las versiones base de los modelos Meta Llama no se admiten para la implementación desde el catálogo de Unity. Consulte Implementar puntos de conexión de rendimiento aprovisionado.
• Para cargas de trabajo de rendimiento aprovisionado que usan Llama 4 Maverick:
  • La compatibilidad con este modelo en cargas de trabajo con rendimiento aprovisionado está en versión preliminar pública.
  • No se admite el escalado automático.
  • No se admiten paneles de métricas.
  • La separación de tráfico no se admite en un punto de conexión que sirva a Llama 4 Maverick. No puede hospedar varios modelos en un punto de conexión que hospede 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.

Límites de recursos y carga para modelos de Foundation y modelos externos

En las tablas siguientes se resumen los límites de recursos y carga para los puntos de conexión que sirven a modelos básicos y modelos externos.

Recursos adicionales

• Introducción a las API de Foundation Model
• Despliegue de puntos de conexión con rendimiento aprovisionado
• Límites y regiones de implementación de modelos
• Referencia de API