Devotd Github
NewInference & serving

prabanta-dev/janas — llama.cpp comparison with the 8-bit KV cache conditions matched

janas's latest commit updated three documents with the results of re-measuring the long-context comparison table under the same 8-bit KV cache conditions as llama.cpp.

Repositoryprabanta-dev/janas ↗

janas's latest commit updated three documents with the results of re-measuring the long-context comparison table under the same 8-bit KV cache conditions as llama.cpp.

GitHub description: 37 tok/s from Qwen3-Next-80B (48 GB) on a 32 GB laptop, 24 without drafts vs 2.8 for llama.cpp; reading 62 vs 16 tok/s. Faster than llama.cpp on all 13 models compared in Q4_K_M. LLMs bigger than your RAM, pure C, CPU or GPU.

stars
★ 469
Forks
37
Language
C
License
GPL-3.0
Latest release
v2026.10.27
Read original source ↗View on GitHub ↗

prabanta-dev/janas is an inference engine written in pure C, aiming to run LLMs larger than memory on CPU or GPU. The repository's latest commit f085859 (2026-10-27, titled 'Release 2026-10-27 (4)') changed only three documents and not a single line of code. It added 19 lines and removed 19 lines in README.md and the release copies dist/README.md and dist/README-windows.md. What changed is the long-context comparison table. It re-measured llama.cpp with the cache that holds keys and values in 8 bits (KV cache) set to q8_0 on both sides. At 8,192 tokens, Janas-LLM wrote answers at 18.2 tok/s and read prompts at 74 tok/s, while llama.cpp was at 4.9 tok/s and 20 tok/s respectively.

The point of this change is to align the comparison conditions. In the previous table only Janas-LLM used an 8-bit cache, while llama.cpp used the default 16-bit. This time llama.cpp was also given -ctk q8_0 -ctv q8_0, and flash attention (-fa 1), which is required for q8_0 cache values, was enabled for the re-measurement. Once the conditions matched, the gap narrowed but did not disappear. At 1,024 tokens, writing was 27.6 versus 12.1 tok/s, a factor of 2.3; at 8,192 tokens it was 18.2 versus 4.9 tok/s, a factor of 3.7. At 16,384 tokens, llama.cpp could not finish reading the prompt within 30 minutes, so it produced no write figure, and reading was only shown as under 9.1 tok/s. 32,000 tokens were measured for Janas-LLM only (read 35 tok/s, write 10.7 tok/s). The llama.cpp results at the 16-bit default were kept separately. For 1,024 to 16,384 tokens, reading was 67·55·44·31 tok/s and writing 12.5·7.7·4.6·2.2 tok/s.

However, the evidence is narrow. Both engines used CPU only (12 threads), and the same Qwen3-4B Q4_K_M file and the same tokens (an English Wikipedia document, C source code, Italian prose), but each measurement was run just once, with a 30-minute cap on every run. The llama.cpp write figure at 16,384 tokens and the 32,000-token comparison were left empty because of the cap. The paragraphs and tools describing Intel NPU and GPU, Gemma 4, and janas-nsm were not touched in this patch. Since the commit changed the numerical documentation rather than the engine code, it does not by itself mean an improvement in runtime performance. It is right to read it as a record obtained from one model on one laptop, from a single measurement.