Janas: Run LLMs larger than RAM by streaming experts from SSD
https://github.com/prabanta-dev/janas📌 32GB 筆電跑 80B 模型:Janas 用 SSD 串流打破記憶體上限
TL;DR:開源工具 Janas-LLM 把 MoE 模型的專家權重即時從 SSD 串流進記憶體,實測在同一臺筆電上全面快過 llama.cpp。
一顆 48GB 的模型,塞進一臺只有 32GB 記憶體的筆電裡跑,聽起來違反常識。但 Janas 這個以 C 語言寫成、零外部依賴的開源專案,靠著「只把當下需要的專家權重留在記憶體裡」的設計,讓這件事真的發生了。
🤔 MoE 模型的記憶體困境
Mixture-of-Experts(MoE)模型雖然每次推論只啟用一小部分參數,但完整權重仍得全部載入記憶體才能運作,這讓一般筆電望著 70B、80B 等級的模型只能興嘆。Janas 的作者 Maurizio「camauri」Cammalleri 認為,既然每個 token 只需要少數專家,那麆不如把權重留在硬碟上,只把真正用到的部分讀進記憶體,常被重複呼叫的專家才留在快取裡。
🧩 核心設計:SSD 常駐、記憶體做快取
Janas 是一個「人工智慧工具家族」的第一個元件 Janas-LLM,專門用來在一般電腦(不論有無 GPU)上運行大型 MoE 語言模型。它的做法是:模型權重留在磁碟上,每個 token 所需的專家(experts)透過 NVMe SSD 即時串流讀取,反覆被用到的專家則留在記憶體快取中。README 特別強調這是一個「實驗,不是產品」——目前處於早期開發階段,公開 API 與命令列介面每週都在變動,唯一的例外是模型檔案格式(.jns,目前為 format version 2),保證未來版本都能讀取。
📊 實測數據:同一臺筆電,全面領先 llama.cpp
作者在一臺 Debian 13、搭載 Intel Core Ultra 9 185H(含內建 Arc GPU)、32GB DDR5 記憶體、讀取速度約 5.7GB/s 的 NVMe SSD 的筆電上,對比了 Janas-LLM 與 llama.cpp 在多個模型上的表現(日期為 2026 年 10 月 9-12 日):
| 模型 | 讀取 prompt (Janas / llama.cpp) | 生成 (Janas / llama.cpp) |
|---|---|---|
| Qwen3-Next-80B-A3B(48.4GB,超過記憶體) | 62 / 16 tok/s | 24 / 2.8 tok/s |
| Qwen3-Coder-Next(48.4GB) | 66 / 14 tok/s | 22 / 2.2 tok/s |
| Qwen3.6-35B-A3B | 104 / 79 tok/s | 19 / 12 tok/s |
| Qwen3-30B-A3B | 135 / 122 tok/s | 32 / 15 tok/s |
| Qwen3.8-27B(dense) | 30.6 / 25.6 tok/s | 4.4 / 2.1 tok/s |
對於超出記憶體容量的 80B 模型,Janas-LLM 的生成速度達到 llama.cpp 的將近 9 倍。README 也坦言有個例外:3-bit 量化的 Qwen3-30B 讀取 prompt 時比 llama.cpp 慢,因為其 Q3_K 權重目前還無法送上 GPU 的快速 prompt 路徑,不過生成速度仍是對手的三倍。在 Windows 11 上測試結果與 Linux 相近,dense 模型因權重整塊送上 GPU,讀取速度甚至快了 1.8 倍。
💡 怎麼用
Linux x86-64(Ubuntu 22.04、Debian 12 以後)可直接下載執行檔解壓後執行 ./janas-chat,程式會列出已知模型供選擇、自動下載並校驗;Windows 10/11 x86-64 則下載對應 zip 解壓後執行 .\janas-chat。模型檔案皆已從 Hugging Face 轉換好,也可以從原始碼自行建置。
⚠️ 穩定性尚未驗證,使用前要有心理準備
README 明確警告:引擎刻意把機器資源用到極限,會用專家快取填滿可用記憶體,並以 O_DIRECT 全速讀取磁碟;在記憶體餘裕不足的機器上,可能把桌面環境逼進 swap 而變慢甚至無回應。作者也提到曾有一次使用 GPU 導致 driver reset,連帶讓桌面環境當掉。若要控制風險,可用 --cache <GiB> 限制記憶體用量,或用 JANAS_GPU=0 完全關閉 GPU;程式只會寫入 ~/.cache/janas,不會更動原始模型檔案。目前只在作者的那臺筆電上開發與測試過,其他 CPU(尤其缺乏 AVX-VNNI 或 AMD 平臺)、獨立顯卡、更慢的磁碟都未經驗證。
🎯 實務啟示
如果你的團隊想在邊緣裝置或個人筆電上跑超出記憶體容量的 MoE 模型做原型驗證,Janas 提供了一個值得關注的方向,但鑑於其「實驗性」定位與尚不穩定的 API,生產環境部署前務必先用 janas-bench 在自己的硬體上實測,並預留應對當機與資源耗盡的空間。
🔗 來源
- 標題:Janas: Run LLMs larger than RAM by streaming experts from SSD
- 作者/機構:Maurizio “camauri” Cammalleri(GitHub: prabanta-dev)
- 連結:https://github.com/prabanta-dev/janas
#MoE #LLMInference #EdgeAI #LlamaCpp #OpenSource #GPUComputing #NVMe #OnDeviceAI #ModelServing #QwenModels
原始資料 Hacker News · 收集於 2026-10-13
摘要原文
Janas 37 tok/s from Qwen3-Next-80B (a 48 GB model) on a laptop with 32 GB of memory, 24 without drafts, where llama.cpp manages 2.8; reading a prompt, 62 tok/s against 16. Janas-LLM was faster than llama.cpp on every model compared on the same laptop (Debian 13 Linux, Intel Core Ultra 9 185H, its integrated Arc GPU, 32 GB, an NVMe SSD; 9-12 October 2026; the whole machine below ): Model reading 1,024 tokens: Janas-LLM llama.cpp writing: Janas-LLM llama.cpp Qwen3-Next-80B-A3B (48.4 GB, more than the memory) 62 tok/s 16 tok/s 24 tok/s 2.8 tok/s Qwen3-Coder-Next (48.4 GB, more than the memory) 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 Qwen3.8-27B (dense, 17.6 GB) 30.6 tok/s 25.6 tok/s 4.4 tok/s 2.1 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 The same models from other hands, in the catalog beside them: Model reading 1,024 tokens: Janas-LLM llama.cpp writing: Janas-LLM llama.cpp Qwen3-30B-A3B, bartowski's Q4_K_M (importance matrix) 131 tok/s 122 tok/s 32 tok/s 16 tok/s Qwen3-30B-A3B, unsloth's UD-Q3_K_XL (3 bits) 100 tok/s 112 tok/s 36 tok/s 11 tok/s Qwen3-4B, bartowski's Q4_K_M (importance matrix) 191 tok/s 160 tok/s 26 tok/s 18 tok/s Qwen3.8-27B: llama.cpp measured on 12 October 2026 ( llama-bench -r 2 ), Janas-LLM on 13 October ( janas-bench --prompt 1024 --gen 16 , two rounds), once its prompt went whole to the GPU in one submission: 30.6 tok/s, where it read 26.4 the day before and 18.7 before the GPU's tiles for the IQ4_XS, IQ3_S and IQ4_NL weights of unsloth's UD mix. One exception: the 3-bit Qwen3-30B reads a prompt slower than llama.cpp, since its Q3_K weights do not go to the GPU's fast prompt yet; it writes three times as fast. How they were measured, and the speeds with the drafts: What works now . On another machine the figures will be other ones: janas-bench measures yours. Try it on Linux x86-64 (Ubuntu 22.04, Debian 12 and later): 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 # the models it knows: pick one, it is downloaded and checked Or on Windows 10 (1903 or later) and 11, x86-64: download janas-windows-x86_64.zip , unpack it, and in a terminal in its janas folder run .\janas-chat . On the same laptop under Windows 11 (12 October 2026) Janas-LLM wrote as fast as on Linux (Qwen3-4B 25.6 tok/s, Qwen3-30B-A3B 34.2) and read a prompt as fast with the mixture (Qwen3-30B-A3B 132 tok/s) and 1.8 times as fast with the dense model (Qwen3-4B 346 tok/s against 193), whose whole blocks go to the GPU, through Intel's own Windows driver there. The models come already converted from Hugging Face ; building from the sources: Getting started . ▄███████████▄ ▄███████████████▄ ███ ▄ █████ ▄ ███ ▄ J A N A S ███▄▄▄█████▄▄▄████ ▀█████▄▀▀▀▄█████▀ ▀ a family of tools for artificial intelligence, in C █████████████ █ █ █ █ █ █ █ █ ▀ ▀ ▀ ▀ ▀ ▀ ▀ ▀ Janas is a family of tools for artificial intelligence, written in C with no dependencies beyond the C library. Its first component, Janas-LLM , runs large mixture-of-experts language models on ordinary computers, with or without a GPU: the weights stay on disk, the experts each token needs are streamed from an NVMe SSD, and the ones that keep coming back stay in memory. An 80-billion parameter model runs, and answers, on a laptop with 32 GB of RAM. Designed and written by Maurizio "camauri" Cammalleri . ⚠️ Read this first This is an experiment, not a product. Stage Early development. The public API and the command line change without notice , and have changed several times a week. The models' files are the exception: the .jns files published on Hugging Face (format version 2) will be read by every later version of Janas-LLM. Stability Not verified. The engine is deliberately hard on the machine: it fills the free memory with its expert cache and reads the disk at full speed with O_DIRECT . On a machine with less headroom than it reckons, the desktop can be pushed into swap and become slow or unresponsive. Using a GPU has, once, caused a driver reset that took the desktop with it. Data It writes only in ~/.cache/janas (what it learns about your machine, and the system messages it has read, so as not to read them again) and where you tell it to put a converted model. It does not touch the model files it reads. Hardware Developed and run on one machine (below). On anything else it is untested: it may be slower, it may refuse the model, it may misbehave. If something goes wrong, Ctrl-C stops a reply and Ctrl-D leaves the chat; --cache <GiB> puts a hard limit on the memory it takes, and JANAS_GPU=0 keeps it off the GPU entirely. The machine it grew on Everything in this repository was written and measured on: Linux Debian 13 (trixie), x86-64, kernel 6.12.107; GPU driver Mesa 26.1.6 (Vulkan); built with GCC 14.2 Intel Core Ultra 9 185H (6 performance cores, 8 efficiency, 2 low-power; AVX2, FMA, F16C, AVX-VNNI; integrated Arc GPU) 32 GB of DDR5 RAM 1 TB NVMe SSD (about 5.7 GB/s reading) The Windows build was run on the same laptop under Windows 11 (build 26300), with Intel's own graphics driver: its tests pass there, and how fast it was is under Or on Windows , above. Everything the engine does is chosen from what it measures, so another machine will make other choices — that part is meant to travel. What has never been tried is the rest: other CPUs (especially without AVX-VNNI, or AMD), discrete GPUs, slower disks, more or less memory. If you run it somewhere else, the report from janas-bench is the single most useful thing you can send back (see Helping it run on more hardware ). What works now What Janas-LLM runs today, model by model and feature by feature: docs/features.md . On the machine above, with nothing else running, janas-bench reports this (measured on 10 October 2026, with the fast prompt the engine uses by default since that day): Model reading a prompt writing a reply with drafts, in a chat Qwen3.5-2B (dense, 1.3 GB) 395 tok/s 50 tok/s 67 tok/s Qwen3-4B (dense, 2.5 GB) 220 tok/s 28 tok/s see --draft below Qwen3.5-9B (dense, 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 (dense, 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 Every figure is the mean of three rounds , 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). (211 points, 84 comments on Hacker News)
由 claude-code/sonnet 自動生成