Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Usar modelos econômicos como DeepSeek Chat, GPT-4o-mini e Gemini 2.5 Flash reduz consideravelmente os custos de API. O problema é que, com um pequeno pico de tráfego, o tempo de resposta dispara de 10 para 60 segundos. Em uma estrutura padrão de requisição HTTP síncrona, esse atraso deixa os processos de worker do servidor travados na espera, enquanto o front-end falha e exibe um erro de timeout.
Para desenvolvedores solo construindo um projeto paralelo ou lidando com um orçamento apertado, a paralisação do servidor é fatal. Por outro lado, voltar a usar modelos caros não é uma opção. É preciso construir diretamente uma arquitetura de separação assíncrona, que rompa a conexão síncrona direta entre o cliente e a LLM e entregue a saída imperfeita do modelo de forma segura ao front-end.
O servidor web nunca deve aguardar diretamente a conclusão da inferência da LLM. O ideal é usar o FastAPI como gateway de API, combinando um broker de mensagens Redis e workers distribuídos do Celery para separar completamente a recepção de requisições da operação real de inferência. Quando o usuário envia uma requisição, o servidor retorna imediatamente apenas o ID da tarefa e encerra a conexão.
Se você executar o Celery com as configurações padrão, as tarefas podem ser perdidas ou executadas duplicadamente caso o worker caia. Para lidar com o tempo de execução prolongado característico das inferências de LLM, é necessário aumentar o visibility_timeout para 3600 segundos e definir task_acks_late = True para enviar a confirmação de recebimento somente quando a tarefa for concluída com sucesso. Também é essencial configurar worker_prefetch_multiplier = 1 para evitar que um único worker agarre várias tarefas pesadas de uma só vez e cause gargalos.
