Un modelo de lenguaje en tu equipo, con la red desconectada.

01 · EL ARGUMENTO

Tres buenas razones y los límites que nadie menciona.

Un modelo local es peor que un modelo alojado de primera línea en casi cualquier tarea. También es la única opción cuando los datos no pueden salir del equipo, y conviene entender ese intercambio con precisión.

Lo que sí te da lo local

• Los datos no salen. Sin términos de servicio, sin política de retención, sin dudas sobre entrenamiento. Para material de clientes, notas médicas, borradores legales o cualquier cosa bajo acuerdo de confidencialidad, ese es todo el argumento.
• Funciona sin conexión. En un avión, en un laboratorio, en una obra sin cobertura o durante una caída del proveedor.
• Sin coste por token ni límites de uso. Clasificación masiva, resúmenes por lotes y experimentos repetidos salen gratis después de la electricidad.
• No lo pueden retirar bajo tus pies. El modelo que guardaste se comporta igual dentro de dos años. Los modelos alojados cambian sin avisar.

Lo que no te da

• Razonamiento de frontera. Un modelo que cabe en memoria de vídeo de consumo no compite con los mayores modelos alojados en razonamiento difícil ni en conocimiento poco común.
• Velocidad con contexto largo. Procesar un documento grande es justo donde el hardware de consumo se nota más lento.
• Menos errores con aplomo. Los modelos pequeños alucinan más, no menos. Local no significa cuidadoso.
• Memoria gratis. Lo que ocupa el modelo es memoria que no tiene el resto de tu trabajo.

02 · EL PRESUPUESTO

La memoria lo decide todo. Esta es la aritmética.

Tamaño del modelo en miles de millones de parámetros, multiplicado por los bytes por parámetro de tu cuantización, más espacio para la ventana de contexto. Ese es todo el cálculo.

Añade margen sobre cada cifra. La caché de claves y valores crece con el texto que introduces, y un contexto largo en un modelo grande consume varios gigabytes más. Un modelo que apenas cabe con el contexto vacío fallará a mitad de un documento largo.

La cuantización en un párrafo

Los pesos se almacenan con menor precisión para que el modelo ocupe menos. Pasar de 16 a 8 bits es casi gratis en calidad. De 8 a 4 bits es el punto dulce que usa casi todo el mundo: una pérdida pequeña y normalmente aceptable a cambio de aproximadamente la mitad de memoria. Por debajo de 4 bits la degradación se vuelve evidente, empezando por el seguimiento de instrucciones. Un modelo más grande a 4 bits suele superar a uno más pequeño a 8 bits, y esa es la regla más útil de todo el tema.

03 · LAS HERRAMIENTAS

Cuatro formas de ejecutar los mismos archivos.

Las cuatro ejecutan los mismos archivos cuantizados, así que la elección va de flujo de trabajo, no de capacidad. Un montaje habitual es Ollama como motor y una interfaz de chat aparte apuntando a su API.

04 · PASO A PASO

De cero a un modelo funcionando en unos diez minutos.

# Descarga un modelo acorde a tu hardware y empieza a chatear
ollama run llama3.1:8b

# Ver qué has descargado y cuánto ocupa
ollama list

# Eliminar lo que ya no quieres
ollama rm llama3.1:8b

# Servir la API local para otras herramientas
ollama serve

La API escucha en localhost, que es adonde se conectan los complementos del editor, las aplicaciones de notas y tus scripts. Nada sale del equipo.

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "Resume esto en tres puntos: ...",
  "stream": false
}'

Qué modelo elegir primero

• Asistente general con 8 GB de VRAM — un modelo instruido actual de 7B a 8B a 4 bits. Es la respuesta por defecto y es buena.
• Código — un modelo especializado del mismo tamaño. Claramente mejor completando y refactorizando que uno general equivalente.
• Pequeño y rápido — un modelo de 3B para clasificación, extracción y etiquetado, donde no necesitas conversación.
• La mejor calidad que quepa — sube en parámetros antes que en precisión.

05 · AJUSTES

Cuatro parámetros que deciden si resulta usable.

• Capas descargadas a la GPU. El ajuste más importante cuando el modelo no cabe entero. Envía a la GPU tantas capas como permita la VRAM; el resto lo calcula la CPU. Una capa de más provoca un fallo por falta de memoria.
• Ventana de contexto. Más contexto cuesta memoria y ralentiza la generación. Ponla en lo que realmente necesites: 4K para conversar, más solo cuando de verdad introduces documentos.
• Tamaño de lote al procesar el prompt. Afecta a la rapidez con la que se ingiere una entrada larga, aparte de la velocidad de salida.
• Nivel de cuantización. Si no cabe, baja de 5 a 4 bits antes de cambiar a un modelo más pequeño.

Si la generación va mucho más lenta que la tabla, es casi seguro que el modelo se está desbordando de la VRAM a la memoria del sistema. Revisa la descarga de capas antes de culpar al hardware.

06 · VERIFICACIÓN

Demuestra que el modelo funciona sin red.

Este es el paso que separa una instalación realmente local de una interfaz local delante de una API remota. Hazlo una vez, a conciencia.

Mantenerlo sin conexión después

• Bloquea la salida a red del motor en el cortafuegos una vez descargados los modelos. Actualiza de forma deliberada.
• Desactiva telemetría y comprobación de actualizaciones en la herramienta que hayas elegido.
• Guarda copia de los archivos del modelo. Son grandes pero no infinitos, y un modelo retirado o relicenciado no se recupera sin copia.
• Cuidado con las interfaces de chat. Muchas admiten proveedores locales y alojados, y cambiar es un desplegable. Comprueba cuál está seleccionado antes de pegar algo sensible.

07 · RESPUESTAS RÁPIDAS

Modelos locales, en breve.