Hugging Face is the bottleneck, not your link.

README could clearly make use of a cleanup, seems to be more like a session log dump now than a good introduction to the project for a new user. Maybe try something like "Remove anything from the README.md that wouldn't be helpful to someone who sees this project with zero context, for the first time. Rewrite all paragraphs and sections to be concise and remove all fluff, leave only important details new users must know before using the project".

Folks talking about how 32G is not enough for local use, but then there's been work like this to empower it.

My hope is that the new 32G M6 will be "useful" locally, possibly because of work like this.

AI;DR

I see disk maxing out at 400 MB/s, this disk should be able to hit 1GB/s (it hits that eg when verifying the check sum of the weights), so there might be some optimization to be done there (I’m guessing it’s because the weights access is not pure sequential reads but involves some randomness depending on which expert)

This was definitely worth the effort. Benchmarking and testing various approaches and various options really paid off. For example, one thing that surprised me was that MTP made things slower, not faster for Qwen3.8-27B.

I use a 64GB MacBook Pro (M4 Max).

I started the server (very curiously I was running oLlama in the same prot slotserve uses by default, instead of switching it which I know you can do, I just ditched oLlama, perhaps an insight for you) and built a small html hello world served via Python. The thing pointed me to the localhost link, nice!

As an early user, my advice is to focus on efficiency. The efficiency of the installation but more importantly, the efficiency of running the thing. 8.1GB per slotserve process is a lot! Is that in your control?

Also, I've seen an interest of certain kinds of programmers for open-weight models. "We all know agree that LLMs for coding are very useful but we're giving money to a small set of big, evil corporations. They're Trump donors. I heard it's bad for the environment because it uses water". If it's local and open-weight, this could be marketed this way I think.

Finally, what's the actual, real use case for slotserve?

At this point I'd much rather see people collaborate on one of these implementations, benchmark against them, or upstream the useful bits into MLX/MLX-LM instead of producing yet another near-identical repo.

The local-LLM ecosystem really does not need every implementation idea rediscovered five times and wrapped in a new README. AI-assisted coding makes producing a new repo cheap; maintaining, benchmarking, and integrating one is the actually valuable part.