数兆パラメータの時代に、無料GPU環境で3Bモデルを動かしたら想像以上だった
2026年に入っても、LLMの巨大化は加速し続けています。
GPT-5は推定数兆パラメータ(MoEアーキテクチャ、公式非公開)。Llama 4 Behemothは約2兆、Kimi K2.5は1兆。GLM-5 Reasoningがオープンソースランキング首位を取り、DeepSeek V3.2(671B)がMITライセンスで公開されるなど、大規模モデルの競争は激しさを増しています。
これらをローカルで動かすにはH100やH200が複数枚必要です。APIであれば月$20程度のサブスクリプションで利用できるサービスもありますが、トークン数や利用回数の制限があり、大量のリクエストを処理する場合は従量課金でコストが膨らみます。また、データをクラウドに送信できないケースでは、そもそもAPIという選択肢自体が使えません。
ところが最近、たった3Bパラメータでこれらの巨大モデルに肉薄するモデルが登場しました。本記事では、無料のKaggle環境を使ってその実力を検証した結果をご紹介します。
Nanbeige4.1-3Bの概要
Nanbeige4.1-3B は、中国のAIラボNanbeigeが開発した3B(実質4B)パラメータの汎用モデルです。Apache 2.0ライセンスで公開されており、商用利用を含めて自由に利用できます。
注目すべきは、パラメータ数が約10倍のQwen3-32Bを主要ベンチマークで上回っている点です。
| ベンチマーク | Nanbeige4.1-3B | Qwen3-32B | 備考 |
|---|---|---|---|
| コーディング(LiveCodeBench-Pro Easy) | 81.4 | 42.3 | 約2倍のスコア |
| 数学(AIME 2026 I) | 87.4 | 75.8 | |
| 科学(GPQA) | 83.8 | 68.4 | |
| 会話品質(Arena-Hard-v2) | 73.2 | 56.0 |
加えて、500回以上のツール呼び出しを伴うDeep Search(自律的なWeb調査)にも対応しています。推論・コード生成・会話・エージェント行動を1つのモデルで実行できる、小型モデルとしては異例の汎用性を備えています。
ローカルAIの実務的価値
巨大モデルの性能は確かに魅力的ですが、実務では別の観点が重要になる場面があります。
プライバシー
主要なAPIサービスでは、有料プランやエンタープライズ契約であればデータが学習に使用されない保証があります。ただし、社内のセキュリティポリシー上、機密データの外部送信自体が許可されないケースも依然として存在します。ローカル実行であれば、データが外部に一切出ないため、こうした制約をクリアできます。
コスト
サブスクリプションプランでは月額$20程度から利用できるものもありますが、利用回数やトークン数に上限があり、上限に達すると追加課金やプランのアップグレードが必要になります。API従量課金の場合も、日常的にコード生成や文書要約を大量に処理すると月額数千〜数万円規模に膨らむことがあります。ローカルモデルであれば、こうした制限なく、実行環境のコスト(電気代やGPUレンタル)のみで運用できます。
カスタマイズ
自社データによるファインチューニングや、ガードレールの調整など、業務要件に合わせた柔軟なチューニングが可能です。
2026年1月時点で、オープンソースLLMとプロプライエタリモデルの品質インデックスの差はわずか5ポイントまで縮小しています(2025年初頭は12ポイント差)。「オープンソース=性能が劣る」という認識は、すでに過去のものになりつつあります。
Kaggle環境での検証
実行環境
- Kaggle Notebooks(無料枠)
- GPU:NVIDIA T4 × 2(週30時間まで無料利用可能)
- 特別な申請やクレジットカード登録は不要
セットアップ
今回は4bit量子化(NF4)を使用しました。必要なコードは以下の通りです。
!pip install -q transformers accelerate sentencepiece protobuf bitsandbytes
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig, TextStreamer
MODEL_NAME = "Nanbeige/Nanbeige4.1-3B"
# 4bit量子化の設定
quantization_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_compute_dtype=torch.bfloat16,
bnb_4bit_quant_type="nf4",
)
tokenizer = AutoTokenizer.from_pretrained(
MODEL_NAME, use_fast=False, trust_remote_code=True
)
model = AutoModelForCausalLM.from_pretrained(
MODEL_NAME,
quantization_config=quantization_config,
device_map="auto",
trust_remote_code=True
)
# ストリーミング表示用(思考過程がリアルタイムに流れます)
streamer = TextStreamer(tokenizer, skip_special_tokens=True)
Dockerや仮想環境の構築は不要で、上記のコードだけで推論環境が整います。モデルのダウンロードに数分かかりますが、セットアップ全体は5〜10分程度です。
推論用のヘルパー関数も定義しておきます。
def generate(messages, max_new_tokens=16384, temperature=0.6, top_p=0.95, stream=True):
prompt = tokenizer.apply_chat_template(
messages, add_generation_prompt=True, tokenize=False
)
input_ids = tokenizer(
prompt, add_special_tokens=False, return_tensors="pt"
).input_ids.to("cuda:0")
with torch.no_grad():
output_ids = model.generate(
input_ids,
max_new_tokens=max_new_tokens,
temperature=temperature,
top_p=top_p,
eos_token_id=166101,
do_sample=True,
streamer=streamer if stream else None,
)
return tokenizer.decode(
output_ids[0][len(input_ids[0]):], skip_special_tokens=True
)
max_new_tokens=16384 と大きめに設定しているのは、このモデルが <think> タグ内で長い思考過程を展開するためです。デフォルトの2048では思考途中で出力が切れてしまいます。
VRAM使用量
nvidia-smi の結果です。
+------------------------------------------+------------------------+
| GPU Name Persistence-M | Memory-Usage |
+==========================================+========================+
| 0 Tesla T4 Off | 1623MiB / 15360MiB |
| 1 Tesla T4 Off | 2853MiB / 15360MiB |
+------------------------------------------+------------------------+
GPU 0: 1.0GB / 14.6GB 使用中
GPU 1: 2.3GB / 14.6GB 使用中
4bit量子化により、合計約3.3GBで動作しています。T4の16GB VRAMに対して大幅な余裕があります。フル精度(BF16)でも約7.9GBのため、量子化なしでもT4 1枚に十分収まります。
検証①:日本語での質問応答
messages = [
{"role": "user", "content": "量子コンピュータについて、中学生にもわかるように説明してください。"}
]
response = generate(messages)
Nanbeige4.1-3Bは推論・コード生成・エージェント行動を兼ね備えた汎用モデルですが、DeepSeek R1やOpenAI o1と同様に <think> タグ内で思考過程を展開してから回答を生成する仕組みを持っています。
思考過程では「中学生に親しみやすく説明する」「比喩を使う」「専門用語を避ける」と自ら方針を立てたうえで、以下のような回答を出力しました(抜粋)。
通常のコンピュータ → ビット(0または1)で情報を処理します。問題を解くには、順に、1つ1つのパスを走る必要があります。
量子コンピュータ → 量子ビット(量子)を使います。0と1のどこまでも重なっている(重ね合わせ)状態!問題を解くには、同時に無数のパスを走る力があります!
表やイメージを交えた構造的な回答で、3Bモデルの出力としては十分な品質です。
ただし、日本語の自然さには課題も見られます。「ビッグボックスのイメージ」「スイープ中のコイン」など、不自然な訳語が散見されました。中国語・英語をベースとしたモデルであるため、日本語品質ではClaudeやGPT-5に及ばない部分があります。
検証②:コード生成
messages = [
{"role": "user", "content": """Pythonで以下の要件を満たすスクリプトを書いてください:
1. 以下の売上データをpandasのDataFrameとして作成
- 月: 1月〜6月
- 売上: [120, 150, 180, 90, 200, 170](万円)
2. matplotlibで棒グラフを描画
3. 日本語のラベルを表示
4. 売上が最大の月をタイトルにハイライト表示
コードだけを出力してください。"""}
]
response = generate(messages)
思考過程で要件を1つずつ分解・整理してからコードを生成しました。出力されたコードの要点は以下の通りです。
# モデルが生成したコード(抜粋)
import pandas as pd
import matplotlib.pyplot as plt
months = ['1月', '2月', '3月', '4月', '5月', '6月']
sales_data = [120, 150, 180, 90, 200, 170]
df = pd.DataFrame({'月': months, '売上': sales_data})
fig, ax = plt.subplots(figsize=(10, 6))
ax.bar(df['月'], df['売上'], color='skyblue', edgecolor='black')
# 売上最大の月を赤色にハイライト(モデルが自発的に追加)
max_sales = df['売上'].max()
for bar in ax.patches:
if bar.get_height() == max_sales:
bar.set_facecolor('red')
このコードをKaggle上でそのまま実行したところ、修正なしで棒グラフが表示されました。売上最大の月を赤色でハイライトする処理も自発的に含まれており、要件の解釈力の高さが伺えます。
検証③:ツール呼び出し(Function Calling)
以下のようにツール定義を渡して検証しました。
tools = [
{
"type": "function",
"function": {
"name": "search_weather",
"description": "指定した都市の現在の天気情報を取得します。",
"parameters": {
"type": "dict",
"properties": {
"location": {"type": "string", "description": "都市名(例:東京、大阪)"}
},
"required": ["location"]
}
}
},
{
"type": "function",
"function": {
"name": "search_web",
"description": "Webを検索して情報を取得します。",
"parameters": {
"type": "dict",
"properties": {
"query": {"type": "string", "description": "検索クエリ"}
},
"required": ["query"]
}
}
}
]
テスト1:「東京の今の天気を教えて」
{"name": "search_weather", "arguments": {"location": "東京"}}
適切な関数名と引数がJSON形式で正確に返されました。
テスト2:「2026年の日本のAI市場規模について調べて」
{"name": "search_web", "arguments": {"query": "2026年 日本 AI市場規模 規模予測"}}
天気APIではなくWeb検索APIを正しく選択し、適切な日本語検索クエリを構成しています。思考過程でも「これは市場規模の質問であり、天気ツールは不適切。search_webを使うべき」と明確に判断していました。
3Bのモデルがツールの使い分けまでできるのは、エージェント用途を考えると実用的です。
検証④:推論能力
messages = [
{"role": "user", "content": """次の論理パズルを解いてください。
A, B, C, D の4人がレースをしました。
- AはBより先にゴールした
- CはDより後にゴールした
- BはDより後にゴールした
- AはCより後にゴールした
ゴールした順番(1位から4位)を答えてください。"""}
]
response = generate(messages)
モデルの出力(抜粋):
与えられた条件の整理
- AはBより先にゴールした → A < B
- CはDより後にゴールした → D < C
- BはDより後にゴールした → D < B
- AはCより後にゴールした → C < A
順序の連鎖(チェーン)
D < C(条件2)、C < A(条件4)、A < B(条件1)
→ D → C → A → B
最終回答として正解の D → C → A → B を導き、さらに全条件を検証する表まで作成しました。
| 条件 | 該当関係 | 該当順序 | 適合 |
|---|---|---|---|
| AはBより先 | A < B | 3 < 4 | ✅ |
| CはDより後 | D < C | 1 < 2 | ✅ |
| BはDより後 | D < B | 1 < 4 | ✅ |
| AはCより後 | C < A | 2 < 3 | ✅ |
思考過程の論理展開も明快で、3Bモデルの推論能力として十分な水準です。
生成速度の比較
参考値として、BF16(フル精度)と4bit量子化の比較を記載します。
| BF16(フル精度) | 4bit量子化(NF4) | |
|---|---|---|
| VRAM使用量 | ~7.9GB | ~3.3GB |
| 生成速度 | 23.2 tokens/sec(P100) | 11.1 tokens/sec(T4) |
GPUが異なるため(P100 vs T4)単純比較はできませんが、傾向として4bit量子化はVRAMを大幅に節約できる一方、速度はやや低下します。3BモデルはそもそもT4 1枚の16GBに余裕で収まるため、速度を優先する場合はBF16での実行を推奨します。
巨大モデルと小型モデルの使い分け
両者は二項対立ではなく、適材適所で使い分けるべきものです。
| 用途 | 巨大モデル(API) | 小型ローカル(3〜4B) |
|---|---|---|
| 複雑な長文生成・創作 | ◎ | △ |
| コーディング支援 | ◎ | ○〜◎ |
| 社内データの分析・要約 | △(機密性の懸念) | ◎ |
| コスト重視の大量処理 | △ | ◎ |
| オフライン環境 | × | ◎ |
| 最高精度が必要な場面 | ◎ | △ |
巨大モデルは最高精度が求められる場面に。小型ローカルモデルはプライバシー・コスト・カスタマイズ性が重視される場面に。目的に応じて両方を使い分けることが、2026年現在のAI活用における現実的なアプローチだと考えています。
まとめ
3Bのモデルが10倍大きいモデルのベンチマークを上回り、ツールの使い分けまでこなす。日本語対応のモデルではないため日本語の品質には少し課題がありますが、精度としては十分実用的な水準の回答が返ってきます。
Kaggleの無料枠でセットアップから推論開始まで約5分で試せますので、興味のある方はノートブックを動かしてみてください。
リンク:
Discussion