Framework LaptopのUMA変更でOSが不安定？XServer VPSで256MB〜1GBのOOM隔離を実測

【PR】この記事にはA8.netのアフィリエイト広告を含みます。

先に結論：Framework LaptopのUMA Frame Bufferを変更してOSごと不安定になる問題は、XServer VPSから修復できません。ただし、メモリを大量消費するAI処理をDockerのhard limit内へ移せば、失敗範囲を実験コンテナだけに限定できます。256MiB・512MiB・1GiBの3条件で全コンテナがOOM終了しましたが、公開APIの監視91回はすべて成功し、既存サービスの復旧は不要でした。判定は一部解決です。

2026年9月1日、4GBのXServer VPSで32MiBずつ実メモリを確保する段階負荷を実行しました。終了コード、OOMKilled、cgroupピーク、ホスト空きRAM、公開APIの生存、終了直後の確認時間を記録しています。

Framework LaptopのUMA割当変更でOSが不安定になるのはなぜ？

CPUとiGPUが同じ物理メモリを使うため、GPU向け固定枠を変えるとOS側の利用可能量やGPUドライバの動作条件も変わるからです。大きく固定すればシステムRAMが減り、小さくしすぎれば対象機・ドライバ・ワークロードによってGPU処理が不安定になる可能性があります。

ただし、クラッシュの原因を常にOOMと決めつけることはできません。GPUハング、ハードウェアウォッチドッグ、BIOS、メモリ互換性なども候補です。

ZennのFramework Laptop 13実例では何が起きた？

Zennの「Ryzen AI 9 HX 370でローカルLLMのメモリを取り戻す ― UMA Frame Buffer最小設定でシステムが落ちた話」では、Framework Laptop 13、32GB RAM、Radeon 890M、Fedora、Gemma4 26B QATという構成が紹介されています。

同記事では、0.5GB時に実際のOOM killやamdgpuリセットのログが見つからず、ハードウェアウォッチドッグの記録だけが残ったとしています。今回のDocker OOMとは原因も障害範囲も異なります。

RedditではFramework 13のiGPUメモリ設定に何を悩んでいる？

Redditのr/frameworkには「Setting shared RAM/VRAM in BIOS for 7040U series」という相談があります。Framework 13・Ryzen 7840Uで、BIOSのAutoとGaming以外に大きなiGPU割当を設定したいという内容です。

投稿内では非公式ツールによる変更に触れつつ、投稿者自身もsoft brickの危険を心配しています。AI用途で割当を増やしたい需要があっても、機種・BIOS世代を無視した値変更は安全とは限りません。

[PR]
VPSでいろいろ試すなら『XServer VPS』

Framework CommunityでもUMA増量は求められている？

Framework Communityの「BIOS Feature Request: Add ability to specify UMA size on AMD APUs」では、ROCmやPyTorchなどのML用途向けに大きなUMA bufferを設定したいという要望があります。一方、64MB相当の設定で起動時クラッシュし、自動的に戻ったという報告もあります。

「設定できる」と「安全に常用できる」は別です。一次情報を取るなら、機種名、BIOS版、設定値、OS、ドライバ、モデル、クラッシュ後のログを一緒に残す必要があります。

XServer VPSでFramework LaptopのUMA問題を再現できる？

再現できません。XServer VPSはGPUなしのLinux AMD64環境で、Radeon 890M、UMA Frame Buffer、GTT、Framework BIOSを備えていません。VPSの結果からFramework Laptopに安全な0.5GB・8GB・16GBを決めることもできません。

検証できるのは、危険なAI負荷を自宅PCから切り離し、Linux cgroupのhard limit内で意図的に失敗させる構成です。OS全体ではなくジョブ単位で落とせるかを測ります。

Docker公式はメモリ上限をどう説明している？

Docker公式のResource constraintsは、既定のコンテナにはリソース制限がなく、ホストが許す範囲でメモリを使えると説明しています。Linuxホストが深刻なメモリ不足になると重要プロセスまでOOM対象になり得るため、事前の必要量テストとコンテナのメモリ制限を勧めています。

今回、OOM killerを無効化する--oom-kill-disableは使いません。hard limitへ達した実験ジョブを終了させ、既存サービスを守ることが目的だからです。

実験前のXServer VPS状態

段階負荷はどのように作った？

Python 3.13.15で32MiBのbytearrayを繰り返し生成し、4KiBごとに書き込んで実ページを確保しました。1段階ごとに0.25秒待ち、Docker外からcgroupと公開APIを監視しています。

256MiB上限ではどこでOOMになった？

224MiBの次に32MiBを確保しようとした段階で終了しました。hard limit 256MiBの全量をアプリデータへ使えるわけではありません。

512MiB上限ではどこでOOMになった？

1GiB上限ではホストも危険になった？

1GiB条件でもホストには約2.22GiB availableが残りました。公開サービス用の余白を先に残し、その内側だけを実験へ割り当てた結果です。

3条件を比較するとどうなった？

全条件で実験コンテナだけが終了し、再起動回数は0でした。公開APIの合計91回の監視はすべてHTTP 200です。

OSと公開APIの復旧時間は？

復旧は不要でした。公開APIは一度も異常になっていません。各OOM直後の最初のreadyプローブは256MiB条件31ms、512MiB条件28ms、1GiB条件26msでHTTP 200でした。

これは「31msで障害復旧した」という意味ではありません。障害が実験cgroup内に閉じ、公開APIが継続していたことをOOM直後にも確認できた時間です。

実験中に分かりにくかった点は？

Pythonログは最終のALLOCATED_BYTES行で突然止まり、MemoryErrorやtracebackを出しませんでした。最初はアプリ例外のような説明が得られません。

そこで、終了コード137だけで判断せず、docker inspectのState.OOMKilled=trueを確認しました。Exit 137はSIGKILLを示しますが、OOMか手動停止かを区別するには追加情報が必要です。

初心者が迷いそうなポイントは？

AIスマホ調査システムではどう応用できる？

司令塔のAPIと実験ワーカーを同じ制限へ入れないことが重要です。今回も公開APIは既存コンテナ、負荷処理は使い捨てコンテナへ分けました。

XServer VPSで便利だった点・限界は？

実験後のVPSは正常？

3つの検証コンテナとVPS上の一時スクリプトを削除しました。実験後はRAM 618MB used、3.48GB available、swap 129MB used、ストレージ使用率11%です。

Caddy、FastAPI、PostgreSQLはhealthy、公開readyはdatabase=ok、artifact_storage=okでした。

よくある質問

Framework LaptopのUMAを何GBにすれば安全？

今回のVPS実験からは決められません。機種、RAM容量、BIOS、OS、GPUドライバ、モデルをそろえた実機試験が必要です。

VPSへ移せばFramework LaptopのGPU性能も得られる？

いいえ。今回のXServer VPSはGPUなしです。得られるのは常時稼働、Docker隔離、ログ保存、司令塔機能です。

OOMしたコンテナは自動再起動すべき？

原因が同じなら再びOOMするため、無制限再起動は避けます。入力縮小、上限変更、別ワーカーへの振り分け後に再試行する設計が必要です。

[PR]
VPSでいろいろ試すなら『XServer VPS』

XServer VPSでこの悩みはどこまで解決する？

判定は一部解決です。Framework LaptopのUMA設定やハードウェアウォッチドッグをVPSから直すことはできません。しかし、AI処理を256MiB・512MiB・1GiBのcgroupへ閉じ込めると、全条件で実験コンテナだけがOOM終了し、公開APIは91/91回成功しました。

自宅PCはAndroid実機の操作と画面取得、VPSはジョブ管理・記録・安全なCPU処理を担当させる構成なら、UMA設定を攻めて日常PCごと不安定にする必要を減らせます。将来GPUワーカーを追加するときも、まずモデルごとのメモリ上限と失敗時の証拠をVPSで管理する方針を引き継げます。