Limites e cotas de APIs do Modelo de Fundação

Esta página descreve limites e cotas para cargas de trabalho das APIs de Modelo Fundamental do Databricks.

As APIs de Modelo do Databricks Foundation impõem limites de taxa para garantir o desempenho confiável e a alocação justa de recursos entre todos os usuários. Esses limites variam de acordo com a camada de plataforma do workspace, o tipo de modelo de base e como você implanta seu modelo de base.

Limites de taxa de endpoint pay-per-token

Os endpoints de pagamento por token são regidos por limites de taxa baseados em token e limites baseados em consulta. Os limites de taxa baseados em token controlam o número máximo de tokens que podem ser processados por minuto e são impostos separadamente para tokens de entrada e saída.

• Tokens de entrada por minuto (ITPM): o número máximo de tokens de entrada (dos prompts) que podem ser processados em uma janela de 60 segundos. Um limite de taxa de ITPM controla a taxa de transferência de tokens de entrada de um endpoint.
• Tokens de saída por minuto (OTPM): o número máximo de tokens de saída (das respostas do modelo) que podem ser gerados em uma janela de 60 segundos. Um limite de taxa de OTPM controla a taxa de transferência de tokens de saída de um endpoint.
• Consultas por hora: o número máximo de consultas ou solicitações que podem ser processadas em uma janela de 60 minutos. Para aplicativos de produção com padrões de uso contínuos, o Databricks recomenda "endpoints" com taxa de transferência provisionada, que ofereçam capacidade garantida.

Como os limites são controlados e impostos

O limite de taxa mais restritivo (ITPM, OTPM, QPH) se aplica a qualquer momento. Por exemplo, mesmo que você não tenha atingido o limite do ITPM, ainda poderá ter uma taxa limitada se exceder o limite de QPH ou OTPM. Quando o limite de ITPM ou OTPM é atingido, as solicitações subsequentes recebem um erro 429 que indica que muitas solicitações foram recebidas. Essa mensagem persiste até que a janela de limite de taxa seja redefinida.

O Databricks rastreia e impõe limites de taxa de tokens por minuto (TPM) usando os seguintes recursos:

Veja a seguir um exemplo de como funcionam a verificação pré-admissão e o comportamento de devolução de créditos.

# 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 taxa por modelo

As tabelas a seguir resumem os limites de taxa ITPM, OTPM e QPH para pontos de extremidade da API do Modelo Foundation de pagamento por token para espaços de trabalho na plataforma de workspace Enterprise:

Níveis de cota de tokens do modelo de parceiro

A escala de cotas de tokens do modelo parceiro possui três níveis numerados. Modelos parceiros adotam por padrão o Tier 1, a menos que uma restrição de capacidade específica do modelo exija um limite inferior. Esses níveis de cota são separados do nível da plataforma do seu espaço de trabalho.

Limites personalizados de tokens exigem uma revisão de capacidade pela Databricks e estão fora desses três níveis. Os níveis de cota de tokens alteram apenas os limites ITPM e OTPM; Os limites de RPS, QPS, RPH e QPH permanecem específicos de cada modelo. Um modelo parceiro mantém um valor padrão mais baixo apenas para uma restrição de capacidade do provedor específica do modelo. Modelos abertos mantêm os padrões mostrados nas tabelas a seguir.

Práticas recomendadas para gerenciar limites de taxa do TPM

Etapa 1. Monitorar a utilização de tokens

Acompanhe as contagens de token de entrada e saída separadamente em seus aplicativos:

# 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

Etapa 2. Implementar lógica de retentativa

Adicione retirada exponencial ao encontrar erros de limite de taxa:

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

Etapa 3. Otimizar o uso de token

• Minimizar o comprimento do prompt: use prompts concisos e bem estruturados
• Controlar o comprimento da saída: use o parâmetro max_tokens para limitar o tamanho da resposta
• Agrupe em lotes com eficiência: agrupe solicitações relacionadas quando possível, permanecendo dentro dos limites

Etapa 4. Considere a seleção de modelo

• Modelos menores para tarefas de alto volume: Use modelos como GPT OSS 20B para tarefas que exigem maior throughput.
• Modelos grandes para tarefas complexas: Reserve o GPT OSS 120B para tarefas que exigem capacidade máxima.

Monitoramento e solução de problemas

Monitore os padrões de uso do token para otimizar o desempenho:

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

Manipular erros de limite de taxa

Quando você excede os limites de taxa, a API retorna um 429 Too Many Requests erro:

{
  "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
  }
}

A resposta de erro inclui:

• limit_type: qual limite específico foi excedido (ITPM, OTPM, QPS ou QPH)
• limit: o valor limite configurado
• current: seu uso atual
• retry_after: tempo de espera sugerido em segundos

Lidar com erros de capacidade de serviço

Um erro 429 Too Many Requests significa que sua carga de trabalho excedeu um limite de taxa sob seu controle. Um erro 503 Service Unavailable é diferente: significa que as APIs de Foundation Model estão temporariamente com capacidade máxima e não puderam atender sua solicitação. Um 503 não conta contra nem indica que você atingiu seus próprios limites de taxa.

Trate as respostas 503 como transitórias e tente novamente com recuo exponencial, seguindo o mesmo padrão do Passo 2. Implemente lógica de retentativa. Para cargas de trabalho de produção que precisam de capacidade consistente, use throughput provisionado, que fornece capacidade dedicada em vez de capacidade compartilhada com pagamento por token. Veja a documentação sobre throughput provisionado reservado e throughput provisionado sob demanda para modelos de fundação suportados.

Problemas comuns e soluções

Limites de taxa de transferência provisionada

Para cargas de trabalho de produção que exigem limites mais altos, os endpoints de taxa de transferência provisionada oferecem:

• Sem restrições de TPM: capacidade de processamento com base em recursos provisionados
• Limites de taxa mais altos: até 200 consultas por segundo por workspace
• Desempenho previsível: recursos dedicados garantem latência consistente

Limites de token de saída

A tabela a seguir resume os limites do token de saída para cada modelo com suporte:

Limites adicionais

Veja a seguir as limitações para cargas de trabalho de taxa de transferência provisionada:

• Para implantar um modelo Meta Llama de system.ai no Catálogo do Unity, você deve escolher a versão de Instrução aplicável. Não há suporte para as versões base dos modelos Meta Llama para implantação no Unity Catalog. Consulte Implantar endpoints de taxa de transferência provisionada.
• Para as cargas de trabalho com taxa de transferência provisionada que usam Llama 4 Maverick:
  • O suporte para esse modelo em cargas de trabalho de taxa de transferência provisionada está na Versão Prévia Pública.
  • Não há suporte para dimensionamento automático.
  • Não há suporte para painéis de métricas.
  • Não há suporte para divisão de tráfego em um endpoint que atende ao Llama 4 Maverick. Você não pode servir vários modelos em um endpoint que serve o Llama 4 Maverick.

Disponibilidade regional e processamento de dados

Para obter a disponibilidade regional de modelos base hospedados pelo Databricks, consulte visão geral do modelo fundacional.

Para obter detalhes de processamento de dados e residência, consulte Processamento de dados e residência.

Limites de recursos e conteúdo para modelos do Foundation e modelos externos

As tabelas a seguir resumem os limites de recursos e conteúdo para pontos de extremidade que atendem modelos de base e modelos externos.

Recursos adicionais

• Visão geral das APIs do Modelo de Fundação
• Implantar endpoints de taxa de transferência provisionada
• Limites e regiões de Model Serving
• Referência de API