O que causa picos de latência no primeiro token depois de um serviço de IA local mudar de modelo?
A latência do primeiro token aumenta normalmente depois da troca de modelo, porque o modelo recém-selecionado tem de reconstruir o estado residente antes de poder processar o prompt.
Um servidor de IA doméstico pode responder rapidamente com um modelo aquecido, mudar para um modelo de visão ou de programação e, depois, fazer uma pausa antes do primeiro token. O atraso pode incluir a leitura dos pesos, a desquantização, a transferência para o dispositivo, a compilação de kernels, a captura do grafo CUDA, a alocação de cache e o prefill do prompt. A etapa dominante depende do armazenamento, da memória disponível do acelerador, da política do runtime e de o modelo anterior ter sido totalmente removido ou não.
O carregamento a frio dos pesos é a primeira família de causas
Se o modelo seguinte não estiver presente na RAM ou na VRAM, o servidor tem de ler um ou mais fragmentos do checkpoint, validá-los ou mapeá-los, construir tensores e transferir os pesos utilizáveis para o dispositivo de execução. Um ficheiro maior ou um caminho NAS mais lento prolonga a pausa antes de a inferência poder começar.
As medições da latência de arranque a frio de LLM mostram que o arranque pode dominar o TTFT quando o estado do modelo está frio. Este sintoma manifesta-se como leituras intensas do armazenamento e tempo do carregador do modelo antes de serem executados kernels de prefill do prompt. Esta distinção continua visível durante os testes domésticos posteriores.
Se a troca entre dois modelos que permanecem ambos residentes produzir o mesmo aumento, o carregamento dos pesos não é a explicação completa. A observação distintiva é saber se os bytes lidos e o estado dos modelos residentes mudam com o pedido lento.
A inicialização do runtime cria um segundo percurso a frio
Um modelo carregado pode continuar operacionalmente frio. O runtime pode inicializar um contexto do dispositivo, selecionar kernels, compilar formas, capturar grafos, alocar blocos KV ou criar caches do tokenizador e do modelo de prompt no primeiro pedido após a ativação.
Uma análise de engenharia sobre streaming e aquecimento de modelos separa o streaming do armazenamento da inicialização e do aquecimento. A assinatura desta etapa é uma E/S de checkpoint moderada, seguida de compilação, alocação ou atividade do acelerador antes do processamento do prompt. O resultado intermédio tem de continuar a ser inspecionável antes de a automatização avançar.
A forma do modelo, o backend de quantização, o limite de contexto, os perfis de batch e o estado do controlador determinam quais os artefactos que podem ser reutilizados. Voltar rapidamente ao modelo anterior pode ser rápido se os caches tiverem sobrevivido, enquanto uma remoção por pressão de memória volta a tornar o mesmo percurso frio.
O enfileiramento e o prefill podem parecer um atraso de carregamento do modelo
O pedido de troca pode ficar à espera do encerramento do modelo, da recuperação de memória, de outro utilizador ou de um prompt longo. Depois de admitido, o prefill processa todos os tokens de entrada antes da descodificação, pelo que históricos maiores aumentam o TTFT sem alterar o tempo de carregamento do modelo. Essa fronteira deve ser medida separadamente em condições de funcionamento realistas.
O design de serving com admissão de cache KV paginada explica como as sequências ativas consomem blocos KV paginados e como a admissão depende da capacidade de cache disponível. Uma troca que altere as reservas de cache pode, portanto, modificar o tempo de espera na fila independentemente do tamanho do checkpoint.
A fronteira da falha é um modelo aquecido e residente, com inicialização estável, e um aumento de latência que acompanha o comprimento do prompt ou a concorrência. Nesse caso, a troca de modelo é apenas uma correlação; o prefill ou o agendamento é a causa direta.
Divida o TTFT em carregamento, aquecimento, fila e prefill
Reproduza prompts fixos enquanto regista a remoção do modelo, os bytes do checkpoint, o débito do armazenamento, a transferência do anfitrião para o dispositivo, a criação do contexto do dispositivo, a compilação de kernels, a captura do grafo, a alocação de KV, o tempo de espera na fila, a duração do prefill e o primeiro passo de descodificação num único relógio monotónico. A consequência prática surge quando várias fontes competem por um contexto limitado.
Compare o rastreio com o encaminhamento de modelos por memória e, em seguida, teste separadamente a troca a frio, a troca imediata de volta, o encaminhamento com dois modelos residentes, um prompt curto e um prompt longo. Preserve a amostragem, o cliente e a concorrência para que apenas o estado pretendido seja alterado. Esta dependência deve continuar explícita na interface final.
Atribua o aumento à primeira etapa que se expande. Mantenha os pesos residentes quando o carregamento for dominante, persista artefactos compatíveis quando a inicialização for dominante e altere a política de admissão ou de contexto quando o enfileiramento ou o prefill - e não a própria troca - determinar o TTFT.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
O que causa ciclos de reconexão do WebSocket numa interface de IA doméstica remota?
Diagnostique os ciclos de WebSocket nas camadas de handshake, proxy, autenticação, heartbeat, percurso da rede, recuperação de sessão e recuo do cliente.
O que faz com que as somas de verificação das cópias de segurança não coincidam após uma transferência interrompida?
Rastreie discrepâncias nas somas de verificação através de instantâneos de origem, manifestos de blocos, deslocamentos de retoma, ficheiros parciais, transformações, gravações no armazenamento e...
O que causa entidades domésticas duplicadas num grafo de conhecimento privado?
Diagnostique nós duplicados do grafo de conhecimento separando variantes de extração, chaves de identidade, limiares de resolução, linhagem da fonte e fusões concorrentes.
