NVIDIA CUDA / cuDNN / TensorRT / TensorRT-LLM の違い 2026年版：ローカルLLM・AI開発でどのライブラリで速くなるのかをレイヤーで整理

結論：CUDA は「NVIDIA GPU で汎用計算するための土台」、cuDNN は「深層学習の演算ライブラリ」、TensorRT は「学習済みモデルを最速で推論する最適化コンパイラ」、TensorRT-LLM は「LLM 特化の TensorRT 拡張」。下から積み上げる階層になっており、どのライブラリを使うかで「触る層」が違います。ローカルLLM で Ollama を回すだけなら CUDA だけで十分、PyTorch で学習するなら cuDNN、最速で 70B クラスをサービングするなら TensorRT-LLM まで積む、という切り分けが 2026 年時点の実務判断です。

「NVIDIA の AI ライブラリ」で並ぶ CUDA / cuDNN / TensorRT / TensorRT-LLM は、いずれも公式で提供されているのに役割の違いが分かりにくいシリーズです。特に「CUDA Core（ハードウェアの演算ユニット）」と「CUDA（ソフトウェアの並列計算基盤）」を混同したまま話が進むと、cuDNN が必要かどうかの判断すらできません。この記事では、4 つのライブラリを Driver から順に積み上げる階層で整理し、ローカルLLM 実務で「どの層まで入れれば良いか」を Blackwell 世代 2026 年基準でまとめます。

NVIDIA AI スタックの全体像

まず 4 つのライブラリを、下から積み上がる階層として一枚にします。

アプリ層          Ollama / llama.cpp / vLLM / SGLang / PyTorch
                       │
LLM 特化最適化    TensorRT-LLM   (KV cache / Paged Attention / 投機的デコード)
                       │
推論最適化        TensorRT       (グラフ最適化 / 量子化 / エンジンビルド)
                       │
DL 演算           cuDNN          (Conv / Attention / RNN の実装)
                       │
汎用並列          CUDA Runtime   (memory / stream / kernel launch API)
                       │
ドライバ          CUDA Driver    (Windows / Linux ドライバ)
                       │
ハードウェア      GPU            (Blackwell / Ada / Hopper)

この図を頭に置くと、以降の話が全部「どの層で何が起きているか」に落ちます。上に行くほど用途が特化し、実行速度が上がる代わりに変換コストや対応モデルの縛りが増える、という関係です。

CUDA：GPU で汎用計算するための土台

CUDA は 2007 年に登場した「NVIDIA GPU で汎用並列計算を書くための開発基盤」で、実体は 2 つの層に分かれます。

層	役割	どこにある
CUDA Driver	OS 側から GPU を操作する低レベル API	ドライバに同梱（Windows / Linux）
CUDA Runtime	アプリから呼ぶ高レベル API（cudaMalloc 等）	CUDA Toolkit に同梱

アプリケーションは通常 CUDA Runtime を叩き、Runtime が Driver 経由で GPU にカーネルを投げます。ここが「GPU で自前計算を回す」ときの入り口になります。

CUDA Toolkit 側は、2026 年 6 月時点で 13.3.1 が最新で、cu12 系（12.6 / 12.8 系）も現行で維持されています。PyTorch 2.5 系は CUDA 12.4、2.6 系は CUDA 12.6 前提のホイールが配布されており、これらは pip インストール時に必要な CUDA Runtime を同梱してくるため、Toolkit を別途入れる必要は基本的にありません。混同されがちな「CUDA Core」との違いは後述します。

CUDA Core（ハードウェア）と CUDA（ソフトウェア）は別物です

ここが最頻の勘違いポイントです。

• CUDA Core：GPU 内部の汎用演算ユニット（ハードウェア）。RTX 5090 なら 21,760 個
• CUDA：NVIDIA GPU 上で汎用並列計算を書くためのソフトウェア基盤（Driver + Runtime + Toolkit）

「CUDA Core が 21,760 個ある」＝「同時に 21,760 スレッドを回せる汎用演算のハードウェア規模が大きい」という話で、「NVIDIA CUDA ライブラリの規模」ではありません。GPU 内には CUDA Core のほかに行列演算専用の Tensor Core、レイトレーシング専用の RT Core も同居しています。ハードウェア側の 3 種類のコアの切り分けは「Tensor Core / CUDA Core / RT Core の違い 2026年版」で詳しく整理しています。ソフトウェアの CUDA は、これら Tensor Core / RT Core もラッパー経由で叩けるように統一 API を用意している、というのが実態です。

cuDNN：深層学習の演算ライブラリ

cuDNN は「畳み込み・RNN・Attention のような深層学習でよく使う演算」を、NVIDIA が手書きの高速実装として提供しているライブラリです。CUDA Runtime の上に載り、PyTorch や TensorFlow の学習・推論バックエンドとして呼ばれます。

2026 年 4 月にリリースされた cuDNN 9.7 では、Blackwell の FP8 畳み込みや、GQA（Grouped-Query Attention）向けの融合カーネルが追加されました。CUDA 12 系対応で、CUDA 11 系のサポートは 2024 年で終わっています。

cuDNN を使うかどうかは、実務ではこうなります。

用途	cuDNN が呼ばれるか
PyTorch で学習・ファインチューニング	呼ばれる（Conv / Attention の実装）
PyTorch で推論	呼ばれる（自動選択）
Hugging Face Transformers	呼ばれる（PyTorch 経由）
Ollama / llama.cpp（GGUF 推論）	呼ばれない（自前カスタムカーネル）
vLLM	一部呼ばれる（Attention は自前カーネル、その他は cuDNN 経由）

つまり「Ollama で Q4_K_M の 70B を回したいだけ」なら cuDNN のインストールは不要です。逆に PyTorch で学習を回すなら、cuDNN が入っていないと Conv や Attention が桁違いに遅くなります。この切り分けは、cuDNN 導入前にまず「何をやるか」で判断するのが早いです。

TensorRT：推論最適化コンパイラ

TensorRT は「学習済みモデルを推論向けに最適化するコンパイラ」です。PyTorch や ONNX で作ったモデルを入力に取り、以下のような最適化を掛けて「エンジン（.engine）」と呼ばれる実行形式に変換します。

• グラフ最適化：不要な層を融合し、レイヤーの並びを最適化
• 精度削減：FP32 → FP16 / FP8 / FP4 の量子化
• カーネル選択：ターゲット GPU に応じた最速カーネルを実装から選ぶ
• テンソルレイアウト最適化：Tensor Core が食いやすい形にメモリを組み替える

汎用 TensorRT は画像分類・物体検出・音声認識といったモデルにも広く使われます。LLM も動きますが、KV cache やバッチング周りが LLM 固有の要件を満たしていないため、そのままではサービング用途で不利です。そこで LLM 特化の派生として TensorRT-LLM が用意されました。

TensorRT-LLM：LLM 特化の TensorRT 拡張

TensorRT-LLM は TensorRT を土台に、LLM 推論で必要な最適化を積み上げたスタックです。

• KV cache 管理：長い会話履歴を効率よくメモリに保持
• Paged Attention：vLLM 系と同様の可変長リクエストの高効率化
• In-flight Batching：異なる長さの複数リクエストを1バッチで裁く
• 投機的デコード（Speculative Decoding）：ドラフトモデルで先読みし、大モデルの検証で採用/棄却
• 量子化フォーマット：FP16 / INT8 SmoothQuant / FP8 / NVFP4 / MXFP4

2026 年時点で TensorRT-LLM 0.17 が Blackwell の FP4 推論（GB200 系）に対応し、GB200 のプロダクション用途で「サブ FP8 の推論経路」として使われ始めました。依存関係は TensorRT 10.9 + CUDA 12.8.1 系です。

Blackwell 世代の 4bit 浮動小数点フォーマット（NVFP4 / MXFP4）そのものの位置付けは「NVFP4 / MXFP4 / FP8 の違い 2026年版」で整理しています。TensorRT-LLM 側から見ると、これらのフォーマットが Blackwell の第5世代 Tensor Core にネイティブで載る、というのが最大の利点です。

Ollama から TensorRT-LLM に切り替えると何倍速いか

70B クラスの目安として、TensorRT-LLM の高速化は次のイメージです。

起点	対 TensorRT-LLM の速度感
Ollama（llama.cpp GGUF Q4_K_M）	約 2〜3 倍速
vLLM（FP16 / AWQ）	約 1.3〜1.8 倍速
SGLang（FP8）	同等〜1.3 倍速

ただし TensorRT-LLM を選ぶには 3 つのコストがあります。

• エンジンビルド：モデルごとに .engine ファイルを事前生成する必要がある（数分〜数十分、GPU リソース消費）
• 量子化フォーマットの縛り：GGUF Q4_K_M / Q5_K_M のような llama.cpp 系フォーマットは直接使えず、FP16 / INT8 / NVFP4 / MXFP4 に変換する必要がある
• モデル対応の遅れ：新しいモデル（Llama 4 系・Qwen 3 系）が出た直後は、TensorRT-LLM 側の対応が数週間〜数ヶ月遅れる場合がある

個人ユースの「シングルユーザーで会話を回す」だけなら Ollama で困りません。サーバー用途で複数リクエストを同時に裁く必要が出てきた時点で、初めて TensorRT-LLM 導入の検討価値が出てくる、という順序が実務的です。推論エンジン 4 派閥（vLLM / SGLang / TensorRT-LLM / Ollama）の総合比較は「vLLM / SGLang / TensorRT-LLM / Ollama の違いとサービング用途の使い分け」に切り出してあります。

実務でどの層まで入れるべきか判断表

「自分の用途で、どの層まで積むべきか」を早見表にまとめます。

用途	最低限入れる層	具体的な組み合わせ
Ollama で LLM 推論（GGUF）	CUDA Driver + Runtime	CUDA Toolkit 12.6+（cuDNN 不要）
llama.cpp を自分でビルド	CUDA Toolkit + nvcc	CUDA 12.6+ / cuBLAS
PyTorch で推論だけ	cuDNN	PyTorch 2.5+（pip 版なら追加不要）+ cuDNN 9.x
PyTorch で学習・LoRA	cuDNN	PyTorch 2.6+ + cuDNN 9.x + CUDA 12.6+
vLLM サービング	CUDA Runtime + カスタム	vLLM 自身が同梱、CUDA 12.6+ だけ用意
SGLang サービング	CUDA Runtime + PyTorch	SGLang 依存の PyTorch + CUDA 12.6+
TensorRT-LLM で最速サービング	全部	CUDA 12.8+ / cuDNN 9.x / TensorRT 10.9+ / TensorRT-LLM 0.17+

個人用のローカルLLM 環境なら、大半は「CUDA Toolkit 12.6+ を入れる」で止まります。cuDNN や TensorRT-LLM は、目的が「学習」「本番サービング」に振り切ったときの追加装備です。使う予定のないものを先回りで入れておく必要はありません。

CUDA / cuDNN バージョン互換の落とし穴

「cuDNN version mismatch」「libcudart.so not found」で詰まる原因は、ほぼこのバージョン組み合わせに集約されます。

• PyTorch と CUDA：PyTorch 2.5 系 は CUDA 12.4、2.6 系 は CUDA 12.6、2.7 系 は CUDA 12.8 前提のホイールが基本
• cuDNN と CUDA：cuDNN 9.x は CUDA 12 系専用（CUDA 11 系の cuDNN サポートは 2024 年に終了）
• TensorRT と CUDA：TensorRT 10.9 は CUDA 12.8 系対応
• Ollama と CUDA：Ollama バイナリは同梱ランタイム前提で、システム側の CUDA Toolkit のバージョンに強く依存はしません

「PyTorch は動くけど nvcc が無い」となるのは、pip 版 PyTorch が同梱ランタイムで動くのに対して、C++ 拡張のビルド（pip install flash-attn 等）でシステム CUDA Toolkit が必要になるためです。この場合は Toolkit を別途入れて nvcc --version が通る状態を作ります。GGUF 系量子化（Q4_K_M / Q6_K / IQ4_XS など）や Blackwell 向けの新フォーマットの位置付けは「LLM 量子化フォーマットの違い 2026年版」に整理してあります。

WSL2 との関係：Windows 側 Driver が CUDA を透過する

Windows 環境で「WSL2 の Ubuntu から CUDA を叩きたい」場合、Ubuntu 側で CUDA Driver を入れる必要はありません。Windows 側にインストールした NVIDIA GPU ドライバが WSL2 に CUDA を透過するため、WSL2 内では CUDA Toolkit（Runtime）だけを入れれば動きます。

• Windows 側：NVIDIA GPU ドライバ（Game Ready / Studio）を入れる
• WSL2 側：CUDA Toolkit 12.6+ / cuDNN / PyTorch を入れる（Driver は入れない）

Ubuntu 側で nvidia-driver パッケージを入れると Windows 側と競合して壊れる、というのが WSL2 で最頻の失敗パターンです。WSL2 でのローカルLLM 環境の実装手順は「WSL2 でローカルLLM 環境を構築するガイド 2026年版」に切り出してあります。NVIDIA / AMD どちらの GPU プラットフォームを選ぶかで悩んでいる場合は、AMD ROCm と NVIDIA CUDA のプラットフォーム比較を扱った「ROCm vs CUDA ローカルLLM 2026年版」も併せて読むと、スタック選定の全体像が揃います。

判断まとめ

私の見立てはこうです。

• Ollama でローカルLLM を回すだけ：CUDA Toolkit 12.6+ を入れて終わり。cuDNN も TensorRT も不要
• PyTorch で学習やファインチューニング：pip 版 PyTorch + cuDNN 9.x で十分。CUDA Toolkit は C++ 拡張ビルド時のみ
• vLLM / SGLang サービング：CUDA 12.6+ だけ用意、あとはエンジン側が同梱
• 本気で最速の LLM サービング（大量リクエスト）：TensorRT-LLM 0.17+ まで積む。ただしエンジンビルドと量子化フォーマット変換のコストを許容できる場合に限る

「NVIDIA の AI ライブラリはなんとなく全部入れる」で走ると、依存関係のバージョン地獄にはまります。用途を1つに絞って、そこで必要な層だけを積み上げるのが 2026 年の実務です。

---

あなたに合うPCを診断する

用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。

→ 診断スタート

関連記事

• Tensor Core / CUDA Core / RT Core の違い 2026年版：Blackwell世代で何が変わったか
• vLLM / SGLang / TensorRT-LLM / Ollama の違いとサービング用途の使い分け 2026年版
• ROCm vs CUDA ローカルLLM 2026年版：AMD Radeon で本当に llama.cpp / vLLM は動くのか
• NVFP4 / MXFP4 / FP8 の違い 2026年版：Blackwell の4bit 浮動小数点は何を変えたか
• WSL2 でローカルLLM 環境を構築するガイド 2026年版