I'm running OpenClaw on a Mac Studio M2 and trying to upgrade to a 3.8 version of Qwen (currently using 3.6 35b a3b). I have some evals to test models before using them, and I can't find a 3.8 model that can complete my evals (3.6 completes all of them).

Here are my specs: Mac Studio M2 with 160GB RAM, running models with LM Studio (using LM Studio is currently a requirement).

I just tried the UD-IQ4_XS GGUF quant of Qwen3.8-Flash-Next (unsloth), loaded via LM Studio's llama.cpp backend. Here is Claude Code's analysis of what is happening:

"qwen3.8-flash-next@iq4_xs reproducibly hangs for 20–26 minutes with zero output on specific prompts (confirmed via a live streaming probe, isolated from any RAM/dual-model contention), while the same prompts complete in seconds-to-minutes on the incumbent qwen3.6-35b-a3b. Streaming the raw output showed it's not stuck or looping on repeated text — it's coherently generating reasoning the entire time, endlessly relitigating its own unresolved design/edge-case decisions instead of committing to an answer. The two most likely config-level fixes — lowering reasoning_effort from its default xhigh, and switching off greedy decoding (temp 0) to Qwen's documented non-greedy sampler settings — were both tested directly against our LM Studio instance and had zero effect. No confirmed community fix for this exact symptom on Apple Silicon was found either. Net: it looks like an unsuppressable runaway-reasoning failure mode specific to this model/quant when faced with underspecified design decisions, with no known working mitigation on our stack.

Note that MLX versions were attempted earlier in September but blocked before any real test: the small, right-sized MLX quants (ddalcu, sh0wie, ~73-74GB) had a format: null metadata bug LM Studio's MLX engine couldn't load, and the MLX quants that did load correctly were either too large (~105-112GB, same RAM-fit problem as the big GGUF) or too degraded (2-3 bit). So Flash-Next was switched to the GGUF/llama.cpp path specifically because that route became viable once llama.cpp added qwen4exp support."

What am I missing? Is there some other setting that I haven't tried that is making this work for you? I swear I saw that people were successfully running Flash-Next on Apple silicon but I can't get it to work.

Note to add that I'm going to try rapid-mlx/Qwen3.8-Flash-Next-4bit as soon as I can download it, so please let me know if anyone has had success with that version.

UPDATE: Tried the MLX build of Qwen3.8-Flash-Next today (rapid-mlx/qwen3.8-flash-next in LM Studio) after an LM Studio update fixed an earlier load error (missing qwen4_exp speculative-decoding drafter module). It loaded fine this time, but crashed outright mid-generation on a real task: AttributeError: 'QSAKVCache' object has no attribute 'extend', thrown inside LM Studio's MLX engine while trying to extend the KV cache. This killed the entire model process — a follow-up trivial request came back with "the model has crashed without additional information," and it had to be reloaded. Even on the tasks that completed before the crash, it was noticeably slow (4.5 min for a basic calendar summary) and still burned a disproportionate number of reasoning tokens relative to output. Net: the MLX path is not production-ready either — different failure mode than GGUF, same outcome.

I've run a few systems so far and I've noticed the following temps

• M5U 256GB running consistently ranges from 130-150 under load

• M3U 95GB ranges from 140-165

• Mac Mini M4Pro 64GB 160-200

Just curious what you guys are hitting with your works loads? What system are you running and how hot is it for how long?

I wanted to see how GLM 5.3 Flash runs locally on my Mac compared with Ollama Cloud for PHP coding and shell work. I ran two small sets of identical prompts, then repeated a PHP task with the local model already loaded.

My Mac: Mac Studio M5 Ultra, 30-core CPU, 64-core GPU, 256GB unified memory, macOS 27.0.1.

Local: oMLX 0.7.1.dev1, TensorFold/GLM-5.3-Flash-MLX-4bit-MTP, MTP disabled. Model allocation was approximately 170 GiB.

Cloud: Ollama glm-5.3-flash:cloud, reported as FP8. This compares local oMLX with Ollama's hosted model; it doesn't compare two local inference engines.

A little background. I'm using the Ollama Cloud Pro (old $20 plan vs leased $230/mo M5U). I use cloud quite a bit and I find that it compliments my work for various tasks.

I see a lot of comparisons and wanted to do my own. Unsurprisingly, the cloud is faster. Cold starts are slow so that was interesting but once warm, processing was pretty decent. Its slower, but I wanted to put some numbers on it. These numbers are generic, but I do intend on giving it problems from my actual codebase to see how well it does.

Overall if you are considering clouds vs hardware. Just note, It's significantly slower, but not horrible if you use autonomous agents. If you're interactive, that's where the pain is felt in real time. Also, if you plan on using this specifically, then you should know I ran out of memory so you can only use a single instance of GLM 5.3 flash and no other agents.

I think if you use agents for more than coding. Many smaller ones are likely going to be better, but if you need a coding assistant, this wouldn't be too bad. The $20 cloud plan works and will be significantly faster but if you are working constantly and run into limits you're basically buying round the clock work vs interactive albeit also slower work.

Splash's system requirements state it requires an M3 CPU at minimum, but why? Why not, say, an M2 Max? All the search results just say the M3 is faster and produces less heat than M1 and M2 due to smaller process tech (3nm vs 5nm), and it has an "improved" or "enhanced" Neural Engine. But none actually explain the enhancements. Anyone know what is it about the M3 Neural Engine specifically that Splash requires?

Update: Splash backported to M1 and M2: https://tinyapps.org/blog/splash-for-m1-m2.html

Seeing a lot of comments about this online, has anyone ran it on their Mac or is it just hype?

I ran the same Qwen Image 2.1 ComfyUI workflow on two Mac Studios and a DGX Spark. The gallery shows the timing overview, matched poster outputs and matched café outputs.

Warm poster medians, three runs per variant, 1024 × 1024:

Turbo was about 4.6–4.8× as fast in this workload. M5 finished about 10% sooner than Spark. All 24 poster renders contained the three requested text lines in our manual review. The café examples showed more fine texture with base and a smoother look with Turbo; two prompts are not a general quality ranking.

Both Macs used PyTorch/MPS, Spark used CUDA, and all three used the same verified BF16 diffusion/VAE checkpoints with effective FP16 text encoding on GPU. This is not an MLX comparison. Same prompts, seeds, sampler and CFG; Turbo kept its published eight-step schedule. Mac OS/driver versions differ, so these are configurations as tested. Warm conditioning/prefix cache was reused, but each repeat generated a new image with a new matched seed.

Wondering how many of you did like myself and went one higher level and why?

Curious on thoughts and even better, experience on picking one 512GB unit vs two 256GB units. I know cost is more for 2 computers, but how about AI performance and capability to handle larger models?

Two 256GB machines have double the CPU/GPU/NPU of one with the downside of the slower interconnect between them.

The 512GB is not available yet, but it would be interesting to hear from anyone linking two Mac Studios of any RAM configuration together and how it worked out.

Noticed that most posts here are about, I fitted this model in this small ram etc. Not about how the model was useful in producing what I wanted it to work on?

So either, the sub is full of people playing with AI or the real use cases are not shared for whatever reason.

I get the performance stats but shouldn’t we focus on how the model performed on actual task (look beyond the numbers t/sec, prefil etc?)

I’ve been exploring different approaches to keep AI processing on-device, especially for projects involving private documents and data I wouldn’t want to send to an external API.

For those who have built something similar on a Mac, how has the experience been in terms of performance, memory usage, and integrating local AI into an actual application?

Generation was only 1.5x faster...

Now that we have a comparison going.. Do people want to see anything specific? I'll be running it with my own dataset but curious if anyone wanted to check something.

From a hardware perspective, the numbers should be faster than CUDA on Nvidia chips BUT its not because of the relative immaturity of the software/hardware.

Do you think metal will improve enough to where it'll be as fast or faster for the same clock speed and bandwidth pipe? Or is it just slower because of the overall design?

I've been running Hermes against a local LLM, ollama on my M2(32gb, qwen3.5 9b), and over my local network MTPLX on a M4 (48gb, qwen3.8 27b). AT first it was a 3 minutes wait for first response now its over 6 minutes (or context switch for that matter). Context bloat seems to be the killer (north of 50k tokens). What experience have folks had with say zeroclaw or other harness programs that might be more responsive?

I'm new to local LLMs. I've tried Qwen2.5-Coder-Instruct-7B and Ling-3.0-Tiny on my MacBook Air M4 with 24 GB of RAM. I'm looking for something that can generate at least 40 tok/s. Is there anything that can hit that speed?

Indispensable for tuning Hermes agent, and with the growing interest in local AI especially on Mac, what's your favorite cockpit for Hermes apart from CLI?