【Gemma4 31B 92.67t/s】VRAM 32GBの世界に足を踏み入れる話③【RTX5060ti×2】

2026年6月24日 01:10

はじめに

前回のつづきです。RTX5060ti×2のLLM性能検証シリーズです。

Gemma4のMTPは恐ろしいです。本当に３倍速くなりますね。

もうすこし詳細を詰めようと思ったのですが、前回の記事で利用したUnsloth Studioのtensor-parallelism機能が動作しなくなったので、素直にllama-serverコマンドを利用します。

（オプションが変わったのが原因？）アップデート後に動作しなくなってしました。github版の自ビルドllama.cppを直接利用する事にします。※ 本当はollamaが対応してくれれば便利なのですが…

# llama-serverバージョン
~/app/llama-cpp/llama.cpp/build/bin/llama-server --version
version: 9762 (9c0ac887f)
built with GNU 13.2.0 for Linux x86_64

下記スクリプトで動作させます。前回は「--spec-draft-n-max」を2に設定してたので、4に増やします。コンテキストサイズは64kにします。※ たぶん64k+αあたりが上限です。

前回と同じ数学の問題でパフォーマンスを測定します。（Open WebUI）

筆者環境では、ドラフト・トークンを増やした方が有利になったようです。※ 増やすと失敗する確率も増えるので、文脈・環境依存です

少し前までは、RTX5090（32GB）でGemma4-31Bモデルを動かすと60〜65 token/s程度の報告をXやネットで多くみかけました。

もちろんRTX5090+MTPだと更に速くなるはずですが、ソフトウェア側の手法だけで少し前の最高峰を大きく凌駕するパフォーマンスを出すのは大したものです。

しかもマルチGPUとは言え、ミドルクラスですから。

CUDAに限らず、一般論として並列演算効率は、大規模（重いモデル）であったり、個々の演算能力が悪い場合に良くなります。つまり超高速ハイエンドでマルチGPUやクラスタにしても、ボトルネックが転送やメモリ帯域になる可能性が高いので、あまり上手くいきません。

マルチGPUやクラスターと聞くと凄そうなイメージがありますが、安い・遅いGPUにこそ最適な利用方法なのかもしれません。

最近は、MTPに関連した新しい技術が続々登場しているので、これからの標準になるかもしれません。

それにしても、軽量モデルが精度悪く超高速でポンポン先に進み、それを主モデルが自分の思考として『追認』していく。まるで、これからのAIと人間の関係みたいですね。

以下、関連する記事の【PR】です