Maurizio Cammalleri, working alone on a single Intel laptop, has built a C-based LLM inference engine called Janas that consistently outperforms llama.cpp — the de facto open-source standard — across every model configuration tested. The headline number: 37 tokens per second generating from Qwen3-Next-80B, a 48 GB model, on a machine with only 32 GB of RAM. llama.cpp manages 2.8 on the same hardware. The trick is architectural: Janas treats the NVMe SSD as a streaming memory layer, pulling only the mixture-of-experts layers each token actually activates and caching the ones that recur. The benchmark table is comprehensive and, unusually for a solo project, methodologically careful. Thirteen models compared head-to-head against llama.cpp build 2b18470 (September 2026) on identical hardware: Debian 13, Intel Core Ultra 9 185H with integrated Arc GPU, 32 GB DDR5, 1 TB NVMe rated at 5.7 GB/s. Every figure is a mean of multiple rounds, alternating order to control for thermal and cache effects. The margins range from modest (Qwen3-30B-A3B reading: 135 vs 122 tok/s) to enormous (Qwen3-Next-80B writing: 24 vs 2.8 tok/s — an 8.6x gap). Prompt reading consistently beats llama.cpp by 1.3x to 4x; generation by 1.4x to 8.6x. The design philosophy is radical minimalism. Pure C with no dependencies beyond the C library. No Python, no CUDA, no frameworks. The GPU path uses Vulkan through Intel's integrated Arc, and the engine auto-tunes its own thread allocation by benchmarking every core count on first run. The expert cache fills available free memory; ODIRECT bypasses the OS page cache for disk reads. This is systems programming in the old style — one programmer knowing exactly what the hardware does and writing code that exploits it. The project is honest about its limitations in ways that matter. It calls itself an experiment, not a product. The API changes several times a week. It has been developed and tested on exactly one machine. The aggressive memory behavior can push a desktop into swap. GPU usage has caused at least one driver reset. There is no testing on AMD CPUs, discrete GPUs, or slower storage. The one exception in the benchmark table — a 3-bit quantized model where llama.cpp reads prompts faster — is called out explicitly, with the reason (those weight formats don't yet use the GPU fast-prompt path). What makes this structurally interesting is not just speed but the unlock it represents. Running models larger than physical RAM at interactive speeds on consumer hardware is a qualitative threshold, not just a quantitative improvement. If an 80B MoE model can generate at 37 tok/s on a laptop, the minimum viable hardware for serious local inference drops dramatically. This directly threatens the cloud inference margin that funds most AI companies — every token generated locally is a token not billed through an API. The speculative-decoding integration (drafts) adds another layer. Models with built-in prediction blocks (Qwen3.5, Qwen3.6, Qwen3-Next, larger Gemma 4) see meaningful speedups: Qwen3-Next-80B jumps from 22 to 37 tok/s with drafts. The survival rate of draft tokens — 74-89% on English, dropping to ~33% on Italian prose — is reported with the kind of specificity that suggests the developer understands what's real and what's noise in a 64-token measurement window. The question is whether this can travel beyond one machine. Every optimization is empirically tuned to a specific Intel CPU, a specific SSD bandwidth, a specific GPU driver stack. The engine's auto-tuning is designed to generalize, but generalization is exactly what hasn't been tested. If the performance holds on diverse hardware, Janas represents a genuine shift in what's possible with local inference. If it doesn't, it's a brilliant proof of concept that proves one developer can out-engineer a well-funded open-source project on one specific laptop.
