モデルのシャードをNASに保存し、別の自宅コンピューターで実行できますか?

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

はい、ランタイムが完全で一貫性のあるチェックポイントを読み取れるなら、モデルのシャードをNASに保存し、別のホームコンピューターで実行できます。

GPUワークステーションがすべてのモデルファイルを恒久的に保管する必要はありません。NAS共有をマウントし、要求されたチェックポイントをシステムRAMまたはVRAMに読み込んでローカルで推論を実行しながら、NASを永続的なライブラリとして利用できます。重要なのはタイミングの違いです。ストレージは読み込み中や断続的なページング時にバイト列を提供しますが、コンピューターのプロセッサーとアクセラレーターは、それらのバイト列がアドレス可能になった後にテンソル演算を実行します。

シャードはストレージを分割するが、計算を自動的に分散するわけではない

シャーディングされたチェックポイントは、1つのモデルのテンソルを複数のファイルに分割し、単一ファイルが扱いにくいサイズになるのを防ぎます。インデックスには、各テンソルがどのシャードに属するかが記録されます。これにより、ダウンロード、保存、読み込みは容易になりますが、NAS上の各ディスクやホームコンピューターが1つのシャードを実行するという意味ではありません。保存時の分散と並列実行は、別々のアーキテクチャ上の判断です。

Transformersは、インデックスを読み取り、各重みファイルをモデルに読み込むことで、シャーディングされたチェックポイントを読み込めます。計算ノードには、テンソルをCPU、GPU、またはディスク上に配置するデバイスマップが必要です。シャードファイルを別々のフォルダーに置くだけでは、テンソル並列処理は実現せず、無関係な複数のマシンのVRAMが統合されることもありません。

ホーム環境では、NASはモデルリポジトリおよび出所情報の管理場所と考えるのが最適です。設定ファイル、トークナイザーファイル、シャードインデックス、チェックサム、ライセンスメタデータを重みファイルと一緒に保管します。ワークステーションは実行ノードです。このストレージと計算の分離は、メディアやドキュメントを集中管理しながら、専用ハードウェアで推論を処理するNASと計算ノードの構成にも見られます。

コールドスタートはネットワークを通過するバイト数に左右される

推論の前に、計算ノードは実行レイアウトを作成するため、チェックポイントを十分に読み込む必要があります。40 GBのモデルは小さな設定ファイルのようには起動できません。すでに有効なローカルキャッシュが存在しない限り、そのバイト列はLANを通過する必要があります。1GbE接続の理論上の上限は、プロトコルのオーバーヘッドを除いて約125 MB/sなので、大規模なコールドロードには数分かかることがあります。

ランタイムはメモリーマップ型モデルファイルを使用し、OSが必要に応じてページを取得し、ページキャッシュに保持できる場合があります。ネットワークファイルシステムでは、キャッシュミスが推論中のネットワーク読み込みになることがあります。これにより初期読み込みは短縮される可能性がありますが、遅延が最初のプロンプトに移り、キャッシュの追い出しやNASの競合によって性能が変動しやすくなることもあります。

ローカルNVMeキャッシュを使うと、所有権を重複させずに使用感を改善できます。ワークステーションは検証済みのモデルバージョンをNASから一度コピーし、ローカルストレージから実行して、マニフェストに従って削除または更新できます。NASが正本であり続け、キャッシュが繰り返し発生する読み込みを吸収します。ネットワーク帯域幅を増やすとコールドスタートは改善しますが、アクティブな重みとキャッシュが常駐した後のトークン生成速度は向上しません。

一貫性とファイルセマンティクスが障害の境界を決める

ローダーは、すべてのシャードとインデックスが同じモデルリビジョンを記述していることを前提とします。あるコンピューターが読み込み中に同期ジョブによってファイルを置き換えると、古いシャードと新しいシャードが混在したり、チェックサムエラーが発生したりする可能性があります。ファイルロック、アトミックなディレクトリ交換、不変のバージョンフォルダー、完成済みマニフェストによって、読み取り側が公開途中のチェックポイントを見ないようにできます。

分散フレームワークは、ストレージの調整を明示的に考慮しています。PyTorchの分散チェックポイントAPIは、互換性のある分散アプリケーション向けに、ストレージリーダーと読み込み時の再シャーディングをサポートします。これは、汎用共有をマウントして、どのランタイムでも学習用シャードを解釈できると期待することとは異なります。推論形式、テンソル名、量子化、デバイス配置も、選択したエンジンと一致している必要があります。

ランタイムがローカルファイルを必要とする場合、ネットワークロックの動作が想定と異なる場合、ページフォールト中にWi-Fi接続が切断される場合、またはワーキングセットがRAM容量を繰り返し超える場合、NASから実行できるという前提は成り立ちません。また、「シャード」が移植可能な推論チェックポイントではなく、学習時のトポロジーに結び付いている場合も失敗します。すべてのチェックポイント形式が互換性を持つと考えるのではなく、デプロイ前にモデルを変換または統合してください。

3回の実行でストレージをテストする

ワークステーションのキャッシュを消去した後のコールドネットワーク実行、OSキャッシュからのウォーム実行、SSD上のローカルキャッシュからの実行を測定します。モデルの準備完了までの時間、最初のトークンまでの時間、持続的な毎秒トークン数、起動後に読み取られたネットワークバイト数、その他のNASワークロードが結果に与える影響を記録します。この3回の実行により、転送時間と実行速度を切り分けられます。

モデルのコールドスタート時のストレージについて詳しく説明した記事では、生成開始前に形式、メモリーマッピング、ページキャッシュ、同時I/Oが重要になる理由を解説しています。このモデルレベルのテストに、リポジトリのファイルチェックサム確認を組み合わせてください。誤ったリビジョンを高速に読み込むよりも、遅くても再現可能な読み込みのほうが優れています。

コールドスタートがまれで、ネットワークが安定しており、ワーキングセットがキャッシュに収まる場合は、NASから直接実行します。モデルを頻繁に起動する場合や遅延が重要な場合は、ローカルキャッシュを使用します。生成中もネットワーク読み込みが続く場合は、ページングの負荷を減らすか、LANをアップグレードする前にモデルをローカルへコピーしてください。合格条件はモデルが開くことではなく、ストレージアクセスが不安定でも実行途中に依存せず、再現可能な読み込みができることです。

テスト 測定対象 想定される判断
NASからのコールドロード LANとストレージのスループット 起動頻度が低い場合は許容
NASからのウォームロード ページキャッシュの効果 キャッシュが安定して維持される場合に有効
ローカルSSDキャッシュ 実行ノードのストレージ上限 起動時間が重要な場合に優先

よくある質問

2台のコンピューターで同じモデルファイルを同時に使用できますか?

不変のモデルバージョンを読み取り専用で開く場合は可能です。ただし、各コンピューターはそれぞれの実行状態とKVキャッシュを読み込みます。同時に読み取っても、RAM、VRAM、生成コンテキストが自動的に共有されるわけではありません。

10GbEにすると推論は速くなりますか?

大規模なコールドロードを短縮し、ページフォールトによる遅延を減らせる可能性があります。重みが常駐した後の生成は通常、NASのスループットではなく、実行ノードの計算性能とメモリ帯域幅によって制限されます。

GGUFの分割ファイルは学習用シャードと同じですか?

いいえ。どちらもデータを複数のファイルに分割しますが、メタデータ、読み込み規則、想定ランタイムは異なります。NAS上のコピーを実行可能なものとして扱う前に、推論エンジンがその分割形式を正確にサポートしていることを確認してください。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.