Limites et quotas des APIs Foundation Model
Cette page décrit les limites et les quotas des charges de travail des API de modèle de fondation Databricks.
Les APIs Databricks Foundation Model imposent des limites de débit afin d'assurer des performances fiables et une allocation équitable des ressources à tous les utilisateurs. Ces limites varient en fonction du niveau de plateforme Workspace, du type de modèle de fondation et de la manière dont vous déployez votre modèle de fondation.
Limites de débit de l'Endpoint par jeton
Les Endpoint à paiement par jeton sont régis par des limites de débit basées sur les jetons et les query. Les limites de débit basées sur les jetons contrôlent le nombre maximal de jetons pouvant être traités par minute et sont appliquées séparément pour les jetons d'entrée et de sortie.
- Jetons d'entrée par minute (ITPM) : Le 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 throughput de jetons d'entrée d'un endpoint.
- Jetons de sortie par minute (OTPM) : le nombre maximal de jetons de sortie (provenant des réponses du modèle) pouvant être générés sur une période de 60 secondes. Une limite de débit OTPM contrôle le throughput des jetons de sortie d'un Endpoint.
- Queries par heure : Le nombre maximum de queries ou de requêtes pouvant être traitées dans une fenêtre de 60 minutes. Pour les applications de production avec des modèles d'utilisation soutenus, Databricks recommande les endpoints de throughput provisionné, qui offrent une capacité garantie.
Comment les limites sont suivies et appliquées
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, votre débit pourrait toujours être limité 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 qui indique qu’un trop grand nombre de requêtes ont été reçues. Ce message persiste jusqu'à ce que la fenêtre de limite de débit Reset.
Databricks suit et applique les limites de taux de jetons par minute (TPM) à l'aide des fonctionnalités suivantes :
Fonctionnalité | Détails |
|---|---|
Comptabilité des jetons et contrôles de pré-admission |
Remarque : Claude Sonnet 4 utilise spécifiquement default 1 000 jetons de sortie lorsque |
Capacité de rafale et lissage |
|
Voici un exemple de fonctionnement de la vérification préadmission et du mécanisme de remboursement du 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
Limites de débit par modèle
Les tableaux suivants récapitulent les limites de débit ITPM, OTPM et QPH pour les endpoints d'API du modèle de fondation à paiement par jeton pour les *workspaces de niveau Entreprise* :
À partir du 15 février 2026, Meta-Llama-3.1-405B-Instruct sera retiré. Consultez Modèles obsolètes et retirés pour connaître le modèle de remplacement recommandé et obtenir des conseils sur la migration pendant la période d'obsolescence.
Grands modèles de langage | Limite ITPM | Limite OTPM | Limite QPH | Notes |
|---|---|---|---|---|
GPT-5.6 Sol | 2 000 000 | 200 000 | 360 000 | LLM phare avec des capacités de raisonnement |
GPT-5.6 Terra | 2 000 000 | 200 000 | 360 000 | LLM polyvalent avec des capacités de raisonnement |
GPT-5.6 Luna | 2 000 000 | 200 000 | 360 000 | LLM optimisé pour le coût avec des capacités de raisonnement |
GPT-5.5 Pro | 200 000 | 20 000 | 360 000 | LLM de plus grande précision avec des capacités de raisonnement |
GPT-5.5 | 200 000 | 20 000 | 360 000 | LLM polyvalent avec des capacités de raisonnement |
GPT-5.4 | 200 000 | 20 000 | 360 000 | LLM polyvalent avec des capacités de raisonnement |
GPT-5,4 mini | 200 000 | 20 000 | 360 000 | LLM polyvalent avec des capacités de raisonnement |
GPT-5.4 nano | 200 000 | 20 000 | 360 000 | LLM polyvalent avec des capacités de raisonnement |
GPT-5.3 Codex | 200 000 | 20 000 | 360 000 | LLM spécialisé dans le code |
GPT-5.2 | 200 000 | 20 000 | 360 000 | LLM polyvalent avec des capacités de raisonnement |
GPT-5.1 | 200 000 | 20 000 | 360 000 | LLM polyvalent avec des capacités de raisonnement |
GPT-5 | 200 000 | 20 000 | 360 000 | LLM généraliste |
GPT-5 mini | 200 000 | 20 000 | 360 000 | LLM généraliste |
GPT-5 nano | 200 000 | 20 000 | 360 000 | LLM généraliste |
Gemini 3.1 Flash Image | 200 000 | 20 000 | 360 000 | Modèle multimodal avec sortie d'image |
Image Gemini 3 Pro | 200 000 | 20 000 | 360 000 | Modèle multimodal avec sortie d'image |
Gemini 3,6 Flash | 200 000 | 20 000 | 360 000 | |
Gemini 3.5 Flash | 200 000 | 20 000 | 360 000 | |
Gemini 3.1 Pro Preview | 200 000 | 20 000 | 360 000 | |
Gemini 3,1 Flash Lite | 200 000 | 20 000 | 360 000 | |
Gemini 3 Flash | 200 000 | 20 000 | 360 000 | |
Gemini 2.5 Pro | 200 000 | 20 000 | 360 000 | Databricks ne prend pas en charge les requêtes de plus de 200 000 jetons d'entrée ou les tailles de requête de plus de 400 Ko par default. |
Gemini 2.5 Flash | 200 000 | 20 000 | 360 000 | Databricks ne prend pas en charge les requêtes de plus de 200 000 jetons d'entrée ou les tailles de requête de plus de 400 Ko par default. |
Qwen3.5 122B A10B (Aperçu public) | 200 000 | 10 000 | Modèle de raisonnement | |
Qwen3-Next 80B A3B Instruct (Bêta) | 200 000 | 10 000 | LLM généraliste | |
GLM 5.2 | 200 000 | 10 000 | Modèle de raisonnement MoE | |
Inkling (Aperçu public) | 200 000 | 10 000 | LLM multimodal | |
GPT OSS 120B | 200 000 | 10 000 | LLM généraliste | |
GPT OSS 20B | 200 000 | 10 000 | Variante GPT plus petite | |
Gemma 3 12B | 200 000 | 10 000 | 7 200 | Le modèle Gemma de Google |
Llama 4 Maverick | 200 000 | 10 000 | 2 400 | Dernière version de Llama |
Llama 3.3 70B Instruct | 200 000 | 10 000 | 2 400 | Modèle Llama de taille moyenne |
Llama 3.1 8B Instruct | 200 000 | 10 000 | 7 200 | Modèle Llama léger |
Llama 3.1 405B Instruct | 5 000 | 500 | 1 200 |
|
Modèles Anthropic Claude | Limite ITPM | Limite OTPM | Limite QPH | Notes |
|---|---|---|---|---|
Claude Fable 5 | 200 000 | 20 000 | 360 000 | |
Claude Haiku 4.5 | 200 000 | 20 000 | 360 000 | Dernière version de Haiku |
Claude Opus 4,8 | 200 000 | 20 000 | 360 000 | Dernière version d’Opus |
Claude Opus 4.7 | 200 000 | 20 000 | 360 000 | |
Claude Opus 4.6 | 200 000 | 20 000 | 360 000 | |
Claude Opus 4.5 | 200 000 | 20 000 | 360 000 | |
Claude Opus 4.1 | 200 000 | 20 000 | 360 000 | |
Claude Sonnet 5 | 200 000 | 20 000 | 360 000 | Dernière version de Sonnet |
Claude Sonnet 4.6 | 200 000 | 20 000 | 360 000 | |
Claude Sonnet 4.5 | 200 000 | 20 000 | 360 000 | |
Claude Sonnet 4 | 200 000 | 20 000 | 360 000 |
Modèles d'intégration | Limite ITPM | Limite OTPM | Limite QPH | Notes |
|---|---|---|---|---|
Qwen3-Embedding-0.6B | N/A | N/A | 2 160 000 | Modèle compact d'intégration de texte multilingue |
GTE Large (Anglais) | N/A | N/A | 540 000 | Modèle d'intégration de texte — ne génère pas d'embeddings normalisés |
BGE Large (Fr) | N/A | N/A | 2 160 000 | Modèle d'intégration de texte |
Bonnes pratiques pour la gestion des limites de débit TPM
Étape 1. Surveiller l’utilisation des jetons
Suivez le nombre 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émentez une logique de nouvelle tentative
Ajoutez un délai d'attente exponentiel lorsque vous rencontrez des erreurs de limite de débit :
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. Optimisez l'utilisation des jetons
- Minimisez la longueur des prompts : utilisez des prompts concis et bien structurés.
- Contrôler la longueur de la sortie : utilisez le paramètre
max_tokenspour limiter la taille de la réponse - Définissez explicitement max_tokens pour Claude Sonnet 4 : spécifiez toujours
max_tokenslorsque vous utilisez Claude Sonnet 4 pour éviter la limite de 1 000 jetons default. - Traiter par batch efficacement : regroupez les requêtes connexes lorsque cela est possible tout en respectant les limites.
Étape 4. Considérer la sélection du modèle.
- Modèles plus petits pour les tâches à volume élevé : utilisez des modèles comme Llama 3.1 8B pour les tâches qui nécessitent un throughput plus élevé.
- Grands modèles pour les tâches complexes : réservez Llama 3.1 405B pour les tâches qui nécessitent une capacité maximale
Monitoring et dépannage
Surveillez vos schémas 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 limitation de débit
Lorsque vous dépassez les limites de débit, l'API renvoie une erreur 429 Too Many Requests :
{
"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 réponse d'erreur inclut :
limit_type: Quelle limite spécifique a été dépassée (ITPM, OTPM, QPS ou QPH) ?limit: la valeur limite configuréecurrent: Votre utilisation actuelleretry_after: Temps d'attente suggéré en secondes
Problèmes courants et solutions
Problème | Solutions |
|---|---|
Erreurs 429 fréquentes | Implémenter une interruption exponentielle, réduire le taux de requêtes et demander des limites de taux plus élevées. |
Limite ITPM atteinte | Optimiser la longueur des prompts |
Limite OTPM atteinte. | Utilisez |
Limite QPH atteinte | Distribuer les requêtes plus uniformément au fil du temps |
Limites de throughput provisionné
Pour les charges de travail de production qui nécessitent des limites plus élevées, les endpoints de throughput provisionné offrent :
- Aucune restriction TPM : capacité de traitement basée sur les ressources provisionnées
- Limites de débit plus élevées : jusqu'à 200 requêtes par seconde et par Workspace
- Performances prévisibles : Des ressources dédiées assurent une latence constante
Limites des jetons de sortie
À partir du 15 mai 2026, Meta-Llama-3.1-405B-Instruct sera retiré. Consultez Modèles obsolètes et retirés pour connaître le modèle de remplacement recommandé et obtenir des conseils sur la migration pendant la période d'obsolescence.
Le tableau suivant récapitule les limites de jetons de sortie pour chaque modèle pris en charge :
Modèle | Limite des jetons de sortie |
|---|---|
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 |
Limites supplémentaires
Voici les limites pour les workloads à throughput provisionné :
-
Pour les workloads de throughput provisionné qui utilisent **Llama 4 Maverick** :
- Le support de ce modèle pour les workloads avec throughput provisionné est en aperçu public.
- Le dimensionnement automatique n'est pas pris 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 endpoint qui sert Llama 4 Maverick. Vous ne pouvez pas servir plusieurs modèles sur un endpoint qui sert Llama 4 Maverick.
-
Pour déployer un modèle Meta Llama à partir de
system.aidans Unity Catalog, vous devez choisir la version Instruct applicable. Les versions de base des modèles Llama Meta ne sont pas prises en charge pour le déploiement à partir de Unity Catalog. Consultez Déployer des Endpoint de throughput provisionné.
Disponibilité régionale et traitement des données
Pour la disponibilité régionale des modèles de fondation hébergés par Databricks, consultez l'aperçu du modèle de fondation.
Pour plus de détails 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 de fondation et les modèles externes
Les tableaux suivants récapitulent les limites de ressources et de charge utile pour les Endpoint qui servent les modèles de fondation et les modèles externes.
Fonctionnalité | Granularité | Limite |
|---|---|---|
Taille de la charge utile | Par requête | 4 Mo |
Taille de la requête/réponse | Par requête | Toute requête/réponse de plus de 1 Mo ne sera pas consignée. |
Requêtes par seconde (QPS) | Per Workspace | 200 |
Durée d'exécution du modèle | Par requête | 597 secondes |
Latence du système | Par requête | Moins de 50 millisecondes |