NVIDIA Blackwell (GB10) 上でオンプレLLM 6モデルをClineで実務タスク比較：起動・ツール呼び出し・到達と合格を分けて検証

「起動した」だけでは仕事を任せられない

モデルを動かす仕組みがエラーなく立ち上がり、API（Clineなどの外部ツールからLLMを呼び出す窓口）が応答し、短い文章を生成できれば、接続の確認としては前進です。しかし、それはAIエージェントとして仕事を任せるための入口にすぎません。

Clineで仕事を進めるには、通常の会話に加え、AIが必要なツールを呼び出す機能（Tool Calling）が働く必要があります。複数回の操作をつなげ、許可された範囲に成果物を残すことも必要です。その後にも、テストなどによる機械の確認と、人による内容確認が残ります。

起動・API応答

↓

通常チャット

↓

ツール呼び出し

↓

実務タスク

↓

機械による確認

↓

人による内容確認

前の段階を通ったからといって、次の段階も通るとは限りません。APIが応答しても、通常チャットの返答内容が条件を満たすとは限りません。通常チャットが成立しても、ツール呼び出しや実務タスクはまだ確認できていません。実務タスクを最後まで実行できても、設定した合格条件を満たしたかは、別に確認する必要があります。

今回確認したのは、使用した構成がこの実機で動作したという事実です。ハードウェアの製造元や、モデル・ソフトウェアの開発元が、そのモデルと実行環境の組み合わせを正式な対応対象として公表しているかは、公表資料などで別に確認する必要があります。また、今回の短時間の検証では、長時間使った場合の安定性までは確認していません。

共通の12実務タスクで6モデルを比較

6モデルは、同じ日時に一括実行したものでも、完全に同じ条件で実行したものでもありません。取得時期に加え、モデル内部の数値の扱い方、モデルを動かすソフトウェア、主要設定にも違いがあります。

一方、すべてのモデルで共通の12実務タスク（T01〜T12）を使い、同じ形式の入力と同じ考え方で結果を判定しました。6モデルはいずれも、少なくとも1つの構成で12の実務タスクを実行しました。このため、本稿では、同一条件での性能順位ではなく、共通の評価項目で確認した6モデルとして比較します。

vLLMとSGLangは、モデルをサーバー上で動かすためのソフトウェアです。開発元配布版のvLLM（upstream vLLM）は、vLLMの開発元が配布した版を指します。NVFP4、FP8、BF16は、モデル内部の数値の扱い方を区別する名称です。同じモデルでも、数値の扱い方やモデルを動かすソフトウェアの組み合わせによって、今回確認できた段階が変わる場合がありました。

次の表では、各モデルについて、Clineを使った12の実務タスクを実行できた構成と、途中で止まった構成を整理します。結果はモデル単体ではなく、構成ごとに確認する必要があります。

なお、「12の実務タスクを実行できた」ことと、「12件すべてが合格条件を満たした」ことは同じではありません。ある構成で途中停止した場合も、そのモデル全体が使えないという意味ではありません。

なお、後発のQwen3.8-Flash-Nextでは、NVIDIA版に先行して公開されたRadixArk/Qwen3.8-Flash-Next-NVFP4を現在Clineで利用しています。ただし、これは本稿の6モデル比較とは別の運用上の利用であり、比較結果には含めていません。

比較条件の違いとして、Ornithは後から追加しました。確認には同じ12の実務タスク、同じ形式の入力、同じ判定方法を使いました。Ornithの確認では、モデルを動かすソフトウェアに対応する実行環境として、既存検証で固定したものを再利用しました。ただし、機器を制御するソフトウェアやGPU周辺の部品まで、すべて同じ状態だったことまでは確認していません。

同じモデルでも、動かし方によって結果は変わった

今回の検証では、同じモデルでも、数値の扱い方やモデルを動かすソフトウェアが異なる構成は分けて記録しました。モデル名だけでは、どの段階まで進んだ結果なのかを区別できないためです。

Qwen3.5とQwen3-Coder-Nextは、それぞれSGLangを使った構成で12の実務タスクを実行しました。Qwen3.8（FP8 / BF16）は、FP8とBF16の両構成で、それぞれ12の実務タスクを実行しました。この2構成は合算せず、24件の総合成績にはしませんでした。FP8とBF16では条件が異なるため、結果も別々に確認しました。

Devstralは、SGLangを使った構成ではモデルの読み込み段階で停止しましたが、開発元配布版のvLLMを使った別の構成では12の実務タスクを実行しました。途中で停止した一つの構成だけから、Devstral全体が使えないとはいえません。反対に、一つの構成で実行できたことから、どの構成でも実行できるともいえません。

Nemotronは、構成によって通常応答やツール呼び出しの段階で停止しました。一方、開発元配布版のvLLMを使った別の構成では12の実務タスクを実行しました。

Ornith（NVFP4 / BF16）では、3つの構成でそれぞれ12の実務タスクを実行しました。別の1構成は、通常チャットの段階で停止しました。

モデルに「使える」「使えない」という評価を一つだけ付けるのではなく、構成ごとに、どの段階まで進み、どこで止まったかを記録しておくと、どの条件で得た結果かを後から確認しやすくなります。

最後まで実行できても、すべてが「合格」とは限らない

6モデル比較では、「タスクを最後まで実行できたか」と「決めた合格条件を満たしたか」を分けました。「結果未確定」とは、決めておいた判定方法では、合格とも不合格とも決められなかった状態です。その場合は、合格・不合格のどちらにも決めず、「結果未確定」としました。

一例として、Ornith（NVFP4 / BF16）では、事前確認を通った3つの構成で、それぞれ12の実務タスクを最後まで実行しました。ただし、各構成とも、12件を実行し、8件が合格条件を満たし、4件は「結果未確定」となりました。別の1構成は通常チャットで停止したため、12の実務タスクの「不合格」として数えず、その前の段階で停止した構成として整理しました。

同じ考え方はQwen3.5、Qwen3-Coder-Next、Qwen3.8にも適用しました。12の実務タスクを実行できたことだけを理由に、12件すべてが業務要件を満たしたとは結論づけませんでした。Qwen3.8（FP8 / BF16）の2構成も、Ornith（NVFP4 / BF16）の3構成も、結果をまとめて一つの成績にはしませんでした。どの構成で得た結果か分かるよう、構成ごとに記録しました。

モデルをまたいだ平均や総合成功率も作りませんでした。取得時期や構成の違いに加え、タスクを実行できたことと合格条件を満たしたことが、一つの数字に混ざってしまうためです。

導入可否を検討するときは、「どの段階まで進んだか」「タスクを最後まで実行できたか」「合格条件を満たしたか」「結果未確定だったか」を分けて整理すると、検証の進み具合と採否判断を区別しやすくなります。

機械で通っても、人が見ると残る問題がある

一例として、OrnithのNVFP4 + vLLM構成で実行した同じ1つのタスクを、機械と人の両方で確認しました。

これは、機械による確認が間違っていたという意味ではありません。機械は、成果物と、機械で確認するよう定めた条件を見ています。人は、資料をどこまで読んだか、指定された順序で作業したか、最終報告が実態と合っているかを見ています。確認する問いが違うため、両方の結果が同時に成立します。

AIエージェントは、最終ファイルだけを見れば条件を満たしていても、必要な資料の一部しか参照していなかったり、実際に行ったことより強い完了報告を返したりする場合があります。とくに、長い仕様書、多数の制約、順序のある作業を任せる場合、成果物のテストだけで作業の進め方まで確認したことにはできません。

本検証では、成果物、構造、テストのように機械で確かめられるものは機械で確認し、資料を読んだ範囲、指定工程、最終報告との整合は人が確認しました。機械による確認だけで「すべて問題ない」と受け取らないためにも、人が確認する範囲をあらかじめ決めておくと、両者の役割を分けやすくなります。

業務利用前に確認したいこと

今回の結果を実際の利用環境に当てはめるときは、モデル名や一度の応答だけで採否を決めず、少なくとも次の項目を分けて確認すると、どこまで確かめられているかが分かります。

• 使用したモデル、モデル内部の数値の扱い方、モデルを動かすソフトウェア、主要設定を記録しているか。
• 起動、API応答、通常チャット、ツール呼び出し、実務タスクを、別の確認段階として扱っているか。
• タスクを実行できたことと、合格条件を満たしたことを別に記録しているか。「合格」「不合格」「結果未確定」を分けているか。
• 実際の業務に近いタスクで、成果物、変更箇所、テスト結果を機械で確認しているか。
• 必要な資料をどこまで読んだか、禁止事項を守ったか、指定された順序で作業したか、最終報告が実態と合うかを、人が確認しているか。
• ファイルやツールの権限、影響の大きい操作の承認を、AI自身の申告だけに任せていないか。
• 今回の実機で動いたことと、ハードウェアの製造元や、モデル・ソフトウェアの開発元が正式な対応を公表していることを分けて確認しているか。長時間運用が必要なら、短時間の検証とは別に安定性を確認する計画があるか。

これらは、特定のモデルを推すための項目ではありません。問題が起きたときに、モデルの読み込み、接続、文章生成、ツール呼び出し、タスク実行、成果物、作業の進め方のうち、どこを確認すべきかを考えるための項目です。

AIにどこまで操作を許すかは、指示文だけでなく、システム側の権限設定でも制限します。影響の大きい操作には人の承認を入れ、最後に変更箇所とテスト結果を確認します。モデルの能力評価と運用上の安全策は、分けて考える必要があります。

今回の検証結果を読むうえでの注意点

今回の結果は、NVIDIA Blackwell GB10（128GB統合メモリ）を搭載したDGX Spark互換機と、今回使用したモデル・設定で得られたものです。また、6モデルは取得した時期や構成も完全には同じではありません。そのため、以下の点に注意して結果を見る必要があります。

• 今回の結果は、6モデルの単体ランキングを示すものではありません。ある構成で得た結果を、そのモデル全体の評価とはしていません。
• 今回の構成差は、vLLMとSGLangの一般的な優劣を示すものではありません。
• 今回の結果は、NVFP4、FP8、BF16の一般的な品質順位を示すものではありません。
• ハードウェアの製造元や、モデル・ソフトウェアの開発元による正式な対応状況は、今回の実機動作とは別に、公表資料で確認する必要があります。
• 長時間の連続運用、長い会話履歴、継続的なツール利用、障害後の復旧は、今回の確認対象に含めていません。
• より複雑な仕様書や、多くの制約・工程をまたぐ作業は、今回の確認範囲に含まれていません。
• 今回使った事前確認が、ほかのモデルやモデルを動かすソフトウェアにもそのまま当てはまるかは、本検証の対象外です。

これらは、今回確認した範囲を読み違えないための注意点です。モデル、モデル内部の数値の扱い方、モデルを動かすソフトウェア、主要設定を変更した場合は、影響する段階も再確認の対象になります。

検証結果を、実際の導入判断につなげるために

今回の6モデル比較で特に重視したのは、「動く」を一つの言葉で済ませないことでした。起動とAPI応答は入口です。その先にある通常チャット、ツール呼び出し、実務タスク、機械による確認、人による内容確認を分けると、どの構成で、どの段階まで仕事を任せられるかが具体的になります。

Qwen3.5、Qwen3-Coder-Next、Qwen3.8、Devstral、Nemotron、Ornithでは、いずれも少なくとも1つの構成で12の実務タスクを実行しました。一方、DevstralとNemotronでは別の構成が途中で停止し、Ornithでも別の1構成が通常チャットの段階で停止しました。

さらに、12の実務タスクを最後まで実行できたことと、合格条件を満たしたことは同じではありません。機械による確認と人による内容確認も別です。これらを分けた結果は、どの候補を次の検証へ進めるかを検討する材料になります。

有償PDF冊子と付属資料では、実際の利用環境で同様の検証と判断を進めるための確認手順や判断材料を整理する予定です。具体的には、次の項目を扱う予定です。

• 6モデルの結果を、使用したモデルと構成ごとに確認する方法。
• 12の実務タスクで何を確かめ、どの条件なら合格とするか。
• 途中で止まった段階から、次に確認する設定、モデルを動かすソフトウェア、成果物を切り分ける方法。
• 機械による確認と人による内容確認を分け、導入候補を「採用」「条件付き採用」「見送り」へ整理する方法。
• 利用環境で使用したモデル、モデル内部の数値の扱い方、モデルを動かすソフトウェア、主要設定を記録し、更新後に再確認する方法。