生成AIを利用する方へ！PCパーツ換装時のトラブルシューティング！（クローンM.2 SSD＆メモリ増設編）
はじめに
今回お伝えすることは、実際に私が遭遇した事象です。
自身の備忘録も兼ねて、noteに残しておきたいと思います。
（今後、さらに増設とかするかもしれないので…）
PCパーツ換装しようと思った経緯
やはり、生成AIを使用していたり、モデルを製作していたりすると、どうしても抱える問題があります。
それは、AIの処理速度ではありません。
圧倒的なメモリ不足と、モデルデータ等の大容量データによるストレージ圧迫です。
SDXL1.0がStability AI社よりリリース発表され、私も実際にSDXL1.0に触れてみました。
私の環境でも、生成は難なくでき、そこまで重いと感じることはありませんでした。
当時のPCスペックは以下です。
CPU：Intel Core i7 8700K
RAM：DDR4-2666 32GB（X.M.P適用済）
SSD（システムドライブ）：SATA SSD（240GB）
HDD（データ保存）：4台積載（4TBx3枚、3TBx1枚、計15TB）
GPU：GeForce RTX3080Ti（VRAM12GB）
CPUなんてもはや、Intel5世代前（2023年8月現在）の超絶型落ちCPUじゃん！
と感じると思いますが、生成AIでは主にGPUを使うことがほとんどですので、正直そこまで難を感じたことはありませんよ！（意訳：CPUめっちゃ替えたい…）
最近は、生成よりもマージモデル製作をしたり等に重きを置いていたので、
「よし！SDXL1.0モデルでもテストマージしてみよう！」と思いました。
実際にSuper Mergerを試してみると…
圧倒的RAM不足！！
Super MergerのGithubでも、このようにアナウンスされています。
A minimum of 64GB of CPU memory is required for the XL model merge. Even with 64GB of memory, depending on the software you are using in conjunction, there is a risk of system instability. Therefore, please work in a state where it is acceptable for the system to crash. I encountered a blue screen for the first time in a while.
注意！ XLモデルのマージには最低64GBのCPUメモリが必要です。64Gのメモリであっても併用しているソフトによってはシステムが不安定になる恐れがあるのでシステムが落ちてもいい状態で作業して下さい。私は久しぶりにブルースクリーンに遭遇しました。
https://github.com/hako-mikan/sd-webui-supermerger#recent-update
RAM32GBで試した私は、久しぶりにPCの完全フリーズ＋ブラックアウト＋BSOD（Blue Screen of Death）を経験しました。
何故、VRAMではなくRAMなの？と感じると思います。
それは、Super MergerのX/Y/Z出力機能では、モデルキャッシュを頻繁に行うため、RAMアクセスが膨大になります。
これにより、大容量であるSDXL1.0モデルのRAMキャッシュが頻繁に繰り返され、深刻なRAM逼迫を引き起こしていました。
つまりは、SDXL1.0でモデルマージをする場合、最低でもRAM64GBは必要ということです。
そんなこんなしていると、ふと目についたものがありました。
それがこれです。
圧倒的容量不足！！！
システムドライブが何故か逼迫しているじゃないですか…
これも原因があって、WebUI上で様々な機能を使うと、Hugging FaceよりPytorch modelを、.cacheフォルダに自動ダウンロードするためです。
ただ、このフォルダ内を全消去しても、5GB程度しか増えず、容量的には依然ギリギリの状態でした。
圧倒的RAM不足、圧倒的容量不足…
これはもう、増設するしかないと思い準備を進めることにしました。
使用したもの
今回、使用したキット類とPCパーツを紹介します。
クローンキット
M.2 SSD
メモリ
SATA SSD→M.2 SSDクローンで起きた不具合
今回、SATA SSDに入っている全領域をM.2 SSDへ移行する為、クローンキットを使用して環境移行することにしました。
クローン実施
特に問題なく終わりました。
クローンには付属のソフトを使用しました。
クローンソフト毎に違いますし、このクローンツールじゃないと使えないツールなので、使い方について割愛します。
不具合内容
クローン済みM.2 SSDにて、Windowsが認識されず、起動直後に以下BSODが発生する。
INACCESSIBLE BOOT DEVICE
0xc0000001
0xc0000098
不具合発生時の状態
まず、回復コンソールを開いて、ドライブの状況を確認しました。
換装したM.2 SSDのドライブレターが「C:」ではない
Windowsにはディスク構成を確認するツールが備わっています。
以下コマンドで確認ができます。
X:\> diskpart
diskpart> list volume
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ---- ---------- ------- --------- --------
Volume 0 H ESD-USB 4.2 GB 正常
Volume 1 C Local Disk NTFS Partition 3726 GB 正常
Volume 2 D Local Disk NTFS Partition 3725 GB 正常
Volume 3 E Local Disk NTFS Partition 2794 GB 正常
Volume 4 F Local Disk NTFS Partition 3725 GB 正常
Volume 5 G NTFS Partition 464 GB 正常
Volume 6 NTFS Partition 529 MB 正常 非表示
Volume 7 FAT32 Partition 100 MB 正常 非表示
Volume 8 NTFS Partition 668 MB 正常 非表示このコマンドで確かめてみると、Windowsが入っているドライブが「G:」ドライブとして認識されていました。
Windowsブートローダ上では、BCD情報にてDefaultで「C:」が割り当たっているはずなので、G:では読み込まないのも納得です。
読み込めるように、ドライブレターを書き換えてみました。
まずは、現在「C:」に割り当たっているHDDを別のドライブレターに変更します。
X:\> diskpart
diskpart> list volume
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ---- ---------- ------- --------- --------
Volume 0 H ESD-USB 4.2 GB 正常
*Volume 1 C Local Disk NTFS Partition 3726 GB 正常
Volume 2 D Local Disk NTFS Partition 3725 GB 正常
Volume 3 E Local Disk NTFS Partition 2794 GB 正常
Volume 4 F Local Disk NTFS Partition 3725 GB 正常
Volume 5 G NTFS Partition 464 GB 正常
Volume 6 NTFS Partition 529 MB 正常 非表示
Volume 7 FAT32 Partition 100 MB 正常 非表示
Volume 8 NTFS Partition 668 MB 正常 非表示
diskpart> select volume 1
diskpart> assign letter = J続いて、M.2 SSDを「C:」ドライブに変更します。
diskpart> select volume 5
diskpart> assign letter = C
diskpart> list volume
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ---- ---------- ------- --------- --------
Volume 0 H ESD-USB 4.2 GB 正常
Volume 1 J Local Disk NTFS Partition 3726 GB 正常
Volume 2 D Local Disk NTFS Partition 3725 GB 正常
Volume 3 E Local Disk NTFS Partition 2794 GB 正常
Volume 4 F Local Disk NTFS Partition 3725 GB 正常
*Volume 5 C NTFS Partition 464 GB 正常
Volume 6 NTFS Partition 529 MB 正常 非表示
Volume 7 FAT32 Partition 100 MB 正常 非表示
Volume 8 NTFS Partition 668 MB 正常 非表示これで、起動できるか試してみましたが、結果はNGでした。
bootrec /rebuildbcdを実行すると、Windowsとして認識したドライブが「0」と表示される
Windowsにはブート情報を再構築するコマンドが備わっています。
X:\> bootrec /rebuildbcdこれを使い、ブート情報を再構築するよう試みてみましたが、Windowsが見つかりません。
これは、Windowsブートローダが確認できない為、発生しています。
BCDファイルを修正するが、起動しない
Windowsには、BCDファイルを修正するコマンドが備わっています。
X:\> bcdboot C:\Windows /l ja-jpこれでも起動できませんでした。
パーティションタイプはGPT形式の為、BIOS UEFIになっているか確認
パーティションタイプによって、BIOS上で取り扱う方法が少々異なります。
MBR形式は、Legacyモード（非UEFIモード）、GPT形式はUEFIモードで起動する必要があります。
ここに差異があると正しく起動しなくなります。
が、BIOS設定上では、UEFIモードになっていた為、クローンの段階でM.2 SSDはGPT形式で構築されているので、全く問題がありません。
スタートアップ修復が正常に完了しない
ここまで来ると何となく想像つきますが、Windowsスタートアップ修復機能では回復しませんでした。
BCDファイルの再構築
これは最終手段です。
大抵のWindows起動不良は、これを行えば直ります。
ただ、手順が多く面倒なので、あまりお勧めはしませんし、これを実施しましたが起動しませんでした。
念のため、参考サイトを載せておきます。
推察
全て、ブートローダに問題がある旨のブルースクリーンが表示されている。
回復コンソール上でブートローダ系の修復作業をしても、起動しない。
トラブルシューティング実施
もう半ば諦めかけていましたが、一縷の望みが見えました。
ネット上でこのブログ記事を発見しました。
まさに、このエラーが出てたので、早速試してみました。
回復コンソールからスタートアップ設定を開き、再起動してみます。
・・・・・・
なんと立ち上がりました。
今までの苦労はなんだったのか…
そして、参考にしたブログに書かれてある通り、何もせずに再起動を実行。
普段通り立ち上がるようになりました。
ベンチマーク実行
起動したので、ベンチマークを実行してみました。
比較をしてみましょう。
SATA SSD
M.2 SSD
全体的に早くなっていますが、Random Writeがガクっと落ちてますね…
書き込みも体感的にはそこまで遅くないんですが、謎です。
これは追々調べます。
[2023/8/11追記]
原因はパーティションアライメントのズレによるものです。
通常、複数のパーティションを分割する際、分割位置を割り出す為に、パーティションの開始位置オフセットを選定します。
フォーマット既定では最小クラスターサイズ（ディスクの読み書きの最小値の4096Byte）をベースに、パーティション整列します。
これによる整列位置をパーティションアライメントと呼びます。
これがズレることで、正しく読み書きするために、効率的にアクセスできなくなり、パフォーマンス低下を引き起こします。
Windows標準装備のdiskpartでも直せますが、パーティション内が基本的に消去されてしまうので、サードパーティ製のツールなどを使うようにします。
修正後は以下のようになりました。
もう段違いですね！
前と比較しても全く転送速度が違います。
メモリ換装で起きた不具合
今回、DDR4-2666 32GBからDDR4-3200 128GB（32GBx4枚）へ換装しました。
POST良好、BIOSも通常起動し特にメモリ相性による起動失敗はありませんでした。
CPU-Zで確認してみた
しっかりと128GBで認識されています。
何にも問題ないじゃん！って思いましたね…？
この時、実際こんなことが起きていました。
不具合内容
実装RAM：128GB（利用可能64GB）
簡単に言えば、実装RAMの半分しか使用可能じゃない状態です。
普通に使えるので、別に大きな問題ではなかったですが、実際に128GB積載しているのに使えないのは、正直気持ち悪いです。
不具合発生時のメモリ認識状況
BIOS上の認識
物理実装メモリ
DIMM_A1：DDR4-2666 32768MB（32GB）
DIMM_A2：DDR4-2666 32768MB（32GB）
DIMM_B1：DDR4-2666 32768MB（32GB）
DIMM_B2：DDR4-2666 32768MB（32GB）
認識RAM
65536MB（64GB）
X.M.P Profile
DDR4-3200 1.35V
Windows上の認識
物理実装メモリ
DIMM_A1：DDR4-2666 32768MB（32GB）
DIMM_A2：DDR4-2666 32768MB（32GB）
DIMM_B1：DDR4-2666 32768MB（32GB）
DIMM_B2：DDR4-2666 32768MB（32GB）
認識RAM
131072MB（128GB）
使用可能RAM
65536MB（64GB）
ハードウェア予約済みRAM
65536MB（64GB）
推察
POST OK、OS正常起動、BIOS認識できている時点で、メモリ不具合の可能性は低い。
マザーボード上のメモリスロット不良か？
メモリスロットに1枚だけ挿して、起動確認を繰り返し実施。
全スロットで正常起動した為、スロット不良の可能性はない。
メモリの接触不良を疑い、抜き差しや入れ替えを実施したが、変化なし。
X.M.P Profileを正しく割り当ててるのに、DDR4-3200ではなく、DDR4-2666で認識される。
DDR4-2666は換装前のX.M.Pである。
メモリとスロットに不具合がない、X.M.Pが正しく認識されていない
＝BIOS設定情報側の認識不良を起こしている可能性が高い？
トラブルシューティング実施
上記の推察から、BIOSのファームウェアアップデートを行いました。
本来は、リスクが少ないCMOSクリアで行うべきですが、何度もPCを分解するのが嫌ということと、BIOSファームウェアがWindows11用にアップデートされていたので、BIOSのファームウェアアップデートで代用しました。
どちらの方法も共通して、BIOSメモリや設定が初期化されます。
結果
Windows上で、使用可能RAM、メモリクロックが正しい値で認識されていますね！
負荷テストという名のテストマージ
SDXL1.0モデルのマージをテストしてみました。
これは…RAM32GBじゃ足りるわけないですね…
Weight Sum＋Normalで、この使用量なので、SDXL1.0モデルのマージには64GBは絶対に必要です。
おわりに
今回、PCを動かせる状態までは持っていけました！まだ課題は残りますが…
注意点としては、今回と同一のエラーが出たからと言って、私の方法が必ずしも有効打になるわけではありません。
不具合発生の状態なども記載しているので、本当に同一の状態なのかを加味した上で、参考にして頂ければと思います！
いいなと思ったら応援しよう！
