1時間50円級GPUで日本語RAGはどこまで動くのか？A4000 16GBでgpt-oss 20Bを試した
本文の状態
日本語全文を表示中
詳細モードで約11分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
HEROZ Tech Blog
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
はじめに
最近、オープンソースLLMの選択肢が急速に増えています。gpt-oss、Gemma、Phi、Ministral、Qwen、DeepSeek、LLM-jp など、ローカル環境やGPUクラウド上で利用できるモデルの候補もかなり広がってきました。
一方で、業務利用、特に日本語RAGで使うことを考えると、公開ベンチマークのスコアだけでは判断できません。日本語で安定して回答できるのか、検索文書に忠実に答えられるのか、英語や中国語が不自然に混じらないのか、推論時間は実用的なのか、といった観点が重要になります。
さらに実務では、GPUコストも無視できません。A100のような高性能GPUを使えば大きなモデルを動かしやすくなりますが、すべての用途で高価なGPUを使えるわけではありません。RAG評価、夜間バッチ、大量の社内文書処理のような用途では、「安価なGPUでどこまで成立するか」の方が重要になることもあります。
そこで今回は、GPUSOROBANで利用できる A4000 16GB 環境を使い、日本語RAGタスクで複数のOSS LLMを比較しました。GPUSOROBANは、ローカルPCからクラウド上のNVIDIA GPUインスタンスを利用できるGPUクラウドサービスで、LLMなどの機械学習用途にも利用できます。また、利用料金は1時間50円からで、停止中は課金されないと説明されています。
結論から言うと、今回の条件でまず試す候補は gpt-oss 20B でした。
Allganize RAG Dataset では上位グループに入り、J-RAGBench ではクラウドLLM基準に匹敵する結果となりました。また、リトライもほぼ発生せず、日本語遵守も安定していました。
今回の記事では、1時間50円級のA4000 16GBで、日本語RAG用OSS LLMがどこまで実用になるのかを見ていきます。
評価条件
今回は、以下の2種類の日本語RAG評価データセットを使用しました。
データセット
問題数
特徴
207問
エンタープライズサーチ寄り
114問
難問寄り
Allganize RAG Dataset は、実務の社内文書検索やFAQに近い性質を持つ評価として見ています。一方で J-RAGBench は、より難しい読解・推論を含むRAG評価として扱いました。
回答生成プロンプトでは、検索文書のみを根拠に日本語で回答するよう明示しました。
与えられた検索文書だけを根拠に、質問に対して日本語で回答してください。
評価は主に「情報の網羅性」の観点で行いました。模範回答に含まれる情報がどの程度含まれているか、不要な情報が追加されていないかを1〜5点で評価しています。各質問に対する回答生成と評価は1回ずつ行い、評価には LLM-as-a-Judge を用いました。評価モデルは Claude Sonnet 4.5 です。
LLM-as-a-Judge の評価は回答の長さや表現の影響を受ける可能性があるため、小さなスコア差だけで厳密な順位を判断するのではなく、応答時間やリトライ回数、日本語遵守も合わせて見る方針にしました。
また、精度だけでなく、次の指標も集計しました。
指標
意味
時間(s)
1回答あたりの平均応答時間
トークン数
1回答あたりの平均出力トークン数
リトライ回数
5分タイムアウトまたは応答失敗による再実行回数
非日本語回答
回答の主言語が日本語以外だった割合
非日本語文字
主言語が日本語でも、中国語・簡体字・ハングルなどが不自然に混入した割合
英語の略語、製品名、技術用語、型番などは、非日本語文字としては扱わない方針にしました。たとえば API、PDF、RAG のような表記は許容しています。
評価対象モデル
今回評価したモデルは以下です。
記事中の表示名
実行名
原産エリア
GPT-5.5 none
API / reasoning none
米国
GPT-5.5 medium
API / reasoning medium
米国
gpt-oss 20B
gpt_oss_20b
米国
Gemma 4 E4B
gemma4_e4b_it_q4_k_m
米国
Phi-4 Reasoning
phi4_reasoning_14b_q4_k_m
米国
Ministral 3 14B
ministral_3_14b_instruct_2512_q4_k_m
欧州
Qwen3 8B
qwen3_8b
中国
Qwen3 14B
qwen3_14b
中国
Qwen3.5 9B
qwen3_5_9b
中国
DeepSeek-R1 14B
deepseek_r1_14b
中国
LLM-jp 4 8B Instruct
llm_jp_4_8b_instruct_gguf_q4_k_m
日本
評価対象モデル
本文中では、読みやすさを優先して gpt-oss 20B、Qwen3.5 9B、LLM-jp 4 8B Instruct のような表示名で統一します。
また、原産エリアは、モデル提供元・開発主体をもとに大まかに整理しています。実行名は、今回実際に利用したOllamaタグに合わせています。本記事は、同一条件に厳密に量子化方式を揃えたモデル研究というより、A4000 16GBで実際に使える形のモデルを動かした実用寄りの比較として見てください。
なお、LLM-jp 4 8B Instruct は、今回利用できるGGUF版を用いて評価しました。公式の配布形態や推奨実行環境そのものを評価したものではないため、LLM-jp 4 の結果は、今回使用したGGUF版での結果として見てください。
結果1：Allganize RAG Dataset
まず、Allganize RAG Dataset の結果です。
モデル
評価
時間(s)
トークン数
リトライ
回数
VRAM
(MB)
非日本語
回答
非日本語
文字
GPT-5.5 none
2.81
2.9
2884.4
0
-
0.00%
0.00%
GPT-5.5 medium
2.79
7.3
3180.2
0
-
0.00%
0.00%
gpt-oss 20B
2.74
11.8
3615.3
1
13625
0.00%
0.00%
Gemma 4 E4B
2.73
11.1
3103.2
0
10196
0.00%
0.00%
Phi-4 Reasoning
2.62
69.0
5749.2
10
12990
2.42%
2.90%
Ministral 3 14B
2.75
8.5
3215.3
0
11131
0.00%
0.48%
Qwen3 8B
2.63
12.5
3327.6
2
6307
0.00%
0.00%
Qwen3 14B
2.67
21.2
3331.1
1
10350
0.00%
0.97%
Qwen3.5 9B
2.61
228.3
5697.5
146
8556
0.97%
1.93%
DeepSeek-R1 14B
2.49
13.9
3067.1
0
10360
0.00%
4.83%
LLM-jp 4 8B Instruct
2.28
4.2
2389.0
0
-
0.48%
0.48%
Allganize RAG Dataset の評価結果
imageAllganize：評価スコアと応答時間
Allganize RAG Dataset では、Ministral 3 14B、gpt-oss 20B、Gemma 4 E4B が上位に入りました。スコア差は小さく、このデータセットではこの3モデルがほぼ同程度の結果だったと見ています。
この時点では、どれか1つが明確に抜けているというより、A4000 16GBでも複数のOSS LLMが実務寄りRAGで十分戦えることが分かります。
一方で、表を見ると、平均スコア以外の指標には大きな差があります。特に応答時間、リトライ回数、日本語遵守にはモデルごとの特徴が出ているため、これらは後の節で詳しく見ます。
なお、Qwen3.5 9B は応答時間が大きく外れているため、散布図では表示範囲外としています。詳細は表の時間とリトライ回数を参照してください。
結果2：J-RAGBench
次に、J-RAGBench の結果です。
モデル
評価
時間(s)
トークン数
リトライ
回数
VRAM
(MB)
非日本語
回答
非日本語
文字
GPT-5.5 none
2.32
2.1
2162.8
0
-
0.00%
0.00%
GPT-5.5 medium
2.61
5.9
2387.4
0
-
0.00%
0.00%
gpt-oss 20B
2.68
6.1
2625.2
0
13625
0.00%
0.00%
Gemma 4 E4B
2.55
9.3
2601.6
0
10196
0.00%
0.00%
Phi-4 Reasoning
2.11
8.9
3063.1
0
12990
0.00%
0.00%
Ministral 3 14B
2.44
3.2
2375.1
0
11131
0.00%
0.00%
Qwen3 8B
2.38
15.1
2998.0
5
6307
0.00%
0.00%
Qwen3 14B
2.46
22.0
2877.3
3
10350
0.00%
0.00%
Qwen3.5 9B
2.18
349.3
4070.7
117
8556
0.00%
0.88%
DeepSeek-R1 14B
2.22
9.7
2430.5
0
10360
0.00%
2.63%
LLM-jp 4 8B Instruct
2.36
1.1
1838.7
0
-
0.00%
0.00%
J-RAGBench の評価結果
imageJ-RAGBench：評価スコアと応答時間
J-RAGBench では、gpt-oss 20B、GPT-5.5 medium、Gemma 4 E4B が上位に入りました。難問寄りのRAG評価でも、gpt-oss 20B はクラウドLLM基準に匹敵する結果となっています。
ここで重要なのは、gpt-oss 20B が単に高いスコアを出したことだけではありません。A4000 16GBに収まるモデルでありながら、難問寄りのデータセットでもクラウドLLMと同じ上位グループに入った点です。
一方で、J-RAGBenchでもモデルごとの運用上の差は大きく出ました。応答時間やリトライ回数、日本語遵守の違いは、平均スコアだけでは見えにくいため、次の節で整理します。
ここまでの結果を踏まえると、今回の条件でまず試す候補は gpt-oss 20B だと感じました。
観点
Allganize
J-RAGBench
評価
2.74
2.68
時間(s)
11.8
6.1
リトライ回数
1
0
非日本語回答
0.00%
0.00%
非日本語文字
0.00%
0.00%
VRAM(MB)
13625
13625
Allganize RAG Dataset では上位グループに入り、J-RAGBench でもクラウドLLM基準に匹敵する結果でした。さらに、リトライがほぼ発生せず、日本語遵守も安定していました。
また、A4000 16GBでVRAM使用量が約13.6GBに収まった点も重要です。1時間50円級のGPUで動かせる範囲に収まりつつ、日本語RAGで十分な品質を出せるなら、検証やバッチ処理用途ではかなり現実的な選択肢になります。
実務的には、最高スコアだけでなく、安定して返ってくること、日本語を守ること、GPUメモリに収まることが大事です。この観点で見ると、今回の範囲では gpt-oss 20B が最も「まず試しやすい」候補でした。
日本語RAGでは、日本語として安定して返ることも重要
日本語RAGでは、回答の内容だけでなく、日本語として安定して返ってくることも重要です。特に業務システムや顧客向け用途では、回答中に突然英語や中国語が混じると、内容以前に信頼感を損ないます。
今回、gpt-oss 20B は Allganize / J-RAGBench の両方で、非日本語回答・非日本語文字ともに 0.00% でした。一方で、DeepSeek-R1 14B は Allganizeで非日本語文字 4.83%、J-RAGBenchで 2.63% となりました。
平均スコアだけを見ると見落としやすいですが、日本語RAGの実運用では、この差はかなり重要です。
reasoningが過剰に走るモデルはRAGで扱いにくい
RAGでは、検索文書に含まれる情報をもとに、必要十分な回答を安定して返すことが重要です。一方で、モデルによっては推論機能が過剰に働き、回答生成が長引いたり、出力が膨らんだり、タイムアウトに到達したりするケースがあります。
今回その傾向が最も強く出たのが Qwen3.5 9B でした。今回のA4000環境では、応答が返らない、または5分タイムアウトに到達するケースが多く発生しました。Allganizeではリトライ146回、J-RAGBenchではリトライ117回となっており、通常のRAG用途にそのまま使うにはかなり厳しい挙動でした。
Phi-4 Reasoning も、Allganizeでは平均応答時間と出力トークン数が大きくなりました。こちらはQwen3.5 9Bほど極端ではありませんが、推論が重く出ると、質問によって応答時間が大きく伸びる可能性があります。
もちろん、推論機能そのものが悪いわけではありません。複雑な問題では有効に働く場面もあります。ただ、日本語RAGのように「検索文書を根拠に、必要な情報を簡潔に返す」用途では、推論が過剰に走ると、精度よりも先に応答時間や安定性が問題になります。
今回の条件では、Qwen3.5 9B のように推論が過剰に走るモデルは、スコア以前に応答時間とリトライ回数がボトルネックになりました。
なお、gpt-oss 20B も reasoning に対応したモデルですが、今回利用したOllamaタグでは、Qwen3.5 9B のような応答なしやタイムアウト多発は見られませんでした。今回の結果を見る限り、reasoning に対応しているかどうかよりも、実際の実行設定で推論が過剰に膨らまず、RAG回答として安定して返ってくるかが重要だと感じました。
まとめ
今回は、1時間50円級のA4000 16GB環境で、日本語RAG用OSS LLMを比較しました。
今回の条件でまず試す候補は gpt-oss 20B でした。Allganize RAG Dataset では上位グループに入り、J-RAGBench ではクラウドLLM基準に匹敵する結果となりました。リトライがほぼ発生せず、日本語遵守も安定しており、A4000 16GBでVRAM使用量が約13.6GBに収まった点も実用上大きいです。
一方で、平均スコアだけでは実用性は判断できません。Qwen3.5 9B のように、reasoningが過剰に走って応答時間やリトライ回数が大きくなるモデルもあります。また、DeepSeek-R1 14B のように、日本語回答中の非日本語文字混入が課題になるケースもありました。
今回の結果からは、安価なA4000 16GB環境でも、日本語RAG用OSS LLMは十分に検討できると感じました。ただし、選ぶときは平均スコアだけでなく、応答時間、リトライ回数、日本語遵守まで含めて見る必要があります。
原文を表示
はじめに
最近、オープンソースLLMの選択肢が急速に増えています。gpt-oss、Gemma、Phi、Ministral、Qwen、DeepSeek、LLM-jp など、ローカル環境やGPUクラウド上で利用できるモデルの候補もかなり広がってきました。
一方で、業務利用、特に日本語RAGで使うことを考えると、公開ベンチマークのスコアだけでは判断できません。日本語で安定して回答できるのか、検索文書に忠実に答えられるのか、英語や中国語が不自然に混じらないのか、推論時間は実用的なのか、といった観点が重要になります。
さらに実務では、GPUコストも無視できません。A100のような高性能GPUを使えば大きなモデルを動かしやすくなりますが、すべての用途で高価なGPUを使えるわけではありません。RAG評価、夜間バッチ、大量の社内文書処理のような用途では、「安価なGPUでどこまで成立するか」の方が重要になることもあります。
そこで今回は、GPUSOROBANで利用できる A4000 16GB 環境を使い、日本語RAGタスクで複数のOSS LLMを比較しました。GPUSOROBANは、ローカルPCからクラウド上のNVIDIA GPUインスタンスを利用できるGPUクラウドサービスで、LLMなどの機械学習用途にも利用できます。また、利用料金は1時間50円からで、停止中は課金されないと説明されています。
結論から言うと、今回の条件でまず試す候補は gpt-oss 20B でした。
Allganize RAG Dataset では上位グループに入り、J-RAGBench ではクラウドLLM基準に匹敵する結果となりました。また、リトライもほぼ発生せず、日本語遵守も安定していました。
今回の記事では、1時間50円級のA4000 16GBで、日本語RAG用OSS LLMがどこまで実用になるのかを見ていきます。
評価条件
今回は、以下の2種類の日本語RAG評価データセットを使用しました。
データセット
問題数
特徴
207問
エンタープライズサーチ寄り
114問
難問寄り
Allganize RAG Dataset は、実務の社内文書検索やFAQに近い性質を持つ評価として見ています。一方で J-RAGBench は、より難しい読解・推論を含むRAG評価として扱いました。
回答生成プロンプトでは、検索文書のみを根拠に日本語で回答するよう明示しました。
与えられた検索文書だけを根拠に、質問に対して日本語で回答してください。評価は主に「情報の網羅性」の観点で行いました。模範回答に含まれる情報がどの程度含まれているか、不要な情報が追加されていないかを1〜5点で評価しています。各質問に対する回答生成と評価は1回ずつ行い、評価には LLM-as-a-Judge を用いました。評価モデルは Claude Sonnet 4.5 です。
LLM-as-a-Judge の評価は回答の長さや表現の影響を受ける可能性があるため、小さなスコア差だけで厳密な順位を判断するのではなく、応答時間やリトライ回数、日本語遵守も合わせて見る方針にしました。
また、精度だけでなく、次の指標も集計しました。
指標
意味
時間(s)
1回答あたりの平均応答時間
トークン数
1回答あたりの平均出力トークン数
リトライ回数
5分タイムアウトまたは応答失敗による再実行回数
非日本語回答
回答の主言語が日本語以外だった割合
非日本語文字
主言語が日本語でも、中国語・簡体字・ハングルなどが不自然に混入した割合
英語の略語、製品名、技術用語、型番などは、非日本語文字としては扱わない方針にしました。たとえば API、PDF、RAG のような表記は許容しています。
評価対象モデル
今回評価したモデルは以下です。
本文中では、読みやすさを優先して gpt-oss 20B、Qwen3.5 9B、LLM-jp 4 8B Instruct のような表示名で統一します。
また、原産エリアは、モデル提供元・開発主体をもとに大まかに整理しています。実行名は、今回実際に利用したOllamaタグに合わせています。本記事は、同一条件に厳密に量子化方式を揃えたモデル研究というより、A4000 16GBで実際に使える形のモデルを動かした実用寄りの比較として見てください。
なお、LLM-jp 4 8B Instruct は、今回利用できるGGUF版を用いて評価しました。公式の配布形態や推奨実行環境そのものを評価したものではないため、LLM-jp 4 の結果は、今回使用したGGUF版での結果として見てください。
結果1：Allganize RAG Dataset
まず、Allganize RAG Dataset の結果です。
Allganize RAG Dataset では、Ministral 3 14B、gpt-oss 20B、Gemma 4 E4B が上位に入りました。スコア差は小さく、このデータセットではこの3モデルがほぼ同程度の結果だったと見ています。
この時点では、どれか1つが明確に抜けているというより、A4000 16GBでも複数のOSS LLMが実務寄りRAGで十分戦えることが分かります。
一方で、表を見ると、平均スコア以外の指標には大きな差があります。特に応答時間、リトライ回数、日本語遵守にはモデルごとの特徴が出ているため、これらは後の節で詳しく見ます。
なお、Qwen3.5 9B は応答時間が大きく外れているため、散布図では表示範囲外としています。詳細は表の時間とリトライ回数を参照してください。
結果2：J-RAGBench
次に、J-RAGBench の結果です。
J-RAGBench では、gpt-oss 20B、GPT-5.5 medium、Gemma 4 E4B が上位に入りました。難問寄りのRAG評価でも、gpt-oss 20B はクラウドLLM基準に匹敵する結果となっています。
ここで重要なのは、gpt-oss 20B が単に高いスコアを出したことだけではありません。A4000 16GBに収まるモデルでありながら、難問寄りのデータセットでもクラウドLLMと同じ上位グループに入った点です。
一方で、J-RAGBenchでもモデルごとの運用上の差は大きく出ました。応答時間やリトライ回数、日本語遵守の違いは、平均スコアだけでは見えにくいため、次の節で整理します。
ここまでの結果を踏まえると、今回の条件でまず試す候補は gpt-oss 20B だと感じました。
観点
Allganize
J-RAGBench
評価
2.74
2.68
時間(s)
11.8
6.1
リトライ回数
1
0
非日本語回答
0.00%
0.00%
非日本語文字
0.00%
0.00%
VRAM(MB)
13625
13625
Allganize RAG Dataset では上位グループに入り、J-RAGBench でもクラウドLLM基準に匹敵する結果でした。さらに、リトライがほぼ発生せず、日本語遵守も安定していました。
また、A4000 16GBでVRAM使用量が約13.6GBに収まった点も重要です。1時間50円級のGPUで動かせる範囲に収まりつつ、日本語RAGで十分な品質を出せるなら、検証やバッチ処理用途ではかなり現実的な選択肢になります。
実務的には、最高スコアだけでなく、安定して返ってくること、日本語を守ること、GPUメモリに収まることが大事です。この観点で見ると、今回の範囲では gpt-oss 20B が最も「まず試しやすい」候補でした。
日本語RAGでは、日本語として安定して返ることも重要
日本語RAGでは、回答の内容だけでなく、日本語として安定して返ってくることも重要です。特に業務システムや顧客向け用途では、回答中に突然英語や中国語が混じると、内容以前に信頼感を損ないます。
今回、gpt-oss 20B は Allganize / J-RAGBench の両方で、非日本語回答・非日本語文字ともに 0.00% でした。一方で、DeepSeek-R1 14B は Allganizeで非日本語文字 4.83%、J-RAGBenchで 2.63% となりました。
平均スコアだけを見ると見落としやすいですが、日本語RAGの実運用では、この差はかなり重要です。
reasoningが過剰に走るモデルはRAGで扱いにくい
RAGでは、検索文書に含まれる情報をもとに、必要十分な回答を安定して返すことが重要です。一方で、モデルによっては推論機能が過剰に働き、回答生成が長引いたり、出力が膨らんだり、タイムアウトに到達したりするケースがあります。
今回その傾向が最も強く出たのが Qwen3.5 9B でした。今回のA4000環境では、応答が返らない、または5分タイムアウトに到達するケースが多く発生しました。Allganizeではリトライ146回、J-RAGBenchではリトライ117回となっており、通常のRAG用途にそのまま使うにはかなり厳しい挙動でした。
Phi-4 Reasoning も、Allganizeでは平均応答時間と出力トークン数が大きくなりました。こちらはQwen3.5 9Bほど極端ではありませんが、推論が重く出ると、質問によって応答時間が大きく伸びる可能性があります。
もちろん、推論機能そのものが悪いわけではありません。複雑な問題では有効に働く場面もあります。ただ、日本語RAGのように「検索文書を根拠に、必要な情報を簡潔に返す」用途では、推論が過剰に走ると、精度よりも先に応答時間や安定性が問題になります。
今回の条件では、Qwen3.5 9B のように推論が過剰に走るモデルは、スコア以前に応答時間とリトライ回数がボトルネックになりました。
なお、gpt-oss 20B も reasoning に対応したモデルですが、今回利用したOllamaタグでは、Qwen3.5 9B のような応答なしやタイムアウト多発は見られませんでした。今回の結果を見る限り、reasoning に対応しているかどうかよりも、実際の実行設定で推論が過剰に膨らまず、RAG回答として安定して返ってくるかが重要だと感じました。
まとめ
今回は、1時間50円級のA4000 16GB環境で、日本語RAG用OSS LLMを比較しました。
今回の条件でまず試す候補は gpt-oss 20B でした。Allganize RAG Dataset では上位グループに入り、J-RAGBench ではクラウドLLM基準に匹敵する結果となりました。リトライがほぼ発生せず、日本語遵守も安定しており、A4000 16GBでVRAM使用量が約13.6GBに収まった点も実用上大きいです。
一方で、平均スコアだけでは実用性は判断できません。Qwen3.5 9B のように、reasoningが過剰に走って応答時間やリトライ回数が大きくなるモデルもあります。また、DeepSeek-R1 14B のように、日本語回答中の非日本語文字混入が課題になるケースもありました。
今回の結果からは、安価なA4000 16GB環境でも、日本語RAG用OSS LLMは十分に検討できると感じました。ただし、選ぶときは平均スコアだけでなく、応答時間、リトライ回数、日本語遵守まで含めて見る必要があります。
AI算出
技術分析ainew評価非常に高い
記事は gpt-oss 20B を含む OSS LLM の A4000 環境での性能を、Allganize RAG Dataset や J-RAGBench という具体的な評価セットを用いて実証しており、コスト対効果という実務的な観点から深い分析を行っている。
6つの評価軸を見る
- AI関連度
- 100
- 情報源の信頼性
- 100
- 新規性
- 75
- 調べる価値
- 100
- 重複の少なさ
- 100
- 日本での有用性
- 75
関連記事
News to Guide
ニュースの次に確認する
発表内容を、現在の料金や仕様と照らし合わせられる関連ガイドです。
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み