GPU を備えたインスタンスに関するよくある質問 - Function Compute

このトピックでは、GPUアクセラレーションインスタンスに関するよくある質問に対する回答を提供します。

Function ComputeのGPUアクセラレーションインスタンスのドライバーバージョンとCUDAバージョンは何ですか?
関数の実行中にCUFFT_INTERNAL_ERRORが報告された場合はどうすればよいですか?
イメージをビルドするときにCUDA GPGエラーが報告された場合はどうすればよいですか?
GPUアクセラレーションインスタンスのインスタンスタイプがg1であるのはなぜですか。
プロビジョニングされたGPUアクセラレーションインスタンスが割り当てられないのはなぜですか?
GPUイメージのサイズの制限は何ですか?
GPUイメージを高速化イメージに変換できない場合はどうすればよいですか?
モデルを画像に統合または分離する必要がありますか?
モデルのウォームアップを実行するにはどうすればよいですか?
GPUイメージの起動時に [FunctionNotStarted] ファンクションインスタンスのヘルスチェックがポートxxxで120秒で失敗した場合、どうすればよいですか?
関数のエンドツーエンドのレイテンシが大きく、大きく変動する場合はどうすればよいですか?
システムがNVIDIAドライバーを见つけられない场合はどうすればよいですか?
AdaシリーズのGPUアクセラレーションインスタンスで「現在のGPUタイプのオンデマンド呼び出しが無効になっています... 」が報告された場合はどうすればよいですか?

Function ComputeのGPUアクセラレーションインスタンスのドライバーバージョンとCUDAバージョンは何ですか?

次の項目は、GPUアクセラレーションインスタンスの主要コンポーネントのバージョンを示しています。

ドライバーバージョン: ドライバーには、nvidia.koなどのカーネルモードドライバー (KMD) とlibcuda.soなどのCUDAユーザーモードドライバー (UMD) が含まれます。 Function ComputeのGPU高速化インスタンスによって使用されるドライバは、NVIDAによって提供され、Function Computeによってデプロイされます。 GPUアクセラレーションインスタンスで使用されるドライバーのバージョンは、イテレーション、新しいカードモデルのリリース、バグ修正、ドライバーのライフサイクルの有効期限の結果として変更される場合があります。コンテナーイメージで特定のドライバーバージョンを指定しないことを推奨します。詳細については、「画像の使用に関する注意事項」をご参照ください。
CUDA Toolkitのバージョン: CUDA Toolkitには、CUDA Runtime、cuDNN、cuFFTなどのさまざまなコンポーネントが含まれています。 CUDA Toolkitのバージョンは、使用するコンテナイメージによって決まります。

GPUドライバーとCUDA ToolkitはNVIDIAによってリリースされ、互いに関連しています。詳細については、「NVIDIA CUDA Toolkitリリースノート」をご参照ください。

Function ComputeのGPUアクセラレーションインスタンスの現在のドライババージョンは550.54.15で、CUDAモジュールのバージョンは12.4です。互換性を高めるために、CUDA Toolkit 11.8以降を使用し、バージョンがプラットフォームのバージョンよりも新しいCUDA UMDを使用しないことをお勧めします。

関数の実行中にCUFFT_INTERNAL_ERRORが報告された場合はどうすればよいですか?

CUDA 11.7のcuFFTライブラリには、前方互換性の問題があります。 Ampereより新しいカードタイプで上記のエラーが発生した場合は、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 A4B469963BF863CC

GPUアクセラレーションインスタンスのインスタンスタイプがg1であるのはなぜですか。

g1インスタンスタイプはfc.gpu.tesla.1と同じです。詳細については、「インスタンスの仕様」をご参照ください。

プロビジョニングされたGPUアクセラレーションインスタンスが割り当てられないのはなぜですか?

次の理由により、プロビジョニングされたインスタンスの割り当てが失敗する場合があります。

プロビジョニングされたインスタンスの起動がタイムアウトします。
- エラーコード: FunctionNotStarted.
- エラーメッセージ: ファンクションインスタンスのヘルスチェックはポートXXXで120秒で失敗しました。
- 解決策: アプリケーションの起動ロジックを表示して、インターネットからモデルをダウンロードし、大きなモデル (10 GBを超える) をロードするロジックが存在するかどうかを確認します。モデルの読み込みロジックを実行する前に、webサーバーを起動することをお勧めします。
関数レベルまたはリージョンレベルでのインスタンスの最大数に達しました。
- エラーコード: ResourceThrottled.
- エラーメッセージ: 予約リソースの制限を超えました。
- 解決策: より多くの物理GPUカードを使用する場合は、DingTalkグループ64970014484に参加してテクニカルサポートを行います。

GPUイメージのサイズの制限は何ですか?

画像サイズ制限は、圧縮画像にのみ適用されます。圧縮されたイメージのサイズは、Container Registryコンソールで確認できます。 docker imagesコマンドを実行して、非圧縮イメージのサイズを照会できます。

ほとんどの場合、サイズが20 GB未満の非圧縮イメージをFunction Computeにデプロイして、期待どおりに使用できます。

GPUイメージを高速化イメージに変換できない場合はどうすればよいですか?

画像の変換に必要な時間は、画像のサイズが大きくなるにつれて長くなります。タイムアウトエラーにより、変換が失敗する可能性があります。 Function Computeコンソールで関数設定を設定して保存することで、GPUイメージの高速化変換を再トリガーできます。既存の設定を保持する場合は、パラメーターを変更する必要はありません。

モデルを画像に統合または分離する必要がありますか?

モデルファイルが大きい場合、頻繁に反復処理される場合、またはイメージとともに公開されるときにイメージのサイズ制限を超える場合は、モデルをイメージから分離することをお勧めします。モデルのサイズが100 MBなど小さく、頻繁に変更されない場合は、モデルファイルをイメージとともに配布できます。プラットフォームイメージのサイズの制限の詳細については、GPUイメージのサイズの制限は何ですか?

モデルをイメージとは別にデプロイするには、モデルをFile Storage NAS (NAS) ファイルシステムまたはObject Storage Service (OSS) ファイルシステムに保存します。モデルは、アプリケーションの起動時にマウントターゲットから読み込まれます。詳細については、「NASファイルシステムの設定」および「OSSファイルシステムの設定」をご参照ください。

モデルをPerformance NASファイルシステムに保存することをお勧めします。このファイルシステムは、Portable Operating system Interface (POSIX) と互換性があり、モデルの読み込みに必要な時間を短縮できる高い初期読み取り帯域幅を備えています。詳細については、「汎用 NAS ファイルシステム」をご参照ください。
モデルをOSSバケットに保存することもできます。これにより、OSSアクセラレータを使用して、低レイテンシと高スループットを実現できます。 OSSファイルシステムをマウントすると、ワークロードはUMDとインスタンスメモリで処理され、一時的なストレージスペースが消費されます。したがって、仕様の大きいGPU高速化インスタンスではOSSを使用することを推奨します。

モデルのウォームアップを実行するにはどうすればよいですか?

/initializeメソッドでモデルをウォームアップすることを推奨します。モデルは、/initializeメソッドが完了した後にのみ本番トラフィックに接続されます。モデルのウォームアップの詳細については、次のトピックを参照してください。

GPUイメージの起動時に [FunctionNotStarted] ファンクションインスタンスのヘルスチェックがポートxxxで120秒で失敗しましたエラーが報告された場合はどうすればよいですか?

原因: AI/GPUアプリケーションの起動に時間がかかりすぎます。その結果、Function Computeのヘルスチェックは失敗します。 AI/GPUアプリケーションの起動に時間がかかりすぎる一般的な理由は、モデルの読み込みに時間がかかりすぎるため、webサーバーの起動がタイムアウトすることです。
解決策：
- アプリケーションの起動時に、インターネット経由でモデルを動的にロードしないでください。モデルをイメージまたはNASファイルシステムに配置し、最も近いパスからモデルをロードすることを推奨します。
- モデル初期化を /initializeメソッドに配置して、アプリケーションを優先的に起動します。具体的には、webサーバーの起動後にモードをロードします。
  説明
  関数インスタンスのライフサイクルの詳細については、「関数インスタンスのライフサイクル」をご参照ください。

関数のエンドツーエンドのレイテンシが大きく、大きく変動する場合はどうすればよいですか?

イメージアクセラレーションの状態が環境情報で使用可能であることを確認してください。
NASファイルシステムのタイプを確認してください。関数がNASファイルシステムからモデルなどのデータを読み取る必要がある場合は、パフォーマンスを確保するために、Capacityタイプの代わりにPerformance NASファイルシステムを使用することをお勧めします。詳細については、「汎用 NAS ファイルシステム」をご参照ください。

システムがNVIDIAドライバーを见つけられない场合はどうすればよいですか?

この問題は、docker run -- gpus allコマンドを実行してコンテナーを指定し、docker commitメソッドを使用してアプリケーションイメージを構築すると発生します。ビルドされたイメージにはオンプレミスのNVIDIA情報が含まれており、イメージがFunction Computeにデプロイされた後はドライバをマウントできません。システムはNVIDIAドライバを見つけることができません。

この問題を解決するには、Dockerfileを使用してアプリケーションイメージを作成することを推奨します。詳細は、「Dockerfile」をご参照ください。

コンテナーイメージで特定のドライバーバージョンを指定しないでください。詳細については、「画像の使用に関する注意事項」をご参照ください。

AdaシリーズのGPUアクセラレーションインスタンスで「現在のGPUタイプのオンデマンド呼び出しが無効になっています... 」が報告された場合はどうすればよいですか?

通常、ResourceExhausted: 現在のGPUタイプのオンデマンド呼び出しは無効です。代わりにインスタンスをプロビジョニングしてください AdaシリーズのGPUアクセラレーションインスタンスは、プロビジョニングされたモードのみをサポートします。実際のリクエスト数に基づいて、プロビジョニングされるインスタンスの数を増やすことを推奨します。