このトピックでは、GPU アクセラレーテッドインスタンスについてよくある質問への回答を提供します。
Function Compute の GPU アクセラレーテッドインスタンスのドライバーと CUDA のバージョンは何ですか？
以下の項目は、GPU アクセラレーテッドインスタンスの主要コンポーネントのバージョンを示しています。
ドライバーバージョン: ドライバーには、
nvidia.koなどのカーネルモードドライバー（KMD）と、libcuda.soなどの CUDA ユーザーモードドライバー（UMD）が含まれます。 NVIDIA は、関数計算の GPU アクセラレーションインスタンスで使用されるドライバーを提供しています。 GPU アクセラレーションインスタンスで使用されるドライバーのバージョンは、機能の反復、新しい GPU のリリース、バグ修正、ドライバーのライフサイクルの期限切れなどによって変更される可能性があります。イメージにドライバー関連のコンポーネントを追加しないことをお勧めします。詳細については、「システムが NVIDIA ドライバーを見つけられない場合はどうすればよいですか？」をご参照ください。CUDA Toolkit のバージョン：CUDA Toolkit には、CUDA ランタイム、cuDNN、cuFFT など、さまざまなコンポーネントが含まれています。 CUDA Toolkit のバージョンは、使用するコンテナイメージによって決まります。
NVIDIA によってリリースされた GPU ドライバーと CUDA Toolkit は、互いに関連しています。 詳細については、「NVIDIA CUDA Toolkit リリースノート」を参照してください。
関数計算における GPU アクセラレーションインスタンスの現在のドライバーバージョンは 570.133.20 で、対応する CUDA UMD のバージョンは 12.8 です。最適な互換性を得るには、CUDA ツールキット 11.8 以降を使用することをお勧めしますが、CUDA UMD のバージョンを超えないようにしてください。
関数の実行中に「CUFFT_INTERNAL_ERROR」が報告された場合はどうすればよいですか？
CUDA 11.7 の cuFFT ライブラリには、上位互換性の問題があります。新しい GPU モデルでこのエラーが発生した場合は、CUDA 11.8 以降にアップグレードすることをお勧めします。 GPU モデルの詳細については、「インスタンスの仕様」をご参照ください。
PyTorch を例に挙げます。アップグレード後、次のコードスニペットを使用して検証できます。エラーが報告されない場合は、アップグレードは成功です。
import torch
out = torch.fft.rfft(torch.randn(1000).cuda())イメージのビルド時に CUDA GPG エラーが報告された場合はどうすればよいですか？
イメージのビルドプロセス中に、次の GPG エラーが報告されます。
W: GPG error: https://developer.download.nvidia.cn/compute/cuda/repos/ubuntu2004/x86_64 InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A4B469963BF863CC
E: The repository 'https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64 InRelease' is not signed.この場合、次のスクリプトを Dockerfile ファイルの RUN rm コマンドラインに追加して、イメージを再ビルドできます。
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys A4B469963BF863CCGPU アクセラレーテッドインスタンスのインスタンスタイプが g1 なのはなぜですか？
g1 インスタンスタイプは fc.gpu.tesla.1 インスタンスタイプと同等です。 詳細については、「インスタンスの仕様」をご参照ください。
プロビジョニングされた GPU アクセラレーテッドインスタンスの割り当てが失敗するのはなぜですか？
プロビジョニングされたインスタンスの割り当ては、次の理由で失敗する可能性があります。
プロビジョニングされたインスタンスの起動がタイムアウトしました。
エラーコード：FunctionNotStarted。
エラーメッセージ：Function instance health check failed on port XXX in 120 seconds.
解決策：アプリケーションの起動ロジックをチェックして、インターネットからモデルをダウンロードするロジックと大きなモデル（10 GB 超）を読み込むロジックが含まれているかどうかを確認します。 Web サーバーを起動してから、モデルの読み込みロジックを実行することをお勧めします。
関数レベルまたはリージョンレベルのインスタンスの最大数に達しました。
エラーコード：ResourceThrottled。
エラーメッセージ：Reserve resource exceeded limit.
解決策：デフォルトでは、Alibaba Cloud アカウントあたり、リージョンごとに割り当てられる物理 GPU は 30 個に制限されています。 実際のクォータは、クォータセンターコンソールで確認できます。より多くの物理 GPU が必要な場合は、クォータセンターコンソールでクォータの調整を申請できます。
GPU イメージのサイズ制限は何ですか？
イメージサイズの制限は、圧縮されたイメージにのみ適用されます。圧縮されたイメージのサイズは、コンテナレジストリコンソール で確認できます。また、docker images コマンドを実行して、圧縮前のイメージのサイズをクエリすることもできます。
ほとんどの場合、20 GB 未満の非圧縮イメージは Function Compute にデプロイでき、想定どおりに機能します。
GPU イメージをアクセラレーテッドイメージに変換できない場合はどうすればよいですか？
イメージの変換に必要な時間は、イメージのサイズが大きくなるにつれて増加します。これにより、変換が失敗する可能性があります。 Function Computeコンソールで関数の構成を編集して再保存することにより、GPU イメージの変換を再トリガーできます。編集中に既存の設定を保持する場合、実際にはパラメーターを変更する必要はありません。
モデルはイメージに統合する必要がありますか、それともイメージから分離する必要がありますか？
モデルファイルが大きい場合、頻繁に反復する場合、またはイメージと一緒に公開するとイメージサイズの制限を超える場合は、モデルをイメージから分離することをお勧めします。そのような場合は、モデルを NAS ファイルシステムまたは OSS ファイルシステムに保存できます。
モデルのウォームアップを実行するにはどうすればよいですか？
/initialize メソッドを使用してモデルをウォームアップすることをお勧めします。 /initialize メソッドに基づくウォームアップが完了した後でのみ、本番トラフィックがモデルに転送されます。モデルのウォームアップの詳細については、次のトピックを参照してください。
[FunctionNotStarted] Function Instance health check failed on port xxx in 120 seconds エラーが GPU イメージの起動時に報告された場合はどうすればよいですか？
原因：AI/GPU アプリケーションの起動に時間がかかりすぎています。その結果、Function Compute のヘルスチェックが失敗します。ほとんどの場合、AI/GPU アプリケーションの起動には、モデルの読み込み時間が長いため時間がかかり、Web サーバーの起動がタイムアウトする可能性があります。
解決策：
アプリケーションの起動中に、インターネット経由でモデルを動的に読み込まないようにしてください。モデルをイメージまたは NAS ファイルシステムに配置し、最寄りのパスから読み込むことをお勧めします。
モデルの初期化を
/initializeメソッドに配置し、アプリケーションの起動を優先します。つまり、Web サーバーの起動後にモデルをロードします。説明関数インスタンスのライフサイクルの詳細については、「関数インスタンスのライフサイクル」をご参照ください。
関数のエンドツーエンドのレイテンシが大きく変動する場合はどうすればよいですか？
環境情報でイメージアクセラレーションの状態が「利用可能」になっていることを確認します。
NAS ファイルシステムのタイプを確認します。関数が NAS ファイルシステムからモデルなどのデータを読み取る必要がある場合は、最適なパフォーマンスを確保するために、容量型ではなくパフォーマンス NAS ファイルシステムを使用することをお勧めします。 詳細については、「汎用 NAS ファイルシステム」をご参照ください。
システムが NVIDIA ドライバーを見つけられない場合はどうすればよいですか？
この問題は、docker run --gpus all コマンドを使用してコンテナを指定し、docker commit メソッドを使用してアプリケーションイメージをビルドすると発生します。ビルドされたイメージにはローカルの NVIDIA ドライバー情報が含まれているため、イメージが関数計算にデプロイされた後にドライバーが正しくマウントされません。その結果、システムは NVIDIA ドライバーを見つけることができません。
この問題を解決するには、Dockerfile を使用してアプリケーションイメージをビルドすることをお勧めします。 詳細については、「Dockerfile」を参照してください。
さらに、イメージにドライバー関連のコンポーネントを含めないでください。また、アプリケーションを特定のドライバーバージョンに依存させないでください。たとえば、CUDA Driver API を提供する libcuda.so をイメージにパッケージ化しないでください。この動的ライブラリは、デバイスのドライバーバージョンと密接に関連付けられています。このようなライブラリをイメージに含めると、基盤となるシステムとのバージョンの不一致が発生した場合に、互換性の問題や予期しないアプリケーションの動作が発生する可能性があります。
関数インスタンスを作成すると、関数計算はユーザーモードドライバーコンポーネントをコンテナに事前に挿入します。これらのコンポーネントは、関数計算によって提供されるドライバーバージョンと一致しています。このアプローチは、NVIDIA Container Runtime などの GPU コンテナ仮想化テクノロジーと一致しています。これらのテクノロジーでは、ドライバー固有のタスクがインフラストラクチャプロバイダーに委任されるため、さまざまな環境での GPU コンテナイメージの互換性が最大化されます。関数計算 GPU インスタンスに使用されるドライバーは、NVIDIA によって提供されます。機能の反復、新しい GPU モデル、バグ修正、ドライバーのライフサイクルの変更に伴い、GPU インスタンスで使用されるドライバーバージョンは将来変更される可能性があります。
NVIDIA Container Runtime またはその他の GPU コンテナ仮想化テクノロジーをすでに使用している場合は、docker commit コマンドでイメージを作成しないでください。このように作成されたイメージには、挿入されたドライバーコンポーネントが含まれている場合があります。これらのイメージを関数計算で実行すると、コンポーネントのバージョンとプラットフォームの不一致により、アプリケーションエラーなどの未定義の動作が発生する可能性があります。
オンデマンド呼び出し中に GPU アクセラレーションインスタンスのプロビジョニングに失敗し、「ResourceExhausted」または「ResourceThrottled」エラーが報告された場合はどうすればよいですか？
GPU リソースは比較的不足しているため、オンデマンド呼び出しはリソースプールの変動の影響を受ける可能性があり、インスタンスが時間内にプロビジョニングされない可能性があります。より予測可能なリソース可用性を得るには、関数の自動スケーリングルールを構成して、GPU リソースを事前に予約することをお勧めします。詳細については、「自動スケーリングルールの構成」をご参照ください。プロビジョニングされたインスタンスの課金の詳細については、「課金概要」をご参照ください。