LM Studio 2026: instalación, primer modelo y ajustes

¿Cómo acaba uno ejecutando sus propios modelos de IA en local? Para mí empezó por un interés profundo por las GPU y los ordenadores potentes. Tengo una máquina en mi red llamada «hopper» con seis GPU NVIDIA y 256 GB de RAM, y ya la usaba para varias tareas, así que la idea de dedicar parte de ese hardware a un LLM local tenía mucho sentido. LM Studio es lo que acabé usando; me costó un poco averiguarlo la primera vez (sobre todo porque los valores por defecto son incorrectos para uso de programación y nadie te lo dice), pero una vez averigué qué ajustes cambiar y cuáles dejar tranquilos, todo el montaje cuajó en una hora aproximadamente. Así que esto soy yo documentando el proceso.

Navegación rápida

Salta directamente a lo que buscas:

¿Por qué molestarse? | Descargar e instalar | Comprueba tu hardware | Elegir el runtime adecuado | Modo desarrollador | Descargar un modelo | Cuantización explicada | Cargar y configurar | Arrancar el servidor local | Servidores MCP | LM Link | Conectar a Claude | La CLI | Solución de problemas

¿Por qué molestarse en ejecutar modelos en local?

Llegué a esto por tres razones y sospecho que al menos una te aplica a ti también.

La primera es el coste. Ahora mismo estoy en el plan Claude Code Max, pero no creo que el precio actual vaya a durar: estas empresas están perdiendo dinero con los modelos insignia y en algún momento su economía tendrá que cambiar. Tener un modelo local que se ocupe del trabajo rutinario (revisiones de código, esqueletos de tests, mensajes de commit, conversiones de formato) significa que no dependo por completo de cómo decida Anthropic fijar los precios el año que viene. Minimizo mi dependencia de servicios en la nube mientras aprendo de la forma más eficiente posible en mi propio equipo.

La segunda es la privacidad. Algunos trabajos de clientes no pueden salir de la red. Codebases propietarios, herramientas internas, archivos de configuración con credenciales repartidas por el código: he tenido proyectos donde enviar código a cualquier API externa estaba descartado por completo, y un modelo local resuelve ese problema sin trabajo adicional de cumplimiento.

Y la tercera es, sencillamente, no tener límites de uso. He chocado contra los límites de uso y los mensajes de «prompt too long» durante sesiones largas de refactoring más veces de las que me gustaría reconocer, normalmente en el peor momento posible. Mi Qwen3 Coder local no se preocupa por cuántas peticiones le lance, siempre que evite peticiones concurrentes enormes.

Si estás valorando herramientas para trabajo asistido por IA, la versión corta es: LM Studio te da una interfaz gráfica, un catálogo de modelos integrado, soporte multi-GPU y un servidor API. Ollama es CLI-first y más ligero. Yo acabé en LM Studio porque ejecuto varios modelos en varias GPU y la interfaz para gestionar todo eso merece una instalación algo más pesada. Pero ambos funcionan.

Descargar e instalar

Ve a lmstudio.ai y descarga el instalador para tu plataforma: Windows, Mac y Linux están todos cubiertos. La instalación en sí es facilísima, sin dependencias con las que pelearse.

La página principal de LM Studio: descarga para tu plataforma y a funcionar.

A fecha de la versión 0.4.16 (la versión más reciente mientras actualizo esto), LM Studio incluye algo llamado llmster: un daemon headless, el mismo motor de inferencia sin interfaz gráfica. Las versiones recientes 0.4.14, 0.4.15 y 0.4.16 han añadido decodificación especulativa MTP, paralelismo de tensores entre varias GPU, un Engine Protocol en beta que desacopla el motor de inferencia de la interfaz, y un montón de arreglos para el endpoint /v1/messages compatible con Anthropic (que importa si diriges Claude Code desde LM Studio; más sobre esto luego). Iré señalando cada uno en la sección que corresponda.

Ejecuto llmster en hopper (mi servidor de GPU) ya que no tiene monitor conectado. Si esa es tu situación:

# Linux/Mac
curl -fsSL https://lmstudio.ai/install.sh | bash

# Windows (PowerShell)
irm https://lmstudio.ai/install.ps1 | iex

Para esta guía uso la app de escritorio completa. Merece la pena conocer el daemon si acabas queriendo ejecutar un servidor dedicado más adelante; volveré sobre ello más adelante en el artículo.

Comprueba tu hardware

Lo primero: abre LM Studio, ve a Settings > Hardware y mira lo que tienes. LM Studio detecta tu CPU, tu RAM del sistema y cada GPU que encuentre. Los números que te importan son la VRAM (memoria de GPU) y la RAM total del sistema como respaldo.

He preparado una guía aproximada basada en lo que he probado en mi propio hardware y lo que he visto reportar a otros en la comunidad; tu experiencia variará un poco según qué más esté corriendo en la máquina, pero estos números están en el orden de magnitud correcto:

Si tienes más de una GPU, LM Studio puede repartir un modelo entre ellas. En GPUs puedes arrastrar para reordenar la prioridad: pon primero tu tarjeta más rápida con más VRAM. El desplegable Strategy debería estar en «Priority order», que carga primero en tu mejor GPU y rebosa a la siguiente, en lugar de repartirse fino entre todas.

Para cargar el mismo modelo en varias tarjetas, la versión 0.4.15 añadió soporte adecuado de paralelismo de tensores, que reparte los pesos del modelo entre las GPU en lugar de rebosar de una a la siguiente. En hopper eso reduce sustancialmente el tiempo de carga de un modelo 70B, y el throughput de inferencia también sube porque ambas tarjetas trabajan en cada token. Se accede desde el mismo panel de ajustes de GPU; el desplegable Strategy gana una opción «Tensor parallel» en cuanto detecta varias tarjetas compatibles.

Ajustes de hardware en hopper: seis GPU detectadas, RTX 4500 arriba en el orden de prioridad con la mayor VRAM. Arrastra para reordenar.

Para que te hagas una idea, esto es lo que muestra hopper en el Administrador de dispositivos: un Threadripper PRO 5995WX con una mezcla de tarjetas RTX 4500, RTX 4000 y A4000:

No necesitas nada parecido para empezar (yo monté el mío con piezas de eBay). Una sola GPU con 16 GB+ de VRAM es más que suficiente.

Algo que sorprende a la gente: los números de VRAM de esta página muestran tu capacidad total, no lo que está libre ahora mismo. Si tienes un juego corriendo o un navegador consumiendo memoria de GPU, tendrás menos margen del que sugiere la página.

Elegir el runtime adecuado

Ve a Settings > Runtime. Aquí le dices a LM Studio qué motor de inferencia usar, y equivocarte aquí es una de las razones por las que la gente acaba con un rendimiento pésimo sin saber por qué.

La página de Runtime: CUDA 12 llama.cpp es lo que quieres para GPU NVIDIA. Pulsa update si hay una disponible.

• ¿GPU NVIDIA? Quieres «CUDA 12 llama.cpp». Asegúrate de que dice «Latest version» en verde. Si hay un botón de update, púlsalo: llama.cpp se actualiza a menudo y las mejoras de velocidad entre versiones pueden ser significativas.
• ¿GPU AMD o Intel? «Vulkan llama.cpp» es tu opción, y en AMD concretamente el runtime «ROCm llama.cpp» recibió un endurecimiento sustancial multi-GPU en 0.4.16: los bugs de orden de prioridad que hacían inestables las configuraciones multi-tarjeta AMD se han solucionado. El soporte CUDA de NVIDIA sigue siendo el camino más maduro y encontrarás más ayuda de la comunidad si algo va mal, pero la historia de AMD es mucho mejor que hace apenas seis meses.
• ¿Sin GPU? «CPU llama.cpp» funcionará, pero estarás en un dígito de tokens por segundo en cualquier cosa mayor de 7B. Doloroso.
• ¿Apple Silicon? LM Studio usa MLX por defecto, que aprovecha la memoria unificada. Déjalo.

De paso, yo dejaría el toggle de auto-update activado.

Activar el modo desarrollador

Settings > Developer, activa Developer Mode a ON. Hazlo antes de cargar nada.

Developer Mode activado: revela los parámetros avanzados de carga, la configuración MCP, la documentación in-app y las claves de permiso del servidor.

Esto llegó en 0.4.0 y creo que probablemente debería estar activado por defecto: revela los parámetros avanzados de carga del modelo, el editor JSON de MCP, la documentación de la API in-app, las estadísticas de procesamiento en vivo y las claves de permiso del servidor. Sin él, LM Studio oculta la mayoría de los ajustes que necesitarás para programación y uso de API detrás de un muro apto para principiantes.

Entiendo por qué lo hacen. Pero si estás leyendo un artículo sobre conectar LM Studio a Claude Code, no eres la persona a la que hay que proteger de un deslizador de longitud de contexto.

Descargar un modelo

Pulsa Ctrl + Shift + M para abrir la búsqueda de modelos. Arriba verás «Staff Picks» (modelos que el equipo de LM Studio ha probado) y, debajo, subidas de la comunidad desde HuggingFace. Hay muchísimos. Busca «Qwen Coder» y obtendrás cincuenta resultados de distintos uploaders, distintas cuantizaciones y formatos de archivo; si no sabes qué buscas, abruma.

La búsqueda de modelos: he buscado «coder next» y Qwen3 Coder Next está arriba. La insignia verde «Full GPU Offload Possible» significa que cabrá en mi GPU.

Para trabajo de programación, yo empezaría con uno de estos e ignoraría todo lo demás hasta que tengas un punto de referencia:

• Qwen3 Coder 30B: lo que ejecuto la mayor parte del tiempo. Es un modelo Mixture of Experts, así que solo una fracción de los 30B de parámetros está activa en cada petición, lo que significa que cabe en 16-24 GB de VRAM en Q4 K M a pesar de que el número de la cabecera parezca enorme. Excelente para generación de código, revisión y esqueletos de tests.
• GPT-OSS 20B: el modelo de pesos abiertos de OpenAI. Buen todoterreno.
• Devstral Small 2 24B: el modelo de programación de Mistral. Buen compromiso si vas justo de VRAM.

Busca el icono del cohete verde junto a las opciones de descarga. Ese pequeño cohete significa que el modelo cabrá en tu hardware. Sin cohete, nada que hacer: ahórrate la descarga de 40 minutos.

Lo más reciente que merece la pena probar

Algunos lanzamientos más recientes que he empezado a intercalar para tareas específicas, en lugar de como sustituto diario de Qwen3 Coder 30B:

• Qwen 3.6 27B: la nueva generación MoE del equipo de Qwen. LM Studio incluyó soporte nativo en mayo de 2026, incluido uso de herramientas y modo razonamiento. Mejor en tareas de programación complejas multi-paso que Qwen3 Coder 30B; huella de VRAM similar en Q4 K M.
• DeepSeek V4 Pro: actualmente lidera los leaderboards de programación de LiveBench. Clase razonamiento, así que espera salidas más largas pero mejores respuestas en refactorings complicados. Más exigente de VRAM que los modelos Qwen.
• GLM 5.1: buen equilibrio entre velocidad y calidad, especialmente fuerte en Python.
• Kimi K2.6 Thinking: modelo de razonamiento con una ventana de contexto larga. Útil cuando la pregunta necesita la cadena de pensamiento.

Para la mayoría del trabajo del día a día Qwen3 Coder 30B sigue siendo el que uso: es rápido, cabe cómodamente y lleva meses estable. Los modelos más nuevos merecen la pena cuando tienes margen y una tarea para la que encajan.

Si entras verás distintos niveles de cuantización listados como opciones de descarga: Q4 K M, Q6 K, Q8 0 y demás. Esta es la parte donde la mayoría de guías pierde a la gente, y siendo justo, la nomenclatura es atroz, así que no culpo a nadie por liarla.

Cuantización: qué significa Q4 M

Esas etiquetas —Q4 K M, Q6 K, Q8 0, BF16— te indican cuánto se ha comprimido el modelo para caber en hardware de consumo.

Los modelos de precisión completa (BF16 o FP16) guardan cada parámetro con su precisión original y son enormes: un modelo 30B a precisión completa necesita aproximadamente 60 GB de memoria. La cuantización reduce el modelo guardando los parámetros a menor precisión. El compromiso es cierta pérdida de calidad, pero esto es lo que encontré al probarlo en mi propio codebase: la caída para tareas de programación es sorprendentemente pequeña hasta que bajas de Q4. Pasé las mismas tareas de revisión de código por Q6 _K y Q4 K M de Qwen3 Coder y los resultados fueron casi idénticos. Baja a Q3 y empieza a alucinar rutas de import. El salto es apreciable.

_El cohete verde junto a una opción de descarga significa que cabrá en tu GPU. Este está descargando Qwen3 Coder Next en Q6 K: 65 GB, que necesita VRAM seria.

El cohete verde hace las cuentas por ti. Si aparece junto a Q6 _K, ve con ese. Si solo aparece en Q4 K M, ese es tu techo: un modelo que cabe cómodamente en Q4 siempre rendirá más que uno cargado en Q6 pero que está constantemente haciendo swap a la RAM del sistema.

Cargar y configurar

Haz clic en + Load Model en la pestaña Developer, o selecciónalo en el desplegable de modelos en Chat. Se abre el diálogo del loader, y esta pantalla es donde se decide la diferencia entre un montaje que funciona bien y uno que te vuelve loco. La mayoría de los valores por defecto son incorrectos para uso de programación. LM Studio no te lo va a decir.

El loader de modelos: la longitud de contexto, el GPU offload y el uso estimado de memoria están aquí. Estos son los ajustes que importan.

Longitud de contexto

Lo pongo primero porque es el motivo más común por el que los montajes no funcionan, y el modo de fallo consume mucho tiempo.

El valor por defecto suele ser 4.096 tokens. Para chat rápido, bien. ¿Para programación? Ni de lejos. Solo el system prompt de Claude Code ocupa varios miles de tokens, y si conectas LM Studio a Claude Code o a cualquier herramienta que pase prompts grandes, una ventana de contexto de 4k hará que el modelo se quede colgado indefinidamente. Sin mensaje de error, solo silencio. Pasé una cantidad vergonzosa de tiempo depurándolo la primera vez, porque no hay nada en la interfaz que te diga qué ha ido mal: simplemente se queda ahí sin hacer nada.

Define esto en al menos 32.000 tokens. Yo lo ejecuto en 78.000 con Qwen3 Coder porque le paso archivos fuente completos y el contexto más grande le permite retener el archivo completo más el historial de conversación sin truncar. Pero más contexto consume VRAM: vigila el indicador de Estimated Memory Usage en la parte superior del diálogo antes de subirlo.

_La VRAM de tu GPU es un presupuesto fijo repartido en tres: pesos del modelo, ventana de contexto (caché KV) y overhead del sistema. Sube demasiado la longitud de contexto y el modelo se derrama a la RAM del sistema, que es aproximadamente 10 veces más lenta. Por eso un modelo Q6 K con 32k de contexto vuela en 24 GB, pero el mismo modelo a 128k de contexto va a rastras.

GPU offload

Este deslizador controla cuántas capas del modelo se cargan en tu GPU frente a las que se quedan en la RAM del sistema. Súbelo al máximo. La diferencia entre GPU offload completo y parcial es la diferencia entre 40+ tokens por segundo y quizá 2. He visto a gente quejarse de que los modelos locales son «inusablemente lentos» cuando el único problema era este deslizador.

Si no llega al máximo, tu modelo es demasiado grande para tu VRAM en la longitud de contexto que has definido. Baja la longitud de contexto o elige una cuantización más pequeña. No intentes buscar un término medio con GPU offload parcial: el precipicio de rendimiento es demasiado abrupto.

Peticiones en paralelo

Nuevo en 0.4.0: Max Concurrent Predictions tiene por defecto 4. Esto permite a LM Studio atender varias peticiones simultáneas con continuous batching en lugar de encolarlas. Si eres la única persona que golpea el servidor, 4 está bien. Si tienes un equipo conectándose, súbelo. Mantén Unified KV Cache activado (es el valor por defecto): evita que los slots paralelos partan en duro tu VRAM.

Desplázate hacia abajo en el loader para ver los ajustes avanzados: GPU offload, batch size, caché KV, flash attention y número de expertos MoE están aquí. Activa «Show advanced settings» abajo si no los ves.

Ajustes MoE

Si estás cargando un modelo Mixture of Experts como Qwen3 Coder 30B, hay un deslizador Number of Experts en las opciones avanzadas. Qwen3 Coder activa 8 de sus 128 expertos disponibles por token por defecto. Salvo que tengas un motivo concreto para cambiarlo, déjalo estar.

Decodificación especulativa

Nuevo en 0.4.14: LM Studio soporta decodificación especulativa MTP (Multi-Token Prediction) de forma nativa para modelos compatibles, incluida la familia Qwen 3.6. Predice unos tokens por delante en cada forward pass y los verifica de golpe, lo que te da una mejora real de throughput sin el sobrecoste de VRAM de ejecutar un modelo draft aparte junto al principal. Si cargas un modelo que lo soporta, el toggle aparece en los ajustes avanzados: déjalo activado. La mejora es más notable en los modelos MoE más grandes.

Arrancar el servidor local

Ve a la pestaña Developer. Hay un toggle Status arriba: pásalo a ON. A su lado verás la URL Reachable at, normalmente http://localhost:1234.

La pestaña Developer con el servidor corriendo: se ven todos los modelos cargados, la URL reachable y el botón mcp.json.

Una vez en marcha, LM Studio expone varios endpoints de API:

• /v1/chat/completions: compatible con OpenAI. Prácticamente cualquier herramienta que hable el formato OpenAI funciona con esto.
• /v1/messages: compatible con Anthropic. Útil si apuntas Claude Code directamente a LM Studio.
• /v1/chat: la API con estado propia de LM Studio, nueva en 0.4.0. Mantiene el estado de conversación en el servidor, puede usar herramientas MCP configuradas localmente.
• /v1/models: lista los modelos cargados. Chequeo rápido de salud.

Para verificar que funciona:

curl http://localhost:1234/v1/models

En mi máquina ahora mismo eso devuelve Qwen3 Coder 30B, GPT-OSS 20B, un modelo de embeddings Nomic y otros cuantos que estoy probando. Si quieres que otras máquinas de tu red golpeen este servidor —por ejemplo, tienes un portátil que quiere usar la GPU de tu sobremesa—, haz clic en Server Settings y activa «Serve on Local Network».

LM Studio 0.4.0 también añadió permission keys: puedes generarlas desde Settings > Server para controlar quién tiene acceso a la API. Para un montaje casero probablemente excesivo, pero merece la pena configurarlo si estás en una oficina o laboratorio compartido.

Servidores MCP dentro de LM Studio

LM Studio tiene su propio soporte MCP integrado. Haz clic en el botón mcp.json de la pestaña Developer y obtendrás un editor JSON donde puedes conectar servidores MCP que el modelo local puede usar por sí mismo: esto es independiente de la configuración de Claude Desktop, es para el modelo que corre en LM Studio.

El editor mcp.json en la pestaña Developer: mismo formato que la configuración de Claude Desktop. Este tiene un Desktop Commander MCP conectado.

El formato de configuración es el mismo que el de Claude Desktop:

{
  "mcpServers": {
    "brave-search": {
      "command": "npx",
      "args": ["-y", "@anthropic-ai/brave-search-mcp"],
      "env": {
        "BRAVE_API_KEY": "your-key-here"
      }
    }
  }
}

Uso el soporte MCP de LM Studio muy poco, mucho menos de lo que imaginarías. La mayoría de mi trabajo con modelos locales va por Claude Code vía Converly LM, donde Claude se ocupa de la orquestación de herramientas y simplemente delega tareas acotadas al modelo local. Pero si quieres un flujo de IA totalmente local donde nada toque una API en la nube —modelo local haciendo búsquedas web, leyendo archivos, llamando a APIs, todo en tu propio hardware—, así es como lo conectarías.

LM Link: usar modelos en una GPU remota

Esta es una de las funciones más recientes de LM Studio, construida en colaboración con Tailscale, y una de mis cosas favoritas de la versión actual.

La idea es: si tienes una GPU potente en otra máquina en algún punto de tu red (o en cualquier sitio, realmente), LM Link crea un túnel cifrado entre dos instancias de LM Studio para que puedas usar ese modelo remoto como si corriera localmente en la máquina que tienes delante. Sin port forwarding que configurar, sin VPN con la que pelearse, nada expuesto a internet público.

Tengo esto corriendo entre mi PC de desarrollo y hopper: un workstation Threadripper con seis GPU NVIDIA (RTX 4500, un par de RTX 4000 y tres A4000) y 256 GB de RAM. Hopper ejecuta lo pesado, modelos de 70B+ parámetros que no caben en mi máquina de desarrollo. En mi PC de desarrollo, esos modelos simplemente aparecen en el loader como modelos «Linked» y puedo usarlos a velocidad completa por la red local. La latencia en gigabit es apenas apreciable.

Ajustes de LM Link en hopper: activado, con «Allow loading models on this machine» activado para que mi PC de desarrollo pueda disparar cargas de modelos remotamente.

Cómo configurarlo

• Instala LM Studio en ambas máquinas (o llmster en la headless)
• En cada una, ve a Settings > LM Link, activa Enable LM Link a ON
• Inicia sesión en la misma cuenta de LM Link en ambas: usa Tailscale por debajo
• Los modelos cargados de la máquina remota aparecen en tu loader automáticamente

Para servidores headless:

lms login
lms link enable

La conexión está cifrada de extremo a extremo. Ni LM Studio ni Tailscale ven tus prompts ni tus respuestas: solo gestionan el descubrimiento de dispositivos.

LM Studio también integró la app para iOS «Locally» en la malla de LM Link en la versión 0.4.16: la app que adquirieron a principios de año. Así que si estás fuera de casa y quieres golpear el modelo 70B de tu equipo doméstico desde el móvil, ahora funciona sin configuración adicional más allá de iniciar sesión en el teléfono con la misma cuenta de LM Link.

Conectar LM Studio a Claude

Dos formas de conectarlo, según si quieres sustituir a Claude por un modelo local o aumentarlo.

Opción 1: Converly LM (lo que recomiendo)

La arquitectura: Claude Code se queda con el trabajo duro (razonamiento, planificación, cambios multi-archivo), Converly LM intercepta las tareas acotadas y las enruta a tu modelo local vía la API de LM Studio. Claude nunca lee el archivo fuente, de ahí el ahorro de tokens.

Este es un servidor MCP que construí y que se sitúa entre Claude Code y tu modelo local. Claude sigue siendo el arquitecto: razonamiento, planificación, operaciones de archivos, lo que se le da mejor. Converly LM intercepta el trabajo rutinario acotado y lo enruta a tu modelo local. Claude además revisa todo lo que vuelve, así que si el modelo local produce algo raro, lo caza.

claude mcp add converly-lm -e LM_STUDIO_URL=http://localhost:1234 -- npx -y @converly/lm

Escribí un walkthrough completo de este montaje con benchmarks que muestran ahorros de tokens del 86-95 % en tareas típicas de delegación.

Opción 2: Claude Code directo

Puedes apuntar Claude Code directamente al endpoint compatible con Anthropic de LM Studio:

export ANTHROPIC_BASE_URL=http://localhost:1234/v1
export ANTHROPIC_API_KEY=lm-studio

Esto sustituye a Claude por completo por tu modelo local. Merece la pena saberlo: las versiones 0.4.14 y 0.4.15 (mayo y junio de 2026) arreglaron dos bugs antiguos del endpoint /v1/messages —pérdida de prompt cache y un error de system message de «invalid role»— que hacían este camino lo bastante poco fiable como para descartarlo. Con esos arreglos, la ruta directa funciona ya lo bastante bien como para ser una opción real, donde hace seis meses te habría dicho que la ignoraras.

El inconveniente que la mayoría de tutoriales de YouTube omiten: el system prompt de Claude Code ocupa miles de tokens, y tu modelo local tiene que procesar todo eso en cada petición. Necesitas una ventana de contexto de al menos 32k, y aun así será notablemente más lento que la API. He visto a gente probarlo, esperar dos minutos por una respuesta y concluir que los modelos locales no sirven, cuando el problema real es que Claude Code nunca se diseñó para ser ligero en el lado del prompting.

La CLI: y

LM Studio incluye lms, una herramienta de línea de comandos que gestiona la mayoría de lo que hace la interfaz:

lms chat                                    # interactive chat in terminal (new in 0.4.0)
lms get qwen/qwen3-coder-30b-a3b-instruct  # download a model
lms server start                            # fire up the API server
lms runtime survey                          # check what GPUs LM Studio can see
lms runtime update llama.cpp                # update the engine
lms daemon up                               # run headless, no GUI

lms chat merece la pena probarlo: tiene slash commands, gestiona el resaltado de think-blocks y he comprobado que maneja el pegado de bloques de código grandes de forma más fiable que la entrada de la interfaz a veces. También es como interactúo con los modelos en hopper por SSH.

Para despliegues de servidor, llmster es el daemon headless: mismo motor, sin el wrapper de Electron. Lo tengo corriendo como servicio de systemd en hopper y lleva meses sólido. La versión 0.4.14 también introdujo un «Engine Protocol» en beta que desacopla el motor de inferencia de la interfaz como proceso separado. La consecuencia para despliegues headless son actualizaciones del motor más rápidas sin necesidad de redesplegar todo el stack, y la arquitectura de interfaz-hablando-con-motor-vía-protocolo es la misma que usa llmster por debajo. Merece la pena seguirlo aunque todavía no lo actives.

Solución de problemas

El modelo se cuelga y no pasa nada {#el-modelo-se-cuelga-y-no-pasa-nada}

Nueve de cada diez veces este escenario implica que tu ventana de contexto es demasiado pequeña. Claude Code y herramientas similares inyectan system prompts enormes. Sube la longitud de contexto a 32k+ y vuelve a probar. No hay mensaje de error, ni timeout, ni nada: simplemente se queda ahí en silencio y te quedas preguntándote si el modelo ha crasheado, si se ha muerto el servidor o si se ha caído tu red. Desesperante.

Avanzando a 1-2 tokens por segundo

Prueba a revisar los ajustes de GPU Offload en el loader del modelo. Si no está al máximo, el modelo está corriendo en CPU. A veces LM Studio no detecta bien las GPU en sistemas multi-GPU y pasa a CPU sin avisarte. Puede que simplemente estés ejecutando un modelo que necesita tu RAM y VRAM, así que el modelo ser demasiado grande para tu VRAM de GPU podría ser el problema. Apunta a modelos que ocupen alrededor del 80 % de tu VRAM disponible para dejar margen.

Caídas a mitad de la generación

Has sobreasignado tu VRAM. El estimador de memoria del loader es una funcionalidad beta y no tiene del todo en cuenta el crecimiento de la caché KV durante generaciones largas. Baja la longitud de contexto o cambia a una cuantización más pequeña. Prefiero un Q4 K M que cabe cómodamente que un Q6_K que crashea cada tercera petición.

Respuestas truncadas

Algunos modelos —Qwen3 y GLM en particular— emiten bloques de razonamiento ... antes de la respuesta real, y esos cuentan contra tu presupuesto de max_tokens. Desactiva el thinking en los ajustes de chat o sube max_tokens; esto puede descolocarte durante un rato. GLM, por ejemplo, escupirá encantado 400-500 tokens de <thinking> antes de una respuesta.

Si quieres llevarlo más allá y empezar a enrutar tareas automáticamente entre Claude y tu modelo local, echa un vistazo a cómo configuré Converly LM. Esa es la pieza que ata todo esto en un flujo de trabajo en condiciones. Ponte en marcha porque, como prometí, hay más en camino.