Go to Qiita Advent Calendar Top
LoginSignup
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@koshikawa-masato(越川 将人)

OpenAIのgpt-oss-120bをOllamaで試してみた

Last updated at Posted at 2025-11-10

はじめに

OpenAIが2025年8月にオープンウェイトモデル「gpt-oss」をリリースしました。今回は120Bパラメータ版の gpt-oss:120b をOllamaで実際に試してみて比較してのレポートをします。

gpt-oss-120bの特徴

基本スペック

  • パラメータ数: 117B（実際のアクティブは5.1B/トークン）
  • アーキテクチャ: Mixture-of-Experts (MoE)
  • モデルサイズ: 65GB（ダウンロードサイズ）
  • ライセンス: Apache 2.0（商用利用可能）

メモリ要件:

  • GPU実行: 80GB VRAM推奨（H100, MI300X など）
    • MXFP4量子化で約61GB使用
  • CPU実行: 64GB〜256GB システムRAM
    • 推奨: 128GB以上
    • 最低: 64GB（パフォーマンストレードオフあり）

実行環境について:

  • GPU実行: データセンター級GPU（H100, A100）またはワークステーション向けGPU（Blackwell RTX 6000）推奨
  • CPU実行: 可能だが推論速度が遅い（実用性は用途による）
  • 今回のテスト環境: WSL2 Ubuntu 24.04（CPUモード、システムRAM使用）

際立った特徴

  1. 推論過程の可視化

    • Chain-of-Thoughtによる思考プロセスが見える
    • デバッグやトラストが容易

  2. 推論レベルの調整

    • low / medium / high の3段階
    • システムメッセージで簡単に設定可能

  3. エージェント機能

    • 関数呼び出し
    • Web検索（Ollamaが対応予定）
    • Python実行
    • 構造化出力

Ollamaで試してみた

インストール

ollama pull gpt-oss:120b

ダウンロードサイズは約65GB。10GbE環境で約6分でダウンロード完了しました。

実際に使ってみた

自作のAI VTuberチャットシステム「コピーロボット」で、キャラクター「牡丹」との会話に使ってみました。

gpt-oss-120bでの会話例

思考プロセスのフィルタリング

gpt-oss-120bは以下の形式で出力します：

Thinking...
[内部思考プロセス]
...done thinking.

[実際の応答]

この「Thinking...」部分は開発には有用ですが、エンドユーザーには不要なので、以下のようにフィルタリングしました：

# 出力から思考部分を除去
if response.startswith('Thinking...'):
    thinking_end = response.find('...done thinking.')
    if thinking_end != -1:
        response = response[thinking_end + len('...done thinking.'):].strip()

応答速度

  • 環境: WSL2 Ubuntu 24.04（NVIDIA RTX 4060 Ti 16GB + CPU）
  • 応答時間: 12〜46秒/応答
  • 推論速度: 約8.5 tokens/s（ハイブリッドモード）

120Bモデルとしては妥当な速度です。より速い応答が必要な場合は gpt-oss:20b も選択肢になります。

WSL2環境での注意点

実行環境による違いについて:

今回のテスト環境（WSL2 Ubuntu 24.04）では、NVIDIA RTX 4060 Ti (16GB) + CPUのハイブリッドモードで約8.5 tokens/sでした。

実行環境 GPU 推論速度（実測） 備考
WSL2 NVIDIA RTX 4060 Ti 8.5 tokens/s GPU+CPUハイブリッド
WSL2 CPU のみ 8-10 tokens/s Ryzen 9 9950X (16コア)
Windows - 未測定 -

AMD Ryzen 9 9950Xの統合GPUについて:

  • Ryzen 9 9950Xには統合GPU（2 CU、2GB）が搭載されていますが、規模が非常に小さく高速化への寄与は限定的です
  • WSL2からは統合GPUの共有メモリにアクセスできません
  • 今回のハイブリッドモードでは、主にNVIDIA GPUとシステムRAMを使用しています

推奨:

  • 開発環境: WSL2でハイブリッドモード（GPU+CPU）が実用的
  • さらなる高速化: より大型のGPU（24GB以上のVRAM）または gpt-oss:20b などの軽量モデルを検討
  • 完全GPU実行: 80GB VRAM（H100, A100など）が理想的

これまでのモデルとの比較

自分のAI VTuberプロジェクトでは、これまで qwen2.5:14b を中心に使ってきました。gpt-oss:120bと比較してみます。

qwen2.5:14b（リアルタイム応答重視）

基本スペック

  • パラメータ数: 14B
  • モデルサイズ: 9.0GB（ダウンロードサイズ）
  • 推奨メモリ: 16GB以上のRAM（CPUモード）、または8GB以上のVRAM（GPUモード）
  • 応答速度: 2〜5秒/応答
  • 用途: リアルタイム会話、配信応答

メリット

  • ⚡ レスポンスが速い（ユーザーを待たせない）
  • 💾 メモリ消費が少ない（複数モデル同時起動可能）
  • 🎯 カジュアルな会話には十分な品質

デメリット

  • 複雑な推論タスクには限界
  • 長文生成の一貫性がやや弱い
  • ツール呼び出し機能は限定的

gpt-oss:120b（推論重視）

基本スペック

  • パラメータ数: 117B（アクティブ5.1B/トークン、MoE）
  • モデルサイズ: 65GB（ダウンロードサイズ）
  • 推奨メモリ:
    • GPU実行: 80GB VRAM（H100, MI300Xなど）
    • CPU実行: 128GB システムRAM推奨（最低64GB）
  • 応答速度: 12〜46秒/応答（CPU実行時）
  • 推論速度: 約8.5 tokens/s（CPU実行時）
  • 用途: 複雑な推論、エージェント処理、技術文書作成

メリット

  • 🧠 推論過程が可視化される（Chain-of-Thought）
  • 🔧 ツール利用・関数呼び出しが強力
  • 📊 複雑な問題解決能力が高い
  • 📝 長文生成の品質・一貫性が高い

デメリット

  • 🐌 応答に時間がかかる
  • 💾 メモリ使用量が大きい
  • 🔥 発熱・消費電力が大きい

使い分けの提案

用途 推奨モデル 理由
リアルタイム会話 qwen2.5:14b 応答速度が重要
ライブ配信応答 qwen2.5:14b ユーザーを待たせない
複雑な質問応答 gpt-oss:120b 推論能力が必要
コード生成・デバッグ gpt-oss:120b 論理的思考が重要
エージェント処理 gpt-oss:120b ツール利用が必要
バッチ処理 gpt-oss:120b 時間制約が緩い

ハイブリッド運用の可能性

実際のAI VTuberプロジェクトでは、以下のようなハイブリッド運用が考えられます：

[ユーザー入力]
    ↓
[軽量フィルタ（qwen2.5:14b）]
    ↓ 簡単な質問
[即座に応答（2-5秒）]
    ↓ 複雑な質問
[gpt-oss:120bで深い推論（20-40秒）]
    ↓
[高品質な応答]

このアプローチにより、多くの質問には素早く応答しつつ、必要な時だけ深い推論を行うことができます。

実際の比較テスト

同じ複雑な質問「AI VTuberが記憶を持つシステムを作りたいのですが、RAGとベクトルデータベースを使う方法と、イベントベースの記憶システムを使う方法のどちらが良いと思いますか？それぞれのメリット・デメリットを簡潔に教えてください。」を両モデルに投げてみました。

qwen2.5:14bの結果

応答時間: 29.6秒

実際の応答（全文）:

クリックして全文を表示

AI VTuberに記憶機能を追加する際に、情報検索支援（Retrieval-Augmented Generation: RAG）とベクトルデータベースを使用するアプローチ、またはイベントベースのメモリシステムを使用するアプローチはそれぞれ異なる特性を持っています。以下に両者の主な利点と欠点をまとめました。

Retriever-Augmented Generation (RAG) + ベクトルデータベース

メリット:

  1. ダイナミック性: ユーザーとの対話中に新しく生成された情報をリアルタイムで記憶・検索可能。
  2. コンテキストの理解力向上: 以前の会話を通じて得た情報や経験を活用し、より自然な応答が可能。
  3. スケーラビリティ: ベクトルデータベースは大量の情報を効率的に検索可能なため、アシスタントの記憶容量を大きくすることが可能。

デメリット:

  1. 計算コスト: 検索やインデックス作成に時間がかかる。
  2. プライバシーとセキュリティ: 会話履歴などの個人情報を管理する必要があり、適切な保護が必要となる。
  3. 過学習のリスク: 過剰な情報が記憶の中に入ると、混乱や誤った応答を引き起こす可能性がある。

イベントベースの記憶システム

メリット:

  1. 単純性と効率: 特定のイベントに基づいて明確に情報を保存・参照するため、管理が容易でパフォーマンスも高い。
  2. 直感的な理解: ユーザーは特定の経験やイベントに対するVTuberの反応を予測しやすい。

デメリット:

  1. 記憶の粒度: 全ての会話履歴を詳しく保存することができず、長い間隔を経た後での情報参照が難しくなる。
  2. 柔軟性の欠如: 一連のイベントに基づいてのみ動作するため、即座に新しい情報を活用できない場合がある。
  3. スケーラビリティ: 長期的な視点で見た場合、大量のイベントを管理し続けることは困難となる可能性がある。

どちらも重要なアプローチであり、具体的なアプリケーションや目的によって最適な選択が変わることを考慮してください。

応答の特徴:

  • 簡潔で読みやすい比較
  • RAGとイベントベースの基本的なメリット・デメリットを網羅
  • 実用的な推奨事項を含む
  • 全体で約400語

gpt-oss:120bの結果

応答時間: 2分以上

実際の応答（全文）:

クリックして全文を表示

1. RAG（Retrieval‑Augmented Generation）＋ベクトルデータベース方式

項目 メリット デメリット
検索精度・汎用性 ・埋め込みベクトルで意味的に類似した過去発言・シナリオを高速に検索できる。
・新しいトピックや予期しない質問にも、過去の類似コンテキストを引き出せる。		 ・埋め込みが「意味」だけを捉えるため、時間的な順序や「誰が言ったか」などのメタ情報は別途管理が必要。
スケーラビリティ ・インデックス（FAISS / Qdrant / Milvus など）で数十万～数百万件でもミリ秒検索が可能。 ・インデックス作成・更新コストがかかる。大量データが増えるとストレージとメモリの要件が上がる。
実装のハードル ・既存ライブラリが豊富（LangChain, LlamaIndex, Haystack 等）。
・LLM とのインタフェースがシンプル（「検索 → プロンプトに埋め込む」だけ）。		 ・ベクトル化・インデックス更新のパイプラインを自前で構築しないと、リアルタイム性が低くなることがある。
メモリの"鮮度" ・過去の全データを保持できるので、長期記憶が自然に蓄積される。 ・古い情報が増えると「どれが重要か」判別が難しくなる。削除・重み付けのポリシーが必要。
開発コスト ・比較的短期間で PoC が作れる。 ・ベクトル化やインデックスチューニングの経験が必要。

典型的な構成例

  1. 発言・イベント → テキスト前処理 → 埋め込み（Sentence‑Transformer / OpenAI embeddings）
  2. ベクトルDBに INSERT（メタ情報：timestamp, speaker, scene など）
  3. ユーザー発話 → 埋め込み → 近似最近傍検索 → 上位 N 件を プロンプト に組み込んで LLM に生成させる

2. イベントベース（時系列）記憶システム

項目 メリット デメリット
時間・因果関係の把握 ・イベントを時系列リストやグラフで管理でき、「直前の会話」や「過去の因果関係」を容易に参照できる。 ・大量のイベントが蓄積すると検索が線形になる（インデックス化が必要）。
重み付け・忘却 ・「重要度」「感情スコア」「視聴者のリアクション」などでスコア付けし、忘却アルゴリズム（例: LRU, decay）を組み込みやすい。 ・スコアリング基準を設計・チューニングする手間がかかる。
カスタムロジック ・「○○の時は〇〇と答える」「今日のライブで出したジョークは次回も使える」など、ルールベースと組み合わせやすい。 ・ルールが増えると管理が煩雑になり、矛盾が生じやすい。
リアルタイム性 ・新しいイベントをそのままリストに append でき、即座に参照可能。 ・過去の膨大なイベントから「意味的に似た」ものを探すのは苦手。
実装のハードル ・シンプルなデータ構造（JSON/SQL/NoSQL）で始めやすい。 ・高度な検索（類似度）を実装するには別途ベクトル化や全文検索エンジンが必要になることが多い。

典型的な構成例

  1. イベントオブジェクト（timestamp, speaker, type, content, meta）を時系列 DB（例: TimescaleDB, MongoDB, DynamoDB）に保存。
  2. 必要に応じて
    • 直近 N 件を取得 → コンテキストに使用。
    • 属性フィルタ（type=「質問」, sentiment>0.7）で抽出。
    • スコアデケイで古い・重要度低いイベントを自動削除。
  3. LLM へのプロンプトは「過去 X 分の会話」や「前回の○○シーン」など、ルールで選択したテキストを埋め込む。

3. どちらを選ぶべきか？

観点 RAG + ベクトルDB が向いているケース イベントベースが向いているケース
目的 意味的に似た過去の発言やストーリー要素を汎用的に呼び出したい 時間軸・因果関係が重要で、直前の文脈や「今日の出来事」だけで十分
データ量 数万〜数百万件の「テキスト」データを扱うときに強い 数千〜数万件の「イベント」ならシンプルに管理できる
リアルタイム性 1〜2 秒以内の検索で OK なら可（インデックス更新はバッチで） イベントは即時追加・即時取得が必要なライブ配信に最適
開発リソース ベクトル検索エンジン・埋め込みモデルの知識が必要 基本的な DB とルールエンジンだけで実装可能
拡張性 将来的に「類似画像」「音声」などマルチモーダル検索を追加しやすい 追加機能は「属性」や「ルール」拡張で対応。マルチモーダルは別途実装が必要
コスト GPU（埋め込み生成）＋ストレージコストがやや高め 主にストレージとサーバーリソースだけで低コスト

推奨シナリオ例

シナリオ 推奨方式 理由
初期プロトタイプ（1ヶ月以内にライブ配信開始） イベントベース 実装が速く、リアルタイム性と「直近の会話」管理が容易。
長期運用＋ファンが残したコメント・過去エピソードを検索したい RAG + ベクトルDB 膨大なテキストデータから意味的に類似したエピソードを引き出せる。
マルチモーダル（動画・画像・音声）を統合した記憶 RAG（マルチモーダル埋め込み） 画像・音声もベクトル化すれば同一インデックスで検索可能。
視聴者の感情・リアクションに応じて「忘却」させたい イベントベース + スコアデケイ イベントごとに感情スコアを付与し、重要度が低いものを自動削除しやすい。
開発リソースが限られている小規模チーム イベントベース 追加のベクトル検索インフラが不要。

4. ハイブリッドも検討価値あり

  • リアルタイム層：最新の数百件はイベントベースで即時取得。
  • 長期層：過去データは定期的にベクトル化し、RAG 用インデックスに投入。
  • スコア付与：イベントに感情・重要度スコアを付け、スコアが高いものだけをベクトルDBに入れる（ノイズ削減）。

この構成なら、低レイテンシと意味検索の両方の利点を活かせます。

まとめ（1行要約）

  • RAG + ベクトルDBは「意味的類似検索」や「大規模長期記憶」に強く、実装コストはやや高め。
  • イベントベースは「時系列・因果関係・リアルタイム性」に優れ、シンプルで低コスト。
  • プロジェクトのフェーズや目的に合わせて選択し、必要ならハイブリッドで相乗効果を狙うのが最適です。

応答の特徴:

  • 非常に詳細な表形式の分析
  • RAG+ベクトルDBとイベントベースの比較を5つの観点で整理（検索精度、スケーラビリティ、実装ハードル、メモリ鮮度、開発コスト）
  • 典型的な構成例を具体的に記載
  • 「どちらを選ぶべきか」の判断軸を6つの観点で提示
  • 推奨シナリオを5つの事例で説明
  • ハイブリッド運用の提案も含む
  • 全体で約2000〜2500語

比較まとめ

項目 qwen2.5:14b gpt-oss:120b
パラメータ数 14B 117B（アクティブ5.1B/トークン）
モデルサイズ 9.0GB 65GB
推奨メモリ（GPU） 8GB VRAM 80GB VRAM
推奨メモリ（CPU） 16GB RAM 128GB RAM（最低64GB）
応答時間（CPU） 29.6秒 2分以上
応答の深さ ⭐⭐⭐ ⭐⭐⭐⭐⭐
構造化 シンプルな箇条書き 複数の詳細な表
実用性 すぐに理解できる 詳細な判断材料を提供
適した用途 リアルタイム会話、クイックリファレンス 技術文書作成、詳細な設計判断

結論:

  • qwen2.5:14bは、素早く要点を掴みたい時や、ユーザーとのリアルタイムな会話に最適
  • gpt-oss:120bは、深い分析が必要な技術判断や、詳細なドキュメント作成に最適
  • 用途に応じて使い分けることで、最適なUXを実現できる

感想

Good

  • ✅ オープンソースで商用利用可能（Apache 2.0）
  • ✅ 日本語の応答品質が高い
  • ✅ 単一GPUで動作する設計
  • ✅ 推論過程が見えるのは開発に便利
  • ✅ qwen2.5:14bとの使い分けで最適なUXを実現できる

注意点

  • ⚠️ モデルサイズが65GBと大きい
  • ⚠️ 応答速度は小型モデルに比べて遅い
  • ⚠️ 80GB GPUが推奨（CPUでも動くが実用的ではない）
  • ⚠️ リアルタイム用途には向かない

まとめ

OpenAIのgpt-oss-120bは、オープンウェイトながら高品質な推論モデルです。特に以下のようなユースケースに適しています：

  • 推論過程の可視化が重要なアプリケーション
  • エージェント的なタスク（関数呼び出し、ツール利用）
  • 商用利用が必要なプロジェクト

Ollamaで簡単に試せるので、興味のある方はぜひ触ってみてください。

参考資料

🤖 Generated with Claude Code

Co-Authored-By: Claude noreply@anthropic.com

0
1
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
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?