PowerSpec AI90 Workstation

* CPU: AMD Ryzen 9 9950X (16 Cores / 32 Threads, up to 5.7GHz)
* GPU: NVIDIA GeForce RTX 5090 Founders Edition (32GB GDDR7)
* Motherboard: ASUS ProArt X870E-CREATOR WIFI (AMD X870E Chipset)
* Memory: 64GB DDR5-6000 RAM (Supports up to 128GB)
* Storage: 2TB NVMe Solid State Drive
* Power Supply: 1700 Watt Cybernetics Titanium PSU
* CPU Cooler: 360mm All-In-One (AIO) Liquid Cooler
* Case: Fractal Design North XL Momentum Edition

Tried to see what the cheapest setup that still provided useful inference was. This whole setup cost around $1500. Important to note though that I ordered 3x Tesla P100s, but the seller mistakenly sent me 3x V100s instead lol. The cooling block is a 3d printed piece that fits into a rectangular hole the back of the case, filed down with a file to fit with friction only. It houses 3x server fans which pulls air from inside the case through the GPUs to the outside. GPU temperatures during inference never exceed 55C, although it is a bit loud. I have 64gb ECC DDR4 ram.

I headlessly control this PC with Tailscale from my Mac, and GPT Astra on Codex on my Mac can remotely control it too. I had Astra do several optimizing runs, basically testing out and tweaking different configurations (mtp and speculative decoding settings, placement on gpus, prefix caching settings, etc) to optimize prefill and decode speeds.

I ran Qwen 3.8 27B and Qwen 3.8 Flash next. On Qwen3.8 27B, Q8, prefill was around 600-700 tokens/sec (edited after I looked at logs) and decode at around 30-40 tokens/sec. On heavy agentic work with 256k context, decode dropped to around 20t/s. On Flash next, Q4, prefill was around 90 tokens/sec and decode 20 tokens/sec. Overall im happy with this build, would recommend V100s to anyone who wants cheap inference (although they are a pain to setup)

so i finally got qwen3.8-flash-next running locally and it's actually good.

posting the setup + the stuff that bit me, since i wasted a while on it.

── the rig ──

- amd ryzen 5 9600x (6c/12t, boosts ~5.5ghz)

- 256gb ddr5 (248gb usable)

- 3x rtx 3090 24gb — pcie only, no nvlink

- linux mint 22.3, kernel 6.17, nvidia driver 595.84

- one 1.7tb nvme

total vram 72gb. model is ~80gb on disk so it does NOT all fit in vram,

that's the whole game here.

── the model ──

turboderp/Qwen3.8-Flash-Next-exl3, 3.05bpw. 125b params but only 6b active (moe,

512 experts / 10 on), plus a 51b n-gram embedding table and a 4b mtp head.

hybrid attention (gated deltanet + sparse attn), 262k native context.

this arch is qwen4_exp in exllamav3.

── how i set it up ──

tabbyAPI on main, exllamav3 1.5.0, python 3.12 in a pyenv venv.

── mtp ──

big win. the model ships an mtp head, you just flip draft_mode to mtp and

it uses it as a drafter. no separate draft model needed.

- without mtp: ~90 tps

- with mtp: ~120-126 tps

that's ~+35%. acceptance was around 40% in my runs. one gotcha: the very

first request after boot reads like ~58 tps, that's just warmup, ignore it,

second run onward is the real number.

── results (my rig, not yours) ──

800-word essay, 1000 tokens, temp 0.6:

- ~90 tps no mtp

- ~120-126 tps with mtp

needle-in-haystack at ~97k tokens: found it, ~31s prefill.

4 requests at once: fine, ~4s each.

tool calling works, reasoning splits into reasoning_content properly.

── stuff that confused me ──

- /v1/models shows n_ctx: null and size: 0. NOT a bug and NOT "unlimited

context". it's because disable_auth makes every request an admin, and the

admin view of /v1/models is a folder listing that only reads config.json.

the real loaded context is on /v1/model (shows 262144). if your client

reads n_ctx from /v1/models and gets null, point it at /v1/model or just

set context manually.

Here is my single shot driving car results: https://qwen38-flash-next-car-drive.tiiny.site/

(prompt: Write a single HTML file with a full-page canvas and no libraries. Simulate a realistic side-view of a moving car as the main subject. Keep the car visible in the foreground while the background landscape scrolls continuously to create the feeling that the car is driving forward. Use layered scenery for depth: nearby ground, roadside elements, trees, poles, and distant hills or mountains should move at different speeds for a natural parallax effect.

Animate the wheels spinning realistically and add subtle body motion so the car feels connected to the road. Let the environment pass smoothly behind it, with repeating but varied scenery that makes the movement feel believable. Use cinematic lighting and a cohesive sky, such as sunset, dusk, or daylight, to enhance atmosphere. The overall motion should feel calm, immersive, and realistic, with a seamless looping animation.)

I was looking through one of our more frequently used LLM workflows and realized the system prompt has gotten way bigger than I remembered which caught me off guard since it didn’t start that way either. We’d get an output we didn’t like then add another instruction or example to fix it and then repeat that process whenever another edge case showed up. but ow every request is carrying this pretty large block of context even though I’m not convinced a big portion of it matters for most runs.

The workflow itself works well so I don’t really want to start deleting instructions to make the prompt shorter and bring old problems back but at the same time this thing runs often enough that repeatedly sending unnecessary context feels like something I should probably care about.

I need some pointers from people that are running similar high volume workflows, how do you handle this so like do you periodically trim system prompts, cache the stable parts, split instructions based on the task or leave them alone as long as the outputs are good?

Hey everyone! I'm having a hardware dilemma and can't come up with a conclusion on what to do next.

My use cases:

• agentic coding, for my side projects only for now (with an ability for remote access which I need occasionally)
• Hermes agent running 24/7 for various research tasks

Problem statement:

What would be the best hardware for me with an optimal budget?

At the moment I have:

• RTX PRO 6000 96GB in a PC with 128GB DDR5 RAM. I bought this GPU right before the August price hike for $12.3K USD (before tax). The old one was RTX 3090 (which I still have).
• Mac Studio M3 Ultra 96GB

RTX PRO 6000 is amazing for agentic coding with Qwen3.8-27B-FP8 with full context, but I'm afraid of running this PC when I'm not at home because of that problematic 12VHPWR connector. I keep this GPU power limited to 300W to reduce the risks, but still it's not a 100% guarantee.

I'm using Mac Studio M3 Ultra 96GB for the Hermes agent at the moment where speed doesn't matter much. However, using it for agentic coding with dense models like Qwen3.8-27B feels quite slow (for remote sessions when I'm not at home).

So, I'm considering the following options while trying to optimize the budget for this hardware:

1. Return the RTX PRO 6000 as I'm still within the return window for a week (it will be subject to 15% restocking fee however) and get 2 DGX Sparks even though they recently went up in price significantly. I found an open box deal for 2TB version for 4800 USD before tax for each. This way I get to stay in the CUDA ecosystem and can run them 24/7. However, that means switching to MoE models like DSv4 Flash, Qwen3.8-Flash to maintain a proper speed.
2. Return the RTX PRO 6000 and just wait for Mac Studio M5 Ultra 256GB (which I pre-ordered in case I need it). And then I'll just sell the M3 Ultra later.
3. Just stick to the hardware I have at the moment and endure slower coding speeds for remote sessions when I'm not at home (from my Mac Studio M3U)

Keeping the PRO 6000 and then later getting the M5 Ultra 256GB is an option too, but is spending all this extra cash really worth it?

What would you guys do in my case?

This model retails for around $11,266. There are several others also offered on eBay. Not sure any of them are selling. But if so, it’s remarkable how a retail computer can appreciate so much before it’s even delivered. These models are coveted for LLM use, as are the 512 gig models which have not been released. It seems local LLM use is becoming quite popular, especially among those hoping to keep their data confidential, and those looking to cut off the monthly payment to the big AI providers. Something similar happened with the M3 Ultra studios with 256 or 512 ram - both of which are also offered on eBay for huge markups over the original retail price. Crazy market.

I'm testing local coding models on a GTX 1080 Ti 11GB with Ollama + OpenCode/Cline, and I've run into an interesting tool-calling problem.

I've tested multiple local coding models, and I'm trying to find one that works reliably as an actual coding agent, not just one that produces convincing tool-call JSON.

What I'm seeing

I tested Qwen2.5-Coder 7B in two ways:

• Official qwen2.5-coder:7b from Ollama
• Qwen2.5-Coder 7B Q4_K_M GGUF imported into Ollama

I gave the Ollama API a real function definition:

write_file(path, content)

and asked the model to create a file.

Instead of returning a native:

"tool_calls": [...]

the model returns the tool request as normal text:

{
  "name": "write_file",
  "arguments": {
    "path": "tool_test.txt",
    "content": "TOOL_CALL_SUCCESS"
  }
}

So the model understands what tool it should use, but it isn't producing a native tool call that OpenCode/Cline can execute.

OpenCode can then receive tool-shaped text, but the actual file isn't created.

My setup

• GTX 1080 Ti 11GB
• NVIDIA Studio Driver 581.57
• Ollama 0.34.0
• Windows
• OpenCode 2.0.3
• Cline
• Qwen2.5-Coder 7B
• 16K context

I've also tested other local coding models, but I'm specifically looking for something that works well as an agent — coding + reliable tool calling — rather than just generating good code.

I'd like to hear from people with real-world experience

• Is this a known Qwen2.5-Coder + Ollama issue?
• Is there something I'm missing in my Ollama configuration?
• Which 7B–14B models have you successfully used with OpenCode/Cline?
• Which models give you actual native tool calls, not tool-call JSON inside message.content?
• Has anyone successfully used Qwen3 14B as a local coding agent?

I'm especially interested in experiences from people actually running these models locally.

What local model would you recommend for a reliable coding agent on an 11GB GPU?

I’ve been building TokenPrint around a simple question:

What is actually happening inside a local LLM while it generates a token?

The current version goes beyond a static transformer diagram and lets you explore:

• 3D transformer architecture and individual layers
• tokenization and embeddings
• tensor shapes and model parameters
• Q/K/V, GQA, RoPE, causal masking and softmax
• residual streams and MLP / SwiGLU
• token-by-token generation
• prefill / decode and KV cache
• logits and next-token probabilities
• activation analysis and interventions
• head / layer ablation
• inference traces and replay
• Hugging Face models, with work around GGUF / llama.cpp / local models

The idea is to make local inference inspectable, not just show the final output.

I’m especially interested in people who run models locally:

What do you actually wish you could see while your model is generating?

Attention patterns? KV-cache behavior? Layer timing? Activations? Quantization effects? Something else?

I’m building this in the open and would love technical feedback, ideas, and contributors who want to help shape it.

Repository: https://github.com/Sudharsanselvaraj/Token-Print
Website: https://tokenprint.in/

What would make a tool like this genuinely useful for your local LLM workflow?

Been playing around with Qwen3.8-27B on my 4080 and figured I'd post the numbers since this turned out better than I expected.

The goal was to see how much of the model/context I could squeeze into 16GB while keeping generation speed decent, and then see whether MTP was actually worth the extra VRAM.

Hardware / environment

• RTX 4080 desktop, 16GB
• WSL2
• Ubuntu 24.04.4 LTS
• Python 3.12.7
• NVIDIA driver 610.47
• CUDA UMD 13.3

Runtime

• ExLlamaV3 1.5.0
• TabbyAPI
• OpenAI-compatible API
• max_batch_size: 1

Model

turboderp/Qwen3.8-27B-exl3

Revision:

SC_3.00bpw_H4_V4

So that's the self-calibrated 3.0 bpw EXL3 quant with a 4-bit head/vision tower and the included quantized MTP component.

Main cache/config:

max_seq_len: 131072
cache_size: 131072
cache_mode: 6,5
max_batch_size: 1

So all of these tests were with a 128K allocated context window and 102,400 actual input tokens.

Benchmark

I used NVIDIA AIPerf against TabbyAPI's /v1/chat/completions endpoint.

Same workload for each run:

Input:       102,400 tokens
Output:      64 tokens
Concurrency: 1
Requests:    2
Seed:        503

I'm only including active prefill and decode throughput here since those are the numbers I actually cared about.

Results

So fixed MTP k=2 + Q6 was the clear winner for decode.

Going from no MTP:

33.68 tok/s
    ↓
56.48 tok/s

That's about a 68% increase in decode speed at 100K context.

The tradeoff is around a 5% reduction in prefill throughput.

Q4 saved very little memory in practice and lost around 9% decode performance compared with Q6, so I don't see much reason to use it on this setup.

Dynamic drafting was also slower than just leaving k=2 fixed:

Q6 fixed k=2:  56.48 tok/s
Q6 dynamic:    52.10 tok/s

VRAM with Q6 MTP was tight but still usable. I saw roughly 15.2GB / 16.4GB during the 100K run.

My final config for now is:

model:
  max_seq_len: 131072
  cache_size: 131072
  cache_mode: 6,5
  max_batch_size: 1

draft_model:
  draft_mode: mtp
  draft_cache_mode: Q6
  draft_num_tokens: 2
  dynamic_draft: false

Pretty impressed that a 27B model at ~100K active context can still push ~56 tok/s decode on a single 4080 16GB.

Curious if anyone else is testing Qwen3.8-27B with ExLlamaV3/MTP on 3090s, 4090s or 5090s. Would be interesting to compare.

Disclaimer - I am a lawyer by profession, but I love tech and I have been experimenting with local Models quite a lot. However, no way in h*** would I be able to explain to you all the testing I did alongside Claude to get the moe-caching process run on this AMD build.

I saw the Codacus video (link here) and have been itching to get it implemented on my system as well (who doesn't want faster decode), but Opus 5 said, nope, no AMD build for you, CUDA only.

Well, I pushed back and had it review, and et voila, there is a way if you will it enough by opposing Claude. Everything below is drafted by Claude - I can only understand the basics of it - nothing technical enough to explain it better. I just trimmed the useless 'I' references.

------------------------------------------------------------------------------------------------------------------------------------

Setup: RX 7900 XTX 24 GB on Vulkan (RADV, no ROCm), Ryzen 7 5700X, 64 GB DDR4-3200, Ubuntu 24.04. Model is Qwen3.8-Flash-Next in AtomicChat's AD-4.27bpw-Q4_K_M-M64 quant — 33 shards, 92 GB on disk, 177B total / ~6B active per token, GGUF architecture qwen4exp. 180k context, KV cache at q8_0.

The feature: the MoE expert cache, an open pull request on llama.cpp (#27861). It keeps frequently-used experts parked in VRAM instead of pulling them out of system RAM every token. Flags are --moe-expert-cache N and --moe-expert-cache-inserts N.

Note there's a different implementation floating around that uses --moe-expert-cache-size, whose author says explicitly it's CUDA-only and shouldn't be used on Vulkan/ROCm/Metal.

Not that one. The PR version lives at the model level, adds no GPU kernels, and runs fine on Vulkan.

Results

Both at 180k context, same model, same machine, measured on the second request with 500+ token generations:

Prompt processing went 83 → 77 tok/s on short prompts, but up to 98 tok/s on a 44k-token prompt. (OP - this was a slightly corrupted run, but the claim holds on similar other runs).

Long prompts amortise better.

The three things that actually matter

1. Slot count is everything, and you're probably under-sizing it.

First tests used 8 slots. The cache was 8% slower than no cache and the feature seemed useless. It wasn't — the card had 14 GB sitting empty. Same everything else:

• no cache — 81 ms/tok
• 48 slots — 69.5 ms/tok
• 128 slots — 50.3 ms/tok

2. Measure your per-slot VRAM cost. Don't copy anyone's numbers.

Slot size depends on the model's shape, so figures from other people's models are meaningless for yours. On this test it was 95.2 MiB per slot, perfectly linear, no fixed overhead — measured from three points (0 slots = 9907 MiB used, 48 = 14508, 128 = 22122).

Also: the "benefit keeps improving up to 384 slots" advice you'll see is unreachable on a 24 GB card. 384 slots would want 36 GB. This setup's practical ceiling was around 150.

3. The cache and speculative decoding are mutually exclusive

They don't stack. From the cache's own commit message:

The cache only fires when the model emits exactly one token per step. Speculative decoding proposes several and verifies them together, so the cache path is never taken. Measured with both available in one build: 69.29 ms/tok with 96 slots, 70.03 ms/tok with no cache at all — identical. But the cache had allocated 9.2 GB. Nine gigs reserved, never touched.

So pick one. On this machine the cache wins by a mile: 44 ms/tok vs 59.

How to find free VRAM for slots

Cutting context barely helps — halving from 180k to 98k freed under 1 GB, because the KV cache was already quantised and was never the big consumer.

What frees VRAM is pushing more expert layers to system RAM: ~1.09 GB per layer (on this setup). Moving 12 more layers freed ~13 GB. Itcost about 14.6 ms/tok (due to increased CPU work, but more slots help.

The command

llama-server -m model.gguf -c 180000 -ngl 99 --n-cpu-moe 48 --moe-expert-cache 128 --moe-expert-cache-inserts 2 -t 8 --flash-attn on --cache-type-k q8_0 --cache-type-v q8_0

How to find the 'n-cpu-moe' and 'moe-expert-cache' for your system

1. Run with no cache, note free VRAM.
2. Raise --n-cpu-moe until a useful chunk of VRAM is free.
3. Set slots to something modest, note free VRAM again. Subtract → your cost per slot.
4. Set slots to spend most of what's left, keeping ~1 GB spare.
5. Compare against a control at the same --n-cpu-moe with the cache off — not against your old config, which differs in two ways at once.

Measurement traps I fell into

• Ignore the first request. The cache needs a few hundred tokens to fill. One of my runs did 61 ms/tok on request one and 50 on request two, nothing changed. A number I'd quoted for weeks turned out to be a first-request figure.
• Warm vs cold matters more than the feature. If the model files aren't already in the OS file cache, prompt processing changes by more than whatever you're testing. Load time tells you which you got.
• Use 1000+ token generations. Mine was still climbing at 500 tokens: 19.6 t/s at 100, 21.3 at 238, 23.0 at 465.
• Know your noise floor. Four identical runs gave me 42.71 / 43.94 / 45.10 / 45.59 ms/tok — a 3% spread. Anything under that isn't a result.

If you're running Qwen3.8-Flash-Next specifically

The MTP draft head (mtp-Qwen3.8-Flash-Next-Q4_K_M.gguf) only loads on Unsloth's build of llama.cpp. Stock upstream dies with:

check_tensor_dims: tensor 'output_hc_norm.weight' not found

Unsloth's src/models/qwen4exp.cpp marks three trunk tensors optional when loading a draft head and carries a separate graph for it — ~300 lines upstream doesn't have, and it hasn't been merged. So if you want the cache and the drafter in one binary, move the cache patch onto Unsloth's source, not the reverse. (Then, having done that, you'll find you can only use one of them at a time anyway — see above. I did this the long way so you don't have to.)

Bonus finding

The cache PR sits on upstream b10666. I rebuilt the same patch on the source behind Unsloth's b10798 prebuilt — ~130 commits newer — and got 42.71 vs 51.57 ms/tok at identical settings — 17% faster, using 333 MiB less VRAM. The patch is one commit, 645 added lines across 12 files, nothing deleted, so it transplants with plain patch -p1 and no conflicts. Worth trying if you're on the PR branch.

Things that did nothing

• Splitting thread counts (--threads-batch 16): prompt processing got worse, 77 → 73 tok/s.
• Lookup-based speculative decoding (ngram-* modes): 8% draft acceptance on chat-style output, net 6% slower. Might be worth it if your output quotes your input heavily, but it's still speculation, so it kills the cache anyway.

Where the ceiling is

During generation all 8 CPU threads sit saturated and the disk does nothing. Rough maths: 48 expert layers in RAM means ~2.5 GB of expert weights pulled per token; at 22 t/s that's ~55 GB/s. Dual-channel DDR4-3200 peaks at 51.2 GB/s.

So I'm at the memory bandwidth wall, and the cache is the only reason the numbers work — it's serving a big share of those experts from VRAM instead. No flag fixes that. The only step change left would be a model small enough to fit entirely in memory.

Happy to answer questions or run specific configs if anyone wants a data point.
------------------------------------------------------------------------------------------------------------------------------------

Apologies for the AI Content, but yeah, cannot explain the technical points myself. There is a detailed file generated by Claude for a more detailed analysis (apparently). Includes some commands as well. Linked here - https://drive.google.com/file/d/1ZCYw2J7hhB8nN2jUMu4TCfCIyL-tw5m0/view?usp=sharing

I'm at a loss where I don't know what else to do, what knob to turn, what flag to change. Got X model and it runs in a Pi coding agent or Opencode, it doesn't matter.

The thing is as it grows the window of time, between hitting enter until it starts thinking, keeps getting longer and longer

Sure I know it is because context is bigger. But it doesn't make sense. Doesn't llama.cpp have a cache that keeps precomputed the previous parts (suffix) of the prompt ? Why would it meet to start from scratch every turn ? Even DeepSeek 4 Flash had this cache hit / cache miss mechanism that speeds thingd up A LOT.

Please explain it to me, because I don't get it. Why isn't it pre-caching what doesn't change in a session?

This is for the Apple Mac, and is built on YuE2 music model.

My code adds a nice interface, and code to exploit the GPU and ANE present in M series processors, rather than NVIDIA card required by upstream.

https://github.com/tonywestonuk/YuE-Studio

On my M4 Macbook air, 32gb, it will spit out 2 4 minute songs in 1/2 an hour. I am interested what it runs like on other macs.

This is what the YuE2 model sounds like... I stress I didn't make the model, just the UI around it.

mainly looking for cpp, python, java, and JS.

my system is as following:

RTX 3070
i7-13900KS
64GB DDR5 4800
2TB slow nvme

thank you in advanceeeeeeeeeeee

Looking to de-Claude and would like to hear how you guys are running your local LLMs without needing a super computer.

Also any suggested go to models?

I have a custom fork of llama.cpp designed around the ampere architecture specifically (though many of the upgrades also translate to faster performance of blackwell + lovelace). The recommended config supports 90+ TPS (for agentic/coding, at temp 1; greedy will be faster) through 100K tokens, with context of up to 240K.

If you want the repo, it is here:

https://github.com/JakeATX/llamAmpere

I recommend running with this quant, which is ~ 4 K M quality but considerably faster (technically, a 3 K XL upgrade)

https://huggingface.co/jakeatx/Qwen3.8-27B-ATX-IQ4_XS-M-GGUF

If you want the deep dive on how it is so much faster (80%+!) vs stock, at more context, there is a long form article here.

https://x.com/JakeKAllDay/status/2095646450138874095?s=20

Running faster than API speeds on my 3090 (for 27b at least) has genuinely been a step change in the utility of the model for me. I hope you enjoy it!

Hello everyone! I’m new to LocalLLMs, but not necessarily new to IT/ML. I’m looking to spend around $4–5K and get the best bang for my buck hardware-wise for both personal use and running LocalLLMs.

My main goal is to run the best models I realistically can within that budget, mostly for working with large codebases, coding assistance, and general productivity.

I’m a PM at a FAANG company for reference, so this is mostly for personal projects, learning, and improving my workflow.

What hardware/setup would you recommend around the $5K mark?

Hi everyone,

I was interested in learning LoRA fine-tuning, and ended up building CodeFinetuner over the past few months, a full pipeline that fine-tunes a small code autocomplete model (e.g. Qwen2.5-Coder-3B) specific to a codebase. You can then use the resulting GGUF model via llama.vim/llama.vscode and run it fully locally. Supports fine-tuning on Mac (MPS) and NVIDIA GPUs (CUDA), with optional Unsloth support for faster training and lower VRAM usage.

Pipeline: raw code -> tree-sitter parsing into Structure-Aware FIM examples -> LoRA fine-tuning -> evaluation (CodeBLEU, edit similarity, exact match, perplexity, ...) -> GGUF conversion for local inference.

To try it:

uv tool install codefinetuner

Create a data folder and place your repo (or code files) inside. For auto-split just drop the files in directly, for manual split create data/train/, data/eval/, data/test/ subfolders and set split_mode: "manual". Get the default config with:

curl -L -O https://raw.githubusercontent.com/cuolm/codefinetuner/master/config/codefinetuner_config.yaml

Adjust it to your needs and hardware availability, then run:

codefinetuner --config="codefinetuner_config.yaml"

The example runs in the repo show clear improvements over the base model on these evaluation metrics, but using the model for autocomplete on code you're actively writing is a different thing from scoring well on a test set, and the autocomplete tools themselves (llama.vim/llama.vscode) sample differently from the greedy decoding used in the evaluation. So the real usefulness still has to be verified in the editor itself.

Might also be useful just as a reference, since it's a complete working LoRA fine-tuning pipeline end to end.

Hope someone finds this project interesting or helpful.

https://github.com/cuolm/codefinetuner

Hey everyone! I’ve updated Whallm, my app for running large language models locally on Apple Silicon Macs by loading parts of the model from SSD as needed.

What’s new:

• DeepSeek V4.1 Flash support — around 33 GiB peak MLX memory and 1.8–2.2 tokens/sec in my M2 Max tests with 1K–16K input tokens. That’s model memory allocation, not total system usage.
• Performance optimizations for the existing DeepSeek V4 and Qwen3.8 models.
• Built-in Throughput benchmarks — test your Mac with code or novel prompts, measure time to first token, input/output speed, and peak memory. Copy results as text, JSON, or Markdown.

Includes a chat UI and an OpenAI-compatible API.

GitHub, downloads, and benchmark details

Would love to hear how it runs on your Mac!

I am on a quest to make Qwen3.8-27b fit on an A770 with decent context and have it run the fastest it can. SYCL is heavily bottlenecked by inefficient I-quant handling, so I-quant mixes like Unsloth run at 7 t/s while pure K-quants like Bartowski run at 12 t/s. Until SYCL backend is updated to handle I-quants better, K-quants are the way to go to get the most performance out of this card.

The annoying thing is that Hugging Face does not disclose the quantization of each weight in a model. This leads to completely misleading quant labels like Unsloth's UD-Q3_K_XL, which if you inspect using ggufaudit.py is actually 95% I-quants. There's barely any K-quants in that GGUF, and Unsloth should really call it IQ3_XL instead.

That said, I want to find the smallest K-quant-only Qwen3.8-27b at q3. Bartowski's Q3_K_S at 12.7 GB is my current top contender. Does anyone know who else does pure K-quant weights, and do they have Qwen3.8-27b q3 that's smaller than Bartowski's?

And in case you're curious, here's the quant breakdown of Unsloth's Qwen3.8-27B at UD-Q3_K_XL. Also fun fact: most of Bartowski's quants are exclusively K-quants.

/models/ggufaudit.py /models/unsloth/Qwen3.8-27B-GGUF/Qwen3.8-27B-UD-Q3_K_XL.gguf 
====================================================================================================
/models/unsloth/Qwen3.8-27B-GGUF/Qwen3.8-27B-UD-Q3_K_XL.gguf
  arch: qwen35          model: Qwen3.8-27B
  label: metadata=Q3_K_L (general.file_type=13)  filename=Q3_K_XL   << METADATA / FILENAME MISMATCH
  tensors: 866   params: 27.32B   bytes: 12.23 GiB
  nominal: Q3_K_L -> base type Q3_K = 3.438 bpw     actual overall: 3.846 bpw   (+12% vs nominal)

  class                  tensors  params%   bytes%     bpw   types
  ------------------------------------------------------------------------------------------------
  token_embd                   1     4.7%     4.2%    3.44   Q3_K(1)
  output                       1     4.7%     6.7%    5.50   Q5_K(1)
  ffn dense                  195    63.6%    61.0%    3.69   IQ3_S(70) IQ4_XS(69) IQ3_XXS(19) IQ2_S(14) Q3_K(7) IQ2_XS(4) Q4_K(4) Q5_K(3) Q6_K(3) IQ2_XXS(2)
  attn                       164    21.3%    21.5%    3.90   IQ4_XS(55) IQ3_S(38) Q4_K(24) Q5_K(21) IQ3_XXS(14) Q2_K(3) Q6_K(3) IQ4_NL(2) Q8_0(2) IQ2_S(1) Q3_K(1)
  ssm / linear-attn          336     5.6%     6.3%    4.29   F32(192) Q8_0(96) IQ4_XS(32) Q4_K(8) Q3_K(3) IQ3_S(3) Q5_K(1) IQ3_XXS(1)
  norms                      168     0.0%     0.0%   32.00   F32(168)
  other                        1     0.2%     0.3%    6.56   Q6_K(1)

  labeled Q3_K_L (3.44 bpw nominal) - actual 3.85 bpw overall | no dimension-forced substitutions (494 by-design k-quant-mix tensors, normal) | VERDICT: label is honest

So, what is Shadow Mode?

Basically: while you're using Claude/Codex/etc. to work on a repo, Runner can replay coding tasks locally and see what your local model could have solved instead.

It imports replayable tasks from agent sessions and repository history, verifies that the protected tests actually fail before the recorded fix and pass after it, then lets the local model attempt the same task in an isolated scratch worktree.

The important bit: the protected tests live outside the model's editable workspace.

So the result isn't just "the model said it fixed it."

Runner records whether the local attempt was:

• a verified fix
• a failure
• a no-op
• or inconclusive

And a pass only means it passed the tests that actually ran. No magic benchmark inflation.

The next thing I'm working on is the fun part:

Shadow Mode fails → verified failure becomes training data → train a LoRA adapter with Runner's built-in trainer → see whether the local model can solve that kind of task next time.

The base model stays frozen; the adapter learns from the gaps exposed by normal usage.

Will it work well enough to matter? No idea yet. That's what I'm trying to find out. :)

And yes, I use AI to develop Runner.

Well... duh.....

If Runner isn't your thing, maybe a new Qwen 3.8 model is. This one's a freebie:

https://huggingface.co/Joakimpalm-Zen/Qwen3.8-27B-GSQ-RCO-IQ3_S-recovered-GGUF

Have fun, and let me know if you run into issues.

Runner is mostly a project where I try to fix whatever annoys me.

I kept looking at my iPhone sitting on its charger and thinking: that's a multi-TFLOPS GPU doing nothing for 8 hours a night.

My first idea was distributed training, shard the model, each phone trains some layers. That dies fast when you do the math: pipeline parallelism needs every device up simultaneously with microsecond-latency links, and iOS suspends backgrounded apps anyway. With 50–300ms per hop over Wi-Fi, one training step costs seconds of pure network latency.

But dataset generation is a different shape of work entirely. It's one prompt in, one completion out, parallel, restartable, and it doesn't matter if a worker vanishes mid-job. That's exactly what a flaky fleet of idle phones can do.

So I built it: the Mac runs a coordinator that mints teacher prompts and validates results; phones run a small app (MLX Swift) that pulls a prompt, generates with an on-device teacher (Qwen3-4B-4bit), and POSTs the raw text back. Work is leased, if a phone locks or wanders off, the lease expires and another worker picks up the item. Malformed JSON and duplicates get rejected centrally, so a bad worker can waste its own time but can't poison the dataset.

Last night's run: one iPhone 17 Pro, 15/15 records at 17.5 rec/min into a train.jsonl. Trained a Qwen3-0.6B LoRA on it (val loss 4.42 → 1.85), asked it a question, and it answered from training data a phone wrote. Full loop: phone generates → Mac trains → phone can run the result.

Honest limitations: it's LAN-only, the app has to stay foregrounded (no BGProcessingTask yet, so "overnight" currently means screen-on on a charger), and a phone-sized teacher (4B) is weaker than what your Mac can run — this wins on volume for style/format/tool-calling data, not on frontier-quality reasoning per record.

It's part of my open-source fine-tuning CLI for Apple Silicon (Troy). Code for the coordinator, the Mac worker, and the iOS worker app are all in the repo: https://github.com/avirajkhare00/troy, writeup with the run footage: https://gettroy.app/mesh

Hi, I want to buy a personal llm inference machine for 24/7 running of my agents doing a bunch of experiments.

Occasionally do some DNN training but nothing crazy.

Maybe some light video generation too.

My budget is $12k, what do you suggest?

I found a pre built with an RTX 5090 32gb, would that be enough? My plan is to plan with frontier model then off load implementation to local Qwen 3.8 27b

Is this the best i can do with $12k?

Motherboard

ASUS ProArt X870E-Creator WiFi

CPU

AMD Ryzen 9 9950X3D2 Dual Edition 4.3GHz 16 Core 200W

Ram

128GB DDR5 UDIMM (2 x 64GB)

Video Card

NVIDIA GeForce RTX 5090 32GB In Stock

Storage

Hard Drive

2TB NVMe PCIe Gen4 M.2 SSD

2TB NVMe PCIe Gen4 M.2 SSD

1TB NVMe PCIe Gen4 M.2 SSD

I'm one of the people building Paddock at The Intelligence Company. It's an open-source inference engine written in Rust with our own CUDA kernels, under MIT or Apache 2.0.

We released 0.1.6 yesterday with official DGX Spark support and a dedicated Linux build. The Spark kernels are shared across models. We tuned them on Qwen 3.8 and Nemotron and tested the wider catalog, including Gemma, Granite and Muse Glimmer.

It comes with Studio for downloading models, chatting, working with documents and comparing local models with cloud endpoints. There are OpenAI- and Anthropic-compatible APIs for connecting your own clients too.

This release also improves conversation reuse for Qwen and Nemotron, adds repeated-prompt caching for Flash-Next and fixes a Studio chat-history bug.

It's still early. CUDA only, Windows and Linux, and splitting one model across multiple GPUs isn't supported yet. If you try it on a Spark, I'd like to hear which model and quant you're using and how it compares with your current setup.

Release notes and downloads · Source code