Porque é que o arranque a frio de um modelo de IA doméstico depende da disposição do armazenamento?

O arranque a frio de um modelo de IA doméstico depende da organização do armazenamento, porque o runtime tem de localizar, ler, descodificar, mapear e transferir todos os pesos necessários antes da inferência.

Duas cópias do mesmo modelo podem arrancar a velocidades diferentes quando uma já está em cache num NVMe local e armazenada num formato adequado ao carregamento, enquanto a outra se encontra numa partilha de rede, num sistema de ficheiros fragmentado, num arquivo comprimido ou num diretório com fragmentos mal organizados. O percurso a frio também inclui os ficheiros do tokenizador, a configuração, a inicialização do runtime, a alocação do acelerador e a primeira execução. As secções abaixo distinguem a largura de banda bruta do armazenamento da organização do checkpoint, para que os atrasos no arranque possam ser atribuídos à fase correta.

O arranque a frio é uma cadeia de fases de armazenamento e runtime

Um modelo não está pronto quando o processo simplesmente abre o primeiro ficheiro. O runtime tem de descobrir os metadados do checkpoint, criar a estrutura do modelo, ler os bytes dos pesos, desserializar ou mapear os tensores, alocar a memória de destino, transferir os dados e inicializar os kernels ou grafos de execução.

A investigação sobre inferência sem servidor identifica o carregamento durante o arranque a frio como uma parte importante do atraso antes de um serviço de LLM ficar pronto. A fase mais lenta varia consoante o tamanho e o formato do modelo, o nível de armazenamento, a memória do anfitrião e o percurso até ao acelerador.

Um SSD rápido pode reduzir o tempo de leitura, mas deixar inalterados a desserialização, as cópias efetuadas pelo CPU, a transferência para a GPU ou o aquecimento dos kernels. Meça o tempo em cada limite, em vez de tratar toda a pausa como um único teste ao disco.

A localização determina se os pesos chegam da cache, da LAN ou do disco

Os pesos armazenados num NVMe local podem ser lidos sem latência de rede ou sem a fila de outro servidor. Um modelo numa partilha SMB, NFS, num armazenamento de objetos ou num disco externo frio acrescenta transporte e comportamento de cache remota antes de o carregamento local começar.

Trabalho recente sobre modelos em cache nos nós mostra que manter artefactos grandes localmente pode tornar os arranques posteriores das réplicas muito menos dependentes de uma nova transferência remota. Num servidor doméstico, o mesmo princípio distingue uma primeira transferência de um lançamento local repetido.

Local não significa necessariamente quente. Um reinício, a expulsão da cache, uma remontagem do sistema de ficheiros ou uma leitura em massa concorrente podem obrigar o arranque seguinte a obter novamente a maioria das páginas do modelo a partir do armazenamento físico.

O artigo da ZimaSpace sobre a expulsão de modelos aborda o limite de memória relacionado: quando um modelo deixa de estar residente, o pedido seguinte tem de reconstruir o estado de execução rápido.

O formato do checkpoint controla o trabalho de desserialização e cópia

Um checkpoint pode ser um único ficheiro contíguo orientado para o carregamento, vários fragmentos de tensores com um índice, um arquivo comprimido ou uma serialização específica de uma framework que reconstrói objetos Python e metadados dos tensores.

O ServerlessLLM utiliza leituras sequenciais de checkpoints para reduzir o custo do arranque a frio. Uma organização que permita leituras diretas de grandes dimensões e uma colocação previsível dos tensores perde menos tempo com operações de metadados pequenas e reconstruções intermédias.

A fragmentação pode reduzir o pico de RAM do anfitrião, porque é processado um fragmento de cada vez, mas demasiados ficheiros pequenos aumentam as pesquisas nos diretórios, as aberturas, os posicionamentos e o processamento do índice. O melhor tamanho dos fragmentos depende do paralelismo do carregador e do sistema de ficheiros subjacente.

A compressão troca capacidade de armazenamento por trabalho adicional do CPU no arranque. Pode ajudar quando o armazenamento é muito lento, mas prejudicar o desempenho quando um SSD rápido fica à espera da descompressão e das cópias para a memória.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

O mapeamento de memória altera o momento em que as páginas entram na RAM

Um carregador ansioso pode alocar um grande buffer no anfitrião e ler todo ou quase todo o checkpoint antes de copiar os tensores para o destino. Um carregador com mapeamento de memória cria mapeamentos virtuais e permite que o sistema operativo carregue as páginas do ficheiro para a RAM à medida que são utilizadas.

A investigação e os sistemas de carregamento modernos utilizam o carregamento com mapeamento de memória para evitar duplicar todo o artefacto na memória anónima. Isto pode reduzir o pico de RAM e permitir que processos repetidos reutilizem páginas através da cache do sistema de ficheiros.

O mapeamento de memória não elimina a latência do armazenamento. Transfere as leituras para o momento das falhas de página, pelo que a primeira inferência pode continuar a bloquear se as páginas necessárias ainda não tiverem sido carregadas ou pré-obtidas.

A pré-obtenção sequencial pode ajudar um modelo que utiliza a maioria dos pesos por ordem, enquanto o acesso aleatório a especialistas ou componentes multimodais pode tornar o padrão de falhas de página menos previsível.

O carregamento paralelo só ajuda quando o percurso de armazenamento tem margem

Vários threads do carregador ou fluxos de cópia para a GPU podem sobrepor leitura, descodificação e transferência. Também podem transformar uma leitura ordenada em vários fluxos concorrentes que saturam um SSD fraco, uma ponte USB, uma partilha de rede ou o percurso de metadados do sistema de ficheiros.

Os resultados de engenharia da NVIDIA sobre transmissão concorrente de pesos mostram que o desenho do carregamento e a escolha do armazenamento determinam em conjunto a melhoria. O paralelismo é útil quando a origem e o destino conseguem sustentá-lo sem aumentar excessivamente as filas.

Um servidor doméstico pode também estar a servir multimédia, a escrever cópias de segurança, a analisar ficheiros ou a executar bases de dados no mesmo conjunto de armazenamento. Essas cargas alteram a latência do arranque a frio, mesmo que o diretório do modelo não tenha mudado.

A cache quente e a reutilização dos pesos podem dominar os arranques repetidos

O primeiro arranque depois do início do sistema pode ler todos os bytes do modelo a partir do armazenamento, enquanto o segundo beneficia da cache de páginas do sistema de ficheiros, da memória da GPU mantida ou de um runtime que conserva os pesos prontos para reutilização.

O Tangram acelera o arranque através da reutilização dos pesos na memória da GPU. A lição mais abrangente para um servidor doméstico é que “arranque a frio” tem de especificar quais as caches e os processos que foram limpos antes do teste.

Não compare um modelo imediatamente após outra execução quente com um modelo diferente depois de um reinício. Defina separadamente os estados a frio, quente no sistema de ficheiros, quente no runtime e quente no acelerador.

Avalie a organização com um teste de estado a frio repetível

Registe o tamanho do modelo, o número de ficheiros, os tamanhos dos fragmentos, o sistema de ficheiros, as opções de montagem, o dispositivo de armazenamento, o percurso de rede, o modo do carregador, a RAM do anfitrião, a memória do acelerador e a E/S concorrente. Depois, meça o tempo de descoberta dos metadados, leitura pelo anfitrião, desserialização, transferência para o dispositivo, inicialização do runtime e primeiro token.

Os estudos do FlowLoader analisam a cache local de modelos, porque a localização dos checkpoints e a sobreposição das fases do pipeline podem reduzir o arranque de segundos ou minutos. O ganho exato depende de o verdadeiro estrangulamento estar no armazenamento, nas cópias ou na inicialização.

Repita o teste depois de limpar a cache do sistema de ficheiros, após uma execução quente normal e durante tráfego representativo no NAS. A diferença resultante revela se serão úteis uma alteração da organização, um nível local mais rápido, menos fragmentos, o mapeamento de memória ou uma política de manutenção ativa.