Limites et quotas des API de modèles fondamentaux

Cette page décrit les limites et quotas des charges de travail Databricks Foundation Model.

Les API Databricks Foundation Model appliquent des limites de débit pour garantir des performances fiables et une allocation équitable des ressources pour tous les utilisateurs. Ces limites varient en fonction du niveau de plateforme de l’espace de travail, du type de modèle de base et de la façon dont vous déployez votre modèle de base.

Limites du taux de point de terminaison par jeton

Les points de terminaison à paiement par jeton sont régis par des limites de débit basées tant sur des jetons que sur des requêtes. Les limites de débit basées sur les jetons contrôlent le nombre maximal de jetons qui peuvent être traités par minute et sont appliqués séparément pour les jetons d’entrée et de sortie.

• Jetons d’entrée par minute (ITPM) : nombre maximal de jetons d’entrée (à partir de vos invites) qui peuvent être traités dans une fenêtre de 60 secondes. Une limite de débit ITPM contrôle le flux des jetons entrants d’un point d'accès.
• Jetons de sortie par minute (OTPM) : nombre maximal de jetons de sortie (à partir des réponses du modèle) qui peuvent être générés dans une fenêtre de 60 secondes. Une limite de débit OTPM contrôle le débit du jeton de sortie d’un point de terminaison.
• Requêtes par heure : nombre maximal de requêtes ou de requêtes qui peuvent être traitées dans une fenêtre de 60 minutes. Pour les applications de production avec des modèles d’utilisation soutenus, Databricks recommande de provisionner des points de terminaison de débit, qui fournissent une capacité garantie.

Suivi et application des limites

La limite de débit la plus restrictive (ITPM, OTPM, QPH) s’applique à tout moment. Par exemple, même si vous n'avez pas atteint votre limite ITPM, vous pourriez toujours être soumis à une limitation si vous dépassez la limite QPH ou OTPM. Lorsque la limite ITPM ou OTPM est atteinte, les requêtes suivantes reçoivent une erreur 429 indiquant qu’un trop grand nombre de demandes ont été reçues. Ce message persiste jusqu’à ce que la fenêtre limite de débit soit réinitialisée.

Databricks effectue le suivi et applique les limites de taux de jetons par minute (TPM) à l’aide des fonctionnalités suivantes :

Voici un exemple de la vérification avant admission et du fonctionnement du comportement de remboursement de crédit.

# 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

Nombre maximal de jetons en sortie pour les modèles ouverts

Chaque modèle ouvert dispose d’un nombre maximal de jetons de sortie qu’il peut générer en une seule réponse. Le tableau suivant liste le maximum pour chaque modèle disponible sur votre cloud.

Limites de débit par modèle

Les tableaux suivants résument les limites de taux ITPM, OTPM et QPH pour les points de terminaison API du Foundation Model à paiement au jeton pour les espaces de travail du niveau de plateforme Enterprise :

Niveaux de quota de jetons modèles partenaires

L’échelle des quotas de jetons du modèle partenaire comporte trois niveaux numérotés. Les modèles partenaires sont par défaut au niveau 1, sauf si une contrainte de capacité du fournisseur propre au modèle exige une limite inférieure. Ces niveaux de quota sont distincts du niveau de plateforme de votre espace de travail.

Les limites personnalisées de jetons nécessitent une revue de capacité par Databricks et sont en dehors de ces trois niveaux. Les niveaux de quotas de jetons ne modifient que les limites ITPM et OTPM ; les limites RPS, QPS, RPH et QPH restent spécifiques au modèle. Un modèle partenaire conserve une valeur par défaut inférieure uniquement pour une contrainte de capacité fournisseur spécifique au modèle. Les modèles ouverts conservent les valeurs par défaut indiquées dans les tableaux suivants.

Meilleures pratiques pour la gestion des limites de taux de transactions par minute (TPM)

Étape 1. Surveiller l’utilisation des jetons

Effectuez le suivi des nombres de jetons d’entrée et de sortie séparément dans vos applications :

# 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

Étape 2. Implémenter la logique de réessai

Ajoutez un retrait exponentiel lorsque vous rencontrez des erreurs de limitation de taux :

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

Étape 3. Optimiser l’utilisation des jetons

• Réduire la longueur des invites : utiliser des invites concises et bien structurées
• Longueur de sortie du contrôle : utiliser un max_tokens paramètre pour limiter la taille de réponse
• Traitement par lots efficace : regroupez les demandes liées lorsque cela est possible tout en respectant les limites

Étape 4. Envisager la sélection du modèle

• Modèles plus petits pour des tâches à grand volume : Utilisez des modèles comme GPT OSS 20B pour des tâches nécessitant un débit plus élevé.
• Grands modèles pour des tâches complexes : Réservez GPT OSS 120B pour les tâches nécessitant une capacité maximale.

Surveillance et dépannage

Surveillez vos modèles d’utilisation des jetons pour optimiser les performances :

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

Gérer les erreurs de limite de débit

Lorsque vous dépassez les limites de débit, l’API retourne une 429 Too Many Requests erreur :

{
  "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 réponse d’erreur inclut :

• limit_type: Quelle limite spécifique a été dépassée (ITPM, OTPM, QPS ou QPH)
• limit: valeur de limite configurée
• current: Votre utilisation actuelle
• retry_after: Temps d’attente suggéré en secondes

Gérer les erreurs de capacité de service

Une erreur 429 Too Many Requests signifie que votre charge de travail a dépassé une limite de débit sous votre contrôle. Une 503 Service Unavailable erreur est différente : cela signifie que les API Foundation Model sont temporairement à pleine capacité et ne peuvent pas répondre à votre demande. Un 503 n’est pas comptabilisé dans vos propres limites de taux et n’indique pas non plus que vous les avez atteintes.

Considérez les réponses 503 comme transitoires et réessayez avec une temporisation exponentielle, suivant le même schéma qu’à l’étape 2. Implémentez la logique de réessayage. Pour les charges de production nécessitant une capacité constante, utilisez le débit alloué, qui fournit une capacité dédiée au lieu d’une capacité partagée à l’usage par jeton. Consultez la documentation sur le débit provisionné réservé et le débit provisionné à la demande pour les modèles de fondation supportés.

Problèmes courants et solutions

Limites de débit provisionné

Pour les charges de travail de production nécessitant des limites plus élevées, les points de terminaison de débit approvisionnés offrent :

• Aucune restriction TPM : capacité de traitement basée sur les ressources approvisionnées
• Limites de débit plus élevées : jusqu’à 200 requêtes par seconde par espace de travail
• Performances prévisibles : les ressources dédiées garantissent une latence cohérente

Limites des jetons de sortie

Le tableau suivant récapitule les limites de jeton de sortie pour chaque modèle pris en charge :

Limites supplémentaires

Voici des limites pour les charges de travail de débit provisionné :

• Pour déployer un modèle Meta Llama à partir du system.ai catalogue Unity, vous devez choisir la version Instruct applicable. Les versions de base des modèles Meta Llama ne sont pas prises en charge pour le déploiement à partir du catalogue Unity. Consultez Déployer des points de terminaison de débit provisionnés.
• Pour les charges de travail à débit provisionné qui utilisent Llama 4 Maverick :
  • La prise en charge de ce modèle sur les charges de travail de débit provisionné est disponible en préversion publique.
  • La mise à l’échelle automatique n’est pas prise en charge.
  • Les panneaux de métriques ne sont pas pris en charge.
  • Le fractionnement du trafic n’est pas pris en charge sur un point de terminaison utilisé pour Llama 4 Maverick. Vous ne pouvez pas servir plusieurs modèles sur un point de terminaison qui sert Llama 4 Maverick.

Disponibilité régionale et traitement des données

Pour connaître la disponibilité de la région du modèle de base hébergée par Databricks, consultez la vue d’ensemble du modèle De base.

Pour plus d’informations sur le traitement et la résidence des données, consultez Traitement et résidence des données.

Limites de ressources et de charge utile pour les modèles Foundation et les modèles externes

Les tableaux suivants résument les limites de ressources et de charge utile pour les points de terminaison servant des modèles de base et des modèles externes.

La limite de diffusion en continu de 30 minutes ne s’applique pas aux modèles hérités Meta Llama 3.1 8B, 70B et 405B. Les requêtes en streaming vers ces modèles utilisent la limite de 597 secondes.

Ressources supplémentaires

• Vue d’ensemble des API Foundation Model
• Déployer des points de terminaison de débit provisionnés
• Limites et régions de mise en service de modèle
• Informations de référence sur l’API