Jetson Orin Nano Super、EVO-X2、DGX Spark、NUC11でLlama 3.2 3BのOllama性能を比較してみた

ちょっと前まで、仮想環境とクラウド環境の仕事をしていたが、バッサリ仮想環境の仕事は止めた。というか縁がなくなった。多分次にお声がかかるのは、10年後くらいかと思っている。その時現役で働いているかどうかは不明だが。別にVMwareが嫌いとかというわけでもない。自分がVMwareにいた時はとてもいい会社だった。しかし、これだけ機材が高騰すると、仮想環境以前に、ハードウェアをオンプレに持つ意味がどうなるのか?クラウドの選択肢も出てくる。ただし、ここまで円安だと果たして、クラウドが安いのか?混迷を極める。技術ではなく状況が改善しないと前に進まないかもしれない環境を変えたかった。(ということにしておく。)
 
一方、AIを始めたのが大きい。ちょっと邪な考え(想像にお任せしますが)で始めたAIが結構奥が深い。さらにDockerコンテナベース。よくよく考えると、Dockerのほうが1ホストにアプリが詰め込める上にメンテナンス性は仮想環境と比較にならないくらい高い。アップデートも簡単。よくセキュリティ要件で「アップデートしなきゃならないが、簡単にはできない」という話があるが、仮想マシン単位で長期間育てる運用も、その原因の一つなんじゃないかと思う。
仮想環境自体は手元から無くなったのではなく、簡単にLinuxイメージがプルできて、OSインストール、メンテナンスが不要なIncusから使っている。AWS EC2で使えるようなcloud-initもサポートしているのが理由。なので、Proxmoxも使っていない。Proxmoxは、ESXiを夢見たKVM環境でしかないので。(ESXiの代用なら選択肢としてはありだが。安くなるかどうかは別として、商用ならNutanix AHVのほうが安全。個人的見解)
 
 
閑話休題
 
 
前の記事でOS環境をセットアップして、Mini DGX Spark的な(あくまでも的な)部分ができたので
 
今回使ったJetsonは8GB版のOrin Nano Superである。JetPack 7.2.1、CUDA 13.2環境を構築し、Ollamaをネイティブインストールした。インストール方法は、ネイティブでもDockerでも構わない。普通にインストールあるいは、普通にDocker/Docker Composeで立ち上げる。(インストール方法は割愛)
 
 
OllamaのインストーラからはJetPackのバージョンについて警告が表示されたものの、実際にはCUDA 13用バックエンドからOrinが正常に認識された。
ollama psでも、
llama3.2:3b 2.6 GB 100% GPU 4096
となり、GPUへの100%オフロードを確認できた。
 
ここまで来ると、単に「Jetsonで動いた」で終わらせるのはもったいない。
手元にはAMD Ryzen AI Max+ 395を搭載したGMKtec EVO-X2とNVIDIA DGX Sparkがある。また、従来型の小型サーバを代表する比較対象としてCore i7搭載NUC11もある。
 
そこで4台で、同じOllama、同じLlama 3.2 3B、同じプロンプトを使って比較することにした。

ベンチマーク条件

モデルはすべて、
llama3.2:3b
を使用した。
 
Ollamaでモデル情報を確認すると、
architecture llama
parameters 3.2B
context length 131072
embedding length 3072
quantization Q4_K_M
である。
 
測定前には短いプロンプトを一度実行し、モデルをロードしてウォームアップした。
ollama run llama3.2:3b “hello”
その後、新しい対話セッションを開始する。
ollama run llama3.2:3b
詳細な性能値を表示させるため、
/set verbose
を指定した。
 
ベンチマーク用プロンプトは以下で統一した。
日本の四季について、春・夏・秋・冬それぞれの特徴、気候、食文化、行事、旅行の楽しみ方を含めて、2000文字程度で詳しく説明してください。途中で要約せず、最後まで連続して説明してください。
 
LLMの出力内容や出力トークン数は毎回変化する。そのため総実行時間そのものではなく、主としてOllamaが最後に表示する eval rate、すなわち生成速度を比較することにした。

 

Jetson Orin Nano Super

まずMini DGX Spark的なJetson Orin Nano Superである。
 
Jetsonには nvpmodel という電力・性能プロファイルを切り替える仕組みがある。
 
今回の環境では、
ID 0 = 15W
ID 1 = 25W
ID 2 = MAXN_SUPER
となっていた。デフォルトはID 1 = 25Wモード
 
MAXN_SUPERを指定するには、
sudo nvpmodel -m 2
を実行する。
さらに、
sudo jetson_clocks
を実行すると、現在のnvpmodelで許されている範囲内でCPU、GPU、EMCなどを高クロックに固定できる。
 
Jetson Orin Nanoが「オラに元気を分けてくれ」状態になる。
 
今回のMAXN_SUPERでは、
CPU 1728 MHz
GPU 1020 MHz
EMC 3199 MHz
となった。
 
実際の動作状態は、
sudo tegrastats
で確認した。
 
LLM生成中はGPU使用率がほぼ95~100%となり、VDD_IN は約20Wで推移した。
 
ベンチマーク結果は、
prompt eval count: 94 token(s)
prompt eval cached: 20 token(s)
prompt eval duration: 110.442ms
prompt eval rate: 670.03 tokens/s
eval count: 465 token(s)
eval duration: 20.890955s
eval rate: 22.26 tokens/s
となった。
 
別の短い質問でも、
eval rate: 22.46 tokens/s
であった。
 
したがって今回の環境では、Llama 3.2 3B Q4_K_Mの生成速度はおおむね22 tokens/sec前後と考えてよい。なお、25Wモードで動的クロックを使用したときには約20.5 tokens/secであった。
MAXN_SUPERまで引き上げても約20.5から22 tokens/sec程度への向上である。常時稼働させるのであれば、25Wモードの方が電力効率はよさそうである。

NVIDIA公称43 tokens/secとの違い

NVIDIAはJetson Orin Nano Superについて、Llama 3.2 3Bで43.07 tokens/secという数字を公開している。今回の約22 tokens/secとはかなり違う。
しかし、NVIDIAの数字はOllamaではない。NVIDIAのベンチマークはMLC APIとINT4量子化を使用している。今回のOllama + Q4_K_Mとは実行ランタイムも量子化方式も異なる。
つまり、
Llama 3.2 3B
├─ Ollama / Q4_K_M
│ → 今回 約22 tok/s
└─ MLC API / INT4
→ NVIDIA公称 43.07 tok/s
という関係である。
「Jetsonが公称性能の半分しか出ていない」という話ではなく、そもそも別のソフトウェアスタックによる測定値なのである。

 

DGX Spark

次はDGX Sparkである。
 
同じLlama 3.2 3Bを同じプロンプトで実行した結果は、
total duration: 16.155100644s
load duration: 1.954622ms
prompt eval count: 94 token(s)
prompt eval duration: 19.317ms
prompt eval rate: 4866.18 tokens/s
eval count: 1564 token(s)
eval duration: 16.131057s
eval rate: 96.96 tokens/s
となった。
 
生成速度は96.96 tokens/secである。
Jetsonの約22.3 tokens/secに対して、およそ4.3倍である。
 
さらに目立つのがprompt evalである。
4866.18 tokens/s
という非常に高い値が出た。
生成速度だけでなく、大量の入力トークンを処理するprefill性能にもDGX Sparkの特徴が現れている。

 

EVO-X2 Vulkan版

次はRyzen AI Max+ 395、Radeon 8060S、128GB UMAを搭載したGMKtec EVO-X2である。
 
まず通常のOllamaイメージ、Vulkanバックエンドで測定した。
 
1回目は、
prompt eval rate: 1021.28 tokens/s
eval rate: 89.38 tokens/s
となった。再測定すると、
total duration: 16.916532028s
load duration: 1.050172ms
prompt eval count: 94 token(s)
prompt eval cached: 20 token(s)
prompt eval duration: 72.929ms
prompt eval rate: 1014.69 tokens/s
eval count: 1511 token(s)
eval duration: 16.835235s
eval rate: 89.75 tokens/s
となった。
 
89.38と89.75 tokens/secなので、生成性能はかなり安定している。
ここで驚いた。
DGX Sparkが96.96 tokens/secなのに対して、EVO-X2は89.75 tokens/secである。
つまり、3B Q4_K_Mという比較的小さなモデルでは、EVO-X2はDGX Sparkの約92.6%の生成速度を出している。

 

EVO-X2 ROCm版

EVO-X2では、さらに ollama-rocm でも測定した。
結果は、
total duration: 13.362704056s
load duration: 1.668095ms
prompt eval count: 94 token(s)
prompt eval cached: 20 token(s)
prompt eval duration: 45.673ms
prompt eval rate: 1620.21 tokens/s
eval count: 1049 token(s)
eval duration: 13.312807s
eval rate: 78.80 tokens/s
となった。これは非常に興味深い結果である。
 
通常のVulkan版では、
Prompt eval 約1,015 tok/s
Decode 89.75 tok/s
だったのに対し、ROCm版では、
Prompt eval 1,620 tok/s
Decode 78.80 tok/s
となった。
 
ROCm版はVulkan版に対してprompt evalが約60%高速になった一方、生成速度は約12%低下した。
単純に「AMD GPUだからROCmを使えば速い」という結果にはならなかったのである。
今回のモデルでは、
Vulkan
→ 生成速度が速い
 
ROCm
→ 入力処理が速い
という性格の違いが現れた。
短いプロンプトを入力して長い回答を生成させるチャット用途ではVulkan版が有利である。
一方、大量のコンテキストやRAGのように入力トークン数が非常に多い用途では、ROCm版の高いprompt eval性能が効いてくる可能性がある。
同じハードウェアでも、バックエンドによって性能特性がこれだけ変化するのは面白い。

 

NUC11 Core i7でCPU推論

最後にCore i7搭載NUC11でも同じモデルを実行した。
こちらはGPUによるLLMアクセラレーションではなく、CPU推論である。
結果は、
total duration: 2m34.352490745s
load duration: 3.936679ms
prompt eval count: 94 token(s)
prompt eval cached: 20 token(s)
prompt eval duration: 1.959456s
prompt eval rate: 37.77 tokens/s
eval count: 1009 token(s)
eval duration: 2m32.386487s
eval rate: 6.62 tokens/s
となった。
生成速度は6.62 tokens/secである。
ここまで来ると、GPUを使った3台との差はかなり大きい。

 

全部並べてみる

今回の結果をまとめると以下となる。
マシン / バックエンド
Prompt eval
Generation
NUC11 Core i7 / CPU
37.77 tok/s
6.62 tok/s
Jetson Orin Nano Super / CUDA
約670 tok/s
約22.3 tok/s
EVO-X2 / ROCm
1,620 tok/s
78.80 tok/s
EVO-X2 / Vulkan
約1,015 tok/s
89.75 tok/s
DGX Spark / CUDA
4,866 tok/s
96.96 tok/s
 
NUC11のCPU推論を1とすると、生成速度はおおむね、
NUC11 CPU 1.0x
Jetson 3.4x
EVO-X2 ROCm 11.9x
EVO-X2 Vulkan 13.6x
DGX Spark 14.6x
となる。
 
この数字を見ると、それぞれのマシンの性格が非常にはっきりする。

 

CPU推論はそろそろ限界か

今回、個人的にかなり印象的だったのがNUC11である。Llama 3.2 3Bという、現在ではかなり小さなモデルでさえ、
6.62 tokens/sec
である。
 
もちろん動く。。。
検証にも使える。。。
 
余っているNUCにOllamaを入れて遊ぶのであれば、今でも十分意味がある。
しかし、これからAI推論を目的として新しくCPU中心のNUCを買うかと言われると、かなーり微妙である。
特に今回のJetsonとの比較が分かりやすい。
NUC11 Core i7 6.62 tok/s
Jetson 約22.3 tok/s
 
Jetson Orin Nano SuperはNUC11 CPU推論の約3.4倍である。
しかもLLM生成時のJetsonの入力電力は約20Wであった。
JetsonはDGX SparkやEVO-X2と比較すると遅く見える。しかし、従来の小型x86マシンによるCPU推論と比較すると、きちんとAIアクセラレータを搭載した機械なのである。

ではNUCはもう不要なのか

もちろん、そういう話ではない。NUCにはNUCの仕事がある。
既存のNUCにメモリとSSDを追加して、
Incus
仮想マシン
Docker
DNS
Proxy
監視
各種ホームラボサービス
などを動かす仮想化・コンテナ基盤として使うのであれば、現在でも非常に便利である。
x86-64なのでソフトウェア互換性も高く、64GB程度のメモリを積める機種ならホームラボの汎用サーバとして使いやすい。
 
つまり、
既に持っているNUCをサーバとして使う価値は十分にある。
問題は、
AI推論を主目的として、これから新たにNUCを買うか
である。
 
今回の結果を見る限り、その用途ならNUCよりJetson Orin Nano Superを選ぶ方が合理的である。
CPU推論6.62 tokens/secに対してJetsonは約22 tokens/secであり、CUDAやTensorRTも利用できる。
さらにJetsonはLLMだけでなく、カメラ映像解析、画像認識、音声処理などのエッジAI用途にも向いている。
 
従来、
「小型の常時稼働マシンが欲しいのでNUCを買う」
という選択肢があった。
現在は用途がAIなら、
「それ、Jetsonでよくないか」
 
という場面がかなり増えているのである。

 

少し脱線だがEVO-X2 70万円、DGX Spark 100万円ならどちらか

今回の実測値を、仮に現在価格を、
EVO-X2 70万円
DGX Spark 100万円
として考えてみる。
 
Vulkan版EVO-X2とDGX Sparkの生成速度は、
EVO-X2 89.75 tok/s
DGX Spark 96.96 tok/s
である。
 
EVO-X2はDGX Sparkの70%の価格で、今回のモデルでは約92.6%の生成性能を出したことになる。
 
単純な1万円あたりの生成速度では、
EVO-X2 約1.28 tok/s / 万円
DGX Spark 約0.97 tok/s / 万円
となる。
 
したがって、今回のベンチマークだけを見るなら、70万円になったEVO-X2でも十分に競争力がある。
ただし、ここでもprompt evalを見ると話が変わる。
最も高速だったEVO-X2 ROCm版でも、
EVO-X2 ROCm 1,620 tok/s
DGX Spark 4,866 tok/s
である。
 
DGX Sparkは約3倍速い。
Vulkan版との比較なら約4.8倍である。
 
長大なコンテキスト、RAG、大量のドキュメント入力などでは、この差が体感性能に影響する可能性がある。
また、DGX Sparkの価格にはCUDAを中心としたNVIDIAのAIソフトウェアエコシステムを利用できるという価値も含まれている。
 
したがって、
ローカルLLMをコスト効率よく動かす
→ EVO-X2
 
CUDAを含めてAI開発を行う
→ DGX Spark
という違いになる。

 

4台は競合しているようで、実は役割が違う

今回の結果を見ると、4台の役割はかなり明確である。
NUC
└─ 仮想化 / Docker / 汎用サーバ
「普通のサーバ」
 
Jetson Orin Nano Super
└─ カメラ / 音声 / 軽量LLM / CUDA
「常時稼働エッジAI」
 
EVO-X2
└─ 128GB UMA / 高速ローカルLLM
「コストパフォーマンス型AIマシン」
 
DGX Spark
└─ 128GB unified memory / CUDA
「NVIDIA AI開発機」
 
NUCはAIマシンとして見ると厳しくなったが、汎用サーバとしての価値はまだ失われていない。
JetsonはEVO-X2やDGX Sparkほど速くないが、20W程度で常時動かせるAIノードとして非常に面白い。
EVO-X2は3BクラスではDGX Sparkに迫る生成性能を見せた。
DGX Sparkは生成速度だけならEVO-X2との差は小さいが、prompt evalでは大差を付けたうえ、CUDAを中心とするNVIDIAのソフトウェア環境を利用できる。
 
単純なtokens/secだけでは、4台の価値を比較できないのである。

 

まとめ

今回の結果は以下となった。
NUC11 Core i7 / CPU 6.62 tok/s
Jetson Orin Nano Super 約22.3 tok/s
EVO-X2 / ROCm 78.80 tok/s
EVO-X2 / Vulkan 89.75 tok/s
DGX Spark 96.96 tok/s
 
3Bモデルの生成性能では、EVO-X2 Vulkan版がDGX Sparkの約93%まで迫った。
一方、prompt evalではDGX Sparkが4,866 tokens/secを記録し、EVO-X2とは大きな差が付いた。
そして今回NUC11を追加したことで、Jetson Orin Nano Superの立ち位置もよく分かった。
JetsonはDGX Sparkの廉価版ではない。
20W程度でNUC11 CPU推論の3倍以上の生成速度を出し、CUDAを使った画像、音声、LLM処理を常時稼働させられるエッジAIコンピュータである。
既存のNUCにはメモリとSSDを積んで仮想化基盤として働いてもらえばよい。
 
しかし、AI推論のためにこれから小型PCを新規購入するのであれば、CPUだけで推論するNUCを選ぶ理由はかなり少なくなった。
AIならJetson、汎用サーバならNUCという役割分担が自然である。
 
そして、より大きなローカルLLMを動かすならEVO-X2かDGX Sparkである。
 
次は7B/8B、20B、70Bとモデルを大きくしてみたい。
3BではEVO-X2がDGX Sparkにかなり迫った。
モデルが大きくなったときにも同じ関係が続くのか、それともどこかでDGX Sparkが大きく引き離すのか。
そこが次の実験である。
 
あれっ、監視カメラはどこ行った?
 
あっ、暇を見つけて今後やる予定w

コメントする