NVIDIA 公式の日本語強化 LLM Nemotron 9B-v2-Japanese を色々なケースで試してみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

2026 年 2 月 17 日、NVIDIA が日本語を強化した LLM NVIDIA-Nemotron-Nano-9B-v2-Japanese を公開しました。Nejumi Leaderboard 4 の 10B 未満カテゴリで 1 位、Qwen3-8B 比で最大 6 倍のスループット、商用利用可能なライセンス。NVIDIA が「公式」で日本語強化モデルを出してきたこと自体が、ローカル LLM を業務で使いたい開発者にとって大きなニュースではないでしょうか。

https://huggingface.co/blog/nvidia/nemotron-nano-9b-v2-japanese-ja

自分はちょうど DGX Spark で Nemotron 3 Nano 4B の日本語ファインチューニングを試していたタイミングだったので、「公式がもっと良いのを出してきた」という状況に若干の切なさを覚えつつ、実機で動かして色々なケースを試してみました。

この記事では、モデルの概要紹介から DGX Spark でのセットアップ、日本語ベンチマーク、Tool Calling や RAG といった実用的なユースケースまで一通り試した結果を共有します。

Nemotron 9B-v2-Japanese とは

Nemotron Nano 9B の日本語強化版で、日本語コーパスでの追加事前学習と NVIDIA 独自の日本語対話データでのファインチューニングを経たモデルです。Nejumi Leaderboard 4 の 10B 未満カテゴリで 1 位、商用利用可能なライセンス（MAU 制限なし）、そして Tool Calling にも対応しています。アーキテクチャや学習プロセスの詳細は NVIDIA 公式の紹介記事にまとまっているので、この記事では「実際に何ができるのか」を中心に見ていきます。

この記事では DGX Spark でのセットアップと日本語ベンチマークに加えて、以下の 4 つのユースケースを実機で試しました。

DGX Spark で動かす

vLLM は動かなかった

まず公式が推奨する vLLM（v0.12.0）を試しました。モデルのダウンロードとロードは問題なく完了するのですが、推論時に Triton の PTX コード生成でエラーが発生します。

ptxas fatal   : Value 'sm_121a' is not defined for option 'gpu-name'

DGX Spark の GB10 GPU は CUDA Compute Capability 12.1（sm_121a）で、vLLM が内部で使う Triton のバージョンがこの世代に対応していません。--enforce-eager フラグで Triton のコンパイルをバイパスしても、最初の推論で同じエラーが再発しました。

Nemotron-Nano-VL-12B-V2（同じ Mamba-2 Hybrid アーキテクチャ）を vLLM で動かそうとして失敗したので、DGX Spark の Blackwell 世代と vLLM の互換性問題のようです。DGX Spark 以外の環境であれば、vLLM や TGI で動かすのが素直な選択肢になります。

GGUF に変換して Ollama で動かす

vLLM がダメなら Ollama で動かします。HuggingFace の safetensors から GGUF への変換には convert_hf_to_gguf.py を使います。

# vLLM コンテナの PyTorch 環境を GGUF 変換に流用
docker run --gpus all --entrypoint bash \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -v /tmp:/tmp --ipc=host \
    vllm/vllm-openai:v0.12.0 -c \
    "pip install -q gguf && python /tmp/llama.cpp/convert_hf_to_gguf.py \
        /root/.cache/huggingface/hub/models--nvidia--NVIDIA-Nemotron-Nano-9B-v2-Japanese/snapshots/*/ \
        --outtype bf16 --outfile /tmp/nemotron-9b-jp-bf16.gguf"

341 テンソル、17.8GB の BF16 GGUF ファイルが生成されました。DGX Spark の 128GB 統合メモリなら BF16 フル精度で余裕をもって乗るサイズです。

Ollama に登録します。

cat <<'EOF' > /tmp/Modelfile-nemotron-9b-jp
FROM /tmp/nemotron-9b-jp-bf16.gguf
PARAMETER num_ctx 4096
PARAMETER temperature 0
EOF

ollama create nemotron-9b-jp -f /tmp/Modelfile-nemotron-9b-jp

シンキングモードの制御

9B-v2-Japanese はデフォルトでシンキングモード（<think> タグ付きの思考プロセスを出力する機能）が有効です。

HuggingFace のチャットテンプレートを確認すると、enable_thinking 変数で制御されています。False のときはアシスタントの応答に空の <think></think> タグが挿入され、モデルに「考えるな」と伝える仕組みです。

Ollama ではこの制御を Modelfile のテンプレートで実現します。

# シンキング OFF（ベンチマーク評価用）
ollama create nemotron-9b-jp-nothink -f /tmp/Modelfile-9b-nothink

# シンキング ON（推論付き回答用）
ollama create nemotron-9b-jp-think -f /tmp/Modelfile-9b-think

テンプレートの中身は、チャットテンプレートの特殊トークン（<SPECIAL_10> = System、<SPECIAL_11> = User/Assistant、<SPECIAL_12> = EOS）を Go テンプレート構文で記述したものです。

TEMPLATE """{{- range .Messages }}
{{- if eq .Role "system" }}<SPECIAL_10>System
{{ .Content }}
{{ else if eq .Role "user" }}<SPECIAL_11>User
{{ .Content }}
{{ else if eq .Role "assistant" }}<SPECIAL_11>Assistant
<think></think>{{ .Content }}
<SPECIAL_12>
{{ end }}
{{- end }}<SPECIAL_11>Assistant
<think></think>"""

TEMPLATE """{{- range .Messages }}
{{- if eq .Role "system" }}<SPECIAL_10>System
{{ .Content }}
{{ else if eq .Role "user" }}<SPECIAL_11>User
{{ .Content }}
{{ else if eq .Role "assistant" }}<SPECIAL_11>Assistant
<think>
{{ .Content }}
<SPECIAL_12>
{{ end }}
{{- end }}<SPECIAL_11>Assistant
<think>
"""

どのくらいのスペックで動くか

今回は DGX Spark（128GB 統合メモリ）で BF16 フル精度のまま動かしましたが、量子化すればもっと手軽な環境でも動きます。9B パラメータなので、量子化レベルに応じたファイルサイズと必要メモリの目安は以下のとおりです。

Mamba-2 ハイブリッドアーキテクチャの恩恵で、全 56 層のうち Attention は 4 層だけです（config.json の hybrid_override_pattern で確認できます）。KV キャッシュが通常の Transformer の 56 層分ではなく 4 層分で済むため、長いコンテキストでもメモリ消費の増加が緩やかになっています。

量子化レベルの選び方としては、精度を優先するなら Q8_0（BF16 との差はほぼ体感できません）、メモリを優先するなら Q4_K_M が現実的です。Q5_K_M はその中間で、精度とメモリのバランスが良い選択肢です。

GPU 別に見ると、VRAM 12GB クラス（RTX 4060 Ti / RTX 3060）なら Q4_K_M で快適に動作します。VRAM 16GB 以上（RTX 4070 Ti Super / RTX 3090）なら Q8_0 まで実用的です。Apple Silicon の Mac であれば、ユニファイドメモリ 16GB で Q5_K_M まで、32GB なら BF16 フル精度でも問題なさそうです。

自分で GGUF 変換せずとも、HuggingFace 上にはコミュニティが公開した量子化済みモデルがあります。mmnga-o 氏のリポジトリでは日本語 imatrix を使った各種量子化が公開されており、ダウンロードして Ollama や LM Studio にそのまま読み込み試すこともできそうです。

日本語ベンチマーク（JCommonsenseQA）

評価条件

以前の Nemotron 3 Nano 4B の評価と同一条件で計測しました。

4B モデルの既存スコアとの公平な比較のため、シンキングモードは OFF に統一しています。評価スクリプトは Ollama の REST API に 3-shot プロンプトを送り、応答から選択肢（choice0-4）を正規表現で抽出する自作スクリプトを使用しました。

結果

9B-v2-Japanese は 91.2% を達成しました。自前で 1,000 件ファインチューニングした 4B モデル（88.3%）を +2.9% 上回っています。

パラメータ数が 2.5 倍あり、日本語データでプロが追加学習をしているので、この結果自体は予想どおりです。むしろ注目したいのは、4B ベースモデル（FT なし）が 87.7% を出していた点です。アクティブパラメータ 3.6B で 9B との差がたった 3.5% しかなく、Nemotron 3 Nano の MoE アーキテクチャはパラメータ効率がかなり高かったことが分かります。

平均レイテンシは 1 問あたり 0.98 秒で、1,119 問の評価が約 18 分で完了しました。BF16 フル精度（17.8GB）なので、DGX Spark の 128GB 統合メモリに十分な余裕があります。

色々なケースで試してみた

モデルの基本性能は分かったので、ここからは実務で使いそうなケースを試していきます。

Tool Calling

社内のチャットボットに「明日の天気は？」と聞いたら天気 API を叩いてくれる、「来週の予定を教えて」と言ったらカレンダー API を参照してくれる。Tool Calling はそういった「自然言語の指示から対応する API を選んで呼び出す」橋渡しを LLM に任せる仕組みです。外部関数を JSON スキーマで定義し、モデルにどの関数をどの引数で呼ぶかを判断させます。

モデルは <AVAILABLE_TOOLS> タグでツール定義を受け取り、<TOOLCALL> タグで呼び出しを返す独自のフォーマットを使います。Ollama のカスタム Modelfile ではネイティブの tools API に対応していないため、system メッセージにツール定義を埋め込む形で検証しました。

天気取得とカレンダー参照の 2 つの関数を定義し、「東京の明日の天気を教えてください」と尋ねると、get_weather を city: "東京" で正しく呼び出しました。

東京の明日の天気予報を取得するために、日付情報が必要です。
現在の日付を基準に「明日」の日付を計算します。

<TOOLCALL>[{"name": "get_weather", "arguments": {"city": "東京"}}]</TOOLCALL>

「2 月 20 日の予定を確認して、その日の大阪の天気も教えて」のように複数ツールが必要なケースでは、まず get_calendar_events を呼び出し、レスポンスを受け取ったあとに get_weather を呼ぶ順次実行パターンで対応しました。並列呼び出しではなく 1 つずつ処理するスタイルですが、結果的に両方の情報を正しく統合した回答が返ってきています。

<TOOLCALL>[{"name": "get_calendar_events", "arguments": {"date": "2026-02-20"}}]</TOOLCALL>

2026年2月20日の予定は以下の通りです：
- 10:00～11:00：チームミーティング
- 14:00～17:00：大阪出張

また、大阪の天気情報を取得するために天気APIを呼び出します。
<TOOLCALL>[{"name": "get_weather", "arguments": {"city": "大阪"}}]</TOOLCALL>

JSON の構造化出力も試しました。「田中太郎さん（35 歳、男性）は東京都渋谷区に住んでおり……」というテキストから、name / age / gender / address / company / position / email の 7 フィールドを抽出させたところ、全フィールドが正確に抽出されました。Ollama の format: "json" オプションとの組み合わせで、安定した JSON 出力が得られます。

{
  "name": "田中太郎",
  "age": 35,
  "gender": "男性",
  "address": "東京都渋谷区",
  "company": "株式会社テック",
  "position": "主任エンジニア",
  "email": "tanaka@example.com"
}

RAG（検索拡張生成）

「この社内規定だと、派遣社員はリモートワークできるんだっけ？」——こういった問い合わせに、都度人が規定を読み返して回答するのは手間がかかります。RAG はドキュメントをコンテキストとして LLM に渡し、その内容に基づいて回答させるパターンです。社内規定や製品マニュアルの QA bot として使うケースを想定して試しました。

架空のリモートワーク社内規定（対象者・利用日数・申請方法・セキュリティ要件・経費の 5 セクション、約 400 文字）をコンテキストとして渡し、3 つの質問をしました。

3 問とも正確に回答しています。特に 3 問目の「記載なし」の判定が正しく機能しているのは実用上ありがたいですね。ドキュメントに書かれていないことを「ない」と言い切れるかどうかは、RAG の信頼性に直結します。応答時間は約 10 秒でした。

1. 派遣社員は原則リモートワークできませんが、所属部門長の承認が
   あれば週2日まで利用可能です。

2. 急にリモートワークに変更したい場合は、前日17時までに上長へ
   メールで連絡する必要があります。また、勤怠システムでの事前申請は
   前月25日が締切のため、急な変更にはこのメール手続きが適用されます。

3. 記載なし

要約と翻訳

長い会議メモを 3 行にまとめたい、海外拠点に送るメールを日英翻訳したい。こうした日常的なテキスト処理をローカル LLM で完結できると、外部サービスにデータを送らずに済むのがメリットです。

生成 AI とデータガバナンスに関する日本語の文章（3 段落、約 500 文字）を「3 行で要約して」と指示したところ、GDPR や日本の個人情報保護法の共通原則、オンプレミスやリージョン指定クラウドの活用、ハイブリッド運用という 3 つの論点を正確に圧縮した要約が返ってきました。元の文章の構造を崩さず、情報の欠落もありません。

生成AIの普及で企業のデータガバナンスが重要化し、特にLLMの学習データに
おける個人情報取り扱いが課題となっている。越境データ移転を巡る各国規制
（GDPR・日本法など）は「透明性」を共通原則とし、国内データ保持のため
オンプレミスやリージョン指定クラウドの活用が進む。機密度に応じた
ハイブリッド運用が現実的なソリューションとして注目される。

日英翻訳では、個人情報の取り扱いに関するビジネス文書（「弊社では、お客様の個人情報を適切に管理するため……」）を英訳させました。"Our company processes customer personal information exclusively at our domestic data centers" のように、ビジネス文書として自然な英語になっています。「閉域ネットワーク」を "closed network environment" と訳すなど、技術用語の処理も適切です。翻訳は約 4.5 秒で完了しました。

Our company processes customer personal information exclusively at
our domestic data centers to ensure proper management. We do not
transfer any data to overseas servers, and security is maintained
through encrypted communication and a closed network environment.
If you have any questions or concerns, please contact the
Privacy Office.

コード生成

「このデータをちょっと集計したいけど、pandas の書き方を毎回調べるのが面倒」「この条件の SQL をサッと書きたい」——データ分析やレポート作成で繰り返し発生するスクリプト作成を LLM に任せるケースです。

「CSV から顧客データを読み込み、年齢層別に人数と平均購入金額を集計する Python スクリプト」を依頼しました。pandas を使った実用的なコードが生成され、pd.cut() での年齢層分類、groupby().agg() での集計、FileNotFoundError や空データのエラーハンドリングまで含まれていました。日本語コメントも自然です。ただし約 92 秒かかっており、コード量が多い場合はそれなりに待ちます。

# 顧客データから年齢層別集計を行うスクリプト
# CSVファイル: name, age, purchase_amount の形式が必要
# 出力: 年齢層ごとの人数と平均購入金額を表示

import pandas as pd

def main():
    # 1. CSVファイルのパスを指定
    file_path = 'customers.csv'

    try:
        # 2. pandasでCSVデータを読み込む
        df = pd.read_csv(file_path)

        # 3. 必要なカラムが存在するか確認（エラー防止）
        required_columns = ['name', 'age', 'purchase_amount']
        if not all(col in df.columns for col in required_columns):
            missing = [col for col in required_columns if col not in df.columns]
            raise ValueError(f"必要なカラムが不足しています: {missing}")

        # 4. 年齢が数値であることを確認
        if not pd.api.types.is_numeric_dtype(df['age']):
            raise TypeError("'age' カラムは数値型でなければなりません")

        if not pd.api.types.is_numeric_dtype(df['purchase_amount']):
            raise TypeError("'purchase_amount' カラムは数値型でなければなりません")

        # 5. 年齢層を新規カラムとして作成（20代、30代...）
        df['age_group'] = pd.cut(
            df['age'],
            bins=[0, 19, 29, 39, 49, 100],
            labels=['19歳以下', '20代', '30代', '40代', '50代以上'],
            right=False
        )

        # 6. 年齢層ごとに集計：人数と平均購入金額
        result = df.groupby('age_group').agg(
            人数=('name', 'count'),
            平均購入金額=('purchase_amount', 'mean')
        ).reset_index()

        # 7. 結果を表示（小数点第2位まで）
        print(result.to_string(
            index=False,
            float_format=lambda x: f"{x:.2f}"
        ))

    except FileNotFoundError:
        print(f"エラー: ファイル '{file_path}' が見つかりません。")
    except pd.errors.EmptyDataError:
        print("エラー: CSVファイルが空です。")
    except Exception as e:
        print(f"予期せぬエラーが発生しました: {e}")

if __name__ == "__main__":
    main()

SQL では、注文テーブルと顧客テーブルの JOIN + WHERE 条件（期間指定と会員ランク絞り込み）+ GROUP BY + ORDER BY のクエリを生成させました。

SELECT c.都道府県, SUM(o.数量 * o.単価) AS 売上合計
FROM orders o
JOIN customers c ON o.顧客ID = c.顧客ID
WHERE YEAR(o.注文日) = 2026 AND MONTH(o.注文日) = 1
  AND c.会員ランク = 'ゴールド'
GROUP BY c.都道府県
ORDER BY 売上合計 DESC;

日本語のカラム名をそのまま扱えており、クエリの論理構造も正しいです。約 34 秒で生成されました。

デプロイ選択肢の比較

Nemotron 9B-v2-Japanese を実際に業務で使うとなると、どこで動かすかが次の問題になります。ここでは 3 つの選択肢を整理します。

個人情報や機密データを扱うケースでは、データの越境移転に配慮が必要な場合があります。SageMaker の東京リージョンなら VPC 内で閉域構成を組めるため、データが日本国内から出ない構成を実現できます。Bedrock でのモデル提供は 2026 年 2 月時点では未確認なので、確実に閉域構成が必要な場合は SageMaker が現実的な選択肢です。

DGX Spark はネットワークに接続しない完全ローカル運用が可能なので、開発段階のプロトタイピングやデータの外部流出リスクをゼロにしたい検証には向いています。一方で 1 台の処理能力に限定されるため、本番のスループット要件が厳しい場合はクラウドへの移行を検討することになります。

まとめ

NVIDIA 公式の日本語強化モデル Nemotron 9B-v2-Japanese を DGX Spark で動かし、ベンチマークと実用的なケースで試してみました。

実用的なケースでの印象をまとめると、Tool Calling と JSON 構造化出力は実用レベル、RAG は「記載なし」の判定も含めて正確、要約・翻訳はビジネス文書として十分な品質でした。コード生成も pandas や SQL のスクリプトが実用的な形で出力されています。

DGX Spark では vLLM が動かないため GGUF 変換が必要ですが、BF16 フル精度で収まるサイズなので量子化の精度低下もありません。日本語ベンチマークは自前 FT した 4B モデルを上回り、テキスト処理系のタスクでは実務に投入できるレベルだと感じました。

個人的には、「自前で FT を試行錯誤したからこそ、公式モデルの凄さが分かる」という経験でした。1,000 件の FT で +0.6% を絞り出した 4B に対して、公式が +3.5% を出してくるのを見ると、やはりデータの質と量の両方が揃ったプロの仕事は強いなと感じます。

一方で、業務で使うとなると「どこで動かすか」が気になるところです。SageMaker 東京リージョンへのデプロイや、ドメイン特化のファインチューニングも試してみたいですね。

おまけ: Nemotron に自分自身の記事をレビューさせてみた

せっかくなので、この記事の要約を Nemotron 9B-v2-Japanese 自身に読ませて感想を聞いてみました。

自画自賛が過ぎる気もしますが、改善提案で「推論速度の言及が少ない」「他モデルとの比較がない」と指摘してきたのは、なかなか的を射ています。LLM が自分自身をレビューすると何を言うのか、という実験としても面白い結果でした。

参考リンク

• NVIDIA-Nemotron-Nano-9B-v2-Japanese（HuggingFace）
• Nemotron-H Technical Report（arXiv）
• NVIDIA 公式ブログ（日本語）
• Nejumi Leaderboard 4
• DGX Spark で Nemotron 3 Nano を日本語ファインチューニングしてみた
• llama.cpp（GGUF 変換）