What is MLX in LM Studio? On an M4 Pro it cut one model’s long read from 74.8 seconds to 30.3

MLX is Apple’s own framework for running machine learning models on its chips, and LM Studio carries it as a second engine beside llama.cpp. We wanted to know what is MLX in LM Studio worth in practice, so on 12 October 2026 we ran two models through both engines on an Apple M4 Pro with 48 GB. Qwen 3.6 35B-A3B read a 20,033-token prompt in 30.3 seconds on MLX against 74.8 on llama.cpp. Gemma 4 31B read a similar prompt in 261.6 seconds against 286.4. One model gained a great deal and the other gained little, and the faster engine broke one thing the slower one handles.

What is MLX, and how is it different from llama.cpp?

MLX is an array framework for machine learning on Apple silicon, published by Apple’s machine learning research team. Those are the project’s own words for itself. Its notes say arrays live in shared memory, so work can move between the processor and the graphics processor without copying the data across. That design suits a Mac, where both draw on one pool of memory.

LM Studio does not use MLX directly. It ships its own MLX engine, which its repository describes as the Apple MLX engine for LM Studio and says is built with Apple’s mlx-lm package for running language models, along with two other packages for structured output and for vision. The repository says the engine has come bundled with LM Studio for Mac since version 0.3.4. On our machine it was at version 1.11.0.

llama.cpp is the engine most people meet first. It runs models stored as GGUF files and, on a Mac, uses Apple’s Metal graphics layer. Ours was at version 2.47.0. The two engines do not share model files. A GGUF file runs on llama.cpp only, and an MLX build, which is a folder of several files, runs on the MLX engine only. So moving a model from one engine to the other means downloading it again in the other format.

That also means the comparison is never perfectly like for like. Our GGUF files were Q4_K_M for Qwen 3.6 and QAT Q4_0 for Gemma 4. The MLX builds were the 4-bit versions published by the LM Studio team. They are all four-bit files, made by different methods, and the Gemma pair even start from different original releases. We compared what a Mac owner would download, and we did not compare the quality of the answers.

What is the speed gain from MLX in LM Studio on an M4 Pro?

It depends on the model. This table has every timed figure, with each model loaded alone.

For Qwen 3.6 35B-A3B the gain is large where it counts for agent work. The long prompt is the size a coding agent sends before it starts, and MLX cut the wait from an average of 74.8 seconds to 30.3, about 2.5 times faster. Writing was about 20 percent faster, 61.5 and 59.1 tokens a second against 50.7 and 49.4. We left the first writing run of each engine out of those pairs. On llama.cpp it came straight after another model was unloaded and wrote 39.2 tokens a second, and on MLX it was the fastest of the three at 68.0.

For Gemma 4 31B the gain is small. The long read fell from 286.4 seconds to 261.6, about 9 percent. Writing rose from 11.7 tokens a second to 12.6 and 12.5, about 7 percent. The llama.cpp figure agrees with our index entry for Gemma 4 31B QAT on the M4 Pro, which records 11.74.

Follow-up replies were close on both models. Once a long prompt has been read, each engine keeps it and only reads what is new, so the wait before the next reply was under two seconds for Qwen 3.6 and between seven and ten seconds for Gemma 4 on either engine.

The last row is the one that surprised us. With two requests sent at the same moment, llama.cpp gave each Gemma 4 request 5.7 tokens a second, half its normal speed. MLX gave each one 11.5, nearly the full speed, so the total doubled. Qwen 3.6 on MLX did the same: two requests ran at 64.8 and 64.6 tokens a second each and finished in 8.4 seconds, the time one request takes alone.

Why did Qwen 3.6 gain so much more than Gemma 4?

This is our reading. We did not inspect either engine’s code.

Gemma 4 31B is a dense model. It uses all of its weights for every token, and the file is 18.85 GB. On a machine like this, the time to write a token is close to the time it takes to pass that much data through memory once, and no engine can make memory faster. Both engines landed at about 12 tokens a second because both were waiting on the same thing.

Qwen 3.6 35B-A3B is a mixture of experts. Qwen’s model card gives its size as 35B parameters in total and 3B activated, so only a small share of the weights is used for each token. The memory wait is much shorter, so the engine’s own overhead is a bigger share of the total, and a more efficient engine shows up clearly. Reading a prompt, which processes many tokens together, showed the widest gap of all.

If that reading is right, the gain from MLX should be larger on models with a small active share and smaller on dense ones. Two models are not enough to call that a rule. It is the pattern in these two.

What stops working when you switch to MLX in LM Studio?

Three things changed on our machine that had nothing to do with speed.

Structured output failed on Qwen 3.6. We asked for a reply in a set JSON form, the way LM Studio’s server allows. On llama.cpp the reply came back correctly three times out of three. On MLX the reply field was empty five times out of five, and the JSON turned up in the field meant for the model’s reasoning. Gemma 4 on MLX did not have the fault. Tool calling was unaffected: both models returned the right tool with valid arguments in all eleven checks on both engines.

The context length we asked for was ignored. We loaded every build with a context length of 32,768. Both llama.cpp builds loaded at 32,768. On MLX, Gemma 4 loaded at 71,936 and Qwen 3.6 at 183,296, with no message. Context length decides how much memory a long conversation can grow to use, and our piece on the default context length in Ollama for Gemma 4 31B covers why that figure matters.

Gemma 4 stopped showing its reasoning. The GGUF build wrote reasoning before every answer, and in the writing test it used all 500 tokens on reasoning and returned an empty reply. That is the behaviour we reported in Gemma 4 empty response. The MLX build wrote no reasoning at all and answered in 413 to 428 tokens. We did not set any reasoning option on either, so this came with the build. A follow-up turn that took 13.7 to 14.5 seconds on llama.cpp took 7.4 to 9.6 on MLX, almost entirely because the model wrote 4 tokens where the other wrote 60.

Should you switch from GGUF to MLX in LM Studio?

For Qwen 3.6 35B-A3B on an M4 Pro, yes, if your work is tool calling and not structured JSON. The wait before a long first reply drops by more than half, and a second request no longer slows the first.

For Gemma 4 31B, the engine alone is not a reason. Seven to nine percent is too small to notice in use. The MLX build is still worth a look for two cases: two agents sharing one model, where it doubled the output, and short tool steps, where the missing reasoning shortens each one. We have not tested what the missing reasoning does to the quality of the work, so that is a trade to make with care.

Before switching anything, measure your own setup the same way on both engines. Our guide to measuring tokens per second in LM Studio covers the method, and the main trap is the same on MLX as on llama.cpp: a repeated prompt is answered from the cache and reports a speed the model does not have. After switching, read the context length LM Studio reports for the loaded model, and send one structured output request if anything you run depends on it.

How did we test this?

One Python script sent every request to LM Studio’s local server and read each reply as a stream, taking its timings from the stream so that a figure means the same on both engines. Temperature was 0, and every fresh prompt began with a new random line so the cache could not answer it.

Each of the four builds was loaded alone, with nothing else in memory, because two models at once on a 48 GB Mac slow each other badly. Each was given the same tests. A short question of about 72 tokens with a 500-token limit, three times. A long prompt of reference text, eight tool definitions and a question, twice: 20,033 tokens by Qwen 3.6’s count and 19,870 by Gemma 4’s. Five follow-up turns of about 380 tokens each on top of the long prompt. Two short requests at the same moment. Eleven tool calling checks, three structured output requests and one image with text to read. The image check passed on three builds and failed once on the Qwen 3.6 GGUF build, in a single request we did not repeat.

The machine is an Apple M4 Pro with 48 GB, on macOS 27.0.1 with LM Studio 0.4.25, llama.cpp engine 2.47.0 and MLX engine 1.11.0. Every figure comes from two or three requests in one session on 12 October 2026, so each is a reading, not an average over days. We did not time loading, because the builds sat on different drives. The data files and the script are in the batch folder for this piece. Our standing method is on the How we test page.