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 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 (provenientes de tus 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 su límite de ITPM, todavía podría estar sujeto a limitaciones de tasa 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 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 siguientes tablas se resumen los límites de tasa para ITPM, OTPM y QPH de los endpoints de la API del Modelo Fundacional de pago por token para las áreas de trabajo del nivel Enterprise:

Gestión de las mejores prácticas de 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. Implemente 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
• Controlar la longitud de salida: utilice el parámetro max_tokens 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")

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

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 Despliegue de puntos de conexión de rendimiento aprovisionado.
• Para cargas de trabajo con rendimiento aprovisionado que usan Llama 4 Maverick:
  • La compatibilidad con este modelo en cargas de trabajo con tasas 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 gestione 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.

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