このトピックでは、GPU インスタンスの使用時に発生する可能性のある一般的な問題とその解決策について説明します。
Function Compute の GPU インスタンスのドライバーと CUDA のバージョンは何ですか？
GPU インスタンスのコンポーネントバージョンは、2つの部分に分かれています：
ドライバーバージョン：これには、カーネルモードドライバーの
nvidia.koと CUDA ユーザーモードドライバーのlibcuda.soが含まれます。Function Compute (FC) の GPU インスタンス用のドライバーは NVIDIA によって提供され、FC プラットフォームによってデプロイされます。GPU インスタンスのドライバーバージョンは、機能の反復、新しいカードモデル、バグ修正、またはドライバーのライフサイクル終了により、将来変更される可能性があります。コンテナイメージにドライバー固有のコンテンツを追加しないでください。詳細については、「NVIDIA ドライバーが見つからない場合はどうすればよいですか？」をご参照ください。CUDA Toolkit バージョン：これには、CUDA Runtime、cuDNN、cuFFT が含まれます。コンテナイメージをビルドする際に、CUDA Toolkit のバージョンを決定します。
GPU ドライバーと CUDA Toolkit は NVIDIA によってリリースされており、特定のバージョン依存関係があります。詳細については、対応するバージョンの CUDA Toolkit リリースノートをご参照ください。
現在、FC の GPU インスタンスはドライバーバージョン 580.95.05 を使用しており、これは CUDA ユーザーモードドライバーバージョン 13.0 に対応しています。最適な互換性を確保するため、CUDA Toolkit はバージョン 11.8 以上を使用してください。CUDA Toolkit のバージョンは、プラットフォームが提供する CUDA ユーザーモードドライバーのバージョンを超えてはなりません。
実行中に 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 に設定することと同じです。詳細については、「仕様」をご参照ください。
プロビジョニング済みの GPU インスタンスがプロビジョニングに失敗したのはなぜですか？
プロビジョニング済みインスタンスが失敗する原因として、以下が考えられます：
プロビジョニング済みインスタンスの起動タイムアウト
エラーコード：「FunctionNotStarted」
エラーメッセージ：「Function instance health check failed on port XXX in 120 seconds」
解決策：アプリケーションの起動ロジックを確認してください。パブリックネットワークからモデルをダウンロードしたり、10 GB を超える大規模言語モデル (LLM) をロードしたりするロジックがないか確認します。まず Web サーバーを起動してから、モデルをロードしてください。
関数またはリージョンのインスタンスクォータに達した
GPU イメージのサイズ制限はどのくらいですか？
イメージサイズの制限は、非圧縮イメージではなく、圧縮イメージに適用されます。圧縮イメージのサイズは、Alibaba Cloud の Container Registry コンソールで確認できます。また、ローカルで docker images コマンドを実行して、非圧縮イメージのサイズをクエリすることもできます。
通常、非圧縮サイズが 20 GB 未満のイメージは、FC にデプロイして正常に使用できます。
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 サーバーを起動できます。説明関数インスタンスのライフサイクルの詳細については、「関数インスタンスのライフサイクル」をご参照ください。
関数のエンドツーエンドのレイテンシーが高く、変動します。これを修正するにはどうすればよいですか？
まず、環境コンテキスト内のイメージアクセラレーションのステータスがアクティブであることを確認します。
ご利用の NAS ファイルシステムの種類を確認してください。関数がモデルなどのデータを NAS ファイルシステムから読み取る必要がある場合は、パフォーマンス向上のため、コンピューティング最適化された汎用型 NAS ファイルシステムを使用してください。ストレージ最適化ファイルシステムは使用しないでください。詳細については、「汎用型 NAS」をご参照ください。
NVIDIA ドライバーが見つからない場合はどうすればよいですか？
docker run --gpus all コマンドでコンテナーを指定し、その後 docker commit を使用してアプリケーションイメージをビルドすると、生成されたイメージにはローカルの NVIDIA ドライバー情報が含まれます。これにより、イメージを FC にデプロイした後にドライバーが正しくマウントされなくなり、結果としてシステムが NVIDIA ドライバーを見つけられなくなります。
この問題を解決するには、Dockerfile を使用してアプリケーションイメージをビルドしてください。詳細については、「dockerfile」をご参照ください。
また、ドライバー関連のコンポーネントをイメージに追加したり、アプリケーションを特定のドライバーバージョンに依存させたりしないでください。たとえば、CUDA Driver API を提供する libcuda.so をイメージに含めないでください。この動的ライブラリは、デバイスのカーネルドライバーのバージョンに強く関連しています。イメージ内のこの種の動的ライブラリとホスト環境との間に不一致があると、互換性の問題によりアプリケーションの異常な動作を引き起こす可能性があります。
関数インスタンスが作成されると、Function Compute プラットフォームはドライバーに関連するユーザーモードコンポーネントをコンテナーに挿入します。これらのコンポーネントは、プラットフォームが提供するドライバーバージョンと一致します。これは、NVIDIA Container Runtime などの GPU コンテナー仮想化技術の動作でもあります。これにより、ドライバー固有のタスクがプラットフォームのリソースプロバイダーにデリゲートされ、GPU コンテナイメージの環境適応性が最大化されます。Function Compute の GPU インスタンス用のドライバーは NVIDIA によって提供されます。GPU インスタンスのドライバーバージョンは、機能の反復、新しいカードモデル、バグ修正、またはドライバーのライフサイクル終了により、将来変更される可能性があります。
すでに NVIDIA Container Runtime などの GPU コンテナー仮想化技術を使用している場合は、docker commit コマンドでイメージを作成しないでください。そのようなイメージには、挿入されたドライバー関連のコンポーネントが含まれてしまいます。このようなイメージを Function Compute プラットフォームで使用すると、プラットフォームのコンポーネントとのバージョン不一致が、アプリケーションの例外など、未定義の動作を引き起こす可能性があります。
GPU インスタンスのオンデマンド呼び出しが失敗し、「ResourceExhausted」または「ResourceThrottled」エラーが返される場合はどうすればよいですか？
GPU リソースは希少であるため、オンデマンド呼び出しはリソースプールの変動の影響を受けます。これにより、リクエストを処理するためのインスタンスが時間内に作成されない場合があります。予測可能なリソース配信のためには、関数のスケーリングルールを設定してリソースを予約してください。プロビジョニング済みインスタンスの課金の詳細については、「課金の概要」をご参照ください。