このトピックでは、GPU インスタンスに関する一般的な問題とその解決方法について説明します。
Function Compute GPU インスタンスのドライバーおよび CUDA バージョンはどれですか？
GPU インスタンスのコンポーネントバージョンは以下の 2 つに分けられます。
ドライバーバージョン：カーネルモードドライバー
nvidia.koおよび CUDA ユーザーモードドライバーlibcuda.soを含みます。Function Compute GPU インスタンスのドライバーは NVIDIA によって提供され、Function Compute プラットフォームによってデプロイされます。GPU インスタンスのドライバーバージョンは、機能の反復、新しいカードモデルの追加、バグ修正、またはドライバーのライフサイクル期限切れなどの理由により変更される可能性があります。コンテナイメージにドライバー固有のコンテンツを追加しないでください。詳細については、「NVIDIA ドライバーが見つからない場合はどうすればよいですか？」をご参照ください。CUDA Toolkit バージョン：CUDA Runtime、cuDNN、および cuFFT を含みます。CUDA Toolkit バージョンは、コンテナイメージをビルドする際に決定します。
GPU ドライバーおよび CUDA Toolkit は NVIDIA によってリリースされており、特定のバージョン対応関係があります。詳細については、該当バージョンの「CUDA Toolkit Release Notes」をご参照ください。
現在、Function Compute ではドライバーバージョン 580.95.05 を使用しています。対応する CUDA ユーザーモードドライバーバージョンは 13.0 です。最適な互換性を得るには、プラットフォームが提供する CUDA ユーザーモードドライバーバージョン以下で、かつ 11.8 以降の CUDA Toolkit バージョンを使用してください。
実行中に 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 A4B469963BF863CCご利用の GPU インスタンスタイプが g1 と表示されるのはなぜですか？
インスタンスタイプを g1 に設定することは、fc.gpu.tesla.1 に設定することと同じです。詳細については、「仕様」をご参照ください。
インスタンスが起動しないのはなぜですか？
インスタンスが起動しない原因として、以下のものが考えられます。
起動タイムアウト
エラーコード：「FunctionNotStarted」
エラーメッセージ：「Function instance health check failed on port XXX in 120 seconds」
解決方法：パブリックネットワークからモデルをダウンロードするタスクや、10 GB を超える大規模モデルの読み込みなど、アプリケーションの起動ロジックを確認してください。Web サーバーを先に起動し、その後でモデルを読み込んでください。
関数またはリージョンの最大インスタンス数に達している
エラスティック GPU インスタンスが作成できず、「ResourceExhausted」または「ResourceThrottled」エラーが報告された場合はどうすればよいですか？
GPU リソースは限定的です。リソースプールの変動により、呼び出しリクエストに対応するためにエラスティック GPU インスタンスがタイムリーに作成できない場合があります。予測可能なリソース配信を確保するには、関数の最小インスタンス数を設定して事前にリソースを確保してください。詳細については、「最小インスタンス数を指定したエラスティックポリシーの設定」をご参照ください。
GPU イメージのサイズ制限はどのくらいですか？
イメージサイズの制限は、非圧縮イメージではなく、圧縮後のイメージに適用されます。 圧縮後のイメージサイズは、Container Registry コンソールで確認できます。 また、ローカルで docker images コマンドを実行して、非圧縮イメージのサイズを調べることもできます。
通常、圧縮前のサイズが 20 GB 未満のイメージであれば、Function Compute にデプロイして使用できます。
GPU イメージのアクセラレーションが失敗した場合はどうすればよいですか？
イメージサイズが大きくなるほど、アクセラレートされたイメージ変換に必要な時間も長くなります。これにより、タイムアウトが原因で変換が失敗する可能性があります。変換を再トリガーするには、「Function Compute コンソール」で関数構成を編集して保存してください。パラメーターを変更する必要はありません。
モデルはイメージ内にパッケージするべきですか、それとも分離すべきですか？
モデルファイルが大規模である場合、頻繁に更新される場合、またはイメージがプラットフォームのサイズ制限を超える場合は、モデルをイメージから分離してください。モデルをイメージから分離する場合は、NAS または OSS ファイルシステムにモデルを格納します。詳細については、「GPU インスタンスにおけるモデルストレージのベストプラクティス」をご参照ください。
モデルのウォームアップを実行する方法とベストプラクティスを教えてください。
モデルのウォームアップは /initialize メソッド内で実行してください。/initialize メソッドが完了した後でのみ、インスタンスは本番トラフィックの受信を開始します。詳細については、以下のドキュメントをご参照ください。
GPU イメージが起動せず、「FunctionNotStarted: Function Instance health check failed on port xxx in 120 seconds」というエラーが報告された場合はどうすればよいですか？
原因：AI/GPU アプリケーションの起動に時間がかかりすぎ、Function Compute (FC) プラットフォームのヘルスチェックに失敗しています。起動時間が長くなる主な原因は、モデルの読み込みに過剰な時間がかかることで、Web サーバーがタイムアウトしてしまうことです。
解決方法：
アプリケーション起動中にパブリックネットワークから動的にモデルを読み込まないでください。より高速な読み込みを実現するには、モデルをイメージ内または File Storage NAS ファイルシステムに配置してください。
モデルの初期化を
/initializeメソッド内に配置してください。これにより、モデルが読み込まれる前に Web サーバーを起動できます。説明インスタンスライフサイクルの詳細については、「インスタンスライフサイクルの設定」をご参照ください。
関数のエンドツーエンドレイテンシが高く、変動が大きいです。どのように対処すればよいですか？
まず、環境コンテキスト内のイメージアクセラレーションステータスが `Available` であることを確認してください。
NAS ファイルシステムのタイプを確認してください。関数が NAS ファイルシステム（例：モデルの読み取り）からデータを読み取る必要がある場合は、パフォーマンス向上のためにコンピューティング最適化型の汎用型 NAS ファイルシステムを使用してください。ストレージ最適化型ファイルシステムは使用しないでください。詳細については、「汎用型 NAS ファイルシステム」をご参照ください。
NVIDIA ドライバーが見つからない場合はどうすればよいですか？
docker run --gpus all コマンドを使用してコンテナーを指定し、その後 docker commit を使用してアプリケーションイメージをビルドすると、結果として生成されるイメージにはローカルの NVIDIA ドライバー情報が含まれます。これにより、Function Compute にデプロイ後にドライバーが正しくマウントされず、システムが NVIDIA ドライバーを見つけられなくなります。
この問題を解決するには、Dockerfile を使用してアプリケーションイメージをビルドしてください。詳細については、「dockerfile」をご参照ください。
さらに、イメージにドライバー関連コンポーネントを追加したり、アプリケーションを特定のドライバーバージョンに依存させたりしないでください。たとえば、イメージに libcuda.so を含めないでください。この動的ライブラリは CUDA Driver API を提供し、デバイスのカーネルドライバーバージョンと密接に結合されています。イメージ内の動的ライブラリがホストのカーネルドライバーと一致しない場合、互換性の問題によりアプリケーションが異常動作する可能性があります。
関数インスタンスが作成される際、Function Compute プラットフォームはユーザーモードドライバーのコンポーネントをコンテナーに注入します。これらのコンポーネントはプラットフォームが提供するドライバーバージョンと一致します。これは、NVIDIA Container Runtime などの GPU コンテナー仮想化技術でも同様の動作です。この動作により、ドライバー固有のタスクがプラットフォームのリソースプロバイダーにデリゲートされ、GPU コンテナーイメージの環境適応性が最大化されます。Function Compute GPU インスタンスのドライバーは NVIDIA によって提供されます。ドライバーバージョンは、機能の反復、新しいカードモデルの追加、バグ修正、またはドライバーのライフサイクル期限切れなどの理由により変更される可能性があります。
すでに NVIDIA Container Runtime などの GPU コンテナー仮想化技術を使用している場合は、docker commit コマンドを使用してイメージを作成しないでください。このようなイメージには注入されたドライバーのコンポーネントが含まれています。Function Compute プラットフォームでこのようなイメージを使用すると、コンポーネントのバージョン不一致により、アプリケーション例外などの未定義の動作が発生する可能性があります。