SplitZip: Ultra Fast Lossless KV Compression for Disaggregated LLM Serving

Resumo Técnico: SplitZip

Definição do Problema
Os sistemas contemporâneos de serviço de Grandes Modelos de Linguagem (LLM) adotam cada vez mais a desagregação de prefill-decode (PD) para otimizar a utilização de recursos, separando a fase de prefill (limitada por computação) da fase de decode (limitada por memória). No entanto, esta arquitetura introduz um gargalo crítico: a transferência do cache Key-Value (KV) dos trabalhadores de prefill para os trabalhadores de decode através de nós físicos. Em configurações de produção realistas, onde o prefill e o decode são separados por links inter-nós ou inter-cluster (frequentemente com larguras de banda de 50–100 GB/s, significativamente menores que o RDMA intra-rack), esta transferência torna-se um fator de latência dominante, especialmente para cargas de trabalho de entrada longa e agentes (agentic workloads).

As soluções existentes enfrentam um compromisso (trade-off):

• Métodos com perda (lossy) (poda, quantização, retenção seletiva) oferecem maior compressão, mas alteram os outputs do modelo, exigindo validação por implantação e correndo o risco de acumulação de erros em contextos longos.
• Métodos sem perda (lossless) (ex: codificação de Huffman, bibliotecas de propósito geral para GPU como a nvCOMP) são frequentemente inadequados para este cenário. Eles visam ou a compressão de pesos offline, ou rodam em CPUs, ou utilizam codificação de comprimento variável que cria padrões de acesso à memória irregulares e dependências sequenciais, resultando em taxas de compressão/descompressão lentas demais para acompanhar a geração de KV durante o prefill.

Metodologia: SplitZip
Os autores propõem o SplitZip, um esquema de compressão sem perda, amigável para GPU, projetado especificamente para a transferência de cache KV em serviços de LLM desagregados. O SplitZip preserva os tensores KV bit a bit, sem alterar a execução ou a semântica do modelo.

• Insight Central: O artigo observa que, em ativações KV em BF16 (e FP8), a redundância está concentrada no campo do expoente, enquanto o sinal e a mantissa exibem alta entropia e baixa compressibilidade. A análise estatística em diversas famílias de modelos (Qwen, Llama, Phi) revela que a entropia do expoente é tipicamente de 3–4 bits, e os 16 valores de expoente mais frequentes cobrem mais de 99% de todas as entradas de expoente.
• Estratégia de Codificação:
  • Codificação de Comprimento Fixo: O SplitZip utiliza um codebook Top-16 calibrado offline para mapear os valores de expoente mais frequentes para códigos de comprimento fixo de 4 bits. Dois códigos de 4 bits são empacotados em um único byte.
  • Fluxo de Escape (Escape Stream): Expoentes que ficam fora do conjunto Top-16 são tratados como "escapes". Para esses valores raros, o sistema registra a posição do elemento (16 bits) e o valor bruto do expoente (8 bits) em um fluxo de correção esparso.
  • Preservação de Sinal/Mantissa: Os bits de sinal e mantissa são armazenados sem perda como um fluxo de 8 bits sem compressão.
  • Otimização: O processo de codificação utiliza um kernel vetorizado fundido "Quad64" para maximizar o throughput da GPU, evitando o overhead de histogramação online ao utilizar um codebook pré-calibrado.
• Estratégia de Decodificação:
  • Paralelismo: A decodificação desempacota bytes em códigos de 4 bits e os mapeia via uma tabela de consulta (lookup table) em paralelo.
  • Correção: O caminho denso reconstrói a maioria dos valores. O fluxo de escape esparso é então aplicado para sobrescrever os poucos expoentes incorretos com seus valores brutos exatos, garantindo a reconstrução bit a bit.
  • Escolha de Design: Os autores escolhem explicitamente um design Top-16 (usando todos os 16 códigos possíveis de 4 bits para valores comuns) em vez de um design Top-15-mais-sentinela. Embora a abordagem de sentinela economize metadados, ela introduz um fluxo de controle irregular que degrada severamente o throughput de decodificação da GPU. O SplitZip prioriza a execução de GPU uniforme e livre de divergência.

Principais Contribuições

1. Caracterização da Redundância de KV: O artigo demonstra que a redundância de expoente em BF16, previamente observada em pesos de modelos, também é prevalente e consistente em ativações KV em arquiteturas densas, MoE e híbridas.
2. Codec de Alto Throughput: O SplitZip alcança 613,3 GB/s de codificação e 2181,8 GB/s de decodificação de throughput em ativações BF16 reais. Estas taxas superam substancialmente os compressores sem perda anteriores (ex: 68,9× mais rápido na codificação que o Falcon, 14,1× mais rápido na decodificação que o nvCOMP Cascaded).
3. Integração End-to-End: O sistema é integrado ao framework de serviço SGLang (utilizando Mooncake para transporte). Ele entrega até 1,32× de aceleração na transferência de cache KV em BF16, 1,30× de aceleração no Tempo de Primeiro Token (TTFT) e um aumento de 1,23× no throughput de requisições para cargas de trabalho de contexto longo.
4. Extensibilidade: A abordagem estende-se para caches KV em FP8 (E5M2), proporcionando uma compressão adicional de 1,14× sobre o armazenamento nativo em FP8.

Resultados

• Desempenho do Codec: O SplitZip mantém uma razão de compressão de 1,324× para BF16 (aproximando-se do limite teórico de 1,33× conforme as taxas de escape caem para 0,16%). Ele supera significativamente os baselines em throughput enquanto mantém a fidelidade sem perda.
• Latência de Transferência: Nos experimentos de transferência com Mooncake, o SplitZip reduz o tempo de transferência em 1,22× a 1,32×, dependendo do comprimento da sequência e do tamanho do lote (batch size). O benefício escala com o comprimento da sequência à medida que a transferência se torna limitada pela largura de banda; para sequências longas (ex: 64K), o overhead do codec torna-se negligenciável (apenas ~7% do tempo total), e o payload reduzido diminui diretamente a latência.
• Estudos de Ablação:
  • Top-16 vs. Top-8: O Top-16 é preferido; o Top-8 reduz a cobertura (92% vs. 99,8%), aumenta as taxas de escape e desacelera a decodificação em 3× devido ao empacotamento menos eficiente.
  • Calibração: Um codebook único calibrado offline generaliza bem entre diferentes datasets (WikiText, HumanEval, MMLU) e camadas de modelos, evitando a penalidade massiva de throughput de uma calibração dinâmica por tensor ou por token.
  • Compromisso de Metadados: O armazenamento explícito de posições de escape (Top-16) é preferido em relação à detecção baseada em sentinela (Top-15) porque preserva caminhos de decodificação uniformes, resultando em um throughput de decodificação 3,5× maior.

Significância
O artigo afirma que o SplitZip aborda um gargalo específico e crescente no serviço de LLM desagregado: o overhead de comunicação da transferência de cache KV. Ao explorar as propriedades estatísticas específicas dos expoentes de ponto flutuante e projetar um codec que mapeia nativamente para o paralelismo da GPU, o SplitZip permite a transferência eficiente e sem perda sem sacrificar a precisão do modelo. Ele permite que a desagregação PD escale efetivamente através de links de rede padrão (não apenas tecidos RDMA de alta largura de banda) e suporta cargas de trabalho de contexto longo e raciocínio de múltiplos passos, onde a compressão com perda é frequentemente inaceitável. Os autores posicionam o SplitZip como uma técnica complementar que pode ser aplicada sobre outras otimizações (como quantização) para reduzir ainda mais os custos de largura de banda.