prabanta-dev/janas 是一个用纯 C 编写的推理引擎，目标是让比内存更大的 LLM 能在 CPU 或 GPU 上运行。该仓库的最新提交 f085859（2026-10-27，标题为“Release 2026-10-27 (4)”）没有改动任何代码，只改了三份文档。它在 README.md 以及发行版用的 dist/README.md、dist/README-windows.md 中新增 19 行、删除 19 行。改动的内容是长上下文对比表。两侧都把存放键和值的缓存（KV cache）统一为 q8_0 后，重新测量了 llama.cpp。在 8,192 个 token 处，Janas-LLM 以 18.2 tok/s 写出回答、以 74 tok/s 读取提示，而 llama.cpp 分别为 4.9 tok/s 和 20 tok/s。
这次改动的要点是对齐比较条件。此前的表格中只有 Janas-LLM 使用 8 位缓存，而 llama.cpp 使用默认的 16 位。这次也给 llama.cpp 加上了 -ctk q8_0 -ctv q8_0，并开启了 q8_0 缓存值所需的 flash attention（-fa 1）后重新测量。条件对齐后，差距缩小了，但并未消失。在 1,024 个 token 处，写入为 27.6 对 12.1 tok/s，即 2.3 倍；在 8,192 个 token 处为 18.2 对 4.9 tok/s，即 3.7 倍。在 16,384 个 token 处，llama.cpp 在 30 分钟内未能读完提示，因此没有给出写入数值，读取也只显示为低于 9.1 tok/s。32,000 个 token 只测量了 Janas-LLM（读取 35 tok/s，写入 10.7 tok/s）。llama.cpp 在 16 位默认值下的结果被单独保留。在 1,024～16,384 个 token 区间，读取为 67·55·44·31 tok/s，写入为 12.5·7.7·4.6·2.2 tok/s。
不过，证据范围很窄。两个引擎都只使用 CPU（12 线程），使用相同的 Qwen3-4B Q4_K_M 文件和相同的 token（英文维基百科文档、C 源代码、意大利语散文），但每次测量只跑一遍，每次运行都有 30 分钟的上限。16,384 个 token 处 llama.cpp 的写入数值和 32,000 个 token 的比较都因为触及上限而为空。介绍 Intel NPU 与 GPU、Gemma 4、janas-nsm 的段落和工具在本次补丁中没有被改动。由于该提交改动的是数值文档而非引擎代码，因此这本身并不代表运行性能有所提升。应当把它看作来自一台笔记本上的一个模型、单次测量的记录。