実行プログラムと拡張機能
DGX Sparkを2台つなぐと、実際に何が変わるのか
1つのDGX Sparkでモデルを起動しました。しかし、回答が期待よりも遅いです。もう1台のデバイスを追加すれば解決するでしょうか？2つ目のデバイスが担当するタスクの種類によって答えは変わります。より大きなモデルを収容するか、1人のユーザーの待ち時間の削減かなど、それぞれを別々に検証していきます。
モデルが1台分に収まらない場合
最初の理由は比較的明確です。望むモデルと会話用キャッシュが一つのメモリに収まらない場合です。実行プログラムがモデルを2つのノードに分割して保持できるならば、2番目のデバイスの空間を活用して実行可能な範囲を広げることができます。
256GBという表記は、128GBメモリ2枚の合計です。どのプログラムからも256GBをひとつの塊のように使うことはありません。モデルをどのように分割し、各デバイスにキャッシュをどれだけ残すかを決定する分散実行経路が必要です。
すでに1台のメモリに収まるなら、考えることが変わる
今回は、同じモデルが1台に余裕を持って収まるようにしてみます。2台に分割すれば、各デバイスが担う計算量は減ります。ただし、中間結果をネットワークでやり取りし、互いに待つ時間が増えます。この追加時間を超え計算量を減らさなければ、回答の速度は上がりません。
分割方式によっても違いがあります。モデルの前後を分割する場合と、1層の計算を一緒に分割する場合では、通信タイミングが異なります。そのため、2つのデバイスの帯域幅を足した値だけではデコード速度を計算することはできません。
「最適設定」という表現に何が含まれているのでしょうか？
結果が速ければ、デバイス数にとどまらず、モデルファイル、量子化、MTP、入力長および同時リクエスト数も確認すべきです。一つは基本設定で、二つはMTPと異なる圧縮バージョンを使用した場合、その差を二つ目のデバイスの効果と呼ぶことはできません。
比較順序は、1台で利用可能な設定をまず確定し、同じモデルの2つのパスを並べて確認するものです。1台では利用できない機能を2台でしか使用できない場合でもそれは重要なメリットですが、どのような違いが生じたかを残すことが、次の更新後も結果を理解できるようにするためです。
複数の仕事を同時に任せるなら、話は変わる
チャット1つ以上の要求だけでなく、ドキュメント処理とコーディングエージェントが同時に要求されるサーバーでは、全体の処理量が重要になります。モデルをそれぞれ複製して異なる要求を担当させたり、分散モデルがより多くの要求を処理できるように構成することができます。どちらが適切かは、モデルサイズとランタイムに依存します。
その際、総トークン数が増しても、個々のリクエストは遅れる可能性があります。各リクエストの最初のトークンの処理時間とデコード速度、同じ時間内で完了したリクエスト数を割って記録すべきです。家族やチームが共用する環境であれば、最も長い待ち時間を持つ人の体験も忘れないでください。
2台目への出費で、何を得たいのか
大きなモデルが必要な場合、単一のデバイスでは実行できない場合は、容量の拡大そのものが購入の理由になります。一方、短い会話だけを迅速に処理したい目的であれば、2台を管理・接続するコストを含めて、どの程度の待ち時間の削減が可能かを確認すべきです。
サイトで1台と2台の想定体験を比較してみてください。ただし、特定のパッチとランタイムの最良記録をすべてのモデルに適用した実測画面ではありません。差が小さい場合は1台の設定を調整する方向、2台でのみ可能である場合はその作業を中心に判断してください。2番目の機器は必ず何かを行う必要があります。