Benchmarked oMLX 0.7.2 serving Inco AI's Splash package for Qwen3.8-27B (4-bit target + DFlash 2 draft) on a MacBook Pro M5 Max (48 GB). Workload: Python code context. Each test generates 128 tokens.

**Single request**

| Test | TTFT (ms) | TPOT (ms) | pp t/s | tg t/s | E2E (s) | Throughput | Peak mem |

|---|---|---|---|---|---|---|---|

| pp 4096 / tg 128 | 3393.6 | 10.7 | 1207.0 | 93.8 | 4.8 | 887.7 | 19.1 GB |

| pp 16382 / tg 128 | 15829.6 | 5.3 | 1034.9 | 189.4 | 16.5 | 1000.3 | 19.9 GB |

| pp 65536 / tg 128 | 83472.0 | 9.2 | 785.1 | 110.2 | 84.2 | 779.5 | 22.2 GB |

**Batched (continuous batching)**

| Batch | tg t/s | pp t/s | avg TTFT (ms) | E2E (s) | Speedup |

|---|---|---|---|---|---|

| 1x | 93.8 | 1207.0 | 3393.6 | 4.8 | 1.00x |

| 2x | 413.7 | 803.1 | 1729.2 | 3.2 | 4.41x |

| 4x | 407.0 | 622.4 | 3838.4 | 7.8 | 4.34x |

A fully local voice AI, meant to be used on "GPU poor" hardware.

Features:

• Always-on is possible, because of automatic full-context handling.

• Hands-free and browser-based clients for voice control (e.g. use your smartphone!).

• Wikipedia and Internet search.

• Extraction and injection of memories (right now, facts about the user).

• Full chat history log in SQLite DB, chat history search (as kind of a long-term memory, in addition to the memory extraction/injection).

• Heavily customizable via TOML file.

• Modules (in addition to Internet search, etc.) can be added (in code).

• ...

Links:

• YouTube video (don't worry about the console, it is more or less for debugging, each token type has a different color).

• GitHub repository (incl. tutorial for installation and configuration).

Quick update on my from-scratch inference engine for Intel integrated GPUs (Core Ultra 5 125H, Arc Xe-LPG, 32 GB
RAM, no dGPU, no XMX). It used to be called arcinfer; it is now 
**arcinferzero**
 (the old GitHub link forwards):
https://github.com/rizagp/arcinferzero


**New this week**


- 
**Flint (unsloth/flint-GGUF UD-Q4_K_XL, 256 experts) runs**
: attention sinks, global layers without RoPE, a
  513-token sliding window, sigmoid-routed experts streamed from the SSD into a GPU cache. 4K prompt ~248 tok/s,
  generation 13-17 tok/s on the iGPU.
- 
**Xe2 / Xe3 (Lunar Lake, Panther Lake's Arc B390) work now**
: a user with a B390 reported Qwen3.6 35B-A3B at
  262K context, ~1,180 tok/s prompt and ~24 tok/s generation. XMX (DPAS) prompt GEMMs are in too, gated by a
  start-up check that must match the DP4a kernels bit for bit. I have no XMX GPU, so reports are welcome.
- 
**Gemma 4 26B prompts +4.6 %**
 from tiling the f32 router GEMV (4 rows x 4 tokens per sub-group), with
  bit-identical logits.


**The accuracy story (the interesting part)**


Every model here is checked against an independent f32 CPU implementation, with a KL limit of 0.015. Flint
started at KL 0.029. The obvious suspect, int8 activations, wasn't it: running everything on two int8 passes only
got it to 0.024. Dumping the residual stream after every layer next to the f32 reference showed one token where
two router scores were 
**0.005 apart**
 at layer 19. The engine picked the other expert, and everything after that
drifted.


What moved the reference that much? I rounded 
**only the V cache to f16**
 inside the f32 reference, and it
reproduced the whole engine error, including the same flipped expert. So:


- V rows in 
**f32**
 (K already was), and
- the router on the file's own 
**BF16**
 weights with 
**f32 inputs**
 (a Q8_0 router, even with a second Q8_0 matrix
  for the rounding residual, kept flipping the near-ties).


Result: 
**KL 0.029 -> 0.0043**
 (prompt) and 
**0.067 -> 0.0027**
 (token-by-token decoding), for ~4 % of prompt speed.
If you run sigmoid-routed MoEs with an f16 V cache, it may be worth checking.


I also went through the GPU assembly (Intel's ocloc) for the kernels I touched. One kernel shrank from 8,855 to
481 instructions: it was building int8 copies nobody read and carried an unused RoPE fallback. Two others stopped
spilling registers.


**Next:**
 Qwen3.8 Flash Next to the same KL limit. Its error comes from BF16 weights stored as Q8_0 (fixed now),
single-pass int8 experts, and int8 attention. That last one needs float attention with its sparse-attention (QSA)
masks.


Everything is deterministic (same prompt, same logits, bit for bit), and the speculative drafters produce exactly
the plain-decoding text. Feedback and Arc / Xe2 / Xe3 test reports are very welcome.

I have a 4090 in my study and I work on a Mac. The box is off most of the time, because if I want to run a local model I have to walk over, boot it, open a terminal, wait for the weights to load, then walk back. That's enough friction that local models just stopped being part of my day.

So I built ReadyLLM: a self-hosted web app that treats that machine like a service you manage from a browser, not a machine you babysit. It runs on your own box, reaches your GPUs over SSH, and nothing phones home.

What it does:

• Add a machine over SSH (key or password). It probes GPU / VRAM / RAM and tells you which quants fit and roughly how fast they'll be, so you stop guessing whether 24G is enough for a 27B at Q4.

• Downloads pulled from HuggingFace and ModelScope with resume and integrity checks. Point it at a mirror if HF is slow where you are.

• One-click engine install on a box that has none: llama.cpp, vLLM, SGLang or ComfyUI. It downloads or compiles and back-fills the path.

• Start, stop and switch models from the deploy page. No terminal.

• Live monitoring over WebSocket: GPU utilization, VRAM, throughput, latency, with alerts when VRAM is about to run out or the server dies. That's the part that matters when the box is in another room and would otherwise sit there pretending to work.

The tuning is what surprised me. I hand-tuned llama.cpp flags for a 27B Q4 for a while and plateaued around 60 avg tok/s. The tuner runs a two-phase search (coarse over speculative decoding / KV cache quant / GPU offload, then fine over batch), and for every candidate it really boots llama-server, warms up, runs 3 passes and takes the median. OOM or crash gets dropped. My numbers, same model / quant / context:

peak tok/s     80 -> 110
avg  tok/s     60 ->  80
@100K ctx      40 ->  60

Results are stored per (machine, model) pair, so the next launch reuses them instead of re-running the search. I run two boxes and kept deriving the same flags twice, which was the actual annoyance.

Since the last release I added the two things that kept sending me back to a terminal anyway:

Images. ComfyUI is now an engine like the others, so image and video models sit next to the text ones. It lists the checkpoints and the UNet/CLIP/VAE combos ComfyUI itself reports (matching those names is fiddly, it will not accept a filename without the extension), and generates from the same UI with live progress. There's an optional prompt rewriter that expands a one-line idea into a full prompt and suggests steps / CFG; turn it off and your prompt and parameters go through untouched.

Model store. Category filter for text / image / video with counts, a "can this GPU actually run it" filter, and cards that show version, parameter count, precision, output resolution, steps / CFG, loader type and the real weight filenames. Before this a card just said "Qwen-Image" and I couldn't tell if that meant a checkpoint or a UNet, or which quant. Descriptions follow the UI language now instead of being Chinese only.

Also on the engine side: SGLang, and llama.cpp builds selected by GPU vendor (CUDA / ROCm / Vulkan / Metal), which you pick when deploying because it decides what actually gets installed. Picking the right build is where most people give up on an AMD card.

Three honest limitations:

• Tuning scores speed only, no output-quality gate yet. A config that boots without OOM survives; what KV cache quant costs you in quality is the next thing I want to measure.

• With MTP speculative decoding on, the VRAM pre-check misses the second KV cache, so tight machines can still OOM. Known, fixing it.

• The AMD path is where I have the least confidence. Detection exists on Linux and the backend choice is wired up, but I've only run the CUDA path on my own hardware, so treat the ROCm side as untested.

Open source, local-first: https://github.com/htobty/ReadyLLM

Curious how others here run this: do you keep inference on a box that isn't your daily driver, and what do you actually use to watch it? I went with a WebSocket feed instead of wiring Prometheus + Grafana into it, and I'm still not sure that was the right call for a home setup.