Compresión de pesos LLM sin pérdida vs 8-bit GGUF: ¿qué está listo para producción?

La respuesta corta: la compresión sin pérdida de pesos BF16 es real, pero el nuevo resultado con GLM-5.2 no es un release de serving listo para producción. Su evidencia más sólida es una representación byte-split que reconstruyó bit a bit los 59.509 tensores BF16 y redujo el payload de pesos un 24,967 %. La reducción K15 del 30,168 % es un cálculo completo de tamaño, no un contenedor GLM serializado y decodificado a escala. Otra prueba en A40 midió una ruta densa de 12 bits, no serving exacto end-to-end de GLM-5.2.

Q8_0 GGUF ofrece otro intercambio. Suele usar menos memoria y tiene detrás el ecosistema maduro de llama.cpp, pero está cuantizado. No puede reconstruir los pesos BF16 originales bit a bit. Elige Q8 cuando la calidad medida sea suficiente y gane la eficiencia de despliegue. Elige compresión sin pérdida cuando los pesos exactos sean un requisito duro. En ese caso, exige un runtime compatible y evidencia de producción antes de prometer ahorro de serving.

¿Qué significa “sin pérdida” para los pesos de un LLM?

Compresión sin pérdida significa que la representación comprimida puede reconstruir exactamente cada peso de origen, incluidos todos los bits del tensor BF16 original. Es una codificación reversible. No redondea valores, no poda pesos y no sustituye BF16 por enteros cercanos.

También puede ser sin pérdida dentro de VRAM. La GPU puede conservar pesos codificados, reconstruir los BF16 exactos en registers o shared memory y usarlos de inmediato en la multiplicación de matrices. La ubicación no define la pérdida. La define el round-trip.

1. Pesos exactos: los bytes comprimidos reconstruyen el tensor bit a bit.
2. Comportamiento exacto: el runtime completo reproduce los outputs de referencia bajo una configuración determinista. Los pesos exactos no bastan si cambian kernels, orden de acumulación o sampling.
3. Mejor serving: el sistema integrado mejora capacidad, latencia, throughput o coste con tráfico real sin introducir un riesgo operativo inaceptable.

¿Qué demostró realmente el experimento con GLM-5.2?

El experimento de Brian Bell recorrió los 282 shards del checkpoint GLM-5.2, unos 1,4 TiB de datos fuente. BF16 usa un bit de signo, ocho de exponente y siete de mantisa. Los pesos entrenados repiten un conjunto estrecho de exponentes. El experimento asigna códigos cortos a símbolos frecuentes de signo y exponente y guarda los raros en un escape stream exacto.

El protocolo de reproducción separa bien estas clases de evidencia. Transmite los shards, los borra tras validar y no necesita GPU para comprobar exactitud. Es evidencia de investigación útil, no un backend plug-and-play para vLLM, SGLang o llama.cpp.

¿Q8_0 GGUF es sin pérdida?

No. Q8_0 GGUF no es sin pérdida respecto a los pesos BF16 de origen. GGUF es un contenedor capaz de guardar BF16, F16 y tipos cuantizados. El formato no es necesariamente lossy. Q8_0 sí lo es.

El flujo de quantization de llama.cpp crea variantes Q desde mayor precisión y advierte que requantizar puede reducir la calidad. Q8_0 representa bloques mediante valores int8 y una escala. La dequantization obtiene aproximaciones útiles, no los patrones BF16 originales. La documentación GGUF de Hugging Face también clasifica Q8_0 como tipo cuantizado y dequantiza estos checkpoints al cargarlos en Transformers.

Esto no convierte Q8 en una mala opción. “No vemos una pérdida material en nuestra evaluación” es una conclusión válida. “Bit-exact sin pérdida” es otra afirmación y necesita una prueba reversible.

¿Cómo encaja con los sistemas anteriores?

• ZipNN separó exponentes compresibles de bits casi incompresibles y publicó cerca de un 33 % de ahorro en modelos BF16 normales. Encaja especialmente en storage, distribución y tráfico de checkpoints.
• DFloat11 combinó códigos de longitud variable con decompresión GPU y publicó modelos BF16 aproximadamente un 30 % menores con pesos reconstruidos exactamente.
• ZipServ co-diseñó un formato fijo y decompression-GEMM fusionado. Su paper publica hasta un 30 % menos de tamaño, hasta 2,21 veces de speedup de kernel y una media de 1,22 veces end-to-end frente a vLLM en sus pruebas.
• Un sistema ANS con decodificación tiled on-the-fly se integró en SGLang y multi-GPU. El preprint publica batches mayores y hasta 1,6 veces más throughput en cargas seleccionadas.
• Cloudflare Unweight investiga reconstructive matmul en Hopper. Su informe llama a los resultados intermedios y comprime pesos MLP seleccionados.

La pregunta comercial ya no es si los exponentes BF16 se comprimen. La cuestión es qué codec, kernel y motor mejoran tu workload real en hardware compatible.

Compresión sin pérdida o Q8 GGUF: ¿qué deberías desplegar?

Empieza por Q8 cuando necesites un despliegue local práctico, llama.cpp soporte el modelo y una evaluación representativa no muestre una pérdida de negocio material.

Pilota compresión sin pérdida cuando BF16 sea la referencia aprobada, una regresión resulte cara y un 20 % a 30 % más de capacidad efectiva cambie el plan de hardware. Tiene sentido para golden baselines, reasoning sensible, distribución de checkpoints y flotas limitadas por ancho de banda de pesos.

Mantén BF16 raw cuando el riesgo de integración cueste más que la memoria ahorrada o falte soporte para arquitectura, generación de GPU, batching, tensor parallelism o tooling de fallos.

¿Está listo para producción el resultado de GLM-5.2?

No. Es un resultado de compresión creíble y reproducible con otro microbenchmark de kernel. No es un motor de serving de GLM-5.2, un modelo K15 físico ni un benchmark de producción end-to-end.

1. Artefacto: serializa el modelo real, valida hashes y decodifica cada tensor desde el contenedor entregado.
2. Runtime: integra el decode exacto con serving engine, kernels, tensor parallelism, batching y arquitectura.
3. Comportamiento: compara outputs deterministas cuando sea posible y ejecuta evaluaciones por tarea contra BF16 raw.
4. Rendimiento: mide time to first token, latencia entre tokens, throughput, concurrencia, arranque, memoria máxima y energía en varios contextos y batches.
5. Operación: prueba recuperación, detección de corrupción, rollback, observabilidad, upgrades y fallback al artefacto sin comprimir.

¿Cómo se calcula el caso comercial?

beneficio mensual = coste de aceleradores evitado + storage y transferencia evitados - compute adicional - ingeniería y operación

Reducir memoria crea valor si elimina una GPU, permite un modelo que no cabía, aumenta el batch seguro, reduce suficiente tráfico de pesos o abarata distribución. Un formato un 30 % menor que necesita kernels custom y añade latencia puede ser peor que un Q8 maduro. Una reducción del 20 % que evita un acelerador por replica puede ser excelente.

Para decidir entre API e infraestructura propia, usa nuestro cálculo de break-even entre LLM local y API. Para ejecutar GLM-5.2 desde NVMe en una máquina pequeña, consulta nuestro análisis de Colibri y GLM-5.2. Esta página se centra en formato de precisión y codec de producción.

Un piloto de producción de 14 días

1. Congela la decisión: registra revisión, hashes, commit del codec, engine, drivers, GPU, prompts y gates.
2. Prueba reversibilidad: decodifica el artefacto, compara todos los tensores byte a byte e inyecta corrupción.
3. Crea tres vías: BF16 raw, candidato sin pérdida y alternativa cuantizada más creíble sobre hardware idéntico cuando sea posible.
4. Ejecuta evals reales: distribución de tareas, contextos largos, tools y casos de fallo.
5. Prueba el serving: batch 1, concurrencia objetivo, warm y cold, p50/p95, tokens por segundo, memoria y energía por tarea correcta.
6. Ejercita operaciones: reinicia workers, cambia versiones, corrompe un shard, retira un nodo y prueba fallback.
7. Decide la economía: convierte capacidad en tamaño de flota y coste mensual, incluido el ownership de un runtime no estándar.

Preguntas para un vendor o equipo de investigación

• ¿Qué dtypes y arquitecturas se soportan exactamente?
• ¿El porcentaje procede de un artefacto serializado con metadata y escapes?
• ¿Se decodificó cada tensor y se comparó con los bytes fuente?
• ¿El benchmark incluye modelo completo, escapes, attention, KV cache, batching y motor?
• ¿Qué GPUs, drivers, batches y longitudes se probaron?
• ¿Qué ocurre si se corrompe un tensor o cambia el decoder?
• ¿Existe fallback a BF16 estándar sin reconstruir el servicio?
• ¿Qué sistema en producción usa esta ruta, con qué tráfico y SLOs?

Fuentes y límites de las afirmaciones

Los tamaños, tensores, reducciones y límites proceden del boletín del experimento y sus notas de reproducción. Las comparaciones usan los papers enlazados. Las afirmaciones GGUF se basan en la documentación actual de Hugging Face y llama.cpp. Los resultados pertenecen a sus autores y sistemas de prueba. Wavect no reprodujo el scan de 1,4 TiB ni los benchmarks GPU. Datos comprobados el 22 de julio de 2026.