Débito da inferência do modelo Scale

Aumentar gradualmente o tráfego de modelos através do Unity Gateway ao lançar uma carga de trabalho ou mudar de modelo. Esta orientação aplica-se a modelos proprietários e de peso aberto fornecidos pelo Azure Databricks e a modelos acedidos através de fornecedores externos conectados.

Aumente gradualmente o tráfego

A capacidade disponível depende do modelo, fornecedor, região e modo de serviço. Os pedidos podem ter erros temporários de capacidade mesmo quando o tráfego se mantém dentro dos limites de taxa configurados. Um aumento de quota por si só não reserva capacidade de serviço.

Para aumentar o rendimento:

1. Verifique os limites de taxa de serviço configurados e os limites para o modelo ou fornecedor externo. Estima as taxas de tokens de entrada e saída e pedidos simultâneos, incluindo tamanhos representativos de prompt e resposta.
2. Comece num nível de tráfego estável conhecido. Para uma nova carga de trabalho, começa com uma pequena carga representativa da utilização.
3. Aumentar o tráfego em pequenos passos. Mantenha cada nível estável enquanto monitoriza a taxa de sucesso dos pedidos, latência, utilização de tokens, profundidade da fila e erros de limitação ou capacidade. Aumente novamente apenas quando a carga de trabalho estiver estável e atingir os objetivos operacionais da sua aplicação.
4. Se a limitação, os erros de capacidade ou a latência aumentarem para além da tolerância da sua aplicação, pause o aumento gradual do tráfego e volte ao último nível estável de tráfego. Reduzir a concorrência e colocar ou adiar trabalhos de menor prioridade.

Escolha o tamanho dos passos e os períodos de observação com base na sua carga de trabalho e nas orientações do modelo ou fornecedor. Repita esta validação ao alterar modelos, regiões ou capacidade de serviço.

Lidar com a limitação de débito e erros de capacidade

Inspeciona tanto o estado HTTP como o corpo de erro da API que chamas. Os códigos de erro e as mensagens podem diferir entre APIs unificadas e nativas do fornecedor.

Um erro de capacidade, por si só, não significa que o autoscaling está em curso nem indica quando a capacidade fica disponível.

Configurar tentativas

• Respeite o Retry-After cabeçalho quando a resposta o incluir. Caso contrário, tente novamente em caso de throttling transitório e de erros de capacidade com recuo exponencial e jitter aleatório.
• Limite o total de tentativas e o tempo decorrido para se ajustar ao orçamento de latência da sua aplicação. Se persistirem erros, reduza o tráfego em vez de adicionar mais tentativas.
• Verifique o comportamento de novas tentativas do SDK antes de adicionar novas tentativas de aplicação. Tenha em conta as retentativas entre camadas para que não multipliquem a carga.
• Trata os erros depois de uma resposta de streaming começar no consumidor do stream. Reproduzir um pedido após receber a saída pode duplicar a saída ou o trabalho.

Para erros persistentes, contacte a sua equipa de conta da Databricks com IDs de pedido, marcas temporais, nomes de modelos e fornecedores, taxas de tokens observadas, concorrência e a cronologia do aumento gradual de tráfego. Para fornecedores externos ligados, verifique também o estado do serviço e os limites da conta do fornecedor.

Inferência em lote

Para cargas de trabalho offline grandes com modelos suportados, use AI Functions, que gerem paralelização, novas tentativas e escalabilidade. Siga as orientações de inferência em lote em vez de aplicar um ciclo de retentativa separado a cada linha.