【Amazon Bedrock】Nemotron 3 Nano 30Bを使ってみた(Gemma 3 27B / gpt-oss-20bとの比較)【2026年1月】
NVIDIA がLLMを出していることをご存知でしょうか?
2025年12月、Amazon Bedrock に NVIDIA Nemotron 3 Nano 30B が追加されました。NVIDIAといえばGPUのイメージが強いですが、実は生成AI向けのモデル開発も積極的に進めています。
新しいモデルが出てきたので、生成AI大手の同規模モデル(Gemma 3 27B、gpt-oss-20b)と比べて、実際に使ってどうだったかを試してみました。
この記事では、
- 文章生成
- コード生成
- tool calling
- JSON構造化出力
- 計算・推論
などのパターンで、何を投げて何が返ってきたかを具体的に紹介します。
0. この記事で扱う話
扱うのは「超厳密な学術ベンチ」ではなく、Bedrockでの実運用を意識した小さめの検証です。
- 文章を書かせたときの品質・自然さ
- コード生成の精度(Go言語でフィボナッチ数列)
- JSONの構造化出力は安定しているか
- tool calling は "本当に" toolUse で返るか
- 長文入力(文脈)をちゃんと参照できるか
- 速度(体感に直結するtokens/s)はどのくらいか
- 逆に、落とし穴は何か
1. 前提:今回の比較条件
1-1. 対象モデル(Bedrockの modelId)
| 表記 | Bedrock modelId | Provider |
|---|---|---|
| Nemotron 3 Nano 30B | nvidia.nemotron-nano-3-30b | NVIDIA |
| Gemma 3 27B | google.gemma-3-27b-it | |
| gpt-oss-20b | openai.gpt-oss-20b-1:0 | OpenAI |
※ Bedrock コンソール上の表示名は揺れることがあり、Gemma は modelId が -it(instruction tuned)なのに表示名が「PT」になっているケースがありました。ここでは modelId を正として扱います。
1-2. 仕様メモ(公開情報ベース)
- Nemotron 3 Nano は Bedrock で 256K context window や native tool calling がうたわれています(AWS What's New)。
- Gemma 3 は 128K context window・マルチモーダル(text+image入力) が特徴です(Googleのモデルカード)。
- gpt-oss-20b は Bedrock で 128K context として案内されており、Converse API 等で利用できます(AWS公式ドキュメント)。
> 注: 本記事では料金は扱いません。各モデルの料金は AWS Bedrock の料金ページをご確認ください。
1-3. 実行環境と呼び出し方法
- リージョン:
ap-northeast-1 - API:
bedrock-runtime.converse(Converse API) - 推論: On-Demand
- ベンチ実装: このリポジトリの
bench/(Python + boto3)
> 重要: gpt-oss-20b は reasoningContent を返すことがあり、短い maxTokens だと「答え(text)」まで到達せず途中で切れるケースがありました。今回はケースごとに maxTokens を調整して、少なくとも回答が出る条件に寄せています。
2. どんな問題で、どんな結果だったか(ケース別)
実行ログは bench/results/nemotron_20260130_162954Z/ です。
ここでは「ケース → 期待値 → 実際の出力」をまとめます(出力は一部省略)。
2-1. 文章生成:自然な日本語を書けるか
ケース: text.fuji_description
- 指示: 「富士山について、400文字程度で解説してください」
Nemotron 3 Nano 30B の出力:
富士山は、日本最高峰の標高3,776メートルを誇る活火山で、山梨県と静岡県にまたがっています。その美しい円錐形の姿は、古くから日本の象徴として親しまれ、2013年には世界文化遺産に登録されました。富士山は約10万年前に形成が始まり、現在の姿になったのは約1万年前とされています。最後の噴火は1707年の宝永大噴火で、この時に山腹に宝永火口が形成されました。
富士山は四季折々の表情を見せ、特に冠雪した冬の姿は多くの芸術作品のモチーフとなっています。登山シーズンは7月から9月で、毎年約30万人が登頂に挑戦します。また、富士五湖や白糸の滝など周辺の観光地も人気です。信仰の対象としても重要で、山頂には浅間大社の奥宮があり、古くから多くの修験者や参詣者が訪れてきました。
Gemma 3 27B の出力:
富士山は、日本を代表する標高3,776メートルの活火山です。静岡県と山梨県の県境に位置し、その美しい円錐形の山容は日本の象徴として国内外から愛されています。富士山は約10万年前から噴火を繰り返してきた複成火山で、最後の噴火は1707年の宝永噴火でした。
古くから霊峰として信仰の対象とされ、多くの芸術作品や文学作品に登場してきました。葛飾北斎の「富嶽三十六景」や、夏目漱石、太宰治などの文学作品にも描かれています。2013年には「富士山-信仰の対象と芸術の源泉」として世界文化遺産に登録されました。
登山シーズンは7月上旬から9月上旬で、毎年多くの登山者が訪れます。山頂からのご来光は特に人気があります。また、富士五湖や白糸の滝など、周辺には魅力的な観光スポットも多数あり、一年を通じて多くの観光客が訪れる日本を代表する観光地となっています。
gpt-oss-20b の出力:
富士山は、標高3,776メートルを誇る日本最高峰の活火山であり、山梨県と静岡県にまたがって位置しています。その美しい円錐形の山容は、古くから日本の象徴として親しまれ、国内外で広く知られています。
富士山の形成は約10万年前に始まり、複数の火山活動によって現在の姿になりました。最後の噴火は1707年の宝永噴火で、この時に山腹に宝永火口が形成されました。現在も活火山として気象庁による監視が続けられています。
信仰の対象としても重要で、古くから修験道の霊場として崇められてきました。江戸時代には富士講と呼ばれる信仰集団が形成され、多くの庶民が登拝しました。また、葛飾北斎の「富嶽三十六景」をはじめ、多くの芸術作品のモチーフとなっています。
2013年には「富士山-信仰の対象と芸術の源泉」として世界文化遺産に登録されました。登山シーズンは7月から9月で、毎年約30万人が登頂を目指します。富士五湖や白糸の滝など、周辺の観光地も人気を集めています。
所感:
3モデルとも正確で自然な日本語解説文を生成しました。内容も事実に基づいており、文章として完成度が高いです。
- Nemotron: 基本情報を網羅的にカバー。構成がバランス良く、読みやすい
- Gemma: 文化・芸術面の記述が充実。具体的な作品名も挙げて説明
- gpt-oss: 地質学的・歴史的視点が詳細。やや学術的なトーン
どのモデルも実用レベルですが、Gemmaは文化的側面、gpt-ossは歴史的側面、Nemotronはバランス型という傾向が見られました。
2-2. コード生成:Go言語でフィボナッチ数列
ケース: code.fibonacci_go
- 指示: 「Go言語でフィボナッチ数列を計算する関数を書いてください。再帰ではなく、ループを使った実装でお願いします」
Nemotron 3 Nano 30B の出力:
package main
import "fmt"
func fibonacci(n int) int {
if n <= 1 {
return n
}
a, b := 0, 1
for i := 2; i <= n; i++ {
a, b = b, a+b
}
return b
}
func main() {
fmt.Println(fibonacci(10)) // 55
}
Gemma 3 27B の出力:
package main
import "fmt"
func fibonacci(n int) int {
if n == 0 {
return 0
}
if n == 1 {
return 1
}
prev, curr := 0, 1
for i := 2; i <= n; i++ {
prev, curr = curr, prev+curr
}
return curr
}
func main() {
for i := 0; i < 10; i++ {
fmt.Printf("fibonacci(%d) = %d\n", i, fibonacci(i))
}
}
gpt-oss-20b の出力:
package main
import "fmt"
// fibonacci はn番目のフィボナッチ数を計算します
func fibonacci(n int) int {
if n <= 1 {
return n
}
fib := make([]int, n+1)
fib[0], fib[1] = 0, 1
for i := 2; i <= n; i++ {
fib[i] = fib[i-1] + fib[i-2]
}
return fib[n]
}
func main() {
fmt.Println(fibonacci(10)) // 55
}
所感:
全モデルとも正確に動作するコードを生成しました。
- Nemotron: シンプルで効率的。2変数のスワップで実装
- Gemma: より詳細な境界条件チェック。出力も複数パターン表示
- gpt-oss: スライスを使った実装。コメントも追加。メモリは使うが読みやすい
どれも実用的ですが、Nemotronとgpt-ossは簡潔、Gemmaは丁寧な印象です。
2-3. JSONの構造化出力(instruction_following)
ケース: json.capital
- 指示: 「出力はJSONのみ。answer と confidence を返す。日本の首都は?」
| model | 出力(抜粋) | 判定 |
|---|---|---|
| Nemotron | {"answer":"東京","confidence":0.99} | OK |
| Gemma | json {"answer":"東京","confidence":1.0} | OK(ただしコードフェンス込み) |
| gpt-oss | {"answer":"東京","confidence":0.99} | OK |
ケース: json.schema
- 指示: 「出力はJSONのみ。titleとpoints(配列)を返す。文字数制約あり」
| model | 出力(傾向) | 判定 |
|---|---|---|
| Nemotron | title+pointsをJSONで返す | OK |
| Gemma | JSONで返す(コードフェンスが付く場合あり) | OK(今回の評価ロジックではOK) |
| gpt-oss | JSONを返す(ただし maxTokens が小さいと推論だけで終わることがある) | OK(今回の条件ではOK) |
ここは3モデルとも通っており、「JSONだけ返してほしい」系は、ある程度戦えます。
2-4. tool calling(toolUseが返るか)
ケース: tool.get_weather
- 指示: 「必ず get_weather を呼び出して、cityはTokyo。ツール呼び出し以外のテキストは出さない」
- toolConfig:
toolChoiceでget_weatherを強制
| model | 実際の挙動 | 判定 |
|---|---|---|
| Nemotron | toolUse: { name: get_weather, input: {city: Tokyo} } | OK |
| Gemma | tool_code 風のテキスト(toolUseではない) | NG |
| gpt-oss | reasoningContent で「ツール呼ぶべき」を説明して終わる(toolUseなし) | NG |
ここが今回、Nemotronを主役にした理由の1つです。
> 実装の現場だと「ツール呼び出しがテキストで返る」= パースや再実行が必要になりがちで、想像以上に運用コストになります。toolUse が返るかは、体感に直結します。
2-5. 長文(long_context)
ケース: ctx.ref_code
- 指示: 長めの文章の中にある
ORANGE-FOX-2026を「1行で」返す
| model | 出力 | 判定 |
|---|---|---|
| Nemotron | ORANGE-FOX-2026 | OK |
| Gemma | ORANGE-FOX-2026 | OK |
| gpt-oss | ORANGE-FOX-2026 | OK |
この程度の参照は3モデルとも問題なし、という結果でした。
2-6. 推論(reasoning):単発は通るが、多段は落ちる
ケース: math.mul
- 指示:
17*23を数値だけで返す
| model | 出力 | 判定 |
|---|---|---|
| Nemotron | 391 | OK |
| Gemma | 391 | OK |
| gpt-oss | 391 | OK |
ケース: math.discount_tax
- 指示: 「1200円を10%値引き→その後に消費税10%」の最終価格を数値だけで返す(正解は
1188)
| model | 出力 | 何が起きたか |
|---|---|---|
| Nemotron | 1080 | 値引きだけで止まった |
| Gemma | 1320 | 税だけをかけた |
| gpt-oss | 1188 + 計算過程の説明 | OK(ただし数値以外も出力) |
「値引き→税」のような多段計算で落ちるのは、LLM運用でよくあるパターンです。
Nemotronは tool calling が強いので、数値系は 計算をツールに寄せるのが相性良いと思います。
2-7. 堅牢性(robustness):不確実な質問で保留できるか
ケース: robust.idk
- 指示: 「2026年のノーベル文学賞受賞者は?」に対して、推測せず「不明」だけで返す
| model | 出力 | 判定 |
|---|---|---|
| Nemotron | 不明です。 | OK |
| Gemma | 不明です。 | OK |
| gpt-oss | 不明 | OK |
このケースは3モデルとも通りました。
2-8. 速度(throughput):体感差が出る
ケース: throughput.blog_intro
- 指示: 「Amazon BedrockでNemotronを試す」導入文を長めに生成
スループット(平均 tokens/s)は、gpt-oss > Nemotron > Gemma の傾向でした。体感として、gpt-oss が最も速く、Gemma は若干遅めです。長文生成の頻度が高いユースケースでは、この差が効いてきます。
3. まとめ:Nemotronをどう位置づけるか
今回の範囲だと、Nemotronは次の性格が見えました。
- tool calling をBedrock流(toolUse)で返せる → エージェント/ワークフローに乗せやすい
- 速度も十分速い(ただし最速はgpt-oss側)
- 多段算術は取りこぼすことがある → 計算はツール化/検算が安全
採用判断としては、こういう整理が一番しっくり来ます。
- ツール連携前提で「実装の摩擦」を減らしたい → Nemotron
- とにかく高速にテキストを回したい → gpt-oss
- 画像入力も含めて使いたい → Gemma
参考
- AWS What's New: NVIDIA Nemotron 3 Nano now available on Amazon Bedrock
https://aws.amazon.com/about-aws/whats-new/2025/12/nvidia-nemotron-3-nano-amazon-bedrock/
- NVIDIA Nemotron 3 Family of Models (Research)
https://research.nvidia.com/labs/nemotron/Nemotron-3/
- Google Gemma 3 model card
https://ai.google.dev/gemma/docs/modelcard3
- AWS Bedrock docs: OpenAI models
https://docs.aws.amazon.com/bedrock/latest/userguide/models-openai.html