Cuando LM Studio falla, el mensaje suele decir dónde mirar. Esta guía recoge los fallos que más se notifican en su propio gestor de incidencias, y los del servidor y de lms que recoge su documentación: un modelo que no carga, el guardarraíl de memoria, un contexto que se queda corto, un modelo atascado en la CPU, un motor desfasado, un servidor al que no llega nadie y un comando lms que no aparece.
Hay un silencio muy particular cuando el modelo que tenías tantas ganas de probar te contesta con un error en vez de con una frase. Nos ha pasado a todos. La buena noticia es que los errores de LM Studio son más concretos de lo que parecen, y abajo tienes cada uno con el texto exacto que vas a ver, por qué pasa y cómo se arregla, para la versión estable vigente, la 0.4.26 (publicada el 8 de octubre de 2026 y todavía la última estable el 9 de octubre de 2026). Esta guía se escribió sobre la 0.4.25; las notas de la 0.4.26 no recogen ningún cambio en estos mensajes, y los de lms siguen iguales en su código el 9 de octubre de 2026. La instalación, el arranque del servidor y cómo cerrarlo bien están en nuestra guía para instalar LM Studio en local; esta página empieza donde acaba aquella.
LM StudioFicha del programa
«Failed to load the model»: primero, el error de verdad
Es el mensaje que más se notifica en el gestor de incidencias de LM Studio, y tiene esta pinta:
Failed to load the model
Error loading model.
(Exit code: 18446744072635812000). Unknown error. Try a different model and/or config.Ese número tan largo cambia de un equipo a otro, así que no busques el tuyo en ninguna lista. Lo importante es que se trata de un mensaje genérico con varias causas posibles detrás: falta de memoria, el controlador de la gráfica o un motor demasiado viejo para el modelo. Las secciones de abajo van una por una. La versión 0.4.21 mejoró los mensajes de error de carga de modelos de llama.cpp, así que en la 0.4.26 el texto que te sale suele ser más concreto que en los informes antiguos. Si vas con una versión anterior, actualizar ya es el primer paso.
Antes de cambiar ningún ajuste, mira qué dice el servidor. Desde una terminal, esto va sacando en directo el registro (el log) del servidor de LM Studio:
lms log stream --source serverDéjalo corriendo en una segunda ventana mientras lo vuelves a intentar. Si la terminal no encuentra lms, salta antes a la última sección.
«Insufficient system resources»: el guardarraíl de memoria
LM Studio calcula cuánta memoria necesita un modelo antes de cargarlo y, si la cifra pasa de su límite de seguridad, se para, y lo hace a propósito:
Error: Model loading was stopped due to insufficient system resources. Under the current settings, this model requires approximately 22.92 GB of memory, and continuing to load it would likely overload your system and cause it to freeze. If you think this is incorrect, you can adjust the model loading guardrails in settings.Fastidia, sí, pero es la manera educada de ahorrarte un ordenador más tieso que la mojama. La cifra del mensaje (22,92 GB en este ejemplo) es la estimación del modelo más el contexto que has pedido, «con los ajustes actuales» («under the current settings»). Así que tienes tres salidas: pedir menos contexto, elegir una versión más comprimida o un modelo más pequeño, o ajustar los guardarraíles de carga de modelos (model loading guardrails) en Settings, como sugiere el propio mensaje. La tercera, solo si tienes claro que tu equipo lo aguanta.
Puedes ver la estimación sin cargar nada:
lms load --estimate-only <model_key>
lms load --estimate-only <model_key> --context-length 8192 --gpu maxTe enseña Estimated GPU Memory y Estimated Total Memory, y termina con uno de estos 2 veredictos: This model may be loaded based on your resource guardrails settings. (el modelo puede cargarse con tus guardarraíles) o This model will fail to load based on your resource guardrails settings. (no va a cargar). Si añade Confidence: LOW, toma la cifra como orientativa. Las opciones --context-length y --gpu cuentan en la estimación, así que puedes ir probando tamaños hasta que el veredicto se ponga en verde. El buscador de modelos te da nuestra propia estimación antes incluso de descargar el modelo.
«Context size has been exceeded», y cuánto contexto cabe en 16 GB
Un modelo que ha cargado sin problemas puede pararse a mitad de conversación con esto:
Context size has been exceeded.El contexto (cuánto texto tiene el modelo a la vista) se fija al cargar el modelo. Cuando la conversación lo supera y el ajuste de desbordamiento del contexto está en parar al llegar al límite, LM Studio se detiene; las otras dos opciones recortan el centro de la conversación o descartan los mensajes más antiguos. Su propia documentación avisa de que pasarse del límite hace que el modelo se comporte de forma errática. El arreglo es cargar el modelo con más contexto:
lms load <model_key> --context-length 16384En la aplicación, puedes cambiar los ajustes de carga al cargar un modelo y guardarlos como predeterminados de ese modelo, o fijar esos predeterminados en My Models con el icono del engranaje. Aquí hay dos ajustes que ahorran memoria: Flash Attention, que reduce el uso de memoria, y cuantizar la caché K y V (la de la V exige tener Flash Attention activado). Y un motivo más para ir al día: la versión 0.4.24 arregló que la lista de modelos cargados enseñara una longitud de contexto incorrecta.
Eso sí, más contexto no sale gratis: se paga en memoria al cargar el modelo, y un salto grande te devuelve de cabeza al guardarraíl. ¿Cuánto es «más»? Hemos hecho las cuentas con nuestra propia calculadora para un Mac con 16 GB de memoria unificada, que deja 13,0 GiB de ella para el modelo, con compresión Q4_K_M y la caché a precisión completa (f16):
Mac con M4 y 16 GB unificadosFicha del equipo
| Modelo | 4k | 32k | 64k | Contexto máximo que cabe |
|---|---|---|---|---|
| Qwen3 8B | 5,92 GiB | 10,38 GiB | 15,48 GiB ✗ | 49.152 tokens |
| Gemma 4 12B | 7,68 GiB | 8,65 GiB | 9,75 GiB | 161.792 tokens |
| gpt-oss-20b | 11,60 GiB | 12,78 GiB | 14,13 GiB ✗ | 37.888 tokens |
Memoria total necesaria (archivo del modelo + caché KV + consumo propio del programa) y el contexto más grande que no se sale de los 13,0 GiB disponibles, buscado en pasos de 1.024 tokens. Cálculo de Local AI Scope del 6 de octubre de 2026 (la fila de Gemma 4 12B, del 15 de octubre de 2026): tamaños de archivo medidos, caché KV calculada con la arquitectura de cada modelo, consumo propio estimado. ✗ = no cabe. Es nuestra estimación; lms load --estimate-only te da la de LM Studio.
En una gráfica con 8 GB de VRAM (7,2 GiB libres para el modelo) el margen es mucho menor: Qwen3 8B cabe hasta 12.288 tokens, y Gemma 4 12B y gpt-oss-20b no caben ni a 4k, así que acaban repartidos con el procesador. Lo que nos lleva al siguiente problema.
Respuestas lentas: el modelo va por la CPU o la GPU no aparece
Si las respuestas salen con cuentagotas, palabra a palabra, mientras los ventiladores se preparan para despegar, lo más probable es que el modelo esté corriendo, del todo o en parte, en el procesador. O no cabía en la memoria de la gráfica, o el motor ni siquiera ha visto la tarjeta.
Lo primero, pide el modelo entero en la GPU al cargarlo:
lms load <model_key> --gpu max # todas las capas en la GPU
lms load <model_key> --gpu 0.5 # la mitad
lms load <model_key> --gpu off # ninguna, solo CPUPara saber antes si cabe, ejecuta lms load --estimate-only <model_key> --gpu max: te enseña la memoria de GPU que necesitaría esa carga. Para fijar de una vez por todas la parte de GPU de un modelo, usa el engranaje de My Models. Después, comprueba qué ve cada motor:
lms runtime surveyHace inventario del hardware disponible para los motores seleccionados. Si tu tarjeta no sale en la lista, prueba con otro motor: LM Studio trae motores llama.cpp distintos para distintos tipos de gráfica (como CUDA, Vulkan o ROCm, según tu sistema), y se cambia de uno a otro con lms runtime select o desde la ventana de motores (runtimes) (⌘ Shift R en un Mac, Ctrl Shift R en Windows y Linux). Con una tarjeta de AMD, una actualización del controlador podía dejar a LM Studio enseñando 0 GPU. La versión 0.4.17 arregló que las GPU de AMD no se detectaran tras actualizar el controlador, y que un inventario del hardware con un motor ROCm antiguo lo dejara atascado sin GPU. Si tu tarjeta de AMD sigue sin aparecer en la 0.4.26, actualiza los motores con lms runtime update y vuelve a hacer el inventario, o selecciona el motor Vulkan.
Como referencia, LM Studio recomienda al menos 4 GB de memoria gráfica dedicada y 16 GB de RAM en Windows, y 16 GB en un Mac; en un Mac de 8 GB te pide que te ciñas a modelos pequeños y contextos modestos.
Se abre en YouTube (sin cookies) solo si pulsas.
«No LM Runtime found», o un modelo recién salido que no carga
LM Studio no ejecuta los modelos por sí mismo: se los pasa a un motor, llama.cpp para los archivos GGUF en Mac, Windows y Linux, y MLX en los Mac con Apple Silicon. Los motores se descargan y se actualizan aparte de la aplicación. Eso explica dos mensajes muy habituales. El primero quiere decir que no hay motor para ese formato de archivo:
No LM Runtime found for model format 'gguf'!El segundo aparece cuando el modelo es más nuevo que tu motor. Un modelo GGUF, sin más, no carga, y uno MLX puede decir algo así:
Error when loading model: ValueError: Model type gemma4 not supported.El motor, sencillamente, todavía no conoce esa arquitectura. Y los motores tienen sus propios requisitos de versión: LM Studio 0.4.22, por ejemplo, avisa de que sus nuevos borradores asistentes (assistant drafters) necesitan el motor llama.cpp en la versión 2.29.1 o posterior. En los dos casos el arreglo es instalar o actualizar el motor, desde la ventana de motores (⌘/Ctrl Shift R) o desde la terminal:
lms runtime ls # motores instalados
lms runtime update # actualiza los instalados
lms runtime get # descarga uno
lms runtime select # elige el activoYa que estás, comprueba dos requisitos: MLX solo existe en los Mac con Apple Silicon, así que un modelo MLX no va a cargar en Windows ni en Linux; y en un PC con Windows x64, LM Studio pide un procesador con el juego de instrucciones AVX2.
Se abre en YouTube (sin cookies) solo si pulsas.
El servidor no arranca en el puerto 1234, o los demás equipos no llegan a él
lms server start arranca el servidor y luego comprueba 5 veces que responde. Si no responde nunca, te sale esto:
Failed to verify the server is running. Please try to use another port.El propio mensaje señala al puerto: puede que otro programa lo esté usando. El de serie es el 1234, pero si no le pasas --port, LM Studio repite el último puerto que usaste, y por eso aquí el clásico «pues ayer funcionaba» no demuestra nada. Mira el estado y prueba con otro puerto:
lms server status
lms server start --port 1235lms server status contesta The server is running on port 1234. (está en marcha en el 1234) o The server is not running. (no está en marcha). En Linux, sudo ss -ltnp | grep 1234 te dice qué proceso tiene el puerto.
¿Funciona en tu equipo, pero no desde el portátil de al lado? Es así por diseño: el servidor escucha en 127.0.0.1, así que solo tu propio ordenador puede hablar con él. Para abrirlo a tu red, activa «Serve on Local Network» en la aplicación, o:
lms server start --bind 0.0.0.0El comando te avisa, y va en serio: Server will accept connections from the network. Only use this if you know what you are doing! (el servidor aceptará conexiones de la red; úsalo solo si sabes lo que haces). LM Studio recomienda activar la autenticación siempre que el servidor escuche en algo distinto de 127.0.0.1; la guía de instalación explica cómo crear tokens de API. Si apuntas lms a otra máquina con --host y no contesta nadie, te lo dice: The server does not appear to be running at <host>:<port>.
«lms» no se encuentra, y la AppImage de Linux que no abre
lms viene con la aplicación, pero tiene truco: tienes que abrir LM Studio al menos una vez antes de poder usarlo. Si después de eso tu terminal sigue sin conocer el comando, añádelo a la ruta (el PATH) y abre una ventana de terminal nueva:
# macOS o Linux
~/.lmstudio/bin/lms bootstrap
# Windows, en PowerShell
cmd /c %USERPROFILE%/.lmstudio/bin/lms.exe bootstrapSi lms arranca pero dice Failed to start or connect to local LM Studio API server., es que no ha conseguido despertar a LM Studio: abre la aplicación, o arranca el servicio en segundo plano con lms daemon up si usas LM Studio sin su ventana.
En Linux, si la AppImage no llega ni a abrir, antes de nada mira tu versión. La 0.4.22 arregló el arranque de la AppImage en sistemas sin FUSE 2 y en sistemas donde no está disponible el aislamiento (sandboxing) de Chromium, arregló que lms despertara las instalaciones AppImage y activó las actualizaciones desde la propia aplicación para las instalaciones AppImage y .deb. LM Studio pide Ubuntu 20.04 o posterior, y avisa de que las versiones posteriores a la 22 no están bien probadas.
Mensajes, comandos y valores por defecto de la documentación y el registro de cambios de LM Studio, del código fuente de su línea de comandos lms y de los mensajes que aparecen en su gestor de incidencias, leídos el 6 de octubre de 2026 para la versión 0.4.25 y repasados con el registro de cambios de la 0.4.26 y el código de lms el 9 de octubre de 2026.
¿Usas también Ollama? Sus errores son otros, y sus arreglos también: ¿Ollama no funciona? 9 errores, su mensaje exacto y el arreglo. Y qué manda LM Studio por su cuenta mientras todo esto funciona lo tienes en su ficha: LM Studio: qué manda a casa y si lo puedes auditar.