Partilhar via

Otimizar os endpoints de Servir de Modelos para produção

Aprenda a otimizar o desempenho dos endpoints de Model Serving para cargas de produção que exigem alta taxa de transferência, baixa latência e desempenho confiável.

As estratégias de otimização dividem-se em três categorias:

Quando otimizar o seu endpoint

Considere otimizar o seu endpoint de Model Serving quando encontrar algum dos seguintes cenários:

  • Elevado volume de consultas: A sua aplicação envia mais de 50 mil consultas por segundo (QPS) para um único endpoint
  • Requisitos de latência: A sua aplicação requer tempos de resposta inferiores a 100ms
  • Gargalos de escalabilidade: Os endpoints experienciam filas ou devolvem erros HTTP 429 durante picos de tráfego
  • Otimização de custos: Quer reduzir os custos de serviço mantendo as metas de desempenho
  • Preparação para produção: Está a preparar-se para passar do desenvolvimento para as cargas de produção

Otimizações da infraestrutura

As otimizações da infraestrutura melhoram o encaminhamento da rede, o comportamento de escalabilidade e a capacidade de computação.

Otimização de rotas

A otimização de rotas proporciona a melhoria de infraestrutura mais significativa para cargas de trabalho de alto rendimento. Quando ativa a otimização de rotas num endpoint, o Databricks Model Serving melhora o caminho de rede para pedidos de inferência, resultando numa comunicação mais rápida e direta entre clientes e modelos.

Benefícios de desempenho:

Característica Limite padrão de endpoint Limite de endpoint otimizado por rotas
Consultas por segundo (QPS) por espaço de trabalho 200 50.000+ (contacte a Databricks para limites superiores)
Concorrência de clientes por espaço de trabalho 192-1024 (varia consoante a região) Sem limite explícito (limitado por concorrência provisionada)
Concurrência configurada de endpoints por entidade servida 1,024 1.024 (contacte a Databricks para limites mais elevados)

Quando usar a otimização de rotas:

  • Cargas de trabalho que requerem mais de 200 QPS
  • Aplicações com requisitos rigorosos de latência (sobrecarga inferior a 50ms)
  • Implementações em produção que servem múltiplos utilizadores simultâneos

Importante

A otimização de rotas está disponível apenas para endpoints de modelos de serviço personalizados. As APIs do Foundation Model e modelos externos não suportam otimização de rotas. Tokens OAuth são necessários para autenticação; Tokens de acesso pessoal não são suportados.

Consulte Otimização de rotas nos endpoints de serviço para instruções de configuração e Interrogar endpoints de serviço otimizados para rotas para obter detalhes sobre consultas.

Concorrência provisionada

A concorrência provisionada controla quantos pedidos simultâneos o seu endpoint pode processar. Configure a concorrência provisionada com base nos seus requisitos esperados de latência e QPS.

Diretrizes de configuração:

  • Concorrência mínima: Definido suficientemente alto para gerir tráfego base sem necessidade de fila
  • Concorrência máxima: Definida suficientemente alta para acomodar picos de tráfego enquanto se controla os custos
  • Autoescalonamento: Permitir o autoescalonamento para ajustar dinamicamente a capacidade com base na procura

Calcule a concorrência necessária:

Required Concurrency = Target QPS × Average Latency (seconds)

Por exemplo, se a sua meta for 100 QPS com uma latência média de 200ms:

Required Concurrency = 100 × 0.2 = 20

Use testes de carga para medir a latência real e determinar as definições ótimas de concorrência.

Tipos de instância

Escolha os tipos de instância com base nos requisitos de computação do seu modelo:

Tipo de instância Melhor para Trade-offs
CPU (Pequeno, Médio, Grande) Modelos leves, lógica de inferência simples Menor custo, mais lento para modelos que exigem muita computação
GPU (Pequeno, Médio, Grande) Modelos grandes, cálculos complexos, processamento de imagem/vídeo Custo mais elevado, desempenho ótimo para aprendizagem profunda

Sugestão

Comece com instâncias de CPU para desenvolvimento e testes. Mude para instâncias de GPU apenas se observar uma alta latência de inferência ou se o seu modelo exigir computação especializada (como operações de aprendizagem profunda).

Otimizações de modelos

As otimizações de modelos melhoram a velocidade de inferência e a eficiência dos recursos.

Tamanho e complexidade do modelo

Tamanho e Complexidade do Modelo: Modelos menores e menos complexos geralmente conduzem a tempos de inferência mais rápidos e a QPS mais elevados. Considere técnicas como quantização de modelos ou poda se o seu modelo for grande.

Criação de batches

Se a sua aplicação conseguir enviar múltiplos pedidos numa única chamada, ative o batching do lado do cliente. Isto pode reduzir significativamente a sobrecarga para cada previsão.

Otimização do pré-processamento e pós-processamento

Descarregar o pré-processamento e pós-processamento complexos dos endpoints de serviço para reduzir a carga na infraestrutura de inferência.

Otimizações do lado do cliente

As otimizações do lado do cliente melhoram a forma como as aplicações interagem com os endpoints de serviço.

Agrupamento de conexões

O pooling de conexões reutiliza ligações existentes em vez de criar novas ligações para cada pedido, reduzindo significativamente a sobrecarga.

  • Use o Databricks SDK, que implementa automaticamente as melhores práticas de pooling de ligações
  • Se usares clientes personalizados, implementa tu próprio o pooling de ligações.

Gestão de erros e estratégias de tentativas

Implemente uma gestão robusta de erros para gerir falhas temporárias de forma eficiente, especialmente durante eventos de autoescalabilidade ou interrupções de rede.

Otimização do tamanho da carga útil

Minimizar o tamanho da carga de dados de pedidos e respostas para reduzir o tempo de transferência na rede e melhorar o throughput.

Medir e melhorar o desempenho

Monitorização do desempenho

Monitorize o desempenho dos endpoints utilizando as ferramentas fornecidas pelo Mosaic AI Model Serving:

Métrico O que mede Target Ação em caso de excesso
Latência (P50, P90, P99) Tempo de resposta aos pedidos Depende da aplicação (tipicamente <100-500ms) Verifique se há filas e otimize o modelo ou o cliente
Rendimento (QPS) Pedidos concluídos por segundo Depende da carga de trabalho Permitir a otimização de rotas, aumentar a concorrência provisionada
Taxa de erro Percentagem de pedidos falhados <1% Revisar registos de serviço, verificar problemas de capacidade
Profundidade da fila Pedidos à espera de processamento 0 (sem fila) Aumentar a concorrência provisionada ou ativar o dimensionamento automático
Utilização de CPU/Memória Utilização de recursos <80% Aumentar o tipo de instância ou aumentar a concorrência

Consulte Monitorizar a qualidade do modelo e a saúde dos endpoints para orientações detalhadas de monitorização e Monitorizar e exportar métricas de saúde dos pontos finais de serviço para o Prometheus e o Datadog para exportar métricas para ferramentas de observabilidade.

Testes de carga

O teste de carga mede o desempenho dos pontos finais em condições de tráfego realistas e ajuda a:

  • Determinar as configurações ideais de concorrência provisionada
  • Identificar estrangulamentos de desempenho
  • Validar requisitos de latência e capacidade
  • Compreenda a relação entre a concorrência do cliente e a concorrência do servidor

Veja Testes de carga para servidores de endpoints.

Resolver problemas de desempenho comuns

Queuing

O Model Serving suporta o autoescalonamento para ajustar a capacidade com base nos padrões de tráfego. No entanto, súbitos picos de tráfego podem causar fila porque o escalonamento automático requer tempo para detetar o aumento da carga e provisionar capacidade adicional. Durante este período, os pedidos recebidos podem temporariamente exceder a capacidade disponível, fazendo com que os pedidos entrem em fila.

O enfileiramento ocorre quando a taxa de solicitação ou concorrência ultrapassa a capacidade atual de processamento do endpoint. Isto acontece tipicamente durante picos bruscos de tráfego, explosões de carga de trabalho ou quando o endpoint tem concorrência provisionada insuficiente. Os pontos de extremidade do Model Serving permitem filas temporárias para lidar com rajadas; no entanto, além de um limite estabelecido, o ponto de extremidade devolve erros HTTP 429 (Demasiados Pedidos) para proteger a estabilidade do sistema.

A fila aumenta a latência porque os pedidos em fila esperam antes de serem processados. Para minimizar as filas:

  • Defina a concorrência mínima provisionada suficientemente alta para lidar com tráfego base mais rajadas típicas
  • Permitir a otimização de rotas para limites de capacidade mais elevados
  • Implemente lógica de tentativa de repetição com backoff exponencial nas aplicações cliente.

Gargalos externos de APIs

Os modelos frequentemente chamam APIs externas para enriquecimento de dados, recuperação de funcionalidades ou outras tarefas durante a inferência. Estas dependências externas podem tornar-se gargalos de desempenho:

  • Latência: Meça o tempo de resposta de cada chamada de API externa. A alta latência nestas chamadas aumenta diretamente a latência global de serviço e reduz a largura de banda.
  • Limites de throughput: APIs externas podem impor limites de taxa ou restrições de capacidade. Ultrapassar estes limites pode causar estrangulamento, erros e degradação do desempenho.
  • Taxas de erro: Erros frequentes de APIs externas podem desencadear novas tentativas e aumentar a carga no endpoint de atendimento.
  • Cache: Implementar cache para dados frequentemente acedidos de APIs externas para reduzir o número de chamadas e melhorar os tempos de resposta.

Monitorize estes fatores para identificar gargalos e implementar otimizações direcionadas para cargas de trabalho de alto rendimento.

Recursos adicionais

  • Last updated on