在一台 32 GB 内存的笔记本上,Qwen3-Next-80B(一个 48 GB 的模型)达到 37 tok/s,无草稿时为 24,而 llama.cpp 只能做到 2.8;读取提示时,为 62 tok/s 对 16。在同一台笔记本上(Debian 13 Linux、Intel Core Ultra 9 185H、其集成 Arc GPU、32 GB、一块 NVMe SSD;2026 年 10 月 9-11 日;整台机器如下):
| 模型 | 读取 1,024 个 token:Janas-LLM | llama.cpp | 写入:Janas-LLM | llama.cpp |
|---|---|---|---|---|
| Qwen3-Next-80B-A3B(48.4 GB,超过内存) | 62 tok/s | 16 tok/s | 24 tok/s | 2.8 tok/s |
| Qwen3-Coder-Next(48.4 GB,超过内存) | 66 tok/s | 14 tok/s | 22 tok/s | 2.2 tok/s |
| Qwen3.6-35B-A3B | 104 tok/s | 79 tok/s | 19 tok/s | 12 tok/s |
| Qwen3-30B-A3B | 135 tok/s | 122 tok/s | 32 tok/s | 15 tok/s |
| Gemma-4-26B-A4B-it | 84 tok/s | 76 tok/s | 18 tok/s | 12 tok/s |
| Gemma-4-12B-it | 65 tok/s | 46 tok/s | 9.9 tok/s | 7.1 tok/s |
| Qwen3.5-9B | 111 tok/s | 78 tok/s | 14 tok/s | 8.7 tok/s |
| Gemma-4-E4B-it | 122 tok/s | 109 tok/s | 20 tok/s | 15 tok/s |
| Qwen3-4B | 193 tok/s | 164 tok/s | 27 tok/s | 18 tok/s |
| Gemma-4-E2B-it | 191 tok/s | 150 tok/s | 38 tok/s | 19 tok/s |
| Qwen3.5-2B | 441 tok/s | 323 tok/s | 52 tok/s | 28 tok/s |
| Qwen3.5-0.8B | 799 tok/s | 519 tok/s | 109 tok/s | 32 tok/s |
| Qwen3-0.6B | 939 tok/s | 670 tok/s | 130 tok/s | 45 tok/s |
来自其他来源的相同模型,就在旁边的目录中:
| 模型 | 读取 1,024 个 token:Janas-LLM | llama.cpp | 写入:Janas-LLM | llama.cpp |
|---|---|---|---|---|
| Qwen3-30B-A3B,bartowski 的 Q4_K_M(重要性矩阵) | 131 tok/s | 122 tok/s | 32 tok/s | 16 tok/s |
| Qwen3-30B-A3B,unsloth 的 UD-Q3_K_XL(3 位) | 100 tok/s | 112 tok/s | 36 tok/s | 11 tok/s |
| Qwen3-4B,bartowski 的 Q4_K_M(重要性矩阵) | 191 tok/s | 160 tok/s | 26 tok/s | 18 tok/s |
一个例外:3 位的 Qwen3-30B 读取提示比 llama.cpp 慢,因为它的 Q3_K 权重尚未进入 GPU 的快速提示路径;它的写入速度是后者的三倍。
它们是如何测量的,以及带草稿时的速度:目前可用的功能。在另一台机器上,数字会有所不同:janas-bench测量你自己的。
试一试在 Linux x86-64(Ubuntu 22.04、Debian 12 及更高版本)上:
curl -LO https://github.com/prabanta-dev/janas/releases/latest/download/janas-linux-x86_64.tar.gz tar xf janas-linux-x86_64.tar.gz && cd janas ./janas-chat #它知道的模型:选一个,它会被下载并检查
或者在 Windows10(1903 或更高版本)和 11,x86-64 上:下载janas-windows-x86_64.zip,解压它,然后在其janas文件夹中的终端里运行.\janas-chat在同一台笔记本电脑上,Windows 11(2026 年 10 月 12 日)下,Janas-LLM 的写入速度与 Linux 上一样快(Qwen3-4B 25.6 tok/s,Qwen3-30B-A3B 34.2),并且读取提示的速度在混合模型下一样快(Qwen3-30B-A3B 132 tok/s),在稠密模型下快 1.8 倍(Qwen3-4B 346 tok/s 对 193),其整个块都通过 Intel 自己的 Windows 驱动送到 GPU。
这些模型已经转换好,来自Hugging Face;从源码构建:快速开始。
▄███████████▄
▄███████████████▄
███ ▄ █████ ▄ ███ ▄ J A N A S
███▄▄▄█████▄▄▄████
▀█████▄▀▀▀▄█████▀ ▀ a family of tools for artificial intelligence, in C
█████████████
█ █ █ █ █ █ █ █
▀ ▀ ▀ ▀ ▀ ▀ ▀ ▀
Janas 是一套用于人工智能的工具家族,用 C 编写,除 C 库外没有依赖。它的第一个组件,Janas-LLM,在普通计算机上运行大型混合专家语言模型,无论有没有 GPU:权重留在磁盘上,每个 token 需要的专家从 NVMe SSD 流式读取,反复出现的那些则留在内存中。一个 800 亿参数的模型可以在 32 GB 内存的笔记本电脑上运行并作答。
由Maurizio "camauri" Cammalleri设计和编写。
⚠️ 先读这个
这是一个实验,不是产品。
| 阶段 | 早期开发。公共 API 和命令行会不经通知而更改,并且每周都会更改数次。模型文件是例外:.jns发布在 Hugging Face 上的文件(格式版本 2)将被 Janas-LLM 的每个后续版本读取。 |
| 稳定性 | 未经验证。该引擎有意对机器要求苛刻:它用专家缓存填满空闲内存,并以全速读取磁盘,使用O_DIRECT。在余量比它估计的更少的机器上,桌面可能被推入交换空间,变得缓慢或无响应。使用 GPU 曾导致一次驱动重置,把桌面也一起带走了。 |
| 数据 | 它只写入~/.cache/janas(它了解到的关于你机器的信息,以及它已读取的系统消息,以免再次读取)以及你告诉它放置转换后模型的位置。它不会触碰它读取的模型文件。 |
| 硬件 | 开发和运行在一台机器上(见下)。在其他任何设备上均未测试:可能更慢,可能拒绝该模型,可能行为异常。 |
如果出了问题,Ctrl-C停止回复并Ctrl-D离开聊天;--cache <GiB>对其占用的内存设置硬限制,并JANAS_GPU=0使其完全远离 GPU。
它成长于的机器
本仓库中的一切都是在以下设备上编写和测量的:
- Linux Debian 13(trixie),x86-64,内核 6.12.107;GPU 驱动 Mesa 26.1.6(Vulkan);使用 GCC 14.2 构建
- Intel Core Ultra 9 185H(6 个性能核、8 个能效核、2 个低功耗核;AVX2、FMA、F16C、AVX-VNNI;集成 Arc GPU)
- 32 GBDDR5 内存
- 1 TB NVMe SSD(读取速度约 5.7 GB/s)
Windows 构建版本在同一台笔记本电脑上、Windows 11(build 26300)下运行,使用 Intel 自带的显卡驱动:其测试在那里通过,速度如何见下或在 Windows 上,见上文。
引擎所做的一切都是从它测量到的结果中选择的,所以另一台机器会做出其他选择——这部分本就是要通用的。从未尝试过的是其余部分:其他 CPU(尤其是没有 AVX-VNNI 的,或 AMD)、独立显卡、更慢的磁盘、更多或更少的内存。如果你在其他地方运行它,来自janas-bench的报告是你能发回的最有用的东西(见帮助它在更多硬件上运行)。
目前可用的功能
Janas-LLM 目前能运行的内容,按模型和功能逐项列出:docs/features.md。
在上述机器上,不运行其他任何程序,janas-bench报告如下(测量于 2026 年 10 月 10 日,使用引擎自那天起默认采用的快速提示词):
| 模型 | 读取提示词 | 撰写回复 | 带草稿,在聊天中 |
|---|---|---|---|
| Qwen3.5-2B(稠密,1.3 GB) | 395 tok/s | 50 tok/s | 67 tok/s |
| Qwen3-4B(稠密,2.5 GB) | 220 tok/s | 28 tok/s | 见--draft下文 |
| Qwen3.5-9B(稠密,5.7 GB) | 103 tok/s | 14 tok/s | 24 tok/s |
| Qwen3-30B-A3B(18.6 GB) | 133 tok/s | 34 tok/s | — |
| Qwen3.6-35B-A3B(22.3 GB) | 86 tok/s | 25 tok/s | 34 tok/s |
| Qwen3-Next-80B-A3B(48.4 GB) | 64 tok/s | 22 tok/s | 37 tok/s |
| Gemma-4-E2B-it(3.1 GB) | 211 tok/s | 38 tok/s | 52 tok/s |
| Gemma-4-E4B-it(5.0 GB) | 133 tok/s | 20 tok/s | 32 tok/s |
| Gemma-4-12B-it(稠密,7.1 GB) | 71 tok/s | 10 tok/s | 14 tok/s |
| Gemma-4-26B-A4B-it(18.3 GB) | 90 tok/s | 18 tok/s | 26 tok/s |
每个数字都是三轮的平均值, not a best round, of the configuration the engine itself chose for each kind of pass - the one a chat runs: a prompt of 256 tokens, then 64 written. Here the integrated GPU reads every prompt (the fast prompt, below), and the threads the engine settled on were the performance cores' 12 for a prompt and for a single token on nearly every model, all the usable cores (performance and efficiency, not the low-power ones) for a few tokens at once. On another machine the engine may settle on other threads: the first passes of each kind try every core, one thread per performance core and the performance cores' threads, keep the fastest, and later try the others now and then, so that a machine that warms up can change the verdict (on an i9-14900HX every thread replied at less than half the speed of the performance cores' 16). The rounds run in alternating order so that the machine warming up and the cache filling weigh on each setting alike. Expect a few per cent either way between runs, and rather less than these on a first run, while the cache is still filling. Without the GPU (JANAS_GPU=0) Qwen3-4B reads the same prompt at 85 tok/s and writes at 27.
The last column is a draft guessing the next tokens and the model checking them, which is the same text at a higher rate — the whole of it is explained under--mtp: the Qwen3.5 and Qwen3.6 models' and Qwen3-Next's own prediction block, Gemma 4's assistant (a small drafting model of its own). It is measured on a chat reply: an ordinary question in English ("explain how bread is made at home"), 64 tokens of the answer, sampled as the chat samples.What the draft is worth depends on the text: there the drafts survived 74-89% of the time on the Qwen models and Gemma's two larger ones, 63-72% on Gemma's E2B and E4B; on Italian prose Qwen3.5-2B kept about a third of them, and gained next to nothing. One round of 64 tokens is noisy here, a tenth either way between runs. Qwen3-30B-A3B has no such block, nor have the dense Qwen3; the dense Qwen3.5 have one in their original checkpoint, whichhf2jns_mtpconverts (MODELS.md).
This column was wrong until 26 September 2026,以及更高:它测量的是重复自身段落的续写块,模型会复制该块,而块几乎每次都能猜中——Qwen3.5-2B 为 107 tok/s,Qwen3.5-9B 为 26。当时的 MoE 数字(29 和 30)恰好低于今天;ChangeLog 中有详细信息。
本页顶部的与 llama.cpp 的对比是这样测量的:llama.cpp(构建版本2b184702026 年 9 月 18 日)在同一集成 GPU 上使用其 Vulkan 后端,所有内容都在其上(llama-bench -p 1024 -n 16 -ngl 99 -t 12;否则最大的模型,见下文),对比janas-bench --prompt 1024 --gen 16在同一批文件上、同样的日期(2026 年 10 月 9-11 日;llama.cpp 的最佳配置,Janas-LLM 自己的选择;10 月 11 日各跑三轮,llama-bench -r 3和janas-bench --rounds 3,针对 Qwen3-0.6B、Qwen3.5-0.8B、Qwen3.6-35B-A3B 以及其他来源的模型;Qwen3-Coder-Next 作为 Qwen3-Next-80B,见下文)。
在 Qwen3-Next-80B-A3B 上,其文件大于这台笔记本电脑的 30 GB,llama.cpp 用其常规构建在 GPU 一参与时就内存不足,即使专家留在 CPU 上(-ngl 99 -ncmoe 48):它的 CPU 后端会自行将权重复制到内存中以重新打包,而 Vulkan 后端会将那些留在 CPU 上的权重复制到系统无法回收的缓冲区中。它用一个没有重新打包的构建运行(GGML_CPU_REPACK=OFF)外加两个选项,--no-host 1 -lm mmap,这些选项将专家留在文件中,通过页缓存读取:使用 GPU 读取为 16 tok/s,仅用 CPU 写入为 2.8(使用 GPU 为 2.0);这些是它在表中的两个数字。Janas-LLM 在没有任何自身选项的情况下运行同一模型,它最常使用的专家放在约 19 GB 的缓存中,其余从磁盘读取。Janas-LLM 的数字各为一轮;写入列在两边都没有草稿。这两个工具的测量方式并不完全相同(llama-bench写入时前面没有提示;janas-bench在 1,024 个 token 之后),而且这是同一台机器。llama.cpp 自己的 CPU 后端在这台笔记本电脑上的读取表现比其 Vulkan 后端差(Qwen3-4B 在 20 线程上为 70 tok/s),写入表现则相当。
先在空闲机器上试试。专家缓存会占用模型打开时空闲的内存,模型剩余的部分在回答时从磁盘读取,因此其他所有运行的程序也分走自己的一份。它会平缓地降级而不是直接崩溃:在打开浏览器和编辑器的情况下实测,同一个模型保持了约四分之三的速度,在磁盘上等待的时间长了五倍。但你首先看到的应该是机器的真实速度,任何你打算发给别人的测量结果都必须在机器独占的情况下取得。
文档
- INSTALL.md——构建需要什么、如何准备模型,以及首次运行
- ChangeLog.md——变更内容,最新的在前
- MODELS.md——转换后模型的许可证是什么,以及哪些可以再分发
- CONTRIBUTING.md——如何提供帮助,以及签署确认
- src/services——Janas 的各项服务,每个都有自己的页面,位于
janas-chat以及其他 MCP 客户端中 - docs/features.md——Janas-LLM 目前能运行什么,按模型和功能逐项列出
- docs/models.md——获取模型:
janas-get,或转换后的 GGUF 文件 - docs/chat.md——使用
janas-chat,其来自 MCP 服务器的服务和工具 - docs/library.md——在程序中调用它,用 C 或 FreeBASIC
- docs/serving.md——将模型提供给 MCP 客户端(
janas-mcp)以及通过 HTTP(janas-server) - docs/code-completion.md——在 VSCodium 和 VS Code 中的代码补全,通过
janas-server - docs/tools.md——转换器、检查器和基准测试
- docs/hardware.md——测量你的机器,并帮助它在更多硬件上运行
- AUTHORS——谁编写了它,以及它归功于谁
- LICENSE——GNU GPL,版本 3 或更高
快速上手
sudo apt install build-essential #Debian/Ubuntu sudo apt install libvulkan-dev glslang-tools vulkan-tools #可选,GPU sudo pacman -S vulkan-headers glslang vulkan-tools #同上,Arch ./build.sh #全部放入 bin/x86_64-linux/ ./build.sh release 测试 #并运行测试
获取模型
下载一个已经用以下工具转换好的模型janas-get,或自己转换一个 GGUF 文件,以及哪些文件已被校验:docs/models.md。
使用聊天
janas-chat:其选项和命令、草稿、Janas 的服务、来自 MCP 服务器的工具、一个被逐字读取的长提示词:docs/chat.md。
填充代码
janas-server在编辑器光标处填充代码,使用诸如 Qwen3-Coder-30B-A3B 这样的代码模型:OpenAI 的/v1/completions配一个suffix,以及 llama.cpp 的/infill,这是 llama.vscode 所询问的。每次按键时发送的窗口保持不动,因此一次按键只读取它改变的内容:在笔记本电脑上生成一个建议需要 1.5-2.2 秒,而窗口滑动一行后重新读取则需要 17 秒。如何在 VSCodium 和 VS Code 中设置它,使用 llama.vscode 或 Continue,以及测量了什么:docs/code-completion.md.
从程序中调用它
从 C 和 FreeBASIC 以及 BASIC MODERN 调用该库,以及从程序中调用 MCP 服务器:docs/library.md.
Janas 作为 MCP 服务器
janas-mcp:将模型作为 Claude Code、编辑器和其他 MCP 客户端的工具:docs/serving.md.
通过 HTTP 使用它
janas-server:一个遵循 OpenAI 规范的 HTTP API,以及一个可从浏览器试用它的聊天页面:docs/serving.md.
测量你的机器
janas-bench:它测量什么,以及它留下的报告:docs/hardware.md.
工具
与程序一同构建的转换器、检查器和基准测试:docs/tools.md.
帮助它在更多硬件上运行
最需要哪些机器、尝试运行 Janas 并写出报告的那一条命令,以及要发送什么:docs/hardware.md.
致谢
Janas 由以下人员设计和编写Maurizio "camauri" Cammalleri(LinkedIn,Substack)。
它建立在其他人的工作之上,并对此予以说明:
- 模型它运行的模型属于其作者:Qwen3、Qwen3.5、Qwen3.6 和 Qwen3-Next 由阿里云 Qwen 团队开发,Gemma 4 由 Google 开发;GGUF 量化由 Qwen、bartowski 和 unsloth 完成(MODELS.md列出了所有来源)。
- llama.cpp 和 ggml是引擎所对照的参考(logits、token、速度);它们的代码没有一行在 Janas 中。从 ggml 中取用的唯一内容是定义格式的数据:IQ3_S 网格,位于
src/llm/iq3s_grid.h,依据 ggml 的 MIT 许可证。 - Unicode 字符数据库为分词器提供其表格(
tools/gen_unicode),以及OpenAI 的 OpenAPI 规范提供janas-server其路由表(tools/openapi_routes)。 - GNU libmicrohttpd、yyjson 和 Mbed TLS被编译进下面列出的程序中。
janas-flights从以下来源读取飞机位置adsb.lol(数据依据开放数据库许可证)和adsb.fi,航线来自adsbdb.com,以及使用用户密钥的时刻表来自AviationStack;其地点表格构建自OurAirports(公有领域)、GeoNames(CC BY 4.0)和Natural Earth(公有领域)。janas-quakes从以下来源读取地震INGV(Istituto Nazionale di Geofisica e Vulcanologia,CC BY 4.0)获取意大利及其海域的数据,以及来自USGS(公有领域)其他地方,以及来自Nominatim(© OpenStreetMap 贡献者,ODbL)的地点。janas-weather读取预报和海洋数据,来自Open-Meteo(CC BY 4.0)和MET Norway(CC BY 4.0),各站点的报告来自aviationweather.gov(NOAA),警报来自MeteoAlarm(EUMETNET),以及意大利的警报级别来自Dipartimento della Protezione Civile(CC BY 4.0)。若未指定地点,这些服务会询问GeoJS或ipwho.is互联网连接所在的位置。janas-maps读取OpenStreetMap的数据(© OpenStreetMap 贡献者,ODbL),通过Nominatim、Photon、Valhalla和OSRM,运行在FOSSGIS的服务器上,以及Overpass API(当Private.coffee 的实例繁忙时使用它),以及公共交通行程来自Transitous,基于运营商的开放时刻表。janas-prices读取European Central Bank(通过Frankfurter)、CoinGecko(数据由 CoinGecko 提供)和Coinbase、Alpha Vantage(使用用户的密钥)、Eurostat和World Bank(CC BY 4.0)、New York Fed、Bank of England和Swiss National Bank、energy-charts.info(Fraunhofer ISE;各区域采用 CC BY 4.0,来自 Bundesnetzagentur 的 SMARD),以及意大利的燃料价格来自MIMIT(IODL 2.0)、法国的prix-carburants、西班牙的ministry和奥地利的E-Control;地点通过Nominatim。janas-github读取GitHub的 REST API;janas-git运行git。janas-wiki读取Wikipedia,通过其 API;文本属于 Wikipedia,采用 CC BY-SA 4.0 许可,每个回答都会给出该页面的地址。- 那些在自己的机器上试用它并在本仓库的 issues 中报告所见的人:他们的报告不止一次改变了引擎(它选取的线程、提示的进度、GPU 的诊断)。
许可证
版权所有 © 2026 Maurizio "camauri" Cammalleri。
Janas 是自由软件,采用GNU General Public License,版本 3 或更高版本——见LICENSE。每个源文件都带有其 SPDX 行。
janas-server,且只有它,编译进了两个他人的库,其源代码未作改动,src/third_party/连同其许可证及来源:GNU libmicrohttpd1.0.10(LGPL 2.1 或更高版本,或此处构建方式下的无 HTTPS 的 eCos 许可证)和yyjson0.13.0(MIT)。libjanas_mcp,以及与之配套的程序,带有Mbed TLS4.2.0 及 TF-PSA-Crypto(Apache-2.0 或 GPL-2.0-or-later),用于https://MCP 服务器。libjanas_llm没有。
模型不在此许可范围内。一个转换后的.jns文件是模型的衍生品,而非 Janas 的衍生品,并保留其作者赋予的许可证;MODELS.md说明本项目会与不会重新分发哪些内容,以及在你转交转换后的模型之前需要检查什么。
贡献
CONTRIBUTING.md。简短版:来自一台这里没人拥有的机器的测量结果,比大多数补丁都更有价值,而且每次提交都需要一个Signed-off-by行(git commit -s)。