要約版 - 私の状況では、export CUDA_VISIBLE_DEVICES="1,0" を llama.cpp の起動スクリプトに追加することで、いくつかの状況でプロンプト処理速度が2倍になりました。
皆さん、私は、2つの "x16" スロット間で PCI-E レーンを 16x / 4x に分割するシステム上でデュアル 3090 の構成を実行しています（x570 ボードでは一般的だと思います）。 理由はともかく、少なくとも私のセットアップ（Ubuntu-Server 24.04、NVIDIA 580.126.20 ドライバー、x570 ボード）では、CUDA0 デバイスは 4 レーンの PCI Express スロット上のものです。
この行を run-llama.cpp.sh スクリプトに追加すると、私のプロンプト処理速度は（MoE モデルの場合は少なくとも）2倍 になりました。この操作はやらないでください、PCI-E レーンが同様に非対称に分割されている、または GPU のパフォーマンス順序が異なる場合を除きます。リンク速度を確認するには nvtop を使用するか、より詳しい lspci のオプションを使って確認してください。
過大サイズの MoE モデルでは、70 t/s から140 t/s に跳ね上がり、私は とても興奮しています。 この喜びを共有せずにはいられませんでした。
システムが x8/x8 の分割を行う場合には無関係ですが、2つの異なるレーン数がある場合、または 2 つの異なる GPU がある場合には関連します。GPU 間で分割方法が異なる ik_llama.cpp や vLLM のようなものでは、私が試していないため影響は小さいかもしれませんが、少なくとも現行の標準的な llama.cpp では、私には大きな差をもたらします！
この無料のパフォーマンスブーストを見ることができて、私は とても興奮しています。
この発見はどうやって知ったのか？ 最近 nvtop を見ていて、プロンプト処理中には作業の大半が GPU0 / CUDA0 で発生しており、それが 4 レーンしか使われていないことを思い出しました。パフォーマンスの変化は控えめだろうと予想していましたが、PP t/s がなんと2倍になるのはあまりにも予想外で、私は正気かどうかを確かめるために何度もテストし、古いベンチマークとスワップの有無を含む現在のベンチマークと比較しました。くそっ！
非過大サイズのモデルでも同程度の差があるかどうか、しばらくしてから追記して知らせます。おそらくそのような状況では僅かな改善が見られると推測します。しかし、DDR4 x570 システムと2台のGPUを持つ人はここにいるのは私だけではないはずです。なので、誰かの一日が少しでも良くなることを願っています！
[リンク] [コメント]
