先読みはモデルの読み込み時間と共有ストレージのトラフィックにどのような影響を与えるか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Does Read-Ahead Affect Model Loading Time and Shared Storage Traffic? - Zima Store Online

先読みは後続ページを事前取得することで、モデルの逐次読み込みを短縮できます。ただし、ウィンドウが大きすぎると、キャッシュと共有ストレージの帯域幅を浪費するおそれがあります。

複数のホームAIワーカーがNAS上の数GBに及ぶ同じモデルを開くと、要求読み込みでは、各ワーカーが未取得のページに到達するたびに処理が停止することがあります。先読みを使えば後続ページを準備できますが、各クライアントが実際には使わないデータを要求したり、別のクライアントと同じトラフィックを重複させたりする可能性もあります。結果は、アクセス順序、メモリマッピング、ページキャッシュの再利用、モデルのシャーディング、同時実行数、ストレージ遅延、そしてキャッシュが行われる場所によって変わります。

先読みは、逐次的な要求読み込みを早期I/Oへ変換する

有効なキャッシュ状態がない場合、ローダーはページに到達すると、ストレージからそのページが返されるまで待機します。先読みは逐次アクセスを検出し、プロセスが要求する前に後続ページへのリクエストを発行します。予測とタイミングが合えば、計算が現在の領域を処理している間に、ストレージが次の領域を埋めていきます。

Linuxのページキャッシュは先読みを適用し、観測したアクセス状況に応じてウィンドウを拡大または縮小します。バッファ付きの逐次読み込みでは、ローダーが到達した時点で後続ページがすでに常駐している可能性があるため、有効です。

ストレージ遅延によって処理に空白が生じ、モデルが予測可能な順序で読み込まれる場合に、効果は最大になります。ファイルがすでにキャッシュされている場合、ダイレクトI/Oがページキャッシュを迂回する場合、ローダーがすべてを明示的に先読みする場合、またはランタイムがマッピング済みページに不規則なパターンでアクセスする場合、効果は小さくなります。

メモリマッピングでは、ページフォールトの順序が読み込みの一部になる

メモリマッピングを使うと、すべての重みページが常駐する前にランタイムがアドレスマッピングを作成するため、モデルの起動が速く見えることがあります。物理I/Oはページがアクセスされた時点で発生します。そのため、見かけ上の読み込み時間は、ベンチマークがマッピング後に終了するのか、それとも推論によってワーキングセットへのページフォールトが完了するまで続くのかによって変わります。

メモリマップされたモデル重みでは、欠落ページのフォールト時にストレージ遅延が発生する可能性があり、不規則なアクセスによって小さな読み込みが多数発生することもあります。アクセス順序が予測できる程度に逐次的であれば先読みが役立ちますが、そうでなければ誤った領域を取得する可能性があります。

モデルオブジェクトの作成にかかる時間と、最初のトークンが完全に生成されるまでの時間を別々に測定してください。I/Oを起動時から最初のリクエストへ移しただけの変更は、読み込み作業を取り除いたことにはなりません。ページの再利用が結果を大きく左右する可能性があるため、ウォームキャッシュのテストとコールドキャッシュのテストは分けて実施してください。

大きすぎるウィンドウはキャッシュを汚染し、共有帯域幅を消費する

ローダーの直近のワーキングセットを超えて広がるプリフェッチウィンドウでは、使用前に追い出されるページまで転送してしまいます。そうしたページはクライアントメモリを占有し、他のキャッシュエントリを追い出し、NASへのリンクとストレージバックエンドの帯域幅を消費します。複数のローダーが異なるモデルを同時に起動すると、この無駄はより顕著になります。

過剰な先読みは不要なデータでキャッシュを汚染する可能性があり、少なすぎる先読みは後続の要求読み込みを引き起こします。どちらも性能を低下させます。逐次読み込み、スパースなエキスパートアクセス、混在するストレージトラフィックのすべてに対して、固定のデフォルト値を最適にすることはできません。

共有ストレージでは、各クライアントが他のクライアントの取得内容を必ずしも把握せずにローカルで予測するため、問題が拡大します。サーバー側のキャッシュがこれらの読み込みを統合できない場合、同期した起動で積極的なプリフェッチがトラフィックバーストを引き起こし、すべてのローダーや無関係なNAS処理を遅延させる可能性があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

キャッシュの場所によって、ローダーがメリットを共有できるかが決まる

クライアントのページキャッシュはそのマシン上のプロセスにメリットをもたらします。一方、NASのキャッシュは複数のクライアントにメリットをもたらせますが、それでもネットワーク転送は必要です。GPUメモリも別の保存先です。そのため、同じモデルのバイト列がサーバー、クライアントRAM、アクセラレーターにそれぞれキャッシュされることがあり、いずれか1つの層だけでは他の層でのデータ移動をなくせません。

モデルシャーディングを使うと、ワーカーはファイル全体ではなく、割り当てられた領域だけを読み込む場合があります。ファイル全体を対象にした先読みは、ワーカーが決して使わないシャードまで取得することで、その利点を損なう可能性があります。一方、シャードに合わせたアクセスなら、先読みを有用な範囲内に保てます。

同じホスト上の並行プロセスは、ファイルバックドページを共有できる場合がありますが、別のホスト同士でクライアントRAMを共有することはできません。実際のトポロジーをテストしてください。ローカルSSD、Ethernet経由のNAS、分散キャッシュ、モデルファイルのコピーなどです。同じ先読み設定でも、ローカルの停止時間を減らしながら、ネットワーク上の総転送量を増やす可能性があります。

コールド、ウォーム、同時実行の読み込みで先読みを調整する

テスト中は、モデルファイル、ランタイム、ストレージパス、ハードウェアを固定し、複数のウィンドウサイズを試してください。コールド状態で最初のトークンが生成されるまでの時間、ウォーム状態での再起動時間、ストレージからの読み込みバイト数、ネットワークスループット、ページフォールト、キャッシュへの負荷、他のNASワークロードのレイテンシを記録します。ローダーを1つだけ動かす場合と、想定される同時実行数で動かす場合の両方を繰り返してください。

プリフェッチとキャッシュに関する実践的な解説では、これらの層が独立したスイッチとしてではなく、相互に作用することが示されています。改善の原因は、役立つ早期読み込み、サーバーキャッシュ、クライアントでの再利用のいずれかに帰属させるべきであり、単一の起動時間だけで判断してはいけません。

最適な設定はワークロードによって異なります。コールド状態での停止時間を減らしつつ、未使用バイト数や同時実行による干渉を大幅に増やさない範囲で、先読みを増やしてください。アクセスがスパースな場合、シャーディングされている場合、またはキャッシュへの負荷が高い場合は、先読みを減らします。ランタイム、モデル形式、シャード配置、ストレージトポロジーを変更した後は、再評価してください。