ELYZAが2026年10月2日に公開した「ELYZA-Thinking-1.0-llm-jp-4」は、国立情報学研究所LLM-jpが国内でゼロから事前学習したllm-jp-4をベースに、ELYZAがMid-trainingとPost-trainingを行った推論モデルだ。
今回面白いのは、33Bのdenseモデルと32B-A3BのMoEモデルが同時に公開されたことだ。
総パラメータ数は近いのに、推論時に使う計算量は異なる。この違いから「A3Bなら3Bモデルのように24GB GPUで余裕なのでは」と考えたくなる。
しかしMoEでは使わないexpertの重みも保持する必要がある。
ローカル実行では、計算量が軽いことと必要VRAMが小さいことを分けて考えなければならない。
ELYZAは「AIによるAI開発」を進めるELYZA RSI Researchの研究成果として、33B dense版と32B-A3B MoE版を公開した。
公式説明では、日本語の数学・コーディング・STEM推論データ、日本語の指示追従データ、日本固有知識の学習を重視している。
33B版の公式モデルカードは33B parameters、BF16と明記され、vLLMを推奨実行環境として案内する。
32B-A3B版も同様にvLLM向け手順が用意されている。
どちらもApache License 2.0で公開されており、ライセンス条件を守れば商用利用可能なオープンモデルとして提供されている。
denseモデルは推論時に基本的に全層のパラメータを使う。
一方MoEは複数のexpertからトークンごとに一部を選んで計算する。
LLM-jp公式仕様では
32B-A3Bは総パラメータ約321億
128 routed expertsのうち8 expertsを活性化し
activated parametersは約38.3億。
33B denseは総パラメータ約332億だ。
MoE版の利点は「全32Bを毎トークン計算しない」ことにある。
メモリ容量だけでなく計算効率を含めて比較する必要がある。
結論から言えば、必要メモリまで3B級になるわけではない。
A3Bはactive parametersを示す名称で、推論時に選択されるexpertが約3.8B相当という意味だ。
モデルをGPU上で高速に実行するには、通常は使われる可能性があるexpertの重みも保持する。
したがってBF16の全重みをGPUへ載せるなら、総パラメータ32B級として大きな容量が必要になる。
一方、計算されるパラメータが少ないため、ハードウェアや推論エンジンがMoEを効率的に扱えればdense 33Bより高速になる可能性がある。
ここが「容量」と「計算量」を分ける理由だ。
単純計算ではBF16は1パラメータあたり約2byteなので、33Bなら重みだけで約66GB、32Bなら約64GB規模になる。
実際にはファイル構造や埋め込み、ランタイムなどが加わる。
4bitなら理論上の重み部分は約4分の1になるが、量子化方式ごとのscaleやmetadataがあるため単純な16GB前後で完結するとは限らない。
4bitなら24GBに必ず収まる、と断定はできない。
KVキャッシュ、CUDA context、推論エンジン、OSの使用量まで含める必要がある。
RTX 4090や一部の24GB GPUで試す場合、公式BF16をそのまま全GPUへ載せる構成ではなく、量子化モデルが現実的だ。
GGUFを使うならllama.cpp系でGPUへ載せる層を調整し、足りない部分をCPU／RAMへオフロードできる。
LM StudioやOllamaも対応する量子化が提供されれば、この系統の実行環境を利用しやすい。
ただしELYZA公式モデルカードが直接推奨する中心はvLLMだ。
Hugging Faceには「Browse Quantizations」としてllama.cpp、Ollama、LM Studio等で利用できる派生量子化への導線があるが、公式BF16とコミュニティ量子化は区別したい。
24GB GPUとRAM 32GBのPCでも量子化次第で試せる構成はあるが、OSとアプリを含めると余裕は小さい。
モデルの一部をRAMへ逃がし、長いcontextを使うほどメモリ不足の可能性が上がる。
RAM 64GBならCPUオフロードの余地が大きくなる。
GPUに主要レイヤーを置き、残りをシステムRAMへ置く構成は「動かす」ためには有効だが、PCIe越しのデータ移動が増えるため全GPU常駐より速度は落ちる。
ローカルLLM用PCを新規購入するなら、VRAMだけでなくシステムRAMも見る。33B級を日常利用するなら64GB以上のRAMが扱いやすい。
llm-jp-4の33Bと32B-A3Bは65,536トークンのcontext lengthを持つ。
ELYZAの公式vLLM例でもmax-model-len 65536が示されている。
しかし「モデルが65K対応」と「24GB GPUで65Kを快適に使える」は同じではない。
生成中にはKVキャッシュが必要になり、入力と出力が長くなるほどメモリを消費する。
短いチャットで収まった4bitモデルが、巨大なコードベースや長文資料を読み込ませた瞬間にメモリ不足になることもある。
8K、16K、32Kと段階的に実測し、必要な長さを決めるのが安全だ。
公式モデルをそのままGPUサーバーで動かすならvLLMが第一候補だ。
ELYZAはreasoning parserやtool parserを含む具体的な起動コマンドを公開している。
SGLangやTransformers、Docker Model Runnerの例もある。
一般PCで量子化して使うならGGUF＋llama.cpp系が導入しやすい。
OllamaやLM StudioはGUIや簡単なコマンドで扱えるが、対象量子化がモデルのchat templateやreasoning形式を正しく保持しているか確認したい。
Apple SiliconではMLX量子化が選択肢になる。
ただしGGUFやMLXの派生版を使う際は、ELYZA公式配布か第三者変換か、変換時の設定、ライセンス表示を確認する。
GPUメモリに余裕があり、denseモデルの単純な実行特性や幅広いbackend互換性を優先するなら33B版が分かりやすい。
32B-A3Bは、MoEを効率的に扱えるvLLMなどの環境で計算効率を狙いたい人に向く。
ただしA3Bという名前だけを見て「小型GPU向け」と判断するのは避けたい。
24GB GPUの個人利用では、どちらも量子化を前提に比較し、同じprompt・contextでtokens/sec、初回応答時間、回答品質、最大VRAMを測るのが確実だ。
ELYZAは今回の2モデルを商用利用可能な形で公開したと発表しており、Hugging Face上のライセンスはApache-2.0だ。
自社サービスへ組み込む場合はApache-2.0のライセンス表示やNOTICE等の条件を確認する。
さらに第三者が作成したGGUF、AWQ、MLXなどを利用する場合は、その派生リポジトリのライセンスや変換元も確認したい。
モデルが商用利用可能でも、入力するデータの権利、生成物の利用、個人情報、社内規程は別の問題として扱う必要がある。
ELYZA-Thinking 1.0は、33B denseと32B-A3B MoEという性格の違う2モデルを選べる国産推論モデルだ。
MoE版は推論時のactive parametersが約3.8Bまで絞られるが、全重みの保存・保持まで3B級になるわけではない。
24GB GPUで試すなら、公式BF16を全GPUへ載せるのではなく4bit等の量子化やCPUオフロードが中心になる。
さらに65K contextを使うほどKVキャッシュの余白も必要だ。
サーバー運用なら公式推奨のvLLM、個人PCならGGUF系量子化という切り分けが分かりやすい。
最終的にはモデル名より、自分のprompt長と量子化条件で速度・品質・メモリを測って選びたい。
.png){kind=logo}
