Resumo Técnico: Concordia: JIT-Compiled Persistent-Kernel Checkpointing para Inferência de LLM com Tolerância a Falhas

1. Declaração do Problema

Agentes de Grandes Modelos de Linguagem (LLM) de longa duração mantêm um estado substancial em GPUs, incluindo caches KV, escalonadores de requisições, estados de comunicação e adaptadores online. Diferente da inferência tradicional sem estado, essas cargas de trabalho acumulam minutos ou horas de computação. Uma falha em um rank de GPU, comunicador ou kernel de aplicação pode destruir esse estado, tornando a sessão irrecuperável sem reiniciar toda a pilha de serviço, recarregar pesos do modelo e reexecutar chamadas de ferramentas — um processo que é frequentemente semanticamente impossível uma vez que interações externas ocorreram.

Os mecanismos de recuperação existentes enfrentam um compromisso fundamental:

• Logging específico de aplicação: Requer a modificação de cada kernel de atenção, alocador e biblioteca para registrar atualizações de KV explicitamente. Isso é frágil em stacks modernas que envolvem bibliotecas fundidas (fused), kernels de fornecedores e compiladores de grafos dinâmicos.
• Checkpointing mediado pelo host: Depende da CPU para lançar kernels de checkpoint ou escanear a memória da GPU. Isso introduz alta latência devido a transferências PCIe e comparações de páginas no lado da CPU, além de colocar o host no caminho crítico durante a recuperação, impedindo que a GPU execute enquanto o host orquestra a recuperação.

O artigo argumenta que a tolerância a falhas para essas cargas de trabalho requer um contexto de execução residente na GPU que possa observar kernels binários, realizar detecção de páginas sujas (dirty-page detection) na largura de banda de HBM e executar lógica de recuperação sem intervenção do host.

2. Metodologia: O Runtime Concordia

Concordia é um sistema de runtime projetado para interpor-se no carregamento de módulos de GPU e fornecer um substrato persistente, residente no dispositivo, para tolerância a falhas. Sua arquitetura consiste em quatro mecanismos principais:

2.1 Executor de Kernel Persistente

A base do Concordia é um kernel persistente que roda durante todo o ciclo de vida de uma sessão de LLM.

• Operação: Ele monitora continuamente um buffer circular livre de travas (lock-free) em memória mapeada pelo host.
• Tarefas: Executa tarefas de computação, checkpoint, comunicação e recuperação sem exigir novos lançamentos de kernels CUDA pelo host.
• Pegada de Recurso: Reserva um número mínimo de Multiprocessadores de Fluxo (SMs) (ex: 1 bloco em uma RTX PRO 6000, ~0,53% de pegada de SM), deixando o restante da GPU disponível para kernels de aplicação.
• Caminho de Controle: Atua como um loop de controle confiável. Se os kernels de aplicação ou comunicadores falharem, o worker persistente permanece vivo para orquestrar a recuperação até que o dispositivo seja declarado perdido.

2.2 Instrumentação PTX/SASS e Compilação JIT

O Concordia instrumenta binários de GPU para expor pontos de checkpoint seguros e gerar handlers especializados.

• Instrumentação: Intercepta chamadas cuModuleLoad. Para módulos PTX, ele reescreve o código para inserir ganchos (hooks) de pausa cooperativa e checkpoint na entrada, saída e locais de barreira. Para kernels apenas binários (SASS), aplica patch conservador para redirecionar a execução através de stubs de trampolim.
• Handlers JIT-Compilados: Para cada região de memória registrada (ex: blocos de PagedAttention KV, adaptadores LoRA, buffers opacos), o Concordia compila via JIT um handler de delta-checkpoint especializado.
  • Regiões KV: Handlers escaneiam tabelas de blocos físicos e bitmaps de páginas sujas fornecidos pelo runtime de serviço.
  • Regiões de Adaptador/Operação: Handlers realizam varredura de páginas densas ou comparação de sombra (shadow-compare) contra cópias residentes na GPU.
• Hot-Swapping: Esses handlers são compilados via NVRTC e inseridos na tabela de operadores do kernel persistente, permitindo atualizações dinâmicas sem interrupção do serviço.

2.3 Delta Checkpointing no Lado da GPU

Em vez de snapshots completos, o Concordia realiza delta checkpointing diretamente na GPU.

• Processo: Nas fronteiras de kernel ou de coletivos NCCL, o kernel persistente executa o handler JIT-compilado para identificar páginas sujas na largura de banda de HBM (~1,8 TB/s).
• Logging: Apenas páginas sujas e metadados são anexados a um log de Arquivo de Somente Adição (AOF - Append-Only File) armazenado em memória CXL visível pela CPU ou DRAM do host.
• Exploração de Estrutura: O sistema explora a estrutura do estado do LLM: pesos base são estáticos (imutáveis), enquanto caches KV e adaptadores mudam de forma esparsa. Isso permite que o sistema evite registrar cada atualização e, em vez disso, detecte mudanças de forma eficiente.

2.4 Recuperação e Tolerância a Falhas

• Modelo Fail-Stop: O Concordia assume que kernels de aplicação ou comunicadores podem falhar, mas o worker persistente é confiável. Se o batimento cardíaco (heartbeat) do worker parar, a GPU é tratada como perdida.
• Fluxo de Recuperação: Após uma falha, uma GPU de substituição (ou o mesmo dispositivo após reset) carrega o último snapshot base commitado e reproduz o log AOF a partir do CXL/DRAM.
• Integração NCCL: Um wrapper aprimorado do NCCL intercepta operações coletivas para identificar fronteiras seguras. Em caso de falha, ele alterna para um anel de fallback pré-computado ou ativa um dispositivo de substituição, reconstruindo o DAG do comunicador sem uma reinicialização completa do NCCL.
• Cross-Architecture (Opcional): Para recuperação entre diferentes arquiteturas de GPU, o Concordia pode normalizar o código instrumentado em uma representação intermediária portátil (CTX) e baixá-lo para a ISA alvo, embora isso seja uma extensão opcional.

3. Principais Contribuições

1. Substrato de Kernel Persistente: O artigo identifica a necessidade de um executor vivo no lado do dispositivo para permitir tolerância a falhas transparente, evitando a latência e as dependências de caminho crítico do checkpointing mediado pelo host.
2. Contrato de Recuperação Unificado: O Concordia combina instrumentação PTX/SASS, um executor persistente livre de travas, handlers delta JIT-compilados no lado da GPU e logging AOF em CXL/DRAM em um único sistema.
3. Delta Checkpointing Consciente de Estrutura: O sistema explora a estrutura de inferência de LLM (pesos estáticos, atualizações esparsas de KV) para realizar a detecção de páginas sujas inteiramente na GPU na largura de banda de HBM, eliminando a necessidade de logging de KV específico da aplicação.
4. Avaliação de Desempenho: O sistema é avaliado em GPUs Blackwell e alvos heterogêneos, demonstrando acelerações significativas no checkpointing e tempos de recuperação de sub-segundo.

4. Resultados Experimentais

A avaliação foi realizada em GPUs NVIDIA RTX PRO 6000 (Blackwell) e RTX 5090, usando PyTorch 2.10.0 e NCCL 2.27.5.

• Velocidade de Checkpointing: O delta checkpointing no lado da GPU é de 85× a 219× mais rápido que a varredura de página transparente no lado da CPU.
  • Para uma região de 256 MB com uma página suja, a diferenciação (diffing) no lado da CPU levou ~111 ms (dominada pelo escaneamento da CPU), enquanto no lado da GPU levou ~0,56 ms (dominada pela largura de banda de HBM).
  • A aceleração escala com o tamanho da região porque o diffing da CPU escala com o tamanho total da região, enquanto o diffing da GPU escala com o tamanho dos dados sujos.
• Latência de Gatilho (Trigger Latency): O envio de uma tarefa de checkpoint via buffer circular persistente leva <0,1 µs, comparado a 7,6 µs para um cudaLaunchKernel síncrono. Isso elimina o overhead de lançamento do host em cada fronteira de checkpoint.
• Overhead de Recurso: O kernel persistente ocupa apenas 0,53% dos SMs (1 bloco de 188), significativamente menor do que abordagens de threads persistentes existentes como CLC (5–10%) ou Green Contexts (3–8%).
• Throughput de Inferência: Na inferência Qwen3-0.6B, o overhead de checkpoint foi de 18,9 ms por fronteira (menos de 4% do tempo de geração), com o sistema sustentando 108,2 tokens/seg.
• Recuperação de Falhas: Um protótipo de recuperação de falha de duas GPUs restaurou o serviço em ~1,5 segundos (10 ms de detecção + 300 ms de isolamento + 800 ms de restauração de estado + 400 ms de reintegração). Isso contrasta com os mais de 47 segundos necessários para um restart padrão do NCCL e recarregamento do modelo.
• Fine-Tuning de LoRA: O sistema lidou efetivamente com a adaptação online, detectando apenas as páginas mutáveis do adaptador (1,75% do total de páginas) e alcançando uma aceleração de 299× sobre o delta checkpointing do lado da CPU para o modelo completo.

5. Significância e Alegações

O artigo afirma que o Concordia fornece um substrato necessário para a inferência de LLM de longa duração com tolerância a falhas, deslocando o loop de controle de recuperação do host para o dispositivo.

• Alegações Modestas sobre Desempenho Estático: Os autores afirmam explicitamente que, para benchmarks de decodificação estática de modelo único, CUDA Graphs cuidadosamente projetados ainda podem superar a execução eager. O Concordia não é apresentado como um substituto para CUDA Graphs, mas como uma camada complementar que opera abaixo das fronteiras do framework para lidar com cargas de trabalho dinâmicas e tolerância a falhas.
• Transparência: O sistema visa binários de GPU não modificados ou parcialmente modificados, cobrindo kernels gerados por frameworks e bibliotecas de fornecedores onde o logging de nível de aplicação é inviável.
• Modelo de Recuperação: A significância reside em permitir um modelo de reprodução AOF estilo Redis para LLMs, separando a durabilidade da capacidade escassa de HBM e permitindo a recuperação sem reconstruir comunicadores ou recarregar pesos.
• Limitações: O sistema assume que o worker persistente não falha independentemente (falhas bizantinas não são tratadas) e requer checkpointing cooperativo em pontos de barreira para migração entre arquiteturas. Também observa que regiões mutáveis opacas ainda exigem cópias de sombra residentes na GPU, consumindo HBM.

Em resumo, o Concordia demonstra que, ao manter um contexto de execução persistente e instrumentado na GPU, é possível alcançar uma tolerância a falhas de alto desempenho e transparente para a inferência de LLM, reduzindo os tempos de recuperação de minutos para segundos e eliminando a CPU do host do caminho crítico.