DGX Spark でツール操作に強いオープンウェイトモデルは?6 モデルの実測比較

DGX Spark でツール操作に強いオープンウェイトモデルは?6 モデルの実測比較

DGX Spark(128GB)で 6 つのオープンウェイトモデルに、ファイルを読んで一覧にする・抜き出す 3 つの課題を任せたところ、3 課題すべてに合格したのは Qwen の 27B(Q8_0)だけで、ハルシネーション(事実と異なる内容をもっともらしく答えること)が 1 回も出なかったのは Nemotron Bolt(74B-A9B)だけでした。当社は自作の軽量なエージェントハーネスから同じ課題を各モデルに 3〜6 回ずつ流し、答えを正解の表と突き合わせて採点しました。

結果を分けたのは、モデルがツールでファイルを読みに行くかと、読んだ内容を落とさずに書き出せるかの 2 点です。ローカル LLM に、自然言語の指示とツール操作を組み合わせた業務処理を任せたい開発者や情報システムの担当者が、モデルを選ぶ前に何を確かめればよいかを判断できるようにまとめました。

検証の条件:何をどう測ったのか?

検証の条件:何をどう測ったのか?

測定は、DGX Spark(128GB)1 台でモデルを 1 つずつ動かし、正解が決まっている 3 つの課題を同じハーネスから流して、答えを正解と照らす形で行いました。

実行環境とハーネス

実行機は DGX Spark(128GB)です。前回の速さの比較では推論エンジンと先読みの設定で所要時間がどう変わるかを測りましたが、今回は速さではなく、答えが正しいかどうかに絞って 6 つのモデルを比べました。

項目内容
実行機NVIDIA DGX Spark(GB10、128GB の統合メモリ)
ハーネス自作の軽量なエージェントハーネス(VS Code 拡張)。起動用の台本で、人が操作せずに課題を流す
モデルが使える道具ファイルの検索・読み込みなどのツール
設定既定のままの「基準」と、モデルに合わせて調整した「調整版」
回数Qwen は各課題 6 回、Nemotron Bolt は課題1 が 6 回・課題2 と課題3 が 3 回、LLM-jp の 33B は各 4 回、ほかは各 3 回

ハーネスは、モデルに依頼文を渡し、モデルがツールを呼べばそれを実行して結果を返す、というやり取りを最後の回答まで繰り返します。モデルが自分でファイルを開かない限り、答えの材料は手に入りません。ここで測っているのは、モデル単体の力ではなく、このハーネスから使ったときの結果です。

LLM-jp の 33B、GPT-OSS-Swallow、Qwen ベースの Swallow の 3 つは、基準に加えて調整版も流しており、記事ではその調整版の結果を載せています。Qwen・Nemotron Bolt・LLM-jp の 32B-A3B は基準の設定だけです。

3 つの課題と合格基準

課題は 3 つとも、ファイルを読まなければ答えられず、正解が 1 通りに決まるものです。

課題内容正解合格基準
課題1:API の一覧化Web アプリのサーバー側のファイルにある API を、すべて表にする47 本見落とし 2 本以下、作り話 0
課題2:未使用 API の検出画面側のコードから呼ばれていない API を表にする2 本見落とし 0、余分 0、作り話 0
課題3:日本語文書からの抜き出し日本語の利用手順書から、パスと節を抜き出す15 行見落とし 2 行以下、作り話 0

課題1は、前回の記事でも使った、47 本の API を一覧にする課題です。1 つのファイルを最後まで読めば解けますが、本数が多いので、途中で読むのをやめたり、表を書く途中で抜かしたりすると見落としが出ます。

課題2は、API を定義したファイルと画面側のコードの両方を読み比べないと解けません。正解は 2 本だけで、実際には呼ばれている API を 1 本でも余分に挙げると不合格になるため、3 課題の中でいちばん基準が厳しい課題です。

課題3は、日本語で書かれた手順書から、パスと節の組を抜き出す課題です。英語のコードではなく日本語の文章を読む力と、抜き出す範囲を守る力を見ています。

正答率・ハルシネーション・実行時間の数え方

表の数字は、次のように数えています。

  • 正答率:正解のうち、答えに入った割合。モデル・課題ごとに、全回の中央値をとっています。
  • ハルシネーション:3 課題を通して、採点で「作り話」と判定した項目が 1 つ以上あった回の割合(全回)。
  • 実行時間:1 回の始めから最後の応答が終わるまでの経過秒数で、ツールを実行している時間も含みます。

実行時間は、終わり方が「完了」の回だけで課題ごとの中央値をとり、3 課題の中央値の最小〜最大を載せています。時間切れ・出力の上限・エラー・ツールを呼ばずに終わった回は除き、秒は四捨五入しています。

このため、列ごとに母数が違います。正答率とハルシネーションは全回、実行時間は完了した回だけで数えています。また、正答率は中央値なので、回ごとのばらつきは表に出ません。合格・不合格は課題ごとに全回の結果をまとめた判定で、3 課題に合格した Qwen にも、課題2と課題3で不合格の回が 2 回ずつあります。

6 モデルの結果はどうだったか?

6 モデルの結果はどうだったか?

3 課題すべてに合格したのは Qwen の 27B だけで、Nemotron Bolt は課題1に合格し、作り話の判定が 1 回もありませんでした。ほかの 4 モデルは、どの課題にも合格していません。

結果の一覧表

今回の条件で有力なのは、Qwen の 27B と Nemotron Bolt の 2 つです。

モデル課題1:API 47 本の一覧化課題2:未使用 API の検出(2 本)課題3:日本語文書の抜き出し(15 行)ハルシネーション実行時間(秒)
Qwen(27B・Q8_0)合格 100%合格 100%合格 100%11%68〜194
Nemotron Bolt(74B-A9B)合格 100%不合格 50%不合格 73%0%59〜292
LLM-jp(33B)不合格 39%不合格 50%不合格 50%83%510〜706
LLM-jp(32B-A3B)判定不能 0%判定不能 0%判定不能 7%33%54〜146
GPT-OSS-Swallow(20B)不合格 2%不合格 0%不合格 0%89%ー
Swallow(30B-A3B・Qwen ベース)不合格 0%不合格 0%不合格 0%67%ー
  • 課題の%は、正解のうち答えに入った割合の中央値(全回)
  • 実行時間の「ー」は、完了した回が 9 回中 1 回しかなく、出していないもの
  • 「判定不能」は、環境の不備で止まった回が多く、モデルの力を測れていないもの(後述)

表の名前と、モデルの規模・設定の対応は次のとおりです。

表の名前規模と形設定
Qwen(27B・Q8_0)27B の Dense モデルを Q8_0 で量子化基準
Nemotron Bolt(74B-A9B)総 74B のうち 9B が動く MoE基準
LLM-jp(33B)33B調整版
LLM-jp(32B-A3B)総 32B のうち 3B が動く MoE基準
GPT-OSS-Swallow(20B)20B調整版
Swallow(30B-A3B・Qwen ベース)総 30B のうち 3B が動く MoE調整版

ハルシネーションの列だけは、Nemotron Bolt が Qwen を上回りました。Qwen の 11% は 18 回中 2 回に作り話の判定が付いたものです。Qwen が不合格になった回を見ると、課題2で実際には呼ばれている API を挙げた回(2 回)と、課題3で抜き出す範囲の外の行を拾った回(2 回)で、文書に存在しないものを作った回はありませんでした。

実行時間の差

完了した回の実行時間は、Qwen が 68〜194 秒、Nemotron Bolt が 59〜292 秒で、どちらも 1 回あたり 1〜5 分ほどでした。Nemotron Bolt は 1 トークンごとに動くパラメータが 9B と少ないものの、課題によっては Qwen より長くかかっています。

LLM-jp の 33B は 510〜706 秒で、1 回に 6〜26 分かかりました。正解の行をかなり読んでいるのに時間切れになる回もあり、人が結果を待つ使い方には重い長さです。

LLM-jp の 32B-A3B は 54〜146 秒と短いものの、後で述べるとおり環境の不備で止まった回が多く、この数字だけではほかのモデルと比べられません。Swallow 系の 2 モデルは、完了した回が 9 回中 1 回しかなく、多くの回が出力の上限に達するか、ツールを呼ばないまま終わっていました。

実行時間は、推論エンジンや先読みの設定でも大きく変わります。前回の記事では、先読みの長さを変えるだけで所要時間が約 2 割縮みました。ここでの秒数は、同じ機械・同じハーネスで比べたときの目安として見てください。

差はどこで生まれたのか?

差はどこで生まれたのか?

6 モデルの差は、ツールでファイルを読みに行くかと、読んだものを正しく書き出せるかの 2 点で生まれていました。

ツールを呼んで読んだか

最初の分かれ目は、そもそもファイルを読みに行くかどうかです。どの課題も、ファイルを読まずに正解することはできません。

モデルツールを使った回
Qwen(27B・Q8_0)18 回中 18 回
Nemotron Bolt(74B-A9B)12 回中 12 回
LLM-jp(33B)12 回中 12 回
LLM-jp(32B-A3B)9 回中 4 回
GPT-OSS-Swallow(20B)9 回中 4 回
Swallow(30B-A3B・Qwen ベース)9 回中 2 回

Qwen・Nemotron Bolt・LLM-jp の 33B は、毎回ツールを呼んでファイルを読んでいました。一方で Swallow 系の 2 モデルは、多くの回でファイルを開かないまま表を書いていました。正答率は GPT-OSS-Swallow が 0〜2%、Qwen ベースの Swallow が 0% です。読まずに書いた表なので、作り話の判定が付く回も多く、ハルシネーションは 89% と 67% でした。

ここで注意したいのは、ツールを呼ばなかった理由です。モデルの力が足りないのか、ツールの呼び方がこのハーネスと合っていないのかは、今回は切り分けていません。Swallow 系について言えるのは「このハーネスではツールをほとんど呼ばなかった」までで、「モデルが弱い」とは言えません。

読んだものを正しく書き出せたか

2 つ目の分かれ目は、読んだ内容を答えの表に落とさず書けるかです。ツールを毎回呼んだ 3 モデルの間でも、ここで差が出ました。

Qwen の 27B は、3 課題とも正解の行をすべて読んでおり、正答率も 3 課題とも中央値 100% でした。不合格になった回は、課題2で実際には呼ばれている API を未使用として挙げた 2 回と、課題3で抜き出す範囲の外の行まで拾った 2 回で、どちらも「多く書きすぎた」側の失敗です。

Nemotron Bolt は逆に、「書き落とし」側で失敗しました。課題3では、抜き出す対象のパス 14 種類をすべてツールで読んでいたのに、答えの表からは 4〜11 行が抜けていました。課題2も、見落とし・余分・出力の上限で不合格です。

LLM-jp の 33B は、正解の行をかなり読んでいるものの、答えを外すか時間切れになりました。課題2では、画面側のコードにある呼び出し 71 か所を 1 つも読んでいません。これでは、どの API が使われていないかを判断できません。

読めていても書き出しで落ちることがある、という点は、モデルを選ぶときに見落としやすいところです。ツールを呼んだ回数や読んだファイルの数だけを見ると、Qwen と Nemotron Bolt の差は見えてきません。

測れなかったモデル:LLM-jp の 32B-A3B

LLM-jp の 32B-A3B は、9 回中 5 回が、作業フォルダーの指示ファイル(AGENTS.md)に書かれていた、別の開発機のパスのところで止まりました。検証用の機械には無いパスで、課題とは関係ありません。そのため表では、不合格ではなく「判定不能」としています。

モデルの力を測る前に、環境の不備でつまずいた例です。AGENTS.md のような指示ファイルは、ハーネスが自動で読み込んでモデルに渡すことがあります。開発機で書いた設定をそのまま検証用の機械に持ち込むと、モデルによっては、そこに書かれたパスで止まってしまいます。

自社でモデルを比べるときは、検証用の作業フォルダーに、別の機械向けの指示ファイルやパスが残っていないかを先に確かめてください。環境の不備は、そのままモデルの成績の差に見えてしまいます。このモデルは、環境を直して測り直すまで評価を保留しています。

Nemotron Bolt に伸びしろがあると見る理由は?

Nemotron Bolt に伸びしろがあると見る理由は?

Nemotron Bolt は、ツールを毎回使い、作り話も出さなかった一方で、読んだ後の書き出しで点を落としました。書き出しの段階の失敗はハーネスの側で補える余地があるため、伸びしろは大きいと見ています。ただし、これは今回まだ確かめていない仮説です。

公開情報から見た構成

Nemotron Bolt は NVIDIA が公開したオープンウェイトモデルで、総パラメータ 74B のうち、1 トークンごとに動くのは 9B だけの MoE(専門家の混合)です。

項目内容出典
規模総パラメータ 74B、推論時に動くのは 9BArtificial Analysis
構成Mamba-2(状態空間モデル、SSM)と疎な MoE を組み合わせたハイブリッド。複数トークン予測(MTP)を内蔵ApX(同じシリーズの説明)
アーキテクチャ名NemotronH_Omni_Reasoning_V3NVIDIA NeMo AutoModel の資料
入出力テキストと画像を入力し、テキストを出力する推論モデルArtificial Analysis
コンテキスト長約 26 万トークン(256K)Artificial Analysis、DataLearner
ライセンスオープンウェイト(OpenMDW-1.1、商用利用可)Artificial Analysis、DataLearner

MoE そのものは特別な構成ではありません。今回不合格だった Qwen ベースの Swallow(30B-A3B)や、測れなかった LLM-jp の 32B-A3B も MoE です。Nemotron Bolt で違うのは、注意機構とは仕組みの異なる Mamba-2 を組み合わせている点です。ただし、この構成が今回の結果の差を生んだのかどうかは、この検証からは分かりません。

もう 1 つの見どころは計算量です。1 トークンごとに動くパラメータは 9B で、Dense モデルである Qwen の 27B の 3 分の 1 です。少ない計算量で、ツールを毎回使う点では Qwen と並び、作り話の少なさでは上回った、という見方ができます。ただし、メモリには 74B 分の重みを載せる必要があります。

落ちたのは書き出しの段階

Nemotron Bolt の失敗は、Swallow 系とは逆の形をしています。Swallow 系は読む段階で止まっていましたが、Nemotron Bolt は読む段階を通り抜け、書き出す段階で落ちていました。

  • ツールは 12 回とも実行し、正解の行もツールの結果として見ている
  • 作り話の判定は 12 回とも 0 で、6 モデルの中で唯一
  • 不合格の原因は、課題3の書き落とし(4〜11 行)、課題2の見落としと余分、出力の上限(課題2で 1 回)

読む段階で落ちるモデルは、答えの材料そのものを持っていないので、書き方を工夫しても救いにくいはずです。これに対して、材料を読めていて書き出しで落とすモデルは、出力の組み立て方を変えれば結果が変わる可能性があります。

もう 1 つ大きいのは、落ち方の種類です。書き落としは、件数を照らせば気づけます。一方で、もっともらしい作り話は、答えを 1 つずつ元の文書と照らさないと見つかりません。業務の処理では後者のほうが厄介なので、作り話を出さずに書き落としで失敗する Nemotron Bolt は、ハーネス側の手当てを試す価値が高いと考えています。

次の検証で試すハーネスの手当て(仮説)

書き出しの失敗に合わせて、次の検証では次のような手当てを 1 つずつ試します。どれも、効くかどうかはまだ確かめていません。

見えた失敗試す手当てねらい
読んだ行の書き落とし(課題3)表を区切って、何回かに分けて書かせる1 回の出力で長い表を書き切らせない
出力の上限に達した(課題2)出力の上限を上げる答えを最後まで書き切れる長さを確保する
見落としと余分(課題2)書いた後に、読んだ内容と表を照らす見直しの手順を入れる抜けと余分を、答えを返す前に拾う

このほか、Mamba-2 と MoE を組み合わせたモデルの性質に合わせて、ハーネスの設定を詰める余地もあると見ています。どの手当ても Qwen の 27B に効く可能性があるので、比べるときは両方に同じ手当てを入れ、差がどう変わるかを見る必要があります。

今回の結果だけで「構成に合わせれば Nemotron Bolt は伸びる」と言い切ることはできません。言えるのは、失敗した場所が書き出しの段階に集まっていたので、どこを狙って手当てを試すかがはっきりした、というところまでです。

この結果から言えること・言えないこと

この結果から言えること・言えないこと

今回の結果は、ファイルを読んで一覧化・抽出する 3 課題を、各 3〜6 回流した小さな検証のものです。数字を読むときは、次の点に注意してください。

対象の範囲と試行回数

試行回数が少ないので、1 回の違いで割合が大きく動きます。たとえば 9 回流したモデルでは、ハルシネーションの割合は 1 回の違いで約 11 ポイント変わります。表の差は統計的に確かめた差ではなく、今回の試行で見えた傾向です。

論点今回の結果で言えること言い過ぎになる読み方
対象の範囲ファイルを読んで一覧化・抽出する 3 課題での結果業務処理全般での優劣
回数1 課題 3〜6 回の小さな試行統計的に確かな差
有力な 2 モデル今回の条件では Qwen の 27B と Nemotron Bolt が有力ほかのモデルは使えない
LLM-jp の 32B-A3B環境の不備で測れていない不合格・性能不足
Swallow 系このハーネスではツールをほとんど呼ばなかったモデルの力不足
Nemotron Bolt の伸びしろ書き出しで落ちたので、ハーネスで補える可能性がある構成に合わせれば改善する

今回の 3 課題は「ファイルを読んで一覧にする・抜き出す」処理に絞っています。文章の要約や、複数の手順をまたいで画面やデータを操作する処理での優劣は、この検証からは分かりません。業務で使う前には、自社の文書と、自社で正解を用意した課題で同じように測るのが確実です。

「Qwen なら何でもよい」わけではない

3 課題に合格したのが Qwen の 27B だったので、「Qwen 系のモデルが強い」とまとめたくなります。しかし、同じ Qwen をベースにした Swallow(30B-A3B)は、ほとんどツールを呼ばず、3 課題とも正答率 0% でした。

ベースのモデルが同じでも、追加の学習や規模、Dense か MoE かで、ツールの使い方は大きく変わることがあります。有力と言えるのは、今回測った「Qwen の 27B を Q8_0 で量子化したもの」であって、名前に Qwen が付くモデル全体ではありません。量子化の段階を変えたときの正確さも、この検証では測っていません。

モデル名の系統で当たりを付けるのは便利ですが、候補を絞った後は、1 つずつ同じ課題で測る必要があります。同じ系統の名前が付いていても、片方は全課題に合格し、片方は全課題で 0% という差が出ることを、今回の結果は示しています。

よくある質問

よくある質問

DGX Spark などの手元の機械で、オープンウェイトモデルにツール操作を任せるときに出やすい疑問に、今回の結果で分かった範囲で答えます。

Q1: DGX Spark でツール操作に使えるオープンウェイトモデルはどれ?

今回の 3 課題(ファイルを読んで一覧化・抽出する処理)では、Qwen の 27B(Q8_0)が全課題に合格し、Nemotron Bolt は作り話の判定が 0 回でした。ただし各 3〜6 回の小さな検証なので、自社の文書と課題で同じように測ってから選んでください。

Q2: MoE のモデルはツール操作に向かないのか?

一概には言えません。今回不合格だった Qwen ベースの Swallow(30B-A3B)も MoE ですが、同じ MoE の Nemotron Bolt はツールを毎回使い、作り話も出しませんでした。Nemotron Bolt が違うのは Mamba-2 と組み合わせた構成ですが、それが差の原因かどうかは分かっていません。LLM-jp の 32B-A3B も MoE ですが、こちらは環境の不備で測れておらず、MoE だから落ちたとは言えません。

Q3: ハルシネーションが 0% のモデルなら、業務の抽出を任せても安心?

作り話が出ないことと、漏れなく書き出せることは別です。Nemotron Bolt は 12 回とも作り話の判定がありませんでしたが、日本語の手順書からの抜き出しでは、読んだはずの行を 4〜11 行落としました。抽出を任せるなら、件数の照合や見直しの手順など、書き落としに気づく仕組みと組み合わせてください。

まとめ

まとめ

DGX Spark(128GB)で 6 つのオープンウェイトモデルに、ファイルを読んで一覧化・抽出する 3 課題を任せた結果、全課題に合格したのは Qwen の 27B(Q8_0)、作り話の判定が 0 回だったのは Nemotron Bolt でした。自然言語の指示とツール操作を組み合わせた処理では、今回の条件ではこの 2 つが有力です。

差を分けたのは、ツールでファイルを読むかと、読んだものを落とさず書き出せるかでした。Swallow 系の 2 モデルはほとんど読まずに表を書き、Nemotron Bolt は読めていたのに書き出しで落としました。後者はハーネスの側で補える余地があり、次の検証で確かめます。

モデルを選ぶときは、名前の系統だけで決めず、自社の文書と正解つきの課題で「読んだか」「作っていないか」「落としていないか」を分けて測ってください。速さの比較は DGX Spark でローカル LLM を速くするには?、選び方の全体像は ローカル LLM / SLM 導入比較もあわせてご覧ください。

当社では、ローカル LLM やエージェントの検証・PoC も支援しています。ご相談は AI・DX 支援からお寄せください。

参考資料(執筆時点で参照): Nemotron Bolt の構成は Artificial Analysis のモデルページ、ApX のモデルページ、DataLearner の比較ページ、NVIDIA NeMo AutoModel のモデルページ。

著者・監修者

Yusuke Ishihara

Yusuke Ishihara

13歳でMSXに触れプログラミングを開始。武蔵大学卒業後、航空会社の基幹システム開発や日本初のWindowsサーバホスティング・VPS基盤構築など、大規模システム開発に従事。 2008年にサイトエンジン株式会社を共同創業。2010年にユニモン株式会社、2025年にエニソン株式会社を設立し、業務システム・自然言語処理・プラットフォーム開発をリード。 現在は生成AI・大規模言語モデル(LLM)を活用したプロダクト開発およびAI・DX推進を手がける。