Por qué tu LLM local se siente tonto (y cómo arreglarlo)

“`html

En pocas palabras: Tu LLM local se siente menos capaz porque corre cuantizado a 4 bits (Q4_K_M): esa compresión cuesta entre 1% y 2% de perplexity según los benchmarks de presenc.ai (2026), y se suman la VRAM limitada y el contexto recortado de tu hardware frente al modelo original sin comprimir.

Tu LLM local no amaneció tonto: lo achicaron a propósito. La cuantización a 4 bits, el contexto recortado y las limitaciones de memoria de tu hardware explican por qué el mismo modelo que impresiona en un data center rinde menos en tu escritorio. La buena noticia es que casi todo eso tiene explicación y, en varios casos, solución.

Un LLM local es un modelo de lenguaje grande que ejecutás en tu propio hardware (una PC, una notebook o un servidor propio) en vez de consumirlo vía API desde servidores remotos. Se corre casi siempre cuantizado a 4 u 8 bits con herramientas como Ollama o LM Studio, y ahí nacen sus límites: la VRAM disponible, el ancho de banda de memoria, el tamaño de contexto y la calidad de la cuantización definen cuán capaz se siente el modelo en la práctica.

¿Cuáles son las principales limitaciones técnicas de un LLM local?

Las tres grandes limitaciones tienen nombre: memoria disponible, ancho de banda y ventana de contexto. Una GPU consumer típica trae 8 GB de VRAM, mientras que los nodos que corren modelos de frontera pasan los 100 GB por equipo. Esa brecha te obliga a usar modelos más chicos y cuantizados, y cada recorte se paga en calidad percibida.

Ponele que descargaste un modelo de 14B en GGUF cuantizado a Q4: ocupa unos 8 o 9 GB. Con 8 GB de VRAM no entra entero, así que Ollama manda parte de las capas a la RAM y los datos empiezan a viajar de ida y vuelta entre memoria y procesador. Ahí no falla la “inteligencia” del modelo; falla la logística para alimentarlo.

¿Casos aislados? No: en el hilo de Level1Techs sobre el tema se repite el mismo patrón de queja con hardwares y modelos distintos.

El segundo freno es el ancho de banda de memoria, y este es el que casi nadie mira. Generar texto consiste, en esencia, en leer los pesos del modelo una y otra vez, de modo que importan menos los TFLOPS de tu chip que la cantidad de gigas por segundo que podés mover. Dos módulos de RAM de escritorio se quedan lejos de una GPU moderna en esa carrera. Por eso hay equipos que cumplen con la RAM recomendada y aun así arrastran: la capacidad alcanza, pero el tubo por donde pasan los datos queda angosto. Cubrimos ese tema en detalle en cómo proteger tus dispositivos con Intune.

O sea: no es que el modelo sea tonto. Es que corre con los tobillos atados.

¿Cómo afecta la cuantización la calidad de un LLM local?

La cuantización reduce la precisión numérica de los pesos del modelo (de 16 bits a 4 en la mayoría de los setups hogareños) y su efecto neto es un intercambio: entre 1% y 2% menos de calidad en perplexity a cambio de 3,5x a 3,8x de velocidad y un cuarto de la memoria (que no es poco), según midió presenc.ai en sus benchmarks de 2026. En tareas cotidianas ese costo casi no se nota; en matemática y razonamiento largo, sí se paga.

Sobre formatos: GGUF es el estándar de facto de llama.cpp, Ollama y LM Studio, corre en CPU, GPU o combinando ambas, y es el que usa la enorme mayoría de las herramientas de escritorio. AWQ y GPTQ apuntan a escenarios de GPU pura con servidores de inferencia. Para tu máquina, GGUF y listo.

¿Se nota pasar de Q4 a Q8? Menos de lo que sugiere el ruido de internet: la curva de calidad se aplana bastante arriba de Q4, y el doble de peso se cobra en velocidad y memoria. Donde sí se cae la pelota es por debajo, en Q2 y Q3: ahí el modelo empieza a repetirse, a ignorar instrucciones y a inventar palabras. Si querés sacrificar algo, que no sea la cuantización hasta ese punto.

Ejemplo de todos los días: un 7B en Q4 resume un mail perfecto y traduce impecable, pero a la primera integral paso a paso arranca a improvisar símbolos. Misma máquina, mismo modelo, tarea distinta: el recorte de precisión golpea donde el margen de error es cero.

¿Por qué mi LLM local olvida el contexto en conversaciones largas?

Tu modelo olvida porque la caché de atención (KV cache) crece con cada token procesado y tu memoria libre no. En la nube reservan decenas de GB para esa caché; en una máquina casera el límite práctico queda entre 2048 y 4096 tokens antes de saturar. Pasado ese punto, el runtime recorta el historial o todo migra a swap y la generación se vuelve dolorosa.

Levantás Ollama, tirás el pull, el primer prompt vuela, y a los diez mensajes el modelo empieza a olvidar lo que le pediste al principio, repite ideas que ya cerró, corta respuestas a la mitad, y vos jurás que bajaste el archivo mal cuando en realidad el caché de atención ya se comió la RAM libre y el sistema está haciendo malabares con la memoria que le queda. Tema relacionado: cómo funciona ChatGPT por dentro.

El detalle tramposo: cuando te pasás del contexto configurado, muchos runtimes descartan los tokens más viejos sin avisarte. Seguís escribiendo tranquilo y el modelo ya perdió la instrucción original. De ahí salen buena parte de los “se corta” y “se repite” que se leen en foros.

Dos palancas útiles: activá Flash Attention si tu build lo soporta (reduce el consumo de memoria de la atención, o sea más margen para contexto) y ajustá num_ctx al valor que uses de verdad en lugar del default. Subirlo a 32k “por las dudas” termina en swap y ventanas congeladas (spoiler: lo probé, no funcionó).

¿Qué velocidad tiene un LLM local: CPU o GPU?

En CPU esperate 3 a 8 tokens por segundo; con GPU dedicada, el rango típico trepa a 40-80. La diferencia no la explica la potencia bruta sino el ancho de banda entre memoria y procesador: la generación lee el modelo completo por cada token producido, así que quien lee rápido, escribe rápido.

Una referencia para calibrar expectativas: una persona lee cómoda a unas 5 palabras por segundo, y un token ronda las tres cuartas partes de una palabra. Con 3 tokens por segundo, usar el modelo es esperar más que leer; con 60, la sensación es de respuesta instantánea. Las mediciones de abril de 2026 publicadas en Das Root sobre velocidad y consumo de LLMs locales coinciden con esos rangos según el hardware.

Moral: si el modelo va a vivir en tu CPU, elegilo chico. O considerá una GPU de segunda mano, que para un 8B cuantizado no hace falta nada exótico.

LLM local o ChatGPT/Claude: ¿quién gana en qué?

Ganan puntos distintos: la nube domina en razonamiento complejo y comodidad; el LLM local gana en privacidad, costos predecibles y trabajo offline. En tareas simples (resumir, traducir, reformatear, clasificar), un 7B u 8B bien cuantizado empata con modelos mucho más caros, y esa paridad sostiene todo el ecosistema local. Más contexto en cómo razonan realmente los modelos de lenguaje.

Aspecto	LLM local	Nube (ChatGPT/Claude)
Razonamiento complejo	Pierde: modelos 7B-70B cuantizados	Gana: modelos de frontera sin recortar
Tareas simples (resumir, traducir)	Paridad en la mayoría de los casos	Paridad
Privacidad de datos	Gana: nada sale de tu máquina	Depende del plan y la política de retención
Costo predecible	Gana: pagás el hardware una vez	Suscripción de USD 20/mes o API por tokens
Conveniencia	Viene flojo: instalás, actualizás, ajustás	Gana: cero configuración

La cuenta fina: si tu uso es el de cualquier humano (consultas sueltas durante la semana), amortizar hardware frente a USD 20 mensuales toma años. Si movés millones de tokens al mes con datos que no pueden salir de la empresa, el cálculo se invierte en meses. El punto medio que más veo en equipos chicos: modelo local para lo sensible y lo repetitivo, nube para lo difícil.

¿Cuáles son los mejores modelos para correr en local en 2026?

Los caballeros del año son Phi-4 (publica 80,4% en el benchmark MATH, sí, 80,4%, lo releí tres veces), Mistral 7B y Medium, Llama 3 en su variante de 8B, y los destilados de DeepSeek para quienes quieren razonamiento paso a paso sin hipotecar la VRAM.

Modelo	Tamaño aprox. en Q4	Dónde anda cómodo
Mistral 7B	4-5 GB	8 GB de RAM; GPU opcional
Llama 3 8B	4-5 GB	8-16 GB de RAM; GPU de 8 GB ideal
Phi-4	8-9 GB	GPU de 12-16 GB o mucha RAM
DeepSeek destilado (7B-14B)	4-9 GB según variante	Escala con el tamaño que elijas

Instalar cualquiera de estos hoy es cuestión de un comando con Ollama o de dos clics en LM Studio; la guía de Hugging Face sobre modelos abiertos para correr en local recorre opciones y requisitos con detalle. Regla rápida para elegir: el archivo del modelo debería entrar entero en la memoria más rápida que tengas (VRAM primero, RAM después). Si no entra, cambiá de cuantizado antes que de modelo.

¿Cómo optimizar un LLM local para mejor rendimiento?

El grueso de la mejora sale de ajustes gratuitos: contexto calibrado, cuantización Q4_K_M, offload completo a GPU y Flash Attention. Ninguno requiere cambiar de modelo ni gastar un peso; todos se hacen en minutos.

• Ajustá num_ctx al uso real: si tus conversaciones no pasan de 3000 tokens, no reserves 32000; cada token de contexto extra paga renta en memoria.
• Quedate en Q4_K_M: es el punto dulce entre calidad, velocidad y memoria; bajá más solo si tu hardware no te da otra.
• Meté todas las capas posibles en GPU: revisá el offload, porque unas pocas capas fuera de VRAM te tiran la velocidad al piso.
• Activá Flash Attention: menos memoria para la atención y más aire para el contexto.
• Elegí el modelo según la tarea: un 7B especializado suele rendir mejor que un generalista más grande y mal elegido.

Si arrancás de cero, la guía para correr LLMs en local del blog de DonWeb recorre instalación y requisitos paso a paso. ¿Sirve para algo tan básico como eso? Cuando la alternativa es pelearte con compilaciones a mano, sí.

Qué significa para empresas y equipos en Latinoamérica

Para equipos de la región, el argumento local se refuerza solo: hardware que se compra una vez contra suscripciones en dólares que se mueven con el tipo de cambio, y datos de clientes que conviene no cruzar fronteras de más. El esquema híbrido es el que mejor zafa: modelo local para lo sensible y lo repetitivo, API de frontera para lo excepcional. Y si tu stack necesita infraestructura propia para la aplicación que consume el modelo, un proveedor argentino como donweb.com te ahorra facturación en divisas y soporte en otro horario.

Errores comunes al correr un LLM local

Los mismos tropiezos se repiten en cada hilo de foro, y todos tienen arreglo en minutos. Estos cuatro encabezan la lista.

• Subir num_ctx “por las dudas”: el caché de atención se come la RAM libre y el equipo entra en swap con cada respuesta. La corrección: subir de a poco y mirar el consumo real en cada paso.
• Descargar el cuantizado más chico para que ocupe menos: Q2 y Q3 degradan el modelo hasta hacerlo inútil, y después el modelo se lleva la culpa. Quedate en Q4_K_M, aunque elijas un modelo de menor tamaño.
• Dejar el system prompt y los parámetros por defecto: el Modelfile genérico de Ollama trae configuraciones conservadoras; definir temperatura, repeat_penalty e instrucciones propias cambia la experiencia más que cambiar de modelo.
• Pedir análisis profundo con un prompt de dos líneas: los modelos chicos necesitan contexto, ejemplos y formato de salida explícitos. Con prompts pobres, cualquier 7B parece tonto; con buenos prompts, sorprende.

Preguntas Frecuentes

¿Por qué los LLMs locales se sienten más torpes que los de la nube?

Porque corrés versiones más chicas y cuantizadas con memoria limitada: la nube usa modelos más grandes, sin recortes y con cientos de GB de memoria por nodo. La diferencia se nota en razonamiento complejo y contexto largo; en tareas simples como resumir o traducir, casi no aparece. Sobre eso hablamos en todo lo que hay detrás de Google.

¿La cuantización Q4 arruina la calidad del modelo?

No: Q4_K_M degrada la perplexity entre 1% y 2% mientras multiplica la velocidad por 3,5-3,8 y recorta la memoria a un cuarto, según los benchmarks de presenc.ai (2026). El daño serio empieza más abajo, en Q2 y Q3, donde el modelo pierde coherencia y repite frases.

¿Cuánta GPU necesito para correr un LLM local de verdad?

Para un 7B u 8B cuantizado, una GPU con 8 GB de VRAM alcanza sobrada. Para un 14B tipo Phi-4 conviene una de 12-16 GB, y para un 70B hablamos de 48 GB o más, salvo que repartas capas entre GPU y RAM sabiendo que la velocidad se desploma.

¿Por qué mi modelo local olvida el contexto en conversaciones largas?

Porque la ventana de contexto configurada se llena y muchos runtimes descartan los tokens viejos sin avisarte. Subí num_ctx dentro de lo que tu memoria aguanta o resumí la conversación cada tanto para liberar espacio.

¿Conviene un LLM local o pagar ChatGPT/Claude en 2026?

Si priorizás privacidad, costos predecibles o trabajás sin conexión, local es una inversión que se amortiza con uso intensivo. Si buscás el máximo razonamiento y cero mantenimiento, la suscripción de USD 20/mes sigue siendo la opción más eficiente. La mayoría de los equipos serios termina usando ambos según el caso.

Conclusión

Lo que quedó claro en 2026: la brecha entre un LLM local y la nube ya no es misterio, es ingeniería. Cuantización bien elegida, contexto calibrado, offload completo a GPU y un modelo acorde a la tarea cierran gran parte de la distancia para el uso cotidiano. Lo que no se cierra es el techo de razonamiento de los modelos chicos, y ahí la estrategia híbrida sigue siendo la jugada inteligente. Mi recomendación concreta: probá tu caso de uso con un 7B u 8B en Q4_K_M, medí tokens por segundo y calidad real, y recién después decidí si el problema era el modelo, tu configuración o tu expectativa.

Fuentes

• Level1Techs – Why your local LLM feels dumber than it is (hilo de discusión técnica)
• presenc.ai – Benchmarks de cuantización y calidad en LLMs locales (2026)
• Das Root – Benchmarking de LLMs locales: velocidad, calidad y consumo (abril de 2026)
• Blog DonWeb – Guía para correr LLMs en local
• Hugging Face – Modelos open source para correr en local