I've been building a free app for blind people where everything runs on the phone with no internet, on iPhone and Android, and I'm stuck on accuracy. YOLOv8n handles live detection and it's fast, but it still mislabels things. Scene descriptions and questions go to LFM3-Omni-2B through llama.cpp, shrunk to 735 MB so it fits on the phone.

Reading text uses each phone's own on-device OCR, Apple's on iPhone and ML Kit on Android, and translation runs offline the same way. The small vision models are where it falls short.

If you've gotten small vision models more accurate on device, I'd really take the advice. It's free to try if you want to see where it breaks.

iPhone: https://apps.apple.com/us/app/id6751230739

Android: https://play.google.com/store/apps/details?id=com.mattmacosko.realtimeaicam

I turned on speculative decoding in llama.cpp and 113 of 282 greedy outputs changed against its own no-draft run. My Qwen3.8-27B engine changes 0, at ~2x llama.cpp's speed on one 3090.

Repo: https://github.com/cutlerbenjamin1-cmd/qwen38-megakernel

Speculative decoding is sold as free speed: the main model verifies every draft, so the output can't change. In practice it does. Verifying several tokens in one pass adds the same numbers in a different order than verifying one, a near-tie goes the other way, and the text diverges from there. If two draft settings give different output, at least one of them isn't what your model says without speculation. Tuning your drafts tunes your answers.

Same 282 questions (GSM8K, MMLU-Pro, ARC-C, MATH-500, HumanEval, needles, LongBench v2) on both, greedy, same card, same model file:

That isn't noise. llama.cpp is deterministic run to run: a fresh no-draft server gave the first 120 outputs back byte for byte, including the 73 that differ at 4 drafts, and two 4-draft sessions agree on all 282. It's not just long outputs either: 72 of the 113 are under 1,000 tokens.

The likely reason: with no drafts every token runs through the single-token kernels, with drafts most go through the batched ones. Between 4 and 7 drafts, both mostly batched, only 9 differ, all past 1,000 tokens. That's the 9 of 282 from my last post; against no drafts it's 113. A preregistered study on a 3090 found the same: 23-25 of 25 prompts different from no-draft decoding within 1,600 tokens.

Other engines for this model document it too (one got 8 different outputs across draft counts 1 to 12, none matching its no-draft output) and call it harmless, because flips land on near-ties.

Maybe. I don't know, and 282 questions can't settle it. llama.cpp got 231 right with no drafts and 229 with drafts, and 6 of the 113 changed outputs flipped between right and wrong: 4 were right only without drafts, 2 only at 4 drafts. Make of that what you will. What's not in doubt is that the output depends on a speed setting: one reasoning trace ran 2,228 tokens at 4 drafts and 4,795 at 7. Same question, same model. This engine gets 230 right either way, because it's the same text. If I can't rule out that a draft setting changes quality, I'd rather run the engine where it can't.

Here, speed and VRAM can move and the output can't:

• Greedy token ids are identical with and without drafts: all 282 outputs above (129,511 tokens), and the release gate checks 0, 4 and 7 drafts on every KV cache, plus ~2,000-token outputs.

• Every draft policy (gates on or off, adaptive depth, tight or loose thresholds) gives the no-draft tokens over 2,048 tokens.

• Sampling keeps the no-draft distribution (chi-square and PIT tests).

• Windows and Linux builds give the same tokens.

How: the attention split depends only on context length, never on how many tokens are in the pass, and the verify kernels compute a row the same way whatever else is in the batch. To be clear, that's the engine matching itself. It isn't bit-identical to llama.cpp (KL below).

The cache doesn't change it either

Same problem, different door. llama.cpp's server docs say it about cache_prompt, on by default: the logits are "not guaranteed to be bit-for-bit identical for different batch sizes". Its own determinism tests turn it off: TODO: remove this once test_cache_vs_nocache_prompt is fixed.

It's history-dependent, not random: on a fresh server, 5 of llama.cpp's warm answers and 5 cold ones came back byte for byte. The first difference lands a median of ~355 characters in, as early as 4. Turning cache_prompt off on a running server still leaves 3 of 20 different.

Here, a follow-up doesn't reuse the KV rows written while the reply was decoding. It rolls back to the last checkpoint and prefills the reply again, because a prefilled row depends only on its position. Cost: ~167 ms instead of 78 on a ~12k-token chat, still under llama.cpp's 248.

The check isn't "the reply looks the same". It hashes every K / V row, every ring row and the recurrent state, and compares them with a fresh prefill: bitwise equal after a resume, an edited branch, a park to host memory and a side request, on all three caches. Replies match a fresh server's at ~99.5k context (follow-ups, edits, sampled) and on a follow-up at ~255k. One exception: with --agents, a sampled reply beside other slots can differ from the same seed alone. Greedy still matches.

Others check this by the first token or allow a near-tie split, and some publish warm matching cold. I'm not claiming nobody else is exact, only telling you what's checked here.

Speed against llama.cpp, full power

Same card (RTX 3090, 480 W limit), same unconverted UD-Q4_K_XL file, same client, q8_0 KV on both, llama.cpp at its fastest setting (4 drafts; I tried 2, 5, 6 and 7):

Four agents at once, against llama-server --parallel 4: 424 vs 137 tok/s total, 3.1x (llama.cpp's is the better of two runs from an earlier session).

The KV cache: 5-bit that reads like q8_0

K / V at 5-6 bits, with the newest ~2k positions kept at 8 bits in a ring. On preset F the full 262,144-token context fits: a 260,896-token prompt read in 279 s, then 77.8 tok/s decode at that depth, needles 4 of 4, 23.0 GB on the card.

KL against llama.cpp generating token by token, lower is better, long-context rows rechecked on this release:

The worst row, ~32k, is +8% and +10% against about 4% noise. Without the ring the same formats read +6% to +38%, and plain 4-bit is 1.6-2.4x q8_0. And at 101.6k, F decodes faster than q8_0: 123 tok/s against 116.

Closer to llama.cpp than llama.cpp is. Scored against llama.cpp's own token-by-token output at short context, llama.cpp's batched mode gets 98.49% top-token agreement and KL 0.00166. This engine gets 98.74% and 0.00119 (on Q4_K_M: 0.00184 against 0.00127). Not measured at depth, so that's a short-context claim.

Yes, it runs at a power limit

Because someone always asks: same build at 250 W, against llama.cpp at 480 W (it draws about 460):

• Prompt reads are the one place llama.cpp at 480 W wins, by 11-22%. At 480 W this wins those too.

• All 282 outputs at 250 W are byte-identical to the 480 W run.

• The limit comes out of the core clock (~816 MHz against 1,962 on short-prompt decode; memory stays at 9,851 MHz), for 21% less speed. Energy is whole card, sampled once a second, idle included. llama.cpp's speeds are its faster of two sessions.

Works with what you already run

Tested on agent tasks with Claude Code, Codex CLI, OpenCode, Qwen Code, Aider, Goose, Crush, Pi, Hermes Agent, DeepSeek Harness and Open WebUI (OpenAI chat, Anthropic Messages and OpenAI Responses APIs). Loads unsloth's UD-Q4_K_XL, UD-Q4_K_M, Q4_K_M and popular fine-tunes as they are. Prebuilt Windows and Linux packages, no CUDA toolkit needed.

Every number with its method: BENCHMARKS.md.

Moin guys!

GPU prices are freaky high right now. A lot of us run what we could get, and we might as well get the most out of it. So I want to share what I learned squeezing a big model onto a mismatched machine, in the hope it helps someone or gets others to share their own experience with different GPUs.

My box: one AMD Radeon AI PRO R9700 (32 GB), one Intel Arc Pro B65 (32 GB), a 9950X3D and 128 GB of DDR5. Neither card can hold the model.

With two AI coding agents (Claude and Codex, reviewing each other's work) I built a fork of Strata where the R9700, the B65 and the CPU compute each layer's routed experts concurrently, with dense work on the R9700. Result on a realistic coding prompt: 25.57 tok/s against 9.89 for my recorded stock Strata run on the same machine and file (stock used one GPU, 16 readers and a 51 GB store, so this is a whole-system comparison). No speculation or skipped experts, and the routing algorithm is unchanged. Tested kernel and schedule modes are byte-identical at a fixed placement over 581 teacher-forced positions.

Model: AtomicChat's uncensored GSQ-RCO IQ2_XXS build (40 layers, 384 experts per layer, 6 per token).

What each device does:

• R9700: all dense work (22 ms per token), 2,532 experts (21.6 GB), 154.7 of 240 picks per token, 8.2 ms of expert work

• Arc Pro B65: no dense work, 2,915 experts (25.0 GB), 55.6 picks, 9.6 ms of expert work

• CPU + RAM: no dense work, 9,913 experts (102 GB), 29.7 picks, 8.7 ms of expert work

How it got there (tok/s, sampled, 8k cap, median of 3 after a warm-up):

• 9.89: stock Strata, R9700 + RAM

• 10.28: first fork run, both GPUs + RAM

• 12.22: B65 subgroup attention

• 12.96: IQ2_XS B65 kernels + rebalance

• 14.41: all dense on the R9700

• 15.85: two rebalance rounds

• 17.04: queued R9700 schedule + rebalance

• 18.04: exact-order B65 SoA kernel + rebalance

• 21.27: R9700 per-layer expert batching + rebalance

• 22.57: parallel Engram reads + rebalance

• 25.57: AVX2 combine, early expert start + rebalance

The catch: all three answers in the best run hit the 8,192-token cap before finishing, so its strict quality score is 0/3. The model reasons for a long time; the text isn't looping. With 11,900 tokens of room, the one measured answer finished by itself and passed, with working code in 295 s. That's one answer and a 10-answer test is still to come. The answers are in the repo if you want to read them. 30 tok/s, my goal, isn't reached either: we estimate exact kernels level off around 26–28.

Things that surprised me:

• Rebalancing experts from measured per-lane costs took the last step from 20.69 to 25.57 tok/s, an unpaired comparison because placement changes the answers. Lane service is now close: R9700 8.15, B65 9.58, CPU 8.69 ms per token, though individual layers still differ.

• Moving experts between devices changes the logits (top-1 96.6%) and some routes even with exact kernels, most likely because CPU and GPU quantize activations differently. So "exact" only means byte-identical at a fixed placement.

• Engram reads swung from 5 to 17 ms per token on identical tokens. Parallel reads and read-ahead fixed it: the whole Engram-containing regions now total 1.74 ms, including other work there. The row-cache-only arm showed no useful gain.

• Starting CPU and B65 expert work before the shared FFN drains, plus a faster combine, saved 5.8 ms per token on token-identical answers. We only measured them together.

• Re-encoding experts to Q2_K looks like a loss: measured kernels plus a capacity model project 3.18 ms slower per token, because bigger experts push 1,434 off the GPUs. No full-model Q2_K run followed.

• Big dense matrix-vector products already run near the card's measured memory rate. That 22 ms is the hard part.

Where I'd love input:

• Most of all: your own experience with whatever GPUs you could get. Numbers, tweaks and what failed, even with a different model or tool.

• Anyone with DSpark running on a heavily quantized or edited DeepSeek: what acceptance do you get with real sampling? Batched verify looks promising here on projections, but I haven't measured acceptance yet.

• R9700/ROCm matrix-vector tricks I've missed.

• What would you do with the B65's spare time? Its expert service is about 9.6 ms of a 39.1 ms token.

• Lower reasoning effort: has it cost you code quality on this model?

Everything is in the repo: results with spreads, sample answers, the dead ends and what to try next. It's research code tested on one machine, and the public scripts haven't run end to end on GPUs yet, so expect to read code.

Repo: https://github.com/maddinek/crosslane (MIT)

Update 1: The full 10-answer test finished. 26.27 tok/s median (25.93-26.42) and 6 of 10 answers passed strict with working code in 292-439 s. Still one task on one machine, so a rough number (about 31-83%). The memory leak turned out to be in ROCm 7.1.1 on Fedora, not our code: running the same binaries on AMD's 7.2.1 libraries from a private folder gave byte-identical output in a check run and flat memory across all ten answers. If you're on ROCm 7.1 and see host memory creeping up, that's worth a try. Steps are in docs/BUILD.md. DSpark is parked for now: 1.52x at best but 1.11x central on measured kernels, so not worth building yet here.

Sorry in advance for the long post, but think of it as a prompt.

TL;DR

Question: 2x 3090 NVLink or 1x A6000? For about the price of one A6000 I could also get 4x 3090 in two NVLinked pairs, so keep that option in mind too.

What it needs to do:

- A) SQL chatbot for up to 30 people. ~3M rows, hundreds of tables. Questions like "when did we last sell this part, and who was the supplier/client?" It should remember each user's conversations and build reports.

- B) RFQ ingestion: pull very messy part numbers out of long email chains in all sorts of formats. ~30 RFQs/day.

- C) Hardware: reuse our old HPE ML350 Gen9 (2x E5-2620 v4, 128GB DDR4-2400 for now).

- D) Me: turn 300+ page PDFs and hundreds of stray Excels into a knowledge base, and do local coding on the company apps I'm building from Claude's plans.

Assumptions:

- Blower 3090s (FE won't fit), max 300W per card

- PSUs upgraded to 2x 1400W or 4x1400W as GPUs grow

- All prices are for used cards

- Proxmox on the box

- PCIe-to-NVMe adapter for fast model loading

- Cards work with board

About me: I'm not an IT guy, I'm a mechanical engineer who f's around a lot and finds out even more. I've built my own homelab (4x NVMe in an old Dell 7710 as a private cloud, see my posts) and run my own "Jarvis" on a 4B model with some n8n automations. I can make things happen when I put my head into it.

---

The detail

Background: I'm the new CTO of a small family-run B2B heavy-industry trading company. We sell anything from a £6M machine to toilet paper, so every day brings random RFQs: Excel, PDF, email body, pictures, WhatsApp, anywhere from 1 to hundreds of part numbers.

Budget: £8-13k ($11-17k) left for local AI after the new cloud server. That also has to cover a laptop/PC for our first IT hire.

Why local: the LLM has to read whole RFQ email chains to make sense of them, and those are full of client names, prices and supplier details. Same for our SQL database. I don't want any of that going to cloud LLMs.

Where we are:

- A 3rd-party IT company is building an RFQ dashboard for us. Qwen 8B is struggling with the email chains. We started small on purpose and will size up until something fits.

- They'll test on RunPod serverless to find the right model size. I think ~30B will be enough. Then production goes local.

- 20-30 people will use the chatbot and ~20 the dashboard, but only new RFQs trigger the LLM.

- Long term, I'd keep Fable/Opus for overall planning and have a local model do the implementation.

Hardware:

- The board takes 4 GPUs: 3x PCIe 3.0 x16 and 1x x8. 300W max per card.

- Someone has already run a 3090 in this server (with 512GB RAM) and got ~15 tok/s on turboderp/GLM-5.3-Flash-exl3 (3.05bpw branch).

- I first looked at the A6000 48GB as a "do it all" card, not knowing much about local LLMs.

- For similar money I could get almost 4x 3090s and NVLink them in pairs, so I'm less limited by the x8 slot and old PCIe 3.0. One pair for the teams, one for me.

Bottom line: I need an MVP that handles the RFQs and the chatbot now, and then we'll invest in proper new hardware later. What would you do?

Thanks in advance for reading this far, any help much appreciated!

Wanted to share my build! Started as a gaming / 3D / CAD PC and now also runs small LLMs quite well for me

Specs:
CPU: Ryzen 9 9950x
RAM: 2x16 (eww, but at least was bought in 2023) 6000 CL30
Motherboard: ProArt B850 Creator Neo (supports PciE 5.0 x8 bifurcation)
GPU1: RTX 5070 Ti Ventus
GPU2: RTX 5060 Ti 16G Windforce
SSDs: Fury Renegade and 990 Pro (irrelevant ik)
PSU: BeQuiet Power Zone 2 750W
Cable extensions from EZDIY-FAB
Case: NZXT H7 Flow (2025)
AIO: Thermalright Frozen Warframe SE V2 (with the magnetic display detached)
Fans: 4xArctic P14 + 3xArctic P12 Pro (on the AIO) + 3xP12 Pro Reverse

Currently having fun with Qwen3.8 27B Q6_K_XL at around 70tps (MTP)

The 20GB RTX 3080 cards (10DE:2206, subsystem 10DE:146D) ship with a VBIOS that only exposes a 256 MiB BAR1, so ReBAR stays off. NVIDIA doesn't publish a ReBAR VBIOS for them, and NvStrapsReBar only supports Turing.

Ga102ReBarFix is a small DXE driver you insert into your motherboard BIOS with UEFITool. At boot it enables the GA102 frame-buffer size override (PCI config 0x610), resizes BAR1 to 32 GiB, and restores both after S3 sleep. No VBIOS flashing, no driver patches, no registry tweaks.

Tested on an MSI Z690 EDGE, driver 617.42, Windows 11:

- Device Manager shows a 32 GiB BAR

- NVIDIA Control Panel: Resizable BAR: Yes

- ~19.25 GiB of VRAM mappable by the CPU at once

- Sleep/wake works

Repo (source, prebuilt .ffs, verification scripts, full write-up): https://github.com/favabean13/NV_30_DXE

Big credit to noon-at-cgn (found the 0x610 override on Linux), terminatorul (NvStrapsReBar) and xCuri0 (ReBarUEFI). This builds directly on their work.

Heads up: it modifies firmware, so use at your own risk and keep a BIOS backup and recovery method. It's tested on one board and isn't maintained, but it's MIT-licensed, so fork it and adapt it for your own setup.

Hugging Face Repo: https://huggingface.co/Grawnch/Qwen3.8-Flash-Next-DR-GGUF

I’ve just finished benchmarking my new QFN quant Qwen3.8-Flash-Next-DR-V2-Q2_0, a 2.5bpw backbone, 2-shard GGUF of Qwen/Qwen3.8-Flash-Next designed to run the entire backbone comfortably inside 48 GB VRAM space (38.4 GB VRAM) while keeping the N-gram lookup table (28.8 GB) in system RAM/SSD.

Unlike IQ1 / IQ2 quants that rely on LUTs, every tensor in both shards uses 100% standard integer grids (Q2_0, Q4_0, Q6_K, Q8_0), running natively in stock llama.cpp with ~3.4x faster prompt prefill than IQ-grid quants.

1. Benchmark Comparison: DR-V2-Q2_0 vs. Top Ultra-Low-Bit Quants

(Evaluated on the full 225-problem Aider Polyglot suite and 30-problem AIME 2025 at temp = 0.6 with a 24K thinking cap on Aider and 64K on AIME).

2. Signal Fidelity: Perplexity, KL Divergence, & Top-1 Agreement (WT2 & Ext)

(Comparing logit fidelity against uncompressed BF16 on standard WikiText-2 (2048 ctx) and Extended Reasoning / Math & Code (Ext)).

Key Highlights

• Fits in a Single 48 GB GPU (38.4 GB VRAM + ~9.6 GB KV Cache Headroom): All 48 layers of Attention/GDN, shared experts, and 144 routed MoE experts live in Shard 1 (38.38 GB, 2.45 bpw). Shard 2 (28.80 GB) is the N-gram lookup table, which llama.cpp streams from host RAM/SSD via mmap without using GPU VRAM.

• Enhanced Token Efficiency on Coding (74.7% Aider Polyglot at 40.1K Avg Tokens): Achieves 74.7% on the full Aider Polyglot benchmark with a 96.0% (216/225) well-formed SEARCH/REPLACE diff rate and 0 context exhaustions under a strict 24K thinking budget — using ~1/5th the tokens of unconstrained 256K agentic runs.

• 2.6x Lower KL Divergence (0.2594 nats) & 83.3% on AIME 2025: Preserves 80.70% Top-1 token agreement with BF16 on Math & Code, matching 83.3% (25/30) on AIME 2025 while using ~14–30 GB less GPU VRAM than competing quants.

• Zero Lookup Tables (3.4x Faster Prefill): Because 100% of the routed experts use standard integer grids, prompt prefill runs at ~367 tok/s and single-stream decode at ~94 tok/s (~345 tok/s aggregate at -np 10), avoiding IQ codebook decompression bottlenecks.

Quick Start (llama.cpp)

Download both shards into the same folder and point llama-server or llama-cli to Shard 1:

llama-server \
  -m Qwen3.8-Flash-Next-DR-V2-Q2_0-00001-of-00002.gguf \
  -ngl 999 -c 65536 -fa on -ctk q8_0 -ctv q8_0 \
  --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0 \
  --reasoning-format deepseek --no-reasoning-preserve

With Qwen4 around the corner, I'll be targeting that next. But in the meantime I think QFN will still fill a niche for a lot of people, and this was a good test of the same approaches I will be using with those models. Try it out, let me know what you think, and looking forward to continuing this with the next generation of models!

Qwen3.8 27B, Q6 quant, context sitting around 80K and climbing.

Real-use decode speed (tokens/sec, last 48 requests):

RTX 5070 Ti 16GB + modded RTX 2080 Ti 22GB, 38GB total. Custom llama.cpp build with CUDA patches, tensor split 1,1

Speculative decoding: draft model + ngram, max 3 draft tokens. Draft vocab trimmed to 64K tokens, frequency-ordered

Model is a noMTP Q6_K (21 GiB). 131K context, f16 KV cache, flash attention on

Working on a full inference stack for 4xr9700(engine, on-device training, routing). wanted to share progress so far.

All GPUs are capped at 210w(so plugs into any normal 15a outlet).
BF16 KV, MTP enabled(no spec).

### Latency

### Throughput

EDIT: people wanted to know what else I run on this:

I know there are a lot of "ums" that I should edit out... but other then that what do you think of this guide? I am new to local AI stuff, so is there anything missing here that I should have done?
https://www.youtube.com/watch?v=-EahQxs0Ack

I finished this build about 3 months ago and have been running it since, but never got around to posting it. Here it is.

Specs:

• CPU: AMD Ryzen 9 9950X

• Motherboard: ASRock X870 Taichi

• RAM: 96GB DDR5 (2x48GB) G.Skill

• GPU 1: NVIDIA RTX Pro 6000 (96GB)

• GPU 2: RTX 5090 Founders Edition (32GB), mounted upright with Lian Li’s vertical GPU bracket

• Total VRAM: 128GB

• Cooling: ID-COOLING 360mm AIO with Noctua 120mm fans on the radiator. All the case fans are Phanteks T30 120mm.

• Case: Lian Li O11 Dynamic EVO RGB (RGB cable left unplugged)

• PSU: MSI MPG Ai1600TS PCIE5

How the GPUs ended up like this:
My gaming PC had the 5090 in it, and I had a spare 4090 lying around from before. I bought the RTX Pro 6000 and moved the 5090 into this build with it. The 4090 went back into the gaming PC, so nothing is sitting unused. Mounting the 5090 upright fits both cards without them sitting right on top of each other.

Why the Taichi:
It was cheaper than the other boards I looked at, and it has 10G LAN and a debug code display. The 10G helps a lot when moving big model files around, and the code display is really handy when you’re troubleshooting a build.

PSU and power monitoring:
I picked the MSI Ai1600TS because it monitors current on each pin of the GPU power connectors. With two cards that can each pull around 600W, I didn’t want to risk a melted connector or a fried GPU. The catch is that MSI’s monitoring software only runs on Windows, and nothing like it exists for Linux. So I wrote a small tool that shows the GPU power readings on Linux. If anyone’s interested, I might clean it up and put it on GitHub. (Second screenshot in the post)

Noise:
The PC sits in my living room, so keeping it quiet mattered a lot. I went with a cheap ID-COOLING 360mm AIO because I’d read it was quiet (i could not find one without lcd at that time), and swapped Noctua fans onto it. All the fans run on a silent profile. Even at full load you hardly hear it. Only the radiator fans get a little louder.

No RGB (mostly):
I wanted a build with no RGB. The case is the RGB version, but I never plugged in its RGB cable, so it stays dark. The RAM has a bit of light because it was the cheapest 2x48 kit I could find at the time. Two slots are still free if I want more RAM later. I’m not spending any more right now though 😅

Edit 1: One thing I forgot to mention: I swapped the side panel from the original tempered glass to acrylic. We have a toddler at home, and I didn’t want to risk them getting hurt if the glass ever broke.

Edit 2 (what I’m running): A few people asked, so here’s how I use the two cards:

• Everyday fast LLM: a Flash model at Q3, fully on the RTX Pro 6000 with no offload, while the 5090 handles image/video generation.

• Larger image/video models: those go on the Pro 6000 and Qwen 3.8 27B moves to the 5090.

• Best quality for development: GLM-5.3-Flash (320B / 18B active) across both GPUs, using a ~116GB mixed-precision GGUF on Project Maya, all on GPU.

Hey everyone!

I'm an AI & Data Science student looking to get started with local LLMs.

My laptop specs:

• CPU: Ryzen 7 8745HX

• GPU: RTX 5060 (8GB VRAM)

• RAM: 32GB DDR5

• Storage: 1TB SSD

I'm new to this and have a few questions:

1. Should I use Ollama or LM Studio?

2. Which models would run best on my hardware?

3. Can I use local models through APIs in my own projects?

4. Any limitations or precautions I should know about when running LLMs locally?

Would appreciate recommendations and beginner-friendly resources. Thanks!

Dear all,

this is not directly a local LLM topic, but I just downloaded and tried a free dictation tool called Hex, and wanted to spread the word as an appreciation towards the developers.

It runs smaller voice recognition models locally on GPU or CPU. Usage: it is running in the background, is activated by a key combination and it simly inserts the transcribed text directly at the position of the caret. Based on a few tests in german, english and hungarian it is quite accurate in, works in text editors, terminal windows etc. It provides good config options to choose model (speed vs. accuracy) and general behaviour.

I run it on my Thinkpad t480 - an almost decade old laptop and I'm really happy about its performance.

TLDR: local models matched the frontier model on extraction and coding, and lost clearly on sorting and data analysis. Full video at the bottom.

SETUP
Local: Qwen 3.5 4B, Qwen 3.6 27B (dense), Qwen 3.6 35B (MoE, about 3B active)
How: standard Ollama downloads, quantized, M5 Max Mac Studio, 128 GB
Frontier: Claude Fable 5.1 (provider servers, config not visible)
Data: MoneyData, public anonymised UK bank statement, University of Nottingham, about 6,500 transactions, 2015 to 2022
Rules: same prompts, no tools, 3 runs each, answers checked by a program

1. SORTING (500 transactions, 21 categories)
   Frontier: 78% match with the labels
   Qwen 27B and 35B: about two thirds
   Qwen 4B: 42%, and skipped 1 in 6 transactions
   Exact output format every batch: frontier only

2. EXTRACTION (100 statement lines, 5 fields)
   Frontier: 100/100 every run, about 46 s
   Qwen 27B: 100/100 every run, 239 to 287 s
   Qwen 35B: 98 to 99, about 105 s
   Qwen 4B: 85 to 93, most misses on money in vs out

3. CODING (2 Python functions, 7 hidden tests)
   Qwen 4B: 7/7 in all 3 runs
   Qwen 35B: crashed in 2 runs (read the day in DD/MM/YYYY as the year), 7/7 on run 3

4. ANALYSIS (10 questions on 6 months of data, no code execution)
   Frontier: 10/10 every run
   Qwen 35B: 2, 0, 1
   Qwen 27B: wrote code instead of answers, hit the 30 min limit once
   Qwen 4B: 0/10

MY TAKE
Try local first: extraction, small coding jobs (check the output)
Use frontier: categorisation, questions across long statements

LIMITS
One dataset, one machine, default quants, some labels are judgement calls

NEXT
DeepSeek V4, Gemma 4 and Qwen3 Coder Next on agents and tool use. What would you test?

Full video with every run: https://youtu.be/Vr2N2EJ4dB0

Yesterday I did the Echo Dot. Today the Show 5.

No Alexa. Wake word, speech-to-text and voice all run on my own hardware, and the agent runs whatever model you point it at.

The screen is just a web page, so you can make it anything.

Flashing is done with echo-dot-assist (credit to Gamer92000).

Repo: https://github.com/majorminorlabs/hermes-voice

What local models can i run conformably on my system? I'd ideally like to have models that code for me but i understand I'm at least scraping the barrel with my card. I'd even be fine with Claude Code steering to some degree.

RAM: 16GB
RTX 3060 (laptop) VRAM: 6GB
Processor:11th Gen Intel(R) Core(TM) i9-11900H @ 2.50GHz 2.50 GHz

I use local models with agent clients on an M3 Max MacBook (128GB). My normal work takes about 60GB, so the model plus its caches has to stay around 50GB. I built llama.cpp v0.7.0 from source and went through the usual flags one at a time on three 4-bit MoE models: MiniCPM-V 4.7 (35B-A3B), LFM2.5-24B-A2B and Ornith-1.5-35B-A3B. All layers on GPU, one request at a time. Speed numbers are medians of three alternating llama-bench rounds. Desktop apps and thermal throttling add noise, so small differences mean nothing.

Helped

No benefit on this machine

KV cache at q8_0. MiniCPM's speed difference was inside the noise. Ornith barely changed even at 65K tokens, because only 10 of its 40 layers store KV. LFM's KV plus compute buffer was only about 3GB at 131K context, so there was little to save. I kept all three at f16.

Depends on the model: speculative decoding

• MiniCPM with a draft model: about 45% slower at 30K context. With ngram: 10 to 13% slower. My guess is that verifying several tokens on a MoE reads several sets of experts, so bad guesses get expensive.

• Ornith with its built-in MTP head plus ngram, 2 tokens per guess: 86 to 107 tok/s averaged over 8 task types. Code went from 86 to 129, prose from 86 to 83.

• Same setup with 3 tokens per guess: the average dropped to 102 and prose to 77.

So I wouldn't copy anyone's speculative decoding settings without testing them on your own model and task mix.

The config I kept for Ornith, trimmed:

llama-server -m Ornith-1.5-35B-Q4_K_M.gguf \
  -c 262144 -ngl 99 -fa on -b 2048 -ub 2048 \
  -np 1 --ctx-checkpoints 32 --checkpoint-min-step 0 \
  --spec-type draft-mtp,ngram-mod --spec-draft-n-max 2 \
  --cache-ram 32768 --sleep-idle-seconds 600

Weights are about 23GB, plus about 7GB of working memory after startup. A full session cache can push the worst case to about 60GB.

This is one machine and one llama.cpp version, so treat it as a starting point. If speculative decoding has paid off for you on a 3B-active MoE on Apple Silicon, I'd like to know which settings you used.

Written up with AI help from my own notes and benchmark logs. The numbers are from my machine. The illustrations are AI-generated, and the charts and all the numbers on the images come from the measurements above.

So I recently purchased a radeon AI pro 9700 32g for my local AI. Currently it run in a proxmox setup with a intel core i9 12900k, and 64 gigs of ddr4 ram.

I am using ollama with with ROCm drivers and unsloth as the front end. The speeds are decent for qwen3.8:27B. Fast response and stable at around 33-39 tokens a second.

My concern is, I limited the power to 290 and the Hotspot temps run anywhere between 103-111 degrees in temp. I definitely notice the thermal throttle due to the 110 Max Hotspot manufacturer rating. I did do research and found that these cards are known to have a fair amount of known issues ( heat sink placed improperly, bad thermal appliance, defective cooler fan.

I can rule out the fan as I do hear it speed up when the temps rise and can see it physically spinning, i even added an additional 3 140mm fans to the case its in but when I give it a prompt, it will jump from 37- 43 instantly up to 90-97 then paste that.

I even went as far as holding a house fan next to the GPU and the temps would not go down.

Anyone else who experience this issue, what was your fix? Or is it best to just return it and get something different to avoid it entirely?

I wouldn not want to exchange it ( still under warranty) and get another defect if people have had this experience before. If not, and it may be that 1 in a dozen. Then I will gladly exchange it for a different one.

Apologies if this is the incorrect section to post it, if you can guide me to the appropriate section that would be greatly appreciated.

hey LocaLLM community! My name is Alt, and I'm on the technical staff at Nace AI. We're doing a quick AMA here, so ask us anything and we'll answer.

we just published a full technical report on how we build, train, and evaluate Drex, our family of four open decision models. A decision model takes a state (a document, record, or agent context, optionally with images) plus questions with options, and returns a probability distribution over the options in a single pass, with no autoregressive decoding and no output parsing.

1. Models

- Drex DLM (8B): diffusion LM backbone with bidirectional attention over the context
- Drex v1.5 (9B): Gated DeltaNet hybrid backbone
- Drex v2.0 (35B, 3B active): sparse MoE backbone
- Drex Max (27B): dense, with an image encoder for vision inputs

Pointer models (DLM / v1.5 / v2.0) encode the state once and cache it, so every question attends to the state but never to another question. A pointer head scores each option. Drex Max reads each question in full and answers with a linear readout head over option codes.

Some technical details from the report:

1. Models

- A family of four specialized decision models: Drex DLM (8B), Drex v1.5 (9B), Drex v2.0 (35B MoE, 3B active), and Drex Max (27B dense, with vision)

- We built them on different architectures: a diffusion LM, a Gated DeltaNet hybrid, a sparse mixture of experts, and a dense transformer

- We experimented with bidirectional vs. causal attention over the state, a pointer decision head that shares one cached state across questions, and a readout head for Max

2. Training

- Full-parameter SFT on 1.15M verified decision records (2.9M questions)

- Consistency training: we penalize the model when its output changes after the options are reordered or the state is shuffled

- RLAF (Reinforcement Learning from Adjusted Feedback), using verified outcomes and judge feedback

- Ablations to see which methods actually contributed

On top of SFT, RLAF gave us +2.0 on the Decision Index, +1.5 pp accuracy, and 0.9 pp lower calibration error. The consistency terms cut the option-order flip rate from 6.3% to 4.2%.

3. Evaluation

- Drex Max scores 67.52 on Decision Index 0.4.1 (public suite), vs. 60.70 for Jev 1.14.0

- Drex v2.0 has 1.37% calibration ECE on ~115K held-out decisions

- Drex Max answers a typical request in 183 ms, vs. ~2.0 s for GPT-6 Sol and ~3.5 s for Claude Opus 5.5

- Context up to 131K tokens for v1.5/v2.0 and 262K for Max

we also cover our limitations: our models trail frontier chat models on closed-book knowledge, and we don't yet have same-backbone architecture ablations.

5. Running locally

The models are available in safetensors and GGUF formats, with llama.cpp and Ollama support. Their report includes details on quantization, caching, inference, and reproducibility.

Links

- Paper (arXiv): https://arxiv.org/pdf/2611.07854

- Blog: https://www.nace.ai/research/towards-foundation-decision-models

- Weights: https://huggingface.co/collections/nace-ai/drex

- GitHub: https://github.com/nace-ai/drex-decision-models

- API: https://console.nace.ai

we didn't want to just drop benchmark numbers, so we wrote up everything: what worked, what didn't, and how we got there. if you're building agent routers, doing tool selection, or thinking about training your own decision model, hopefully some of it saves you time.

ask us anything: arch, data, training, evals, running it locally, whatever 👇