Nanbeige4.3-33B 必要スペック早見表

Nanbeige4.3-33B は、Nanbeige LLM Lab が公開した総33.1B・全パラメータ稼働の密（dense）なオープンウェイトモデルで、4bit量子化（Q4_K_M）のファイルサイズは約20.8GB。RTX 3090・4090（24GB）に短めの文脈で載せられ、BF16の原本は約66GBで80GB級のGPUか96GB以上のMacが必要になる。 コンテキストは最大524,288トークン（512K）まで対応するが、KVキャッシュの分だけメモリが増えるため、長い文脈を使うなら余裕を見込む必要がある。

2026年10月下旬にHugging Faceで公開され、ライセンスはApache 2.0（商用利用可）。コーディングと、オフィス業務・エージェント作業（cowork）に強い約30Bクラスのモデルとして位置づけられている。本記事では、公開されているモデル構成とbartowskiのGGUFファイルサイズから必要スペックを整理する。ベンチマークは開発元の公表値で、独立した検証はまだ少ない（2026年10月26日時点）。

手元のGPU・Macで動くかをすぐ確かめたい場合は、モデル・量子化・コンテキスト長を選ぶだけで必要VRAMを試算できるVRAM計算ツール（無料・登録不要）も用意している。Nanbeige4.3-33Bもモデル一覧から選択できる。

ファイルサイズはbartowskiのGGUFの値。「必要メモリの目安」はファイルサイズにKVキャッシュ（8K文脈で約1.6GiB）と実行時の作業領域を加えた推定で、実測ではない。文脈を長くするほど増えるため、下限に近い目安として扱ってほしい。

Nanbeige4.3シリーズのフラッグシップ（教師）モデルで、ベースモデルのNanbeige4.3-33B-Baseも同時に公開されている。従来は3Bクラスの Nanbeige4.1-3B・4.2-3B（ループ型トランスフォーマーのエージェントモデル）が中心で、今回は33Bまで拡大した形になる。MoEではなく密なモデルなので、1トークンごとに全パラメータを使う。同じファイルサイズのMoEより生成は遅くなりやすい点は覚えておきたい。

パラメータ数は構成値からの計算で約33.1B。GQAでKVヘッドが8に絞られているため、33B級の密モデルとしてはKVキャッシュが軽い部類に入る。

KVキャッシュは構成値から計算できる。FP16で 2（K・V）×52層×8ヘッド×128次元×2バイト＝212,992バイトで、1トークンあたり約0.2MiB。以下は推定値で、実装による上乗せがある。KVキャッシュをq8_0にすると概ね半分になる。

Q4_K_M（20.8GB）に32KのFP16 KVキャッシュを足すと約27GBになり、24GBのGPUには載らない。24GBカードなら8〜16K程度に抑えるか、IQ4_XSとq8_0 KVキャッシュを組み合わせるのが現実的。512K全体を使う用途は、重みと合わせて100GB台後半が必要になる。KVキャッシュの仕組みはKVキャッシュとコンテキスト長のVRAM解説で詳しく扱っている。

以下は上記のファイルサイズとKVキャッシュからの推定による目安で、実測ではない。

密な33Bは、同じファイルサイズのMoEより1トークンあたりの計算が重い。本記事では生成速度の数値を示していない（実測の裏付けがないため）。Mac向けにはMLX 4bit版も公開から1日以内に出ている。

以下は開発元が公表した値で、第三者による再現はまだ少ない。比較対象はQwen3.8-27B、Muse-Glimmer-30B、Gemma4-31B。

ターミナル操作やツール利用などエージェント系の指標で上回る一方、SWE-Bench ProとGDPvalはQwen3.8-27Bが、GPQA DiamondはGemma4-31Bが上になっている。比較モデルの必要スペックは、Qwen3.8-27B、Muse-Glimmer-30B、Gemma 4の各記事を参照してほしい。

GGUF版はllama.cppのb11845以降が必要。古いビルドでは読み込めない可能性がある。llama.cppでは、Hugging Faceから直接取得して起動できる。

Ollamaでは、hf.co のGGUFを指定して実行する。

公式の推論例はTransformers、SGLang、vLLMで、vLLMの例ではテンソル並列4・gpu-memory-utilization 0.8が使われている。BF16と長い文脈を前提に4枚のGPUを想定したレシピと読める。LM StudioとDocker Model Runnerでも動く。

推奨設定は次のとおり。

- 思考モード: enable_thinking は既定でオン。非思考にしたい場合はFalseにする
- preserve_thinking: 通常のチャットはFalse、複数ターンのツール利用・エージェント・オフィス作業ではTrueを推奨
- ツール呼び出し: tool_call_format="xml" を推奨（jsonも可）
- エージェント・ツール利用: temperature 1.0、top_p 0.95、max_new_tokens 65,536
- 推論・チャット: temperature 0.6、top_p 0.95、max_new_tokens 262,144

迷ったらQ4_K_M（20.79GB）が出発点になる。24GBのGPUで文脈を稼ぎたいならIQ4_XS（18.64GB）、32GBのGPUや48GBのMacで品質を優先するならQ5_K_M（25.07GB）かQ6_K（29.02GB）。Q3以下は容量の逼迫を逃れる手段で、思考の長いエージェント用途では精度低下の影響が出やすい。量子化の種類ごとの違いはGGUF量子化ガイドに、実行ツールの選び方はOllamaとLM Studioの比較にまとめている。

FP8、NVFP4、EXL3、AutoRound W4A16などのコミュニティ量子化も公開から1日以内に多数出ている（派生リポジトリは約89件）。ただし品質は配布者ごとに異なるため、最初は公式の評価に近いBF16と、広く使われているGGUFから試すのが安全。

- メモリ不足（OOM）: コンテキスト長を下げる、KVキャッシュをq8_0にする、一段小さい量子化にする、の順に試す。GPUに載り切らない分は -ngl を下げてCPUへ逃がせるが速度は落ちる
- モデルが読み込めない: llama.cppがb11845より古い可能性が高い。最新版に更新する
- 思考が長すぎる: enable_thinking=False で非思考にするか、max_new_tokens を制限する。推論用の262,144は上限が非常に大きい
- ツール呼び出しが安定しない: tool_call_format="xml" を使い、エージェント用途ではtemperature 1.0・top_p 0.95、preserve_thinking=True に揃える
- 複数ターンで文脈が崩れる: preserve_thinking の設定を用途に合わせる（チャットはFalse、エージェントはTrue）