Frontier on-device AI lab. Models, runtime & infrastructure to make on-device AI interactive, ambient & continuous.
San Francisco
Joined January 2025
- Tweets107
- Following34
- Followers1.6K
- Likes376
Pinned Tweet
Today we are releasing our speculative decoding implementation in our inference engine uzu.
Initially for Qwen3.6 27B, with support for Qwen3.8 27B and Muse Glimmer coming soon.
On Apple M5-series chips, we outperform MTPLX (MLX + speculative decoding) by almost 2x, and llama.cpp by over 3x at comparable quantization levels, with the strongest gains achieved on mathematical reasoning and coding tasks.
Run the model:
Mirai-M: trymirai.com/local-models/al…
Mirai-L: trymirai.com/local-models/al…
Explore the benchmarks:
trymirai.com/metrics
Learn more about our speculative decoding implementation:
trymirai.com/blog/speculativ…
Our draft model, quantized checkpoint format, verification algorithm, and GPU kernels are co-designed from the ground up around the latest Apple M5 chips to take maximum advantage of GPU Neural Accelerators.
Unlike popular speculative decoding architectures such as model-native MTP, which produce small draft chains of 3-4 tokens at a time, we use extremely aggressive speculative budgets of 16-32 tokens. This enables us to use Neural Accelerator-backed GEMM kernels, achieving maximum utilization of hardware arithmetic throughput.
Mirai Labs retweeted
We have released a new version of uzu and run the latest benchmarks on Qwen-3.8 27B we are by far the fastest at decode, and our checkpoints match Unsloth quality frontier and significantly surpass MLX ones in terms of quality
github.com/trymirai/uzu
882 tok/s prefill on M5 Max for Qwen3.8-27B, with uzu.
Compared to Splash:
prefill: 1.83x faster
time to first token: 1.81x faster
generation: 1.05x faster
Measured on MT-Bench, MATH-500 and HumanEval.
Please note that the evals used (MT-Bench, MATH-500 and HumanEval) are not very representative of the normal agentic use. We show the numbers on those specific datasets for the sake of interpretability of the results. The performance on the long context multi-turn interaction will be different.
Mirai Labs retweeted
We may have cooked a 2-bit version of Qwen3.8 27B which *actually works*, is not deep fried to benchmaxx, and fits in 8.5GB
We have not yet finished evaluating it, and it'll take some time to properly ship it, but if someone wants to try and share feedback please dm me
Mirai Labs retweeted
Mirai Labs (@trymirai) compressed Qwen3.8-27B to 2.4 bits. I ported it to llama.cpp and now it runs on a 12 GB card with 128K context.
With q4 KV cache the 128K window takes 11.3 GB of VRAM, with q8 KV you get 74K in 11.1 GB. Decode is 40 tok/s, still 34-35 tok/s at 62K deep, and prefill around 1000 tok/s. I measured all of it on 1 RTX 3090 at 300 W, capped to what fits in 12 GB.
No requant anywhere. The GGUF carries Mirai's compressed codes bit for bit, and greedy output matches their own vLLM plugin.
Everything in the video was built by this same model as an agent in pi, 11 builds from 1 prompt each, a few needed a follow up and 1 is a blooper. That run was vLLM on my 3090s. Today the same weights run in llama.cpp.
Big thread, all links and recipes 👇
Our team loves to catch unique bugs
Our GPU whisperer @ychnzhn4 wrote a small blogpost about the most annoying bug I have ever seen, which was an absolute nightmare to catch
trymirai.com/blog/tackling-r…
📣 We've just published our latest research on state-of-the-art speculative decoding in interactivity.
Introducing a new approach that achieves a 4.37× speedup over autoregressive decoding in small batch setting and outperforms the strongest tuned DFlash baseline by 24.7%.
arXiv: arxiv.org/abs/2607.06763
github: github.com/trymirai/sglang
huggingface: huggingface.co/trymirai/weav…
Mirai Labs retweeted
We are releasing our first quantized checkpoints for the Qwen3.5 series of models, co-designed jointly with our inference engine to achieve maximum possible performance on Apple hardware
Starting from 0.8B, 2B and 4B models
trymirai.com/blog/quantizati…
Google DeepMind released Gemma 4.
Our engineer @norpadon analyzed the architecture
If you've implemented speculative decoding, you've run into this: your speculator predicts the distribution correctly and still gets rejected.
Let’s take an example:
"The random number from 1 to 10 inclusive is"
Ideal LLM: uniform 1/10 across all numbers.
Good speculator: same distribution.
In that situation, the naive scheme takes a random number from the speculator, then takes another random number from an LLM and can only accept the bonus token in 1/10 cases when they happen to match.
We should be able to always take its guess without the loss of generation quality.
The fix is straightforward.
Sample from both the speculator and the LLM using the same seed via the Gumbel-max trick.
Shared randomness means shared outcome when distributions match.
100% acceptance rate in this case. Near-optimal in practice.
We shipped this in github.com/trymirai/uzu
Full kernel implementation: trymirai.com/blog/how-to-imp…
Day 0 on-device support of the latest and the smallest @liquidai model
LFM 2.5 350M is now available on @trymirai
Day 0 support across the stack:
> Hardware: @AMD, @Intel, @Qualcomm
> On-device: @lmstudio , @Cactuscompute, @RunAnywhereAI , @zeticai_ , @trymirai
> Customization: @distil_labs
LFM2.5-350M is now available on Mirai.
@liquidai smallest model outperforms Qwen3.5-0.8B on reasoning and agentic tool use.
Running on Mirai in full precision, it exceeds 70 tokens/second on iPhone.
LLM activations have outliers. A few channels spike 100x past the rest, every token. Standard INT8 wastes almost all its precision covering them.
The fix: rotate the weight space so outliers disappear before quantization. It's why QuaRot and TurboQuant work.
Here's how we implemented it:
trymirai.com/blog/why-activa…
Morton codes for GEMM
Apple just released its programming guide for Metal Performance Primitives, and they suggest using Morton codes for tiled GEMM, but why?
In computer graphics, you use such space-filling curves all of the time
It makes objects that are close in space to be close in memory
There are several reasons, but one of them is that you get better cache locality, meaning less expensive reads from the device memory
This is exactly why it’s appealing for GEMM too - you have a lot of overlapping memory reads between the tiles
Morton schedules tiles in compact square patches, minimizing the working set that fits in last-level cache simultaneously, so nearby threadgroups are more likely to reuse the data they share