SplitZip: Ultra Fast Lossless KV Compression for Disaggregated LLM Serving

Resumen Técnico: SplitZip

Planteamiento del Problema
Los sistemas contemporáneos de servicio de Modelos de Lenguaje de Gran Escala (LLM) adoptan cada vez más la desagregación de prefill-decode (PD) para optimizar la utilización de recursos, separando la fase de prefill (limitada por cómputo) de la fase de decode (limitada por memoria). Sin embargo, esta arquitectura introduce un cuello de botella crítico: la transferencia del caché de Clave-Valor (KV) desde los trabajadores de prefill hacia los trabajadores de decode a través de nodos físicos. En entornos de producción realistas donde el prefill y el decode están separados por enlaces inter-nodo o inter-clúster (a menudo con anchos de banda de 50–100 GB/s, significativamente menores que el RDMA intra-rack), esta transferencia se convierte en un factor de latencia dominante, especialmente para cargas de trabajo de entrada larga y agentes.

Las soluciones existentes enfrentan un compromiso:

• Los métodos con pérdida (poda, cuantización, retención selectiva) ofrecen una mayor compresión pero alteran las salidas del modelo, lo que requiere validación por cada despliegue y conlleva el riesgo de acumulación de errores en contextos largos.
• Los métodos sin pérdida (por ejemplo, codificación Huffman, librerías generales para GPU como nvCOMP) a menudo no son adecuados para este entorno. O bien se enfocan en la compresión de pesos offline, se ejecutan en CPU, o utilizan codificación de longitud variable que crea patrones de acceso a memoria irregulares y dependencias secuenciales, lo que resulta en tasas de compresión/descompresión demasiado lentas para seguir el ritmo de la generación de KV durante el prefill.

Metodología: SplitZip
Los autores proponen SplitZip, un esquema de compresión sin pérdida compatible con GPU, diseñado específicamente para la transferencia de caché KV en el servicio de LLM desagregado. SplitZip preserva los tensores KV bit a bit sin alterar la ejecución o la semántica del modelo.

• Información Clave: El artículo observa que en las activaciones KV en BF16 (y FP8), la redundancia se concentra en el campo del exponente, mientras que el signo y la mantisa exhiben alta entropía y poca compresibilidad. El análisis estadístico a través de diversas familias de modelos (Qwen, Llama, Phi) revela que la entropía del exponente es típicamente de 3 a 4 bits, y los 16 valores de exponente más frecuentes cubren más del 99% de todas las entradas de exponente.
• Estrategia de Codificación:
  • Codificación de Longitud Fija: SplitZip utiliza un libro de códigos (codebook) Top-16 calibrado offline para mapear los valores de exponente más frecuentes a códigos de longitud fija de 4 bits. Dos códigos de 4 bits se empaquetan en un solo byte.
  • Flujo de Escape (Escape Stream): Los exponentes que caen fuera del conjunto Top-16 se tratan como "escapes". Para estos valores raros, el sistema registra la posición del elemento (16 bits) y el valor bruto del exponente (8 bits) en un flujo de corrección disperso (sparse).
  • Preservación de Signo/Mantisa: Los bits de signo y mantisa se almacenan sin pérdida como un flujo de 8 bits sin compresión.
  • Optimización: El proceso de codificación utiliza un kernel vectorizado fusionado "Quad64" para maximizar el rendimiento de la GPU, evitando la sobrecarga de la creación de histogramas online mediante el uso de un libro de códigos pre-calibrado.
• Estrategia de Decodificación:
  • Paralelismo: La decodificación desempaca los bytes en códigos de 4 bits y los mapea mediante una tabla de búsqueda en paralelo.
  • Corrección: El camino denso reconstruye la mayoría de los valores. Luego, el flujo de escape disperso se aplica para sobrescribir los pocos exponentes incorrectos con sus valores brutos exactos, asegurando una reconstrucción bit a bit exacta.
  • Decisión de Diseño: Los autores eligen explícitamente un diseño Top-16 (usando todos los 16 posibles códigos de 4 bits para valores comunes) sobre un diseño Top-15 más centinela. El enfoque de centinela ahorra metadatos, pero introduce un flujo de control irregular que degrada severamente el rendimiento de decodificación de la GPU. SplitZip prioriza la ejecución de GPU uniforme y libre de divergencia.

Contribuciones Clave

1. Caracterización de la Redundancia de KV: El artículo demuestra que la redundancia del exponente en BF16, previamente observada en los pesos del modelo, también es prevalente y consistente en las activaciones KV en arquitecturas densas, MoE e híbridas.
2. Codec de Alto Rendimiento: SplitZip logra un rendimiento de codificación de 613.3 GB/s y de decodificación de 2181.8 GB/s en activaciones reales de BF16. Estas tasas superan sustancialmente a los compresores sin pérdida previos (por ejemplo, 68.9× más rápido en codificación que Falcon, 14.1× más rápido en decodificación que nvCOMP Cascaded).
3. Integración de Extremo a Extremo: El sistema se integra en el marco de servicio SGLang (usando Mooncake para el transporte). Ofrece hasta un 1.32× de aceleración en la transferencia de caché KV en BF16, un 1.30× de aceleración en el Tiempo al Primer Token (TTFT) y un incremento de 1.23× en el rendimiento de solicitudes para cargas de trabajo de contexto largo.
4. Extensibilidad: El enfoque se extiende a los cachés KV en FP8 (E5M2), proporcionando una compresión adicional de 1.14× sobre el almacenamiento nativo en FP8.

Resultados

• Rendimiento del Codec: SplitZip mantiene una relación de compresión de 1.324× para BF16 (acercándose al límite teórico de 1.33× a medida que las tasas de escape caen al 0.16%). Supera significativamente a las bases en rendimiento manteniendo la fidelidad sin pérdida.
• Latencia de Transferencia: En los experimentos de transferencia de Mooncake, SplitZip reduce el tiempo de transferencia en 1.22× a 1.32× dependiendo de la longitud de la secuencia y el tamaño del lote. El beneficio escala con la longitud de la secuencia a medida que la transferencia se vuelve limitada por el ancho de banda; para secuencias largas (ej. 64K), la sobrecarga del codec se vuelve insignificante (solo ~7% del tiempo total) y el tamaño de carga útil reducido disminuye directamente la latencia.
• Estudios de Ablación:
  • Top-16 vs. Top-8: Se prefiere Top-16; Top-8 reduce la cobertura (92% vs. 99.8%), aumenta las tasas de escape y ralentiza la decodificación por 3× debido a un empaquetado menos eficiente.
  • Calibración: Un único libro de códigos calibrado offline se generaliza bien a través de diferentes conjuntos de datos (WikiText, HumanEval, MMLU) y capas del modelo, evitando la penalización masiva de rendimiento de la calibración dinámica, por tensor o por token.
  • Compromiso de Metadatos: Almacenar explícitamente las posiciones de escape (Top-16) es preferible al uso de detección por centinela (Top-15) porque preserva rutas de decodificación uniformes, resultando en un rendimiento de decodificación 3.5× mayor.

Significancia
El artículo afirma que SplitZip aborda un cuello de botella específico y creciente en el servicio de LLM desagregado: la sobrecarga de comunicación de la transferencia del caché KV. Al explotar las propiedades estadísticas específicas de los exponentes de punto flotante y diseñar un codec que se mapea nativamente al paralelismo de la GPU, SplitZip permite la transferencia eficiente y sin pérdida sin sacrificar la precisión del modelo. Permite que la desagregación PD escale efectivamente a través de enlaces de red estándar (no solo tejidos RDMA de alto ancho de banda) y soporta cargas de trabajo de contexto largo y razonamiento de múltiples pasos donde la compresión con pérdida suele ser inaceptable. Los autores posicionan a SplitZip como una técnica complementaria que puede integrarse con otras optimizaciones (como la cuantización) para reducir aún más los costos de ancho de banda.