「重い処理はエディタを閉じてから」と言われても、その自動化はエディタの中で動いてるんですが
自動の動画パイプラインで、画像を手元のMacでローカル生成しています。16GBのM4。生成モデルは12Bパラメータ級（FLUX）で、4bitに量子化しても重みが ~7GBほど常駐します。
過去にこれでマシンを凍らせた教訓から、安全装置は入れてあります。開始前に空きメモリ50% を切っていたら生成を始めない（事前ゲート）。生成中に危険水位を割ったら、生成プロセスだけを落とす（watchdog）。 マシンは凍らせない、が最優先。
その安全装置が、見事に2回 仕事をしました。生成を殺して。
殺される。画像が出ない
ゲートは通る（空き51%）。なのに生成を始めた瞬間、空きが51→7% へ滑り落ち、watchdogが「危険」と判断して生成をkill。画像はゼロ。
マシンは無事です。安全装置は完璧に動いている。でも、欲しいもの（画像）が一個も出てこない。守られながら、何も作れない状態でした。
仮説1：「解像度を下げればいいのでは」→ 外れ
まず思いつくのは解像度です。出力を一回り小さくして再挑戦。
…またしても、単調に空きが落ちてkill。
ここで一つ分かりました。犯人は出力の大きさではなく、常駐する重みそのものだと。解像度を変えても、メモリの落ち幅はほとんど同じ。12Bの重みは、絵の大きさと関係なく最初にドンと載るからです。最初の仮説は、気持ちよく外れました。
実メモリを覗く。マシンはそもそも飢えていた
落ち着いて、実際のメモリ内訳を見ます。
PhysMem: 13G used (うち 3.6G は OS が握って離さない領域, 2.9G は既に圧縮済み)
真の空き: 2.7G
swap: 7.8G 使用中平常運転で、もう余裕がない。しかも開発環境そのもの（エディタ＋常駐プロセス）で ~3GB食っている。そこへ7GBの重みを載せようとすれば、そりゃ溢れます。
そして、ここで例の助言が刺さります。「重いステージはエディタを閉じてから」。ごもっとも。でも、この生成を回している自動化は、そのエディタの中で動いているんです。閉じたら自分が死ぬ。完璧な板挟みでした。
転換点は「7GBって下げられないの？」という素朴な問い
ここで方針が変わります。「7GBはFLUXの仕様なのか、それとも工夫の余地があるのか」。
生成ツールのオプションを端から読み直したら、量子化のレベルが3,4,5,6,8bitから選べると分かりました。自分は今4bit。つまり、もう一段 下げる余地がある。追加ダウンロードも要らない、いちばん安い実験です。
（ちなみに最初の検証は、自分がオプション名を取り違えて一回コケました。メモリの問題ですらなく、ただのタイプミス。原因調査の道中で、いちばん時間を溶かすのは大抵こういうやつです）
直して、3bitでエディタを開いたまま生成。…通りました。最低空き19% で完走。初めて、自分の作業環境を閉じずに画像が出た瞬間でした。
勝利のブログを書く前に、A/Bで犯人を確定する
ここで「3bitが銀の弾丸だった！」と書きたくなります。が、待ってください。直前に重いブラウザも閉じていた。効いたのは3bitなのか、メモリを空けたことなのか、切り分けていない。
なので、空きが多い状態で、あえて元の4bitを回してみました。
| 条件 | 開始空き | 生成中の最低空き | 結果 | ピーク消費（概算） |
|---|---|---|---|---|
| 4bit / 余裕なし | 51% | 7% で停止 | kill | ~9GB |
| 4bit / 余裕あり | 71% | 12% | 完走 | ~9.4GB |
| 3bit / 中くらい | 62% | 19% | 完走 | ~6.9GB |
読めてきました。真犯人は「開始時の空き不足」。ブラウザを閉じて開始を51→71% に上げれば、4bitでも通る。つまりメモリを空けたことが最大の効き目。
そのうえで、3bitはピークを実測で ~2.5GB削る（9.4→6.9GB）。必須ではないけれど、最低空きが12→19% に上がり、より少ない余裕でも・より多くのアプリを開いたままでも安全に回る。おまけに、画質の劣化は目視できませんでした。
ついでに気づいたおまけ：事前ゲートの50% は、この構成には少し甘かった。実ピークが ~9.4GBなら、生き残るには開始 ~57% 以上が要る。watchdogが2回 救ったのは、このゲートと実ピークのズレが原因でした。3bitにするとピークが ~6.9GBに下がり、50% ゲートがまた「正直」になる。だから3bitを既定にするのが筋でした。
学び
- 安全に「拒否」する仕組みは、freezeを「計測」に変える。落ちてくれたおかげで、毎回 最低空きを観測できた。固まっていたら何も分からなかった。
- いちばん それっぽい仮説（解像度）を、最初に手早く潰す。外れの確定も前進です。
- 勝利のブログを書く前にA/Bする。直前に変えた要因が複数あるなら、手柄を取り違える。実際、主因は3bitではなく「メモリ解放」でした。
- 見るべきは「モデルがデカいか」ではなく、「ピーク消費vs開始時の空き」のギャップ。両方を測って初めて、詰まりの正体が見える。
ローカル生成が「なぜか動かない/落ちる」とき、サイズに怯える前に、ピークと空きの両方の数字を取ってみてください。犯人は、たいていその差分に隠れています。