Ejecutando LLMs en local: LM Studio.

Continuando la serie de ejecución de LLMs en local, en este post veremos una alternativa a Ollama también extendida en el mercado para poder hacernos una idea de sus diferencias y similitudes. En este caso hablaremos de LM Studio y su funcionamiento.

¿Quieres echarle un vistazo a los posts anteriores de la serie?

• Ejecutando LLMs en local: primeros pasos con Ollama
• Ejecutando LLMs en local: Ollama avanzado

¿Qué es LM Studio?

Igual que Ollama, LM Studio es una aplicación para gestionar LLMs de forma local, pudiendo instalarlo en los distintos sistemas operativos (macOS, Linux y Windows) con los correspondientes requisitos mínimos del sistema. Entre sus funcionalidades clave se encuentran:

• Aplicación para ejecución y gestión de LLMs en local.
• Interfaz de chat.
• Búsqueda y descarga a través de Hugging Face.
• Servidor local que escucha en endpoints compatibles con OpenAI.

Instalación

En este caso ejecutamos LMStudio con la instalación de Linux. Una vez descargado el programa (puede ser necesario descargar Chrome y darle los permisos adecuados al instalable con el comando chmod +x LM-Studio-0.3.23-3-x64.AppImage), se ejecutará el siguiente comando:

./LM-Studio-0.3.23-3-x64.AppImage --no-sandbox

Con él, ya se desplegará la aplicación:

Siguiendo los pasos del instalador, se podrá seleccionar el nivel de personalización que queramos:

Y seguidamente, nos encontraremos con la interfaz de chat (en caso de aparecer un paso para descargar un modelo directamente, se puede omitir):

Además de poder buscar modelos en la sección correspondiente del propio programa, dentro de la página de LMStudio también se puede encontrar un listado de modelos disponibles con su descripción y posibles configuraciones:

Comandos CLI

LM Studio proporciona una CLI para interactuar con los modelos por comandos. La CLI es una de las secciones que se incluyen en la interfaz gráfica:

Otra de las opciones es instalar la CLI directamente en nuestro sistema para poder ejecutarla desde la terminal. Esta es la opción que seguiremos en este artículo a través del sistema operativo Ubuntu. Para ello se deberá ejecutar el comando:

npx lmstudio install-cli

Los comandos disponibles en LM Studio son:

1. LOAD

Comando que carga un modelo en memoria. Se le pueden informar parámetros como la longitud de contexto, la desactivación de la GPU o el TTL. Hay que indicar que no existe un comando de interacción directa con el modelo cargado a través de la CLI, sino que se carga dicho modelo para que esté disponible de cara a la interacción en la interfaz gráfica.

lms load google/gemma-3-1b

lms load google/gemma-3-1b --context-length 4096 

lms load google/gemma-3-1b --gpu off

lms load google/gemma-3-1b --ttl 3600

2. UNLOAD

Comando que descarga un modelo en memoria. Se le puede indicar la opción “--all” para descargar todos los modelos.

lms unload google/gemma-3-1b

lms unload --all

3. GET

Comando para buscar y descargar modelos de los repositorios remotos. Si no se indica el nombre del modelo, se muestran algunos modelos recomendados. Los modelos descargados habitualmente se encuentran en el directorio ~/.cache/lm-studio/ o ~/.lm-studio/models.

lms get google/gemma-3-1b

lms get --mlx #filtrado por el formato del modelo mlx

lms get --gguf #filtrado por el formato del modelo gguf

lms get --limit 5 #limitar los resultados

4. SERVER START

Comando para iniciar el servidor local de LM Studio, pudiendo especificar el puerto y habilitar el soporte para CORS.

lms server start

lms server start --port 3000

lms server start --cors

5. SERVER STATUS

Comando que indica el estado actual del servidor local de LM Studio además de su configuración.

lms server status

lms server status --verbose

lms server status --quiet

lms server status --log-level debug

7. SERVER STOP

Comando para parar el servidor local.

lms server stop

7. LS

Comando que muestra los modelos descargados en local con información como el tamaño, arquitectura y parámetros.

lms ls

lms ls --llm #solo muestra los modelos de tipo LLM

lms ls --embedding #solo muestra los modelos de tipo embedding

lms ls --detailed

lms ls --json

8. PS

Comando que lista los modelos cargados en memoria.

lms ps

lms ps --json

9. CLONE

Comando para descargar los ficheros model.yaml (este fichero se comenta con más detalle en una sección posterior), README y otros ficheros de metadatos (no descarga los pesos del modelo).

lms clone google/gemma-3-1b

10. LOG STREAM

Comando que permite visualizar los prompts que se envían exactamente al modelo.

lms log stream

11. PUSH

Comando que empaqueta el contenido del directorio actual y lo sube al Hub de LM Studio para poder compartir modelos con los demás usuarios.

lms push

API

Como en otras herramientas, nos encontramos con dos tipos de endpoints API: los compatibles con OpenAI y los propios. Esta funcionalidad es importante especialmente desde el punto de vista de un perfil de desarrollo para poder realizar integraciones con las aplicaciones.

Endpoints compatibles con OpenAI

En este caso, los endpoints disponibles son:

• /v1/models: lista los modelos que están cargados actualmente, igual que el comando lms ps.

• /v1/chat/completions: envía una interacción de chat en la que se recibe la respuesta del asistente. Se pueden indicar múltiples parámetros como temperature, stream, seed, etc.

• /v1/embeddings: permite obtener los embeddings de un texto.

• /v1/completions: respuesta del modelo al input del usuario. Este endpoint ya está deprecado por OpenAI pero LM Studio lo mantiene por cuestiones de compatibilidad.

Endpoints propios

Es importante remarcar que esta es una funcionalidad en fase beta y que requiere una versión de LM Studio superior a la 0.3.6. Los endpoints disponibles son:

• /api/v0/models: lista los modelos cargados y descargados.

• /api/v0/models/{model}: responde con la información de un modelo concreto.

• /api/v0/chat/completions: envía una interacción de chat en la que se recibe la respuesta del asistente.

• /api/v0/completions: respuesta del modelo al input del usuario.

• /api/v0/embeddings: permite obtener los embeddings de un texto.

Además de las formas de interacción vistas anteriormente (interfaz, CLI y API), existen sdks para Python y Typescript para poder realizar llamadas directamente a LMStudio a través de métodos y funciones preconfigurados.

Model.yaml

LM Studio también está construyendo (todavía en fase borrador) su forma centralizada y estandarizada de gestionar los distintos modelos. En este caso, lo hace a través de un fichero en formato yaml, permitiendo describir un modelo y todas sus variantes, metadatos personalizados o incluso una lógica personalizada. De esta forma consigue delegar la responsabilidad al runtime para que seleccione cuál es la variante del modelo adecuada para descargar y ejecutar.

Existen varias secciones para la construcción de un model.yaml:

• Model (obligatorio): instrucción con la identificación del modelo en el formato <organización/nombre>.

model: google/gemma-3-1b

• Base (obligatorio): apunta a los archivos de modelos concretos para el modelo “virtual” referenciado. Cada entrada tiene una clave única y una o varias fuentes desde las que descargar el fichero que pueden ser:
  • Un string referenciando a otro modelo “virtual”.
  • Un array de especificaciones de modelos con sus fuentes.

base:
  - key: lmstudio-community/gemma-3-1B-it-QAT-GGUF
    sources:
      - type: huggingface
        user: lmstudio-community
        repo: gemma-3-1B-it-QAT-GGUF
  - key: mlx-community/gemma-3-1b-it-qat-4bit
    sources:
      - type: huggingface
        user: mlx-community
        repo: gemma-3-1b-it-qat-4bit

• MetadataOverrides: sobreescribe los metadatos del modelo. Su función está asociada a la muestra de funcionalidades del modelo (no se usa para hacer cambios funcionales en el modelo). Los posibles campos son:
  • domain: tipo del modelo (llm, embedding, etc).
  • architecture: array con los nombres de las arquitecturas de los modelos (llama, qwen2, etc).
  • compatibilityTypes: array de los formatos que soporta el modelo (gguf, safetensors, etc).
  • paramsStrings: etiquetas del tamaño de los parámetros (1B, 7B, etc).
  • minMemoryUsageBytes: RAM mínima en bytes necesaria para cargar el modelo.
  • contextLengths: array de los window-size context permitidas.
  • trainedForToolUse: si el modelo soporta el uso de “herramientas” (tool-calling). Los posibles valores son: true, false, mixed.
  • vision: si el modelo soporta el procesado de imágenes. Los posibles valores son: true, false, mixed.

metadataOverrides:
  domain: llm
  architectures:
    - gemma3
  compatibilityTypes:
    - gguf
    - safetensors
  paramsStrings:
    - 1B
  minMemoryUsageBytes: 754974720
  trainedForToolUse: false
  vision: false

• Config: preconfiguraciones para el modelo en tiempo de carga o de ejecución:
  • operation: parámetros en tiempo de inferencia/ejecución.
  • load: parámetros en tiempo de carga.

config:
  operation:
    fields:
      - key: llm.prediction.topKSampling
        value: 20
      - key: llm.prediction.minPSampling
        value:
          checked: true
          value: 0

• CustomFields: campos a configurar propios de cada modelo. La definición consta de las siguientes propiedades:
  • key: identificador único del campo.
  • displayName: nombre que se indicará en la UI.
  • description: explicación de la finalidad del campo.
  • type: tipo de dato (boolean o string).
  • defaultValue: valor inicial.
  • effects: qué efectos se aplican.

customFields:
  - key: enableThinking
    displayName: Enable Thinking
    description: Controls whether the model will think before replying
    type: boolean
    defaultValue: true
    effects:
      - type: setJinjaVariable
        variable: enable_thinking

Para que este ejemplo funcione, la plantilla jinja debe tener definida la variable enable_thinking.

• Suggestions: recomendaciones de configuración en base a ciertas condiciones centradas en la UI. Las propiedades a definir son:
  • message: el texto que se muestra al usuario.
  • conditions: cuando debe aparecer la sugerencia.
  • fields: valores de configuración a aplicar.

suggestions:
  - message: The following parameters are recommended for thinking mode
    conditions:
      - type: equals
        key: $.enableThinking
        value: true
    fields:
      - key: llm.prediction.temperature
        value: 0.6

Comparto aquí un ejemplo de fichero completo.

Es importante indicar que, hasta el momento de la escritura de este post, el model.yaml está enfocado en la personalización de modelos para publicarlos en el Hub de LM Studio y posteriormente poder descargarlos (mediante el comando lms get) y usarlos.

Como por el momento está marcada como una función beta, es posible que en un tiempo esta característica funcione de una forma similar a la ofrecida por Ollama y sus Modelfiles para poder crear y ejecutar dichos modelos personalizados desde el propio pc, sin necesidad de subirlos a un registry o Hub.

Importando modelos externos

También en una fase experimental, LM Studio permite importar modelos en formato GGUF descargados fuera del ámbito del propio LM Studio. Para hacer uso de estos modelos, primero ejecutamos el comando de importación:

lms import ./llama-3.2-1b-instruct-q4_k_m.gguf

Y luego ya podemos ejecutarlo como otro modelo más existente en el sistema.

Conclusiones

Continuando la serie de ejecución de LLMs en local, hemos visto LM Studio como una alternativa a Ollama. LM Studio tiene una serie de funcionalidades muy parecidas a Ollama, además de proporcionar una interfaz de usuario para la interacción y gestión de los modelos, lo que la convierte en una buena opción para ejecutar LLMs en local.

En el próximo post hablaremos sobre una tercera opción: Llamafile. ¡Te leo en comentarios!

Referencias

• Documentación oficial de LM Studio