0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

IBM Granite 4.1 日本語性能を検証

0
Posted at

はじめに

2026年4月30日にIBMがリリースした Granite 4.1 は、Apache 2.0ライセンスのオープンソースLLMファミリーです。3B・8B・30B の3サイズが公開されており、特に「Long CoT なしで高性能」「FP8量子化対応」「131Kトークンコンテキスト」という特徴が注目を集めています。

本記事では、ローカルGPU環境(RTX 4070 Ti SUPER 16GB)でGranite 4.1-3Bおよび8Bを動かし、日本語タスク(要約・QA・議事録作成) における性能を検証します。

Granite 4.1 とは

項目 詳細
開発元 IBM Research
ライセンス Apache 2.0
モデルサイズ 3B / 8B / 30B
コンテキスト長 131,072 tokens
学習データ 約15兆トークン
対応言語 12言語(日本語含む)
特徴 FP8量子化、ツールコール対応、Long CoT不要

アーキテクチャの特徴

Granite 4.1 は以下の技術要素を採用した Dense Decoder-only モデルです。

  • Grouped Query Attention (GQA): 推論効率の向上
  • Rotary Position Embeddings (RoPE): 長コンテキストへの対応
  • SwiGLU 活性化関数 + RMSNorm
  • 5段階プリトレーニング戦略: フェーズ5で32K→128K→512Kのコンテキスト拡張

学習後処理では SFT(440万サンプル)と GRPO+DAPOloss による多段階 RL アライメントを実施しています。

検証環境

OS:  Windows 11
GPU: NVIDIA GeForce RTX 4070 Ti SUPER (16 GB)
CPU: AMD Ryzen 7 9700X 8-Core Processor (3.80 GHz)
Python: 3.14.4
PyTorch: 2.11.0+cu128
Transformers: 5.7.0

セットアップ

# 仮想環境作成
python -m venv .venv
.\.venv\Scripts\Activate.ps1

# PyTorch インストール(CUDA 12.8)
pip install torch --index-url https://download.pytorch.org/whl/cu128

# 依存パッケージ
pip install transformers>=4.47.0 accelerate sacrebleu rouge-score

# HF ログイン(モデルアクセスに必要)
python -c "from huggingface_hub import login; login()"

推論コード(基本)

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "ibm-granite/granite-4.1-8b-instruct"

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype=torch.float16,
    device_map="auto",
)
model.eval()

messages = [
    {"role": "system", "content": "あなたは優秀なアシスタントです。"},
    {"role": "user", "content": "大規模言語モデルとは何ですか?"}
]

input_ids = tokenizer.apply_chat_template(
    messages,
    add_generation_prompt=True,
    return_tensors="pt",
).to(model.device)

with torch.no_grad():
    output_ids = model.generate(input_ids, max_new_tokens=256, do_sample=False)

new_tokens = output_ids[0][input_ids.shape[1]:]
print(tokenizer.decode(new_tokens, skip_special_tokens=True))

VRAM使用量: 3B モデル約5.5GB、8B モデル約15.5GB(float16)

評価タスク設計

1. 要約

医療AIの現状と課題というテーマの日本語長文(約450字)をAIに生成させ、それを要約させました。

2. QA(質問応答)

事実確認・コーディングの2カテゴリで評価します。

3. 議事録生成

会議の音声書き起こしテキストを入力し、【議題】【決定事項】【アクションアイテム】【次回議題】の4セクション形式で議事録を生成させます。評価用にKPIダッシュボード新機能リリース計画というテーマで約500字のテキストをAIで生成しました。

なお今回はVRAM使用量と推論速度以外の定量評価は実施しませんでした。評価値はモデルカードに記載があるためです。

評価結果

VRAM使用量と推論速度

モデル VRAM使用量 推論速度 備考
3B (fp16) 5.5 GB 37 tok/s
8B (fp16) 12.6 GB 4.4 tok/s 一部ウェイトがCPUにオフロード
8B (NF4 4bit) 4.6 GB 25 tok/s bitsandbytes量子化

8B fp16 は16GB VRAMではギリギリ収まらず、CPUオフロードが発生して推論速度が大幅に低下しました。NF4 4bit量子化を使うと VRAM を 4.6GB に抑えつつ 25 tok/s を達成できました。

要約評価

入力文(約450字):

近年、人工知能(AI)技術の医療分野への応用が急速に進んでいる。特に深層学習を用いた画像診断支援システムは、放射線画像や病理画像の解析において医師と同等以上の精度を示すケースが報告されており、早期がん発見や希少疾患の診断支援ツールとして実用化が始まっている。

また、電子カルテや医療文献の大規模なデータを学習した大規模言語モデルは、医師の診断補助、治療法の提案、薬剤の相互作用チェックなどに活用されつつある。米国のMayo ClinicやMemorial Sloan Kettering Cancer Centerなどの著名な医療機関でも、AIを活用した診断支援システムの導入が進んでいる。

一方で、課題も多い。AIの判断根拠の説明可能性(XAI)、学習データの偏りによる公平性の問題、医療事故が発生した際の責任所在の曖昧さ、そして患者データのプライバシー保護など、技術的・倫理的・法的な課題が山積している。厚生労働省や各国の規制当局も、医療AIの承認基準の整備を急いでいるが、技術の進化速度に規制が追いついていないのが現状だ。

今後は、AIと人間の医師が協調して診断・治療を行う「Human-AI collaboration」モデルが主流になると予想されており、AIリテラシーを持つ医師の育成が急務となっている。

3B の出力(273字):

近年、人工知能(AI)は医療分野で急速に進化し、深層学習を用いた画像診断支援システムが医師と同等以上の精度を示し、早期発見や診断支援に活用されています。また、大規模言語モデルは医師の診断補助や治療法の提案に利用されており、米国の著名な医療機関でもAIシステムの導入が進んでいます。しかし、説明可能性、データの偏り、責任問題、プライバシー保護などの技術的・倫理的・法的課題が存在し、規制の整備が追いついていない状況です。今後は、AIと医師の協調「Human-AI collaboration」が主流となり、AIリテラシーの向上が求められています。

8B (NF4 4bit) の出力(262字):

近年、人工知能(AI)技術は医療分野で急速に進化し、特に深層学習を用いた画像診断支援システムが高い精度を達成し、早期がん発見や希少疾患の診断支援に実用化されています。大規模言語モデルは診断補助や治療法の提案に活用され、著名な医療機関でも導入が進んでいます。しかし、説明可能性、データの偏り、責任所在、プライバシー保護などの技術的・倫理的・法的課題があり、規制が追いついていない状況です。今後は「Human-AI collaboration」モデルが主流となり、AIリテラシーを持つ医師の育成が重要視されています。

両モデルとも論点(画像診断・LLM活用・課題・Human-AI collaboration)を的確に抽出し、原文の約半分に圧縮できています。文体や細かい表現に違いはありますが、情報の取捨選択は同水準です。

QA評価

例1: 事実確認

Q: 東京スカイツリーの高さは何メートルですか?また、完成した年はいつですか?

3B の回答:

東京スカイツリーの高さは634メートルで、完成したのは2012年です。

8B (NF4 4bit) の回答:

東京スカイツリーの高さは634メートルです。完成した年は2012年です。

シンプルな事実確認では両モデルとも正確・簡潔に回答。3B の方がやや自然な一文にまとまっています。


例2: コード生成(日本語指示)

Q: Pythonで、元の順序を保ったまま重複を除いたリストを返す関数を書いてください。

3B の回答:

def unique_elements_preserve_order(lst):
    return list(dict.fromkeys(lst))

8B (NF4 4bit) の回答:

def unique_ordered_elements(lst):
    seen = set()
    result = []
    for item in lst:
        if item not in seen:
            seen.add(item)
            result.append(item)
    return result

3B は dict.fromkeys を使った Python らしい慣用的な1行実装、8B は set を使ったより教科書的な実装を選択。どちらも正しく動作しますが、3B の簡潔さが際立ちます。

議事録生成評価

会議の録音データから書き起こしをして、そこから議事録作成をするユースケースを想定。実際はここまできれいに書き起こしできませんが、まあいいでしょう。

入力(書き起こし全文):

田中(PM): じゃあ始めましょうか。今日はダッシュボードのエクスポート機能の件ですね。鈴木さん、現状どうですか?

鈴木(エンジニア): えーと、バックエンドはほぼできてて、CSVは動いてます。PDFはまあ、あと2、3日あれば。

田中: 了解です。佐藤さんはUIどうですか?

佐藤(デザイナー): デザインカンプは出てます。ボタンの配置とかは固まってて、あとはフロントの実装ですね。鈴木さんと合わせて進める感じで。

田中: スケジュール的にはどのくらいで行けそうですか?

鈴木: バックエンド込みで実装は来週中には終わると思います。そのあとテストで1週間くらい見れば。

山田(QA): テストは私がやりますけど、モバイル対応の確認も必要ですよね?ブラウザだけじゃなくて。

田中: そうですね、モバイルも対応必須で。じゃあ、リリースは再来週の金曜、つまり2週間後を目標にしましょう。それでいいですか?

鈴木: 大丈夫です。

佐藤: はい、問題ないです。

田中: 決定で。アクションとしては、鈴木さんがPDF対応と実装完了を来週金曜まで。佐藤さんがフロント実装を同じく来週金曜。山田さんがモバイル含めたテストをその翌週でお願いします。次回は1週間後に進捗確認しましょう。以上です。

3B の出力(216字):

【議題】
- ダッシュボードのエクスポート機能の進捗とリリース計画

【決定事項】
- リリース日を再来週の金曜日(2週間後)に設定

【アクションアイテム(担当者・期限付き)】
1. 鈴木(エンジニア): PDF対応と実装完了を来週金曜まで
2. 佐藤(デザイナー): フロントエンドの実装を来週金曜まで
3. 山田(QA): モバイル含めたテストを翌週まで

【次回議題・日程(あれば)】
- 次回の進捗確認会議を1週間後に設定

8B (NF4 4bit) の出力(356字):

【議題】
ダッシュボードのエクスポート機能の実装に関する進捗確認

【決定事項】
- リリース目標日:再来週の金曜日(2週間後)
- PDF対応:来週金曜まで(鈴木さん)
- フロントエンド実装:来週金曜まで(佐藤さん)
- モバイル対応テスト:翌週(山田さん)

【アクションアイテム(担当者・期限付き)】
- 鈴木(エンジニア):PDF対応とバックエンド実装を来週金曜まで完了
- 佐藤(デザイナー):フロントエンド実装を来週金曜まで完了
- 山田(QA):モバイル含めたテストを翌週行う

【次回議題・日程(あれば)】
次回の進捗確認会議を1週間後に設定。

両モデルとも構造化フォーマットを正確に守り、担当者・期限・決定事項を漏れなく抽出。3B はコンパクトにまとめ、8B はより詳細に展開する傾向があります。なお両モデルとも「CSV」対応については議事録に明示されず、これが唯一のミスでした。

タスク別 応答時間(実測)

タスク別応答時間の実測値をまとめました。当然3Bのモデルのほうが早いです。

タスク 3B (fp16) 8B (NF4 4bit)
要約(約450字入力) 約8〜9秒 約21〜23秒
QA 短答(事実確認) 約0.9秒 約2.6秒
QA 長文(コード) 約14〜23秒 約21〜29秒
議事録(約550字書き起こし) 約11〜17秒 約16〜19秒

まとめ

結論

  • Granite 4.1-8B は16GBのコンシューマGPUで動作し、日本語要約・QA・議事録作成で十分実用的な性能を発揮
  • 今回のタスクでは8Bの優位性を活かせていないようで、3B vs 8B の差はあまり見られず
  • Apache 2.0 ライセンスのため商用利用・ファインチューニングが自由、エンタープライズ用途に適している
  • 個人利用で考えると、このレベルの性能を持つモデルがGPUさえあれば無料で動かせるのは魅力的に感じる

参考リンク


0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?