FOREDOOM / LAB RECORD 1513
32GB RAMのWindows PCで、58GBのローカルLLMは動くのか。
RAM32GB・VRAM16GBのWindows PCで約58GBのローカルLLMを実行。Strataによる起動成功後に発生したメモリ不足の原因をWindowsのWorking Set調査で絞り込み、File Releaseで改善するまでの過程を記録しました。
Published
StrataとQwen3.8 Coderを検証。メモリ不足の原因を追い、実行環境を改善するまで。
ローカルLLMを使っていると、いずれ気になってくるのが、もっと大きなモデルを動かせないかということです。
これまでforedoomでは、普段使用しているWindows PCで複数のローカルLLMを試してきました。小規模なモデルであれば十分に動作しますが、モデルが大きくなるほど、必要なメモリも増えていきます。
今回挑戦したのは、本体だけで約58GBある大型モデルです。
使用するPCのシステムRAMは32GB。GPUには16GBのVRAMがありますが、それでもモデル本体の容量には届きません。
普通に考えれば、もっと大きなメモリを搭載した機材が必要に思えます。
しかし、SSDとRAM、VRAMを組み合わせてモデルを実行する仕組みを利用すれば、今のPCでも動かせる可能性があります。
そこで、実際に試してみることにしました。
結果から言えば、モデルの起動と回答の生成には成功しています。
ただし、その道のりは簡単ではありませんでした。
最初はメモリ不足で余裕がなく、設定を変更しても途中で停止する状態が続きました。原因を調べていくうちに、Windowsがモデルのデータを物理メモリへ読み込む仕組みに、改善の手掛かりが見つかります。
今回は、2026年11月2日から3日にかけて実施した、大型ローカルLLMの実行検証と、メモリ不足を改善するまでの過程を紹介します。
ENVIRONMENTまずは、今あるPCで試してみる
foredoomでは、将来的なAI基盤の構築に向けて、クラウドAIとローカルAIの使い分けを研究しています。
大きなモデルを利用できる環境にも興味がありますが、最初から高価なAI専用機を購入するつもりはありません。
まずは既存の機材でどこまで実現できるのか。その限界や課題を知ったうえで、必要な設備を考えていく方針です。
今回使用したのは、普段の仕事やゲームにも使っているWindows PCです。
| 項目 | 検証環境 |
|---|---|
| OS | Windows 11 Home |
| CPU | AMD Ryzen 7 9800X3D |
| GPU | Radeon RX 9070 XT 16GB |
| システムRAM | DDR5-5600 32GB |
| SSD | NVMe SSD 2TB |
| Runtime | Strata v0.2.9 |
| Engine | 0.1.55 Windows HIP rx9070 |
実行環境には「Strata」を使用しました。
Strataは、モデルのデータをSSD、RAM、VRAMといった異なる記憶領域から利用し、大型モデルの実行を可能にする仕組みを備えています。
検証対象は、Qwen3.8-Flash-Nextを元にしたCoder派生モデルです。
正式には、ISTA-DASLabが公開する「Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF」のIQ1_M版を使用しています。
これは元の大型モデルからExpertの数を減らし、さらに強く量子化したモデルです。
量子化とは、モデルのデータをより少ない容量で表現するための技術です。容量を抑えられる一方、回答品質への影響が生じる可能性もあります。
そのため、今回の結果を元の通常版モデル全体の評価として扱うことはできません。
まずは、このCoder IQ1_Mを既存PCで実際に動かせるのか。
そこから検証を始めました。
MODEL / SSD
モデル本体 約58.41GB
SSD上のモデルデータから、必要な部分へ段階的にアクセス。
SYSTEM MEMORY
RAM 32GB
アクセスしたファイル由来のページも物理RAMを使用する。
GPU MEMORY
VRAM 16GB
StrataがRAM・VRAMなどの記憶領域を組み合わせて推論する。
容量は搭載容量・ファイル容量です。使用量の内訳図ではなく、モデル全体が32GB RAM内へ常駐したことを意味しません。MTPは無効です。
FIRST RUN58GBのモデルが動いた。しかし余裕はほとんどなかった
今回使用したモデル本体の容量は、正確には58,408,584,928 bytes、約58.41GBです。
関連するMTPデータも取得しましたが、今回の推論ではMTPを無効化しています。
モデルのデータを取得して整合性を確認し、Strataの実行環境を整えたうえで、最初のテストを行いました。
結果は、ひとまず成功でした。
モデルをロードでき、短い質問2問に対してHTTP経由で回答を返しています。
初回のモデルロード時間は約15.1秒。
32GB RAMのWindows PCでも、大型モデルを実際に推論させられることが分かりました。
ただし、喜んでばかりはいられません。
推論中、OSの空きRAMが最小で約0.504GiBまで減少していたのです。
ほとんど余裕がなく、ほかのアプリケーションへの影響も懸念される状態でした。
また、生成された回答にも問題がありました。日本語の説明には英語や中国語が混ざり、PHPの修正問題では不正確なコードが生成されています。
つまり、この段階で確認できたのは、あくまでモデルが動いたという事実だけでした。
起動できること、安定して動かせること、仕事に使える回答を生成できること。この3つは別の問題です。
回答品質の評価は後で行うとして、まずはメモリ不足を改善することにしました。
MEMORY SETTINGS設定を変えても、なぜかメモリが足りなくなる
最初に見直したのは、モデルのデータをメモリへ読み込む方法でした。
通常のResident構成では、実行に必要なモデルデータをメモリに保持します。
一方、mmapという仕組みを利用すると、ファイルの内容をメモリに対応づけ、必要な部分へアクセスできるようになります。
モデル全体を専用のメモリ領域へコピーしなくても済むため、メモリ使用量を抑えられる可能性があります。
ところが、実際に変更してみると、期待した結果にはなりませんでした。
開始時のメモリ使用状況には改善が見られたものの、回答を生成する途中で空きRAMが減少し、安全監視によって処理が停止してしまいます。
会話キャッシュを無効化したり、入力処理に関するPrefillの設定を変更したりしても、状況は大きく変わりませんでした。
| 試した構成 | 空きRAM最小 | 結果 |
|---|---|---|
| 初回Resident | 0.504GiB | 短文2問は完走 |
| mmap Experts | 3.281GiB | 途中停止 |
| mmap＋会話キャッシュOFF | 2.562GiB | 途中停止 |
| mmap＋キャッシュOFF＋Prefill128 | 3.455GiB | 途中停止 |
※それぞれの数値は測定条件や停止時点が異なるため、空きRAMの数値だけで設定間の優劣は判断できません。
専用メモリへのコピーを減らしているのに、なぜ生成中にRAMが不足するのか。
設定変更を繰り返すだけでは、その理由が見えてきません。
そこで、単純な使用メモリ量の比較から、実際に何が物理RAMを消費しているのかを調べる方向へ切り替えました。
WORKING SET原因は、モデルのファイルがRAMに残り続けることだった
今回の検証で大きな転機になったのが、Windowsのメモリ使用状況をファイル単位で調べたことです。
それまでは、OS全体の空きRAMや、推論を実行するプロセスのメモリ使用量を中心に確認していました。
しかし、それだけでは何が原因で増えているのか判断できません。
そこでWindows APIを利用し、「Working Set」を詳しく調査しました。
Working Setとは、簡単に言えば、プログラムが現在物理RAM上に保持しているメモリ領域のことです。
mmapを使ってファイルを読み込む場合、専用メモリへコピーしなくても、アクセスしたファイルの一部は物理RAMに置かれます。
今回の調査では、モデルの実行用データに含まれるexperts.binというファイルが、推論を進める中で大量にRAMへ常駐していることが確認できました。
過去の検証ログには、回答生成中のメモリ使用量について、次の変化が記録されています。
| 観測項目 | 生成中の変化 |
|---|---|
| プロセスRSS | 約3.857GiB増加 |
| Privateメモリ | 約0.009GiB増加 |
| OS空きRAM | 約4.733GiB減少 |
RSSが大きく増えている一方で、プログラム専用のPrivateメモリはほとんど増えていません。
このことから、専用バッファが大きくなっているというより、ファイルに対応づけられたメモリページの常駐が原因ではないかと考えました。
さらに調査を進めた結果、experts.binが主要な増加対象であることを確認できています。
ここでようやく、問題を改善するために調べるべき箇所が明確になりました。
単にRAMを節約する設定を探していた段階から、何がRAMを使っているのかを突き止め、その部分に対処する段階へ進めたのです。
なお、Working Setには共有ページも含まれるため、観測された数値をそのままOS全体の一意なメモリ消費量として扱うことはできません。
それでも、問題の原因を絞り込むうえで、重要な測定結果になりました。
FILE RELEASEFile Releaseによって、メモリに余裕が生まれた
原因を調べる中で、StrataのEngineに、Windowsでファイル由来のメモリページを解放するための機能があることを確認しました。
「File Release」と呼ばれる機能です。
今回の環境では、次の設定によって有効化できます。
STRATA_FILE_RELEASE=1
この機能を有効にすると、不要になったファイル由来のメモリページを解放し、物理RAMの圧迫を抑えられる可能性があります。
実際に設定を変更し、その前後を比較しました。
| 観測項目 | OFF | ON |
|---|---|---|
experts.bin Ready時常駐 | 7.447GiB | 0.018GiB |
experts.bin 最大常駐 | 17.928GiB | 12.831GiB |
| OS空きRAM最小 | 3.492GiB | 8.302GiB |
| 短文テストA | 途中停止 | 完走 |
| 短文テストB | 未実施 | 完走 |
それまでとは、明らかに違う結果が得られました。
experts.binの物理RAMへの常駐量が減り、OSの空きRAMにも余裕が生まれています。
何より、それまで途中停止していた短文テストAが最後まで完了しました。続けて行った短文テストBも完走しています。
もちろん、すべてがFile Releaseだけの効果とは断定できません。
比較時にはGPUへの自動割当やOSキャッシュの状態なども変化しているため、数値差には複数の要因が含まれている可能性があります。
それでも、特定ファイルの常駐量が減少し、それまで停止していた処理が完了するようになったことは、実測によって確認できました。
この段階で、今回の短文テストにおけるメモリ問題は大きく改善しています。
ただし、長時間の連続運用や、さまざまな条件での安定性まで確認できたわけではありません。
今回の結果は、限定された条件での技術的な成功として扱っています。
Ready時 experts.bin 常駐
最大 experts.bin 常駐
OS空きRAM 最小
棒の共通目盛：0〜20GiB。常駐量は小さい方、空きRAMは大きい方が余裕を示します。
短文テストB：OFF 未実施 → ON 完走
GPU自動割当やOSキャッシュ状態などの条件差を含みます。差のすべてをFile Release単独の効果とは断定できません。短文2問の完走であり、長時間安定性は未確認です。
VALIDATION SYSTEMAIに検証を任せるための仕組みにも、改善が必要だった
なお、初回の実行用データ作成では監視が起動せず、安全停止が働かない不備もありました。この工程は安全に成功した検証とは扱わず、その後に監視処理を修正・検証しています。
今回の研究では、Strataの導入から設定確認、実行テスト、ログ解析まで、多くの作業をCodexと連携して進めました。
メモリ不足の原因を絞り込んでいく過程でも、Codexを活用しています。
その一方で、AIの実行を監視する仕組み自体にも問題が発生しました。
例えば、PowerShellのバージョンによる実行環境の違いから、Driverの監視が正常に動作しなかったことがあります。
また、監視データを保存するファイルの更新と読み取りが重なり、アクセスエラーが発生する問題も見つかりました。
こうした不具合も調査・修正し、監視動作や、異常が発生した際の対象を限定した停止処理を確認しています。
大型モデルの検証では、メモリ不足によってPC全体の動作に影響する可能性もあります。
そのため、AIに実行作業を任せる場合でも、処理を監視し、問題が発生したら安全に止められることが重要です。
今回の経験から、AIを使った研究では、モデルの動作だけでなく、検証を進める仕組みそのものの信頼性も確認する必要があると分かりました。
また、Codexを活用できたからといって、それが最も短時間・低コストな進め方だったかどうかは別です。
今回は研究にかかった総工数やクラウドAIの使用量まで測定できていないため、作業時間や費用の削減効果については評価を保留しています。
この点も、今後の研究では確認していきたい部分です。
NEXT STEPS大型モデルを動かせた。その先にある課題
今回、32GB RAMと16GB VRAMを備えた既存のWindows PCで、本体約58.4GBの大型モデルを動作させることができました。
もちろん、58GBのモデル全体を32GBのRAMへ格納できたという意味ではありません。
SSD・RAM・VRAMを組み合わせ、必要なデータへ段階的にアクセスする実行方式によって成立しています。
最初はメモリ不足による停止が続きましたが、WindowsのWorking Setを調査することで原因を絞り込み、File Releaseによる改善も確認できました。
今回の検証で分かったのは、モデルのファイル容量だけでは、実際に動かせるかどうかを判断できないということです。
一方、動作できたからといって、そのモデルが快適に使えるとは限りません。
さらに、実際の仕事を任せられる回答品質があるかどうかは、また別の問題になります。
今回も、メモリ問題を改善した後に、日本語やコード生成の品質を検証しました。
その結果、限定されたPythonの課題では正確なコードを生成できた一方、PHPの修正では不正なコードが残るなど、課題によって結果が大きく分かれています。
そのため、今回のモデルを実務へ採用する判断はしていません。
また、今の段階で新しいAI専用機を購入したり、WindowsのRAMを増設したりすることも決めていません。
将来的には、Windowsのメモリ増設、Macのユニファイドメモリ環境、新しいAI専用機など、複数の選択肢を比較していく予定です。
ただし、機材を高性能にすること自体が目的ではありません。
追加の機材によって何ができるようになるのか。その能力が、実際の仕事でどんな価値を生むのか。
そこを確かめながら、必要な投資を判断していきたいと考えています。
今回の研究は、そのための判断材料を得る一歩にもなりました。
そして、次に考えるべきなのは、大型モデルを動かした後のことです。
実際に動いたAIへ、どこまで仕事を任せられるのか。
次のLABでは、今回のモデルによるPython・PHPのコード生成検証と、実務採用を見送った理由について紹介します。
Experiment Record
| 研究対象 | Strata × Qwen3.8-Flash-Next Coder IQ1_M |
|---|---|
| 実施期間 | 2026年11月2日〜3日 |
| 目的 | 既存のWindows PCで大型ローカルLLMを実行し、メモリ制約と改善方法を検証する |
| 検証環境 |
|
| 対象モデル | ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF / IQ1_M |
| モデル本体容量 | 58,408,584,928 bytes（約58.41GB） |
| Status | COMPLETED |
| 確認できた結果 |
|
| 研究上の判断 |
|
| 継続課題 |
|
Update Log
- 2026年11月2日Strata実行環境の準備、モデル取得・整合性確認、初回推論を実施
- 2026年11月2日〜3日メモリ最適化、監視処理の修正、Working Set調査、File Releaseによる改善を検証
- 2026年11月3日限定条件での技術的成功と、長時間運用・実務採用は保留とする判断を整理