Requisitos Previos: La Realidad de 4GB VRAM

El Edge no es el Cloud. Hay que dejar de lado la fantasía de los 70B parámetros. Cuando el recurso es una GPU con solo 4GB de VRAM, o incluso un sistema single-board con memoria unificada, la única táctica válida es la cuantización estricta a 4-bit y la gestión forense de la memoria. Ignorar esto es un crash del kernel o un rendimiento inútil de 0.5 tokens/segundo. El modelo objetivo debe ser pequeño, idealmente de 3B a 7B de parámetros.

Para empezar, necesitamos la herramienta de facto para estos entornos: Ollama, que maneja de forma eficiente el formato GGUF y la descarga de modelos ya cuantizados, optimizando la carga en memoria limitada. El stack de hardware requiere soporte para CUDA (NVIDIA, aunque no sea una A100) o OpenCL/ROCm (AMD/Integradas), además de un sistema operativo Linux. Es la única manera de interactuar con el hardware sin sobrecarga.

Instalación de Ollama y Dependencias

Si no tienes un entorno de desarrollo on-device limpio, empieza con Docker. Es la forma más rápida de aislar el entorno y gestionar las dependencias de GPU. Asumo un sistema debian-based con Docker ya instalado; si no, aquí tienes la línea de fuego para que funcione a la primera.

# 1. Instalar Docker (si no está): sudo apt update && sudo apt install docker.io -y sudo systemctl start docker && sudo systemctl enable docker sudo usermod -aG docker $USER  # 2. Reinicia o ejecuta 'newgrp docker' para aplicar el cambio de grupo. # 3. Instalar la CLI de Ollama (opcional, pero útil para host): curl -fsSL https://ollama.com/install.sh | sh

: A stylized, wireframe rendering of a minimalist edge computing device (like a small fanless box) connected to a complex, transparent network of data streams and a single holographic projection of a 4-bit quantized LLM structure, photorealistic, 16k resolution, sharp focus, ray tracing, unreal engine 5 render, cinematic volumetric light, technical schematics style, depth of field.

Paso 1: Selección y Carga del Modelo 4-bit

Nuestro límite de 4GB es un desafío brutal. Un modelo de 7B parámetros en formato GGUF (que usa q4_k_m) rondará los 4.3 GB en disco. Si añadimos la sobrecarga del framework (Ollama), el KV Cache (memoria para el contexto) y las activaciones, estaremos al límite del VRAM disponible. La sobrecarga puede ser de hasta 1GB. La mejor prueba es usar un modelo de 3B a 5B, o una variante mini de 7B.

El comando para desplegar y probar la latencia inicial del modelo es directo. Escogemos un modelo conocido que esté disponible en una variante de cuantización baja.

# Ejemplo: Descargar y correr un modelo 4-bit (q4_k_m es el estándar GGUF) # Usaremos 'orca2:7b' o similar, asumiendo que su variante q4_k_m cabe. ollama run llama2:7b --config num_gpu=99 # 'num_gpu=99' obliga a cargar la mayor cantidad posible en la GPU. # La primera ejecución es lenta porque construye el cache.

El rendimiento en la primera ejecución es engañoso. El verdadero cuello de botella en sistemas de 4GB VRAM no es el cálculo matricial, sino el ancho de banda de memoria para cargar el modelo y el KV Cache. Si el modelo no cabe, el offload a la memoria RAM principal (que es mucho más lenta) matará el rendimiento.

Paso 2: Evaluación del Rendimiento (Metrics Hardcore)

La métrica no es “si funciona”, es cuán rápido funciona. Nos centraremos en dos métricas clave extraídas del verbose de la inferencia, que Ollama o llama.cpp exponen: Latencia (Time to First Token – TTFT) y Rendimiento (Tokens/segundo – TPS). El TTFT te dirá cuán rápido se evalúa el prompt y el TPS te dará la velocidad de generación pura.

Para obtener métricas precisas, necesitamos un prompt largo que maximice la evaluación y luego una generación libre. Es obligatorio ejecutar múltiples veces para promediar.

Script de Benchmarking Pragmático

Este script básico utiliza el modo verbose para extraer los datos de rendimiento. El desafío de los 4GB es mantener el TPS por encima de 5 para que sea “utilizable”.

# Script de prueba simple con un prompt largo para estresar el TTFT/Evaluación PROMPT="Escribe un informe de 500 palabras sobre la complejidad algorítmica de la atención en modelos transformer cuantizados a 4 bits, centrándose en el trade-off de memoria y precisión. Tono técnico."  echo "Iniciando prueba de rendimiento..." ollama run llama2:7b "$PROMPT" --verbose 2>&1 | grep -E 'eval|load' # Filtra las métricas clave: # load_time: Indica la latencia de carga. # eval_duration: Tiempo de evaluación del prompt (Latency/TTFT). # eval_rate: Velocidad de procesamiento del prompt (en tokens/seg). # speed: Velocidad de generación (Tokens/segundo - Throughput/TPS).

Este resultado te muestra la cruda verdad. Si el `speed` (TPS) es inferior a 2, el modelo es funcionalmente inútil para una conversación interactiva. La `eval_rate` (TTFT) debe ser lo más baja posible; en 4GB VRAM, lucharemos por mantenerla por debajo de los 10 segundos, dependiendo de la longitud del prompt. Esto requiere coraje técnico: aceptar que el hardware impone límites físicos.

Paso 3: Optimización del KV Cache

Una vez que el modelo carga, el siguiente asesino de memoria es el KV Cache, que almacena las claves y valores de atención del context window (la memoria a corto plazo del LLM). En 4-bit, es crucial cuantizar también el KV Cache (aunque sea a 8-bit o 4-bit) para ahorrar memoria. De lo contrario, contextos largos (ej. 8K o 16K tokens) sobrecargarán los 4GB restantes del stack de memoria.

Para manipular esto, debes usar un Modelfile de Ollama y no solo el comando run simple.

Configuración de la Quantización del KV Cache

Creamos un Modelfile que especifique explícitamente la cuantización para nuestro modelo base y el KV Cache, forzando la optimización de memoria.

# 1. Crear el Modelfile nano ./Modelfile_4bit

# Basado en un modelo existente que ya es q4_k_m FROM llama2:7b # Modificar el tamaño del contexto para ajustarse al límite PARAMETER stop "USUARIO:" PARAMETER num_ctx 4096  # Reducir el contexto de 8192 a 4096 puede liberar VRAM crítica. # Ajuste de VRAM: offload total (asumiendo que num_gpu=99 ya lo hace). # KV Cache: La propia implementación GGUF en Ollama gestiona la cuantización. # Si el modelo tiene un tamaño de 4.3GB (q4_k_m), el contexto de 4k cabe. SYSTEM """ Actúa como un SysAdmin experto. """

[IMG_INPOST_2]: A close-up, macro shot of a single, highly detailed microchip with illuminated traces, symbolizing a low-bit quantization layer (4-bit). The surrounding environment is blurred, emphasizing the sharp focus on the chip’s structure, photorealistic, 16k resolution, sharp focus, ray tracing, unreal engine 5 render, cinematic volumetric light, technical schematics style, depth of field.

Ahora, construye y ejecuta la versión optimizada:

# 2. Construir el modelo optimizado ollama create llama2:7b-opt -f ./Modelfile_4bit # 3. Correr el nuevo modelo (comparar las métricas) ollama run llama2:7b-opt "$PROMPT" --verbose 2>&1 | grep -E 'eval|load'

Si el `speed` mejora, el ajuste del `num_ctx` (tamaño del contexto) fue clave. En 4GB de VRAM, cada token de contexto cuenta; reducir el contexto es una compensación dura pero necesaria para mantener la velocidad de generación. No se trata de tener el modelo más grande, sino el más rápido dentro de tu presupuesto de hardware.