llm-jp-4-33b-thinking-exl3

llm-jp-4-33b-thinking EXL3 Quantized

LLM-jp / 国立情報学研究所が公開している llm-jp/llm-jp-4-33b-thinking をベースに EXL3 (ExLlamaV3) 形式へ量子化した非公式の派生モデルです。

本リポジトリは LLM-jp / 国立情報学研究所による公式配布物ではありません。 元モデルのライセンス、利用上の注意事項、モデル自体の評価については、必ず元モデルのModel Cardも参照してください。

Status

• EXL3 2.5 / 3.0 / 3.5 / 4.0 / 4.5 / 5.0 / 6.0 / 8.0 bpw を生成
• native ExLlamaV3 / TabbyAPI による基本動作・Harmony・multi-turn検証を実施
• qbenchによるBF16忠実度評価は完了
• MT-Bench JA/EN のcandidate生成・比較評価完了

Variants

EXL3は NVIDIA CUDA GPU向け の量子化・推論形式です。 とりあえず試す場合は、GPUのVRAM容量と「どこまで品質を優先するか」でvariantを選んでください。

迷った場合: RTX 5090 32GBならまず 4.0bpw H6、品質優先なら 5.0bpw H6 または 6.0bpw H6 を推奨します。

VRAMについて

上表は「最低動作要件」ではなく、安全側に寄せた目安です。必要VRAMはcontext length、KV cache、batch size、runtime設定によって変わります。 検証では8K context / 4-bit KV cacheを中心に確認しており、RTX 5090 32GBで6.0bpw H6まで動作確認済みです。一方、8.0bpw H8はRTX 5090 32GBでは通常ロード時にVRAM不足となりました。 4.0bpw H6も検証設定では24GBを超えるVRAMを使用したため、24GB級GPUで利用する場合はcontext/cacheの縮小が必要になる可能性があります。

Usage

EXL3 (ExLlamaV3) は、汎用的なモデル形式ではなく、NVIDIA GPU上での高速・省VRAMな推論にフォーカスした量子化形式です。 そのため、現時点では EXL3形式を llama.cpp、vLLM、Ollama などの一般的な推論エンジンで直接読み込むことはできません。 EXL3モデルの実行には ExLlamaV3 を使用できます。 OpenAI互換APIとして利用する場合は、ExLlamaV3の公式・推奨API backendでありEXL3をサポートする TabbyAPI を推奨します。

Download

先人のEXL3公開方式に倣い、1つのHugging Face repository内でbranchを分けて配布する形式です。 利用したいvariant名を --revision に指定して、そのbranchだけを取得できます。

例（4.0bpw H6）:

REPO_ID=shunmoridev/llm-jp-4-33b-thinking-exl3

hf download "$REPO_ID" \
  --revision 4.0bpw_H6 \
  --local-dir ./llm-jp-4-33b-thinking-exl3-4.0bpw_H6

利用可能なrevision名:

• 2.5bpw_H6
• 3.0bpw_H6
• 3.5bpw_H6
• 4.0bpw_H6
• 4.5bpw_H6
• 5.0bpw_H6
• 6.0bpw_H6
• 8.0bpw_H8

Quick start with TabbyAPI

TabbyAPI はExLlamaV3の公式API backendで、OpenAI互換APIとしてこのEXL3モデルを利用できます。 以下は Linux / WSL + CUDA 12.x で4.0bpw H6を起動する最小構成例です。

1. TabbyAPIを準備

git clone https://github.com/theroyallab/tabbyAPI
cd tabbyAPI

python -m venv venv
source venv/bin/activate
pip install -U '.[cu12]'

2. モデルを models/ へダウンロード

REPO_ID=shunmoridev/llm-jp-4-33b-thinking-exl3

hf download "$REPO_ID" \
  --revision 4.0bpw_H6 \
  --local-dir models/llm-jp-4-33b-thinking-exl3-4.0bpw_H6

3. config.yml を作成

network:
  host: 127.0.0.1
  port: 5000
  disable_auth: true
  api_servers: ["OAI"]

model:
  model_dir: models
  model_name: llm-jp-4-33b-thinking-exl3-4.0bpw_H6
  backend: exllamav3
  max_seq_len: 8192
  cache_size: 8192
  cache_mode: 4,4
  gpu_split_auto: true
  autosplit_reserve: [256]
  chunk_size: 2048
  output_chunking: true
  harmony: true

disable_auth: true は localhostだけで利用する場合の簡易設定です。外部ネットワークへ公開する場合は認証を有効にしてください。

harmony は現在のTabbyAPIではspecial tokenから自動判定できますが、このモデルがHarmony response formatを使用することを明示するため、上の例では true にしています。

4. 起動

python main.py

OpenAI互換APIは通常 http://127.0.0.1:5000/v1 で利用できます。

動作確認:

curl -s http://127.0.0.1:5000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "llm-jp-4-33b-thinking-exl3-4.0bpw_H6",
    "messages": [
      {"role": "user", "content": "日本の首都はどこですか？"}
    ],
    "reasoning_effort": "medium",
    "temperature": 0,
    "max_tokens": 256
  }'

正常時は、最終回答が content、thinking内容が reasoning_content として分離されたOpenAI互換レスポンスが返ります。

Thinking token budget:

複雑な推論では max_tokens=1024 ではthinkingだけで上限へ到達する場合があります。 長めの推論を行う場合は 4096 以上を目安に調整してください。 また、長いcontextを使う場合は max_seq_len / cache_size とVRAM使用量も合わせて調整してください。

Run notes

このモデルはthinking modelであり、元モデルのchat templateはOpenAI Harmony response format互換として設計されています。 元モデル付属のtokenizer / chat templateをそのまま使用し、generic tokenizerや別templateへ置き換えないことを推奨します。

検証では以下を確認しています。

• 日本語 / 英語生成
• reasoning_effort = low / medium / high
• Harmonyのreasoning / final分離
• multi-turn conversation
• special tokenの非漏洩と正常stop

詳細な利用方法は、元モデルの LLM-jp cookbook、 TabbyAPI Getting Started、ExLlamaV3のドキュメントも参照してください。

Model Details

元モデルは Llama 系の dense 33B thinking model です。

Original / Source

• Architecture: LlamaForCausalLM
• Layers: 64
• Hidden size: 5120
• Attention heads: 40
• KV heads: 8
• Context length: 65,536
• Vocabulary size: 196,608
• Original dtype: BF16
• License: Apache-2.0

Quantization variants

• Decoder: 2.5 / 3.0 / 3.5 / 4.0 / 4.5 / 5.0 / 6.0 / 8.0 bpw
• LM head: H6（2.5～6.0bpw）、H8（8.0bpw）
• Codebook: mul1
• Calibration: ExLlamaV3 default (250 x 2048)
• Output scales: always
• HQ mode: disabled

Evaluation

量子化後の品質を一つの数値だけで判断しないため、実タスク評価とBF16への内部的な忠実度評価を分けて確認しています。

MT-Bench — 実タスク評価

LLM-jp公式評価では gpt-5.4-2026-03-05 をjudgeとして使用し、3回の推論・評価結果の平均値が掲載されています。

本EXL3量子化モデルについても、同じ gpt-5.4-2026-03-05 をjudgeとして MT-Bench JA / ENを各量子化につき3回実施しました。

結果は3 runの平均値 ± 標本標準偏差です。

4.0–6.0bpwの範囲では、MT-Bench上で明確な品質差は観測されませんでした。 量子化間の差は小さく、3 run間のばらつきと同程度です。

なお、llm-jp-4-33b-thinking の値はLLM-jpが公開している公式評価値であり、 当方の環境でBF16モデルを再評価した値ではありません。

生成結果、judgeによる評価結果、runごとのscore table、および集計結果は evaluation/mt-bench/ に保存しています。

qbench — BF16への量子化忠実度

ExLlamaV3付属の qbench を使用し、量子化後の次トークン確率分布が元BF16からどの程度変化したかを測定しています。

ここで見ているのは「モデルの知能スコア」ではなく、量子化によって元モデルの出力傾向がどれだけ変わったかです。 KLD (Kullback-Leibler divergence) は小さいほどBF16に近いことを意味します。

特に4.0bpw以降で差が大きく縮まり、 6.0bpwではBF16のnoise floorにかなり近い水準まで低下しています。

qbench LLM-jp in-domain trace

日本語instruction / thinking modelに近い条件を見るため、 llm-jp/llm-jp-instructions v1.0 の公式test splitを母集団として固定traceを作成しました。

• Dataset revision: 93d6a615c1e0836668cfb682273124624b103cda
• Split: test
• Pool: 400 prompts
• Selection: SHA256(seed:ID) 昇順
• Seed: 42
• Selected rows: 8
• Input tokens: 809
• Scored response tokens: 20,816
• enable_thinking = true
• reasoning_effort = high
• Trace生成モデル: EXL3 6.0bpw H6
• Vocab size: 196,608

同一traceをBF16 referenceと全EXL3 variantへ入力し、response token位置のlogit distributionを比較しています。 traceは6.0bpw H6からself-samplingしているため、PPLには生成元への軽い自己適合バイアスがあり得ます。そのため、比較ではKLDを主指標としています。

qbench WikiText-2

in-domainだけに都合のよい結果になっていないかを確認する外部コーパスとして、qbenchのwiki2入力も使用しました。

• Dataset: wikitext/wikitext-2-raw-v1
• Rows: 10
• Length: 2048 tokens / row
• Stride: 2048
• 合計評価規模: 約20k tokens
• 同一tokenizer / 同一BF16 referenceで全variantを比較

WikiText-2でも、in-domain traceと同じ順序でbpw増加に伴うKLD改善が確認されました。

<strong>qbench 詳細結果（PPL / KLD）</strong>

全variant

KLD分布

BF16 / noise-floor reference

qbench weight footprint はqbenchがtensor storageから算出した比較用の値であり、実際の推論時ピークVRAMや配布ファイル全体のサイズではありません。KV cacheやruntime workspaceは別途必要です。

Quantization / Evaluation Environment

Source model

• Model: llm-jp/llm-jp-4-33b-thinking
• Source revision used for quantization: 9e6928628594b205bd3ccd93c2813064aa53fe97
• Source dtype: BF16

ExLlamaV3 / qbench

• ExLlamaV3: v1.4.2
• Pinned commit: 5f3c537ca9d89893d771256f5c43c93656553fbb
• Python: 3.12.3
• PyTorch: 2.9.0+cu128
• CUDA: 12.8
• GPU: NVIDIA GeForce RTX 5090 32GB
• Transformers: 4.51.0

Tokenizer

元モデルに同梱されているtokenizer資材、custom tokenizer Python、chat templateを維持しています。

特にこのモデルは独自のLLM-jp tokenizerとHarmony系special tokenを使用するため、generic tokenizerへ置き換えていません。

検証では以下のspecial tokenを含むtokenizer互換性を確認しています。

• <|start|>
• <|message|>
• <|channel|>
• <|constrain|>
• <|end|>
• <|return|>
• <|call|>

Reproducibility

評価に使用した設定・入力・出力・実行記録は、evaluation/ 以下に保存しています。

MT-Bench artifactは evaluation/mt-bench/ に保存しています。

qbench artifactは evaluation/qbench/ に保存しています。

MT-Bench

実際の生成品質については、MT-Bench JA / ENを使用しています。

• Judge: gpt-5.4-2026-03-05
• 対象: EXL3 4.0bpw H6 / 5.0bpw H6 / 6.0bpw H6
• 各variant 3 runs
• 各runのgeneration outputを保存
• 各runのjudge raw output / category score / turn score / final scoreを保存
• 3 runsの平均値・標本標準偏差を集計

生成結果と評価結果を分けて保存しているため、 既存のgeneration outputを別のjudgeで再評価することも可能です。

qbench

qbenchについては、以下のartifactを保存しています。

• qbench YAML設定
• 結果JSON
• 実行log
• 固定20k-token trace
• trace生成条件・dataset revision・選択ID
• 実行環境情報
• source / evaluation artifactのSHA256
• ExLlamaV3 qbenchに対する変更差分・適用記録

in-domain評価では、生成したtraceを固定し、BF16 referenceおよび全EXL3 variantに対して同一token列を使用しています。

これにより、variantごとに異なるprompt / responseを評価することを避け、 量子化によるlogit distributionの差を比較しています。

qbenchは元BF16に対するlogit fidelityを見る評価であり、 一般的なモデル能力ベンチマークの代替ではありません。

Risks and Limitations

本リポジトリは元モデルを量子化した非公式配布物です。量子化により元モデルと完全に同一の出力が保証されるものではありません。 また、元モデル自体のリスク・制限事項については、LLM-jp公式Model Cardの記載が優先されます。

License

元モデルは Apache License 2.0 で公開されています。本量子化モデルも元モデルのライセンス条件に従います。

詳細は元モデルのModel Cardを参照してください。

Acknowledgement / Credits

• Original model: LLM-jp / National Institute of Informatics
• Source model: llm-jp/llm-jp-4-33b-thinking
• Official GGUF reference: llm-jp/llm-jp-4-33b-thinking-gguf
• Quantization / runtime: ExLlamaV3
• API runtime validation: TabbyAPI
• Evaluation: ExLlamaV3 qbench, llm-jp-judge