Porque é que a latência do primeiro token dos LLM locais aumenta depois de o servidor ficar inativo?

A latência do primeiro token aumenta frequentemente após um período de inatividade, porque o pedido seguinte tem de reconstruir o estado do modelo, da memória, do acelerador e da alimentação que os pedidos em ambiente quente reutilizam.

Um servidor de IA doméstico pode responder rapidamente a pedidos repetidos e, depois, parecer lento quando o primeiro pedido chega na manhã seguinte. O modelo pode continuar a existir no disco, mas as respetivas páginas, a alocação da GPU, os kernels e o contexto de execução podem já não estar quentes. A velocidade do armazenamento, a pressão sobre a memória, a expulsão pelo runtime, a gestão de energia do dispositivo e o comprimento do prompt determinam a quantidade de atraso que regressa.

O tempo de inatividade remove vários tipos diferentes de estado quente

Um pedido quente pode reutilizar pesos já residentes na RAM ou na VRAM, páginas do sistema de ficheiros mantidas pelo sistema operativo, bibliotecas de aceleradores inicializadas, kernels compilados, pools de memória e um worker de modelo ativo. A limpeza durante a inatividade pode remover apenas uma camada ou encerrar todo o processo.

carregamento de checkpoints em vários níveis reduz o arranque de modelos serverless ao manter os checkpoints próximos dos aceleradores, carregá-los através de vários níveis de armazenamento e agendar pedidos onde o estado do modelo já está local. O seu design mostra que a latência fria é uma cadeia de transferências e passos de inicialização, e não um único valor de leitura do disco.

O atraso observável depende da camada que ficou fria. Um processo que permaneceu ativo pode precisar apenas de aumentar a frequência do dispositivo, enquanto um modelo expulso tem de ler os pesos, alocar memória do dispositivo, reconstruir as estruturas do runtime e, depois, processar o prompt antes de emitir um token.

O carregamento do modelo e o prefill acumulam-se antes de surgir qualquer token

O tempo até ao primeiro token inclui o tempo de espera na fila, a disponibilidade dos pesos, a inicialização do runtime, a tokenização e o prefill de toda a entrada. Uma taxa de descodificação elevada não consegue ocultar estas etapas, porque não existe nenhum token de saída até o prefill produzir o primeiro estado de descodificação.

reutilização da memória da GPU mantém os parâmetros na memória não utilizada da GPU e usa agendamento orientado por afinidade para reduzir transferências repetidas. As melhorias comunicadas no arranque a frio ilustram por que motivo a preservação de uma residência parcial pode ser importante, mesmo quando um serviço não consegue manter todos os modelos totalmente carregados.

Por isso, um prompt de sistema longo pode continuar lento depois de os pesos estarem quentes, enquanto um prompt curto pode continuar bloqueado pelo carregamento a frio do modelo. Separar o tempo de carregamento, a inicialização, o prefill e a primeira descodificação evita que um único valor médio de TTFT esconda o componente frio real.

A poupança de energia é normalmente uma camada menor, mas mensurável

CPUs, GPUs, dispositivos NVMe e ligações PCIe podem entrar em estados de baixo consumo durante a inatividade. O primeiro pico tem de aumentar as frequências e restaurar os caminhos ativos, acrescentando uma breve rampa antes de começar a computação sustentada; a suspensão agressiva do sistema anfitrião pode acrescentar muito mais, ao suspender serviços ou discos.

sobreposição das etapas de arranque a frio sobrepõe o carregamento do modelo, a comunicação e a computação nos arranques a frio de LLM na periferia. O trabalho demonstra que ocultar uma etapa de arranque exige coordenação com as restantes, sobretudo quando os pesos e a computação estão distribuídos por dispositivos com recursos limitados.

O erro está em atribuir todas as primeiras respostas lentas ao estado de energia. Se o atraso for medido em muitos segundos, a expulsão do modelo, as leituras do armazenamento, o arranque do contentor ou o prefill do prompt costumam dominar uma transição de frequência à escala dos milissegundos. Diagnostique a linha temporal em vez de desativar, por predefinição, toda a poupança de energia.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Separe o arranque a frio do custo do prompt frio

Envie um prompt curto fixo após 0, 1, 10, 60 e 480 minutos de inatividade. Registe a duração do processo, a residência do modelo, a utilização de RAM e VRAM, os bytes lidos, as frequências do dispositivo, o tempo na fila, a tokenização, o prefill, a primeira descodificação e o TTFT total para cada intervalo.

Compare a camada de armazenamento com o armazenamento para arranque a frio de modelos e, depois, repita o teste fixando o worker, aquecendo apenas a cache do sistema de ficheiros, mantendo apenas a RAM do anfitrião quente e alterando o comprimento do prompt. Cada execução deve alterar uma camada de estado, em vez de combinar todas as otimizações.

Considere o servidor quente apenas quando intervalos repetidos de inatividade preservarem o TTFT necessário sem privarem outros serviços de recursos. Se fixar o modelo causar pressão sobre a memória ou bloquear cargas de trabalho de prioridade superior, aceite um arranque a frio limitado e exponha-o, em vez de ocultar o compromisso.