LM Studioで死にかけた話 〜 I/O競合によるシステムクラッシュの診断と解決
3回目の投稿となる今回は、ローカル環境でLLMを使う際によく使われる「LM Studio」で遭遇した深刻なシステムクラッシュ問題と、その根本原因の特定、そして実装した解決策についてお話しします。
TL;DR（結論）
🔴 問題：LM Studioでモデル読み込み時にWindowsがフリーズ
🔍 原因：Cドライブへの過度なI/O集中により、NVMeコントローラが過負荷に
✅ 解決：18.54GBのモデルをEドライブに移動し、シンボリックリンクで透過的にアクセス
📌 初心者向け補足（クリックで展開）
- I/O = ディスクの読み書き処理
- NVMeコントローラ = SSDの司令塔役。処理が多すぎると過負荷になります
事の始まり
ある日の午後、LM Studioでモデルを読み込もうとした時のことです。
13:59:34 - モデル読み込み開始
14:30:25 - システムフリーズ発生
15:06:41 - 予期しないシャットダウンWindowsのあらゆる操作を受け付けなくなりました。マウス、キーボード、さらには運用していたユーティリティ（RunCatなど）すら反応しなくなったのです。
再現条件（ざっくり）
- LM Studioで GGUFモデルを「読み込み」 したタイミング（※筆者環境では 11GB級だけでなく5GB級でもフリーズを確認）
- Cドライブのディスク使用率が張り付き、応答時間が急上昇
ひとまず再起動…？
「こういう場合はとりあえず再起動すれば治る」というのは古い教えですが、操作を受け付けないため電源ボタンの長押しで強制再起動を行いました。
Tips:
- 強制再起動は最後の手段です。通常は「スタート > 電源 > 再起動」で安全に再起動を行います。
しかし、大きな問題が発生しました。
再起動後、画面に映ったのは予期せぬ「BIOS画面」でした。
嫌な予感…。何もしていないのにBIOSに入る。これはOSが起動できていない可能性が高い兆候です。
恐る恐るブートメニューを確認すると、起動ディスク（Cドライブ）が認識されていないことが判明しました。
偶然だと信じて、もう一度再起動…。
幸運にもOSは起動しました。しかし、またLM Studioでモデルを動かそうとすると、同じ問題に直面。今度は再起動しても戻ってきません。
何回再起動しても同じ状態。
まさか、ハードウェア的な故障…？
CMOSクリアの試行
ChatGPTに相談したところ、CMOSクリアを試すことを勧められました。
マザーボード上のCMOSバッテリーを一時的に取り外す（または専用ボタンを押す）ことで、BIOS設定を初期化するという手法です。
💡 初心者向け補足（CMOS）
- CMOS はマザーボードに組み込まれた小さなメモリで、BIOS設定を保存しています。バッテリーを外すと初期化されます。
こんなことで治らないと思いながらも、試してみることにしました。
筆者のマザーボードにはCMOSクリアボタンが搭載されていたため、これを押下。
すると…起動後、BIOSで起動メディアが正常に認識されていることが確認できました。OSも無事起動。
本格的に根本原因を究明する必要がありました。
🔍 根本原因の特定
システム構成の把握
まず、筆者のシステム環境を整理しました：
| ドライブ | 文字 | 種類 | 容量 | 空き | バス |
|---|---|---|---|---|---|
| Lexar SSD NM610PRO 1TB | C | NVMe SSD | 930.58 GB | 652.55 GB | NVMe |
| CT120BX500SSD1 | D | SATA SSD | 111.77 GB | 67.85 GB | SATA |
| INTEL SSDPEKNW512G8 | E | NVMe SSD | 475.33 GB | 99.68 GB | NVMe |
| ROG ESD-S1C | G | USB SSD | 931.26 GB | 391.16 GB | USB |
| BUFFALO External HDD | H | USB HDD | 2794.52 GB | 1335.83 GB | USB |
LM Studioの配置
C:\Users\hogehoge\.lmstudio\
├── models/ (18.54 GB, 11,367ファイル)
│ ├── lmstudio-community/
│ │ └── gpt-oss-20b-MXFP4.gguf (11.28 GB) ⚠️
│ └── elyza/
│ └── Llama-3-ELYZA-JP-8B-q4_k_m.gguf (4.58 GB)
└── その他のデータ大きなモデルファイル（最大11.28GB）がすべてCドライブに保存されていました。
I/O監視による発見
2回目のフリーズ時にタスクマネージャーでシステム監視を実施。モデル読み込み中のCドライブのメトリクスを確認すると：
- 🔴 ディスクI/O使用率: 100%に張り付き状態
- 🔴 応答時間: 50,000ms（50秒）を超える
OSが入っているドライブ（Cドライブ）がボトルネック化していたのです。
💡 技術者向け解説（ディスク応答時間の目安）
- タスクマネージャーの「パフォーマンス > ディスク」で I/O 待機時間（応答時間） を確認できます。
- 目安：10ms 以上 = 要注意 / 50ms 以上 = かなり危険（体感で固まりやすい）
根本原因：I/O競合
🔍 クラッシュに至る流れ
- LM Studio が 11.28GB のモデルを読み込み開始
- Cドライブ (Lexar NVMe) への大量I/O発生
- 同時に Windowsシステム、ページファイル、キャッシュも同じドライブにアクセス（I/O競合！）
- 単一NVMeコントローラの過負荷
- ⚠️ Event ID 129: stornvme "Reset to device" 発生
- ⚠️ Event ID 141: Kernel Watchdog Violation
- ❌ システム応答不能 → フリーズ → 強制再起動
推定原因（観測ベース）: Cドライブへの過度なI/O集中により（ディスク使用率100%張り付き＋応答時間が数万ms）、NVMe側でタイムアウト→リセット（Event 129）が発生していた可能性が高い状況でした。
💡 たとえ話（I/O競合）
- 銀行窓口に 50 人が一気に押し寄せた状態です。
- 受付係（NVMeコントローラ）が処理しきれず、客（I/Oリクエスト）が待ちきれずパニック → 営業停止。
- これを防ぐには、別の支店（別ドライブ）に客を分散させる必要があります。
検出されたシステムエラー
| タイムスタンプ | イベントID | ソース | 内容 |
|---|---|---|---|
| 12/9 15:06:41 | - | EventLog | 予期しないシャットダウン |
| 12/9 15:14:09 | 129 | stornvme | Reset to device (NVMe) |
| 12/9 2:56:27 PM | 219 | Kernel-PnP | WUDFRd driver failed |
| 12/8 21:27:18 | 129 | stornvme | Reset to device (NVMe) |
| 12/8 21:26:57 | 129 | stornvme | Reset to device (NVMe) |
✅ 実施した対応
Step 1: LM Studioモデルの物理移動
まず、大容量モデルをCドライブからEドライブへ移動することにしました。
1. 移動先ディレクトリを作成
New-Item -ItemType Directory -Path "E:\LMStudio" -Force2. robocopyで移動（マルチスレッド対応）
robocopy "C:\Users\hogehoge\.lmstudio\models" "E:\LMStudio\models" /E /MOVE /MT:4 /R:2 /W:5移動結果
- 移動量: 15.86 GB（2ファイル）
- 移動時間: 約4分58秒
- 平均速度: 56.9 MB/s
Step 2: シンボリックリンクの作成
LM Studioは設定ファイル内で固定パスを参照しているため、直接パスを変更するのは避けたい。シンボリックリンクを使用することで、LM Studioは設定変更なしでもEドライブのモデルにアクセス可能になります。
💡 初心者向け補足（シンボリックリンク）
- シンボリックリンク は「ショートカットの高機能版」です。
- LM Studio から見ると「
C:\...\models」に見えますが、実際は「E:\LMStudio\models」を指しています。- メリット: アプリは設定変更不要で、データだけ別の場所に移動できます。
Windowsシンボリックリンク作成（管理者権限が必要）
注意:
mklinkは リンク元のパスが既に存在すると失敗します。robocopy /MOVE後にC:\Users\hogehoge\.lmstudio\modelsが残っている場合は、空であることを確認して削除する（または退避する）必要があります。
mklink /D "C:\Users\hogehoge\.lmstudio\models" "E:\LMStudio\models"実行結果
symbolic link created for C:\Users\hogehoge\.lmstudio\models <<===>> E:\LMStudio\modelsシンボリックリンクの利点
- ✅ LM Studioは設定変更不要
- ✅ 既存のショートカット・パスが機能し続ける
- ✅ Eドライブのモデルに透過的にアクセス
Step 3: 動作確認
シンボリックリンクが正しく機能しているか確認
Get-Item "C:\Users\hogehoge\.lmstudio\models" | Select-Object Name,LinkType,Target実行結果
Name LinkType Target
---- -------- ------
models SymbolicLink {E:\LMStudio\models}📊 対応前後の比較
🔴 対応前
| 項目 | 状態 |
|---|---|
| Cドライブのモデルデータ | 18.54 GB |
| I/O処理の集中 | すべてCドライブ ❌ |
| NVMeコントローラ負荷 | 極度に高い ❌ |
| クラッシュ頻度 | 定期的に発生 ❌ |
🟢 対応後
| 項目 | 状態 |
|---|---|
| Cドライブのモデルデータ | 0 GB ✅ |
| I/O処理 | Cドライブと Eドライブに分散 ✅ |
| NVMeコントローラ負荷 | バランス取れた状態 ✅ |
| クラッシュ | 完全に解決 ✅ |
I/O分散の効果
対応前（単一ドライブへの集中）
🔴 NVMe Controller (Lexar, Cドライブ) の状態
- I/O Queue: 飽和状態 ⚠️
- 📥 モデルロード (11.28 GB, 高頻度)
- 📥 ページファイル (OS, 継続的)
- 📥 システムキャッシュ (OS, 継続的)
- 📥 アプリケーション実行
結果: キューオーバーフロー → タイムアウト → クラッシュ ❌
💡 イメージ（オーバーフロー）
- 1本の川に大量の水が流れ込む → 氾濫（オーバーフロー）
対応後（I/O分散）
🟢 I/O負荷の分散状態
Cドライブ (Lexar NVMe)
- 📥 ページファイル
- 📥 OSキャッシュ
- 📥 アプリ実行
Eドライブ (Intel NVMe)
- 📥 モデルロード
- 📥 モデルアクセス
結果: 各キューに十分な余裕 → 安定動作 ✅
💡 イメージ（分散）
- 1本の川の水を 2 本の川に分散 → 各川に余裕がある（安定）
🎯 今後の予防策
ドライブ管理
- ✅ 大容量のモデルファイルはシステムドライブに保存しない
- ✅ 複数NVMe SSDがあれば、I/O分散させる
- ✅ ページファイルはシステムドライブに設置
定期メンテナンス
（必要に応じて）ディスクチェック（破損ファイルの修復）
chkdsk /F /R⚠️ 補足（chkdskの負荷）
/Rはセクタ検査まで行うため、環境によってはかなり時間がかかります。症状が出ている時、突然のクラッシュ後、エラーが疑われる時などに実施する運用でも十分です。
月1回: Cドライブの空き容量確認（最低30%確保）
Get-Volume3ヶ月1回: BIOS/ファームウェアアップデート確認
- マザーボードメーカーの公式サイトで最新版を確認
💡 詳細解説（メンテ）
chkdsk /F /R= ディスクの物理的な破損をスキャン & 修復（実行時はOSの再起動が必要。寝る前に実行がおすすめ）- 空き容量 30% 確保 = SSDの動作効率を保つため必須（25%以下だと性能急低下）
システム監視
-
📊 イベントビューアで
stornvmeエラーを監視Win + R→eventvwr→ システムログを右クリック → フィルター- “stornvme”, “disk”, “nvme” のエラーを確認
-
📊 Cドライブの使用率を監視（75%以上に注意）
- 75% 以上 = 空き容量不足で性能低下 → すぐ対処
-
🌡️ NVMe温度モニタリング（最大: 90°C）
- 85°C 以上 = サーマルスロットリング発生（処理速度低下）
- 90°C 以上 = 危険領域（放熱改善が必須）
🔬 技術的背景（参考）
NVMeコントローラの特性
| 項目 | Cドライブ (Lexar) | Eドライブ (Intel) |
|---|---|---|
| モデル | SSD NM610PRO 1TB | SSDPEKNW512G8 |
| インターフェース | PCIe Gen 3 | PCIe Gen 3 |
| 最大速度 | ~3,500 MB/s | ~3,500 MB/s |
各NVMeコントローラは物理的に異なるチップセットに接続されているため、I/O処理を分散させることで効率が向上します。
💡 技術者向け補足（QDとタイムアウト）
- PCIe Gen 3 は帯域幅は十分でも、実運用では I/Oキューの深さ（QD） やスケジューリングがボトルネックになり得ます
- 単一コントローラに複数の高速I/Oリクエストが同時到着 → キュー満杯 → タイムアウト
- I/O分散により、各キューの混雑が解消 → タイムアウトを避けやすい
発生していたカーネルエラーの詳細
-
Event 129 (stornvme): NVMe デバイスのリセット
- 原因：NVMeコントローラが I/O タイムアウトを検出
-
Event 141 (Kernel): Watchdog Timeout → ハードウェアが応答しない
- カーネルが I/O 完了を 30 秒以上待機 → 強制リセット
-
Event 144 (USBXHCI): USB XHCIコントローラエラー
- 副次的影響：USB デバイスも応答不能に
📋 結論
問題の本質
Cドライブ（Lexar NVMe）への過度なI/O集中により、NVMeコントローラのタイムアウトが発生。その結果、カーネルがハードウェアリセットを余儀なくされ、システムがクラッシュしていました。
実装した解決策
最大 18.54GBのLM StudioモデルデータをCドライブからEドライブ（Intel NVMe）へ物理移動し、シンボリックリンクで透過的にアクセス可能にしました。
期待される効果
✅ システムフリーズの完全解決
✅ NVMeリセットイベントの消滅
✅ 両NVMe SSDを効率的に活用
✅ システム安定性の大幅向上
まとめ
今回の対応により、CドライブへのI/O集中が緩和され、システムの安定性が大幅に向上しました。
実は筆者は、以前にもSteamVRに起因するもので同様の問題に直面しており、その際もドライブのI/O分散が効果を発揮しました。
📌 この記事から学べることは 3 つ
-
「まずディスク I/O を疑え」
- システムフリーズ → イベントログ確認 → I/O 競合かもしれない
-
「OS ドライブと データドライブは分離しろ」
- 大容量データや高 I/O 処理は Cドライブ以外に配置
- 例：ゲーム、AI モデル、キャッシュディレクトリなど
-
「複数ドライブがあれば I/O 分散は基本中の基本」
- NVMe が複数台あると思った以上に効果がある
- 体感速度も改善される
最後に：
ハードウェアのI/O負荷を分散させることが、システムの安定性を保つ鍵です。
特にI/O書き込みが多いソフトウェア（AI モデル読み込み、エンコーディング、ゲームなど）は Cドライブ以外に置くことを強く推奨します。