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 |
|
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
Le tableau suivant résume les limites de débit ITPM, OTPM et QPH pour les Endpoint de l'API des modèles de fondation avec paiement par jeton pour les Workspace de l'offre Enterprise Workspace platform tier :
Pour les modèles prenant en charge le throughput provisionné, créez un endpoint de throughput provisionné si les limites de paiement au jeton ne répondent pas aux exigences de votre cas d’utilisation.
Niveaux de quota de jetons pour les modèles partenaires
L’échelle de quotas de jetons des modèles de partenaires comporte trois niveaux numérotés. Les modèles de Partenaires utilisent par default le niveau 1, sauf si une contrainte de capacité du fournisseur spécifique au modèle exige une limite inférieure. Ces niveaux de quota sont distincts de votre niveau de plateforme Workspace.
Niveau de quota | Limite ITPM | Limite OTPM | Disponibilité |
|---|---|---|---|
Niveau 1 | 1 000 000 | 100 000 | Appliqué automatiquement aux modèles de partenaires, sauf en cas d’exception de capacité du fournisseur spécifique au modèle. |
Niveau 2 | 5 000 000 | 500 000 | Disponible via le flux de demande de quota |
Tier 3 | 10 000 000 | 1 000 000 | Disponible via le flux de demande de quota |
Les limites de jetons personnalisées nécessitent un examen de capacité par Databricks et se trouvent en dehors de ces trois niveaux. Les niveaux de quota de jetons modifient uniquement les limites ITPM et OTPM ; les limites RPS, QPS, RPH et QPH restent spécifiques au modèle. Un modèle partenaire conserve une limite default inférieure uniquement pour une contrainte de capacité du fournisseur propre au modèle. Les modèles ouverts conservent les valeurs default indiquées dans les tableaux suivants.
Grands modèles de langage | Limite ITPM | Limite OTPM | Limite QPH |
|---|---|---|---|
GPT-6.1 Sol | 1 000 000 | 100 000 | 360 000 |
GPT-6 Sol | 1 000 000 | 100 000 | 360 000 |
GPT-6 Luna | 1 000 000 | 100 000 | 360 000 |
GPT-6 Astra | 1 000 000 | 100 000 | 360 000 |
GPT-5.6 Sol | 1 000 000 | 100 000 | 360 000 |
GPT-5.6 Terra | 1 000 000 | 100 000 | 360 000 |
GPT-5.6 Luna | 1 000 000 | 100 000 | 360 000 |
GPT-5.5 Pro | 1 000 000 | 100 000 | 360 000 |
GPT-5.5 | 1 000 000 | 100 000 | 360 000 |
GPT-5.4 | 1 000 000 | 100 000 | 360 000 |
GPT-5,4 mini | 1 000 000 | 100 000 | 360 000 |
GPT-5.4 nano | 1 000 000 | 100 000 | 360 000 |
GPT-5.3 Codex | 1 000 000 | 100 000 | 360 000 |
GPT-5.2 | 1 000 000 | 100 000 | 360 000 |
GPT-5.1 | 1 000 000 | 100 000 | 360 000 |
GPT-5 | 1 000 000 | 100 000 | 360 000 |
GPT-5 mini | 1 000 000 | 100 000 | 360 000 |
GPT-5 nano | 1 000 000 | 100 000 | 360 000 |
Gemini 3.1 Flash Image | 1 000 000 | 100 000 | 360 000 |
Image Gemini 3 Pro | 1 000 000 | 100 000 | 360 000 |
Gemini 3,5 Flash Lite | 1 000 000 | 100 000 | 360 000 |
Gemini 3.8 Flash | 1 000 000 | 100 000 | 360 000 |
Gemini 3.7 Flash | 1 000 000 | 100 000 | 360 000 |
Gemini 3,6 Flash | 1 000 000 | 100 000 | 360 000 |
Gemini 3.5 Flash | 1 000 000 | 100 000 | 360 000 |
Gemini 3.1 Pro Preview | 1 000 000 | 100 000 | 360 000 |
Gemini 3,1 Flash Lite | 1 000 000 | 100 000 | 360 000 |
Gemini 3 Flash | 1 000 000 | 100 000 | 360 000 |
Qwen3.5 122B A10B (Aperçu public) | 1 000 000 | 100 000 | 360 000 |
Qwen3-Next 80B A3B Instruct (Bêta) | 1 000 000 | 100 000 | 360 000 |
GLM 5.3 | 2 000 000 | 40 000 | 7 200 |
GLM 5.3 Flash | 2 000 000 | 40 000 | 7 200 |
GLM 5.2 (ancien) | 200 000 | 20 000 | 7 200 |
OpenJev (Qwen3.5 4B) | 2 000 000 | 40 000 | 7 200 |
DeepSeek V4.1 Flash | 2 000 000 | 40 000 | 7 200 |
DeepSeek V4 Pro (0813) | 200 000 | 4 000 | 7 200 |
DeepSeek V4 Flash (0731) | 200 000 | 10 000 | |
Kimi K3 | 2 000 000 | 40 000 | |
Grok 4,6 | 1 000 000 | 100 000 | 360 000 |
Grok 4,7 | 1 000 000 | 100 000 | 360 000 |
Inkling (Aperçu public) | 200 000 | 10 000 | 7 200 |
GPT OSS 120B | 1 000 000 | 100 000 | 360 000 |
GPT OSS 20B | 1 000 000 | 100 000 | 360 000 |
Gemma 3 12B | 1 000 000 | 100 000 | 360 000 |
Llama 4 Maverick | 1 000 000 | 100 000 | 360 000 |
Llama 3.3 70B Instruct | 1 000 000 | 100 000 | 360 000 |
Llama 3.1 8B Instruct | 1 000 000 | 100 000 | 360 000 |
Modèles Anthropic Claude | Limite ITPM | Limite OTPM | Limite QPH |
|---|---|---|---|
Claude Fable 5.1 | 1 000 000 | 100 000 | 360 000 |
Claude Fable 5 | 1 000 000 | 100 000 | 360 000 |
Claude Haiku 5,5 | 200 000 | 20 000 | 360 000 |
Claude Haiku 4.5 | 1 000 000 | 100 000 | 360 000 |
Claude Opus 5 | 1 000 000 | 100 000 | 360 000 |
Claude Opus 5.5 | 1 000 000 | 100 000 | 360 000 |
Claude Opus 4,8 | 1 000 000 | 100 000 | 360 000 |
Claude Opus 4.7 | 1 000 000 | 100 000 | 360 000 |
Claude Opus 4.6 | 1 000 000 | 100 000 | 360 000 |
Claude Opus 4.5 | 1 000 000 | 100 000 | 360 000 |
Claude Opus 4.1 | 1 000 000 | 100 000 | 360 000 |
Claude Sonnet 5 | 1 000 000 | 100 000 | 360 000 |
Claude Sonnet 5.5 | 1 000 000 | 100 000 | 360 000 |
Claude Sonnet 4.6 | 1 000 000 | 100 000 | 360 000 |
Claude Sonnet 4.5 | 1 000 000 | 100 000 | 360 000 |
Modèles d'intégration | Limite ITPM | Limite OTPM | Limite QPH |
|---|---|---|---|
Qwen3-Embedding-0.6B | N/A | N/A | 2 160 000 |
GTE Large (Anglais) | N/A | N/A | 540 000 |
BGE Large (Fr) | N/A | N/A | 2 160 000 |
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
Step 2. Implement retry logic
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 - 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 à grand volume : utilisez des modèles comme GPT OSS 20B pour les tâches nécessitant un throughput plus élevé.
- Grands modèles pour des tâches complexes : réservez GPT OSS 120B aux tâches nécessitant 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 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: la valeur limite configuréecurrent: Votre utilisation actuelleretry_after: Temps d'attente suggéré en secondes
Gérer les erreurs de capacité du 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 erreur 503 Service Unavailable est différente : elle signifie que les APIs Foundation Model sont temporairement saturées et n'ont pas pu répondre à votre demande. Une erreur 503 ne compte pas et n'indique pas que vous avez atteint vos propres limites de débit.
Considérez les réponses 503 comme temporaires et réessayez avec un intervalle exponentiel, en suivant le même modèle qu’à l’ étape 2. Mettre en œuvre une logique de nouvelle tentative. Pour les charges de travail de production qui ont besoin d'une capacité constante, utilisez le throughput provisionné, qui fournit une capacité dédiée au lieu d'une capacité partagée pay-per-token. Consultez la documentation sur le throughput provisionné réservé et le throughput provisionné à la demande pour connaître les modèles de base pris en charge.
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 |
503 Service indisponible | Nouez avec une interruption exponentielle ; pour une capacité de production cohérente, utilisez le throughput provisionné |
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
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 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 |