Em 21 de agosto, a equipe de infraestrutura Ling da Ant, junto com a Alibaba e a equipe do SGLang, apresentou no blog da LMSYS um componente chamado Weight Cache Daemon: um processo residente na memória da GPU que mantém os pesos já quantizados e fatiados, permitindo que um novo mecanismo de inferência os mapeie com cópia zero via CUDA IPC. Segundo os números divulgados pela equipe, o carregamento dos pesos FP8 do Ling-2.6-1T cai de cerca de 495 segundos para 0,63 segundo, e o início completo passa de 8,8 minutos para 0,528 minuto.
Oito dos oito minutos e meio são gastos lendo o disco
A equipe decompôs um ciclo completo de inicialização e mediu cada etapa. O Ling-2.6-1T FP8 roda em 8 GPUs H20-3e, com os pesos armazenados em um SSD NVMe de 3,5 TB; do início até estar pronto para atender requisições, o processo leva cerca de 527 segundos. Desse total, o carregamento dos pesos consome 495 segundos, ou 93,9%; a inicialização do tokenizador leva 13 segundos, a inicialização distribuída do torch 5 segundos, a captura do CUDA graph 7,7 segundos, e o restante soma menos de 6 segundos.
Cada GPU precisa ler do disco cerca de 120 GB de safetensors, desserializar, fatiar conforme o paralelismo de tensores e depois aplicar quantização FP8 e reorganizar os pesos, totalizando 161 fragmentos. Esse pipeline roda do zero a cada reinício, mas seu resultado é determinístico: com o mesmo modelo e a mesma configuração, os tensores que acabam na memória são sempre os mesmos — e muitas vezes ainda estão lá logo depois que o processo anterior é encerrado.
Em produção, esses minutos significam um salto acentuado na latência de cauda P99 durante o reinício, requisições em andamento falhando por completo ou ficando em fila indefinidamente, e atualizações contínuas e recuperação de falhas travadas por esse mesmo ciclo.
Os pesos ficam na memória da GPU
Cada GPU executa um processo daemon, um por TP rank. Ele carrega os pesos uma vez seguindo o pipeline completo a partir do disco e depois exporta todos os parâmetros e buffers de model.state_dict() como handles de CUDA IPC, entregues via socket Unix aos processos do mecanismo que se conectam. O mecanismo primeiro monta a estrutura do modelo no meta device, sem alocar memória, e então faz o ponteiro data de cada parâmetro apontar para o tensor mapeado. Os dois processos compartilham a mesma memória física, sem nenhuma cópia. Parâmetros de pós-processamento gerados durante a quantização FP8, como weight_scale, também são armazenados em cache, eliminando a necessidade de requantizar.
Duas camadas de segurança foram implementadas. A primeira é uma impressão digital de configuração: o caminho do modelo, o particionamento TP/PP/DP, o método de quantização com o hash de configuração e o dtype precisam coincidir, além de registrar a capacidade de computação da GPU e a versão do torch como marcas de ambiente. A razão é que arquiteturas ou versões do torch diferentes seguem caminhos de pós-processamento diferentes: os pesos podem ser mapeados sem erro, mas gerar resultados sem sentido. Ao incluir o ambiente na impressão digital, esse erro silencioso se torna uma incompatibilidade explícita, que faz o sistema recuar para o carregamento a partir do disco.
A segunda camada é uma lista de permissões para métodos de quantização. Por enquanto, só sem quantização e block-wise FP8 estão verificados; per-tensor FP8, Marlin e AWQ/GPTQ geram erro imediato. O motivo é que o IPC exporta apenas os dados brutos do tensor, enquanto esses métodos deixam parte do efeito em metadados do lado Python, ou reorganizam e transpõem os pesos — o mapeamento resultaria em valores incorretos. A equipe optou por falhar de forma explícita em vez de entregar silenciosamente um resultado errado.
Se o daemon falhar, o mecanismo já em execução não é afetado: a contagem de referências do CUDA continua ativa, e a memória só é liberada quando ambos os lados terminam. Quando o daemon reinicia, ele volta a ler do disco e a exportar os handles, e só então um novo mecanismo pode se conectar.
De quebra, resolve a conta do hot standby
O componente tem três modos: daemon (o próprio mecanismo inicia o daemon; o primeiro início continua lento), client (conecta-se a um daemon já em execução, com reinício em menos de um segundo) e off (padrão, passa pelo disco; no Ling-2.6-1T leva de 405 a 411 segundos).
Mais relevante do que a aceleração do início são alguns padrões de implantação. Várias instâncias do mecanismo na mesma GPU mapeiam o mesmo conjunto de pesos: o disco é lido uma única vez e a quantização é feita uma única vez. Um serviço online de alta prioridade e um processamento em lote offline de baixa prioridade compartilham uma GPU; quando o segundo é desalojado, ele volta a subir em menos de um segundo. Na comutação entre primário e backup, o mecanismo de standby se conecta com cópia zero ao mesmo conjunto de pesos e permanece "quente"; se a instância principal cair, o backup assume o controle em até 1 segundo.
Esse último ponto é um item de custo evidente. Em números aproximados: uma instância do Ling-2.6-1T ocupa 8 GPUs H20-3e; um hot standby tradicional significa manter mais 8 GPUs ociosas ao lado. Trocando por um backup de pesos compartilhados, elimina-se justamente esse grupo de GPUs permanentemente reservado. O mesmo vale para atualizações contínuas: estimando cerca de 8,8 minutos por ciclo, cada instância queima cerca de 1,2 hora-GPU ociosa a cada rodada de reinício, e em um cluster com centenas de instâncias, uma única rodada de atualização soma horas-GPU na casa das centenas.
Ainda não chegou ao fim
O Weight Cache Daemon é a primeira fase do Fast Engine Recovery Framework. O roteiro prevê inicializações a frio abaixo de 10 segundos e comutações de hot standby abaixo de 1 segundo. Em seguida, estão planejadas a serialização do CUDA graph, o cache de kernels e a otimização da inicialização distribuída. Pela decomposição apresentada acima, esses itens somam cerca de 26 segundos, que é justamente o maior bloco restante depois dos pesos.
Também foram divulgados números para a categoria Qwen3-235B FP8: cerca de 235 GB de pesos, de 306 a 327 segundos para carregar do disco, menos de um segundo com o mapeamento IPC — uma diferença de cerca de 500 vezes. No Ling-2.6-1T, essa diferença é de cerca de 780 vezes.
O blog também menciona de passagem o recém-lançado Kimi K3, de 2,8 trilhões de parâmetros. Conforme o número de parâmetros cresce, o tempo de carregamento a partir do disco cresce praticamente de forma linear, enquanto o mapeamento por IPC permanece quase constante — e essa diferença só tende a aumentar. Para equipes que já operam modelos na escala de trilhões de parâmetros, o custo de um reinício está deixando de ser "esperar alguns minutos" para se tornar "quase sem espera nenhuma", e isso afeta não só os números de disponibilidade, mas também a disposição de mudar configurações com frequência e de colocar dois serviços na mesma GPU.
Fontes: blog técnico da LMSYS Org, CocoLoop, documentação do projeto SGLang; a decomposição do tempo de inicialização e os números comparativos de carregamento de pesos versus mapeamento IPC vêm da tabela de benchmark de nó único publicada pela equipe.