GPU on KnightLiブログ

2026年4月のGPU選び：避けたいモデルと、より見やすいモデル

Mon, 27 Apr 2026 08:51:10 +0800

最近PCを組もうとしているなら、GPU選びでは「新しいかどうか」だけで見ないほうがいいです。2026年4月という時点では、すでにかなり買いにくくなっているカードもありますし、完璧ではなくても同価格帯の中ではまだ素直に選びやすいカードもあります。

今回は理屈を広げすぎず、型番をそのまま挙げていきます。

あまりおすすめしにくいモデル

1. `RTX 5060 Ti 8GB`

このカードの問題は、まったく使えないことではありません。問題は、8GB という容量がこの時点では少し中途半端になってきていることです。

軽めのオンラインゲームを 1080p 中高設定で遊ぶだけならまだ成立します。ですが、次のような方向に進むと弱点がかなり早く見えてきます。

新しめのAAAタイトル
より高いテクスチャ設定
1440p
AI推論、編集、制作作業との兼用

すでに RTX 5060 Ti を見ているなら、少し予算を削って 8GB にするより、最初から 16GB 版を選ぶほうが無難です。

短く言えば、

RTX 5060 Ti 8GB：あまりおすすめしにくい
RTX 5060 Ti 16GB：かなり見やすい

2. まだ高い旧世代カード、特に `RTX 3080 10GB` と `RTX 3070 Ti`

これらのカードは、性能がまったく通用しないわけではありません。ただ、いま買うとかなり微妙な位置に置かれやすいです。

消費電力は低くない
世代は古い
VRAMも余裕があるとは言いにくい
中古の出どころも複雑になりやすい

特に RTX 3080 10GB は、価格がまだ高いままだと「見た目は強いけれど、実際はあまりバランスが良くないカード」になりやすいです。

RTX 3070 Ti も同じです。絶対に買えないわけではありませんが、価格差が十分でないなら、もう少し新しいカードや、VRAMに余裕があるカード、あるいは消費電力とのバランスが良いカードを見たほうがたいてい納得しやすいです。

3. 出どころが不明な旧フラッグシップ、たとえば `RTX 3090` や `RTX 3080 Ti`

この2枚は欲しくなる理由がとてもわかりやすいです。

名前が強い
スペック上の性能もまだ悪くない
中古市場でよく見かける

ただし、本当に注意すべきなのは出どころです。

もし買うものが、

抜き取り品
修理歴あり
使用履歴がはっきりしない中古

であるなら、普通の新品カードよりリスクはかなり高くなります。RTX 3090 は 24GB VRAM が魅力ですが、発熱、電源まわり、個体の状態、過去の使われ方など、気にすべき点が新品カードよりずっと多いです。

自分が何を買っているのかをはっきり把握していないなら、こうした旧フラッグシップは気軽に手を出さないほうが無難です。

4. 価格が合っていない `RTX 5070`

RTX 5070 は、存在そのものが悪いカードではありません。ただし、価格が正しいことが前提です。

気まずくなりやすいのは、RTX 5070 Ti との差額があまり開いていないときです。そうなると、多くの人が買ったあとに微妙な気分になりやすいです。

よくある感覚はこうです。

5070 を買う：もう少し出せば 5070 Ti に届いた気がする
予算を足さない：それでも「少し足りない側」を買った感覚が残る

なので RTX 5070 は完全に候補外ではありませんが、価格が明確にうまいときだけ見るカード だと思ったほうがいいです。値付けが中途半端だと、理屈では正しくても実際にはあまり気持ちよく買えません。

比較的見やすいモデル

1. `RTX 5060 Ti 16GB`

中価格帯を見ているなら、このカードは 8GB 版よりずっと無難です。

理由は単純です。

同じシリーズ内で余裕がある
今後数年でVRAM不足にぶつかりにくい
ゲームと制作系を混ぜても扱いやすい

この価格帯で一番派手なカードとは限りませんが、「買ってすぐ後悔しにくい」カードではあります。

2. `RTX 5070 Ti`

予算を伸ばせるなら、現状では RTX 5070 よりこちらのほうが完成度の高い答えに見えます。

強みは、あらゆる場面で圧倒することではありません。ゲーム、解像度、そして使う年数のバランスを取りやすいことです。

特に向いているのは、

1440p 高設定を狙いたい人
何年か使いたい人
すぐにアップグレードを考えたくない人

もともと 5070 と 5070 Ti のあいだで悩んでいて、差額が極端でないなら、最初から 5070 Ti にしたほうが気持ちよく終わることが多いです。

3. ちゃんとした価格の新品カードは、古い高級カードより先に見る価値がある

中古GPUを掘り慣れていないなら、単純ですがかなり有効な考え方があります。

まずは普通の新品カードを優先する
出どころの複雑な旧ハイエンドは後回しにする

今の時点では、より現実的なのはたとえばこうです。

中価格帯の予算：まず RTX 5060 Ti 16GB
もう少し上：RTX 5070 Ti
RTX 5070 は価格が明らかに良いときだけ検討

名前が強そうだからといって、履歴の重い古いカードに最初から賭けに行く必要はあまりありません。

ひとことで言うなら

次のように覚えておくと早いです。

あまりおすすめしにくい：RTX 5060 Ti 8GB
価格次第で判断：RTX 5070
慎重に扱うべき：RTX 3080 10GB、RTX 3070 Ti、出どころ不明の RTX 3090 / RTX 3080 Ti
比較的見やすい：RTX 5060 Ti 16GB
予算が届くならより安心：RTX 5070 Ti

最後に

この時期のGPU選びでいちばん怖いのは、少し高く買うことではありません。見た目には問題なさそうなのに、実際に使うとずっと何か足りないと感じるカードを買ってしまうこと です。

後悔を減らしたいなら、RTX 5060 Ti 16GB と RTX 5070 Ti は比較的選びやすく、RTX 5060 Ti 8GB、価格が合わない RTX 5070、そして履歴の複雑な旧ハイエンドは先に消していくほうが楽です。

Ubuntu 26.04 LTS の GPU とハードウェア対応アップデート: CUDA、ROCm、DPC++、そして各種プラットフォームの変更

Sun, 26 Apr 2026 19:35:57 +0800

前の記事が Ubuntu 26.04 LTS のデスクトップ全体像だったとすれば、こちらはハードウェアと計算基盤まわりの補足版です。今回の 26.04 では、AI、GPU コンピューティング、プラットフォーム互換性に関わる項目が、メインアーカイブや正式サポートの範囲にかなり取り込まれています。

先に結論を言うと、今回の注目点は単なるデスクトップやカーネルの更新ではなく、Ubuntu が Intel、NVIDIA、AMD の GPU コンピューティングスタックを、より体系的にディストリビューションへ取り込み始めたことです。

1. Intel DPC++ と関連コンポーネントが Ubuntu Archive に追加

26.04 から、Intel のオープンソース oneAPI DPC++ コンパイラが Ubuntu Archive から直接利用できるようになり、SYCL コードのビルドに使えます。ランタイムには Intel GPU 向けアダプタも含まれます。

あわせて、次の関連コンポーネントも Ubuntu リポジトリで利用可能になりました。

oneDPL。DPC++ library として、より高生産性な開発 API を提供
oneDNN。dpclang-6 でビルドされており、Intel GPU 上で実行可能

つまり、すでに SYCL、ヘテロジニアスコンピューティング、あるいは Intel GPU 上の AI ワークロードを見ている人にとって、Ubuntu 上での導入経路がかなり素直になったということです。従来のように外部スタックを丸ごと別管理する必要が薄くなります。

実運用上の注意点として、Ubuntu はこれらの Intel GPU 関連機能を使うにはユーザーが render グループに属している必要があるとも明記しています。

2. NVIDIA CUDA toolkit も `apt` で直接導入可能に

多くの開発者や運用担当者にとって、これは今回の更新の中でもかなり実用的な変更でしょう。

26.04 から、NVIDIA CUDA toolkit を Ubuntu Archive から直接インストールできます。

`1`	`sudo apt install cuda-toolkit`

意味があるのは、単にセットアップ手順が少し減るという話だけではありません。

Ubuntu 向けにソフトウェアを配布する開発者にとっては、CUDA runtime への依存関係を宣言するだけでよくなり、実際のインストールや互換性管理は Ubuntu 側がディストリビューションレベルで面倒を見る形になります。CUDA が Ubuntu 上でよりネイティブなシステム機能に近づき、別管理の外部スタックとして抱え込む必要が減るわけです。

3. AMD ROCm 7.1.0 が Universe に追加

AMD 側では、Ubuntu Universe に ROCm 7.1.0 が入りました。

このライブラリ群が提供する主なものは次の通りです。

AMD GPU 向け AI 学習・推論のバックエンド基盤
機械学習および高性能計算向けのソフトウェア基盤

さらに Canonical は、ROCm 関連コンポーネントを自社の CI/CD パイプラインで継続的に検証していると述べています。autopkgtests に加えて、次のようなユーザー空間アプリケーションも対象です。

llama.cpp
pytorch
Blender
Lemonade Server

ここはかなり重要です。Ubuntu は単にパッケージを置いただけではなく、ROCm をメンテナブルなソフトウェアスタックとして扱い、継続的に検証していることを意味します。

4. 本当のポイントは 3 社の GPU エコシステムが同時に進んでいること

DPC++、CUDA、ROCm を並べて見ると、26.04 の方向性がわかりやすくなります。

Intel: SYCL / oneAPI 系の機能を公式リポジトリへ取り込む
NVIDIA: CUDA toolkit にディストリビューション管理の導入経路を与える
AMD: ROCm 7.1.0 を Universe に入れ、継続的な検証も行う

Ubuntu 上で次のような用途に触れる人ほど、この更新の意味を感じやすいはずです。

ローカル LLM 推論
GPU アクセラレーションを使った学習やファインチューニング
Blender、科学技術計算、HPC
複数の GPU プラットフォームをまたぐ開発環境

要するに、Ubuntu は「GPU ドライバが入る OS」から一歩進み、AI と GPU コンピューティングに必要なユーザー空間ソフトウェアスタックもより包括的に担うディストリビューションになりつつあります。

5. NVIDIA Dynamic Boost がデフォルトで有効化

25.04 以降、対応する NVIDIA 搭載ノート PC では Dynamic Boost がデフォルトで有効になっています。

仕組み自体はわかりやすく、システム負荷に応じて CPU と GPU の間で消費電力を動的に振り分けます。ゲーム用途では、必要なときに GPU へより多くの電力を回し、性能を引き上げる形になります。

ただし有効になる条件は 2 つあります。

AC 電源に接続されていること
GPU 負荷が十分に高いこと

バッテリー駆動時には動作しません。

6. 新しい Intel 内蔵 GPU / 外付け GPU のサポートも前進

Ubuntu は新しい Intel GPU への対応も引き続き進めています。主な対象は次の通りです。

統合 GPU:

Intel Core Ultra Xe2
Intel Core Ultra Xe3

ディスクリート GPU:

Intel Arc 5 B570
Intel Arc 5 B580
Intel Arc Pro B50
Intel Arc Pro B60
Intel Arc Pro B65
Intel Arc Pro B70

これらのデバイスに関連して、Ubuntu はすでに利用可能な機能も挙げています。

Intel Embree を利用した GPU / CPU レイトレーシング描画性能の向上。Blender 4.2+ などで恩恵あり
“Battlemage” デバイスで AVC、JPEG、HEVC、AV1 のハードウェアエンコードをサポート
Intel Compute Runtime に新しい CCS 最適化を導入
Intel Xe GPU のデバッグサポートを有効化

さらに後続の 25.10 では、次のような機能強化も続きます。

Linux kernel 6.17 を通じて、開発コードネーム Panther Lake の次世代 Intel クライアントプラットフォームを初期サポート
IOMMU、PCIe サブシステム、マルチ GPU サポートの改善
Mesa 25.2.3 で Battlemage と Panther Lake 向けに VK_KHR_shader_bfloat16 を有効化
intel-media-driver 25.3.0 で Panther Lake のデコードと VP9 エンコードを追加
intel-compute-runtime 25.31 で Level Zero の USM プールやローカルデバイスメモリ上のイベント確保戦略を調整
level-zero 1.24 と level-zero-raytracing 1.1.0 で仕様対応と RTAS 拡張を強化

7. Nvidia デスクトップのサスペンド復帰も安定化

25.10 から、Ubuntu はプロプライエタリな Nvidia ドライバでサスペンド復帰を有効化し、復帰時の破損やフリーズを減らしています。

見た目に派手な変更ではありませんが、長時間稼働させるデスクトップや、サスペンドと復帰を繰り返す環境ではかなり大事な改善です。

8. ARM、Raspberry Pi、RISC-V、IBM Z でも要件変更がある

GPU ソフトウェアスタック以外にも、今回のリリースノートにはプラットフォーム面で覚えておきたい変更がいくつかあります。

ARM64 デスクトッププラットフォーム

25.10 から、ARM64 向け linux-generic カーネルは、UEFI で起動する ARM64 デスクトッププラットフォームへの互換性をより広く提供します。

Raspberry Pi の新しいブートレイアウト

25.10 で導入され、26.04 でも継続調整されている変更の 1 つが、Raspberry Pi 向けブートパーティションの新レイアウトです。

目的はブート信頼性の向上で、新しく書き込まれたブート資産はいったん「テスト」され、問題がなければ新しい “known good” セットとして確定されます。

特に覚えておきたいのはファームウェア日付の条件です。

Pi 3 / 3+ / CM3+ / Zero 2W: 追加作業は不要。ブートファームウェアはイメージ自体に含まれる
Pi 4 / 400 / CM4: ブートファームウェアの日付が 2022-11-25 以前であってはならない
Pi 5 / 500 / CM5: ブートファームウェアの日付が 2025-02-11 以前であってはならない

確認コマンドは次の通りです。

`1`	`sudo rpi-eeprom-update`

ファームウェアが古く、かつ Ubuntu 24.04 LTS 以降を使っているなら、次のように更新できます。

1
2

sudo rpi-eeprom-update -a
sudo reboot

Raspberry Pi デスクトップイメージは desktop-minimal ベースに

25.10 から、Raspberry Pi 向け Ubuntu Desktop イメージは完全な desktop seed ではなく、desktop-minimal ベースになりました。

Ubuntu が示している利点は明確で、デフォルトのアプリセットが小さくなり、非圧縮イメージと実システムの両方で約 777MB を節約できます。

アップグレード後にこのデフォルトアプリ群をまとめて削除したい場合は、次を使えます。

`1`	`sudo apt purge ubuntu-desktop --autoremove`

一部のアプリを残したいなら、先に apt で手動インストール扱いにしておけば除外できます。

Raspberry Pi の swap は cloud-init 管理に

25.10 から、Raspberry Pi デスクトップイメージ上の swap ファイル作成は cloud-init が担当します。
初回起動前に swap サイズを調整したい場合は、ブートパーティション上の user-data を直接編集できます。

RISC-V の要件が引き上げ

25.10 から、Ubuntu 26.04 LTS の RISC-V 版は RVA23S64 ISA profile を実装したハードウェアを必要とします。

この要件を満たさないシステムでは Ubuntu 26.04 LTS を動かせません。もし以前の RVA20 プロセッサコアを使ったボードを使っているなら、Ubuntu 24.04 LTS のサポートラインに留まる必要があります。

Ubuntu の説明では、2026 年 4 月 時点で実機の RVA23S64 ハードウェアはまだ存在しません。そのため、現在サポートされる唯一の環境は、実質的には -cpu rva23s64 を指定した QEMU 仮想環境です。

IBM Z の最低要件は z15 に

26.04 から、s390x アーキテクチャの最低要件は z15 へ引き上げられました。

つまり次のようになります。

z14 / LinuxONE II およびそれ以前のシステムでは Ubuntu 26.04 LTS をインストールできない
z15 / LinuxONE III 以降では性能向上が期待できる

9. この内容を先に読むべき人

次のようなケースでは、この文章のほうがデスクトップ概要より優先度が高いはずです。

Ubuntu 上で CUDA、ROCm、SYCL、ローカル AI 推論を使う
Intel、NVIDIA、AMD の GPU を使った開発や計算処理を行う
Raspberry Pi、ARM64、RISC-V、IBM Z など、標準的な x86 以外のプラットフォームを運用している
アップグレード後のリポジトリ可用性、ドライバ挙動、ランタイム、プラットフォーム要件に敏感である

10. ひと言でまとめると

Ubuntu 26.04 LTS のハードウェアと AI スタック面での要点は、どこか 1 社の GPU だけが大きく強化されたことではありません。Intel の DPC++、NVIDIA の CUDA、AMD の ROCm が、より公式に、よりリポジトリ内で、より保守しやすい形で Ubuntu エコシステムへ入ってきたことです。

これまで Ubuntu を「まず OS を入れて、その上に GPU 環境は自分で組むもの」と見ていたなら、26.04 は AI やヘテロジニアスコンピューティングのワークロードを、ディストリビューション側がより積極的に支える方向へ進み始めた版だと言えます。

Ollama が GPU を使わず CPU で動いてしまう問題の対処法

Fri, 24 Apr 2026 18:30:00 +0800

ローカルで大規模モデルを動かしているとき、かなり悩まされやすいのが「GPU があるのに Ollama がほぼ CPU しか使わず、速度も極端に遅い」という問題です。

先に結論を言うと、この手の問題はたいてい単一の原因ではありません。よくある原因は次のとおりです。

Ollama が利用可能な GPU を認識できていない
ドライバ、ROCm、CUDA の環境構築が正しくない
Ollama サービスが正しい環境変数を引き継がずに起動している
モデルが大きすぎて CPU もしくは CPU/GPU の混在ロードに落ちている
AMD 環境では、ROCm のバージョン、gfx 設定、デバイス可視性などの互換性問題が追加で発生している

以下、時間を無駄にしにくい順番で切り分けていきます。

1. まず本当に GPU を使えていないのか確認する

一番わかりやすい確認方法はこれです。

`1`	`ollama ps`

見るべきなのは PROCESSOR 列です。

100% GPU: モデルは完全に GPU 上で動いている
100% CPU: GPU はまったく使えていない
48%/52% CPU/GPU のような表示: 一部は VRAM に載り、一部はシステムメモリに落ちている

100% CPU なら、次は環境とサービス設定を重点的に確認すべきです。
混在ロードの場合は、GPU が壊れているとは限らず、単純に VRAM が足りないだけのことも多いです。

2. まず一番多い思い込みを外す: モデルが VRAM に収まっていない

GPU を積んでいれば Ollama は常にフル GPU 推論になる、と考えている人は多いですが、実際はそうではありません。

モデルが大きすぎる、コンテキストが長すぎる、あるいは別のモデルがすでに VRAM を使っている場合、Ollama は次のような状態に落ちることがあります。

一部 GPU + 一部 CPU
100% CPU

この場合、まずは次の 2 つを試すのがいちばん早いです。

より小さいモデルでテストする
いきなり大きなモデルを試すのではなく、まずは 4B や 7B のような小さめのモデルで確認します。
すでに読み込まれている他のモデルを外してから再確認する
先に ollama ps を見て、別のモデルが VRAM を占有していないか確認します。

小さいモデルは GPU で動くのに、大きいモデルだけだめなら、原因はドライバではなく VRAM 容量であることがほとんどです。

3. GPU ドライバと下位ランタイムが正常か確認する

小さいモデルですら CPU しか使わないなら、次は下位レイヤの確認です。

NVIDIA の場合

まずはドライバが正常で、OS から GPU が見えているかを確認します。よく使う確認方法は次のとおりです。

`1`	`nvidia-smi`

ここでエラーになるなら、Ollama が GPU を正常に使える可能性はかなり低いです。

AMD / ROCm の場合

AMD GPU、特に ROCm 環境なら、まず次を確認します。

1
2

rocminfo
rocm-smi

これらがデバイスを正常に列挙できないなら、問題はまだ Ollama より下の層にあります。アプリ側をいじる前に、そこを直すべきです。

AMD でよくあるのは、単純な「ドライバが入っているか」ではなく、次のような問題です。

ROCm のバージョンと OS の組み合わせが合っていない
対象 GPU アーキテクチャのサポートが不完全
デバイス自体は存在するが、実行環境が Ollama に正しく渡っていない

4. ターミナルではなく Ollama サービス自体を再起動する

これはかなりよくある落とし穴です。

ドライバを入れ直し、環境変数を変え、ROCm を調整したあとで、単に新しいターミナルを開いて ollama run を続けてしまうケースがあります。ですが Ollama がバックグラウンドサービスとして動いているなら、古い環境のまま動作し続けている可能性があります。

なので、より安全なのは次のやり方です。

Ollama サービスを完全に再起動する
必要なら OS ごと再起動する

Linux でサービスとして動かしているなら、古いプロセスを再利用していないかも確認してください。

5. 環境変数が本当にサービスまで届いているか確認する

これは特に AMD ROCm 環境で重要です。

シェル上で手動実行すると問題ないのに、Ollama サービスにすると CPU しか使わない、というケースがあります。多くの場合、原因はシェルで設定した変数がサービスプロセスに渡っていないことです。

よく確認したい変数は次のあたりです。

1
2

ROCR_VISIBLE_DEVICES
HSA_OVERRIDE_GFX_VERSION

それぞれの意味は次のとおりです。

ROCR_VISIBLE_DEVICES: ROCm から見える GPU を制限または指定する
HSA_OVERRIDE_GFX_VERSION: 一部 AMD 環境で互換性確保のために使うことがある

現在のターミナルで一時的に export しただけでは、systemd、デスクトップのバックグラウンドサービス、その他のデーモン経由で起動された Ollama には反映されないことがあります。

つまり、ターミナルで「設定済みに見える」ことと、Ollama が実際にその設定を使っていることは別です。

6. AMD 環境では ROCm の互換性を重点的に見る

公開ページの情報を見る限り、この話題の元動画は AMD Max+ 395、strix halo、AMD ROCm の文脈にあります。
この種の環境では、Ollama が GPU を使えない原因は、NVIDIA よりもバージョン整合性に左右されやすい傾向があります。

優先的に見るべき点は次のとおりです。

現在の OS と GPU に対して ROCm のバージョンが適切か
その GPU が ROCm で比較的安定して動くアーキテクチャか
HSA_OVERRIDE_GFX_VERSION の指定が必要か
古い Ollama や古い推論ランタイムが互換性の問題を起こしていないか

rocminfo は正常で GPU も OS から見えているのに、Ollama だけが CPU しか使わないなら、モデルパラメータをいじるより、まずバージョンの組み合わせを疑うべきです。

7. Docker、WSL、リモート環境ではデバイスマッピングも確認する

もしベアメタルではなく、次のような環境で動かしているなら:

Docker
WSL
リモートコンテナ
仮想化環境

もう一段下を見て、「GPU デバイスが本当にその環境に渡っているか」を確認する必要があります。

典型的には次のような状態になります。

ホスト側では GPU が見えている
しかしコンテナやサブシステム内の Ollama は CPU しか使わない

この場合、問題は Ollama 自体ではなく、コンテナやサブシステムに GPU アクセス権限が渡っていない可能性があります。

8. 最後にログを見る。やみくもに再インストールしない

ここまで確認したなら、次に有効なのは何度も再インストールすることではなく、Ollama の起動ログと実行ログを直接見ることです。

見るべきポイントは大きく 2 つです。

GPU を認識できているか
ドライバ、ライブラリ読込、デバイス初期化失敗などのエラーが出ていないか

ログに「互換 GPU が見つからない」や「ROCm/CUDA の初期化に失敗した」といった内容が出ていれば、切り分けの方向はかなり明確になります。

切り分け順序

最短ルートだけ覚えたいなら、次の順番で確認すると効率的です。

ollama ps で GPU、CPU、混在ロードのどれかを確認する
小さいモデルで試し、VRAM 不足を切り分ける
nvidia-smi、rocminfo、rocm-smi で下位環境が正常か先に確認する
Ollama サービスを完全に再起動する
特に AMD では ROCR_VISIBLE_DEVICES と HSA_OVERRIDE_GFX_VERSION を確認する
Docker / WSL ならデバイスマッピングを確認する
最後にログを見て、具体的なエラーを特定する

まとめ

Ollama が GPU ではなく CPU を使ってしまう問題は、だいたい次の 3 パターンのどれかです。

GPU がそもそも認識されていない
GPU は見えているが、実行環境が Ollama に届いていない
GPU は動いているが、モデルが大きすぎて CPU または混在メモリに落ちている

この 3 つをまず分けて考えるだけで、切り分けはかなり速くなります。
AMD 環境では特に、ROCm のバージョン整合性、デバイス可視性、互換性用の環境変数を重視して確認するのがポイントです。

元動画：https://www.bilibili.com/video/BV1cHoYBqE8k/

NVIDIA nvbandwidth とは何か：GPU 帯域テストツールの使い方

Fri, 24 Apr 2026 14:41:35 +0800

複数の NVIDIA GPU 間の接続性能を調べているときや、PCIe、NVLink、ホストメモリと VRAM の間で実際にどれくらいの帯域が出ているか確認したいとき、NVIDIA/nvbandwidth は知っておく価値のある小さなツールです。

これは汎用的なベンチマークソフトではなく、大規模モデルのフレームワークに隠れているコマンドでもありません。NVIDIA がオープンソースで公開している、GPU 関連のメモリコピーにおける帯域とレイテンシを測定するための専用ツールです。理論帯域を見るだけではなく、nvbandwidth は次のような実務的な問いに向いています。このマシンにある GPU と相互接続の組み合わせで、実際にどれだけの帯域が出るのか。

1. `nvbandwidth` は何をするツールか

公式 README によると、nvbandwidth は NVIDIA GPU の帯域を測定するためのコマンドラインツールです。

主に、さまざまな memcpy パターンにおける転送性能を測ります。たとえば次のようなものです。

GPU -> GPU
CPU -> GPU
GPU -> CPU
マルチノード環境での GPU 間転送

この種のテストは、特に次のような場面で役立ちます。

マルチ GPU の学習や推論で相互接続のボトルネックを調べる
NVLink、PCIe、C2C などのリンクが実際にどう動いているかを確認する
サーバー構成、トポロジ、ドライバ、CUDA バージョンごとの差を比較する
クラスタ導入前の基礎的なハードウェア検証を行う

要するに、nvbandwidth が見ているのはモデルのスループットではなく、より下層の「データを運ぶ力」です。

2. 単なる 1 つのスコアを出すツールではない

帯域テストというと最後に 1 つの数字だけが出るイメージを持つ人もいますが、nvbandwidth の出力はもっと細かいです。

各テストごとに行列形式で結果を出します。たとえば device_to_device_memcpy_write_ce のようなテストでは、GPU の行列として各デバイス対の帯域が表示されます。これにより、「このマシンはだいたい速いかどうか」だけでなく、次のようなことも見えてきます。

どの GPU ペアが特に高速か
どの経路が明らかに PCIe に制限されているか
一部の GPU ペアで異常に低い帯域が出ていないか
マルチ GPU のトポロジが想定どおりか

8 GPU サーバー、デュアルソケット構成、あるいはマルチノード環境を見ているなら、この行列形式の出力は単純な平均値より役に立つことが多いです。

3. `CE` と `SM` の 2 種類のコピーをどう理解するか

公式ドキュメントでは、テストを 2 種類に分けています。

CE：memcpy API に基づく copy engine 転送
SM：kernel ベースの転送

この 2 種類の結果は、必ずしも完全には一致しません。なぜなら、異なるコピー経路を表しているからです。
まず通常のデバイス間転送を見たいなら、一般的には CE を先に確認します。より細かい実行経路まで見たい場合は、続けて SM を見るのがよいです。

また README では、帯域の結果は既定で複数回の測定に対する中央値を使うと説明されています。新しいバージョンでは変動統計も追加されており、値の安定性を判断しやすくなっています。

4. 実行に必要な環境

nvbandwidth は、ダウンロードしてそのまま実行できる単独バイナリではありません。標準的な CUDA 開発環境が前提です。

現在の README にある基本要件は次のとおりです。

CUDA Toolkit 11.x 以上
C++17 をサポートするコンパイラ
CMake 3.20+、推奨は 3.24+
Boost program_options
利用可能な CUDA デバイスと互換ドライバ

マルチノード版を使う場合は要件がさらに上がります。README では次のように明記されています。

マルチノード版のビルドには CUDA Toolkit 12.3 が必要
ドライバは 550 以上が必要
MPI が必要
nvidia-imex サービスの設定が必要

そのため、これは一般的なデスクトップ向けというより、Linux の GPU サーバーやクラスタ向けのエンジニアリングツールと考えたほうが自然です。

5. シングルノード版のビルドと実行方法

シングルノード版のビルド手順はシンプルです。

1
2

cmake .
make

Ubuntu / Debian では、共通依存関係のインストールとビルドを行う debian_install.sh スクリプトも用意されています。

ビルド後は、まずヘルプを確認できます。

`1`	`./nvbandwidth -h`

よく使うオプションは次のとおりです。

-l：利用可能なテストを一覧表示する
-t：名前または番号で特定のテストを実行する
-p：プレフィックス指定でテストをまとめて実行する
-b：memcpy buffer サイズを設定する。既定値は 512 MiB
-i：測定反復回数を設定する
-j：JSON で出力する
-H：ホストメモリ割り当てで huge pages を有効にする

まずは既定のテストを 1 回流したいだけなら、次のように実行します。

`1`	`./nvbandwidth`

特定の項目だけ試したい場合、たとえばデバイス間コピーを 1 つだけ見るなら次のようにします。

`1`	`./nvbandwidth -t device_to_device_memcpy_read_ce`

6. マルチノード対応がこのツールの特徴

nvbandwidth はシングルノードのマルチ GPU テストだけのツールではなく、マルチノード環境にも対応しています。

README によると、マルチノード版のビルドは次のように行います。

1
2

cmake -DMULTINODE=1 .
make

実行時は通常 mpirun と組み合わせ、GPU ごとに 1 プロセスを割り当てて起動します。
公式ドキュメントでは、参加するすべての rank が同じ multinode clique に属している必要があるとされており、MPI 環境では主に multinode プレフィックスの付いたテストを実行することが推奨されています。

このあたりからも、ワークステーションの簡単な自己診断用というより、高性能計算や大規模 GPU システム寄りのツールであることが分かります。

NVLink を使うマルチノード構成や、GB200 / Grace Hopper のような複雑なプラットフォームを扱っているなら、一般的なコンシューマ GPU 環境よりも nvbandwidth の価値はずっと高くなります。

7. `v0.9` では何が変わったか

2026 年 4 月 24 日 時点で、GitHub Releases ページでは nvbandwidth の最新バージョンは v0.9、公開日は 2026 年 4 月 8 日 となっています。

このリリースで特に注目しやすい更新点は次のとおりです。

帯域出力に変動統計を追加
ホストメモリ向け huge pages 対応を追加（Windows は対象外）
デバイス間テストに pair sampling オプションを追加
troubleshooting guide を追加
シングルノードとマルチノードの実行経路を統一

加えて、エンジニアリング面で次の 2 点も実用的です。

実際の GPU アクセスにあまり依存しない CUDA アーキテクチャ検出に改善
CUDA Toolkit 13.0+ 環境で Volta（sm_70 / sm_72）サポートを廃止

初期の情報しか見ていなかった人にとっては、v0.9 はもはや単なる帯域測定の初期版ではありません。自動化、トラブルシュート、大規模システム検証へと明確に進んでいます。

8. どんなときに使うとよいか

nvbandwidth が特に向いているのは次のようなケースです。

複数の NVIDIA GPU 間で実際の相互接続帯域を確認したい
ある GPU が帯域制限のある PCIe スロットに挿さっている疑いがある
NVLink 経路と非 NVLink 経路を比較したい
マルチノード GPU クラスタを構築していて、リンクを検証したい
結果を JSON で出して自動化パイプラインに組み込みたい

一方で、「学習はどれくらい速いか」「推論は何 tokens/s 出るか」といった問いにそのまま答えるツールではありません。
その場合は、学習フレームワーク、推論エンジン、あるいは実際のワークロードでの測定と合わせて見る必要があります。

9. このツールの価値をどう捉えるか

GPU の性能問題の多くは、実は計算性能そのものが足りないのではなく、データの通り道が想定どおりに機能していないことが原因です。

たとえば次のようなケースです。

GPU 間で意図した接続経路が使われていない
NUMA をまたぐアクセスで速度が落ちている
一部の GPU ペアだけ帯域が異常に低い
マルチノード通信の設定が不完全

こうした問題は、nvidia-smi やモデルのスループットだけを見ていても特定しにくいことがあります。
nvbandwidth のような、より低レイヤで行列形式のテストツールは、相互接続レイヤで何が起きているかを可視化できる点が強みです。

つまり、nvbandwidth は NVIDIA GPU システム向けの帯域ヘルスチェック用コマンドラインツールとして理解すると分かりやすいです。

Tesla V100 に ECC エラーがあるか確認する方法

Thu, 23 Apr 2026 11:50:21 +0800

手元に Tesla V100 があり、まず基本的なヘルスチェックをしたいなら、優先して確認したい項目のひとつが ECC の状態です。

最も手軽な方法は、nvidia-smi でカードの詳細情報を確認することです。

1
2
3

nvidia-smi -q
# 查询第 0 块 GPU
nvidia-smi -q -i 0

見るべきなのは ECC Errors のセクションです。

正常な状態のカードであれば、ECC Errors の下にある代表的な 4 つの統計グループは、いずれも 0 または N/A であるはずです。ここにすでに非ゼロの値がある場合、そのカードは過去に対応する種類の ECC 異常を起こしたことがあるため、引き続き使用してよいか追加で判断する必要があります。

参考出力は次のとおりです。

nvidia-smi -q
    ECC Mode
        Current                          : Enabled
        Pending                          : Enabled
    ECC Errors
        Volatile
            Single Bit
                Device Memory            : 0
                Register File            : 0
                L1 Cache                 : 0
                L2 Cache                 : 0
                Texture Memory           : N/A
                Texture Shared           : N/A
                CBU                      : N/A
                Total                    : 0
            Double Bit
                Device Memory            : 0
                Register File            : 0
                L1 Cache                 : 0
                L2 Cache                 : 0
                Texture Memory           : N/A
                Texture Shared           : N/A
                CBU                      : 0
                Total                    : 0
        Aggregate
            Single Bit
                Device Memory            : 0
                Register File            : 0
                L1 Cache                 : 0
                L2 Cache                 : 0
                Texture Memory           : N/A
                Texture Shared           : N/A
                CBU                      : N/A
                Total                    : 0
            Double Bit
                Device Memory            : 0
                Register File            : 0
                L1 Cache                 : 0
                L2 Cache                 : 0
                Texture Memory           : N/A
                Texture Shared           : N/A
                CBU                      : 0
                Total                    : 0
    Retired Pages

簡単に整理すると、次のように理解できます。

Volatile は今回の通電サイクル内でのエラー統計
Aggregate は累積エラー統計
Single Bit は訂正可能エラー
Double Bit は訂正不能エラーで、よりリスクが高い

素早くふるい分けしたいだけなら、まずは次の基準を覚えておけば十分です。

ほとんどの項目は 0 であるべき
該当しない項目が N/A なのは正常
Double Bit や合計値が 0 でない場合は、売り手の説明だけを鵜呑みにせず、より十分なストレステストと安定性確認を続けるべき

この確認だけで完全な検品にはなりませんが、V100 を入手した直後の第一段階のチェックとしては十分に実用的です。

Tesla V100 はまだ買う価値があるか：ECC確認、冷却改造、DIYの落とし穴

Thu, 23 Apr 2026 11:15:10 +0800

最近、中古の Tesla V100 を見ていると、だいたい次の2つの意見にぶつかります。

まだ十分戦えるし、コストパフォーマンスが高い
この手のカードは闇が深く、DIY ユーザーは簡単に失敗する

どちらも間違っていません。

V100 は買ってはいけないカードなのではなく、普通の民生向け GPU と同じ感覚で買ってはいけないカードです。見るべきなのは、起動するかどうかだけでも、「新品同様」「純正サーバー抜き取り」といった売り文句だけでもありません。このカードに手が入っていないか、ECC の状態はどうか、冷却と電源構成が本当に信頼できるかが重要です。

この記事では、実際の購入と運用で役立つチェックポイントをまとめます。

まず結論

短く要点だけ見るなら、次を覚えておけば十分です。

V100 はおおむね 2017 年から 2021 年まで生産され、16G 版で 2021 年製はあまり多くありません
「ECC が全部ゼロ」「純正抜き取り」だけでは判断材料として足りません。数値も外観も手を入れられている可能性があります
本当に危ないのは、古いカードを買うこと自体より、分解済み・書き換え済み・冷却に欠陥があるカードを買うことです
DIY ユーザーにとって最大の落とし穴は、コアそのものより、変換基板、電源供給、ホットスポット温度、バックプレート冷却です

1. まず製造年とロット感を見る

実用的な見方は、チップ本体の年式を見て、その周辺部品の年式がだいたい一致しているかを確認することです。

たとえばチップ表面に 1828 とあれば、通常は次のように読めます。

18 = 2018 年
28 = 第 28 週

つまり 2018 年第 28 週製造のチップです。

チップ本体だけでなく、周辺のインダクタにも年式に関係する刻印があることがあります。もしチップ年式とインダクタ年式が大きくずれていて、たとえば：

チップは 2017
インダクタは 2020

となっているなら、注意したほうがよいです。即座に不良と断定はできませんが、少なくとも非常にオリジナルに近い状態とは言いにくくなります。

逆に、

2018 のチップに 2018 年ごろの周辺部品
2019 年末のチップに 2020 年ごろの周辺部品

のように大筋で辻褄が合っているなら、より自然です。

2. 外観確認ではチップだけでなく、インダクタ、スプリング、フレームも見る

外観確認は、いくつかの段階に分けて見るのがわかりやすいです。

1. まずインダクタを触る

インダクタを軽く触ってみて、通常はどれもグラつかないはずです。

もしどれかがすでに動くなら、たいていは：

はんだの状態が良くない
使用を続けると問題が広がる可能性がある

ということです。今は動いていても、積極的には勧めにくい状態です。

2. 固定スプリングが外された形跡を確認する

ここでも実用的な判断があります。

売り手が「純正サーバー抜き取り」と強く主張するなら
固定スプリングは簡単に外された形跡がないほうが自然です

通常のサーバー運用で、このスプリングだけをわざわざ外すことはあまりありません。

もし軽くこじるだけで簡単に外れるなら、一度は分解されている可能性が高いです。それでいて「未分解」と言っているなら、かなり怪しいと考えるべきです。

3. フレームが簡単に分かれるのも不自然

中央フレームを外したあと、構造がほとんど力を入れずに分離するなら、それも何度も分解された痕跡であることが多いです。

中古 V100 ではこの点が重要です。後からの書き換え、改造、修理は、こうした分解痕を残しやすいからです。

3. バックプレートが簡単に外れるなら、VBIOS 書き換えや改造を疑う

PCB の下には金属製のプレートがあり、これは保護だけでなく放熱にも関わっています。

オリジナルに近い状態では、このプレートは普通あまり簡単には外れません。理由は次の通りです。

接着材
構造的な密着
そもそも何度も分解する前提の設計ではない

もし少し力を入れるだけでバックプレートが PCB から外れるなら、次のような可能性を疑うべきです。

過去に分解された
VBIOS が書き換えられた可能性がある
二次的な改造が行われた可能性がある

それだけで使えないとは言えませんが、「完全オリジナル」とは明らかに整合しません。

4. `ECC` の見方：重要なのはゼロかどうかではなく、増えるかどうか

V100 を買うとき、多くの人が ECC を気にします。この項目は丁寧に見る価値があります。

よく使われる方法は、nvidia-smi の詳細表示で ECC Errors を確認することです。

1. リアルタイムのエラーが最も危ない

上のほうの項目は、実運用中のリアルタイムエラーとして捉えられます。

もし稼働中にその数字が増え続けるなら、小さな問題ではないことが多く、すでに不安定なカードである可能性が高いです。

要するに：

静的にゼロであることより、実際に走らせても増えないことのほうが重要
負荷をかけるとすぐ増えるカードは、履歴だけ多いカードより怖い

2. 生涯累積エラーは必ずしも致命的ではない

別の項目には、そのカードがこれまでに経験した累積エラー数が出ることがあります。

それが：

一桁
あるいは十数件程度

であれば、即アウトとは限りません。

実際の動作中にリアルタイムエラーが増えないなら、普通に使えることもあります。

3. ページリタイアはより重視したい

さらに重要なのが、修復不能エラーによってメモリブロックが退役したことを示すページリタイア系の項目です。

実用的には次のように考えられます。

シングルビット側、ダブルビット側それぞれに退役ブロックがあり得る
合計が 10 を超えてくると、かなり慎重に見たほうがよい

完全に使えないわけではありませんが、実効メモリ量や長期安定性には明らかに影響します。

5. 「ECC ゼロ」を信じすぎない。数値自体が触られている可能性もある

ここで現実的に意識したいのは、ECC の数値それ自体も絶対的ではないということです。

もしカードが：

異様にきれいな数値を示している
それなのに分解痕は強い
構造的にも明らかに手が入っている

なら、「ECC がゼロだから安心」とは言えません。

たとえるなら、何年も経った中古車なのに、走行距離が突然 0 で、タイヤ摩耗もほとんどないようなものです。走行計に手が入っていないか疑うのが自然です。

V100 でも同じで：

完璧すぎる数値は、必ずしも良い兆候ではない
数値、外観、ストレステスト結果が互いに噛み合っているかのほうが大事

6. ストレステストは必須。ただしコアだけ見ても足りない

gpu-burn のようなツールで数分から十数分以上負荷をかけ、次の点を確認するとよいです。

安定しているか
カードが落ちないか
新しい ECC エラーが出ないか

ただし、ここでも重要な注意点があります。

コアだけテストしても、カード全体が健全だとは言えません。

V100 の故障は、必ずしもコアから始まるわけではなく、次のような場所から壊れることも多いからです。

電源回路の過熱
バックプレート周辺の冷却不足
ホットスポット温度の上昇
変換基板や冷却構成が長期間ギリギリの状態にあること

つまり、ストレステストでわかるのは「今は動く」ということまでで、「この DIY 構成で長く安定運用できる」ことまでは保証してくれません。

7. DIY ユーザーが本当に失敗しやすいのは、購入より冷却と電源

ここがいちばん重要なポイントかもしれません。

結論から言えば、DIY ユーザーが適当な変換ベースと汎用クーラーを組み合わせるだけでは、安定した構成になりにくいです。

なぜなら V100 は普通の民生 GPU ではなく、

消費電力が高く
発熱が大きく
熱分布が複雑な

サーバー向けアクセラレータだからです。

発熱源はチップ中央だけではありません。バックプレート、電源回路、コネクタ周辺もかなり熱くなります。

1. GPU の平均温度だけを見ない

多くの監視ツールが表示するのはカード全体の平均温度ですが、本当に危険なのは hot spot のほうであることが多いです。

つまり：

表示温度は 60 度台でも
局所的なホットスポットは 100 度超えになっているかもしれない

それが、見た目には「温度は大丈夫そう」な DIY V100 が、後から突然壊れる理由のひとつです。

2. バックプレートと電源まわりの冷却は必須

バックプレートと電源まわりを冷却しない構成は危険です。

コアだけを冷やしても、

MOS 周辺を見ていない
バックプレートに熱を逃がせていない
背面側に十分な放熱設計がない

のであれば、構成全体としては不完全です。

3. 安い寄せ集め水冷構成はリスクが高い

「適当な変換基板に、安い一体型水冷をのせる」ような構成には慎重になるべきです。

問題は、すぐ壊れると決まっていることではなく、次のような欠点を抱えがちなことです。

水路のカバー範囲が不均一
電源部の冷却が足りない
ホットスポットを本当に押さえられていない
長期寿命が読みにくい

8. それでも DIY するなら、最低限ここは見る

実用的なポイントは次の通りです。

より成熟していて実績のある変換基板を優先する
コアだけでなく、背面の電源部とバックプレートにも熱対策をする
水枕は「物理的に載る」だけでなく、面全体をきちんとカバーできるものを選ぶ
ストレステスト後も温度、ホットスポット、長期安定性を継続して確認する
電源の質もコイル鳴きや安定性に影響する

要するに、DIY V100 の難しさは「起動するか」ではなく、「その後ちゃんと生き残るか」にあります。

9. コイル鳴きと変換基板の個体差も現実的な問題

最後に、見落とされやすい点が2つあります。

1. コイル鳴きは完全には消せないことがある

カードの個体差、インダクタ、コンデンサ、電源環境が絡むため、ケーブルや小物ひとつで必ず解決できるとは限りません。

2. 変換基板の個体差はかなり大きい

そのため、裸カードを売るタイプの売り手でも：

先に動作確認する
シリアル番号を記録する
ストレステストを行う
手順を記録する

といった対応を重視することがあります。

トラブルの原因はシリコン本体より、後から組み合わせた変換基板や冷却構成にあることも多いからです。

まとめ

では Tesla V100 はまだ買う価値があるのか。答えは、ある。ただし、自分が何を買っていて、その後どう使うのかを理解している場合に限ります。

見るべきなのは、単に：

起動するか
ECC がゼロか
売り手が「純正抜き取り」と言っているか

だけではありません。

本当に確認したいのは：

年式とロット感が合っているか
分解痕が不自然でないか
バックプレートや構造に明らかな改造痕がないか
負荷時にエラーが増えないか
冷却と電源構成に無理がないか

特に DIY ユーザーにとって危険なのは、「古いカードを買うこと」より、「このカードが要求する冷却・電源・改造品質を甘く見ること」です。

llama.cpp / ollama GPU 性能ランキング：CUDA、ROCm、Vulkan

Thu, 23 Apr 2026 10:22:04 +0800

まずパラメータを理解する

`Q4_0` とは

Q4_0 は 4-bit 量子化フォーマットの一種です。これは「モデルがより強い」という意味ではなく、「モデルが小さく、VRAM を節約でき、より多くのデバイスに載せやすい」という意味です。これらのランキングでは多くの場合 Llama 2 7B, Q4_0 に条件をそろえ、変数を減らして GPU 同士を横比較しやすくしています。

`pp512` とは

pp512 は一般に prompt processing 512 tokens、つまり 512 個の入力 token を処理するときのスループットとして理解できます。

pp = prompt processing
512 = 入力長が 512 token
t/s = tokens per second

これは「プロンプトを読み込む速度」に近く、並列化が効きやすいため数値が大きくなりがちです。

`tg128` とは

tg128 は一般に text generation 128 tokens、つまり 128 個の token を連続生成するときの速度として理解できます。

tg = text generation
128 = 128 token を連続生成
t/s = tokens per second

こちらは普段感じる「モデルの返答が速いか」により近い指標です。生成段階は token を逐次的に進めるため、通常は pp512 よりかなり低くなります。

`FA` とは

FA は Flash Attention です。簡単に言えば、attention 計算を最適化するためのスイッチです。

with FA は Flash Attention を有効化した状態
no FA は Flash Attention を無効化した状態

多くの GPU では、FA は tg128 より pp512 に対して目立った改善を出しやすいです。ただし、バックエンド、ドライバ、アーキテクチャによって効果はそろわず、デバイスによっては PP だけ伸びる、TG の変化が小さい、あるいは PP が下がることもあります。

`t/s` の読み方

t/s は tokens per second です。フレームレートでも FLOPS でもなく、モデルのスループットを直接表す結果です。

ランキングを読むときに一番大事なのは、同じ種類のテストを比較しているかを先に確認することです。

pp512 と tg128 を混ぜて比較しない
no FA と with FA を混ぜて比較しない
CUDA、ROCm、Vulkan の結果を完全に同じ条件の曲線として扱わない

先に結論

現時点でこれらの discussion に見えているデータからは、おおよそ次のように読めます。

CUDA は今でも llama.cpp の GPU ベンチマークで最も強く、サンプルも最も多い系統です。特に高性能な Nvidia GPU は pp512 で大きな優位があります。
ROCm はハイエンド AMD GPU や Instinct 系でかなり実用的な成績を出しており、MI300X、7900 XTX、W7900 などの項目は十分強いです。
Vulkan の強みは「絶対に最速」ではなく、対応範囲の広さです。Nvidia、AMD、Intel、Apple Asahi / MoltenVK に加え、古い GPU や内蔵 GPU でも比較対象を見つけやすいです。
tg128 は日常の体感に近く、pp512 はスループットを見るのに向いています。ランキング上位の GPU でも、両指標でのリード幅は必ずしも同じではありません。

CUDA 完全ランキング

Llama 2 7B, Q4_0, no FA

Chip	Memory	pp512 t/s	tg128 t/s	Commit	Thanks to
RTX 5090	32 GB / GDDR7 / 512 bit	14073.41 ± 115.16	290.02 ± 1.10	8cf6b42	@totaldev
RTX PRO 6000 Blackwell	96 GB / GDDR7 / 512 bit	14854.63 ± 22.73	274.20 ± 0.14	79c1160	@Tom94
H100 80 GB	80 GB / HBM3 / 5120 bit	9918.34 ± 176.97	267.81 ± 1.54	5143fa8	@Hedede
A100 80 GB	80 GB / HBM2e / 5120 bit	4849.53 ± 8.94	190.88 ± 0.33	5143fa8	@Hedede
RTX 4090 D	24 GB / GDDR6X / 384 bit	10293.86 ± 134.72	189.33 ± 0.19	79c1160	@autonomous-AI-lab
RTX 4090	24 GB / GDDR6X / 384 bit	11992.70 ± 107.99	186.21 ± 0.13	2241453	@lhl
RTX 5080	16 GB / GDDR7 / 256 bit	8297.36 ± 9.50	181.99 ± 0.42	8a4280c	@Hedede
RTX 5070 Ti	16 GB / GDDR7 / 256 bit	6952.38 ± 13.73	176.85 ± 0.07	933414c	@TinyServal
RTX 6000 Ada	48 GB / GDDR6 / 384 bit	9229.23 ± 101.78	176.07 ± 0.26	b8e09f0	@Hedede
RTX 3090 Ti	24 GB / GDDR6X / 384 bit	6567.49 ± 20.30	171.19 ± 3.98	9c35706	@slaren
RTX 3090	24 GB / GDDR6X / 384 bit	5174.69 ± 21.83	158.16 ± 0.21	c76b420	@m18coppola
L40	48 GB / GDDR6 / 384 bit	8870.49 ± 378.76	152.01 ± 0.28	ee09828	@Hedede
RTX 4080 SUPER	16 GB / GDDR6X / 256 bit	8125.15 ± 41.05	148.33 ± 0.20	81086cd	@zacharyarnaise
RTX 4080	16 GB / GDDR6X / 256 bit	8031.64 ± 26.49	142.49 ± 0.16	20638e4	@Ristovski
RTX 3080	10 GB / GDDR6X / 320 bit	5013.86 ± 24.80	139.65 ± 0.99	9c35706	@slaren
RTX A6000	48 GB / GDDR6 / 384 bit	4913.93 ± 6.79	138.73 ± 2.75	4795c91	@Hedede
RTX 4070 Ti SUPER	16 GB / GDDR6X / 256 bit	6924.53 ± 13.87	132.26 ± 0.16	9c35706	@Ristovski
RTX PRO 4000 Blackwell	24 GB / GDDR7 / 192 bit	4992.83 ± 113.52	131.66 ± 0.20	7d77f07	@Hedede
RTX A5000	24 GB / GDDR6 / 384 bit	4028.16 ± 19.14	130.07 ± 2.74	e5155e6	@Hedede
Tesla V100	32 GB / HBM2 / 4096 bit	3042.64 ± 40.71	129.08 ± 0.05	51f5a45	@Hedede
RTX 5070	12 GB / GDDR7 / 192 bit	5184.75 ± 18.70	127.54 ± 0.46	@Spyro000	-
A40	48 GB / GDDR6 / 384 bit	4609.01 ± 10.67	124.11 ± 0.17	3470a5c	@Hedede
A30	24 GB / HBM2e / 3072 bit	2767.10 ± 1.88	124.81 ± 0.16	583cb83	@Hedede
Titan V	12 GB / HBM2 / 3072 bit	2617.46 ± 2.10	108.79 ± 0.05	e56abd2	@Hedede
RTX 2080 Ti	11 GB / GDDR6 / 352 bit	2890.66 ± 2.42	107.51 ± 0.21	9c35706	@ariya
Quadro RTX 6000	24 GB / GDDR6 / 384 bit	2751.18 ± 19.43	102.77 ± 0.04	b8e09f0	@Hedede
Quadro RTX 8000	48 GB / GDDR6 / 384 bit	2709.95 ± 3.35	102.68 ± 0.03	b8e09f0	@Hedede
RTX A4500	20 GB / GDDR6 / 320 bit	2827.20 ± 66.43	97.32 ± 2.80	5cdb27e	@aleksyx
RTX 5060 Ti 16 GB	16 GB / GDDR7 / 128 bit	3737.25 ± 6.79	90.94 ± 0.02	89d1029	@mike-llamacpp
RTX 2070 SUPER	8 GB / GDDR6 / 256 bit	2088.34 ± 1.94	88.06 ± 0.28	bc07349	@phstudy
RTX A4000	16 GB / GDDR6 / 256 bit	2684.06 ± 15.28	83.77 ± 0.37	65349f2	@TinyServal
Titan Xp	12 GB / GDDR5X / 384 bit	1154.96 ± 1.46	76.08 ± 0.08	c4510dc	@Hedede
RTX 3060	12 GB / GDDR6 / 192 bit	2137.50 ± 10.12	75.57 ± 0.07	baa9255	@QuantiusBenignus
Quadro RTX 4000	8 GB / GDDR6 / 256 bit	1536.89 ± 0.90	65.62 ± 0.62	7d77f07	@Hedede
RTX 4060 Ti 8 GB	8 GB / GDDR6 / 128 bit	3394.63 ± 7.44	63.86 ± 0.01	89d1029	@mike-llamacpp
GTX 1080 Ti	11 GB / GDDR5X / 352 bit	1084.41 ± 3.01	62.49 ± 0.06	9c35706	@ariya
RTX A4000 Ada	20 GB / GDDR6 / 160 bit	2779.77 ± 9.91	61.83 ± 0.04	a74a0d6	@sdwolfz
RTX 2060 SUPER	8 GB / GDDR6 / 256 bit	1420.24 ± 1.95	60.04 ± 0.01	5c0eb5e	@ggerganov
Tesla P100	16 GB / HBM2 / 4096 bit	760.80 ± 2.92	58.35 ± 0.00	b8372ee	@Hedede
DGX Spark	128 GB / LPDDR5x	3062.31 ± 11.02	57.21 ± 0.06	5acd455	@ggerganov
Tesla P40	24 GB / GDDR5 / 384 bit	1007.42 ± 1.23	54.74 ± 0.07	c76b420	@m18coppola
RTX 2000 Ada	16 GB / GDDR6 / 128 bit	1956.22 ± 7.74	50.62 ± 0.04	756cfea	@DigitalRudeness
Tesla T4	16 GB / GDDR6 / 256 bit	1219.06 ± 4.18	46.38 ± 0.73	d32e03f	@pt13762104
RTX 4050 Laptop	6 GB / GDDR6 / 96 bit	1725.85 + 17.85	43.72 + 0.41	d79d8f3	@TimCabbage
GTX 1660	6 GB / GDDR5 / 192 bit	148.91 ± 0.01	41.35 ± 0.02	9515c61	@ariya
Tesla M40	24 GB / GDDR5 / 384 bit	282.65 ± 0.15	38.04 ± 0.02	97d5117	@Hedede
GTX 1070 Ti	8 GB / GDDR5 / 256 bit	714.44 ± 2.04	37.82 ± 0.02	79c1160	@pebaryan
Jetson AGX Orin	64 GB / LPDDR5 / 256 bit	991.31 ± 1.15	33.58 ± 0.14	c1b1876	@TinyServal
Tesla P4	8 GB / GDDR5 / 256 bit	514.53 ± 3.06	33.29 ± 0.00	c76b420	@m18coppola
P106-100	6 GB / GDDR5 / 192 bit	406.94 ± 0.25	30.40 ± 0.02	5fd160b	@pebaryan
GTX 1060	6 GB / GDDR5 / 192 bit	416.85 ± 1.75	27.79 ± 0.02	5fd160b	@pebaryan
Quadro T1000	4 GB / GDDR5 / 128 bit	79.44 ± 0.01	27.82 ± 0.18	f6da8cb	@hanabu
Quadro P2000	5 GB / GDDR5 / 160 bit	309.30 ± 0.05	23.63 ± 0.00	baa9255	@TinyServal
Quadro P1000	4 GB / GDDR5 / 128 bit	183.40 ± 0.11	13.99 ± 0.13	1e74897	@aleksyx
Tesla K80	12 GB / GDDR5 / 384 bit	133.14 ± 0.55	13.80 ± 0.02	32732f2	@pebaryan

Llama 2 7B, Q4_0, with FA

Chip	Memory	pp512 t/s	tg128 t/s	Commit	Thanks to
RTX 5090	32 GB / GDDR7 / 512 bit	14970.15 ± 381.06	300.40 ± 0.28	8cf6b42	@totaldev
RTX PRO 6000 Blackwell	96 GB / GDDR7 / 512 bit	16618.98 ± 20.66	281.11 ± 0.41	5143fa8	@Tom94
H100 80 GB	80 GB / HBM3 / 5120 bit	11263.29 ± 98.34	280.74 ± 1.17	5143fa8	@Hedede
A100 80 GB	80 GB / HBM2e / 5120 bit	5285.96 ± 6.58	200.90 ± 0.12	5143fa8	@Hedede
RTX 4090 D	24 GB / GDDR6X / 384 bit	12506.97 ± 11.51	191.57 ± 0.03	79c1160	@autonomous-AI-lab
RTX 4090	24 GB / GDDR6X / 384 bit	14770.63 ± 102.93	188.96 ± 0.05	2241453	@lhl
RTX 5080	16 GB / GDDR7 / 256 bit	9487.70 ± 21.89	184.68 ± 0.05	8a4280c	@Hedede
RTX 5070 Ti	16 GB / GDDR7 / 256 bit	8419.56 ± 35.50	182.43 ± 0.09	933414c	@TinyServal
RTX 6000 Ada	48 GB / GDDR6 / 384 bit	10576.85 ± 530.21	179.47 ± 0.32	b8e09f0	@Hedede
RTX 3090 Ti	24 GB / GDDR6X / 384 bit	6924.01 ± 10.76	172.26 ± 1.31	9c35706	@slaren
RTX PRO 4500 Blackwell	32 GB / GDDR7 / 256 bit	7251.66 ± 92.40	168.90 ± 0.20	becc481	@Hedede
RTX 3090	24 GB / GDDR6X / 384 bit	5560.06 ± 16.28	161.89 ± 0.18	c76b420	@m18coppola
L40	48 GB / GDDR6 / 384 bit	10097.64 ± 671.22	153.76 ± 0.12	ee09828	@Hedede
RTX 4080 SUPER	16 GB / GDDR6X / 256 bit	9439.01 ± 56.75	147.48 ± 1.41	81086cd	@zacharyarnaise
RTX 4080	16 GB / GDDR6X / 256 bit	9205.93 ± 22.31	143.47 ± 0.02	20638e4	@Ristovski
RTX A6000	48 GB / GDDR6 / 384 bit	5662.39 ± 13.87	144.87 ± 0.18	4795c91	@Hedede
RTX 3080	10 GB / GDDR6X / 320 bit	5569.56 ± 14.04	139.95 ± 0.95	9c35706	@slaren
RTX PRO 4000 Blackwell	24 GB / GDDR7 / 192 bit	5674.44 ± 139.53	136.38 ± 0.13	7d77f07	@Hedede
RTX A5000	24 GB / GDDR6 / 384 bit	4552.15 ± 9.68	135.83 ± 0.11	e5155e6	@Hedede
Tesla V100	32 GB / HBM2 / 4096 bit	2973.78 ± 3.62	134.76 ± 0.02	51f5a45	@Hedede
RTX 4070 Ti SUPER	16 GB / GDDR6X / 256 bit	7612.32 ± 37.35	132.85 ± 0.31	9c35706	@Ristovski
A30	24 GB / HBM2e / 3072 bit	3068.72 ± 0.63	131.93 ± 0.18	583cb83	@Hedede
RTX 5070	12 GB / GDDR7 / 192 bit	5783.44 ± 36.95	128.21 ± 2.52	@Spyro000	-
A40	48 GB / GDDR6 / 384 bit	5256.38 ± 19.39	126.24 ± 0.06	3470a5c	@Hedede
Titan V	12 GB / HBM2 / 3072 bit	2481.25 ± 1.31	112.17 ± 0.01	e56abd2	@Hedede
RTX 2080 Ti	11 GB / GDDR6 / 352 bit	3107.61 ± 4.34	109.17 ± 0.07	9c35706	@ariya
Quadro RTX 6000	24 GB / GDDR6 / 384 bit	3053.96 ± 1.37	104.38 ± 0.04	b8e09f0	@Hedede
Quadro RTX 8000	48 GB / GDDR6 / 384 bit	3052.35 ± 5.64	103.63 ± 0.02	b8e09f0	@Hedede
RTX A4500	20 GB / GDDR6 / 320 bit	3453.10 ± 49.19	103.00 ± 0.25	5cdb27e	@aleksyx
RTX 5060 Ti 16 GB	16 GB / GDDR7 / 128 bit	4195.53 ± 1.98	93.46 ± 0.01	89d1029	@mike-llamacpp
RTX 2070 SUPER	8 GB / GDDR6 / 256 bit	2293.29 ± 5.91	87.71 ± 0.29	bc07349	@phstudy
RTX A4000	16 GB / GDDR6 / 256 bit	2807.83 ± 52.44	85.17 ± 0.66	65349f2	@TinyServal
RTX 3060	12 GB / GDDR6 / 192 bit	2407.67 ± 3.73	76.92 ± 0.03	baa9255	@QuantiusBenignus
Titan Xp	12 GB / GDDR5X / 384 bit	1218.12 ± 1.82	73.84 ± 0.04	c4510dc	@Hedede
Quadro RTX 4000	8 GB / GDDR6 / 256 bit	1662.80 ± 2.04	67.62 ± 0.67	7d77f07	@Hedede
RTX 4060 Ti 8 GB	8 GB / GDDR6 / 128 bit	3803.45 ± 70.80	64.03 ± 0.53	89d1029	@mike-llamacpp
Tesla P100	16 GB / HBM2 / 4096 bit	787.36 ± 3.27	61.99 ± 0.00	b8372ee	@Hedede
GTX 1080 Ti	11 GB / GDDR5X / 352 bit	1138.14 ± 2.02	61.38 ± 0.03	9c35706	@ariya
RTX A4000 Ada	20 GB / GDDR6 / 160 bit	3171.86 ± 4.34	61.37 ± 0.01	a74a0d6	@sdwolfz
RTX 2060 SUPER	8 GB / GDDR6 / 256 bit	1563.77 ± 0.51	61.13 ± 0.05	5c0eb5e	@ggerganov
DGX Spark	128 GB / LPDDR5x	3661.37 ± 38.66	56.74 ± 0.03	5acd455	@ggerganov
Tesla P40	24 GB / GDDR5 / 384 bit	1079.66 ± 0.18	53.73 ± 0.05	c76b420	@m18coppola
RTX 2000 Ada	16 GB / GDDR6 / 128 bit	2250.14 ± 5.91	50.71 ± 0.01	756cfea	@DigitalRudeness
Tesla T4	16 GB / GDDR6 / 256 bit	1309.73 ± 1.02	44.03 ± 0.57	d32e03f	@pt13762104
GTX 1660	6 GB / GDDR5 / 192 bit	154.45 ± 0.52	41.43 ± 0.01	9515c61	@ariya
Tesla M40	24 GB / GDDR5 / 384 bit	290.17 ± 0.11	39.98 ± 0.01	97d5117	@Hedede
GTX 1070 Ti	8 GB / GDDR5 / 256 bit	790.52 ± 2.39	37.87 ± 0.00	79c1160	@pebaryan
Jetson AGX Orin	64 GB / LPDDR5 / 256 bit	1171.96 ± 4.70	35.88 ± 0.18	c1b1876	@TinyServal
Tesla P4	8 GB / GDDR5 / 256 bit	529.53 ± 2.12	33.12 ± 0.03	c76b420	@m18coppola
P106-100	6 GB / GDDR5 / 192 bit	438.49 ± 0.38	30.64 ± 0.06	5fd160b	@pebaryan
GTX 1060	6 GB / GDDR5 / 192 bit	446.19 ± 0.81	28.18 ± 0.01	5fd160b	@pebaryan
Quadro T1000	4 GB / GDDR5 / 128 bit	27.46 ± 0.23	27.46 ± 0.23	f6da8cb	@hanabu
Quadro P2000	5 GB / GDDR5 / 160 bit	311.55 ± 0.19	23.76 ± 0.01	baa9255	@TinyServal
Tesla K80	12 GB / GDDR5 / 384 bit	133.36 ± 0.60	14.27 ± 0.32	32732f2	@pebaryan
Quadro P1000	4 GB / GDDR5 / 128 bit	173.82 ± 0.02	13.65 ± 0.14	1e74897	@aleksyx

Apple Silicon の参照基準

#4167 の discussion が後の 3 つと大きく違うのは、より早い段階で統一された見方を作っており、Q4_0 だけでなく F16 や Q8_0 も併記している点です。PP / TG / t/s を理解するうえで役立ちます。

discussion 内での説明は次のとおりです。

PP は prompt processing
TG は text-generation
t/s は tokens per second

本文で確認できる時系列比較の例として、同じ M2 Ultra がバージョンと FA の進化に応じてどう変わったかが示されています。

日時	デバイス	バージョン/説明	帯域 GB/s	GPU コア	F16 PP	F16 TG	Q8_0 PP	Q8_0 TG	Q4_0 PP	Q4_0 TG
2023-11-21	M2 Ultra	8e672ef	800	76	1401.85	41.02	1248.59	66.64	1238.48	94.27
2024-11-12	M2 Ultra	86ed72d + FA	800	76	1525.95	43.15	1368.18	73.11	1391.78	108.80
2025-08-02	M2 Ultra	5c0eb5e + FA	800	76	1561.35	43.24	1386.97	73.35	1412.42	109.41

デバイス	Q4_0 PP	Q4_0 TG	Q8_0 PP	Q8_0 TG	F16 PP	F16 TG
M1 Pro 16 GPU	266.25	36.41	270.37	22.34	302.14	12.75
M2 Ultra 76 GPU	1238.48	94.27	1248.59	66.64	1401.85	41.02
M3 Max 40 GPU	690.99	65.85	749.37	43.00	794.26	25.27

Apple の系統はここでは全文を展開せず、以降は指定された 3 種類のディスクリート GPU バックエンドのランキングを中心に見ます。

ROCm / HIP 完全ランキング

Llama 2 7B, Q4_0, no FA

Chip	Memory	pp512 t/s	tg128 t/s	Commit	Thanks to
Instinct MI300X	192 GB / HBM3 / 8192 bit	11476.40 ± 72.79	232.92 ± 0.53	ee3a9fc	@yeahdongcn
RX 7900 XTX	24 GB / GDDR6 / 384 bit	3552.27 ± 101.96	167.11 ± 0.50	2f0c2db	@Diablo-D3
Instinct MI210	64 GB / HBM2e / 4096 bit	2486.22 ± 9.58	124.51 ± 0.04	8160b38	@65a
Pro W7900	48 GB / GDDR6 / 384 bit	3213.17 ± 80.47	121.18 ± 0.06	8160b38	@65a
RX 7900 XT	20 GB / GDDR6 / 320 bit	3098.38 ± 24.02	116.15 ± 0.06	1e15bfd	@AdamNiederer
RX 9070	16 GB / GDDR6 / 256 bit	2381.77 ± 3.68	114.48 ± 0.60	d0660f2	@andj1210
Instinct MI100	32 GB / HBM2 / 4096 bit	2732.83 ± 1.98	110.48 ± 0.14	9c35706	@firefox42
RX 9070 XT	16 GB / GDDR6 / 256 bit	5055.19 ± 109.58	101.27 ± 0.27	583cb83	@Hadrianneue
RX 7800 XT	16 GB / GDDR6 / 256 bit	2151.81 + 17.94	100.94 + 0.10	00131d6	@olegshulyakov
Instinct MI50	32 GB / HBM2 / 4096 bit	1057.24 ± 0.53	98.95 ± 0.25	97d5117	@wtarreau
RX 7900 GRE	16 GB / GDDR6 / 256 bit	1456.98 ± 12.39	96.07 ± 0.10	6fa3b55	@MihaiBojescu
AI PRO R9700	32 GB / GDDR6 / 256 bit	4443.54 ± 339.25	93.84 ± 0.26	bd4ef13	@gogich77
Instinct MI60	32 GB / HBM2 / 4096 bit	1289.11 ± 0.62	91.46 ± 0.13	504af20	@Said-Akbar
RX 6900 XT	16 GB / GDDR6 / 256 bit	1889.84 ± 31.21	88.49 ± 0.00	a972fae	@notgood
Pro VII	16 GB / HBM2 / 4096 bit	1064.99 ± 1.18	87.45 ± 0.04	2739a71	@8XXD8
RX 6800 XT	16 GB / GDDR6 / 256 bit	1447.07 ± 1.36	83.92 ± 0.03	79c1160	@MrLavender
Pro V620	32 GB / GDDR6 / 256 bit	1803.65 ± 2.54	74.66 ± 0.01	5c0eb5e	@samteezy
RX 9060 XT	16 GB / GDDR6 / 256 bit	1419.67 ± 3.64	67.58 ± 0.24	a0e13dc	@lcy0321
RX 5700 XT	8 GB / GDDR6 / 256 bit	354.17 ± 0.18	67.55 ± 0.04	c05e8c9	@daniandtheweb
Instinct MI25	16 GB / HBM2 / 2048 bit	409.83 ± 0.23	63.94 ± 0.06	2739a71	@8XXD8
AI Max+ 395	128 GB / LPDDR5	911.36 ± 1.79	50.01 ± 0.07	e60f241	@firefox42
RX 7600 XT	16 GB / GDDR6 / 128 bit	1099.64 ± 2.05	48.58 ± 0.06	9c35706	@wbruna
RX Vega 64	8 GB / HBM2 / 2048 bit	240.68 ± 0.09	48.46 ± 0.09	ec428b0	@davispuh
Radeon 8060S	System Shared / DDR5	351.36 ± 0.67	47.97 ± 0.33	1d0125b	@hspak
Radeon 880M	System Shared / DDR5	163.25 ± 13.86	12.97 ± 1.63	c55d53a	@Hedede

Llama 2 7B, Q4_0, with FA

Chip	Memory	pp512 t/s	tg128 t/s	Commit	Thanks to
Instinct MI300X	192 GB / HBM3 / 8192 bit	11945.97 ± 54.29	218.53 ± 0.09	ee3a9fc	@yeahdongcn
RX 7900 XTX	24 GB / GDDR6 / 384 bit	3874.25 ± 11.92	170.12 ± 0.56	2f0c2db	@Diablo-D3
Pro W7900	48 GB / GDDR6 / 384 bit	3472.86 ± 52.86	127.43 ± 0.12	8160b38	@65a
Instinct MI210	64 GB / HBM2e / 4096 bit	2571.82 ± 2.89	130.18 ± 0.06	8160b38	@65a
RX 9070	16 GB / GDDR6 / 256 bit	2452.68 ± 1.33	115.32 ± 0.52	d0660f2	@andj1210
RX 7900 XT	20 GB / GDDR6 / 320 bit	3261.75 ± 9.09	112.30 ± 0.06	1e15bfd	@AdamNiederer
Instinct MI50	32 GB / HBM2 / 4096 bit	1129.43 ± 0.15	105.82 ± 0.07	97d5117	@wtarreau
Instinct MI100	32 GB / HBM2 / 4096 bit	2755.00 ± 3.68	104.71 ± 0.10	9c35706	@firefox42
AI PRO R9700	32 GB / GDDR6 / 256 bit	4773.07 ± 49.30	97.98 ± 0.13	bd4ef13	@gogich77
RX 7900 GRE	16 GB / GDDR6 / 256 bit	1598.79 ± 11.48	97.53 ± 0.06	6fa3b55	@MihaiBojescu
RX 9070 XT	16 GB / GDDR6 / 256 bit	4903.51 ± 96.36	97.28 ± 0.13	583cb83	@Hadrianneue
RX 7800 XT	16 GB / GDDR6 / 256 bit	2304.63 + 2.85	95.99 + 0.21	00131d6	@olegshulyakov
RX 6900 XT	16 GB / GDDR6 / 256 bit	1948.31 ± 13.51	85.04 ± 0.02	a972fae	@notgood
Pro V620	32 GB / GDDR6 / 256 bit	1256.86 ± 0.55	70.83 ± 0.02	5c0eb5e	@samteezy
RX 9060 XT	16 GB / GDDR6 / 256 bit	1479.27 ± 0.71	65.42 ± 0.19	a0e13dc	@lcy0321
RX 5700 XT	8 GB / GDDR6 / 256 bit	314.17 ± 0.29	62.02 ± 0.05	c05e8c9	@daniandtheweb
AI Max+ 395	128 GB / LPDDR5	1003.53 ± 2.91	49.87 ± 0.02	e60f241	@firefox42
Radeon 8060S	System Shared / DDR5	366.08 ± 1.44	48.97 ± 0.15	1d0125b	@hspak
RX 7600 XT	16 GB / GDDR6 / 128 bit	1199.16 ± 1.07	47.65 ± 0.06	9c35706	@wbruna
RX Vega 64	8 GB / HBM2 / 2048 bit	153.17 ± 0.72	42.46 ± 0.40	ec428b0	@davispuh
Radeon 880M	System Shared / DDR5	213.31 ± 14.05	16.16 ± 1.41	c55d53a	@Hedede

Vulkan 完全ランキング

Llama 2 7B, Q4_0, no FA

Chip	pp512 t/s	tg128 t/s	Commit	Comments
Nvidia RTX 5090	10381.64 ± 508.84	263.63 ± 0.91	ca71fb9	coopmat2
AMD Radeon RX 7900 XTX	3531.93 ± 31.74	191.28 ± 0.20	2f0c2db
Nvidia RTX 4090	9452.03 ± 187.70	187.97 ± 0.21	4ae88d0	coopmat2
Nvidia RTX 5080	7444.99 ± 20.11	185.10 ± 0.54	f6b533d	coopmat2
Nvidia A100	6389.86 ± 4.83	160.78 ± 0.16	2257758	coopmat2
Nvidia RTX 3090	4298.97 ± 10.59	160.13 ± 0.25	4ae88d0	coopmat2
Nvidia RTX 4080 Super	7101.18 ± 269.79	147.13 ± 5.64	81086cd	coopmat2
Nvidia RTX 3080	4287.11 ± 55.50	139.15 ± 0.05	7c7d6ce	coopmat2
Nvidia RTX A5000	3641.55 ± 9.05	139.89 ± 0.69	4ae88d0	coopmat2
AMD Radeon RX 9070 XT	5036.04 ± 88.16	137.11 ± 0.02	e9fd8dc
Nvidia RTX 5070 Ti	6213.63 ± 27.72	135.63 ± 0.18	d13d0f6	coopmat2
AMD Radeon AI Pro R9700	4036.04 ± 34.58	130.19 ± 0.39	3191462
Nvidia Tesla V100	1391.39 ± 1.19	129.58 ± 0.58	7d77f07
Nvidia RTX 4070 Ti Super	6099.18 ± 154.30	129.45 ± 0.18	4ae88d0	coopmat2
AMD Radeon RX 7900 XT	2941.58 ± 17.17	123.18 ± 0.40	71e74a3
AMD Radeon RX 9070	3164.10 ± 66.84	119.71 ± 3.40	21c17b5
AMD Radeon RX 7800 XT	2017.33 ± 19.30	118.27 ± 0.27	4fdbc1e
AMD Radeon RX 7900 GRE	2336.31 ± 7.52	116.11 ± 0.26	4b2a477
Apple M3 Ultra	1116.83 ± 0.55	115.54 ± 0.78	2d451c8	MoltenVK
Intel Arc Pro B70	3379.00 ± 47.92	112.02 ± 1.08	b863507
Nvidia Titan V	984.36 ± 4.13	108.86 ± 0.28	e56abd2
AMD Radeon Pro VII	1078.54 ± 0.86	107.82 ± 0.14	N/A
AMD Radeon RX 6900 XT	1837.21 ± 25.44	104.60 ± 0.30	a972fae
Intel Arc Pro A60	2261.11 ± 9.53	104.25 ± 0.07	97d5117
AMD Radeon RX 6800 XT	1752.92 ± 1.71	100.32 ± 0.97	N/A
AMD Radeon VII	1059.14 ± 0.56	101.19 ± 0.53	77d6ae4
Nvidia RTX 2080 Ti	1888.24 ± 9.20	97.58 ± 6.60	N/A
AMD Radeon RX 6800	1698.69 ± 0.80	95.61 ± 0.19	4b385bf
AMD Radeon Pro W6800X Duo	687.71 ± 4.33	94.82 ± 0.12	N/A
Nvidia RTX 5060 Ti	3460.92 ± 7.16	93.51 ± 0.15	89f10ba	coopmat2
Nvidia RTX 4070	3179.37 ± 46.16	92.29 ± 0.28	9a48399
AMD Radeon Pro W6800X	510.80 ± 0.13	86.47 ± 0.46	13b4548	MoltenVK
AMD Radeon RX 6700 XT	1051.20 ± 0.98	83.88 ± 0.08	6d75883
AMD Radeon RX 6750 XT	1040.58 ± 0.35	81.98 ± 0.03	228f34c
AMD Radeon Pro V620	1595.32 ± 1.59	81.78 ± 0.06	03d4698
Nvidia RTX 3070	2113.02 ± 7.38	78.71 ± 0.13	1b8fb81
AMD Radeon Instinct MI60	369.26 ± 2.48	78.16 ± 1.40	504af20
Nvidia RTX 3060	1815.70 ± 5.85	75.94 ± 0.80	92c0b38	coopmat2
Apple M4 Max	724.77 ± 20.93	75.02 ± 0.14	1ece0cb6
Nvidia Tesla T10	1692.70 ± 2.05	75.01 ± 0.21	7f76692	coopmat2
Nvidia RTX A4000	2248.14 ± 7.59	73.74 ± 0.08	f5245b5	coopmat2
AMD Radeon RX 5700 XT	529.69 ± 0.26	70.73 ± 0.04	4fdbc1e
AMD Radeon RX 9060 XT	2141.67 ± 6.87	70.54 ± 0.74	ed52f36
Intel Arc B580	620.94 ± 15.33	70.14 ± 0.28	7f76692
AMD Radeon Pro V540	583.88 ± 6.56	69.64 ± 0.24	9da3dcd
AMD Radeon Pro W5700	449.85 ± 0.46	68.55 ± 0.15	23bc779
Intel Arc Pro B60	522.36 ± 3.60	68.55 ± 0.01	516a4ca
Nvidia GTX 1080 Ti	540.69 ± 0.71	64.99 ± 0.08	360d653
Nvidia RTX 2070 Super	1199.13 ± 7.70	64.64 ± 0.20	b7552cf
Nvidia RTX 3070 Mobile	1689.40 ± 19.57	63.64 ± 0.39	ceff6bb	coopmat2
Nvidia Tesla P100	678.14 ± 1.40	63.16 ± 0.06	eec1e33
AMD BC-250	370.66 ± 0.04	62.32 ± 0.32	5886f4f
AMD Radeon RX 6650 XT	1029.52 ± 1.21	62.14 ± 0.02	dbb852b
Nvidia RTX 4060 Mobile	2135.66 ± 23.18	59.53 ± 0.03	a5c07dc	coopmat2
Nvidia Tesla P40	488.06 ± 0.27	59.36 ± 0.16	N/A
Nvidia GTX 1660 Ti Mobile	511.67 ± 2.85	56.60 ± 0.07	b43556e
AMD Radeon Instinct MI25	439.42 ± 0.34	54.69 ± 0.03	2739a71
AMD Radeon RX 6600 XT	574.65 ± 0.86	53.92 ± 0.11	091592d
AMD Ryzen AI Max+ 395	1288.96 ± 6.49	53.59 ± 0.38	7f76692
AMD Radeon RX 7600 XT	840.85 ± 3.02	53.02 ± 0.01	01d8eaa
Intel Arc A770	1073.85 + 29.68	52.56 + 0.11	a69d54f
Nvidia GB10	2737.79 ± 19.56	52.28 ± 0.03	b9da444	coopmat2
AMD FirePro S9300 x2	247.26 ± 0.43	51.86 ± 0.11	eec1e33	Split across two GPUs
AMD Radeon RX 6600	761.89 ± 1.76	50.63 ± 0.02	b1c70e2
AMD Radeon RX Vega 56	439.87 ± 0.61	50.23 ± 0.14	92c0b38
Intel Arc B570	913.95 ± 0.90	49.64 ± 0.03	7f76692
Nvidia RTX 3060 Mobile	1059.76 ± 3.54	49.03 ± 0.13	dbb3a47
AMD Radeon RX 6800M	861.99 ± 7.67	48.71 ± 0.71	8e6f8bc
AMD Radeon RX 6600M	605.59 ± 0.65	48.21 ± 0.07	fe5b78c
Intel Arc A770M	875.92 ± 2.16	47.69 ± 0.16	eeee367
Nvidia P104-100	311.90 ± 0.22	46.18 ± 0.05	eec1e33
AMD Radeon RX Vega 64	356.08 ± 0.09	45.73 ± 0.18	ec428b0
Nvidia RTX A2000	1245.19 ± 8.76	45.52 ± 0.54	b1afcab	coopmat2
AMD Radeon RX 7600M XT	459.39 ± 2.34	45.28 ± 0.10	b9ab0a4	eGPU
AMD Radeon Pro V340	375.41 ± 0.24	45.16 ± 0.06	9da3dcd	Split across two GPUs
Nvidia GTX 1070 Ti	297.50 ± 0.54	42.86 ± 1.20	860a9e4	eGPU
Intel Arc A750	1075.94 ± 13.89	42.66 ± 0.18	c1b1876
Nvidia RTX 4050 Mobile	1154.28 + 15.76	41.89 + 0.10	d79d8f3
Nvidia GTX 1070	321.57 ± 0.93	41.48 ± 0.09	eec1e33
Intel Arc Pro B50	193.50 ± 0.24	39.99 ± 0.10	7b43f55
Nvidia Tesla M40	92.48 ± 0.02	39.35 ± 1.22	b8372ee
AMD Radeon RX 580	258.03 ± 0.71	39.32 ± 0.03	de4c07f
AMD Radeon RX 470	218.07 ± 0.56	38.63 ± 0.21	e288693
AMD Radeon Pro W5500	315.39 ± 3.76	36.82 ± 0.38	860a9e4
AMD Radeon RX 480	248.66 ± 0.28	34.71 ± 0.14	3b15924
Apple M2 Ultra	205.98 ± 0.02	34.34 ± 0.12	dbb852b	Asahi Linux
Nvidia GTX 980	186.24 ± 0.09	33.90 ± 0.51	860a9e4
Nvidia P106-100	183.78 ± 0.26	29.77 ± 0.04	23bc779
AMD FirePro W8100	155.22 ± 0.17	29.52 ± 0.05	4536363
Nvidia Tesla P4	265.54 ± 0.21	28.03 ± 0.14	24d2ee0
AMD Radeon RX 6500 XT	255.25 ± 0.35	27.81 ± 0.10	g9fdfcd
Apple M3	263.70 ± 0.02	26.39 ± 0.14	b9ab0a4	MoltenVK
AMD FirePro S10000	94.78 ± 0.02	25.32 ± 0.02	914a82d	Split across two GPUs
Nvidia Quadro P2000	169.55 ± 0.17	23.05 ± 0.03	63f8fe0
Intel Core Ultra 200 Series	544.95 ± 4.15	22.49 ± 0.09	cea560f
AMD Ryzen AI 9 300 Series	479.07 ± 0.41	22.41 ± 0.18	N/A
AMD Ryzen 6000 Series	240.89 ± 0.52	21.26 ± 0.08	ee09828
Apple M2 Pro	62.70 ± 0.03	20.95 ± 0.11	1fe0029	Asahi Linux
Nvidia GTX 1050 Ti	136.42 ± 0.67	20.96 ± 0.21	2f0c2db
AMD Ryzen 8000 Series	266.19 ± 1.36	20.53 ± 0.08	a5c07dc
AMD Ryzen 7000 Series	281.62 ± 1.56	19.91 ± 0.07	ebce03e
AMD Ryzen Z1 Extreme	199.36 ± 7.02	18.77 ± 0.02	53ff6b9
AMD FirePro D700	69.95 ± 0.04	16.62 ± 0.01	d3bd719	MoltenVK, running in FP16 mode on FP32 only chip
AMD Radeon Pro WX 4100	78.79 ± 0.10	16.05 ± 0.07	860a9e4
Apple M2	50.79 ± 0.16	13.50 ± 0.02	8c0d6bb	Asahi Linux
Apple M1	38.29 ± 0.00	12.47 ± 0.03	2370665	Asahi Linux
AMD Ryzen 5000 Series	90.55 ± 0.08	10.98 ± 0.07	d84635b
Intel Core 1100 Series	187.20 ± 1.78	10.39 ± 0.04	abb9f3c
AMD Radeon RX 550	52.66 ± 0.49	10.20 ± 0.01	N/A
AMD Ryzen 4000 Series	103.87 ± 0.02	9.63 ± 0.01	4b385bf
Nvidia Tesla K80	89.46 ± 0.10	9.39 ± 0.06	5d46bab	Running on single GPU
Nvidia Tesla K40	64.37 ± 0.09	9.30 ± 0.19	eec1e33
MediaTek Dimensity 9400	38.36 ± 15.15	8.92 ± 0.06	b9ab0a4	GPU supports coopmat but pp512 is faster with it turned off
Intel Core Ultra 100 Series	185.51 ± 0.22	8.21 ± 0.07	1d72c84
AMD Ryzen 3000 Series	48.63 ± 0.10	8.49 ± 0.01	1fe0029
CIX CD8180	2.80 ± 0.01	5.51 ± 0.00	4dca015
Intel Core 1000 Series	25.58 ± 0.00	4.25 ± 0.18	N/A
Intel Core 8000 Series	25.43 ± 0.17	3.35 ± 0.03	c4df49a
Intel N150	28.84 ± 0.02	2.93 ± 0.00	4f63cd7

Llama 2 7B, Q4_0, FA enabled

Chip	pp512 t/s	tg128 t/s	Commit	Comments
Nvidia RTX 5090	11796.38 ± 601.36	273.68 ± 0.52	ca71fb9	coopmat2
AMD Radeon RX 7900 XTX	3332.90 ± 11.47	195.30 ± 0.23	2f0c2db
Nvidia RTX 5080	8054.59 ± 35.68	192.17 ± 0.21	f6b533d	coopmat2
Nvidia RTX 4090	10830.41 ± 36.25	190.10 ± 0.31	4ae88d0	coopmat2
Nvidia A100	7064.40 ± 1.63	170.56 ± 0.02	2257758	coopmat2
Nvidia RTX 3090	4732.33 ± 4.80	162.28 ± 0.21	4ae88d0	coopmat2
Nvidia RTX 4080 Super	8007.37 ± 46.03	150.20 ± 0.26	81086cd	coopmat2
Nvidia RTX 3080	4913.83 ± 21.52	145.74 ± 0.16	7c7d6ce	coopmat2
Nvidia Tesla V100	1411.25 ± 2.12	142.13 ± 0.03	7d77f07
Nvidia RTX A5000	4071.22 ± 13.13	140.43 ± 0.22	4ae88d0	coopmat2
AMD Radeon RX 9070 XT	4911.74 ± 28.52	138.20 ± 0.18	e9fd8dc
Nvidia RTX 5070 Ti	6764.53 ± 11.95	135.65 ± 0.02	d13d0f6	coopmat2
AMD Radeon AI Pro R9700	4333.83 ± 29.36	130.90 ± 0.12	3191462
AMD Radeon RX 7900 XT	3043.93 ± 10.42	124.20 ± 0.09	71e74a3
AMD Radeon RX 7800 XT	2094.64 ± 14.38	119.63 ± 0.13	4fdbc1e
AMD Radeon RX 9070	3277.24 ± 18.17	119.55 ± 0.06	21c17b5
AMD Radeon RX 7900 GRE	2402.07 ± 22.50	116.77 ± 0.08	4b2a477
Apple M3 Ultra	1115.55 ± 0.75	115.99 ± 0.12	2d451c8	MoltenVK
Intel Arc Pro B70	3314.53 ± 17.95	111.63 ± 0.05	b863507
Nvidia Titan V	792.74 ± 4.30	109.21 ± 0.72	e56abd2
AMD Radeon Pro VII	783.94 ± 0.77	108.45 ± 0.48	N/A
AMD Radeon RX 6900 XT	1761.93 ± 4.75	106.15 ± 0.04	a972fae
Nvidia RTX 2080 Ti	1936.25 ± 32.08	100.99 ± 0.24	N/A
AMD Radeon RX 6800 XT	1704.79 ± 0.71	100.50 ± 0.06	N/A
AMD Radeon Pro W6800X Duo	795.28 ± 0.72	100.08 ± 0.02	N/A
Nvidia RTX 5060 Ti	3912.65 ± 5.86	97.01 ± 0.14	89f10ba	coopmat2
AMD Radeon RX 6800	1749.46 ± 3.36	96.65 ± 0.48	4b385bf
Nvidia RTX 4070	4293.57 ± 27.70	91.49 ± 0.89	9a48399	coopmat2
AMD Radeon RX 6750 XT	997.05 ± 0.45	82.29 ± 0.06	228f34c
AMD Radeon RX 6700 XT	1010.90 ± 12.89	81.86 ± 0.19	6d75883
Nvidia RTX 3060	2012.88 ± 10.12	80.59 ± 0.02	92c0b38	coopmat2
AMD Radeon Pro V620	1556.31 ± 2.82	79.24 ± 0.09	03d4698
Nvidia RTX A4000	2482.74 ± 26.05	76.07 ± 0.08	f5245b5	coopmat2
Nvidia Tesla T10	1840.14 ± 1.22	76.05 ± 0.13	7f76692	coopmat2
AMD Radeon RX 5700 XT	538.31 ± 0.35	74.43 ± 0.03	4fdbc1e
Intel Arc B580	419.49 ± 3.37	72.00 ± 0.24	7f76692
Apple M4 Max	557.46 ± 26.87	71.79 ± 4.16	1ece0cb6
AMD Radeon Pro W5700	446.98 ± 0.39	71.30 ± 0.24	23bc779
Intel Arc Pro B60	274.76 ± 0.27	70.54 ± 0.03	516a4ca
AMD Radeon RX 9060 XT	1915.41 ± 7.90	70.52 ± 0.16	ed52f36
Nvidia Tesla P100	685.51 ± 0.88	66.48 ± 0.02	eec1e33
AMD Radeon RX 6650 XT	1088.90 ± 0.40	64.53 ± 0.75	dbb852b
Nvidia GTX 1080 Ti	529.96 ± 0.38	64.63 ± 0.10	360d653
AMD BC-250	356.87 ± 1.24	63.14 ± 0.09	5886f4f
Nvidia RTX 3070 Mobile	1832.07 ± 57.14	62.92 ± 0.37	ceff6bb	coopmat2
Nvidia RTX 4060 Mobile	2358.03 ± 12.17	60.01 ± 0.08	a5c07dc	coopmat2
Nvidia Tesla P40	484.37 ± 0.27	59.22 ± 0.15	N/A
Nvidia GTX 1660 Ti Mobile	514.34 ± 0.88	57.30 ± 0.42	b43556e
AMD Radeon RX 7600 XT	1024.38 ± 7.56	56.11 ± 0.02	01d8eaa
AMD FirePro S9300 x2	243.33 ± 0.22	55.64 ± 0.06	eec1e33	Split across two GPUs
Nvidia GB10	3279.89 ± 26.78	53.64 ± 0.05	b9da444	coopmat2
AMD Radeon RX 6600	808.76 ± 0.15	53.24 ± 0.03	b1c70e2
Intel Arc A770	1119.68 + 30.25	53.07 + 0.09	a69d54f
AMD Ryzen AI Max+ 395	1357.07 ± 10.94	53.00 ± 0.13	7f76692
AMD Radeon RX Vega 56	428.54 ± 0.50	52.66 ± 0.03	92c0b38
Intel Arc B570	288.51 ± 0.09	50.49 ± 0.05	7f76692
Nvidia P104-100	325.30 ± 0.25	48.64 ± 0.04	eec1e33
AMD Radeon Pro V340	360.23 ± 0.74	47.54 ± 0.06	9da3dcd	Split across two GPUs
AMD Radeon RX 6800M	784.16 ± 2.76	49.06 ± 0.34	8e6f8bc
AMD Radeon RX Vega 64	320.12 ± 0.22	47.06 ± 0.01	ec428b0
Nvidia RTX A2000	1361.85 ± 3.26	45.69 ± 0.20	b1afcab	coopmat2
Intel Arc A770M	384.74 ± 0.78	45.68 ± 0.06	eeee367
Intel Arc A750	303.37 ± 1.44	43.96 ± 0.03	c1b1876
Nvidia GTX 1070 Ti	292.85 ± 0.23	43.42 ± 0.34	860a9e4	eGPU
Nvidia GTX 1070	330.84 ± 1.02	43.33 ± 0.06	360d653
Nvidia Tesla M40	93.35 ± 0.01	41.68 ± 0.01	b8372ee
Intel Arc Pro B50	132.48 ± 0.04	41.02 ± 0.04	7b43f55
AMD Radeon RX 470	197.26 ± 0.27	37.28 ± 0.11	3769fe6
AMD Radeon RX 480	194.52 ± 0.61	37.23 ± 0.09	0bcb40b
Apple M2 Ultra	198.83 ± 0.85	198.83 ± 0.85	dbb852b	Asahi Linux
Nvidia GTX 980	180.97 ± 0.74	34.16 ± 0.10	860a9e4
Nvidia P106-100	183.40 ± 0.34	30.79 ± 0.32	23bc779
AMD FirePro W8100	140.52 ± 0.34	29.28 ± 0.14	4536363
Nvidia Tesla P4	287.14 ± 0.29	28.37 ± 0.24	24d2ee0
Nvidia Quadro P2000	181.71 ± 0.12	23.77 ± 0.02	63f8fe0
Intel Core Ultra 200 Series	536.48 ± 1.27	23.05 ± 0.04	cea560f
AMD Ryzen AI 9 300 Series	532.59 ± 3.55	22.31 ± 0.06	N/A
AMD Ryzen 6000 Series	277.91 ± 0.37	21.15 ± 0.09	ee09828
Apple M2 Pro	58.86 ± 0.02	20.97 ± 0.03	1fe0029	Asahi Linux
AMD Ryzen 8000 Series	297.39 ± 1.22	20.59 ± 0.38	a5c07dc
AMD Ryzen 7000 Series	312.85 ± 2.51	20.09 ± 0.35	835b2b9
Nvidia GTX 1050 Ti	127.54 ± 1.03	20.08 ± 0.17	2f0c2db
AMD Radeon Pro WX 4100	75.59 ± 0.19	16.56 ± 0.04	860a9e4
Apple M1	35.93 ± 0.00	12.85 ± 0.02	2370665	Asahi Linux
Apple M2	46.81 ± 0.08	12.25 ± 2.30	8c0d6bb	Asahi Linux
AMD Ryzen 5000 Series	79.06 ± 0.01	10.75 ± 0.00	5d195f1
Intel Core 1100 Series	174.77 ± 4.47	10.58 ± 0.03	abb9f3c
Nvidia Tesla K40	64.37 ± 0.02	9.92 ± 0.06	eec1e33
AMD Ryzen 4000 Series	113.32 ± 0.01	9.87 ± 0.01	4b385bf
Nvidia Tesla K80	88.26 ± 0.19	9.49 ± 0.01	5d46bab	Running on single GPU
AMD Ryzen 5 3000 Series	47.41 ± 0.14	8.47 ± 0.01	1fe0029
Intel Core Ultra 100 Series	77.66 ± 2.75	7.75 ± 0.05	2e89f76
Intel Core 8000 Series	25.55 ± 0.04	3.35 ± 0.02	c4df49a
Intel N150	25.59 ± 0.00	2.91 ± 0.00	4f63cd7

これらの表の使い方

GPU を買いたい、または手元のマシンがおおよそどの位置にあるかを知りたいだけなら、実用的な読み方は次の 3 ステップです。

まず tg128 と pp512 のどちらを重視するかを見る。
日常会話、コーディング、チャットの体感なら tg128 を優先します。長いコンテキストの処理、バッチ処理、サーバー側で大量の prompt をさばく用途なら pp512 を見るべきです。
次に実際に使うバックエンドを見る。
Nvidia なら通常 CUDA が実際の上限に近く、AMD なら ROCm と Vulkan を先に照合します。クロスプラットフォーム互換を重視する場合は Vulkan が参考になります。
最後に FA を見る。
多くの GPU では FA 有効時に pp512 がより大きく伸びますが、tg128 が同じだけ伸びるとは限りません。単一の最高スコアだけで判断しないほうが安全です。

ひと言でまとめると

同じ llama.cpp ベンチマークでも、pp512、tg128、Q4_0、FA、CUDA / ROCm / Vulkan はそれぞれまったく違う軸を表します。先に条件を切り分けてから数字を見ることで、ランキングに意味が出ます。

最短で覚えるなら、次のとおりです。

CUDA は現時点で全体的に最も強い
ROCm はハイエンド AMD GPU でかなり戦える
Vulkan は対応範囲が最も広く、古い GPU、内蔵 GPU、Intel Arc、Apple Asahi まで比較対象がある
tg128 は pp512 より日常の実際の体感に近い

元データ

CUDA discussion #15013: https://github.com/ggml-org/llama.cpp/discussions/15013
Apple Silicon discussion #4167: https://github.com/ggml-org/llama.cpp/discussions/4167
ROCm discussion #15021: https://github.com/ggml-org/llama.cpp/discussions/15021
Vulkan discussion #10879: https://github.com/ggml-org/llama.cpp/discussions/10879

GPU 推論速度テストでよく見る指標の意味: FA、pp512、tg128、Q4_0 とは何か

Thu, 23 Apr 2026 00:15:00 +0800

ローカル LLM や GPU 推論速度テストを見始めると、すぐに FA、pp512、tg128、Q4_0 といった略称に出会います。どれも性能指標のように見えますが、文脈がないとかなりわかりにくいです。

たとえば、次のような行を見かけることがあります。

`1`	`CUDA Scoreboard for Llama 2 7B, Q4_0 (no FA)`

さらにその下には、

1
2

pp512 t/s
tg128 t/s

のような表示が並びます。

これらを分解して理解しないままだと、この種の速度テストが何を測っているのか、また異なる GPU の結果をどう比較すべきかが見えてきません。

この記事では、どの GPU を買うべきかではなく、GPU 推論速度テストでよく出てくる指標そのものを整理します。

まずタイトル行全体が何を言っているのか

CUDA Scoreboard for Llama 2 7B, Q4_0 (no FA) のような一行には、すでにかなり多くの前提が含まれています。

少なくとも次の四つの情報があります。

CUDA: NVIDIA GPU の CUDA 経路で測っている
Llama 2 7B: テスト対象は Llama 2 の 7B モデル
Q4_0: モデルは 4-bit 量子化形式
no FA: Flash Attention を有効にしていない

つまりこれは要するに、

「NVIDIA GPU 上で、ある量子化済み LLM を、特定の推論経路で動かしたときの速度テスト」

という意味になります。

FA とは何か: Flash Attention

ここでいう FA は Flash Attention の略です。

これは大規模モデルの学習や推論で非常に重要な最適化のひとつで、主に Attention 計算の実装を高速化するための技術です。Transformer 系モデルでは、Attention 部分が最も重い処理のひとつだからです。

従来の Attention 実装には次のような問題があります。

グローバルメモリの読み書きが多い
中間結果が増えやすい
メモリと演算コアの間でデータ移動が多い
コンテキストが長いほど負担が重くなる

Flash Attention は計算順序を工夫し、より多くの処理を高速なメモリ階層の中で完結させることで、この負担を減らします。

その典型的な効果は次の三つです。

速くなる
メモリ使用量が減る
数学的には通常の Attention と等価で、精度を落とす近道ではない

そのため、現在の推論・学習系フレームワークでは重要な最適化として扱われています。

no FA とは何か

FA が Flash Attention なら、no FA は単純に Flash Attention を使っていないという意味です。

つまり、そのベンチマークはより伝統的な Attention 実装で測られています。

なぜわざわざ no FA と書くのかというと、主に次の理由があります。

比較用の基準として残したい
ハードウェアやソフトウェアの都合で FA を使えないケースがある
条件の違うスコアを混ぜて読まれないようにしたい

したがって no FA は「GPU が弱い」という意味ではありません。より正確には、

「このスコアは Flash Attention を使わない条件で測られた」

という意味です。

Q4_0 とは何か: 量子化形式

Q4_0 は 4-bit 量子化形式のひとつです。

LLM の元の重みは通常、こんな低精度では保存されていません。そのままではサイズが大きすぎるため、量子化によって重みをより少ない bit 数で表現し、一般的な GPU でも動かしやすくします。

ざっくり言えば、

Q: Quantization
4: 4-bit
_0: 具体的な量子化方式の識別

という理解で十分です。

重要なのは、量子化によって

モデルサイズが縮む
VRAM 要求が下がる
そのままでは載らないモデルも動かしやすくなる

という点です。

つまり Llama 2 7B, Q4_0 は、「7B モデル」ではあるものの、「4-bit 量子化された 7B モデル」を意味しています。

pp512 t/s とは何か

pp512 は通常、

Prompt Processing 512 tokens

を意味します。

これは入力プロンプトを処理する速度の指標で、単位は t/s、つまり tokens per second です。

ここでの 512 は、テスト時の入力長が 512 token だったことを表しています。

この指標が測っているのは「しゃべる速さ」ではなく、モデルが回答を始める前に、入力内容を読み込んで計算する速さです。言い換えると、「まずこちらの入力を読む段階」のスループットです。

この段階の大きな特徴は、並列性が高いことです。

入力系列はまとめて処理しやすいので、GPU はこの場面では高い並列度を活かせます。そのため pp512 の値は非常に大きくなることが多く、初めて見ると少し不自然に感じるほどです。

たとえば

`1`	`pp512 ≈ 14000 t/s`

のような値が出ても不思議ではありません。これは「入力処理の吞吐量」を測っているのであって、逐次生成の速さを測っているわけではないからです。

tg128 t/s とは何か

tg128 は通常、

Text Generation 128 tokens

を意味します。

これは 128 token を連続生成したときの平均生成速度で、同じく単位は t/s です。

この指標は、私たちが普段感じる「モデルの返答速度」により近いです。実際に出力フェーズを測っているからです。

ただし pp512 との最大の違いは、テキスト生成が一般に自己回帰的であることです。

つまり、

まず 1 個目の token を出す
それが決まってから 2 個目を出す
さらにその後に 3 個目を出す

という順番になります。

そのため、入力処理のような大規模並列はかけにくく、速度はずっと低くなります。

だからこそ、

pp512 は数万 t/s
tg128 は数百 t/s

といった差が普通に起こります。

これは測定ミスではなく、そもそも別の性質の処理を測っているためです。

なぜ pp512 と tg128 の差がこんなに大きいのか

ここは多くの人が最初に引っかかるポイントです。

一言で言えば、

pp512 は並列吞吐、tg128 は逐次生成性能を見ているからです。

もう少し丁寧に言うと、

入力処理は並列化しやすい
出力生成はトークンごとの逐次性が強い
生成側はメモリ帯域やキャッシュ効率の影響を受けやすい
そのため生成速度は入力処理よりかなり低くなりやすい

これにより、GPU 間比較でも面白い現象が起きます。

pp512 では一方が勝つ
tg128 では別の GPU が少し速い

ということがあり得るのです。

これは矛盾ではなく、一方がピーク算力寄り、他方が実際の生成経路での帯域・遅延特性に左右されているからです。

t/s はどう読むべきか

t/s は tokens per second の略です。

つまり、モデルが 1 秒あたりに何 token を処理または生成できるかを表しています。

ただし注意したいのは、token は「文字」でも「単語」でもなく、モデルのトークナイザが切る単位だということです。モデルや言語によって、1 token が表すテキスト量はかなり変わります。

そのため t/s は主に次の用途に向いています。

同一モデル内で GPU を比べる
同じ環境で設定違いを比べる
同一フレームワークで最適化の有無を比べる

逆に、モデルもフレームワークもトークナイザも違う条件をまたいで、絶対値だけで単純比較するのにはあまり向いていません。

Scoreboard を読むときにまず押さえるべき点

毎回略称に埋もれたくないなら、まず次のポイントから見れば十分です。

1. テスト対象モデルは何か

たとえば Llama 2 7B なのか、量子化形式は Q4_0 なのか。同じモデル・同じ量子化でなければ、結果の横比較はあまり意味を持ちません。

2. 重要な最適化が有効かどうか

もっとも典型的なのが FA です。一方は Flash Attention を有効にしていて、もう一方は無効なら、そのスコアは単純には比較できません。

3. 入力速度を見ているのか、出力速度を見ているのか

pp512 と tg128 は別物です。前者は「読み込みの速さ」、後者は「しゃべる速さ」に近いです。

4. 吞吐を見たいのか、体感を見たいのか

長いプロンプトの立ち上がりを重視するなら pp512 が参考になります。実際の返答の滑らかさを気にするなら、tg128 の方が体感に近いことが多いです。

もっとも実用的な覚え方

これらを一番短く覚えるなら、次のように整理すると実用的です。

Q4_0: モデルは 4-bit 量子化されている
FA: Flash Attention を使っているかどうか
pp512: 512 token の入力処理速度
tg128: 128 token の出力生成速度
t/s: 1 秒あたり何 token か

この五つだけ分かっていれば、似たような CUDA Scoreboard を見たときに、単に「どちらの数字が大きいか」ではなく、「その数字は何を測っているのか」を理解しやすくなります。

結び

GPU ベンチマーク表が難しく見えるのは、指標そのものが神秘的だからではありません。モデル名、量子化、最適化の有無、入力処理と出力生成という別々の吞吐が、短い略称に圧縮されているからです。

FA、Q4_0、pp512、tg128 を順に解きほぐしていけば、こうした Scoreboard は実はそれほど難しくありません。

本当に大事なのは、GPU 名だけを見て終わらないことです。つまり、

どのモデル条件で測ったのか
最適化は有効か無効か
入力を測っているのか、出力を測っているのか
算力寄りなのか、実際の生成体感に近いのか

を一緒に見ることです。

そうすれば、似たようなベンチマーク表を見ても、その結果がどんな条件と意味を持っているのかを判断しやすくなります。

大規模モデルでよく使われるテンソル型入門: FP32、FP16、BF16、TF32、FP8

Wed, 22 Apr 2026 22:40:00 +0800

大規模モデルの学習、推論、デプロイに触れ始めると、すぐに FP32、FP16、BF16、TF32、FP8 という略称を見かけるようになります。これらはモデルの説明欄に添えられた小さなラベルのように見えますが、実際の意味はそれ以上に大きいです。

これらの型は、数値をメモリ上にどう保持し、計算中にどう表現するかを決めます。そしてそれは、学習の安定性、推論速度、さらには 1 枚の GPU でどれだけ大きなモデルを扱えるかにまで影響します。

そのため、大規模モデルの精度トレードオフを本当に理解したいなら、特定モデルのベンチマークを見る前に、まずこれらのテンソル型が何であり、なぜそのように設計されているのかを押さえるのが近道です。

テンソル型は何を決めているのか

大規模モデルの本質は、膨大なパラメータを使った行列演算です。そしてテンソル型とは、その数値をメモリ上でどう保持し、計算中にどう表現するかという形式です。

このトレードオフは、たいてい次の三つの軸に集約されます。

精度
VRAM 使用量
計算速度

これは画像フォーマットに少し似ています。可逆形式は細部を多く保てますが、容量が大きく、読み込みも遅くなります。圧縮形式は人間に見えにくい情報を一部捨てる代わりに、サイズを小さくし処理を速くします。大規模モデルが同じような折衷を受け入れられるのは、非常に多くのパラメータの中では、ごく小さな数値の違いが最終出力に大きく影響しないことが多いからです。

そのため、モデルの世界にはさまざまな精度フォーマットが存在します。

数値はどう表現されるのか

各フォーマットを見る前に、まず浮動小数点数の基本構造を押さえておくと理解しやすくなります。浮動小数点数は通常、次の三つの部分からできています。

符号ビット: 正負を決める
指数ビット: 数値の表現範囲を決める
仮数ビット: 数値の細かさを決める

大規模モデルでは仮数精度も重要ですが、多くの場合それ以上に問題になりやすいのが、指数ビット不足による表現範囲の狭さです。これがオーバーフローや学習不安定性につながります。多くのテンソル型設計は、限られた bit 数を「範囲」と「細かさ」の間でどう配分するか、という問題だと考えるとわかりやすいです。

まずは次の図で全体像をつかむと理解しやすいです。

FP32: 最も安定するが高価

FP32 は最も伝統的な単精度浮動小数点形式で、合計 32 bit、つまり 4 バイトです。

長所はわかりやすいです。

数値範囲が広い
精度が高い
学習が最も安定しやすい

その一方で、欠点も明確です。VRAM を大きく消費します。

非常に大ざっぱに見積もるなら、

`1`	`VRAM 使用量 ≈ パラメータ数 × 1 パラメータあたりのバイト数`

となります。

もし 27B モデルの重みをすべて FP32 で持つなら、重みだけでおよそ

`1`	`27B × 4 bytes ≈ 108GB`

が必要です。

しかも、ここには活性値、KV Cache、オプティマイザ状態、そのほかの実行時オーバーヘッドは含まれていません。つまり、現代の大規模モデル推論や学習において、FP32 はもはや標準というより、「最も安定な基準形式」に近い存在です。

FP16: サイズは半分、ただし安定性はやや弱い

FP16 は各パラメータを 2 バイトに圧縮し、FP32 と比べてメモリ使用量をほぼ半分にします。

同じ 27B モデルで重みサイズだけを見ると、

`1`	`27B × 2 bytes ≈ 54GB`

になります。

これだけでも、なぜ多くのデプロイ手順で 27B モデルの VRAM 要件が 50GB 前後になるのかを説明できます。

FP16 の利点は明快です。

VRAM 圧力が大きく下がる
スループットが高い
初期の mixed precision 学習で広く使われた

ただし弱点は、指数ビットが少なく、動的範囲が狭いことです。大規模モデル学習ではこれがオーバーフローを起こしやすくし、loss scaling のような補助技法を必要とするため、運用がやや面倒になります。

そのため FP16 は今も一般的ですが、多くの場面では最も扱いやすい選択肢ではなくなっています。

BF16: 大規模モデル時代により実用的な半精度

BF16 も 2 バイトですが、FP16 とは設計思想が異なります。

指数範囲を大きく確保することで、動的範囲を FP32 に近づけ、その代わり仮数精度を一部削っています。この折衷は大規模モデルに特に向いています。というのも、多くのモデルは仮数の数 bit より、まず範囲不足に敏感だからです。

そのため、現在では多くの学習フレームワーク、大規模モデルの論文、実際のデプロイ環境が BF16 を好む傾向にあります。

感覚的には次のように捉えるとわかりやすいです。

VRAM コストは FP16 に近い
安定性は FP32 に近い

ある 27B のデプロイ手順が 50GB 前後の VRAM を要求し、別の最適化された手順が 30GB 近くまで下がるなら、前者はまだ FP16/BF16 の層に留まり、後者はより低精度や量子化に踏み込んでいることが多いです。

TF32: VRAM 削減ではなく FP32 ワークフローの高速化

TF32 は「また別の省メモリ形式」と誤解されやすいですが、役割はかなり違います。

一般的には、指数範囲を大きく保ちつつ、仮数精度を短くした計算形式として捉えるとわかりやすいです。

ただし重要なのは、TF32 は FP16/BF16 のように重み保存のための形式というより、Tensor Core 上で使われる内部計算形式に近いという点です。

これは主に NVIDIA が新しい GPU 世代で提供している計算モードであり、目的は VRAM 使用量を下げることではなく、もともと FP32 ベースだった学習ワークフローを、大きくコード変更せずに高速化することです。

要点を一言で言えば、

表向きは FP32 ワークフローのまま
行列演算の内部でより高速な近似計算を行う

ということです。

したがって TF32 が解決するのは「FP32 が遅い」という問題であり、「FP32 が VRAM を食いすぎる」という問題ではありません。同じモデルで VRAM 要件が大きく変わる理由を考えるとき、TF32 は主因ではありません。

FP8: さらに圧縮するが、より高度な工学が必要

さらに先へ進むと FP8 があります。1 つの数値をさらに少ない bit 数で表現し、メモリ帯域と保存コストをさらに下げます。

これは単一の形式というより、代表的には E4M3 と E5M2 という二つの変種として現れます。

ただし FP8 の代償も明確です。bit 数がここまで少なくなると、範囲と精度を同時に保つのが難しくなります。そのため実際の工学では、順伝播、逆伝播、勾配など段階ごとに異なる変種を使ってバランスを取ることがよくあります。

この系統は、より攻めた方針を表しています。

さらなる精度低下を受け入れる
その代わり保存コストとスループットを改善する
より成熟したハードウェアとフレームワークが必要になる

将来性は高いですが、一般ユーザーが日常的に意識する分岐点としては、依然として FP32、FP16、BF16 が中心です。

なぜこれらの型を理解することが重要なのか

最初はこれらの略称を、ダウンロードページに書かれた実装上の細部だと捉えがちです。ですが実際には、学習やデプロイをどう理解するかそのものに関わってきます。

たとえば、同じ GPU を見ていても、

なぜ学習では数値安定性がそれほど重視されるのか
なぜ推論では量子化や低精度がすぐ話題になるのか
なぜパラメータ数が近いモデルでもデプロイ難易度が大きく違うのか
なぜある形式は重み保存向きで、別の形式は計算経路向きなのか

といった疑問が出てきます。

こうした問いを突き詰めていくと、結局は「精度、範囲、メモリ、速度をどう交換するか」という一点に戻ってきます。

だから FP32、FP16、BF16、TF32、FP8 を理解することは、単に用語集を読めるようになるためではありません。学習設定、推論エンジン、デプロイ要件を見たときに、その数字の裏で何が交換されているのかを理解するためです。

実用的な覚え方

最初から細かな仕様を全部覚えたくないなら、まずは次の順で捉えると実用的です。

FP32: 最も安定、最も高価
FP16: VRAM は減るが、範囲は狭い
BF16: FP16 に近い VRAM で、より大規模モデル向きの安定性
TF32: 主に FP32 の遅さを改善し、VRAM 削減は主目的ではない
FP8: さらに攻めた圧縮と高速化の路線

こうしておけば、モデル配布ページに fp16、bf16、fp8 と書かれていても、あるいはデプロイ手順ごとに VRAM 要件が大きく違っていても、それが単なる表記の違いではなく、精度予算と工学的な選択の違いだとわかるようになります。

結び

大規模モデルにおけるテンソル型の話は、表面上は bit 数の話に見えても、本質的には工学的なトレードオフの話です。

FP32、FP16、BF16、TF32、FP8 に絶対的な優劣はありません。それぞれが、安定性、範囲、精度、メモリ、速度のどこに重みを置くかが違うだけです。

この層が見えるようになると、学習論文を読むときも、推論設定を調整するときも、異なるデプロイ戦略を比べるときも、ずっと要点をつかみやすくなります。

16GB GPUでも35Bモデルは動かせる: LM StudioでMoEモデルのVRAMを圧縮する考え方

Wed, 22 Apr 2026 21:47:34 +0800

16GB VRAM というと、ローカルで大規模モデルを動かす場合はせいぜい 12B〜14B あたりが限界で、それ以上は量子化してもかなり厳しい、というイメージを持つ人が多いと思います。その見方は完全に間違いではありませんが、16GB GPU の本当の上限でもありません。

モデル選定とパラメータ設定がうまく噛み合えば、16GB GPU は必ずしも「小さめのモデル」に留まる必要はありません。その代表的な考え方のひとつが、LM Studio で MoE モデルを使い、適切なアンロード戦略によって 35B 級モデルを実用的な速度で回すというものです。

01 なぜ16GB GPUが12B〜14Bに固定されるわけではないのか

ここでの核心はシンプルです。VRAM 容量は重要ですが、モデルのアーキテクチャも同じくらい重要です。

標準的な dense モデルを 16GB GPU に無理やり押し込もうとすると、すぐに限界に当たります。こうしたモデルは推論時に基本的にすべてのパラメータ計算へ関与するため、VRAM と帯域の負荷が一気に上がるからです。

しかし MoE モデルは違います。総パラメータ数は大きくても、1 回の推論で実際に有効化される専門家パラメータはその一部だけです。35B 級モデルを例にすると、総量は大きくても、1 回の推論で実際に計算に参加するパラメータはずっと少ないため、実際の VRAM 要求は想像ほど極端ではありません。

だからこそ、16GB GPU にもまだ工夫の余地があります。

02 実測上のポイント: 35BのMoEモデルはかなり速く動く

代表的な例として挙げられるのが、Qwen 3.5 35B A3B のような MoE モデルの量子化版です。16GB GPU と LM Studio の組み合わせで設定を調整すると、Q6 量子化で 30 tokens/s を超える水準に届き、Q4 ではさらに高い速度が出ることもあります。

この結果に価値があるのは、単に「動く」からではありません。速度がすでに「明らかに実用的」と言える水準に入っているからです。

比較として、同じくらい大きな規模でも MoE ではないモデルを 16GB GPU で無理に回そうとすると、VRAM あふれや大幅な速度低下が起こりがちです。つまり結果を決めるのは、総パラメータ数だけではなく、推論時にそのパラメータをどう使うかです。

03 LM Studioでは、見るべきパラメータが1つではない

16GB GPU でこうしたモデルを安定して動かすには、運任せではなく、2 つのパラメータを正しく調整する必要があります。

GPU Offload
一部の expert layer を CPU メモリへ強制的に載せるための設定

前者は比較的わかりやすく、GPU Offload は基本的に可能な限り高く設定し、GPU 側での計算を優先させます。

後者こそが重要です。これは「VRAM があふれてからシステムメモリを借りる」という昔ながらのやり方ではなく、あらかじめ一部の expert layer を CPU メモリへ逃がして VRAM 使用量を下げる方法です。MoE モデルはそもそも毎回すべての expert を有効化するわけではないため、専門家層の一部をメモリ側へ回しても、推論速度への影響は多くの人が思うほど大きくありません。

実際には、まず一定の範囲から試し、手元のマシンに合わせて少しずつ調整するのが安全です。

関連値を 20〜35 あたりから始める
VRAM 使用量とメモリ圧力を見ながら微調整する

本質的には、システムメモリを使って VRAM の余裕を買う方法です。

04 128Kコンテキストでも動き、さらに縮めればVRAMをもっと減らせる

もうひとつ面白いのは、コンテキスト長を 128K に引き上げた状態でも、35B 級 MoE モデルが比較的高い速度を保てることです。

ここからわかるのは、16GB GPU の限界は思っているほど固定的ではない、ということです。特に LM Studio のようなローカル推論ツールでは、「動くか動かないか」の二択ではなく、実際には次のようなトレードオフになります。

より多くのシステムメモリを使ってでも VRAM を節約するか
コンテキスト長を短くするか
量子化ごとの能力差を受け入れるか

もしコンテキストを 128K から 64K や 32K に縮めれば、VRAM 圧力はさらに下げられます。つまり、35B 級の MoE モデルの中には、より少ない VRAM の GPU でも何とか動くものが出てくる可能性があります。ただし、その分だけ速度とメモリ負荷のバランスは再調整が必要になります。

05 この方法の代償: RAMと仮想メモリへの要求が高くなる

もちろん、この方法はタダで性能が増えるわけではありません。

注意すべきなのは、VRAM 圧力をさらに圧縮すると、システム RAM の使用量が目立って増え、仮想メモリの負荷も上がることです。つまり、コストが消えるのではなく、GPU から RAM とディスクスワップへ圧力が移るだけです。

そのため、実際に試すなら、先にいくつか確認しておくべきです。

システム RAM が十分あるか
仮想メモリを十分に確保しているか
バックグラウンドで重いソフトがたくさん動いていないか

こうした条件が揃っていないと、「35B が速く動く」どころか、マシン全体が遅くなる可能性があります。

06 量子化は攻めればいいというものでもない

ここにはもうひとつ実務的な判断があります。より低ビットの量子化はたしかに VRAM をさらに節約しやすいですが、それが最善とは限りません。

実際には、Q4 のほうが速度は高くても、元の能力が落ちやすいモデルもあります。その点、Q6 は速度と能力保持のバランスが取りやすいことが多いです。結局は、自分がどちらを優先するかです。

とにかく速く、VRAM に収めたいのか
それともモデル本来の能力をより多く残したいのか

この優先順位によって、選ぶ量子化は変わってきます。

07 試す価値があるモデルの考え方

この観点で見ると、やるべきことは「とにかく大きいモデルを追うこと」ではなく、この戦略に合うモデルを先に探すことです。

MoE アーキテクチャのモデル
LM Studio での対応が良く、量子化版が揃っているモデル
長いコンテキストや instruction following に明確な強みがあるモデル

そして、この考え方は 1 つの 35B MoE モデルだけに限りません。長文脈記憶に強い実験的モデル、命令追従が優秀なモデル、あるいは軽量量子化で速度が出るモデルなどにも自然に広げられます。

つまり重要なのは、まず「メモリで VRAM を補う」戦略に合うアーキテクチャを見つけ、そのうえで調整に入ることです。最初に総パラメータ数だけ見て判断するべきではありません。

08 まとめ

もし手元に 16GB GPU があり、ローカル LLM はせいぜい 12B〜14B までだと思っていたなら、その前提は少し更新してよさそうです。

より正確に言えば、次のようになります。

16GB GPU でも大きめのモデルが完全に無理なわけではない
dense モデルと MoE モデルは分けて考える必要がある
LM Studio の GPU Offload と expert layer の CPU メモリ移動は、VRAM 使用量を大きく変えられる
実際には、より大きいモデル規模とより高い実用速度を得るために、より高いメモリ圧力を受け入れている

この方法がすべてのマシンに向くわけではありませんが、少なくともひとつ確かなことがあります。ローカル LLM 運用では、VRAM 上限だけが唯一の制約ではなく、モデルアーキテクチャと推論設定も同じくらい重要です。

12V-2x6 と 12VHPWR：GPU 用 16Pin 電源コネクタの違い

Sun, 19 Apr 2026 23:21:17 +0800

ここ数年のハイエンド GPU でよく話題になる電源コネクタといえば、12VHPWR と新しい 12V-2x6 だ。どちらも外観は 16Pin、つまり 12 + 4 の構造に見えるが、完全に同じインターフェースではない。

簡単に言えば、12V-2x6 は ATX 3.1 と PCIe CEM 5.1 の文脈で、初期の 12VHPWR 設計を修正したものと考えられる。高出力能力は維持しつつ、挿入検出と端子構造をより保守的に設計している。目的は、コネクタが完全に挿さっていない状態で負荷がかかり続けるリスクを減らすことだ。

01 ケーブル自体の差は大きくない

多くの人がまず気にするのは、12V-2x6 と 12VHPWR のモジュラーケーブルを共用できるのか、という点だ。

ケーブルそのものだけを見ると、差は通常それほど大きくない。主な変化はボード側コネクタ、つまり GPU のソケットや電源ユニット側のモジュラーバックプレートソケットにある。新しい 12V-2x6 モジュラーケーブルも、旧来の 12VHPWR モジュラーケーブルも、16Pin GPU 電源という用途自体は同じだ。

そのため互換性を判断するときは、ケーブル長、線径、見た目だけを見るべきではない。GPU 側と PSU 側のソケット仕様、端子品質、そして電源メーカーが明示する対応情報を確認する必要がある。

02 機械構造の主な変更点

12V-2x6 のポイントは、コネクタ外形を完全に変えることではなく、ピン構造を調整したことにある。

12 本の主電源ピンは長くなり、先に接触する。一方、4 本の SENSE 信号ピンは短くなり、後から接触する。この設計の意図は分かりやすい。コネクタが十分奥まで挿さったときだけ SENSE ピンが正しく導通し、GPU が想定どおりの供電能力を認識できるようにするためだ。

これは、初期の 12VHPWR で表面化した典型的な問題に対する対策でもある。見た目では挿さっているように見えても、実際には最後まで挿さっていない場合がある。高負荷時には接触が不十分な部分が発熱し、深刻な場合はプラグやソケットの焼損につながる。

03 より保守的な SENSE ロジック

SENSE0	SENSE1	Initial Power (Power Up)	Max Sustained Power
Ground	Ground	375 W	600 W
Open	Ground	225 W	450 W
Ground	Open	150 W	300 W
Short	Short	100 W	150 W
Open	Open	0 W	0 W

12V-2x6 の安全性向上の中心は、SENSE ロジックにある。

新しい定義では、SENSE0 と SENSE1 が Open、つまり浮いた状態の場合、GPU は正常に電源投入されないか、対応する高出力入力状態に入らない。つまりコネクタが正しく挿さっていないときは、GPU に電力を食わせ続けるのではなく、「動作させない」方向に寄せている。

これは初期の 12VHPWR より保守的だ。初期設計では、SENSE 状態が理想的でなくても、条件によっては一定の入力電力を許容する場合があった。高出力 GPU では、この許容がかえってリスクになることがある。

SENSE ピンを短くすることは、本質的には「完全に挿さっていること」をより厳しい前提条件にする設計だ。

04 H++ 表記の意味

新しい 12V-2x6 コネクタでは、H++ という表記を見かけることがある。これは端子が 9.2A 以上の電流能力に対応していることを示し、以前の H+ 表記の 12VHPWR と区別するためのものだ。

注意したいのは、H++ が 600W を超える電力上限を意味するわけではないことだ。新旧どちらでも、GPU 向け 16Pin 方式の一般的な上限は 600W のままだ。H++ は単純な「より高いワット数」ではなく、端子仕様とコネクタ世代を識別する情報と見るべきだ。

05 自作 PC への影響

通常の PC 組み立てにおいて、12V-2x6 の最大の意味は挿入不良のリスクを下げることだ。ただし、それだけで安全が保証されるわけではない。

この種のコネクタを使うときは、次の点に注意したい。

プラグは必ず奥まで完全に挿す。「見た目では挿さっている」だけで判断しない。
GPU 側コネクタの直近でケーブルを急角度に曲げない。
ケースのサイドパネルでケーブルを無理に圧迫しない。
PSU または GPU メーカーが明示的に対応を示している純正ケーブル、カスタムケーブル、変換ケーブルを優先する。
高出力 GPU では、出どころ不明の安価な変換アダプタを避ける。

ケース内部の空間が狭い場合、90 度の L 字ケーブルやメーカー認証済みのカスタムケーブルは曲げ圧力を緩和できる。ただし、端子品質、線径仕様、メーカー認証を確認すべきで、見た目だけで選ぶべきではない。

06 まとめ

12V-2x6 は、「見た目が 12VHPWR と同じだから違いはない」と言えるコネクタではない。本当の変化は、内部構造と検出ロジックにある。

次のように理解すると分かりやすい。

ケーブル形状は近いが、ボード側コネクタと端子設計のほうが重要。
主電源ピンは長く、SENSE ピンは短い。
コネクタが完全に挿さっていない場合、新版は GPU が動作状態に入るのを防ぎやすい。
H++ 表記は、より高い電流能力を持つ端子仕様を示す。
一般的な GPU 電源上限は引き続き 600W。

高出力 GPU を組むなら、12V-2x6 は初期の 12VHPWR より安心感がある。ただし最終的な安全性は、プラグが奥まで挿さっているか、ケーブル品質、PSU 設計、ケース内の配線スペースに左右される。コネクタ規格が改善されたからといって、雑な取り付けが許されるわけではない。

Ollama マルチ GPU メモ：VRAM の合算、GPU 選択、よくある誤解

Sun, 19 Apr 2026 00:18:00 +0800

Ollama でローカル推論を試していると、よく次のような疑問が出てきます。今 1 枚 GPU があり、マザーボードに空き PCIe スロットがある場合、GPU を追加すると Ollama に効果があるのか。複数 GPU は同じ型番でなければならないのか。VRAM は合算できるのか。学習フレームワークのようにマルチ GPU で推論速度が大きく上がるのか。

この記事では、Ollama のマルチ GPU 動作を整理します。先に結論を書くと次の通りです。

Ollama は複数 GPU をサポートします。
複数 GPU の主な価値は、より大きなモデルを合計 VRAM に載せやすくすることであり、token/s が線形に伸びることではありません。
デフォルトでは、モデルが 1 枚の GPU に完全に収まる場合、Ollama は単一 GPU に載せる傾向があります。
モデルが 1 枚の GPU に収まらない場合、Ollama は利用可能な GPU にモデルを分散できます。
異なる型番の GPU も Ollama から見える場合がありますが、性能や配置が理想的とは限りません。
SLI / NVLink は必須ではありません。
Ollama が使う GPU を制限したい場合は、CUDA_VISIBLE_DEVICES、ROCR_VISIBLE_DEVICES、GGML_VK_VISIBLE_DEVICES を使います。

公式の挙動：まず単一 GPU、入らなければ複数 GPU

Ollama FAQ では、マルチ GPU のロードロジックが比較的明確に説明されています。新しいモデルをロードするとき、Ollama は必要な VRAM を見積もり、現在利用可能な VRAM と比較します。モデルがどれか 1 枚の GPU に完全に収まる場合、その GPU にロードします。1 枚に収まらない場合、利用可能なすべての GPU に分散されます。

この戦略の理由は性能です。単一 GPU に載せることで、推論時の PCIe バス越しのデータ転送を減らせるため、通常はそのほうが速くなります。

そのため、Ollama のマルチ GPU を「GPU が増えれば自動で数倍速くなる」と考えないほうがよいです。より正確には次のように理解できます。

小さいモデルが単一 GPU に入る：通常は単一 GPU で動く。
大きいモデルが単一 GPU に入らない：複数 GPU に分層ロードされる。
それでも VRAM が足りない：一部がシステムメモリに落ち、速度が大きく低下する。

モデルがどこにロードされたかは、次のコマンドで確認できます。

`1`	`ollama ps`

出力の PROCESSOR には、たとえば次のように表示されます。

1
2
3

100% GPU
48%/52% CPU/GPU
100% CPU

48%/52% CPU/GPU と表示される場合、一部がすでにシステムメモリにあります。この場合、CPU/RAM に頼り続けるより、GPU を増やすか、より大容量 VRAM の GPU に替えるほうが有効なことが多いです。

マルチ GPU は単純な計算力の合算ではない

ローカル LLM 推論は、ゲームにおける SLI とは別物です。Ollama のマルチ GPU では、モデルの異なる層やテンソルを別々のデバイスに置く形が一般的です。これにより複数 GPU の VRAM を使って大きなモデルを載せられますが、推論中にはデバイス間でデータを渡す必要が出る場合があります。

したがって、マルチ GPU の利点は通常 2 種類です。

VRAM 面の利点：大きなモデルを載せやすくなり、CPU/RAM への退避を避けやすくなる。
性能面の利点：単一 GPU に入らない、または CPU との混在が深刻な場合に目立ちやすい。

8B や 14B のモデルが 1 枚の RTX 3090 に完全に入る場合、それを 2 枚の GPU に無理に分割しても速くなるとは限りません。むしろ GPU 間転送で遅くなる可能性があります。Ollama のデフォルトの「入るなら単一 GPU」戦略は、この不要な PCIe コストを避けるためのものです。

SLI や NVLink は不要

Ollama のマルチ GPU は SLI に依存しません。通常の PCIe GPU が複数あり、ドライバと Ollama が認識できれば、スケジューリング対象になります。

NVLink やより高い PCIe 帯域は、一部の GPU 間分散シナリオで役立つ可能性がありますが、前提条件ではありません。中古 GPU サーバーやワークステーションでも、普通の PCIe マルチ GPU で動かせます。

本当に注意すべきなのは PCIe 帯域です。x1、x4、x8、x16 の差は、モデルを VRAM にロードする速度に影響します。大きなモデルを頻繁に切り替える場合、PCIe リンクはボトルネックになりやすくなります。モデルのロード後、生成時の影響は通常小さくなりますが、GPU 間分散には追加コストが残る可能性があります。

無難な考え方は次の通りです。

可能なら x16 / x8 を使い、マイニング用 x1 riser は避ける。
大きなモデルを頻繁に切り替えるなら、PCIe 帯域はより重要。
モデルを長時間 VRAM に常駐させる場合、PCIe 帯域の影響は相対的に小さくなる。
マルチ GPU 機では、マザーボードの PCIe トポロジーと CPU 直結レーンを確認する。

Ollama が使う NVIDIA GPU を制限する

NVIDIA のマルチ GPU 環境では、CUDA_VISIBLE_DEVICES で Ollama から見える GPU を制御します。

一時的に実行する場合：

`1`	`CUDA_VISIBLE_DEVICES=0,1 ollama serve`

2 枚目の GPU だけを使う場合：

`1`	`CUDA_VISIBLE_DEVICES=1 ollama serve`

NVIDIA GPU を使わせない場合は、無効な ID を指定できます。

`1`	`CUDA_VISIBLE_DEVICES=-1 ollama serve`

公式ドキュメントでは、数値 ID の順序は変わる可能性があるため、GPU UUID のほうが信頼できるとされています。まず UUID を確認します。

`1`	`nvidia-smi -L`

出力例：

1
2

GPU 0: NVIDIA GeForce RTX 3090 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
GPU 1: NVIDIA GeForce RTX 3070 (UUID: GPU-yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy)

その後、UUID を指定します。

`1`	`CUDA_VISIBLE_DEVICES=GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ollama serve`

Linux の systemd サービスとして Ollama をインストールしている場合は、サービス環境変数に書きます。

`1`	`sudo systemctl edit ollama.service`

追加内容：

1
2

[Service]
Environment="CUDA_VISIBLE_DEVICES=0,1"

再読み込みして再起動します。

1
2

sudo systemctl daemon-reload
sudo systemctl restart ollama

AMD と Vulkan の選択変数

AMD ROCm 環境では、ROCR_VISIBLE_DEVICES で見える GPU を制御します。

`1`	`ROCR_VISIBLE_DEVICES=0,1 ollama serve`

ROCm GPU を使わせない場合も、無効な ID を指定できます。

`1`	`ROCR_VISIBLE_DEVICES=-1 ollama serve`

Ollama の GPU ドキュメントでは、実験的な Vulkan サポートも触れられています。Vulkan GPU を選ぶには GGML_VK_VISIBLE_DEVICES を使います。

`1`	`OLLAMA_VULKAN=1 GGML_VK_VISIBLE_DEVICES=0 ollama serve`

Vulkan デバイスで問題が出る場合は無効化できます。

`1`	`GGML_VK_VISIBLE_DEVICES=-1 ollama serve`

AMD のマルチ GPU は、NVIDIA よりもドライバ、ROCm バージョン、GFX バージョンの互換性問題に遭遇しやすいです。公式ドキュメントでも Linux の ROCm ドライバ要件や HSA_OVERRIDE_GFX_VERSION などの互換性設定が説明されています。異なる世代の AMD GPU を混在させる場合は、まず各カードが単独で動くことを確認してからマルチ GPU を試すのが安全です。

Docker で複数 GPU を見せる

Docker で Ollama を動かす場合、NVIDIA 環境では通常 nvidia-container-toolkit を入れ、--gpus でデバイスを公開します。

すべての GPU を公開：

docker run -d \
  --gpus=all \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

指定した GPU だけを公開：

docker run -d \
  --gpus '"device=0,1"' \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

環境変数と組み合わせることもできます。

docker run -d \
  --gpus=all \
  -e CUDA_VISIBLE_DEVICES=0,1 \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

コンテナ内で nvidia-smi が GPU を見られない場合、Ollama も GPU を使えません。まず Docker の GPU passthrough を確認し、その後 Ollama を確認します。

`OLLAMA_SCHED_SPREAD` とは

マルチ GPU 設定では、OLLAMA_SCHED_SPREAD=1 や OLLAMA_SCHED_SPREAD=true を見かけることがあります。これは Ollama のスケジューラに関係する設定で、モデルやリクエストを複数 GPU により分散させたい場面で使われることがあります。

設定例：

`1`	`OLLAMA_SCHED_SPREAD=1 ollama serve`

systemd の場合：

1
2

[Service]
Environment="OLLAMA_SCHED_SPREAD=true"

ただし万能ではありません。有効にしても token/s が線形に増えるわけではなく、複数モデルの同時ロード、VRAM 見積もり、コンテキスト長、KV cache の増加によって OOM になることもあります。公式 FAQ の基本方針は変わりません。1 枚の GPU にモデルが完全に入るなら単一 GPU のほうが効率的なことが多く、1 枚に入らないときに複数 GPU 分散が有効になります。

そのため、OLLAMA_SCHED_SPREAD はマルチ GPU 必須設定ではなく、高度なスケジューリング実験項目として扱うのがよいです。まずデフォルト挙動を理解し、ollama ps、ログ、nvidia-smi の結果を見ながら調整します。

複数 GPU が本当に使われているか確認する

よく使う確認コマンド：

`1`	`ollama ps`

`1`	`watch -n 0.5 nvidia-smi`

Ollama サービスログ：

`1`	`journalctl -u ollama -f`

Docker の場合：

`1`	`docker logs -f ollama`

確認したい点：

Ollama が対応 GPU を検出しているか。
モデルが 100% GPU または CPU/GPU 混在で表示されているか。
各 GPU に VRAM 使用量があるか。
モデルロード時に複数 GPU の VRAM が増えるか。
生成時の token/s が CPU/RAM 退避より明らかに改善しているか。
OOM やモデルのアンロードが頻発していないか。

GPU 使用率だけを見ると誤解しやすいです。LLM 推論では、特にマルチ GPU、低 batch、小さいコンテキスト、遅い CPU、遅い PCIe 環境では、GPU 使用率が常に高いとは限りません。

よくある誤解

誤解 1：12GB GPU 2 枚は 24GB GPU 1 枚と同じ

完全には同じではありません。複数 GPU にモデルを配置できますが、デバイス間アクセスには追加コストがあります。「入らない」問題は解決できますが、単一大容量 VRAM GPU と同じ速度や安定性になるとは限りません。

誤解 2：異なる型番の GPU は混在できない

必ずしもそうではありません。ドライバ、計算能力、ランタイムライブラリが対応していれば、Ollama は複数 GPU を認識できます。ただし混在構成では、遅いカード、小さい VRAM、PCIe トポロジーに制約されやすくなります。最も予測しやすいのは、同じ型番、同じ VRAM、同世代でサポートの良いドライバ構成です。

誤解 3：マルチ GPU は必ず単一 GPU より速い

必ずしも速くありません。モデルが 1 枚の高速 GPU に完全に入る場合、単一 GPU のほうが速いことがあります。マルチ GPU は主に、大きなモデル、長いコンテキスト、単一 GPU の VRAM 不足に向いています。

誤解 4：NVLink / SLI が必須

不要です。普通の PCIe マルチ GPU システムでも Ollama は利用できます。NVLink は前提条件ではありません。

誤解 5：GPU を追加したらサービス再起動は不要

必ずしもそうではありません。Linux systemd サービス、Windows のバックグラウンドアプリ、Docker コンテナは、デバイスや環境変数を再検出するために再起動が必要な場合があります。

GPU 選びの目安

Ollama のローカル推論では、おおよその優先順位は次の通りです。

単一 GPU の VRAM が大きいほど扱いやすい。
同一 GPU 複数枚は、混在 GPU よりトラブルシュートしやすい。
PCIe レーンが十分あるほど、大きなモデルのロードが快適。
古い GPU は CUDA compute capability または ROCm 対応を先に確認する。
マルチ GPU では電源、冷却、筐体エアフローを事前に計算する。

中古予算重視の場合：

RTX 3090 2 枚は、今でもよく使われる大容量 VRAM 構成です。
P40 / M40 のような古い Tesla は VRAM が大きい一方、消費電力、冷却、ドライバ、性能のトレードオフがあります。
RTX 4070 / 4070 Ti などは効率が良いですが、単一 GPU の VRAM 容量が制約になりやすいです。
古い 8GB GPU を複数枚使う構成は実験としては面白いですが、大きなモデルを長期運用する用途にはあまり向きません。

まとめ

Ollama のマルチ GPU は、「性能加速より先に VRAM 拡張」と理解すると分かりやすいです。モデルが 1 枚の GPU に完全に入るなら、デフォルトの単一 GPU 経路のほうが速いことが多いです。1 枚に入らない場合、複数 GPU に分散することで CPU/RAM への大きな退避を避け、大きなモデルを実用的にできます。

実際の設定では、まず ollama ps でモデルのロード先を確認し、nvidia-smi や ROCm ツールで VRAM 使用量を観察します。GPU を制限する場合、NVIDIA は CUDA_VISIBLE_DEVICES、AMD ROCm は ROCR_VISIBLE_DEVICES、Vulkan は GGML_VK_VISIBLE_DEVICES を使います。Docker で動かす場合は、まずコンテナから GPU が見えているか確認します。

マルチ GPU は魔法ではありません。より大きなモデルを載せる助けにはなりますが、線形加速は保証されません。安定して使うなら、大容量 VRAM の単一 GPU、または同一型番のマルチ GPU を優先し、ドライバ、PCIe、電源、冷却、モデル量子化をまとめて考えるのが現実的です。

参考連結

Ollama FAQ：How does Ollama load models on multiple GPUs?：https://github.com/ollama/ollama/blob/main/docs/faq.mdx
Ollama GPU ドキュメント：Hardware support / GPU Selection：https://github.com/ollama/ollama/blob/main/docs/gpu.mdx
Ollama Docker Hub：https://hub.docker.com/r/ollama/ollama
NVIDIA Container Toolkit：https://github.com/NVIDIA/nvidia-container-toolkit

Ollama モデルが GPU にロードされているかどうかを確認する方法

Mon, 06 Apr 2026 10:15:18 +0800

Ollama モデルが実際に GPU 上で実行されているかどうかを確認する最も直接的な方法は、現在ロードされているモデルのプロセッサ使用状況情報を確認することです。

コマンドを使用する

`1`	`ollama ps`

出力例

1
2

NAME        ID            SIZE    PROCESSOR   UNTIL
llama3:70b  bcfb190ca3a7  42 GB   100% GPU    4 minutes from now

`PROCESSOR` 列の解釈方法

100% GPU: モデルは GPU メモリに完全にロードされています。
100% CPU: モデルはシステムメモリに完全にロードされています (GPU 推論は使用されません)。
48%/52% CPU/GPU: モデルは一部がメモリ内にあり、一部がビデオメモリ内にあり、混合負荷です。

実践的なアドバイス

GPU を使用する予定なのに 100% CPU が表示される場合は、まずグラフィックスドライバー、CUDA/ROCm 環境、および Ollama ランタイムパラメーターを確認してください。
モデルパラメータの数が多く、ビデオメモリが不足している場合、通常、CPU/GPU 混合負荷が発生します。
パフォーマンスの問題のトラブルシューティングを行う場合は、最初に ollama ps を実行し、次に速度データを確認してボトルネックをより迅速に特定します。

要約する

ollama ps は、モデルが実際に GPU を使用しているかどうかを判断する最初のステップです。 PROCESSOR 列に注目して、現在の読み込み位置をすばやく確認し、それに応じてその後の最適化の方向を決定します。

GPU on KnightLiブログ

2026年4月のGPU選び：避けたいモデルと、より見やすいモデル

あまりおすすめしにくいモデル

1. RTX 5060 Ti 8GB

2. まだ高い旧世代カード、特に RTX 3080 10GB と RTX 3070 Ti

3. 出どころが不明な旧フラッグシップ、たとえば RTX 3090 や RTX 3080 Ti

4. 価格が合っていない RTX 5070

比較的見やすいモデル

1. RTX 5060 Ti 16GB

2. RTX 5070 Ti

3. ちゃんとした価格の新品カードは、古い高級カードより先に見る価値がある

ひとことで言うなら

最後に

Ubuntu 26.04 LTS の GPU とハードウェア対応アップデート: CUDA、ROCm、DPC++、そして各種プラットフォームの変更

1. Intel DPC++ と関連コンポーネントが Ubuntu Archive に追加

2. NVIDIA CUDA toolkit も apt で直接導入可能に

3. AMD ROCm 7.1.0 が Universe に追加

4. 本当のポイントは 3 社の GPU エコシステムが同時に進んでいること

5. NVIDIA Dynamic Boost がデフォルトで有効化

6. 新しい Intel 内蔵 GPU / 外付け GPU のサポートも前進

7. Nvidia デスクトップのサスペンド復帰も安定化

8. ARM、Raspberry Pi、RISC-V、IBM Z でも要件変更がある

ARM64 デスクトッププラットフォーム

Raspberry Pi の新しいブートレイアウト

Raspberry Pi デスクトップイメージは desktop-minimal ベースに

Raspberry Pi の swap は cloud-init 管理に

RISC-V の要件が引き上げ

IBM Z の最低要件は z15 に

9. この内容を先に読むべき人

10. ひと言でまとめると

Ollama が GPU を使わず CPU で動いてしまう問題の対処法

1. まず本当に GPU を使えていないのか確認する

2. まず一番多い思い込みを外す: モデルが VRAM に収まっていない

3. GPU ドライバと下位ランタイムが正常か確認する

NVIDIA の場合

AMD / ROCm の場合

4. ターミナルではなく Ollama サービス自体を再起動する

5. 環境変数が本当にサービスまで届いているか確認する

6. AMD 環境では ROCm の互換性を重点的に見る

7. Docker、WSL、リモート環境ではデバイスマッピングも確認する

8. 最後にログを見る。やみくもに再インストールしない

切り分け順序

まとめ

NVIDIA nvbandwidth とは何か：GPU 帯域テストツールの使い方

1. nvbandwidth は何をするツールか

2. 単なる 1 つのスコアを出すツールではない

3. CE と SM の 2 種類のコピーをどう理解するか

4. 実行に必要な環境

5. シングルノード版のビルドと実行方法

6. マルチノード対応がこのツールの特徴

7. v0.9 では何が変わったか

8. どんなときに使うとよいか

9. このツールの価値をどう捉えるか

関連リンク

Tesla V100 に ECC エラーがあるか確認する方法

Tesla V100 はまだ買う価値があるか：ECC確認、冷却改造、DIYの落とし穴

まず結論

1. まず製造年とロット感を見る

2. 外観確認ではチップだけでなく、インダクタ、スプリング、フレームも見る

1. まずインダクタを触る

2. 固定スプリングが外された形跡を確認する

3. フレームが簡単に分かれるのも不自然

3. バックプレートが簡単に外れるなら、VBIOS 書き換えや改造を疑う

4. ECC の見方：重要なのはゼロかどうかではなく、増えるかどうか

1. リアルタイムのエラーが最も危ない

2. 生涯累積エラーは必ずしも致命的ではない

3. ページリタイアはより重視したい

5. 「ECC ゼロ」を信じすぎない。数値自体が触られている可能性もある

6. ストレステストは必須。ただしコアだけ見ても足りない

7. DIY ユーザーが本当に失敗しやすいのは、購入より冷却と電源

1. GPU の平均温度だけを見ない

2. バックプレートと電源まわりの冷却は必須

3. 安い寄せ集め水冷構成はリスクが高い

8. それでも DIY するなら、最低限ここは見る

9. コイル鳴きと変換基板の個体差も現実的な問題

1. コイル鳴きは完全には消せないことがある

2. 変換基板の個体差はかなり大きい

まとめ

llama.cpp / ollama GPU 性能ランキング：CUDA、ROCm、Vulkan

まずパラメータを理解する

1. `RTX 5060 Ti 8GB`

2. まだ高い旧世代カード、特に `RTX 3080 10GB` と `RTX 3070 Ti`

3. 出どころが不明な旧フラッグシップ、たとえば `RTX 3090` や `RTX 3080 Ti`

4. 価格が合っていない `RTX 5070`

1. `RTX 5060 Ti 16GB`

2. `RTX 5070 Ti`

2. NVIDIA CUDA toolkit も `apt` で直接導入可能に

1. `nvbandwidth` は何をするツールか

3. `CE` と `SM` の 2 種類のコピーをどう理解するか

7. `v0.9` では何が変わったか

4. `ECC` の見方：重要なのはゼロかどうかではなく、増えるかどうか

`Q4_0` とは

`pp512` とは

`tg128` とは

`FA` とは

`t/s` の読み方

`OLLAMA_SCHED_SPREAD` とは