vllm-metal vs vllm-mlx: The Two Apple Silicon vLLM Ports Compared (2026)

vLLM built its reputation on Linux and NVIDIA, where PagedAttention and continuous batching made it the default high throughput serving engine. On a Mac it was historically a non starter. That is no longer true in 2026, and in fact the situation has overshot: vLLM now has two competing Apple Silicon ports with different foundations. One is vllm-metal, a Metal GPU backend that unifies MLX and PyTorch under a single compute pathway and has shipped inside Docker Model Runner on macOS. The other is vllm-mlx, built directly on Apple's MLX framework, which has posted the higher raw throughput of the two. Choosing between them, or deciding to use neither, is the actual decision now.

Aspect	vllm-metal	vllm-mlx
Foundation	Metal GPU backend, unifies MLX and PyTorch	Built directly on Apple's MLX framework
Distribution	Landed in Docker Model Runner on macOS	Standalone MLX based serving path
Reported throughput	roughly 134 to 343 tokens per second, wide variance	up to 525 tokens per second on small text models (M4 Max)
Run to run stability	more variance between individual runs	more consistent in tested configurations
Best fit	teams already standardized on Docker workflows	maximum single node Mac throughput

Why two ports exist at all

The two ports reflect two philosophies about how vLLM should reach Apple Silicon. vllm-metal takes the Metal route: it targets Apple's GPU API directly and unifies MLX and PyTorch under one compute pathway, which fits the world where vLLM already lives, with PyTorch semantics and a familiar deployment shape, and it slots into container tooling. That is why it landed in Docker Model Runner, which matters for teams whose whole workflow is already containers. vllm-mlx takes the native route: it builds on MLX, the array framework Apple designed for its own unified memory architecture, and pays for the higher integration effort with higher throughput because MLX is purpose built for the hardware it runs on.

Neither approach is wrong. They optimize for different things, and the split is the same one that runs through the entire Apple Silicon inference stack, where the Metal and PyTorch lineage competes with the MLX native lineage on every runtime. We traced that same tension in MLX versus vLLM for production inference and batching, and the two vLLM ports are that tension expressed inside a single project.

Throughput and the stability caveat

On raw numbers, vllm-mlx leads. On an M4 Max it has reached up to 525 tokens per second on a small text model such as Qwen3-0.6B, and it exceeded llama.cpp by 21 to 87 percent across the configurations tested, along with beating mlx-lm. That is a strong result and it makes sense, since building on MLX gives it the tightest path to the unified memory hardware.

vllm-metal tells a more mixed story. Reported throughput lands roughly in the 134 to 343 tokens per second band, and the important detail is not the midpoint, it is the width. That much run to run variance means the backend's performance is less predictable, which is a real cost for anyone trying to reason about capacity or latency budgets, because you cannot size a system around a number that swings by more than a factor of two between runs. A slower but predictable backend is often more useful in practice than a faster but erratic one, and this is exactly the kind of stability difference that never shows up in a single headline benchmark.

A caveat on all of these figures: a 0.6 billion parameter model at hundreds of tokens per second is a throughput demonstration, not a representative production workload. The gaps between runtimes narrow, sometimes sharply, as model size grows into the range you would actually serve, because larger models are more memory bandwidth bound and less sensitive to framework overhead. Benchmark the model you intend to run, not the one that produces the prettiest number.

Serving a model, in practice

The mechanics of standing either port up are close to the standard vLLM experience, which is much of the appeal. A minimal serve looks like the usual OpenAI compatible pattern, and if you are on the Docker path, vllm-metal comes up through Docker Model Runner rather than a bare install.

# vllm-mlx, OpenAI compatible server on a Mac
# pip install vllm-mlx first
from vllm_mlx import serve

serve(model="Qwen3-0.6B", port=8000)

# then call it like any OpenAI compatible endpoint, e.g. with the openai client:
# client.completions.create(model="Qwen3-0.6B", prompt="health check", max_tokens=16)

The value of the OpenAI compatible surface is that your application code does not care which backend answers. That means you can prototype against vllm-mlx for throughput, and if your team standardizes on containers you can move to vllm-metal through Docker Model Runner without rewriting the client. We covered the container path for local inference in depth in local LLM inference with Docker and Apple Silicon GPU passthrough, and the same passthrough concerns apply when the serving engine is a vLLM port rather than a bare runtime.

The honest case for neither

Here is the trade off the throughput charts hide. vLLM's real advantage on Linux and NVIDIA is not single stream token rate, it is high concurrency serving: PagedAttention and continuous batching let one GPU serve many simultaneous requests efficiently. On Apple Silicon, that concurrency advantage is the part that ports least cleanly, and both Mac ports are stronger as single node, low concurrency tools than as the many tenant serving engine vLLM is on Linux. For a workload that genuinely needs vLLM's feature set at load, the realistic pattern in 2026 is still to develop locally on Apple Silicon and deploy to Linux with GPUs for production, so your dev loop is fast and local while your serving tier is where vLLM is strongest.

We reached the same conclusion in does vLLM's MLX integration actually work on Apple Silicon, and the two ports do not change it so much as sharpen it. They make local vLLM development on a Mac pleasant, which is worth a lot; they do not turn a Mac into a production vLLM serving node for high concurrency traffic.

When this applies to your stack

If you build LLM features on a Mac and deploy vLLM in production, the two Apple Silicon ports are good news: reach for vllm-mlx when you want the fastest single node throughput on the Mac, and prefer vllm-metal when your workflow is already containerized and you value fitting Docker Model Runner over squeezing out the last tokens per second. Either way, keep the OpenAI compatible surface between your app and the engine so the choice stays reversible, and keep your high concurrency production serving on Linux and GPUs where vLLM's batching earns its reputation.

Standing up local inference that mirrors production, and drawing the line between what runs on the Mac and what runs on GPU infrastructure, is the kind of applied AI infrastructure work we do at Contra Collective. If you want a local development story that does not lie to you about production performance, we can help you design the split.

FAQ

Does vLLM run on Apple Silicon in 2026? Yes, through two ports: vllm-metal, a Metal GPU backend that ships in Docker Model Runner on macOS, and vllm-mlx, built on Apple's MLX framework. Neither fully replicates vLLM's high concurrency serving strength from Linux and NVIDIA.

Which is faster, vllm-metal or vllm-mlx? In the public numbers vllm-mlx is faster, reaching up to 525 tokens per second on a small model on an M4 Max and beating llama.cpp by 21 to 87 percent in tested configurations. vllm-metal shows more run to run variance, roughly 134 to 343 tokens per second, so it is less predictable.

Should I serve production traffic with vLLM on a Mac? Usually no. vLLM's advantage is high concurrency batching, which ports least cleanly to Apple Silicon. Develop locally on the Mac and deploy to Linux with GPUs for production serving.

Do I need to change my application code to switch ports? No, if you keep both behind the OpenAI compatible API. Your client calls the same endpoint shape regardless of which port answers, so you can move between them without rewriting the app.