LM Studio: GUI, MLX and Headless Serving

By the end of this lesson you will be able to say whether LM Studio runs on your track at all, drive it entirely from the command line without opening its window, start it as a headless server on a machine with no screen, point any OpenAI client at it, and decide honestly whether it is the right tool for you or whether you are choosing it because it has buttons.

Everything below was read from the documentation of LM Studio 0.4.23 · verified 2026-09-08.

The shape of the thing

LM Studio is unusual in this course because it is three products in one download: a chat application, a model manager, and a server. The server is the part that matters for everything after Part 9, and it can be run without ever seeing the other two.

One download, three products

the window is optional; the layers below it are not

1. Desktop windowChat, model browser, per-model settings, MCP tool configuration. Optional.optional
2. lms command lineget, ls, ps, load, unload, import, server start/stop/status, log stream, runtime, daemon.
3. llmster daemon"the core of the LM Studio desktop app, packaged to be server-native, without reliance on the GUI".
4. OpenAI-compatible server on port 1234/v1/models, /v1/chat/completions, /v1/completions, /v1/embeddings, /v1/responses.
5. Two enginesllama.cpp for GGUF weights everywhere; MLX for Apple silicon, which the docs describe as "running LLMs using Apple's MLX".
6. Model directory~/.lmstudio/models, laid out as publisher/model/file.gguf.

The two engines are the interesting layer. On a Mac the same model can often be had in two formats, GGUF or MLX, and which one you download decides which engine runs it. Part 8 measures the difference properly; here the point is only that the choice exists and that it is made at download time, not at run time.

Where it runs, and where it does not

Track S — NVIDIA DGX SparkNot supported

The system requirements name x64 for Linux, and the download page offers no Linux aarch64 build. A DGX Spark has nothing to install.

Track S has no LM Studio. The system-requirements page states “Ubuntu 20.04 or newer is required” for Linux and that “On x64, LM Studio ships with AVX2 support by default”; the download page lists Windows x64 binaries and a Mac/Linux install script for the headless daemon, with no aarch64 Linux build named (checked 8 September 2026).

Use llama-server from Part 6 or Ollama from the previous lesson. Read this page for the comparison, because a Mac or a Windows desktop elsewhere in the house may well be running LM Studio and you will need to talk to it.

Track X — AMD Ryzen AI Max+ 395

Supported as an ordinary x64 machine. On Windows the requirements name AVX2 and recommend “at least 4GB of dedicated VRAM”; on Linux, Ubuntu 20.04 or newer, with the page noting that versions newer than Ubuntu 22 are “not well tested”.

The system-requirements page does not name ROCm or Vulkan support, so which backend the llama.cpp engine uses on this chip is a question to answer by looking at the runtime LM Studio selects rather than by reading. That is worth knowing before you assume the integrated graphics processor is being used.

Track M — Apple silicon

The primary track for this tool, and the only one where the MLX engine exists. The requirements are “macOS 14.0 or newer is required” and Apple silicon: “Apple Silicon (M1/M2/M3/M4)”. Intel Macs are not supported at all, which is a stricter rule than Ollama’s, where an Intel Mac runs on the CPU.

16 GB or more of memory is recommended by the same page, with smaller models workable at 8 GB.

Track N — NVIDIA desktop or laptop

Supported on Windows x64 and on Linux x64. This is the track where the graphical model browser is most useful, because the fit question is about a fixed amount of video memory and the browser shows you what it thinks will fit before you spend the download.

!Important

LM Studio is a closed-source application wrapped around open-source engines. The course’s version table records it as proprietary freeware; the engines it runs, llama.cpp and MLX, are separately licensed open-source projects. Confirm the current terms on the vendor’s site before deploying it inside an organisation, because the licence of the application is not the licence of the engines and neither is the licence of the model.

Finding a model, and choosing which file to fetch

The model browser is the part that earns the download for most people, and it is worth understanding what it is doing. It searches the Hugging Face Hub: the documentation says you can search “by keyword (e.g. llama, gemma, lmstudio), or by providing a specific user/model string”, and that “You can even insert full Hugging Face URLs into the search bar”. So it is the same catalogue Part 4 taught you to read, with a different front door. The publisher, the licence and the model card are all still the Hub’s, and the habits from that part still apply: check who published it, check the licence, and prefer the publisher’s own repository to a conversion when both exist.

What the browser adds is the choice of file, presented as a list rather than as a directory listing. Each repository offers several quantisations, and the documentation explains the naming in the same terms this course does — the Q prefix marks “a technique called ‘Quantization’, which roughly means compressing model files in size, while giving up some degree of quality” — and gives one piece of advice: “Choose a 4-bit option or higher if your machine is capable enough for running it.”

That advice matches Part 4’s arithmetic and does not replace it. The browser can tell you whether a file fits in the memory you have right now; it cannot know what context length you intend to configure, and the key-value cache at a long context is frequently larger than the difference between two neighbouring quantisations. Decide the context first, then the quantisation, then let the browser confirm the file fits.

✦Tip

On a Mac you will often see both a GGUF and an MLX conversion of the same model. Download one deliberately rather than whichever appears first, and write down which you chose: comparing them later is Part 8’s lab, and it is a much less interesting comparison if you cannot remember which one you have been using all month.

lms runtime manages the engines themselves, which the documentation describes as being there to “Manage and update the inference runtime”. This matters more than it sounds: the llama.cpp build inside LM Studio is updated on its own schedule, so a model that gains support in llama.cpp upstream this week may need a runtime update here before it loads, and a benchmark run against this tool needs the runtime version recorded alongside the application version.

Driving it without the window

The lms command is installed alongside the application, and the headless installer puts it on a machine that has no application at all:

RunnableAll tracks

install the headless daemon (Linux and macOS)

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

The documented Windows equivalent is irm https://lmstudio.ai/install.ps1 | iex. From there the daily commands are short:

RunnableAll tracks

the whole workflow, no window opened

lms daemon up
lms get qwen3-4b
lms ls
lms load qwen3-4b --context-length 8192 --gpu max
lms ps
lms server start --port 1234

lms get searches and downloads. lms ls lists “the models available on disk” and lms ps lists “the models currently loaded in memory”. lms load takes --context-length and --gpu, documented as --gpu=max|auto|0.0-1.0, plus --identifier to give the loaded instance a name your clients can use. lms unload --all clears memory. lms log stream “monitors incoming and outgoing messages”, which is the fastest way to see what a chat front-end is really sending.

✦Tip

lms load --context-length 8192 is the answer to the problem the Ollama lesson ended on. Where Ollama needs a Modelfile to give an OpenAI client a larger context, LM Studio sets it on the loaded instance, so the same client gets the larger window with no model-building step. That is a genuine ergonomic advantage of this tool and worth knowing about even if you use it on one machine only.

Headless, and what “just in time” means

The headless story is llmster, described in the documentation as “a standalone daemon, no GUI required” and “the core of the LM Studio desktop app, packaged to be server-native, without reliance on the GUI”. On a desktop you can get most of the way there without it: the settings dialogue has a box to “run the LLM server on login”, after which “exiting the app will minimize it to the system tray, and the LLM server will continue to run in the background”.

Just-in-time loading is the behaviour that most often confuses people who come from llama-server. With it enabled, “Calls to OpenAI-compatible /v1/models will return all downloaded models” and an inference call “will load the model into memory if it’s not already loaded”. So a front-end shows you twenty models, all of which appear to be running, and the first message to any of them pays a load. Models loaded this way “will be auto-unloaded from memory by default after a set period of inactivity”, which is the same trade Ollama’s keep-alive makes, arrived at from the other direction.

✕Common mistake

Reading /v1/models as “what is loaded” is the mistake. With just-in-time loading on, that list is “what could be loaded”, and it is lms ps that answers the other question. If you are debugging why the first request to a shared server takes twenty seconds and the second takes one, this is why, and it is not a fault.

Talking to it

The server’s base URL is http://localhost:1234/v1 and the compatibility page lists five endpoints: GET /v1/models, POST /v1/chat/completions, POST /v1/completions, POST /v1/embeddings and POST /v1/responses. There is also a separate LM Studio REST API in beta, under /api/v0, for things the OpenAI shape has no room for.

RunnableAll tracks

the same request every tool in this course makes

curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3-4b",
    "messages": [{"role": "user", "content": "In one sentence, what is a KV cache?"}],
    "temperature": 0
  }'

If that works, then every client in Parts 24 to 26 works, because they all speak this. The embeddings endpoint matters more than it looks: it is what a document-search front-end needs in order to index your files locally rather than sending them somewhere.

Tools and MCP

LM Studio passes tools through the chat-completions endpoint like any OpenAI-compatible server, and it also acts as a client for tool servers itself. From version 0.3.17 the application “acts as an Model Context Protocol (MCP) Host”, meaning “you can connect MCP servers to the app and make them available to your models”; the servers are configured by editing an mcp.json from the application’s Program tab.

⛨Security

The documentation’s own warning is the right one to repeat: “Never install MCPs from untrusted sources.” It goes on: “Some MCP servers can run arbitrary code, access your local files, and use your network connection.” A tool server is a program you are giving a model permission to invoke, and the model chooses when. Part 24 builds the agent loop that makes this concrete and Part 26 puts a sandbox around it; until then, treat an MCP server exactly as you would treat any executable a stranger sent you.

Where the models live

The import documentation gives the layout directly:

Output — what you should see

~/.lmstudio/models/
└── publisher/
    └── model/
        └── model-file.gguf

with the worked example ~/.lmstudio/models/infra-ai/ocelot-v1/ocelot-v1-instruct-q4_0.gguf. Three levels, mirroring the Hugging Face convention of publisher and repository that Part 4’s library already uses. lms import copies a GGUF file into that structure for you.

That layout is exactly why LM Studio can be made to share one library with everything else, and the next lesson but one does it: a symbolic link in the right shape costs nothing, and the alternative is a second copy of every model on the same disk.

When LM Studio is the right choice

It is the right choice when the person using the machine is not going to type commands, and when the machine is a Mac. The model browser turns “will this fit” into something visible before the download rather than after it, the MLX engine is a genuine Apple-silicon advantage that Part 8 quantifies, and lms load --context-length removes the single most annoying limitation of the OpenAI-compatible path.

It is the wrong choice when you need the machine to be reproducible from a file. There is no equivalent of the Modelfile you can commit to a repository, no aarch64 Linux build for Track S, and the application’s licence is not the engines’ licence, which matters the moment somebody else is depending on the service. For a server that other people rely on, the lab in this part uses a container and a text file for exactly those reasons.

It is a reasonable choice alongside the others. Nothing in this course requires you to pick one tool: llama-server, Ollama and LM Studio all serve the same OpenAI-compatible shape, on different ports, from the same weights if you set the library up once.

Reproduce a GUI success through the API

A successful conversation in a desktop interface proves the interface’s own configuration works. Your application may send a different model identifier, omit the system prompt or request a context the server has not allocated. Reproduce the smallest successful interaction through the local API before integrating an editor or agent.

Write down the loaded checkpoint, backend, context, prompt template and sampling settings from the actual session. Send a short request from a second client and compare the content and reported usage. Then test the feature you need: structured output, image input or tool calls. A shared API path does not make those features interchangeable across models and backends.

Keep the lifecycle explicit when moving to headless operation: how the model is loaded, how readiness is determined and how the process is stopped. A graphical session that happened to leave a model resident can conceal missing startup steps. Restart the service and repeat the probe to establish that the configuration can be recreated without the earlier interactive state.

Recap

• LM Studio is a window, a command line, a daemon and an OpenAI-compatible server in one download, and the window is the only optional-looking part that is actually optional.
• It does not run on Track S: the documented Linux build is x64, and no aarch64 Linux build is offered.
• On a Mac it has two engines, and which one runs is decided by which format you downloaded.
• lms load --context-length sets the context on the loaded instance, which is the thing the OpenAI-compatible API cannot do by itself.
• Just-in-time loading makes /v1/models a menu, not an inventory. lms ps is the inventory.
• Models live at ~/.lmstudio/models/publisher/model/file.gguf, a shape that can be satisfied with symbolic links into a shared library.

Check your understanding

Question 1. You have a DGX Spark and want to run LM Studio on it. What do the requirements say?

• Install the Linux ARM64 build
• The Linux requirement is x64 and no aarch64 Linux build is offered, so there is nothing to install; use llama-server or Ollama instead
• Run it under emulation
• It works but only on the CPU

Show the answer and why

Answer: The Linux requirement is x64 and no aarch64 Linux build is offered, so there is nothing to install; use llama-server or Ollama instead

Platform support is a fact to check rather than assume, and it is the kind of fact that changes. The date on that statement is part of the statement: it was true of the pinned version on 8 September 2026.

Question 2. A front-end connected to LM Studio lists twenty models and the first message to any of them takes twenty seconds. What is happening?

• All twenty models are loaded and competing for memory
• Just-in-time loading means /v1/models lists everything downloaded, and the model is loaded into memory on the first inference call
• The server is downloading the model
• The context length is too large

Show the answer and why

Answer: Just-in-time loading means /v1/models lists everything downloaded, and the model is loaded into memory on the first inference call

The documentation describes both halves: /v1/models returns all downloaded models, and a call loads the model if it is not already loaded. lms ps shows what is genuinely resident, and idle models are auto-unloaded after a period of inactivity.

Question 3. Which statements about LM Studio's engines are supported by its documentation? Select all that apply.

• It can run GGUF weights
• It supports running models with Apple's MLX on Apple silicon Macs
• The MLX engine is available on Windows with an NVIDIA card
• macOS support requires Apple silicon; Intel Macs are not supported

Show the answer and why

Answer: It can run GGUF weights, It supports running models with Apple's MLX on Apple silicon Macs, macOS support requires Apple silicon; Intel Macs are not supported

MLX is Apple's array framework and runs on Apple silicon; there is no Windows or Linux MLX path. Part 8 covers MLX directly, including when it beats the portable engine on the same Mac and when it does not.

Question 4. Why does the course treat an MCP server as a security decision rather than a feature?

• Because MCP servers are always malicious
• Because a tool server is a program the model can decide to invoke, and the documentation itself warns that such servers can run arbitrary code, read local files and use the network
• Because MCP requires an internet connection
• Because MCP servers cost money

Show the answer and why

Answer: Because a tool server is a program the model can decide to invoke, and the documentation itself warns that such servers can run arbitrary code, read local files and use the network

The risk is not the protocol, it is the delegation: you grant the permission once and the model chooses when to use it. Part 24 builds the loop and Part 26 sandboxes it, which is the order in which those two ideas should be met.

Check my answersClear