Como é que a colocação de modelos em cache altera o tempo de resposta de um servidor de IA doméstico?

A colocação em cache do modelo altera o tempo de resposta ao permitir que pedidos repetidos reutilizem ficheiros transferidos, pesos residentes na memória, kernels compilados ou o estado do prompt processado anteriormente.

Um servidor de IA doméstico não tem uma única cache universal. O artefacto do modelo pode já existir no armazenamento local, as páginas do ficheiro podem permanecer na RAM do sistema, os pesos podem continuar carregados na memória do acelerador, o código de execução compilado pode ser reutilizável e um prompt de sistema repetido pode ainda ter um estado KV válido. Cada camada elimina uma parte diferente do percurso do pedido. As secções abaixo separam essas camadas para que uma segunda resposta rápida não seja confundida com uma geração mais rápida do modelo ou com hardware melhor.

A Colocação do Modelo em Cache Refere-se a Várias Camadas Independentes

A primeira distinção útil é perceber o que foi colocado em cache. Um checkpoint transferido evita a transferência pela rede, a cache de páginas do sistema de ficheiros evita reler alguns blocos do armazenamento, os pesos residentes evitam o carregamento do modelo, os artefactos compilados evitam trabalho de configuração e a cache de prefixos evita recalcular tokens partilhados do prompt.

A investigação sobre cache multinível trata o arranque do modelo como um movimento entre o armazenamento, a memória do anfitrião e a memória do acelerador, e não como um único estado binário frio ou quente. Um pedido pode estar quente numa camada e frio noutra.

Isto explica por que razão dizer que “o modelo está em cache” é incompleto. O servidor pode ter os ficheiros localmente, mas ainda precisar de alocar VRAM, carregar os pesos, compilar kernels e processar o prompt antes de produzir um token.

Uma Cache de Artefactos Remove o Atraso da Transferência e do Repositório

Quando os ficheiros do modelo já estão materializados no servidor doméstico, o arranque evita a autenticação, as verificações de metadados do repositório, a largura de banda remota e a transferência de fragmentos com vários gigabytes. O runtime pode começar a partir da cópia local.

A Netflix descreve a cache de artefactos do modelo como necessária, porque transferir pesos grandes durante o arranque excede a latência prática do escalonador. O mesmo mecanismo é importante em casa quando um contentor é recriado ou um modelo é iniciado após uma limpeza.

A cache de artefactos não garante um primeiro token rápido. Um checkpoint local pode continuar num disco lento, utilizar muitos fragmentos, exigir conversão ou competir com leituras e escritas no NAS.

A Cache do Sistema de Ficheiros Pode Tornar o Segundo Carregamento Muito Mais Rápido

Depois de o sistema operativo ler os ficheiros do modelo, as páginas limpas dos ficheiros podem permanecer na RAM do sistema não utilizada. Um arranque posterior pode obter esses bytes a partir da memória, em vez de voltar a esperar pelo dispositivo de armazenamento.

O MAIO melhora o arranque de LLM ao otimizar a política de cache do sistema de ficheiros utilizada durante o carregamento do modelo. Os resultados mostram por que razão dois arranques a partir do mesmo caminho NVMe podem ter tempos de leitura diferentes, dependendo das páginas do modelo que continuam em cache.

Esta cache pode ser recuperada. Cópias de segurança, disponibilização de ficheiros, bases de dados ou outro modelo podem substituir essas páginas, pelo que uma resposta rápida ontem pode voltar a ficar limitada pelo armazenamento após pressão sobre a memória ou um reinício.

Fazer testes sem definir o estado da cache de páginas mistura dois regimes de armazenamento e pode sobrestimar a melhoria obtida com uma atualização da unidade.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Os Pesos Residentes Eliminam a Maior Fronteira de Recarregamento

Manter os pesos na RAM, na memória unificada ou na VRAM permite ao runtime avançar diretamente para o processamento do prompt. Descarregar o modelo liberta capacidade para outras aplicações, mas faz com que o pedido seguinte volte a pagar o custo do carregamento.

O guia da ZimaSpace sobre residência do modelo mostra o padrão característico: um pedido lento após a expulsão, seguido de respostas normais enquanto o modelo permanece quente.

A residência altera sobretudo a prontidão e o tempo até ao primeiro token. Não aumenta necessariamente a taxa de tokens produzidos quando a geração já está a decorrer.

Manter todos os modelos residentes também pode criar a pressão sobre a memória que provoca a expulsão de outro modelo, da cache KV ou de uma aplicação do servidor doméstico.

As Caches de Compilação e de Kernels Eliminam o Trabalho da Primeira Execução

Alguns runtimes especializam kernels, capturam grafos de execução ou compilam código para o modelo ativo, a arquitetura da GPU, as dimensões dos tensores e a configuração do runtime. O primeiro pedido compatível pode realizar trabalho que os pedidos seguintes reutilizam.

Uma análise prática do arranque a frio observa que a compilação do runtime pode ocorrer entre o carregamento dos pesos e o fornecimento da primeira resposta. Uma cache de compilação persistente transfere esse custo para fora dos arranques seguintes, até que uma alteração ao modelo, ao controlador, ao runtime ou ao hardware a invalide.

Isto cria outro estado quente: os ficheiros e os pesos podem já estar presentes, mas a primeira nova dimensão ou caminho de execução pode ainda causar um pico de latência.

A Cache de Prefixos Reduz o Prefill, mas Não a Descifragem de Novos Tokens

Um prompt de sistema repetido, um documento longo ou um bloco de instruções partilhado normalmente exige que o modelo processe novamente os mesmos tokens antes de chegar à nova entrada do utilizador. Uma cache de prefixos armazena o estado de atenção reutilizável desse prefill anterior.

A investigação Prompt Cache regista uma menor latência até ao primeiro token quando os pedidos reutilizam módulos longos do prompt. O benefício aumenta com o comprimento do prefixo partilhado, porque é possível ignorar mais cálculos de prefill.

Isto não torna prompts novos arbitrários mais rápidos e não elimina o custo de descodificar novos tokens de saída. Os acertos da cache dependem da reutilização exata ou suportada do prefixo, da capacidade disponível da cache e da política de expulsão do runtime.

Meça os Percursos Frios e Quentes como Classes de Resposta Separadas

Teste um pedido fixo após um reinício, após o carregamento do modelo, após uma repetição imediata, depois de um longo período de inatividade e após uma carga de trabalho concorrente. Registe separadamente a transferência do artefacto, a leitura do armazenamento, o carregamento do modelo, a compilação, a avaliação do prompt, o primeiro token e a taxa de tokens de saída.

A análise de caches frias alerta para o facto de a latência com cache quente poder ocultar uma cauda mais lenta quando alguns pedidos não encontram a cache. Um assistente doméstico deve ser avaliado pela combinação de situações que os utilizadores realmente encontram, e não apenas por um teste repetido imediatamente.

Depois de identificar a camada que falhou, a solução torna-se específica: pré-carregar os ficheiros do modelo, preservar margem para a cache de páginas, prolongar o tempo de manutenção do modelo carregado, persistir os artefactos compilados ou ativar a reutilização de prefixos para prompts partilhados estáveis.

FAQ

Um modelo em cache utiliza sempre menos RAM?

Não. Algumas caches consomem deliberadamente RAM ou VRAM para reduzir trabalho futuro. Trocám capacidade por menor latência, em vez de reduzirem a utilização de memória.

Por que razão a primeira resposta é lenta, mas as seguintes são rápidas?

O primeiro pedido pode carregar os pesos, alocar o estado do runtime, compilar kernels ou processar um prompt longo. Os pedidos seguintes reutilizam um ou mais desses resultados.

Limpar as caches pode corrigir respostas incorretas da IA?

Pode corrigir artefactos do runtime desatualizados ou corrompidos em alguns casos, mas as caches dos modelos normalmente afetam o carregamento e a reutilização de cálculos, não a qualidade factual de pesos e prompts inalterados.