Por que é que a expulsão de modelos provoca picos de latência em servidores domésticos de IA?

A expulsão do modelo cria um pico de latência porque o modelo que tratou o pedido anterior já não está residente na memória rápida. O próximo pedido tem de recarregar os pesos, restaurar o estado do runtime e processar o prompt antes que a geração normal de tokens possa começar. Uma vez que o modelo está quente novamente, os pedidos seguintes podem parecer rápidos.

Se o seu assistente de IA doméstico responde rapidamente durante uma conversa ativa, mas pausa após estar inativo, mudar de modelo ou partilhar a GPU com outro serviço, o modelo em si pode não ser lento. A questão útil é se o tempo está a ser gasto a carregar o modelo ou a gerar a resposta. Essa distinção determina o que deve ser alterado.

A expulsão do modelo altera o primeiro pedido, não todos os pedidos

Um runtime de inferência local mantém os pesos do modelo na memória GPU, memória unificada ou RAM do sistema enquanto o modelo está ativo. A expulsão ocorre quando o runtime remove parte ou todo esse estado residente. Pode fazê-lo após um tempo de inatividade, quando outro modelo precisa da mesma memória ou quando o serviço reinicia.

Um pedido quente pode passar diretamente para o processamento do prompt porque os pesos já estão disponíveis para o motor de inferência. Um pedido após expulsão segue um caminho mais longo: localizar os ficheiros do modelo, ler os pesos, colocá-los no nível de memória necessário, inicializar o caminho de execução e depois avaliar o prompt.

É por isso que a expulsão geralmente aparece como uma pausa isolada em vez de uma redução permanente nos tokens por segundo. A primeira resposta após um período de inatividade é lenta, enquanto o segundo pedido ao mesmo modelo é normal. Se todos os pedidos permanecerem lentos, o gargalo é mais provavelmente a geração, descarregamento da CPU, largura de banda da memória, enfileiramento ou limites térmicos.

Latência de IA é toda a cadeia, não apenas a velocidade de geração

Os utilizadores frequentemente descrevem toda a espera como “latência de inferência”, mas um pedido de IA local tem várias etapas. Pode esperar numa fila, carregar um modelo, processar o prompt de entrada e gerar tokens de saída. Um servidor pode, portanto, reportar uma velocidade de geração saudável e ainda assim parecer não responsivo antes do primeiro token aparecer.

A expulsão do modelo aumenta principalmente o tempo até o primeiro token. Não altera necessariamente a velocidade dos tokens que se seguem. Por isso, um benchmark de tokens por segundo sozinho pode não detectar o problema: o benchmark pode começar depois de o carregamento já ter terminado ou pode reutilizar um modelo que permaneceu quente.

Quando o runtime expõe campos de temporização, compare-os em vez de confiar na sensação. Temporizações separadas de carga do modelo e avaliação mostram se o atraso ocorre antes do processamento do prompt ou durante ele. Um componente de carga grande no primeiro pedido e um pequeno no seguinte é uma forte evidência de um modelo frio em vez de uma decodificação lenta.

Por Que os Servidores de IA Domésticos Despejam Modelos

A causa mais simples é uma política de inatividade. Um runtime liberta modelos inativos para que a memória possa voltar ao sistema operativo ou a outras aplicações. No Ollama, os modelos permanecem carregados por cinco minutos por defeito, enquanto as configurações de keep-alive podem prolongar a residência. Uma pausa que segue consistentemente o mesmo intervalo de inatividade aponta para a política em vez de hardware com falha.

A pressão de memória cria um padrão menos previsível. Dois modelos de linguagem, um modelo de incorporação, um gerador de imagens ou um serviço de vídeo podem competir pela RAM ou VRAM. Sistemas que partilham um servidor entre Plex e IA local são especialmente vulneráveis porque uma transcodificação ou trabalho em segundo plano pode deslocar um modelo mesmo que o serviço de IA em si não esteja inativo.

A troca de modelos pode causar a mesma instabilidade. Se apenas um modelo grande cabe confortavelmente, pedir o Modelo B pode forçar a saída do Modelo A. Voltar ao Modelo A então desencadeia outro carregamento. O servidor parece aleatoriamente lento, mas os picos seguem na verdade a ordem em que os modelos são usados.

Reinícios são outro limite. Uma atualização do contentor, falha do serviço, reinício do anfitrião ou paragem manual limpa o estado residente independentemente do valor de keep-alive. O primeiro pedido após esse evento é um arranque a frio por design. Tratar isso como um erro de despejo pode levar a configurações agressivas que consomem memória sem melhorar a operação normal.

Onde o Atraso de Despejo se Acumula

O primeiro custo é mover o modelo. Carregar os pesos do modelo na memória da GPU normalmente requer lê-los do armazenamento para a memória da CPU antes de os transferir para a GPU. Ficheiros maiores e caminhos de armazenamento mais lentos prolongam essa parte da espera.

O caminho dos dados é tão importante quanto o rótulo da unidade. Os pesos podem atravessar o armazenamento, a memória do sistema e um caminho PCIe ou de memória unificada antes de a inferência começar. Durante essa transferência, a largura de banda limitada da memória pode aumentar a latência da IA, especialmente quando outra carga de trabalho está a mover grandes quantidades de dados ao mesmo tempo.

Carregar os bytes nem sempre é o fim do caminho frio. Dependendo do runtime, o servidor pode também criar um contexto GPU, alocar pools de memória, preparar kernels ou capturar gráficos de execução. Sistemas que preservam o estado CUDA inicializado podem acordar mais rápido do que um reinício completo porque esses passos de configuração não têm de ser todos repetidos.

O prompt precisa então de ser avaliado novamente. A evicção normalmente descarta o cache ativo do modelo, por isso um prompt de sistema longo, contexto recuperado ou histórico de chat deve passar pelo pré-preenchimento antes do primeiro novo token aparecer. Esse atraso não é o carregamento do peso, mas os utilizadores experienciam ambos os custos como uma pausa silenciosa.

O que Diferentes Padrões de Latência Geralmente Significam

O padrão de temporização revela mais do que um único teste de velocidade. Compare quando ocorre a pausa, qual métrica cresce e o que acontece no pedido imediato repetido.

A assinatura de evicção mais característica é a primeira linha: um pedido caro seguido de respostas normais do mesmo modelo. As outras linhas impedem que fixe um modelo na memória quando o problema real está noutro ponto do caminho do pedido.

Como Testar se a Evicção é a Causa

Comece com um modelo e um prompt fixo. Envie o prompt duas vezes com apenas uma pequena pausa, depois repita o teste após o servidor estar inativo tempo suficiente para ultrapassar a sua política atual de descarregamento. Mantenha o comprimento do prompt e as configurações do modelo inalterados para que a comparação isole a residência.

Registe o tempo total de resposta, tempo de carregamento do modelo, tempo de avaliação do prompt e tempo de geração onde o tempo de execução os expõe. Se apenas o tempo de carregamento aumentar após o período de inatividade, a evidência aponta para expulsão. Se a avaliação do prompt crescer, o comprimento do contexto ou a reutilização do cache são pistas melhores.

Monitorize a memória ao mesmo tempo. Um modelo deve aparecer na RAM ou VRAM após o primeiro pedido e permanecer lá durante o teste de aquecimento. Se a sua pegada desaparecer antes do pedido lento, tem confirmação direta de que o tempo de execução ou outra carga de trabalho o libertou.

Finalmente, altere uma condição. Prolongue o tempo de manutenção, pare temporariamente serviços GPU concorrentes ou pré-carregue o modelo antes do pedido de teste. Um diagnóstico real de expulsão deve responder à alteração. Se a latência permanecer inalterada, volte a estrangulamentos de computação, memória, armazenamento ou rede em vez de assumir que o modelo foi descarregado.

Configurações práticas que reduzem picos de expulsão

Manter o modelo que serve pedidos interativos residente durante um período que corresponda ao uso real. Um assistente doméstico usado a cada poucos minutos pode beneficiar de uma janela de manutenção mais longa. Um modelo grande usado uma vez por dia pode não beneficiar. A configuração deve proteger o caminho crítico, não transformar cada modelo descarregado em consumo permanente de memória.

Deixar margem real de memória. A VRAM instalada não é idêntica à memória disponível para os pesos do modelo porque o ecrã, o tempo de execução, o cache de contexto e outras aplicações também a consomem. Verificar a memória usada e restante com nvidia-smi permite medir a VRAM livre real antes de escolher o tamanho do modelo e a quantização.

Reduzir o conjunto de trabalho residente quando o modelo ativo mal cabe. Uma quantização menor, um limite de contexto mais curto ou um modelo predefinido mais pequeno podem criar margem suficiente para evitar a expulsão rotineira. As escolhas de modelo e contexto devem seguir os requisitos de RAM e acelerador da carga de trabalho, e não apenas a contagem de parâmetros.

Controlar a troca de modelos. Direcionar pedidos comuns para um modelo predefinido e reservar um modelo especialista maior para tarefas que justifiquem a recarga. Se vários modelos tiverem de permanecer disponíveis, verifique se os seus pesos combinados, caches e sobrecarga de execução se ajustam, em vez de aumentar cegamente o limite de concorrência.

Use armazenamento local rápido para ficheiros de modelo e pré-carregue o modelo interativo após uma reinicialização planeada. Um armazenamento mais rápido não pode eliminar o trabalho de inicialização ou pré-preenchimento do prompt, mas pode encurtar a fase de transferência. O pré-carregamento move esse custo para um momento controlado em vez de fazer a primeira pessoa que faz uma pergunta esperar por ele.

Quando a Expulsão Continua a Ser a Troca Certa

A expulsão não é automaticamente um erro. Num servidor doméstico com memória limitada, evita que uma carga de trabalho ocasional de IA monopolize recursos necessários para partilha de ficheiros, contentores, serviços multimédia ou outro modelo. O servidor abdica do tempo de ativação instantâneo em troca de capacidade e estabilidade.

A política correta segue a carga de trabalho. Mantenha um assistente frequentemente usado e sensível à latência ativo. Permita que modelos em lote, modelos de imagem e experiências raramente usadas descarreguem. Se dois modelos interativos se substituem constantemente, as escolhas duráveis são modelos mais pequenos, mais memória ou aceleradores separados — não um valor infinito de manutenção ativa.

Um limite prático é a frequência de repetição. Se os utilizadores normalmente regressam antes do modelo descarregar, prolongar a residência elimina atritos visíveis a um custo modesto de memória. Se os pedidos estiverem separados por horas e a máquina tiver outros trabalhos, aceitar um arranque a frio pode ser o design de sistema mais limpo.

Perguntas Frequentes

A expulsão do modelo torna as respostas da IA piores?

A expulsão altera a prontidão, não os pesos do modelo armazenados. Recarregar o mesmo modelo com o mesmo prompt e definições não deve reduzir a sua capacidade. No entanto, uma conversa descartada ou cache de prefixo pode alterar a quantidade de contexto que deve ser processada novamente, e o estado da aplicação em falta pode afetar a continuidade se não tiver sido armazenado separadamente.

Um disco NVMe mais rápido pode eliminar o pico de latência?

Pode encurtar a fase de leitura dos pesos, especialmente quando o caminho de armazenamento anterior era lento ou ocupado, mas não pode eliminar a configuração da GPU, a alocação de memória, a preparação do kernel ou o pré-preenchimento do prompt. Se o armazenamento for apenas uma pequena parte do tempo de carregamento medido, uma atualização para NVMe não eliminará toda a pausa.

Deve cada modelo local permanecer carregado?

Não. Fixar todos os modelos pode criar a mesma pressão de memória que causou a instabilidade, ao mesmo tempo que reduz a capacidade para caches e outros serviços. Mantenha o pequeno conjunto de modelos sensíveis à latência ativos, deixe que modelos ocasionais descarreguem e confirme a pegada combinada residente sob a carga real do servidor.

A regra mais simples é comparar o primeiro pedido com a repetição imediata. Uma grande diferença no tempo de carregamento indica expulsão; uma geração lenta em ambos os pedidos aponta para outro problema. Meça esse limite primeiro, depois ajuste a residência, o tamanho do modelo e os recursos partilhados conforme os utilizadores do modelo realmente precisam de sentir a resposta imediata.