← Volver al Jardín

Corriendo LLMs de 27B Parámetros en una GPU de 8GB: 1-Bit, Ternario y 262K de Contexto

•
#LLM#1-Bit#Ternario#PrismML#CUDA#GGUF#Homelab

BENCHMARK_LOG // RTX4000_8GB // PRISM_ML // LLAMA_CPP

Correr modelos de 27 mil millones de parámetros en local solía exigir un setup multi-GPU costoso o resignarse a un offloading a CPU que arrastraba la generación a unos tristes 2 - 4 tok/s. Intentar bajar de 4 bits con cuantización tradicional Post-Training (PTQ) como IQ2_XXS o Q2_K solo provocaba un colapso severo en el razonamiento del modelo.

En mi workstation beast, logré romper esta barrera combinando las arquitecturas nativas binarias y ternarias de Prism ML (Bonsai-27B-Q1_0 y Ternary-Bonsai-27B-Q2_0) con optimizaciones agresivas en llama.cpp y un ajuste de hardware clave: eliminar la limitación manual de consumo que le había aplicado a la GPU (subiendo de 100W a sus 125W de fábrica).

El resultado: 27.35 tokens/segundo corriendo al 100% en GPU con una ventana de contexto de 160,000 tokens en una sola NVIDIA Quadro RTX 4000 de 8 GB VRAM.

Hitos de Rendimiento

  • 27.35 tok/s en 160K de contexto (125W Stock): Residente al 100% en 8 GB VRAM a 163,840 tokens con Bonsai-27B-Q1_0.gguf.
  • Contexto completo de 262K desplegado: Escalado al límite nativo de 262,144 tokens en modo híbrido GPU/CPU, generando a 12.93 tok/s.
  • Serving Ternario de Alta Calidad a 18.04 tok/s: Con Ternary-Bonsai-27B-Q2_0.gguf (reteniendo el 94.6% de la inteligencia FP16) sobre 32,768 de contexto 100% en GPU.
  • Ganancia Real de Eficiencia a 125W: Quitar el freno manual de 100W y pasar a 125W dio un salto del +32.7% en throughput en 1-bit, reduciendo el consumo energético efectivo por token de 4.85 J/token a 4.57 J/token. En modo ternario, la penalización de consumo es mínima frente al gran incremento en latencia/responsiveness.

Deep-Dive Arquitectural: Bajo Bit Nativo vs PTQ Tradicional

A. Representación de Pesos (Q1_0_g128 vs Q2_0_g128)

A diferencia del PTQ convencional (que fuerza pesos densos FP16 en contenedores pequeños degradando la precisión), la familia Bonsai-27B entrena los pesos binarios y ternarios de principio a fin de forma nativa:

  • Bonsai-27B-Q1_0.gguf (Binario 1-bit):

    • Formato nativo: Q1_0_g128 (pesos {-1, +1} con escala FP16 por grupo de 128 pesos).
    • Ancho de bit efectivo: 1.125 bits/peso (1 bit de signo + 16-bits escala / 128).
    • Footprint en memoria: ~3.8 - 3.9 GB (~14.2x menor que el baseline FP16 de ~54 GB).
    • Retención de inteligencia: Conserva el 89.5% del rendimiento benchmark en FP16 (76.11 promedio en 15 benchmarks de modo pensamiento).

  • Ternary-Bonsai-27B-Q2_0.gguf (Ternario / 2-bit):

    • Formato nativo: Q2_0_g128 (pesos {-1, 0, +1} en slots de 2 bits con escala FP16 por grupo).
    • Ancho de bit efectivo: 1.71 bits/peso teórico (2.125 bpw desplegado en el contenedor GGUF actual).
    • Footprint en memoria: ~7.2 - 7.5 GB (~9.4x reducción vs FP16).
    • Retención de inteligencia: Conserva el 94.6% del benchmark FP16 (80.49 promedio), superando al IQ2_XXS tradicional (72.73) ocupando menos espacio.

B. La Ventaja del Hybrid-Attention en KV Cache

Bonsai 27B deriva de la arquitectura Qwen3.6-27B, que emplea un backbone de atención híbrida (~75% linear attention y ~25% full attention a lo largo de 64 bloques).

Al requerir KV cache completo solo en 16 de las 64 capas, el crecimiento de memoria del contexto se reduce en un 75% comparado con transformers estándar. Al sumar la cuantización de KV Cache en Q4_0, la memoria requerida para 262K tokens cae drásticamente de ~17.2 GB a solo ~4.3 GB.

C. Comparativa de Densidad de Inteligencia

La Densidad de Inteligencia ($D$) mide la relación entre la capacidad del modelo en benchmarks y su espacio ocupado en GB:

D = -log2(1 - Score / 100) / Size_GB
Variante de Modelo Tamaño Desplegado Benchmark Promedio (Thinking) Densidad de Inteligencia (1/GB)
1-bit Bonsai 27B (Q1_0) 3.9 GB 76.11 0.530
Ternary Bonsai 27B (Q2_0) 5.9 GB (ideal) / 7.2 GB 80.49 0.400
Qwen3.6-27B IQ2_XXS 9.4 GB 72.73 0.199
Gemma-4-31B Q2_K_XL 11.8 GB 73.31 0.162
Qwen3.6-27B Q4_K_XL 17.6 GB 84.99 0.155
Qwen3.6-27B FP16 54.0 GB 85.07 0.0513

Hardware y Setup del Banco de Pruebas

Todas las mediciones se realizaron en mi banco de trabajo beast:

  • Host System: beast
  • GPU: NVIDIA Quadro RTX 4000 (8,192 MiB GDDR6 / ~7,795 MiB usables, CUDA CC 7.5 Turing)
  • Power Target GPU: Cap manual previo de 100W (ahorro de energía) vs 125W (límite stock liberado)
  • CPU: AMD Ryzen 9 7945HX con Radeon Graphics (16 Cores / 32 Threads, AVX-512 activo)
  • RAM del Sistema: 96 GB DDR5-5600
  • Motor de Inferencia: llama.cpp (llama-server custom build con kernels low-bit de PrismML)
  • OS / CUDA / Driver: Linux / CUDA 13.3 / NVIDIA Driver 610.43.02
  • Frontend Client: Open WebUI (vía endpoint compatible OpenAI API)

Benchmarks Empíricos

Modelo Binario 1-Bit (Bonsai-27B-Q1_0.gguf)

Contexto (-c) Power Cap GPU Layers (-ngl) KV Cache Gen Speed Prompt Eval VRAM Utilizada Modo Operativo
65,536 100W (Cap manual) 99 q4_0 22.06 tok/s 357.36 tok/s 5,260 MiB 100% GPU Resident
131,072 100W (Cap manual) 99 q4_0 21.87 tok/s 355.47 tok/s 6,732 MiB 100% GPU Resident
163,840 100W (Cap manual) 99 q4_0 20.61 tok/s 347.01 tok/s 7,472 MiB 100% GPU Resident
163,840 125W (Stock) 99 q4_0 27.35 tok/s 420.24 tok/s 7,468 MiB 100% GPU Resident (Unlocked)
262,144 100W (Cap manual) 45 q4_0 12.93 tok/s 336.93 tok/s 7,612 MiB Híbrido Max Context (45 GPU / 19 CPU)

Modelo Ternario (Ternary-Bonsai-27B-Q2_0.gguf)

Contexto (-c) Power Cap GPU Layers (-ngl) KV Cache Gen Speed Prompt Eval VRAM Utilizada Modo Operativo
16,384 100W (Cap manual) 99 q8_0 17.10 tok/s 349.12 tok/s 7,472 MiB 100% GPU Resident
32,768 100W (Cap manual) 99 q4_0 15.10 tok/s 316.42 tok/s 7,588 MiB 100% GPU Resident
32,768 125W (Stock) 99 q4_0 18.04 tok/s 356.78 tok/s 7,608 MiB 100% GPU Resident (Unlocked)
65,536 100W (Cap manual) 59 q4_0 10.92 tok/s 238.59 tok/s 7,612 MiB Modo Híbrido (59 GPU / 5 CPU)

Análisis de Eficiencia Energética

Inicialmente había capado la GPU a 100W para reducir el consumo general de mi workstation. Sin embargo, al analizar los datos descubrimos un comportamiento contraintuitivo pero óptimo:

E_token = P_TDP / Throughput_tok/s  [Joules/token]
E_mWh   = E_token / 3.6

Perfil Energético Comparativo

Modelo & Configuración Potencia (P) Throughput (T) Energía / Token (E) Energía / Token (mWh) Veredicto de Eficiencia
Q1_0 (160K Contexto) 100W (Cap manual) 20.61 tok/s 4.85 J/token 1.35 mWh/token Power Throttled
Q1_0 (160K Contexto) 125W (Stock) 27.35 tok/s 4.57 J/token 1.27 mWh/token +5.8% MÁS Eficiente!
Q2_0 (32K Contexto) 100W (Cap manual) 15.10 tok/s 6.62 J/token 1.84 mWh/token Límite Ahorro
Q2_0 (32K Contexto) 125W (Stock) 18.04 tok/s 6.93 J/token 1.92 mWh/token -4.7% costo por +19.5% velocidad

Conclusiones Clave de Energía

  1. Ganancia real de eficiencia en 1-Bit: Con el cap manual de 100W, los relojes y ancho de banda de la GPU sufrían throttling. Al liberar los 125W stock (un +25% de potencia), la velocidad saltó un +32.7% (20.61 a 27.35 tok/s). Como la ganancia de velocidad superó al incremento de potencia, el costo energético real por token bajó de 4.85 J a 4.57 J. Correr a 125W stock en 1-bit es numéricamente más eficiente por token impreso.
  2. Excelente trade-off en Modo Ternario (Q2_0): En modo ternario, quitar el límite de 100W incrementa la velocidad un +19.5% (15.10 a 18.04 tok/s), con un aumento insignificante del +4.7% en el consumo por token. Para respuesta interactiva en chat, esa ganancia en responsiveness compensa ampliamente el ínfimo gasto marginal.

Presets Recomendados para Producción

Preset 1: Máxima Velocidad y Contexto (160K Contexto @ 125W — 100% GPU)

Ideal para: Asistencia de código rápida, chat diario e interacción con latencia cero.

./build/bin/llama-server \
  -m Bonsai-27B-Q1_0.gguf \
  --host 0.0.0.0 --port 11433 \
  -c 163840 -np 1 \
  -ngl 99 \
  -fa on \
  -ctk q4_0 -ctv q4_0 \
  -rea on

Preset 2: Máxima Calidad de Inteligencia (32K Contexto @ 125W — Ternario Q2_0)

Ideal para: Matemáticas complejas, razonamiento lógico (94.6% de retención sobre FP16) y síntesis formal de documentos.

./build/bin/llama-server \
  -m Ternary-Bonsai-27B-Q2_0.gguf \
  --host 0.0.0.0 --port 11433 \
  -c 32768 -np 1 \
  -ngl 99 \
  -fa on \
  -ctk q4_0 -ctv q4_0 \
  -rea on

Preset 3: Análisis Masivo de Contexto (262K Contexto — Modo Híbrido GPU/CPU)

Ideal para: Repositorios de código multi-archivo, libros completos o batches gigantescos de archivos PDF.

./build/bin/llama-server \
  -m Bonsai-27B-Q1_0.gguf \
  --host 0.0.0.0 --port 11433 \
  -c 262144 -np 1 \
  -ngl 45 \
  -fa on \
  -ctk q4_0 -ctv q4_0 \
  -rea on

Reflexión Final: Democratización de la IA Local y la Era de la Eficiencia

Más allá del logro técnico inmediato, la llegada de cuantizaciones extremas como 1-bit y 2-bit (ternario) toca una fibra fundamental: la soberanía y democratización de la Inteligencia Artificial.

Soy un defensor firme de la IA local, abierta y libre. Sin embargo, con los precios y la escasez actual del hardware (donde las GPUs de clase empresarial con VRAM masiva resultan prohibitivas), correr modelos potentes en local se había vuelto un privilegio para muy pocos. Esto cambia las reglas del juego.

La IA está atravesando la misma evolución histórica que la máquina de vapor en los inicios de la revolución industrial. Al principio, la tecnología es ineficiente y bruta: la industria se enfoca en explorar los límites máximos sin importar el consumo. Sucedió exactamente lo mismo con las CPUs y las GPUs en su momento, donde la era de la fuerza bruta dio paso eventualmente a la búsqueda obsesiva de la eficiencia arquitectónica por vatio. La IA está finalmente entrando en esa segunda etapa.

Si estos formatos de bajo bit logran la tracción que merecen, en el futuro cercano no necesitaremos GPUs inaccesibles ni cantidades absurdas de VRAM para correr modelos top. Podremos tener inteligencia de nivel enterprise descentralizada en hardware modesto de consumo.

En el papel, Qwen3.6 27B impresiona. Ahora que logré ponerlo a rodar localmente a una velocidad realmente fluida, empieza la prueba de fuego real: probarlo a fondo con mi flota de agentes (Hermes, Pi, OpenCode, OpenClaw) para verificar si este modelo es genuinamente usable y robusto en flujos de trabajo de producción diaria.