このトピックでは、GPU インスタンスに関するよくある質問とその回答を示します。
Function Compute の GPU インスタンスのドライバーと CUDA のバージョンは何ですか？
以下に、GPU インスタンスの主要コンポーネントのバージョンをリストします。
ドライバーバージョン: ドライバーには、
nvidia.koなどのカーネルモードドライバー (KMD) やlibcuda.soなどの CUDA ユーザーモードドライバー (UMD) が含まれます。Function Compute の GPU インスタンスが使用するドライバーは NVIDIA によって提供されます。ドライバーのバージョンは、機能の反復、新しい GPU のリリース、バグ修正、およびドライバーのライフサイクル満了の結果として変更される場合があります。ドライバー関連のコンポーネントをイメージに追加しないことを推奨します。詳細については、「システムが NVIDIA ドライバーを見つけられない場合はどうすればよいですか？」をご参照ください。CUDA Toolkit バージョン: CUDA Toolkit には、CUDA Runtime、cuDNN、cuFFT などのさまざまなコンポーネントが含まれています。CUDA Toolkit のバージョンは、使用するコンテナイメージによって決まります。
NVIDIA GPU ドライバーと CUDA Toolkit が正しく機能するには、バージョンの互換性が必要です。詳細については、「CUDA Toolkit リリースノート」をご参照ください。
現在、Function Compute の GPU インスタンスの KMD バージョンは 570.133.20 で、対応する CUDA UMD バージョンは 12.8 です。最適な互換性を得るために、CUDA UMD のバージョンを超えない範囲で、CUDA Toolkit バージョン 11.8 以降を使用することを推奨します。
関数実行中に「CUFFT_INTERNAL_ERROR」が報告された場合はどうすればよいですか？
CUDA 11.7 の cuFFT ライブラリには、上位互換性の問題があります。このエラーが発生した場合は、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 インスタンスタイプと同等です。詳細については、「インスタンス仕様」をご参照ください。
スナップショットの起動が失敗するのはなぜですか？
プロビジョニングされたインスタンスは、次の理由で起動に失敗することがあります。
プロビジョニングされたインスタンスの起動がタイムアウトする
エラーコード: 「FunctionNotStarted」
エラーメッセージ: 「ポート XXX の関数インスタンスのヘルスチェックが 120 秒で失敗しました」
解決策: アプリケーションの起動ロジックを確認し、インターネットからのモデルのダウンロードや大規模モデル (10 GB 超) の読み込みロジックが含まれているかどうかを確認します。モデルの読み込みロジックを実行する前に Web サーバーを起動することを推奨します。
関数またはリージョンのインスタンス数が上限に達した
エラーコード: 「ResourceThrottled」
エラーメッセージ: 「Reserve resource exceeded limit」
解決策: デフォルトでは、Alibaba Cloud アカウントはリージョンごとに割り当てられる物理 GPU が 30 に制限されています。実際のクォータは Quota Center で確認できます。より多くの物理 GPU が必要な場合は、Quota Center でクォータの調整を申請できます。
エラスティック GPU インスタンスのプロビジョニングに失敗し、「ResourceExhausted」または「ResourceThrottled」エラーが報告された場合はどうすればよいですか？
GPU リソースは比較的希少であるため、リソースプールの変動により、呼び出しリクエストを満たすためにエラスティック GPU インスタンスが時間内にプロビジョニングされない場合があります。より予測可能なリソース配信のために、事前にリソースを予約するよう、関数のプロビジョニングされたインスタンスを構成することを推奨します。エラスティックインスタンスとプロビジョニングされたインスタンスの課金の詳細については、「課金の概要」をご参照ください。
GPU イメージのサイズ制限は何ですか？
イメージサイズの制限は、圧縮されたイメージにのみ適用されます。Container Registry コンソールで圧縮イメージのサイズを確認できます。また、docker images コマンドを実行して、圧縮前のイメージのサイズをクエリすることもできます。
ほとんどの場合、20 GB 未満の非圧縮イメージは Function Compute にデプロイでき、期待どおりに機能します。
GPU イメージの高速化イメージへの変換に失敗した場合はどうすればよいですか？
イメージの変換に必要な時間は、イメージのサイズが大きくなるにつれて長くなります。これにより、タイムアウトによる変換失敗が発生する可能性があります。Function Compute コンソールで関数の構成を編集して再保存することで (実際にはパラメーターを調整せずに)、GPU イメージの変換を再トリガーできます。
モデルはイメージに統合すべきですか、それとも分離すべきですか？
モデルファイルが大きい場合、頻繁に反復される場合、またはイメージと一緒に公開するとイメージサイズの制限を超える場合は、モデルをイメージから分離することを推奨します。このような場合、モデルを NAS ファイルシステムまたは OSS ファイルシステムに保存できます。詳細については、「GPU インスタンスにおけるモデルストレージのベストプラクティス」をご参照ください。
モデルのウォームアップを実行するにはどうすればよいですか？
/initialize メソッドを使用してモデルをウォームアップすることを推奨します。本番トラフィックは、/initialize メソッドが完了した後にのみモデルに送られます。詳細については、次のトピックをご参照ください。
GPU イメージの起動時に「FunctionNotStarted」Function Instance health check failed on port xxx in 120 seconds が報告された場合はどうすればよいですか？
原因: AI/GPU アプリケーションの起動に時間がかかりすぎます。その結果、Function Compute のヘルスチェックが失敗します。ほとんどの場合、AI/GPU アプリケーションの起動は、モデルの読み込み時間が長いために時間がかかり、Web サーバーの起動がタイムアウトする原因となります。
解決策:
アプリケーションの起動中にインターネット経由でモデルを動的に読み込むことは避けてください。モデルをイメージまたは NAS ファイルシステムに配置し、最も近いパスから読み込むことを推奨します。
モデルの初期化を
/initializeメソッドに配置し、アプリケーションの起動完了を優先します。つまり、Web サーバーが起動した後にモデルを読み込みます。説明関数インスタンスのライフサイクルの詳細については、「インスタンスのライフサイクルを設定する」をご参照ください。
関数のエンドツーエンドのレイテンシーが高く、大きく変動する場合はどうすればよいですか？
まず、環境情報でイメージアクセラレーションの状態が「利用可能」であることを確認してください。
NAS ファイルシステムのタイプを確認してください。関数が NAS ファイルシステムからモデルなどのデータを読み取る必要がある場合は、最適なパフォーマンスを確保するために、容量型ではなくパフォーマンス最適化 NAS を使用することを強く推奨します。詳細については、「汎用型 NAS」をご参照ください。
システムが NVIDIA ドライバーを見つけられない場合はどうすればよいですか？
この問題は、docker run --gpus all コマンドを使用してコンテナーを指定し、その後 docker commit メソッドを使用してアプリケーションイメージをビルドした場合に発生します。ビルドされたイメージにはローカルの NVIDIA ドライバー情報が含まれているため、イメージが Function Compute にデプロイされた後にドライバーが正しくマウントされません。その結果、システムは NVIDIA ドライバーを見つけることができません。
この問題を解決するには、Dockerfile を使用してアプリケーションイメージをビルドすることを推奨します。詳細については、「dockerfile」をご参照ください。
さらに、ドライバー関連のコンポーネントをイメージに含めず、アプリケーションが特定のドライバーバージョンに依存しないようにしてください。たとえば、CUDA Driver API を提供する libcuda.so は、デバイスのドライバーバージョンと密接に関連しているため、イメージにパッケージングしないでください。このようなライブラリをイメージに含めると、バージョンの不一致がある場合に互換性の問題や予期しないアプリケーションの動作が発生する可能性があります。
関数インスタンスを作成すると、Function Compute はユーザーモードのドライバーコンポーネントをコンテナーに積極的に注入します。これらのコンポーネントは、Function Compute が提供するドライバーバージョンと一致します。このアプローチは、NVIDIA Container Runtime などの GPU コンテナー仮想化技術と一致しており、ドライバー固有のタスクはインフラストラクチャプロバイダーにデリゲートされます。これにより、異なる環境間での GPU コンテナイメージの互換性が最大化されます。Function Compute の GPU インスタンスに使用されるドライバーは NVIDIA から供給されます。継続的な機能の反復、新しい GPU モデル、バグ修正、およびドライバーのライフサイクルの変更により、GPU インスタンスで使用されるドライバーのバージョンは将来変更される可能性があります。
すでに NVIDIA Container Runtime または他の GPU コンテナー仮想化技術を使用している場合は、docker commit コマンドでイメージを作成しないでください。このようにして作成されたイメージには、注入されたドライバーコンポーネントが含まれている可能性があります。これらのイメージを Function Compute で実行すると、コンポーネントのバージョンとプラットフォームの不一致により、アプリケーションエラーなどの未定義の動作が発生する可能性があります。
プロビジョニングされたインスタンスを持つ GPU 関数の使用上の注意点は何ですか？
CUDA バージョン
CUDA 12.2 以前のバージョンを使用することを推奨します。
イメージの権限
コンテナイメージはデフォルトの root ユーザーとして実行することを推奨します。
インスタンスへのログイン
GPU がフリーズしているため、アイドル状態の GPU インスタンスにはログインできません。
インスタンスの正常なローテーション
Function Compute は、ワークロードに基づいてアイドル状態の GPU インスタンスをローテーションします。サービス品質を確保するために、モデルのウォームアップと事前推論のために、関数インスタンスにライフサイクルフックを追加することを推奨します。これにより、新しいインスタンスの起動直後に推論サービスを提供できます。詳細については、「モデルのウォームアップ」をご参照ください。
モデルのウォームアップと事前推論
アイドル状態の GPU インスタンスの初回ウェイクアップのレイテンシーを短縮するために、コード内で
initializeフックを使用してモデルをウォームアップまたはプリロードすることを推奨します。詳細については、「モデルのウォームアップ」をご参照ください。プロビジョニングされたインスタンスの構成
アイドルモードスイッチをオンにすると、関数の既存のプロビジョニングされた GPU インスタンスは正常にシャットダウンされます。プロビジョニングされたインスタンスは、短時間解放された後に再割り当てされます。
推論フレームワークの組み込みメトリクスサーバー
アイドル状態の GPU の互換性とパフォーマンスを向上させるために、NVIDIA Triton Inference Server や TorchServe などの推論フレームワークの組み込みメトリクスサーバーを無効にすることを推奨します。