この記事は「AIエンジニアの悲劇の罠の記録」シリーズの第6回目です。マシンには 11.8 と 12.x がインストールされ、conda 環境も切り替えられました。 nvcc によって与えられたバージョンはまだ間違っており、トレーニング中にどういうわけかデータベースで見つかりませんでした。この記事では、実際の CUDA ツール チェーンの 2 つのバージョンを使用して、このマシン上で制御された実験を実施し、「誰が有効になるか」という審判ルールを徹底的に説明します。
この記事に含まれる 3 つのシーン繰り返しコマンドは、Z 公式アカウントで入手でき、プライベート メッセージで受け取ることができます。
このピットの典型的なスクリプトは次のとおりです。
マシンには 2 セットの CUDA がインストールされています (1 つは 11.8、もう 1 つは 12.6)。 conda 環境を行ったり来たりして nvcc -V と入力しても、不要な環境が表示されたままになります。拡張機能をコンパイルすると、多数のライブラリが見つからず、インストールした記憶のないパスをエラーが指摘していることが報告されました。
通常、最初の反応はアンインストールして再インストールすることです。ロード後も文字列のままです。
問題は決して「ふりをするかしないか」ではなく、「どちらが先か」です。今日、私はネイティブ実験を使用してこのルールを確立しました。
1. 実験セットアップ: 2 セットの実際の CUDA ツール チェーン
このマシン上に共存する CUDA コンパイル ツール チェーン コンポーネントの 2 セット (1 セット 12.6.85 と 1 セット 12.9.86) を用意し、2 つの独立した環境ディレクトリにインストールしました (pip Wheel によって配布された CUDA ツール チェーン コンポーネント ptxas が使用されました。これは、公式 CUDA インストール パッケージの bin ディレクトリにある ptxas.exe です。バージョンの動作は nvcc の動作とまったく同じであるため、デモにはシステム レベルは必要ありません) installation).
これで、マシン上に 2 セットの CUDA ツール チェーンが同時に存在し、それぞれが独自のディレクトリに存在します。次に変更する必要があるのは 1 つだけで、PATH の順序です。
2 つおよび 3 つのシナリオの実測、同じコマンドに対する 3 つの結果
シナリオ 1、PATH には A (12.6.85) のみがあります。
where.exe は唯一の ptxas バージョン 12.6.85 を見つけました。これが有効になったものです。
シナリオ 2、PATH を B (12.9.86) に変更します。
同じコマンド、同じコードでは、出力バージョンは 12.9.86 になります。プロセス全体を通じて 2 つのツール チェーンのインストール場所は変更せず、PATH のみを変更したことに注意してください。
シナリオ 3、ここが重要なポイントです。 A と B の両方が PATH に存在し、A が 1 位にランクされます。
where.exe は 2 つの ptxas を見つけましたが、どちらも「インストール済み」でした。ただし、ptxas –version を押すと有効になるバージョンは 12.6.85 です。
これが「2台設置しても失敗する」の完全な真実です。両方のセットが存在し、無傷です。誰が最終的なジョブを実行するかは、PATH 内の順序によって決まります。どのアフターマーケットやどのバージョンが新しいかは関係ありません。
3. 仕組み: PATH はキュー、コマンドはテーブル検索
3つのシーンを1枚の写真に凝縮。
PATH は基本的に、セミコロンで区切られたディレクトリのリストです。ターミナルにコマンドを入力すると、Windows はキューの左端から開始して、各ディレクトリ内で同じ名前の実行可能ファイルを検索します。最初のヒットは直接実行され、後続のヒットは考慮されません。。
したがって、「環境の切り替え」アクションが実際に有効になるには、ターゲット環境のディレクトリをキューの先頭に挿入する必要があります。これが conda activate の動作です。現在の環境の bin ディレクトリを先頭に追加します。シェルを変更するだけ、新しいタブを開く、または CUDA をまったく使用せずに環境をアクティブ化するだけの場合、キューの順序は変更されず、元の順序が自然に有効になります。
「インストール済み」と「検証済み」は 2 つの異なるものであり、PATH シーケンスによって区切られています。
4. あなたの気持ちではなく、悪魔の鏡はどこにありますか.exe
この種の問題をトラブルシューティングするための最初のコマンドは、再インストールではなく、where.exe です。
where.exe nvcc をクリックして、PATH 内にあるすべての nvcc をリストし、有効性の優先順位で並べ替えます。最初の nvcc が実際に作業を行うものになります。このコマンドは、「先週 12.1 をインストールしたようだ」と思い出すよりも 100 倍信頼性が高くなります。
ちなみに、PyTorch側の対応するチェックはtorch.version.cudaです（第1回で述べました）。独自のホイール内のランタイムのみを認識し、PATH の影響を受けません。ツールチェーンはPATHを認識し、フレームワークはホイールを認識します。 2 つのロジックを混同しないでください。
5. よくある質問 3
1. 目的のバージョンを「有効な」バージョンに変更するにはどうすればよいですか?
Two roads.一時的な変更では、現在のセッションのターゲット bin ディレクトリを PATH に置きます ($env:Path = “target bin;” + $env:Path、変更後すぐに使用可能になりますが、ウィンドウを閉じると無効になります)。永続的な変更を行うには、システム環境変数パネルでターゲット CUDA のビンを別のビンの前に移動します。 Conda ユーザーは、activate を使用してツールにフロントエンドを管理させることを好みます。
2. conda 環境を使用して CUDA を分離しましたが、それでもブロックされるのはなぜですか?
Check two points.まず、起動している環境がCUDAがインストールされている環境かどうか。 CUDA を使用せずに環境をアクティブ化した後、キューの前に新しいエントリはなくなり、システム レベルのインストールは引き続き有効になります。次に、一部のスクリプトは実行時に PATH 自体を変更し (一部の深層学習フレームワークの起動スクリプトなど)、それによって並べ替えが変更されます。診断方法は変わりません。問題が発生しているセッションで「where.exe nvcc」と入力し、キューの最初の行を確認します。
3. 動的ライブラリもこの一連のルールに従いますか?
ルールは同じですが、審判が異なります。実行可能ファイルは PATH によって決定され、Windows ではダイナミック ライブラリ (DLL) も PATH によって検索されます。したがって、DLL バージョンの競合の古典的な根本原因も、「同じ名前の DLL が複数の PATH ディレクトリに存在し、最初のものが優先される」というものです。 Linux側はLD_LIBRARY_PATHに相当します。ライブラリ名が競合すると「コンパイルはできたが実行時にエラーが報告される」という奇妙な現象が発生しますが、これはおそらくこの方法が原因だと思われます。
6. この記事の概要
- 2 セットの CUDA をインストールしましたが、問題はまだ発生しています。インストールが間違っているのではなく、PATHの並び替えが間違っているのです。キューの左側の最初のヒットが有効になります。
- ここで.exe は魔法の鏡です。 1 つのコマンドで、すべての候補と実際のバリデータがリストされます。
- すべての環境が有効になるかどうかは、先頭に追加されるターゲット ディレクトリによって異なります。これが conda activate の本質的な動作です。
この記事のピットカード
| 分野 | コンテンツ |
|---|---|
| チート名 | CUDA ツール チェーンの複数のセットが共存する場合、PATH の順序によって実際の有効なバージョンが決まります。 |
| 現象テキスト | 環境を切り替えた後、nvcc/ptxas のバージョンは変更されず、コンパイル中にライブラリが見つかりません。 |
| 環境 | Win11、2 セットの CUDA ツール チェーン コンポーネント 12.6.85 と 12.9.86 が共存 |
| 再現手順 | デュアル バージョンを個別にインストール → PATH の前に A を使用して 1 回テスト → B を前に使用して 1 回テスト → PATH の両方 (A を前に) で再度テスト |
| 根本的な原因 | PATH is a queue.インストール順序やバージョンに関係なく、左から右にコマンドの最初のヒットが実行されます。 |
| 解決 | セッション内のターゲット bin にプレフィックスを付けるか、システムの PATH 順序を永続的に調整します。 conda の接頭辞として activate を使用します。 |
| 落とし穴を避けるためのヒント | トラブルシューティングの最初のステップは常に where.exe です。記憶に基づいてどのバージョンが有効であるかを推測しないでください。 |
| ネイティブ認証 | |
| バージョンのタイムスタンプ | 2026-11-05、CUDA ツールチェーン コンポーネント 12.6.85 / 12.9.86 |
| 関連ピット | パート 1 nvidia-smi の CUDA バージョン (環境層と同じ) |
列ナビゲーション
| 章 | テーマ | 州 |
|---|---|---|
| 1 | nvidia-smiで表示されるCUDAのバージョンはインストールしたものですか? | ✅ |
| 2 | torch.cuda.is_available() は常に False で、1 つのコマンドでブレークポイントを見つけます。 | ✅ |
| 3 | ラベルと画像が一致していないため、モデルはノイズを学習し続けます | ✅ |
| 4 | 損失は NaN になり、フックを使用してレイヤーごとに配置します | ✅ |
| 5 | DataLoader が最初のバッチでスタックする、Windows マルチプロセスの落とし穴 | ✅ |
| 6 | CUDAを2セットインストールしたのに接続できない、PATHと優先順位の真実 | |
| 7 | データ漏洩: パーティショニングの前に前処理が行われます | 予定されている |
| 8 | RAG の回答が半分になったらコンパイルを開始し、取得しきい値と拒否メカニズムを実際に操作します。 | 予定されている |
| 9 | ランダムなシードが設定されていますが、結果はまだ再現できません。 | 予定されている |
| 10 | 類似度はすべて 0.9: ベクトルは正規化されていません | 予定されている |
| 11 | 混合精度が有効な場合、NaN が表示されます。 GradScaler は一体何をしているのでしょうか? | 予定されている |
| 12 | 損失は下がらず、むしろ増加します。まずモデルの構造を疑ってはいけません。 | 予定されている |
| 13 | トレーニングは削減されますが、検証は削減されません。最初にデータを確認してから、規則性について話します。 | 予定されている |
次の記事のプレビュー「データ漏洩: パーティション分割の前の前処理」。検証セットのスコアが誤って高い場合、オンラインになるとクラッシュします。次回の記事では、同じデータを使用し、処理順序を 1 つだけ変更して、指標の違いを見ていきます。
著作権に関する声明: この記事の 3 つのシーンの出力はすべて、私の実機から再現されたものです。このコラムの読者は、それらの使い方を学ぶことができます。全文の転売・譲渡を禁止します。
