CMP 170HXのECCも解除されたそうですが、何が変わるのでしょうか？

長時間計算では、メモリー上の一時的なデータエラーが結果に影響しないようECCが補正に使われます。v0.5でDRAM・SRAM ECCが有効になり、稼働SMも70基から74基に増えました。SM数は並列演算のリソースに関わりますが、この更新だけで特定モデルの速度がどれほど変わるかは測定されていません。

以前のカード案内でECCを利用できないとしていた説明は、v0.5以前の状態を指しています。対応範囲と試験記録は、以下のパッチ記録と導入案内で確認できます。

リポジトリーにはecc-enable.patch、ecc-fbpa-static.patch、ecc-reporting.patchがあります。最初の二つはメモリー制御経路でECC機能を有効にするために使われ、reportingパッチはドライバーがECC状態やエラーカウンターを扱う互換経路を補います。三つのパッチが一緒に公開されていても、機能の変更と表示互換性は分けて理解します。

開発者が公開したドライバー615.71.09での試験では、ECC_CTRLは0x41、メモリーレジスターMR4は0x33、readoutは0x00010233で、nvidia-smiにはECC Enabledと表示されました。この構成では64GBのメモリーも維持されました。この記録はv0.5の動作経路を示しますが、別のドライバー・カード・カーネルの組み合わせで同じ結果になることを保証しません。

ECC reporting互換パッチはEnabled、Supported、scrubComplete、InfoROM 6.16などの状態を合成し、一部のカウンターを0に初期化します。そのため、nvidia-smiのEnabled表示とカウンター0だけでは、エラー発生時に実際に訂正されたか、長時間負荷の後もメモリーが安定しているかは確認できません。パッチのバージョンを記録し、メモリー負荷試験と実作業の結果を併せて確認する理由です。

cmpunlocker v0.5はLinux x86-64でNVIDIA open driver 610.xx.xx以降の系列を必要とします。対応するドライバーライブラリーとファームウェア、稼働中のカーネルに合ったカーネルヘッダーが必要で、Secure Bootは無効にします。初回ビルドにはネットワーク接続も必要です。リポジトリーの現在の対応一覧には615.78.08も含まれるため、任意の最新バージョンではなく、対応と記載されたドライバー系列を基準に選びます。

導入はリポジトリーを取得してsudo ./install.shを実行し、再起動する流れです。標準プロファイルはカード構成を検出します。明示的に選ぶ必要がある場合は、ハードウェアを確認してからsudo ./install.sh --profile=8gbまたはsudo ./install.sh --profile=10gbを使います。8GBプロファイルはデュアルランクカードで64GB、一部のシングルランクカードで32GBを開放でき、10GBプロファイルは40GB構成を対象とします。プロファイルはECCだけでなくメモリー開放構成も選ぶため、カードに合わせる必要があります。

インストーラーはLinuxカーネルモジュールにパッチを適用し、署名されていないモジュールを使う場合があります。カーネル更新後は対応するモジュールの再ビルドが必要になることがあり、カードのファームウェアへ永続的に書き込む変更ではありません。元に戻す場合はリポジトリーの案内に従ってsudo ./remove.sh --yesを実行し、再起動します。GPUを使うLinux PC上で作業し、導入前にOSとドライバーを復旧する手段を用意してください。

再起動後、nvidia-smiでECC Enabledと表示されるか確認し、cmpunlockerとドライバーのバージョンを記録してください。カードが認識され、メモリー容量が選択したプロファイルと合っていることも確認します。

次に、メモリーを多く使う固定入力の処理や正解が分かっている数値計算を実行し、結果とCUDA²・カーネルのエラーログを記録してください。モデルの回答を確認する場合はtemperatureを0にし、同じ質問と設定を使います。長時間処理中のエラーや中断も確認します。

エラーが続く場合は、記録したドライバー・カーネルの組み合わせとログを確認し、パッチを外す必要があればリポジトリーの削除手順に従ってください。実運用で使うモデル・文脈・同時処理を含めて再確認すると、パッチが作業条件に合うか判断しやすくなります。