Janasは32GBのPCで80BのMoEを動かせるのか？

メモリ32GBのPCに、48GBあるQwen3-Next-80Bはそのままでは載りません。Janasは、MoEモデルの重みをSSDに置いたまま、トークンごとに要るエキスパートだけを読み出すC製の推論エンジンで、作者の計測ではメモリ32GBのノートPCで80Bモデルが毎秒24トークンを書いています。動く条件と、この数字をどこまで信じていいかを、READMEとビルドの記録から整理します。

Janasは32GBのPCで80BのMoEを動かせるのか？

答えは「x86-64のPCとNVMe SSDがあれば、作者の1台では動いている」です。計測機は Intel Core Ultra 9 185H、メモリ32GB（DDR5）、内蔵Arc GPU、1TBのNVMe SSD（読み約5.7GB/s）、Debian 13のノートPC。この上で48.4GBのQwen3-Next-80B-A3Bが、プロンプトの読み62 tok/s、書き24 tok/sで動いたとREADMEにあります。

一方で作者は、それ以外の機械は未検証だと明記しています。遅いかもしれない、モデルを受け付けないかもしれない、とまで書いてあるので、数字は「この1台ではこうだった」として読むのがちょうどいい距離感です。

Macがメインの人は、ここで1回止まってください。配布バイナリは janas-linux-x86_64.tar.gz と janas-windows-x86_64.zip だけで、Apple Siliconは公式の対象に入っていません。

GitHub - prabanta-dev/janas: 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.

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 y...

github.com

MoEだからSSDから読める、Janasの仕組み

MoE（Mixture of Experts）は、モデルの中に「エキスパート」と呼ぶ部品がたくさんあり、1トークンごとにその一部だけを使う構造です。Qwen3-Next-80B-A3Bの「A3B」は、80Bのうち1トークンで動くのが約3B分という意味。そのトークンに要る分さえ手元にあれば、計算は進みます。

Janasはここを突いて、重みはディスクに置いたまま、要るエキスパートだけをNVMe SSDから読みます。冷蔵庫（メモリ）に入りきらない食材をパントリー（SSD）に置き、よく使う食材だけ冷蔵庫に移しておくイメージです。READMEの80Bの計測では、オプションなしで約19GBのキャッシュによく使うエキスパートを持ち、残りはディスクから読んでいます。キャッシュの大きさは --cache <GiB> で変えられます。

モデルは独自形式の .jns に変換して使います。量子化をやり直すわけではなく同じ数値の並べ替えで、一緒に呼ばれやすいエキスパートを近くに置き、SSDの読み込みがまとまるようにしているそうです。ファイルの並び順だけで速度を稼ぐ発想、個人的にはここが一番面白いです。変換済みのモデルはHugging Faceで配られています。

自分のPCで動くか、判定はこの表で

最初に見るのはCPUです。手元のPC、x86-64ですか？Linuxなら grep -o -m1 avx2 /proc/cpuinfo で avx2 と出れば、速度の前提は満たしています。

次がSSD。Janasは生成中もエキスパートをSSDから読み続けるので、公式はNVMe SSDを前提にしています。SATAのSSDや外付けドライブで同じ数字が出る保証はありません。

arm64のコンテナでビルドすると、43秒で止まりました

Apple SiliconのMac上で、arm64のLinuxコンテナ（gcc:14）にリポジトリ（10月14日のコミット afb874e）をcloneし、./build.sh を走らせました。結果は43秒でエラー終了です。

src/llm/attention.c:661:23: error: unused variable 'pf' [-Werror=unused-variable]
cc1: all warnings being treated as errors

ビルドは -Wall -Wextra -Werror で、警告を全部エラーとして扱います。-Werror を外そうと build.sh を sed で書き換えたら、別の行まで巻き込んでスクリプト自体が構文エラーになり、そこで打ち切りました。

INSTALL.mdが対象にしているのはx86-64だけで、arm64でのビルドは公式が想定していない組み合わせです。Macで触りたいなら、ビルドをいじるよりx86-64のLinuxかWindows機を1台用意するほうが早いです。

READMEの24と2.8、2つの書き込み速度の読み方

READMEの先頭で目に入る「37 tok/s」は、ドラフト（次のトークンを先に予想して、本体が検算する推測生成）ありの値です。ドラフトなしの書きは24 tok/s、プロンプト1,024トークンを読む速さは62 tok/s。僕が10月16日に読んだ版（10月14日のコミット）の値で、READMEは頻繁に更新されているので、引用するなら日付を添えたほうが安全です。

「じゃあllama.cppの2.8 tok/sは、雑な設定で測った値なの？」って思いますよね。作者の説明では、llama.cpp（2026年9月18日のビルド 2b18470、Vulkan）はGPUを使った時点でメモリ不足になり、エキスパートをCPU側に残す -ngl 99 -ncmoe 48 でも同じでした。そこで重みの再配置を切ったビルド（GGML_CPU_REPACK=OFF）に --no-host 1 -lm mmap を足し、エキスパートをファイルに置いたままページキャッシュ経由で読ませています。この構成で読み16 tok/s（GPUあり）、書き2.8 tok/s（CPUのみ。GPUありは2.0）です。

つまり比べているのは「メモリに載らない80Bを、llama.cppで何とか動かした構成」と「SSDから読む前提で作られたJanas」です。llama.cpp側の設定を詰めれば差が縮むのかは、このREADMEだけでは判断できません。

作者自身が書いている留保も3つあります。

• 計測は作者の1台だけで、2026年10月9〜12日、3ラウンドの平均
• llama-bench はプロンプトなしで書き、janas-bench は1,024トークンを読んだあとに書くので、測り方が完全には同じでない
• 3bitのQwen3-30B-A3B（unslothのUD-Q3_K_XL）は、読みがllama.cppより遅い（100対112 tok/s）

それでも、メモリに載らないモデルで書きの速さが8倍以上というのはインパクトがあります。自分の機械でどうなるかは janas-bench で測れます。

入れる前に知っておきたいJanasの注意点

READMEは自らを「製品ではなく実験」と呼び、公開APIは予告なく変わる、実際に週に何度も変わってきた、と書いています。仕事の道具に組み込むには、まだ早い段階です。

体感に響きそうなのがメモリの使い方。Janasは空いているメモリをエキスパートのキャッシュで埋め、O_DIRECT でディスクを全速で読みます。ブラウザやIDEを開いたままだと、ほかのアプリが重くなるかもしれません。最初はほかの作業をしていない時間に走らせるのが無難です。

ライセンスはGPL-3.0以降。変換した .jns はJanasではなく元のモデルの派生物という扱いで、モデル側のライセンスを引き継ぎます。

開発環境につなぐ口もあります。janas-server はOpenAI互換のHTTP APIとブラウザのチャット画面を持ち、VS CodeやVSCodiumのコード補完（llama.vscodeかContinue経由）にも使えます。janas-mcp は、モデルをClaude CodeなどのMCPクライアントからツールとして呼べるようにするものです。SSDに置いた大きなモデルをエディタの補完に回せるなら、これはかなりアツいです。

Janasを動かす手順と、試す価値がある人

Linux x86-64なら、リリース版を展開するだけです。

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

Windows 10（1903以降）と11は、janas-windows-x86_64.zip を展開し、janas フォルダのターミナルで .\janas-chat を実行します。janas-chat は対応モデルの一覧を出し、選んだモデルのダウンロードとチェックまで進めます。80Bは48.4GBあるので、SSDの空きは足りていますか？先に確かめておきましょう。

ソースからビルドするなら罠が1つあります。シェーダーのビルドにはglslang 15.2以降が要り、Ubuntu 24.04の glslang-tools は15.1で古いため、GPUなしのビルドになるとINSTALL.mdにあります。ビルド後は bin/x86_64-linux/janas-bench qwen3-next-80b-a3b で、自分の機械の数字が janas-bench-<日付>.txt に出ます。

試す価値があるのは、x86-64でNVMe SSDとメモリ32GBのPCを持っていて、大きなMoEをllama.cppで動かすのを諦めていた人です。Apple SiliconのMacがメインの人や、仕事で安定して使いたい人は、今はllama.cppのままでいいと思います。

32GBで80Bは、いまのところ「作者の1台では動いた」段階です。条件に当てはまるPCがあるなら、janas-bench を回してREADMEの数字と並べてみるのが次の一手です。