いや･･･ホントに真面目にそう感じた話し。最後は「フォグ」で〆めてます。
はじめに
9月のスマート工場EXPO（ネプコンジャパン）に展示したDell Pro Max with GB10 に関する書き殴りブログです。これまで（ここ1年ぐらいボチボチと）、ローカル LLM のベンチマークをいろいろとやってきてましたが、今回は用途を決めての具体的なベンチマークを実施したのでその結果の一部を公開したいと思います。
ベンチマークの目的
製造現場で使う、工場内で使えるインカムAIエージェントをGB10で動かすなら「どのモデルを選んで、どう設定するのが正解か？」これを実機で確かめるための計測を行いました。
まず、巷で「高性能だ！」と言われる7モデルを揃えるところから始めて、小さいモデルに替え、東京科学大学とかが公開している日本語強化版も試してみました。
計測方法としては、実際の同時接続を想定したパラメータ設定や、混雑させた状況、最後に3段直列で通したりという本格的なモノになっています。
最初に結論
意外なことに8回測って、モデル選定の結論はそんなに変動しませんでした。gpt-oss:120b を think:"low" で使うというのが割と早い段階で出た話しでその確定作業という意味合いがベンチマークの中身になっています。
ただし先に釘を刺しておきます。**ここでいう「最強」は速さの話ではありません。**速度だけなら gpt-oss:20b が全指標で上回ります。120b が勝ったのは「日本語で前提を踏まえて、分からないときに黙る、回答シチュエーションをわきまえる」という一点です。ここを混ぜて読むと、この記事は目的から外れてしまうので注意して読んでください。
面白かったのは、8回のうち何度も直感と逆の結果が出たことでした。この記事はその5つを軸に書きます。
測定環境と条件
数字を出す前に条件を置きます。ここを落とすと再現できない記事になるので、最初に全部書きます。
| 項目 | 値 |
|---|---|
| GPU | NVIDIA GB10（Blackwell） |
| CPU | Cortex-X925 ×10 + Cortex-A725 ×10（20コア／aarch64） |
| メモリ | 121 GiB 統合メモリ（LPDDR5x） |
| メモリ帯域 | 273 GB/秒（メーカー公開値） |
| 電源 | 240 W（GB10 の TDP は 140 W） |
| OS | Ubuntu 24.04.4 LTS / カーネル 6.17.0-1031-nvidia |
| ドライバ / CUDA | 580.173.02 / 13.0 |
| 推論エンジン | Ollama 0.33.2（arm64） |
推論のパラメータは全回で揃えています。
seed 42
temperature 0
num_ctx 4096
think "low"（gpt-oss 系）/ false（qwen3 系）
seed 42 と temperature 0 なので、同じプロンプトなら出力は完全に同じです。だから逆説4に出てくる 17 / 13 / 18 という点数の差は、渡したマスタの違いだけで生まれています。
なおこの機体は Arm です。 x86 用のバイナリは動きませんのでご注意ください。
逆説1：大きいモデルほど遅いという「思い込み」が外れる
まず5モデルを同じ条件で流しました。入力55トークン、生成256トークン。
| モデル | 構造 | 総／活性化 | 載った量 | 生成 tok/s | 最初の1文字 | 電力 |
|---|---|---|---|---|---|---|
| qwen3:30b-a3b | MoE | 30B / 3B | 45 GB | 89.16 | 0.101 秒 | 38 W |
| gpt-oss:120b | MoE | 117B / 5.1B | 65 GB | 44.08 | 0.356 秒 | 41 W |
| qwen3:8b | 密 | 8B | 11 GB | 43.08 | 0.068 秒 | 45 W |
| qwen3:32b | 密 | 32B | 30 GB | 10.01 | 0.188 秒 | 41 W |
| llama3.3:70b | 密 | 70B | 85 GB | 4.86 | 0.347 秒 | 42 W |
図 モデル別の生成速度。117B の MoE が 8B の密モデルを上回った
117B の gpt-oss:120b が、8B の qwen3:8b より速い。 44.08 対 43.08 で、わずかですが上回りました。
逆説2：いちばん速いモデルが、いちばん挙動が怪しかった
速度で並べても仕方がないので、用途そのもので採点しました。工場のインカム音声を想定した10問を投げて、22点満点で専用のGraderを作って採点しています。
| モデル | モード | 合計 | うち「推測してはいけない」問 | 判断到達（秒） |
|---|---|---|---|---|
| gpt-oss:120b | think:"low" | 17/22 | 4/4 | 2.2〜4.1 |
| gpt-oss:20b | think:"low" | 14/22 | 3/4 | 1.2〜5.1 |
| gpt-oss:120b | think（既定） | 14/22 | 3/4 | 5.4〜14.6 |
| qwen3:8b | think:false | 11/22 | 0/4 | 0.9〜1.6 |
| qwen3:30b-a3b | think:false | 3/22 | 0/4 | 4.7〜11.3 |
| gpt-oss-swallow:20b | think | 2/22 | 0/4 | ほぼ返らない |
図 インカム想定の問いを採点した結果。22点満点
効いてきたのが「推測してはいけない」問でした。 こういう評価をちゃんとやらないと会話のなかで「事故る ＝ AIが嘘を言う」になってユーザがゲンナリしちゃいますよね。
まとめ
8回の検証を経てもモデル選定の結論はブレませんでした。採用モデルは gpt-oss:120b （think:"low"） です。
しかし、それ以上に収穫だったのは、検証の過程で得られた以下の知見です。
-
「処理速度」と「実用性」の順位は一致しない
- 最も高速なモデル が、存在しない値を「確度 HIGH」で返してくるケースがありました。
-
設定ひとつで処理時間が 23 倍変化する
- 43.5 秒かかっていた処理が 1.9 秒まで短縮されました(設定は大変)。
-
プロンプトの記述方法だけでスコアが 5 点動く
- 情報を単に増やすと精度が下がり、構造を整理し直すことで過去最高スコアを記録しました。
カタログスペックや公開ベンチマークだけでは、これらの事実は決して見えてきません。「実機を使い、自身のユースケースに沿った問いを投げて計測するしかない」。
結局･･･これが 8 回の検証から得た最大の結論ですね。
おわりに
このGB10を現場に置いて何をするつもりか
ここまでは実測データに基づくお話でした。最後に、これから検証予定の構想について 1 点だけ触れておきます（数値検証はこれからです）。
GB10 は 150 mm 角の小型デバイスであり、サーバーラックだけでなく工場の制御盤横にも設置できるサイズ感です。今回の検証では、120b と 20b の両モデルを併置した状態でも、121 GiB 中 28.2 GiB の空きメモリが残りました。
弊社（PROMPT-X）では普段、産業 IoT・OT 向けの時系列データ基盤を商用ソフトウェアとして開発＆販売しています。
具体的には「CLOUDSHIP®」が現場のOTデータ、具体的には PLC のセンサー値や設備データ、カメラ画像を同一の時系列データとして蓄積し、「RealBoard®」がそれをノーコードで可視化・分析する構成です（弊社では詳細分析画面とも呼んでいます）。
この時系列DBやRealBoardと gpt-oss:120b は、非常に相性が良いと考えています。 理由は大きく 2 つあります。
-
データ保持に上限を設けていない点
CLOUDSHIP はデータ点数やレコード数に制限がありません。何点でも何レコードでも同じライセンス価格で利用できます（通常の商用DBは従量制）。フィジカル AI が扱うべきなのは、設備が出力した生のデータの並びそのものです。データを限らず＆削らず･･･すべて残せることが前提条件となります。 -
120b が「分からないときに正しく"分からない”と答える」点
今回の検証で最も重要だと感じた特性です（逆説 2）。現場のデータには欠損や外れ値、データの定義自体が変わる区間が日常的に存在します。勝手な補完を行うモデルを採用すると、基盤側がどれほど正確にデータを保持していても出力精度が担保できなくなります。「蓄積側がすべてを残し、思考側が妄想で補わない」という関係性が揃って初めて、現場に AI を置く価値が生まれます。
AIデータセンターとIoTのデータセンターを現場で統合できる
クラウド利用や送信を前提とすると以下の 3 つの課題が一般的には生じやすくなります。
-
各種制限によるデータの間引き
- 従量制が前提となる「サーバレス環境」では間引きが必須となり、生データが現場に残されたまま捨てられる。
-
画像データ送信の限界
- 容量の大きいカメラ画像を 短い周期で全件クラウドに送信するのは現実的でない。
- CLOUDSHIP＆RealBoardは画像データも時系列データとして処理できます！
-
通信障害による停止リスク
- ネットワークやクラウド障害が発生すると、分析・思考プロセス全体が停止する。
フィジカルAIには時系列データが必要だ！
小型エッジサーバ内に時系列データ基盤と 117B 規模のモデルを同居できれば、これら 3 つの課題を一挙に解決できます。「蓄積・可視化・思考」の全プロセスが現場のエッジ内で完結するためです。
特にフィジカル AI では、出力結果の受け手は人間だけでなく設備や搬送台車（AGV）やロボットになるため、クラウドとの往復遅延や断絶が直接制御の遅れに直結します。エッジ完結型の価値が最も発揮されるのはまさにこの部分かもしれないと考えています。
時系列DBのCLOUDSHIP や RealBoardで現場のエンジニアが自分で作った画面情報をコンテキストとして生成AIが活用して、現場で働く方々や設備やロボットと協働する世界が実現できそうな妄想に至っています。
もちろんクラウドとの連携が最適（フォグ構想の再来！？）
とはいえ、現実的はクラウドと組みあせたり、クラウド上にデプロイされている「フロンティモデルのLLM」と連携するのが現実的な使い方だと思います。
これってちょっと前に流行った「フォグ」なのかもしれませんね。