Um serviço de IA local pode mudar para a CPU quando a memória da GPU estiver cheia?

Sim, mas uma comutação fiável para a CPU tem de ser concebida antes de a memória da GPU ficar cheia; a maioria dos processos de inferência não recupera de forma transparente de um OOM inesperado.

Um servidor de IA doméstico pode responder rapidamente através da GPU até que um prompt mais longo, um lote maior, um pedido de imagem ou um segundo modelo consuma a VRAM restante. A alocação seguinte pode falhar mesmo quando a RAM do sistema e a CPU estão inativas. A sobrevivência do pedido depende do runtime: alguns conseguem colocar os pesos na CPU desde o início, enquanto outros precisam de um worker de CPU separado e de um router que repita o pedido em segurança.

O Descarregamento para a CPU e a Comutação para a CPU Resolvem Problemas Diferentes

O descarregamento para a CPU é uma estratégia de colocação do modelo. Camadas, tensores ou componentes do pipeline selecionados ficam na RAM do sistema e são transferidos para o acelerador quando necessário, reduzindo a VRAM necessária para um pedido normal. A comutação para a CPU é um comportamento do serviço: quando o caminho da GPU fica indisponível ou rejeita um pedido, outro worker aceita-o e executa um modelo compatível com a CPU sem perder o trabalho.

O Hugging Face Accelerate disponibiliza métodos de descarregamento para a CPU que movem deliberadamente o estado do modelo entre a memória da CPU e um dispositivo de execução. Trata-se de uma execução heterogénea planeada, não de uma resposta de emergência depois de um estado CUDA arbitrário ter falhado. O modelo, o mapa de dispositivos, os hooks e o orçamento de memória são preparados antes do início da inferência.

Um modelo parcialmente descarregado pode já estar a utilizar a CPU e, ainda assim, depender da GPU para cada token. Se a GPU falhar, esse processo pode não conseguir continuar na CPU a partir do token interrompido. A verdadeira comutação normalmente reinicia o pedido num worker preparado para a CPU. Esta distinção explica por que motivo uma aplicação pode anunciar suporte para CPU e, ainda assim, devolver um erro de OOM em vez de concluir o pedido atual.

A VRAM Pode Ficar Cheia Depois de um Modelo Carregar com Êxito

Os pesos do modelo são apenas uma parte do orçamento de memória. A cache de chave-valor cresce com o comprimento da sequência ativa e a simultaneidade, os kernels temporários precisam de espaço de trabalho, os codificadores de imagem ou áudio adicionam tensores e um alocador de memória pode reservar blocos para reutilização. Por isso, um modelo que cabe no arranque pode falhar com um contexto longo ou com vários utilizadores em simultâneo.

O PyTorch utiliza um alocador de memória com cache, pelo que a memória indicada como reservada não é idêntica à memória dos tensores ativos. A fragmentação e as alocações feitas fora da framework podem reduzir ainda mais a margem disponível. Um acionador de comutação deve monitorizar alocações rejeitadas e o estado dos workers, não inferir segurança a partir de um único número num painel ou do facto de o carregamento do modelo ter sido concluído.

É também por isso que uma regra estática do tipo “o tamanho do modelo é inferior à VRAM” é incompleta. Um serviço pode definir um limite de contexto mais baixo, limitar as sequências simultâneas ou deixar uma percentagem da VRAM livre para proteger as alocações do runtime. Estes controlos evitam mais falhas do que uma mudança reativa para a CPU, porque mantêm o processo da GPU num estado conhecido e preservam uma latência previsível para os pedidos aceites.

A Repetição Automática Só É Segura Quando o Pedido Pode Ser Reproduzido

Depois de um OOM, o router pode marcar o worker da GPU como não íntegro, libertá-lo ou reiniciá-lo e repetir o pedido original num worker de CPU. Isto funciona para a geração de texto normal quando não ocorreu nenhum efeito externo. É mais difícil no caso de respostas em streaming, pipelines de imagem com sementes aleatórias ou agentes que possam já ter chamado uma ferramenta.

As frameworks também podem distribuir modelos grandes por dispositivos desde o início. A inferência de modelos grandes do Accelerate suporta mapas de dispositivos e a colocação na CPU ou no disco quando um modelo excede a capacidade de um dispositivo. Esta abordagem pode manter um pedido ativo dentro de um único grafo de execução planeado, mas troca velocidade por capacidade e não deve ser confundida com o encaminhamento de um pedido falhado para um serviço separado.

A alegação de comutação deixa de se aplicar quando a CPU não tem RAM suficiente, o runtime não dispõe de kernels compatíveis com a CPU, o pedido já produziu uma ação irreversível ou a latência esperada na CPU excede o tempo-limite do cliente. Nesses casos, devolva um erro de capacidade controlado ou coloque o pedido numa fila. Repetir silenciosamente pode duplicar efeitos secundários ou deixar os utilizadores à espera muito mais tempo do que a interface promete.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Comprove a Comutação com um Teste de Memória Deliberado

Execute um worker de GPU e um worker de CPU atrás de um router e envie um pedido que exceda o perfil da GPU sem exceder a RAM do sistema. Registe a primeira falha, a decisão de repetição, a hora de início na CPU, o resultado final e se a ligação do cliente se mantém. Repita primeiro com o streaming desativado e, em seguida, teste o cancelamento, o tráfego simultâneo e um pedido de agente com uma ferramenta simulada.

A execução parcial na GPU é uma referência útil, porque runtimes como o llama.cpp podem colocar uma parte configurável do trabalho do modelo nos aceleradores, mantendo a execução na CPU. Compare perfis residentes na GPU, de divisão CPU/GPU planeada e de recurso independente na CPU. Um modelo de carga de trabalho de IA híbrida ajuda a distinguir o recurso de capacidade do encaminhamento normal para a cloud.

Considere o design fiável apenas se a repetição for concluída uma vez, preservar a identidade do pedido, evitar ações duplicadas de ferramentas e restaurar o worker da GPU sem interromper trabalhos não relacionados. Se a conclusão na CPU for demasiado lenta, utilize-a como um caminho de segurança que preserva a fila, e não como um equivalente interativo. O objetivo operacional é uma degradação controlada, não fingir que os níveis de serviço da CPU e da GPU são intercambiáveis.

Perguntas frequentes

Libertar a cache da GPU cria um mecanismo de comutação?

Não. A libertação da cache pode disponibilizar blocos reservados não utilizados, mas não cria execução na CPU, não repara um estado de pedido corrompido nem garante memória contígua suficiente para a próxima alocação.

A alternativa na CPU produzirá a mesma resposta?

Pode produzir, quando são utilizados os mesmos pesos, precisão, prompt, tokenizador e estado de amostragem. Kernels, quantização, sementes ou um estado de streaming reiniciado diferentes podem, ainda assim, alterar o resultado exato.

Um modelo mais pequeno é melhor do que a comutação para a CPU?

Muitas vezes, no caso de um serviço interativo. Um modelo de GPU mais pequeno pode proporcionar uma latência previsível, enquanto a comutação para a CPU protege a disponibilidade para pedidos excecionais. Os dois mecanismos resolvem objetivos de serviço diferentes e podem ser combinados.