Algo inusual en este blog: aquí no tenemos prácticamente nada que venderte. Somos Geonode, vendemos proxies, y ejecutar un modelo de lenguaje en tu propio ordenador no requiere absolutamente nada de eso. Sin proxies, sin ancho de banda, sin cuenta. La relación es indirecta: los modelos locales suelen implementarse con recuperación de datos propios, y si esos datos proceden de la web pública, alguien tiene que recopilarlos. Esa es nuestra parte del proceso y está realmente separada del modelo. Así que lee esto como una guía escrita por personas que no tienen ningún interés en qué modelo elijas, lo cual es una postura más infrecuente de lo que debería ser en este ámbito.
Qué te ofrece el servicio «local» y cuánto cuesta
Vale la pena ser concreto, porque ambos aspectos suelen exagerarse.
Qué obtienes. Los datos nunca salen de tu equipo, lo cual, en el caso de trabajos regulados, no es una preferencia, sino un requisito. No hay coste por token, por lo que el uso intensivo o experimental es gratuito una vez adquirido el hardware. No hay límites de velocidad ni dependencia del tiempo de actividad de terceros. Estabilidad total de la versión: el modelo no cambia sin que tú lo decidas, lo cual es muy importante si has ajustado las indicaciones en función de su comportamiento. Y la capacidad de realizar un ajuste fino con tus propios datos sin tener que enviarlos a ningún sitio.
Lo que pagas. Capacidad, principalmente. Los mejores modelos locales de 2026 son realmente buenos, pero siguen estando por detrás de los modelos alojados de vanguardia en lo que respecta al razonamiento complejo. El hardware, que supone un coste de capital real. La velocidad, a menos que hayas adquirido un hardware de alto rendimiento. Tu propio tiempo dedicado a la configuración, las decisiones de cuantificación y la integración. Y la electricidad, que no es poca cosa para una máquina sometida a una carga sostenida.
El enfoque que lleva a la gente por mal camino es tratar esto como una comparación de costes. Si envías unos cientos de miles de tokens al mes a una API alojada, los modelos locales no te ahorrarán dinero: el hardware cuesta más que años de ese uso. Los modelos locales ganan en privacidad, control y estabilidad, o en volúmenes muy elevados. Si ninguno de esos casos se aplica a tu situación, tampoco lo hará la parte económica.
La cuestión del hardware lo decide todo
Antes de fijarte en ningún modelo, calcula cuánta VRAM necesitas. Todo lo demás depende de ello.
| Memoria disponible | Qué funciona sin problemas | Expectativas realistas |
|---|---|---|
| 8 GB | Modelos de 4B–8B, cuantificados | Adecuado para resúmenes, extracción de información y chat sencillo |
| 12–16 GB | Modelos de 12B–14B cuantificados, MoE con conjuntos activos pequeños | Asistente general sólido, ayuda decente para la programación |
| 24 GB | MoE de clase 30 mil millones, cuantificados densos de 32 mil millones | Verdaderamente capaz en la mayoría de las tareas cotidianas |
| 48 GB | 70 mil millones cuantificados | Cerca de la calidad de los modelos de gama media alojados |
| 80 GB | MoE de clase 120 mil millones con cuantificación nativa | Lo máximo que puede ofrecer una sola tarjeta |
Hay dos factores que hacen que esta ecuación te favorezca.
Las arquitecturas de mezcla de expertos (Mixture-of-experts). Estas tienen un gran número total de parámetros, pero solo activan una fracción por token. gpt-oss-120b tiene 117 mil millones de parámetros en total y 5,1 mil millones activos; La ficha del modelo de OpenAI indica que cabe «en una sola GPU de 80 GB (como la NVIDIA H100 o la AMD MI300X)» utilizando la cuantificación MXFP4 de los pesos de los expertos. gpt-oss-20b tiene un total de 21 000 millones, 3 600 millones activos, y funciona «con 16 GB de memoria». Se obtienen las ventajas de calidad de un modelo más grande con el coste de memoria y velocidad de uno mucho más pequeño.
Memoria unificada de Apple Silicon. En un Mac, la memoria del sistema es la memoria de la GPU. Un equipo con 64 GB de memoria unificada ejecuta modelos que requerirían una tarjeta que la mayoría de la gente no posee. El rendimiento es inferior al de una GPU discreta de capacidad equivalente, pero el límite máximo de capacidad es mucho mayor en relación con el precio.
Ten en cuenta también el contexto. Los pesos del modelo no lo dicen todo: la caché KV crece con la longitud del contexto y puede consumir varios gigabytes en entradas largas. Un modelo que cabe en un contexto de 4K puede que no quepa en uno de 128K.
Los modelos que vale la pena ejecutar en 2026
Qwen3 es la familia más útil para la implementación local, principalmente porque abarca todo el rango de tamaños con un comportamiento coherente. La colección de Hugging Face incluye modelos densos de 0,6 mil millones, 1,7 mil millones, 4 mil millones, 8 mil millones, 14 mil millones y 32 mil millones, además de las variantes de mezcla de expertos 30 mil millones-A3B y 235 mil millones-A22B, con versiones cuantificadas en los formatos FP8, GGUF, AWQ, GPTQ y MLX.
La ficha del modelo Qwen3-8B recoge las características más relevantes: licencia Apache 2.0, 32 768 tokens de contexto nativo que se amplían a 131 072 con el escalado YaRN, y «compatibilidad con más de 100 idiomas y dialectos». Su característica distintiva es la posibilidad de alternar, en un mismo modelo, entre el modo «thinking» (para tareas que requieren un gran esfuerzo de razonamiento) y el modo «non-thinking» (para un diálogo eficiente).
Un detalle práctico de esa ficha que suele pasarse por alto: los ajustes de muestreo son importantes, y los valores recomendados varían según el modo: temperatura 0,6, top-p 0,95 y top-k 20 para el modo de reflexión; temperatura 0,7, top-p 0,8 y top-k 20 en los demás casos. Se desaconseja expresamente la decodificación «greedy» en el modo de pensamiento. Si un modelo rinde peor de lo esperado, comprueba tus parámetros de muestreo antes de culpar al modelo.
Gemma 4 de Google es el lanzamiento más destacado para cualquiera que antes se sintiera desanimado por la licencia de Gemma, ya que ahora es Apache 2.0. La ficha del modelo enumera cinco tamaños —E2B, E4B, 12B, 26B, A4B y 31B— con «una ventana de contexto de 128K, mientras que los modelos medianos admiten 256K», compatibilidad multilingüe en «más de 140 idiomas» y entrada de texto e imágenes con soporte de audio en los modelos E2B, E4B y 12B. La entrada de audio nativa en un modelo pequeño de peso abierto es poco habitual y merece la pena tenerla en cuenta si ese es tu caso de uso.
gpt-oss, de OpenAI, cubre ambos extremos. El 20B cabe en una máquina de 16 GB; el 120B cabe en una sola tarjeta de 80 GB. Ambos están bajo licencia Apache 2.0, descrita en las fichas de los modelos como una «licencia Apache 2.0 permisiva: compílalos libremente sin restricciones de copyleft ni riesgo de patentes». El modelo de 20 mil millones está pensado para «una menor latencia y casos de uso locales o especializados», con trabajo de agente, llamada a funciones y ejecución de código entre las aplicaciones indicadas.
DeepSeek-R1 sigue siendo la referencia para los modelos de razonamiento abierto y cuenta con licencia del MIT, que, según indica la ficha del modelo, «admite el uso comercial y permite cualquier modificación y obra derivada». Para el uso local, las versiones destiladas son más importantes que el modelo completo: Las versiones destiladas basadas en Qwen de 1.5B, 7B, 14B y 32B, y las basadas en Llama de 8B y 70B, todas ellas ajustadas con «800 000 muestras seleccionadas con DeepSeek-R1». Las versiones destiladas de 14 mil millones y 32 mil millones son las opciones más prácticas para el hardware de consumo.
Llama sigue siendo, con diferencia, la familia más descargada: la biblioteca de Ollama muestra que llama3.1 tiene 119,1 millones de descargas y llama3.2, 82,1 millones, por delante de deepseek-r1 con 92,2 millones y gemma3 con 40 millones. La popularidad implica disponer de las mejores herramientas, el mayor número de ajustes realizados por la comunidad y más material para la resolución de problemas, lo que supone una ventaja real independiente de la capacidad bruta.
Y no hay que pasar por alto los modelos integrados. «nomic-embed-text» ocupa el tercer puesto en la biblioteca de Ollama con 84,2 millones de consultas, lo que pone de manifiesto hasta qué punto el uso local de los LLM consiste, en realidad, en la recuperación de información de documentos privados más que en el chat.
Las licencias importan más que los índices de referencia
Esta es la sección que evita que la gente cometa un error costoso, y que habitualmente se omite en las comparaciones de modelos.
El concepto de «pesos abiertos» no es algo único. Los modelos anteriores se dividen en tres grupos:
Apache 2.0 — Qwen3, Gemma 4, gpt-oss y las versiones de DeepSeek basadas en Qwen. Permiso amplio, uso comercial permitido, sin restricciones de ámbito de uso y concesión de patente incluida. Si vas a comercializar un producto, esta es la opción que te conviene.
MIT — El propio DeepSeek-R1. Igualmente permisiva, que admite explícitamente el uso comercial, la modificación y las obras derivadas.
Licencias personalizadas de la comunidad: la familia Llama y, por herencia, las versiones de DeepSeek basadas en Llama, que cuentan con las licencias Llama 3.1 y Llama 3.3, respectivamente. Estas permiten muchas cosas, pero no son Apache ni MIT: incluyen políticas de uso aceptable, requisitos de atribución y condiciones que se activan cuando se alcanza un gran número de usuarios. Por lo general, están bien. No están bien automáticamente, y merece la pena leerlas antes de crear un producto basado en ellas.
El cambio de Gemma 4 a la licencia Apache 2.0 es significativo precisamente porque Gemma utilizaba anteriormente una licencia personalizada. Si ya habías evaluado la familia y la descartaste por motivos de licencia, ese motivo ya no es válido.
Dos aspectos prácticos. En primer lugar, comprueba la licencia del modelo concreto que estés utilizando, no la de la familia: los «distills» de DeepSeek son el ejemplo más claro, ya que diferentes «distills» de la misma versión tienen licencias distintas en función de su modelo base. En segundo lugar, si estás realizando ajustes, lee lo que dice la licencia sobre obras derivadas y sobre la denominación, ya que algunas exigen que la obra derivada conserve el nombre original.
Las herramientas: Ollama, llama.cpp, LM Studio, vLLM
| Herramienta | Ideal para | Interfaz | Ventajas e inconvenientes |
|---|---|---|---|
| Ollama | Primeros pasos, desarrollo local | CLI + API HTTP | Menor control sobre los detalles de la inferencia |
| llama.cpp | Máximo control, hardware poco habitual | CLI + servidor | Hay que configurarlo todo uno mismo |
| LM Studio | Usuarios sin conocimientos técnicos, experimentación | GUI | Menos adecuado para la automatización |
| vLLM | Dar servicio a múltiples usuarios | API HTTP | Requiere un hardware de GPU adecuado |
Ollama es la opción predeterminada adecuada para la mayoría de los usuarios. Un solo comando para descargar un modelo, un punto final HTTP compatible con OpenAI y valores predeterminados de cuantificación razonables. La limitación es que, cuando quieras ajustar con precisión los parámetros de inferencia, acabarás por superarla.
llama.cpp es la base sobre la que se construye Ollama, y utilizarlo directamente te ofrece un control total sobre la cuantificación, la gestión del contexto, la descarga de capas a la GPU y los subprocesos de la CPU. También es la opción mejor adaptada para hardware poco habitual: tarjetas antiguas, sistemas solo con CPU o Apple Silicon.
LM Studio es una aplicación de escritorio con búsqueda de modelos y una interfaz de chat. Si la persona que utiliza el modelo no es desarrolladora, esta es la solución.
vLLM es un sistema de servicio más que una herramienta local, diseñado para ofrecer un alto rendimiento con procesamiento por lotes continuo. Si estás ejecutando un modelo para un equipo en lugar de para ti mismo, este es el nivel al que debes pasar, y requiere hardware de GPU real.
Un patrón útil: desarrolla utilizando el punto final de Ollama compatible con OpenAI y, si más adelante necesitas ofrecer el servicio correctamente, pasa a vLLM utilizando la misma interfaz. El código de tu aplicación no cambia.
Cuantización sin simplificaciones
La cuantización reduce la precisión numérica de los pesos, por lo que el modelo necesita menos memoria. Así es como un modelo que, en teoría, necesita 60 GB, puede ejecutarse en una tarjeta de 24 GB.
| Formato | Tamaño frente a FP16 | Calidad | Cuándo utilizarlo |
|---|---|---|---|
| FP16/BF16 | 100 % | Referencia | Si dispones de memoria de sobra |
| Q8 | ~50 % | Prácticamente indistinguible | Si dispones de espacio y quieres la máxima calidad |
| Q5_K_M | ~35 % | Muy buena | Un equilibrio razonable |
| Q4_K_M | ~28 % | Buena, ligera degradación | El valor predeterminado habitual |
| Q3 e inferiores | ~20 % | Degradación apreciable | Solo cuando no cabe nada más |
La regla que se cumple en la práctica: un modelo más grande con una cuantificación más intensa suele superar a un modelo más pequeño con una cuantificación más ligera. Un modelo de 32B en Q4 suele ofrecer un rendimiento superior al de uno de 14B en Q8 con el mismo presupuesto de memoria. La excepción se da en el extremo: por debajo de Q3, la degradación se vuelve tan grave que la relación se invierte.
Ten en cuenta también que MXFP4, utilizado para los pesos expertos de gpt-oss, es un caso en el que la cuantificación forma parte del diseño del modelo, en lugar de ser algo aplicado posteriormente. Por eso las cifras de memoria en esas fichas de modelo son tan bajas.
Realiza pruebas con tu propia carga de trabajo en lugar de fiarte de una tabla, incluida esta. La cuantificación degrada las diferentes capacidades de forma desigual, y un nivel que pasa desapercibido para la síntesis puede resultar evidente para la generación de código.
Expectativas realistas frente a la frontera
Establecerlas correctamente evita la mayor parte de las decepciones.
Ámbitos en los que los modelos locales son realmente competitivos: resumen, extracción, clasificación, traducción, autocompletado sencillo de código, redacción y respuesta a preguntas mejorada mediante la recuperación de información en tus propios documentos. Para todas estas tareas, basta con un modelo de 14 000 a 32 000 millones de parámetros bien elegido, y la diferencia con respecto a un modelo de vanguardia alojado en la nube es tan pequeña que te costaría notarla.
Ámbitos en los que la brecha sigue siendo real: razonamiento largo de varios pasos, trabajo complejo de tipo «agente», grandes bases de código que requieren una comprensión genuina, tareas que necesitan un conocimiento amplio y actualizado del mundo. La brecha se ha reducido considerablemente, pero no se ha cerrado.
Donde los modelos locales ganan sin lugar a dudas: cualquier caso en el que los datos no puedan salir de tu infraestructura, y cualquier caso con un volumen lo suficientemente elevado como para que predomine la tarificación por token. No se trata de argumentos sobre la capacidad, pero suelen ser los decisivos.
Otra expectativa que hay que tener en cuenta: la velocidad. En hardware de consumo, un modelo de 32 000 millones de parámetros genera tokens a una velocidad adecuada para una interfaz de chat, pero lenta para cualquier tarea por lotes. Si vas a procesar diez mil documentos, mide el rendimiento antes de decidirte por una arquitectura.
Cuándo conviene limitarse a utilizar una API
La sección que rebate la premisa.
Cuando el volumen es bajo. Unos pocos cientos de miles de tokens al mes suponen un coste muy reducido en una API alojada y nunca justificarán la compra de una GPU. Comprar hardware para evitar una factura pequeña es una mala inversión, a menos que ese hardware tenga otros usos.
Cuando necesitas capacidad de vanguardia. Si la tarea requiere realmente el razonamiento más potente disponible, los modelos locales aún no están a la altura y fingir lo contrario supone perder semanas.
Cuando no dispones del hardware necesario. Ejecutar un modelo de 7.000 millones de parámetros en una tarjeta de 8 GB porque es lo único que tienes, y luego concluir que los modelos locales no son buenos, es una decepción habitual y evitable. El modelo que puedes ejecutar no es el modelo del que has leído.
Cuando el mantenimiento supone un coste que no puedes asumir. Los modelos se actualizan, las herramientas cambian, los formatos de cuantificación evolucionan. Una API alojada es un problema operativo ajeno.
Cuando estás creando un prototipo. Desarrolla basándote en una API, comprueba que el producto funciona y, a continuación, evalúa si merece la pena pasarte a un entorno local. Hacerlo al revés significa resolver problemas de hardware antes de saber si la idea es buena.
Y el caso en el que no hay ambigüedad: si tu restricción es que los datos no deben salir de tus instalaciones, nada de lo anterior se aplica. En esa situación, el entorno local no es una preferencia, y la única cuestión es qué modelo se adapta a tu hardware.
Preguntas frecuentes
¿Cuál es el mejor LLM local en 2026?
No hay una respuesta única, pero Qwen3 es la familia más útil para el despliegue local, ya que abarca desde 0,6 mil millones hasta 235 mil millones con un comportamiento consistente y una licencia Apache 2.0. Adapta el tamaño a tu VRAM: 8 000 millones para 8-16 GB, el modelo «mixture-of-experts» de 30 000 millones-A3 000 millones para 24 GB y gpt-oss-120b si tienes una tarjeta de 80 GB.
¿Cuánta VRAM necesito para ejecutar un LLM local?
Con 8 GB se pueden ejecutar modelos útiles de entre 4 mil millones y 8 mil millones cuantificados. 16 GB cubren holgadamente modelos de entre 12 mil millones y 14 mil millones, o el gpt-oss-20b, que según la documentación funciona con 16 GB. 24 GB te permiten utilizar modelos de la clase de 30 mil millones. Las arquitecturas de «mezcla de expertos» te favorecen en este sentido, ya que solo se activa una fracción de los parámetros por token.
¿Son los LLM locales tan buenos como ChatGPT o Claude?
No en las tareas de razonamiento más complejas, no. Para la síntesis, la extracción, la clasificación, la traducción y la recuperación de información en tus propios documentos, un buen modelo local de 14B a 32B se acerca lo suficiente como para que la diferencia rara vez importe. La brecha se está reduciendo, pero aún no se ha cerrado.
¿Qué LLM locales puedo utilizar con fines comerciales?
Qwen3, Gemma 4 y gpt-oss están bajo licencia Apache 2.0. DeepSeek-R1 está bajo licencia MIT. Todos permiten el uso comercial sin restricciones en cuanto al ámbito de aplicación. La familia Llama utiliza licencias comunitarias personalizadas que permiten muchas cosas, pero conllevan condiciones que vale la pena leer. Comprueba el modelo específico en lugar de la familia: las versiones destiladas de DeepSeek basadas en Qwen están bajo licencia Apache 2.0, mientras que las basadas en Llama tienen licencias de Llama.
¿Cuál es la forma más sencilla de ejecutar un LLM localmente?
Ollama para desarrolladores: un solo comando para descargar un modelo y un punto final HTTP compatible con OpenAI. LM Studio si prefieres una interfaz gráfica y no quieres usar la línea de comandos. Ambos se encargan de la cuantificación y la detección de hardware por ti.
¿La cuantificación afecta a la calidad?
En cierta medida, y de forma desigual. Q8 es prácticamente indistinguible de la precisión total. Q4_K_M es el valor predeterminado habitual, con una ligera degradación que la mayoría de la gente no nota. Por debajo de Q3, la diferencia se hace evidente. Por regla general, un modelo más grande en Q4 supera a uno más pequeño en Q8 con el mismo presupuesto de memoria.
¿Puedo ejecutar un LLM local en un Mac?
Sí, y a menudo mejor que en un PC de precio similar, ya que la memoria unificada de Apple Silicon está disponible para la GPU. Un Mac de 64 GB ejecuta modelos que requerirían una tarjeta que la mayoría de la gente no tiene. El rendimiento es inferior al de una GPU discreta, pero el límite máximo de capacidad es mucho mayor por libra.
¿Necesito proxies o una configuración de red especial para los LLM locales?
No. El modelo se ejecuta en tu equipo y no realiza solicitudes de red. La red solo entra en juego si estás recopilando datos de la web para recuperarlos, lo cual es una parte totalmente independiente del proceso.
Conclusión
Elige primero por la memoria, luego por la licencia y, por último, por las pruebas de rendimiento. Este orden es el contrario al que se suele seguir en la mayoría de las comparativas, pero es el que da como resultado un sistema que funciona.
Tu VRAM determina qué modelos son siquiera candidatos, y las arquitecturas de «mezcla de expertos» han hecho que esa restricción sea considerablemente menos limitante: 117 000 millones de parámetros en una sola tarjeta de 80 GB, o 21 000 millones en una de 16 GB, no eran propuestas realistas hace mucho tiempo. La licencia determina si puedes distribuir lo que creas, y el cambio de Gemma 4 a Apache 2.0 significa que el nivel permisivo ahora cubre la mayoría de las opciones sólidas. Las pruebas de rendimiento quedan en último lugar porque, dentro de una misma clase de tamaño, las diferencias son pequeñas y tu carga de trabajo específica no coincidirá con la tabla de clasificación de todos modos.
El resumen honesto de la situación actual es el siguiente: para trabajos con restricciones de privacidad, para grandes volúmenes y para cualquier caso en el que necesites que el modelo deje de cambiar bajo tus pies, el modelo local es ahora una opción claramente buena, en lugar de un compromiso. Para un uso ocasional con capacidades de vanguardia, todavía no lo es, y una API alojada sigue siendo la respuesta más sensata.
