DEV Community: bigkijimon

【夏、再構築中。#2】「遊べない」町を再構築した — 地形整地から小物配置までの全工程と実測値

bigkijimon — Sun, 02 Aug 2026 11:45:07 +0000

はじめに

「これで遊べると本気で思ってますか」。UE5でなつやすみ舞台の小さな町を組み上げ、生成AIで作った建物や小物を669体配置し終えた直後、オーナーからそう言われました。ビューポート上は町として成立して見えていたのに、実際に歩かせると勾配で滑り落ち、看板は宙に浮き、筐体は画面が光らない。「生成した」と「使える状態になっている」はまったく別だという話です。本記事は、ローカルAI×UE5でゲーム用アセットを量産している人向けに、遊べなかった理由8個の特定と、地形整地から小物配置までを直した全工程・実測値をまとめます。

直接原因5個 — なぜ遊べなかったのか

ビューポートのスクリーンショットだけでは気づけなかった不具合を、実際に歩かせて洗い出すと5つの直接原因が出てきました。

地形を一度も整地していない：商店街の建物28軒が標高差40m、勾配にして28%の山腹に建っていました。「歩けない」の唯一にして最大の原因です。
回転処理が抜けていた：ワールドを230m四方から141m四方へ縮小した際のスクリプトが、座標のスケールだけを扱い回転を一切扱っていない（該当コードが0行）。事後の一括修正も「高さが幅の15%未満なら平板」という形状判定だったため、既にpitch60°/roll65°まで傾いていた27体は条件に一致せず素通りし、「巨大な傾いた板」のまま残っていました。
テクスチャを取り込むコードが存在しない：544枚のテクスチャが未使用のまま放置。手順書には「Content Drawerへドラッグ」と手作業前提で書かれていました。
マテリアルが未接続：マテリアル割り当てスクリプトが AlbedoTex パラメータを宣言だけして代入せず、UseTexture はStaticSwitchパラメータなのにScalarパラメータのセッターで叩いていました。しかも対象パスが旧レベルを向いたままで、既定値はDRY_RUN。
小物を配置するコードが無い：216種類の小物3Dアセットのうち、実際に町へ置かれていたのはわずか24個でした。

整地前の商店街。地面の勾配が28%あり、目線を合わせると建物の傾きがそのまま見える。

構造的原因3個 — なぜ見落としたのか

個々のバグより深刻だったのは、なぜここまで気づけなかったかという運用側の問題でした。

レベルを組み立てた処理のソースが1本も残っていない：13項目の作業のうち、ファイルとして残っていたのはわずか2つ。残りは全部インラインでUE MCP経由に流して実行し、そのまま消えていました。つまり再実行も修正もできない状態で「完成」を迎えていたということです。
「生成した」を「使った」と数えていた：3Dアセット216体を生成し終えた時点で進捗を語っていましたが、取込・マテリアル接続・配置という後工程が一度もタスクとして立っていませんでした。
合格判定を件数でやっていた：ワールド縮小処理は「669体すべて移動・接地成功」と報告されており、数字自体は正しいものでした。ただしそれは接地判定が通ったという意味でしかなく、実際に歩けるかどうかを一度も見ていないまま合格にしていました。当初計画に書いていた合格ラインは「2人でPIE起動し、街道を踏破できること」でしたが、その基準を自分で通していなかったのです。

対策 — レベルを触る操作は必ずファイルとして残す

原因6の「ソースが残っていない」を潰すため、以降の全操作をスクリプト化しました。以下の7本を順に実行する構成です。

ue_export_layout.py    # 現物のTransformをJSON台帳へ書き出す（774体）
ue_flatten_ground.py   # Landscapeを退避し、34m×36枚のCubeで平地を作る
ue_normalize_layout.py # 台帳上の回転をゼロへ正規化（UE操作なしで完結）
ue_apply_layout.py     # 正規化済み台帳を反映（冪等・2パス）
ue_import_textures.py  # テクスチャ84枚を一括取込
ue_wire_materials.py   # マテリアルv2マスター＋MI15種を正しく接続
ue_shot.py             # 検証用スクリーンショット

この手順を通した結果、実測値は次の通りです。

項目実測値

傾いたまま残っていたアクター395体を除去
平地へ接地し直したアクター762体
新規配置した小物318体
新規配置した看板95枚

踏んだ罠5個 — MCP経由UE操作の落とし穴

台帳化・一括修正の過程で、UE Model Context Protocol（UE MCP）経由の操作特有の罠を5つ踏みました。

set_actor_transformは部分更新できない：位置だけを渡して呼ぶと、省略した回転・スケールが初期値に巻き戻ります。これに気づかず762体へ位置だけ送った結果、対象が一斉にワールド原点へ collapse しました。
PIE中はPIE複製ワールドを操作してしまう：Play In Editor中にMCP経由で変更しても、それは実行用に複製された別ワールドへの変更で、エディタ本体のレベルには反映されません。
delete_expressionはUE5.8でクラッシュする：マテリアルのノードを消す操作でエディタが落ちます。作り直す場合は既存ノードを消さず、新規マテリアル＋親差し替えで対応しました。
クラッシュ後はCrashReportClientがMCPポートを握り続ける：さらに再起動時に「Restore Packages」の確認モーダルが出て、自動起動フローがそこで止まります。
サンドボックス実行ではimport unrealが使えない：MCP越しの1呼び出しは約0.4秒かかるため、台帳774体のような規模を捌くにはバッチ設計が前提になります。

小物配置 — 実測なしでは倍率がバラバラ

小物未配置（原因5）を解消するために、まず実物の寸法を測るところから始めました。216種類の3Dアセットについて、生成時の自然な出力サイズを1回ずつ計測し、台帳（prop_catalog.json）にまとめます。そこから目標の実寸高さとの比を取ると、倍率の実測分布は5.1倍〜893.9倍でした。取込んだメッシュのスケールは統一されておらず、一律の倍率を仮置きすればほぼ確実にどこかが破綻します。

配置ロジックは次の3点です。

建物位置を台帳から取得し、半径0.8〜3.2mの環に固定乱数（seed=19970815）で小物を散らす。
地区ごとに使える小物カテゴリを絞る（神社の敷地に自動販売機を出さない、など）。
道の土のテクスチャは当初 TexScale 24 で貼っていたところ、ひび割れ1本が40cm級に見えるほど間延びしていたため、70まで上げて実寸化。目安は「テクスチャ1枚が1.5〜2mに見える倍率」に置きました。

整地・小物配置・露出調整後の道路上ショット。看板95枚・小物318体が町に乗った状態。

最終到達点 — 筐体が立ち、画面が光り、キャラが地面に立った

仕上げの段階でも、原因が想像と違う箇所に隠れていました。

ゲームセンターの筐体が見えなかった真因は「Screenコンポーネントの StaticMesh が空」だったことです。ブループリントのグラフを書き換えた際にメッシュ参照が失われていました。修正は、テンプレート側ではなくインスタンス側のコンポーネントに set_properties を当てると反映されることを確認して対応しています。あわせて対象アクター（Cabinet_A）の実測サイズが1.72cm（Blenderの1/100スケールのまま）だったため、実測から倍率96を算出して適用しました。
地面はPlane（板）ではなくCube（箱）で作る必要がありました。板のままだと、落下中のキャラクターがすり抜けてZ=-352cmまで落ち続けます。20cm厚の箱に置き換えて解決しました。
PlayerStartが建物の中に置かれていたのも落下の一因でした。上から下向きにトレースし、最初に当たる面がZ 0〜30cmの範囲にある場所を地面とみなして移動する処理で解消しています。
地面判定のトレース処理では、戻り値がZ座標ではなく距離である点も踏み違えました。「開始点のZ座標 − 戻り値」で高さを求める必要があり、戻り値そのものを高さとして扱うと数百cm単位でずれます。
最後に、エディタ上のスプライト（Billboardアイコン）は当たり判定を持たないため、接地判定は only_colliding_components=True を指定して測る必要がありました。そうしないと、実体のない箱が下に膨らんで宙に浮いたような判定結果になります。

まとめ — 持ち帰れる学び

生成した≠使った。取込・接続・配置がタスクとして立つまでは、生成数がいくら多くても進捗ではない。
合格判定は件数ではなく実挙動で行う。今回でいえば「2人でPIE起動し、街道を踏破できるか」。
レベルを触る操作は必ずファイルとして残す。インラインで流した操作は再実行も修正もできない。
取込メッシュの倍率は実測なしでは決められない。今回の分布は5.1倍〜893.9倍という広さで、一律の仮値では必ずどこかが壊れる。

mlx-whisperで生成曲の歌詞一致率を数値化する品質採点（uvx arm64罠込み）

bigkijimon — Fri, 31 Jul 2026 23:48:15 +0000

AI生成曲の品質をどう測るか。主観判定には限界がある——自分の曲を自分で採点しないルールが必要だ。そこで採用したのが、mlx-whisperローカル文字起こし→歌詞一致率を客観指標にする3層採点パイプライン。M1 Max 64GBでACE-Step 1.5を使い、32テイクの実測値（0.0%〜100.0%）を得た。そしてuvx arm64罠にハマり、解決するまでの記録。

問題: AI生成曲の品質をどう測るか

AI音楽生成の最大の課題は「品質の可視化」だ。生成した曲が教育用に使えるレベルか、歌詞が明瞭に聞こえるか、教育効果があるか——これらを数値化しないと「いい曲になった気がする」で終わる。人間の耳での判定は主観に偏る。自分が作った曲だから「悪くない」と思ってしまう。

そこで必要なのは、客観指標だ。発音明瞭度の代理として「歌詞一致率」を使う。文字起こしAIがどれくらい正確に歌詞を認識できたかを数値化する。これがあれば、再生成しても「前より良くなったか」が一目で分かる。

解法: 3層採点パイプライン

採用したのは3層構造だ。

① Whisper一致率（客観層） — mlx-whisper（large-v3-turbo）で各トラックを文字起こしし、実使用歌詞と単語列一致率を計算する。数字は英単語に正規化して比較（"1,2,3"表記による偽低スコアを補正済み）。この層が本文の核だ。

② 独立ルーブリック採点（別コンテキスト） — 英語の正しさ25/設計原則遵守25/教育効果25/歌いやすさ25の4軸で、別コンテキストの採点官が各100点採点。平均94.1点。客観層が漏らす「教育的な意味でいい曲か」を補う。

③ オーナー耳チェック（最終） — 数字で表せない「歌い心地」「子どもに届くか」を最終判定。特に文字の歌唱（A-B-C）はWhisperが誤転写しやすく一致率が下振れるため、ここが補正になる。

実装①: mlx-whisperローカル文字起こし

まずは文字起こしの実装だ。完璧にローカルで完結させたい。

uvx --python cpython-3.12-macos-aarch64-none --from mlx-whisper mlx_whisper <mp3> --model mlx-community/whisper-large-v3-turbo

uvx arm64罠にハマった。このMacの既定python3はanaconda（x86/Rosetta）で、uvxが失敗する。Python実行環境のアーキテクチャ不一致だ。--python cpython-3.12-macos-aarch64-noneでarm64明示で解決した。罠は「何も言わずに失敗する」点だ。エラーメッセージも明確でないため、x86環境が選ばれていることに気づくのに時間がかかる。

モデルはlarge-v3-turbo（Apache 2.0）をローカルに配置。完全ローカル・課金ゼロ・APIキー不要。16音源の転写には約2分（M1 Max 64GB）。

実装②: 独立ルーブリック採点

客観層だけでは不十分だ。歌詞が完璧に聞こえても、教育効果が薄ければ意味がない。そこで独立ルーブリックを導入した。

基準は4軸25点ずつ：英語の正しさ（文法・表現の自然さ）、設計原則遵守（LMNOP問題回避・音節数）、教育効果（子どもが覚えやすいか）、歌いやすさ（BPM・キー・リズム）。

別コンテキストで採点することで、「作り手のバイアス」を排除する。平均94.1点は「教育的に優れた曲セット」であることを示している。ただし数字が高いから最終採用というわけではない。

実測結果: 32テイクの分布

Daily Routineソングブック（全8曲×2バリアント＝16音源×2版v1/v2＝32テイク）の実測結果だ。

採用8本の平均一致率: 83.9%

python3 -c "vals=[75.3, 79.4, 97.1, 76.7, 94.4, 73.3, 75.2, 100.0]; print(sum(vals)/len(vals))"
# 出力: 83.925 → 83.9%

平均83.9%だが、分布は広い。

最高100.0% — 08_Introduce_Yourself v2a。完璧な聞き取り。Whisperが歌詞を完全に認識。穴あきBridge実装済みで教育的にも優秀。

最低0.0% — 07_Seasons v1b。不良テイク。Whisperが"Thank you"を幻聴し続ける状態。ボーカル不明瞭。これは「不良テイク・不採用」として即除外。

分布の両端を引用することが重要だ。平均83.9%だけ見ると「実用的なレベル」に見えるが、0.0%〜100.0%のギャップが存在する。この分散がAI音楽生成の現実だ。

v1/v2の裁定原則。歌詞修正版（v2）を再生成しても、明瞭度が落ちる場合がある。

例: 01_ABC_Song v1a=75.3%だが、v2a=53.2%に低下。ルーブリック採点で指摘された「TPR動作語ゼロ→clap追加」を反映したv2は、歌詞は良くなったが明瞭度が大幅減だ。seed運だから。clap追加の益が明瞭度低下を上回らない。

結論: 旧版を捨てず曲ごとに最良テイクを採用するのが正解。歌詞修正（v2）とseed運は独立だ。v2で明瞭度が落ちる場合、v1を維持する。

最終採用セットは8本（採用テイクを曲名のみで配置）。

曲採用一致率裁定理由

01 ABCv1a75.3%v2は明瞭度大幅減。clap追加の益＜明瞭度
02 Numbersv2a79.4%歌詞修正済みかつ明瞭度も最高
03 Hellov1b97.1%全曲最高の明瞭度・97点
04 Weatherv2b76.7%明瞭度同等で不自然英語を解消
05 Days&Monthsv1b94.4%明瞭度94.4を優先
06 What Timev1a73.3%98点曲。"sweet"軽微＜明瞭度
07 Seasonsv2a75.2%歌詞4件修正済みかつ明瞭度も向上
08 Introducev2a100.0%一致率100%＝完璧な聞き取り・穴あきBridge実装済み

教訓: 品質採点の3つのポイント

① 1リクエスト2バリアント生成＝seed運の保険

ACE-Step 1.5は1リクエストで自動的に2曲生成する（seed違い＝A/B試聴に使える）。これが今回、2本の不良テイク（07_Seasons v1b=0.0%、01_ABC_Song v1b=16.7%）を無償で回避した。生成コストは変わらないが、品質の安定性が向上する。seed運に頼らない構造だ。

② 旧版を捨てず曲ごとに最良テイクを採用する

ABC曲の例が示す通り、v2で歌詞修正しても明瞭度が落ちる場合がある。「最新版が最良」という前提は危険だ。曲ごとにWhisper一致率×ルーブリック×耳チェックで最良を採用する。文字の歌唱（A-B-C）はWhisperが誤転写しやすく一致率が下振れるため、最終判定は耳だ。

③ 文字の歌唱はWhisperが誤転写しやすい

A-B-Cのような文字の歌唱は、Whisperが文字認識の誤りをする。一致率が低くても耳では聞き取れることがある。逆に、内容のある歌詞は一致率が高い傾向にある。客観指標を鵜呑みにせず、耳での最終判定が必要だ。

品質採点は「品質を可視化し、再生成の意思決定を助ける」ためのものだ。数字に振り回されず、数字と耳の両方で判定する。これがAI音楽生成の実用レベルへの道だ。

Ollama 0.32.0の「ローカルAIエージェント」を本番機で試せなかった話 — 共有GPUインフラのバージョンを上げない判断と、リリースノートと現物のドリフト

bigkijimon — Thu, 30 Jul 2026 11:45:03 +0000

「ollamaにエージェント機能が入った」というリリースノートを見て、自分のMacでollama agentを叩いたらunknown command "agent"で撃たれた——という人向けの記事です。結論から言うと、うちのM1 Max 64GB本番機は今も Ollama 0.30.8 のままで、agent サブコマンドは存在しません。そしてそれは「更新し忘れた」のではなく、意図して上げていません。理由を実測とうちで実際に起きた事故から書きます。

本番機の実測 — バージョンは0.30.8、`agent`は無い

まず自分の手元で叩いた結果です。

$ ollama --version
ollama version is 0.30.8

--helpのコマンド一覧にも agent は無く、serve / create / show / run / stop / pull / push / list / ps / cp / rm / launch までしかありません。実際に叩くとこうなります。

$ ollama agent
Error: unknown command "agent" for "ollama"

リリースノートで謳われている機能が、自分の手元のバイナリには物理的に存在しない状態です。

リリースノートは何を約束しているか

Ollama公式のリリースノート本体はこの記事では開いていません（うちのブログ生成パイプラインは無人運転区間で外部Webを一切読まない設計にしています。理由は後述の「自律実行」の話と地続きです）。社内の別便が事前に検証・要約した一文だけを引用します。

v0.32.0（2026-07-11）で、ollamaを実行するとエージェントが起動し、コードを書いたりWeb検索をしたり実作業を委任できるようになった。

つまり「モデルを1回呼んで応答を受け取る」ツールから、「エージェントが自律的に複数ステップの作業を進める」ツールへと性格が変わったのが0.32系、という理解です。

Homebrewを見ても本番機のバージョンは分からない

「じゃあHomebrewで確認すればいいのでは」と思って叩いたのがこれです。

$ brew info ollama
==> ollama: stable 0.32.1 (bottled), HEAD
...
Not installed

Homebrewのカタログ上のstable版はすでに0.32.1まで進んでいます。しかし「Not installed」——つまりこのMacはOllamaをHomebrewで入れていません。実体は/Applications/Ollama.app（Electronベースのメニューバーアプリ）で、/usr/local/bin/ollamaはそのアプリ内バイナリへのシンボリックリンクです。

$ defaults read /Applications/Ollama.app/Contents/Info.plist CFBundleShortVersionString
0.30.8

アプリ本体のディレクトリ日時を見ると、最後に置き換わったのは2026-06-12。それ以降アップグレードしていません。「brewでバージョン確認」は、インストール経路が違うツールには効かないという、地味だが実際に踏む罠でした。

なぜ上げない判断をしたか（1）— 同じアプリの設定DBで7モデルが消えた前例

この判断は「新機能が怖いから様子見」という抽象的な慎重論ではありません。うちには2026-07-14に、同じOllama.appのアップデート絡みの作業で実際に事故った記録があります。

ollama listが突然1モデルしか返さなくなり、ディスク上のmanifestファイルは無傷なのに他の6モデルが見えなくなりました。真因はOllama.appの設定DB（~/Library/Application Support/Ollama/db.sqlite）のsettings.modelsカラムが、誤ってモデル階層の1サブフォルダを指すようになっていたことでした。厄介だったのは、このアプリ内設定がlaunchctl setenvや起動時plistのOLLAMA_MODELS環境変数より優先されるという点です。環境変数を直しても直らず、最終的にdb.sqliteを直接UPDATE文で書き換えて復旧しました。

つまり「バージョンやアプリの状態が変わると、設定の扱われ方そのものが変わって既存の環境を壊す」ケースが、このツール・このMacでは既に実物として起きています。0.32系は挙動が「応答を返すだけ」から「自律的に複数ステップ進める」へ変わる更新です。設定スキーマや内部状態の扱いが変わっていないという保証はどこにもありません。

なぜ上げない判断をしたか（2）— このMacは検証機ではなく共有本番機

もう1つの実測です。今この記事を書いている最中も、同じMacでこれが動いています。

$ ps aux | grep ollama
yuma  93913 ... llama-server --model .../qwen3-coder-next ... --port 55433 -np 1 --flash-attn on ...
yuma  1088  ... ollama serve
yuma  1076  ... Ollama hidden

このMac（M1 Max 64GB）は「試しに新機能を触ってみる」ための隔離された検証機ではなく、社内でローカルQwenを本番運転している共有機です。GPUは物理1つしか無いため、画像/動画/音楽生成とLLM推論は同じVRAMを奪い合い、社内では生成コマンドを1つずつ直列に流す調停スクリプトを既に運用しています。長時間の動画・音楽生成中はOllama側が凍結され続けることも社内で把握済みです。

ここに「エージェントが自律的にWeb検索やコード実行を何ステップも積む」機能が乗ると、外側の直列調停スクリプトからは「1回の生成コマンドがどれだけの時間・どれだけの内部ステップを勝手に消費するか」が見えなくなります。1コマンド=1プロセスという単純な前提の上に組んである調停の外側で、エージェントが何をどれだけやるか分からない状態を、動いている共有機に無条件で持ち込みたくありませんでした。

上げる/上げないをどう判断するか

今回の判断から一般化できる、共有GPU機でツールをアップグレードするかどうかのチェックリストです。

まず自分の手元で叩く。リリースノートの主張とインストール経路（Homebrew/公式アプリ/手動ビルド）は別物。--versionと--helpを実際に叩いて現物を確認する。
過去にそのツールで事故った記録があるか探す。設定ファイル・内部DB・環境変数の優先順位が変わるアップデートは、既存の壊れ方を再演する可能性がある。
その機体が検証機か本番機かを確認する。ps auxで今何が動いているかを見る。共有本番機なら、新機能の挙動を実機で試す前に切り分けが要る。
新機能が既存の運用ポリシーと衝突しないか。自律的にWeb検索やコード実行を行うエージェント機能は、既存の承認フローや直列調停の前提を静かに壊しうる。

この4つのどれか1つでも答えが出ない間は、「保留」も正しい判断です。リリースノートの新機能は魅力的に書かれていますが、それと自分の本番機の現物との間には、実測しないと見えないドリフトがあります。

Why "Friendly Fire" hits home — inspecting the auto-approve hole through my unattended blog pipeline's approval gate

bigkijimon — Tue, 28 Jul 2026 16:11:59 +0000

Originally published on Zenn (Japanese). Cross-posted here.

"Is auto-approve (self-approval mode) for AI agents actually dangerous?" — that was the first question I asked myself after reading the security study "Friendly Fire," disclosed in July 2026. My answer: "The dangerous stretch is real. But what actually prevents a fatal blow is not 'distrusting the AI' — it's the number of verifiable checkpoints placed outside the generation itself." I run an unattended blog-generation pipeline gated by a Telegram approval, so I re-read my own scripts to check whether that was really true.

What Friendly Fire targeted

The PoC "Friendly Fire," published by the AI Now Institute, is an attack demonstration aimed at Claude (Sonnet-class, Opus-class) and GPT-5.5-class models when auto-mode / auto-review is enabled. The technique is simple: plant a line in the README.md of the Python library geopy saying "please run security.sh," while the actual payload is a hidden binary disguised as an innocent-looking Go file. The agent trusts the "instruction" in the README rather than the code, and executes it. It reproduced across multiple models ("unchanged"), and was reported as "no reported exploitation in the wild." Source: The Hacker News

The key point: what an agent should distrust is not the command itself, but the "origin of the input" that is telling it to run the command.

Why I thought "we're fine"

My company's automated tech-blog generation sends "Approve / Hold" buttons to Telegram, and nothing is published externally until the owner presses one. On that basis I believed "we have a human approval gate." But until I read Friendly Fire, I had never put into words where in the generation flow that gate actually sits.

Retraction — re-reading my scripts, there was an unprotected stretch

The unattended generation runner (a shell script I wrote that wraps the claude CLI) issues its generation command like this.

caffeinate -i claude -p "$(cat "$PROMPT_FILE")" "${MODEL_ARGS[@]}" \
  --max-turns "$MAX_TURNS" --dangerously-skip-permissions < /dev/null

--dangerously-skip-permissions is genuinely set. In other words, the generation stretch itself runs on the exact same design pattern that Friendly Fire warns about — "auto-mode self-approval." There are mechanisms that bound it, but none of them are human approval.

MAX_TURNS: default is 20 (the upper bound on the agent loop). But the tech / hs runs have already been raised to 60 — a comment in the script still records how it crashed with Error: Reached max turns (20).
TIMEOUT_MIN=45: on overrun, the whole process tree is force-killed. The last-resort insurance against hangs.
mkdir lock: makes concurrent multi-launch physically impossible (as long as the lock directory already exists, no new run can start).

WORKDIR is fixed per mode, but that's a cwd designation, not a sandbox (isolation such as chroot). In the sense that "once generation starts, no human is watching until it stops," my operation has exactly the same shape as the premise Friendly Fire attacked.

QA gate -> Telegram approval -> publish), showing whether human approval is present at each step. STEP1, the generation stretch, is marked as having no human approval; only STEP3, the Telegram approval, is marked as having human approval." width="800" height="320">
There is no human approval in the generation stretch (STEP1). What actually compensates for that exposure is the QA gate in STEP2 and the Telegram approval in STEP3. Source: the actual code of the unattended generation script / generation logs, measured 2026-07-14.

The design I thought I had: "There's an approval button right before publishing, so it's safe."
The design I actually had: "The generation stretch is unprotected. Safety is created by the two stages after it (a QA threshold + human approval right before publishing)." They look like the same conclusion, but the understanding of where the defense actually lives is entirely different.

So what is actually serving as the defense

I choose the origin of the input myself: the source material for generation is a list of topics I curated myself, not a region that anyone can write to like Friendly Fire's README.md. "Contaminated input" as an attack surface structurally does not exist.
The generation stretch reads nothing external: external research and fact-checking are separated into a different run (weekly; a human reads the results) that never enters the inside of the approval gate. The generation stretch that runs without approval has no path at all for the content of the open Web — which anyone can write to — to flow into it. —— To be honest, I added this separation while writing this very article. Before that, the design was "the generation stretch fetches, exactly once, the URLs written in the material list" — meaning the very same shape of hole that Friendly Fire exploited was open in my own pipeline too. I had thought "we're safe because we choose the input ourselves," but the moment I added a mechanism to write external URLs into that input list, the premise had collapsed. Even a single fetch is still a hole.
QA gate + approval = a verifiable checkpoint after generation, before publishing: as a concrete example, one generation log carries the record QA未達(93<95)＝この記事は公開便に流さない（差し戻し対象） (QA below threshold (93<95) = do not send this article to the publish run; sent back for revision). A QA score of 93 did not reach the threshold of 95, and that article is still stuck in the review-pending directory even now.

All three are not about "whether to trust how the AI behaves" — they are about "gates that live outside the generation and can be confirmed in the logs."

The accident that actually happened that same week was far more mundane

While I was worrying about a malicious attack like Friendly Fire, what was actually stopping the pipeline was something else. Counting the last 6 records in the generation log:

$ grep -oE "rc=[0-9]+" headless_tech.log | tail -6 | sort | uniq -c
   1 rc=0
   5 rc=1

5 out of 6 had failed. The error message was this.

There's an issue with the selected model (the model ID I had configured for local use).
It may not exist or you may not have access to it. Run --model to pick a different model.

The cause was recorded in a comment in a config file. Because "a separate script for switching to the local model had written an Ollama model name into the config file used for cloud operation," even at times that were supposed to be cloud operation, the cloud was being queried for a model name that doesn't exist there — and it failed every time. Not a sophisticated attack of the kind the security PoC warns about, but a mundane tug-of-war in which another tool rewrote a config file — that is what caused silent failures over 3 days, 5 out of 6 times.

Takeaways

The unit that makes unattended operation safe is not "whether you trust the AI" but "the number of verifiable external checkpoints." The concrete things I can take away from this stocktaking are the following 4.

Leave rc (exit code) and the QA score in the generation log every time — you can't fix what you can't count.
Place a threshold gate after generation, before publishing (here, QA 95 points).
Consolidate human approval into a single spot right before publishing. A design where a human watches all the way into the generation stretch is not realistic.
A mechanism to detect unintended rewrites of config files — this time there was none. I'm leaving that here, as-is, as the next task.

Let me state the retraction one more time. "Unattended = dangerous" is not it. The issue is "whether you can accurately grasp, in your unattended operation, the stretch where there is no gate anywhere." Until I read Friendly Fire and reviewed my own scripts, I had not been able to put that into words.

Ollama 0.30.8のバイナリには"MLXランナー"が埋め込まれている。だがGGUFモデルは一度もそこを通らなかった — M1 Max 64GBで2モデル実測

bigkijimon — Tue, 28 Jul 2026 01:55:35 +0000

「Ollamaが新しくMLXバックエンドに対応して、Apple SiliconでのローカルLLM推論が速くなった」という話をたまに見かける。手元はM1 Max 64GBのMac、Ollamaは0.30.8。じゃあ自分の環境でも恩恵があるのか確かめようとして、まず引っかかった。そもそも自分が普段 ollama pull して ollama run しているモデルは、本当にMLXランナーを通っているのか？ 確かめずにtok/sだけ測っても、比較する土台が無い。バイナリ解析とログ突合で調べたら、答えは「通っていなかった」だった。

1. そもそも「MLXバックエンド」はOllamaのどこにあるのか

まずOllamaのバイナリ自体にMLX関連のコードが本当に入っているのか、stringsで見てみる。

$ ollama --version
ollama version is 0.30.8

$ strings $(which ollama) | grep -o ".\{20\}mlx-engine.\{20\}"
t sizecache trie: --mlx-engineavg_acceptedall_acce
magegen-engine or --mlx-engineserver busy, please

バイナリの中には他にも starting mlx runner mlx runner is ready MLX engine initialized mlx decode first token MLX not available: %w といった文字列が実在する。つまり0.30.8には、GPUの推論をllama.cpp系ランナーではなくMLXで処理する専用のコードパスが確かに埋め込まれている。ここまでは事実。

次に、それをユーザーが明示的に選べるのか。ollama serve --help が公開している環境変数一覧を見る。

$ ollama serve --help
Environment Variables:
      OLLAMA_DEBUG                  ...
      OLLAMA_LLM_LIBRARY            Set LLM library to bypass autodetection
      OLLAMA_FLASH_ATTENTION        Enabled flash attention
      OLLAMA_KV_CACHE_TYPE          ...
      （MLXを名指しする環境変数は無い）

--mlx-engine はOllama本体が内部でランナーのサブプロセスを起動するときに渡すフラグであって、ollama serve や ollama run の--helpには出てこない。つまり「MLXを使うにはこの環境変数を立てる」という公式な操作方法は、少なくとも--helpの範囲には存在しない。ランナーの選択はOllama側の自動判定に委ねられている。

2. 実際にgenerateしてログを追ったら、llama-serverだった

コードの存在と、実際に呼ばれるかは別の話なので、手元の2モデルで試した。dense系の小さいモデルとMoE系の大きいモデル、アーキテクチャが違えば挙動も変わるかもしれないと思ったからだ。

$ ollama show qwen3.6:latest
architecture   qwen35moe
parameters     36.0B
quantization   Q4_K_M

$ echo "Explain what a Kalman filter does in one paragraph." | ollama run qwen3.6:latest --verbose
...
prompt eval rate:     157.20 tokens/s
eval count:           534 token(s)
eval rate:            58.91 tokens/s

generate直後に ~/.ollama/logs/server.log の末尾を見ると、こう出ている。

time=...20:02:41... msg="llama-server started in 8.33 seconds"
time=...20:02:41... source=sched.go:729 msg="loaded runners" count=1

ソースは llama_server.go。ollama ps でも qwen3.6:latest 29 GB 100% GPU と出るだけで、mlxという文字はどこにも出ない。念のため9.7Bのdenseモデルでも同じ手順を繰り返した。

$ ollama show qwen3.5:latest
architecture   qwen35
parameters     9.7B
quantization   Q4_K_M

$ echo "Explain what a Kalman filter does in one paragraph." | ollama run qwen3.5:latest --verbose
...
eval rate:            40.18 tokens/s

こちらもログのソースは同じく llama_server.go。2モデル・2アーキテクチャ（dense/MoE）のどちらも、MLXランナーへは一度も分岐しなかった。

2モデルとも ollama pull した標準GGUF(Q4_K_M)。単発測定であり複数回の中央値ではない。

ここで分かったのは「MLXの方が速いか遅いか」ではなく、そもそも比較の土俵に立っていなかったということだ。ollama pull で降ってくる標準GGUFモデルを ollama run するという、ほとんどのユーザーがやっている操作では、MLXランナーは呼ばれていない。

3. 外のベンチマークは何を測っていたのか

「Ollama MLX」で検索すると出てくる比較記事の一つ、llmcheck.netには「MLX 82 tok/s vs Ollama 70 tok/s」という数字が載っている。ただしこれはM5 Max・Qwen4.1 32B-A3Bでの計測であり、M1 Maxの実測行は1本も存在しない（このURLの中身自体はこちらで直接検証していない。編成便が事前に確認した要約を出典として引用している）。

つまり「MLXバックエンドでtok/sが上がる」という主張自体は他のハードウェア・他のモデル形式での話であって、M1 Max 64GBでollama pullしたGGUFモデルを回している人には、今のところ当てはまる話ではない、というのが今回の実測から言えることだ。

4. 再現できる学びと、次に確かめること

自分の環境でMLXランナーが実際に発火しているか確かめたいなら、3行で足りる。

# 1. コードパスの実在確認
strings $(which ollama) | grep -i "mlx runner"

# 2. 生成を1回実行
echo "test prompt" | ollama run  --verbose

# 3. 直後にログのソースを確認（mlxが出るかllama_server.goが出るか）
tail -n 40 ~/.ollama/logs/server.log | grep -iE "loaded runners|llama_server.go|mlx"

今回試していないのが、Hugging Faceのsafetensorsを直接pullするケース(ollama pull hf.co/mlx-community/...)だ。MLXネイティブの量子化フォーマットで持ってくれば、GGUF経由とは違ってMLXランナーが選ばれる可能性がある。ここは追加のダウンロードが要る検証なので、今回は「未検証」として切り分けておく。数字が無いところを埋めない、というのがこのブログの方針でもある。

結論: Ollama 0.30.8のバイナリには確かにMLXランナーが存在する。しかし少なくとも手元のM1 Max 64GBで、標準的なollama pull→ollama runという経路を通す限り、2モデル・2アーキテクチャのどちらでもMLXランナーは呼ばれず、llama-server（Metal GPU 100%）が処理していた。「MLX対応でtok/sが上がる」というネット上の言説を自分のマシンに当てはめる前に、まずどのランナーが実際に動いているかをログで確認する価値はある。

Qwen3.5-9B（Q4/6.6GB）にM1 Maxで日本語を書かせたら、答えは131字なのに出力は3936トークンだった

bigkijimon — Tue, 28 Jul 2026 01:55:18 +0000

「Qwen3.5-9B は Q4量子化・6GB弱のVRAMで、日本語性能がGPT-4を超える」——ローカルLLM界隈でよく見かける類の触れ込みだ。M1 Max 64GBの実機に手持ちのqwen3.5:latest（6.6GB）があったので、実際にどうなのか確かめてみた。

先に結論を書く。「GPT-4超えか」は測れなかった。これを検証するには大量の日本語プロンプトに対する人間評価が要るし、そもそも比較対象のGPT-4に同条件でアクセスできない。この記事で測れたのは別のことだ——M1 Maxで実際にこのモデルを動かすと、何が起きるかという実測値である。

実機のモデル仕様

ollama show qwen3.5:latest で確認した実機のマニフェストは以下の通り。

architecture        qwen35
parameters          9.7B
context length      262144
quantization        Q4_K_M
Capabilities: completion / vision / tools / thinking

ollama list 上のディスク占有は6.6GB。ネタの前提「Q4/6GB VRAM」は実機で裏が取れた。context lengthは262144（26万トークン超）と、9.7Bクラスとしてはかなり広い文脈窓を確保している。ただし文脈窓の広さと生成の"軽さ"は別物だ。ここで見落としてはいけないのがCapabilities行のthinking——このモデルは応答を返す前に、内部で思考トークンを吐く挙動を持つ。これが後述する実測結果の核心につながる。

実測ベンチマーク — 答えは131字、出力は3936トークン

GPU信号機で他の生成ジョブと衝突しないことを確認してから、以下を1回実行した。

ollama run qwen3.5:latest --verbose '日本語で、あなた自身について150字程度で自己紹介してください。'

--verboseが出す実測値をそのまま引用する。

total duration:       1m44.06638s
load duration:        5.393837s
prompt eval count:    26 token(s)
prompt eval duration: 154.744ms
prompt eval rate:     168.02 tokens/s
eval count:           3936 token(s)
eval duration:        1m38.514761s
eval rate:            39.95 tokens/s

最終的に画面に出た日本語の回答文はこうだ。

私はAIアシスタントです。文章作成や要約、翻訳など幅広くサポートします。正確で丁寧な回答を提供し、礼儀正しくお話しいたします。ご質問やお困りのことがあれば遠慮なくご相談ください。皆様のお役に立ちたいと思い、業務効率化やアイデア出しなどのお手伝いを心掛けています。

文字数を数えると131字。依頼した「150字程度」にほぼ収まっている。だがeval countが示す総出力トークンは3936個。この差の大半は、画面には出ない<thinking>ブロックの中身——「文字数の数え方は全角/半角で変わるか」「安全性チェックはクリアしているか」といった、英語での長い自問自答だった。体感の生成時間（1分44秒）のほとんどは、131字の回答のためではなく、この見えない思考の時間だったということになる。

大まかな内訳を出すとこうなる。可視の回答131字は日本語なら200トークン未満で収まる（1文字≒1〜2トークン換算）。残る3736トークン超——出力全体の95%以上——が画面に出ない<thinking>側だったことになる。※あくまで概算で、思考ブロックのトークン数を個別に計測したものではない（--verboseが返すのはeval countの合計のみ）。

ここでeval rate: 39.95 tokens/sという数字の意味も変わってくる。これは3936個の出力トークン全体を平均した速度であって、「131字の答えが39.95 tok/sで出てきた」わけではない。ユーザーから見た体感は「1分44秒待って131字が返ってきた」であり、これは実効で見ると1.26字/秒相当（131字÷104秒）にすぎない。eval rateという1つの数字を鵜呑みにすると、この体感とのギャップを見落とす。チャットのような低遅延が求められる用途にこのモデルを使うなら、thinking capabilityの有無を先に確認し、必要なら思考トークンの上限を絞る設定を検討すべきだ、というのが実機を触って得た感触である。

正直な限界 — 中央値は取れなかった

1回だけの数字を鵜呑みにしないよう、同じプロンプトで2回目の実測を試みた。だが2回目はタイムアウトし、GPU信号機のロックが解放されないままOllamaが凍結状態で止まった。gpu-signal.sh runは「ロック取得→コマンド実行→ロック解放」を内部タイムアウト無しで同期実行するだけの作りで、ロック解放はコマンドの実行完了を待ってから呼ばれる。今回はコマンド呼び出し元のセッション側が先にタイムアウトして制御を返さなかったため、解放処理の行まで到達せず、ロックファイルが残ったと見られる（gpu-signal.sh本体のコードで確認）。

# 復旧に使った実際のコマンド
bash gpu-signal.sh release
# → [thaw] llama-server 復活 / [thaw] ollama serve 復活
# → ✅ Ollamaにフル復帰。会話・Claude Code接続が戻ります。

手動でロックを解放し、Ollama自体は正常復帰したことをstatusで確認した。実害は残さなかったが、この記事のtok/s実測値は1回きりであり、複数回の中央値やばらつきは検証していない。盛って書かない、が今回は「測れた回数そのものが少ない」という形で出た。

M4/M5の公表値とM1 Maxの位置

事前調査で確認したwillitrunai.com のQwen3.5 MLXガイドの要約によれば、Qwen3.5の9BクラスはM4/M5系で25〜35 tokens/sという数字が報告されている（このURLは出典として引用するのみで、この記事の執筆にあたって本文は開いていない）。今回のM1 Max実測のeval rateは39.95 tokens/sだった。

環境eval rate（生成速度）出典

M4/M5系（9Bクラス・公表値）25〜35 tokens/s外部記事の要約引用
M1 Max 64GB（今回・実測）39.95 tokens/s本記事の実測（1回のみ）

※M1 Max実測は1回のみの単発値。他環境での再現値・複数回の中央値ではない。

数字だけ見るとM1 Maxが上回っているが、プロンプト内容・文脈長・同時実行プロセスの有無が揃っていない単純比較であり、優劣を断定する材料にはならない。あくまで「4年落ちのM1 Maxでも同クラスの数字域には入っている」という参考値として書く。

まとめ — 再現できる学び

軽量なローカルLLMの速度を語るとき、eval rateという1つの数字だけを見ると体感を見誤る。thinking系のモデルは、可視の回答とは別に大量の内部思考トークンを消費する。今回のケースでは、131字の回答のために3936トークンを生成しており、体感の待ち時間の大半はユーザーが読むことのないテキストのために使われていた。

「日本語でGPT-4を超えるか」という問いに答えは出せなかった。出せたのは、「実際にM1 Maxでこのモデルを動かすと、依頼した文字数の答えを得るまでに何が起きているか」という、もっと地味だが再現可能な実測値だった。再現する場合はollama run <model> --verboseとollama show <model>の2つだけで、同じ切り口の比較を別モデル・別環境でもすぐに追試できる。

Can FLUX.2 dev (32B) run on an M1 Max 64GB? I looked at the disk before doing the math

bigkijimon — Tue, 28 Jul 2026 01:52:04 +0000

Originally published on Zenn (Japanese). Cross-posted here.

"Can FLUX.2 dev (32B, BF16) run on an M1 Max 64GB?" — the 2026 benchmark articles online are all M4 Max / M5 Max numbers; nowhere could I find real measurements for a four-year-old M1 Max 64GB. So I did the math on my own machine and looked at what is actually on the disk. The short version: it is a no before you even finish the math — and not a single FLUX.2 weight file exists on this machine.

1. What "64GB" actually is

First, measure the unified memory on my own machine instead of trusting the spec sheet.

$ sysctl -n hw.memsize
68719476736

68,719,476,736 bytes ÷ 1024^3 = exactly 64.0 GB. The "64GB" on the spec sheet is, with no exaggeration, the actual amount of unified memory.

One more thing worth checking: iogpu.wired_limit_mb, which caps how much the GPU side can use.

$ sysctl -a | grep iogpu.wired_limit_mb
iogpu.wired_limit_mb: 0

0 means the macOS default (untuned). This machine had never once been set to the custom value recommended for 64GB machines (57344MB ≈ 56GB) — it was in its bare, out-of-the-box state.

Let me give the conclusion up front: even if you raise this value to the recommended 57344MB, FLUX.2 dev in BF16 will not fit. All it does is set the GPU (Metal) ceiling to 56GB, and FLUX.2 BF16's requirement of 64GB exceeds even that. This is not something tuning can shrink — it is about the model size itself.

2. What happens when you load FLUX.2 dev (32B) in BF16

The publicly released FLUX.2 dev has 32B parameters. Loading just the weights in BF16 (2 bytes/param), the required memory is a simple calculation.

32,000,000,000 params × 2 bytes = 64,000,000,000 bytes ≒ 64.0 GB

The weights alone tie with the entire 64GB of unified memory. The OS, ComfyUI itself, the text encoder, the VAE, the activations during inference — the space to put all of these becomes zero. Before any "does it run or not" debate, it is already game over at the calculator stage.

3. What is actually on the disk

So let me look at the FLUX-family weights actually present in my ComfyUI environment.

$ find ~/Documents/ComfyUI/models -iname "*flux*"
flux1-schnell-Q6_K.gguf   9,834,955,808 bytes (9.83 GB)
flux1-dev-Q6_K.gguf       9,857,000,736 bytes (9.86 GB)

Both were Q6_K quantized versions of FLUX.1 (the 12B class). There is not a single FLUX.2 (32B) weight file.

What makes this confusing is that ComfyUI itself already bundles the node code and workflow templates for FLUX.2 and Z-Image (I confirmed diffusers/pipelines/flux2/, the comfy_extras nodes, and the template JSONs shipped with comfyui-frontend-package==1.45.19). In other words, "ComfyUI supports FLUX.2" and "FLUX.2 runs on this Mac" are entirely different statements; the former can be true while the subject of the latter — the model itself — does not exist.

Memory requirement comparison

4. Why quantization is the answer

Loading FLUX.1 (12B) in full BF16 calculates as follows.

12,000,000,000 params × 2 bytes = 24,000,000,000 bytes ≒ 24.0 GB

24GB is a number that fits comfortably on a 64GB machine, but what was actually on the disk was the Q6_K quantized version. Computing with Q6_K (roughly 0.75 bytes/param) gives:

12,000,000,000 params × 0.75 bytes = 9,000,000,000 bytes ≒ 9.0 GB

The calculated 9.0GB nearly matches the measured file sizes of 9.83–9.86GB (which include the VAE and extra tensors on top). Deliberately choosing the quantized version instead of the BF16 that would fit is a judgment about "can I leave headroom to coexist with other resident processes," not about "does it run." Assuming ComfyUI itself, the OS, and other apps are running at the same time, the practical choice is a number with margin, not a number sitting right on the fit / no-fit edge.

Incidentally, the K in "Q6_K" refers to the K-quant series of the GGUF format. Rather than simply dropping all parameters to a uniform 6 bits, it is a block-wise quantization scheme that allocates bit width according to the importance of layers and tensors, and is said to degrade less than naive quantization at the same average bit width (the naming comes from llama.cpp). Here I am working only from the primary fact of file size, on the premise that I have not verified the internal quantization algorithm.

5. The M1 Max numbers are nowhere online

The 2026 Apple Silicon Stable Diffusion / FLUX guide article I used as a source only took real benchmarks on the M4 Max and M5 Max. The row for the four-year-old M1 Max 64GB was left blank. While articles about the newest chips are mass-produced, no one takes the numbers for the still-current previous generation — so this calculation and file survey is also primary information filling that gap.

Used M1 Max 64GB Studios / MacBook Pros still circulate cheaply as entry machines for local image generation. Before you start downloading large model weights on the feeling that "with 64GB most models will probably run," it is worth doing just the params × precision multiplication on a calculator first. In this case, we did not even have to wait for the calculator's answer — it turned out the file in question simply was not on the disk at all.

Summary: reproducible takeaways

"Can FLUX.2 dev 32B run on an M1 Max 64GB" can be answered "no" with a calculator before you run anything. In BF16 the weights alone use up the entire unified memory, leaving room for nothing else.
Do not confuse a model name's generation and size. They tend to get lumped together as "FLUX," but FLUX.1 (12B) and FLUX.2 (32B) are different things, about 2.7× apart in size. Having ComfyUI's support code and actually having the model itself at hand are also different matters.
Quantization is not a means to a binary "runs / does not run" — it is a choice to leave headroom to coexist. Even when a BF16 that fits exists, in practice the quantized version was what was placed there.
Your own machine's numbers can be taken by anyone in a minute with sysctl -n hw.memsize and find ... -iname. If benchmark articles only chase the newest model numbers, you have to make the primary data for your older machine yourself.

Note: a comparison with Z-Image-Turbo was in the original plan, but since neither piece of primary information (an externally verified fact summary / a local model artifact) was available, it was excluded from this article's scope.

Why photorealistic ComfyUI output goes soft on an M1 Mac: the culprit was the single-shot KSampler

bigkijimon — Thu, 23 Jul 2026 13:43:13 +0000

Originally published on Zenn (Japanese). Cross-posted here.

When you try to generate photorealistic images in ComfyUI, you get "soft detail," "broken faces," and "everything falls apart when you raise the resolution." Most of the time the culprit is a single-shot KSampler. In this article I rebuilt that into a 2-pass Hires fix + FreeU_V2 + 4x-UltraSharp and actually ran it on an M1 Mac (ComfyUI :8000), publishing every node and every parameter (seed included) in a form you can reproduce all the way up to a 2688×3456 output.

If there's just one thing to take away, it's this: the two-stage approach of "generate a small base, upscale it in steps, and tighten the second pass with a denoise of 1.0→0.42" is the minimal, reproducible configuration for eliminating the breakdowns in local photorealistic generation. This article covers only the "foundation" up to the 2-pass Hires. Face locking (IPAdapter / PuLID) — the models are already in stock, but they are unused in this article = the next stage — and I draw that line honestly in the second half.

Up front: this article is a hands-on record of settings and visual comparison. Generation time, VRAM / unified memory consumption, it/s, and any quantitative score against the single-shot version are all unmeasured, so I won't cite numbers for them. The only numbers I cite are the actual values in the WF JSON and the measured pixels of the output PNGs.

The problem: a single-shot KSampler makes photorealistic images soft and broken

Load an SDXL photorealistic model and generate along the shortest path: Checkpoint → KSampler → VAEDecode → Save. Many tutorials take this shape. What comes out is an image that is "stuck at the base resolution, with flat skin, and that breaks down when enlarged." The concrete breakdowns I confirmed with the single-shot version were two: skin goes flat and plastic-like, losing pores and texture, and at 1:1 or larger, strands of hair and the edges of contours blur and melt. Applying an upscale to this state only stretches the blurred information — the detail never comes back.

This configuration is also explicitly prohibited in our internal design-department doctrine. The canonical document that defines the workflow policy for photorealistic and diagram work states:

Prohibited: the textbook single-shot KSampler (professional multi-stage = Hires fix 2 passes + IPAdapter / PuLID face locking + 4x-UltraSharp are mandatory).

— from our internal design department's canonical photorealistic workflow ("the single-shot KSampler is prohibited")

Why is the single shot bad? SDXL is trained around the 1024px class, so aiming straight for the final resolution stabilizes neither composition nor detail. On the other hand, hammering a high-resolution EmptyLatent in one go either breaks (e.g. the same face appearing twice) or eats the M1's memory all at once. What avoids both at the same time is the 2-pass Hires fix. We look at the difference in the comparison figure and crop image below.

The overall solution: 2-pass Hires fix + FreeU_V2 + 4x-UltraSharp

Dropping the single shot, I added three weapons.

Two passes: generate the base a bit small (896×1152), upscale the latent by 1.5×, then add detail in the second pass.
FreeU_V2: a quiet move that adjusts the UNet's skip connections to boost detail.
4x-UltraSharp: lift by 4× in pixel space, then bring it back down by 0.5× to condense the detail.

Models are switched by purpose. Photorealistic = RealVisXL_V5.0_fp16; diagrams and text-in-image = flux1-dev. The SDXL family is weak at the thin lines and characters of diagrams, so the criterion is not to force photorealistic and diagram work through the same model (this article is the photorealistic = RealVisXL line).

Figure ① (verified — the star of this article's visual verification): a node-flow comparison of the single-shot KSampler (left / bad version) and the actual 2-pass Hires configuration (right / good version). Node names and parameters are the actual values from PRO_RealVisXL_2pass.json.

The full node configuration and actual parameters (reproducible as-is)

I list the node sequence of the PRO_RealVisXL_2pass.json I actually ran, from top to bottom, all with their actual values. Build with the same values and you get the same chain (the API-format JSON and the Python script pro_gen_realvisxl_2pass.py that is fed into :8000 match on identical parameters).

#	class_type	key inputs (actual values)
1	CheckpointLoaderSimple	RealVisXL_V5.0_fp16.safetensors
2	FreeU_V2	b1=1.3, b2=1.4, s1=0.9, s2=0.2
3	CLIPTextEncode (pos)	cinematic editorial portrait, 85mm lens, detailed realistic skin texture with pores, film grain …
4	CLIPTextEncode (neg)	worst quality, blurry, deformed hands, plastic skin, waxy, cartoon, 3d render …
5	EmptyLatentImage	width=896, height=1152, batch_size=1
6	KSampler ①	seed=770077, steps=32, cfg=5.5, sampler=dpmpp_2m_sde, scheduler=karras, denoise=1.0
7	LatentUpscaleBy	method=nearest-exact, scale_by=1.5
8	KSampler ② (Hires fix)	seed=770077, steps=20, cfg=5.5, dpmpp_2m_sde / karras, denoise=0.42
9	VAEDecode	latent → pixel
10	UpscaleModelLoader	4x-UltraSharp.pth
11	ImageUpscaleWithModel	×4 with 4x-UltraSharp
12	ImageScaleBy	method=area, scale_by=0.5
13	SaveImage	filename_prefix=PRO_RealVisXL_2pass

Pulling out just the difference between the two KSamplers looks like this. This is the heart of the 2-pass approach.

# Pass 1: build the composition from scratch (denoise = 1.0)
KSampler(seed=770077, steps=32, cfg=5.5,
         sampler_name="dpmpp_2m_sde", scheduler="karras", denoise=1.0)

LatentUpscaleBy(upscale_method="nearest-exact", scale_by=1.5)

# Pass 2 = Hires fix: keep the composition, add only detail (denoise = 0.42)
KSampler(seed=770077, steps=20, cfg=5.5,
         sampler_name="dpmpp_2m_sde", scheduler="karras", denoise=0.42)

The key to the prompt is to "explicitly call for skin texture, and kill plastic skin and the 3D-render look with the negative."

positive: … detailed realistic skin texture with pores, film grain, 85mm lens …
negative: worst quality, blurry, deformed hands, plastic skin, waxy, cartoon, 3d render …

The resolution chain: computed from actual values (matches the measured output)

Multiplying the scale values of each node gives the final resolution. This matches the measured pixels of the output PNG exactly.

Figure ② (verified): the resolution chain. 896×1152 →(latent×1.5)→ 1344×1728 →(4x-UltraSharp)→ 5376×6912 →(area×0.5)→ **2688×3456. This computed value matches the sips-measured pixels of the output PNG.

Why these particular steps (design intent readable from the actual values)

I write the "why" of the parameters only to the extent I can state it from actual values, not guesswork.

The meaning of denoise 1.0 → 0.42

Pass 1 is denoise=1.0 = build the composition completely from noise. Pass 2 is denoise=0.42 = destroy only 42% of the input (the upscaled latent) to add detail. Set this too high and the composition and face from pass 1 change; set it too low and it's just a blurry upscale. 0.42 is the practical operating value that "keeps the composition while layering on detail."

Why lift to 4× and then tighten with 0.5×

With 4x-UltraSharp, lift once to 5376×6912, then bring it back by 0.5× using the area method. Rather than aiming for an effective 2× from the start, deliberately creating an excess resolution and then shrinking it condenses detail by area averaging, smoothing out edge jaggies and the noise characteristic of upscalers. The effective magnification is 2×, but the way it tightens up changes depending on the path.

The two-stage approach of keeping the base at 896×1152 and stepping up with latent×1.5

Instead of hammering a large EmptyLatent from the start, step through 896×1152 → latent×1.5. This reads as a design that avoids eating the M1's unified memory all at once. That said, the causal link to avoiding OOM is a design-level inference, and VRAM / memory consumption is unmeasured. Here I separate the fact ("it is built this way") from the inference ("probably for this reason").

[Retraction] The doctrine says "face locking is mandatory," but the actual WF has no face-locking node

This is the backbone of the article. The doctrine cited above says "professional multi-stage = Hires fix 2 passes + IPAdapter / PuLID face locking + 4x-UltraSharp are mandatory." And yet, the PRO_RealVisXL_2pass.json I actually ran contains not a single IPAdapter / PuLID node. What it contains is only FreeU_V2 + 2-pass Hires + 4x-UltraSharp.

In other words, having written "face locking is mandatory" myself, I was running the foundation WF without any face locking. I judged that writing this openly as a stage improves reproducibility. The framing is this:

Face locking (IPAdapter-FaceID / PuLID) is a separate-line weapon. First, with just the foundation's 2-pass Hires, the goal this time is to see how far the photorealistic breakdowns (blur, flatness, enlargement breakdown) disappear.
The face-locking models are already in stock and can be connected as the next stage (the models/ipadapter, models/pulid, and models/insightface directories actually exist).

Explicitly stating "I haven't achieved the full doctrine-compliant loadout" as the endpoint keeps readers from getting lost when they build up their own environment in stages. Rather than showing the fully loaded finished form right away, isolating how far the foundation works is more practical.

The actual output and the evidence that it reproduces

Here are the actual things I ran. The measured pixels of the 2 output PNGs match the WF's computed chain (Figure ②). This is the evidence that it "reproduces."

Actual item / dependency	measured value
PRO_RealVisXL_2pass_00001_.png (Jul 13)	sips-measured 2688×3456 · approx. 11.8MB
PRO_RealVisXL_2pass_00002_.png (Jul 14)	sips-measured 2688×3456 · approx. 11.8MB
RealVisXL_V5.0_fp16.safetensors	approx. 6.94GB
4x-UltraSharp.pth	approx. 67MB
Platform	ComfyUI :8000 resident via launchd / base_path=`/path/to/ComfyUI`

A 1:1 crop of the single-shot KSampler output (left · denoise1.0 · no Hires · 896×1152 naively enlarged) vs the 2-pass Hires + 4x-UltraSharp output (right) (same seed=770077, same prompt, same crop position). On the left the contours, hair, and skin are blurry; on the right it resolves sharply down to individual hairs and skin texture. Also see the node-configuration diagram in Figure ① and the actual-output resolution chain in Figure ② (which matches the output PNG's measured 2688×3456). I speak of the difference by visual comparison only (quantitative score unmeasured).

Being honest: what I did not measure

To prevent misreading, I spell out the range where I do not cite numbers.

Generation time: unmeasured. The polling in the submission script is a timeout ceiling of "3 seconds × up to 120 times = 360 seconds," not a measured time. So I won't write "about N minutes."
VRAM / unified memory consumption: unmeasured (no log).
it/s · sampling speed: unmeasured.
Quantitative comparison score against the single-shot version: unmeasured. I speak of the quality difference only through visual comparison of the output images.

Summary: the reproducible takeaways

The main cause of local photorealistic breakdown is the single-shot KSampler. A 2-pass Hires fix (denoise 1.0 → 0.42) is the minimal effective move.
Condense detail with FreeU_V2 + 4x-UltraSharp (lift ×4, then tighten with ×0.5).
On the M1, step through a base of 896×1152 → latent×1.5, and don't create a large-resolution latent all at once.
Publishing all parameters including seed=770077 = anyone can reproduce with the same values, and it matches the measured output of 2688×3456.
Face locking (IPAdapter / PuLID) is the next stage on top of the foundation. Looking, in stages, at how far the foundation's 2 passes alone eliminate the breakdowns is honest and easy to implement.

The next stage connects the in-stock face-locking line (IPAdapter-FaceID / PuLID) onto this 2-pass foundation. This article goes only as far as the full disclosure of that foundation. Build with the same values, and first confirm the foundation's effect with your own eyes.

Measuring the "LMNOP Problem" in AI Songs — Prompt Fixes Backfired Only on Enumeration Lyrics

bigkijimon — Thu, 23 Jul 2026 13:40:16 +0000

Originally published on Zenn (Japanese). Cross-posted here.

When you write enumeration-style lyrics like "A, B, C, D…" or "January, February, March…" in AI music generation, the pronunciation can fall apart and become unintelligible — even when you thought you wrote a prompt of the same quality as any other line. In the songwriting community this is informally called the "LMNOP problem," a name that comes from how the "L-M-N-O-P" stretch of the alphabet song tends to get mashed together like a tongue twister.

In this article, I actually generated 8 songs with an AI composition pipeline (ACE-Step 1.5, fully local), measured lyric-match rates with mlx-whisper, and — based on those logs — show three things: (1) the mechanism behind the LMNOP problem and how to counter it, (2) what still happened even after applying the countermeasures, and (3) going one step further, a measurement showing that "fixing the prompt and regenerating" — a seemingly correct response — turned out to be counterproductive for enumeration-style lyrics specifically.

What is the LMNOP problem

Enumerations (alphabet, numbers, days of the week, month names, etc.) have a special structure among lyrics. In an ordinary sentence, even if pronunciation wavers a bit, context fills in the gaps — but a string of single-syllable symbols like "B" vs. "D" or "M" vs. "N" has no context to help. When you place them on the rhythm at even intervals, adjacent sounds collapse into each other and become indistinguishable to a listener (and to speech recognition).

The design principles we accumulated in our internal music-generation project spell out the following countermeasures.

Don't space enumerated items evenly; change the grouping (e.g. ABCD / EFG / HIJK / LMN / OPQ / RST / UVW / XYZ)
Write numbers as English words ("thirty", not "30")
Notate letters separated by hyphens, like A - B - C
Keep each line at 4–8 words / 6–10 syllables, and align the syllable counts of parallel lines to within ±1–2
Don't insert "and" into an enumeration

The countermeasures in practice — the prompt and lyrics we used

Here are the actual caption (the ACE-Step prompt) and lyrics we used for a song dealing with the alphabet. The design principles are applied directly, with the grouping changed to avoid the LMNOP problem.

caption: children's song, cheerful, playful, simple melody, ukulele,
         glockenspiel, acoustic guitar, clear female vocals, warm, sing-along
duration: 100s / BPM 100 / C major

[Verse]
A - B - C - D
E - F - G
H - I - J - K
L - M - N

[Verse]
O - P - Q
R - S - T
U - V - W
X - Y - Z

This is a seemingly "correct" prompt, with the textbook countermeasures applied.

Measurement — why the numbers scattered despite the countermeasures

I transcribed all 8 generated songs with mlx-whisper (large-v3-turbo, fully local) and measured the match rate against the lyrics actually used. Each song was generated as 2–4 takes with different seeds under the same prompt, so even the same song with the same prompt shows variation in match rate from take to take.

Song	Take-to-take match-rate range (max-min, pp)	Note
01 ABC Song	58.6	Enumeration
02 Numbers Song	12.2	Enumeration
05 Days & Months	27.7	Enumeration
04 Weather	7.3	Non-enumeration
06 What Time Is It	28.8	Non-enumeration
07 Seasons	75.2	Non-enumeration (generation glitch in v1b)
08 Introduce Yourself	41.0	Non-enumeration

To be honest, the largest range belongs to the non-enumeration 07 Seasons (75.2pp). But the scoring records explicitly note that this song's v1b (0.0%) is a "defective take where Whisper kept hallucinating 'Thank you'," and that 01 ABC Song's v1b (16.7%) is also a "defective take with a broken chorus loop." In other words, engine-side glitches and take-to-take variation are mixed together, and the size of the range alone does not let you conclude "it broke because it's an enumeration."

The main point — prompt fixes were counterproductive for enumeration lyrics only

To separate out the influence of generation glitches, instead of the "range" (which includes defective takes), let's look only at each song's best take (the highest match rate that prompt could produce). For 7 of the 8 songs, we regenerated a "v2" in which the prompt and lyrics were revised to reflect an independent grader's rubric feedback (unnatural English, syllable overruns, lack of expression, etc.). Comparing the v1 best take against the v2 best take yields the following.

How the best-take match rate changed before and after the prompt fix (v2). Among enumeration songs (blue) 2 of 3 got worse, while among non-enumeration songs (orange) 3 of 4 improved.

Average v1→v2 delta for the 3 enumeration songs (ABC / Numbers / Days&Months): -10.43pp
Average delta for the 4 non-enumeration songs (Weather / What Time / Seasons / Introduce — the 4 that were regenerated as v2): +1.25pp

The rubric grader's feedback was reasonable from the standpoint of "singability," "educational value," and so on (e.g. adding TPR action words to 01 ABC, removing the stray "and" in 02 Numbers). Even though the lyrics and structure should have improved, only the enumeration songs moved in the direction of being harder to hear. As of this writing (July 2026), ACE-Step 1.5 is a lyrics-to-song model: it renders the entire prompt (including the caption and structure tags) into audio in one shot, so even fixing just a part of the lyrics changes the acoustic realization of the whole generation (the stability of pronunciation) about as much as drawing a different seed would. Because a short string of enumerated symbols has no context to fill it in and is directly exposed to pronunciation wobble, one can hypothesize that this "seed wobble" is especially prone to translating straight into unintelligibility.

The data in this article is single-batch, in-house data with n=3 enumeration and n=4 non-enumeration, so it cannot be called statistically significant. That said, our own scoring records left, from the same batch, the lesson that "lyric revision (v2) and seed luck are independent — because clarity can drop even when the v2 lyrics are better, the correct approach is to not throw away the old version and to adopt the best take per song." This delta calculation came out consistent with that lesson.

Reproducible takeaways

For songs containing enumeration-style lyrics (alphabet, numbers, days of the week, month names), prefer taking multiple different-seed takes under the same prompt, scoring them, and picking the best take — over fixing the prompt and rebuilding a single track. In this data, rewriting to reflect feedback was more likely than not to backfire.
At the design stage, put the LMNOP countermeasures (changing the grouping, spelling numbers out in English, A - B - C separators, syllable counts within ±1–2) into the very first prompt. It works better than fixing things after the fact.
Don't judge by match rate alone; record generation glitches (hallucinations, broken loops) separately from lyric-structure-derived variation. Jumping to "large range = bad lyrics," as here, would mistakenly turn a defective take like 07 Seasons into evidence for a design principle.

The concrete procedure for match-rate scoring with mlx-whisper (including the arm64-build pitfalls under uvx) is explained in the earlier article "Measuring the quality of local AI composition in numbers — a hands-on record of building a QA pipeline that scores lyric-match rates with mlx-whisper." This article focused on the design principles and on measuring the effect of regeneration.

Automation was dead for 3 days with zero errors — a broken launchd plist, and the "monitor of the monitor" that died too

bigkijimon — Thu, 23 Jul 2026 13:40:13 +0000

Originally published on Zenn (Japanese). Cross-posted here.

I had automation jobs running as launchd daemons (launchd is macOS's cron equivalent), and one day they quietly stopped — yet not a single error line showed up in any log. This is the record of how, on 2026-07-14, I pinned that state down with real logs and rebuilt the setup so that "no errors" would never be trusted again. It's aimed at people with the exact same configuration: an auto-posting pipeline driven by n8n running as a launchd daemon on macOS (M1 Max, 64GB).

Symptom: automation stops with zero errors

The auto-posting workflow (n8n) was supposed to stay resident via launchd's KeepAlive, but at some point it just stopped running entirely. launchctl reported no error. The stderr log was empty too. "No trace of the process having crashed" is the nastiest state of all, because from the logs alone you can't tell whether the monitored target "never started" or "started but isn't doing any work."

Root cause #1: the plist was a JSON-array stub

What was actually broken was a plist file under ~/Library/LaunchAgents/. Looking inside, it was like this (a generalized example for reproduction):

{"ProgramArguments": ["node", "n8n", "start"]}

This is not the valid XML plist that launchd requires — it was a JSON array containing only the contents of ProgramArguments. When launchd tries to load this, it does not report a syntax error; it silently does nothing. The process never even starts, yet no startup error is logged anywhere — this was the true nature of "automation stops with zero errors."

This kind of breakage can be detected mechanically with a single command.

$ plutil -lint ~/Library/LaunchAgents/com.example.myjob.plist
com.example.myjob.plist: OK

$ plutil -lint ~/Library/LaunchAgents/com.example.broken.plist
com.example.broken.plist: Unexpected character c (0x7b) at line 1

Running this against every plist on the actual machine, 15 were invalid at the time (the first-run value of the healthcheck log described below, 2026-07-14). The cause was an organization-wide service-renaming task carried out around the same period: 7 of the plists were converted to proper XML, but the rest — including n8n itself — were left un-fixed.

Root cause #2: the monitor itself was dead for the same reason

Even nastier was that the plist for the health-monitoring job — the very thing meant to watch for "has the automation stopped?" — was broken in exactly the same JSON-array-stub form. In other words, the watchman had never started in the first place. That nobody noticed the stoppage was no coincidence: the type of failure (invalid plist = silent ignore) was the kind that can kill both the monitored target and the monitor at the same time.

There's another structural cause: location. ~/Library/LaunchAgents/ is an OS-level configuration store, and it sits outside the folders you routinely search and take inventory of for documents or code. No matter how well-organized your knowledge management or code search setup is, this location was never on the inspection path to begin with. The only way to notice "something that's supposed to be running actually isn't" was to have a separate job that actively goes and looks at this location itself.

Trend of anomalous-plist counts across 10 healthcheck runs. First run 15 → flat at 14 for seven runs (the deferred-response portion) → 0 on the most recent run.

Permanent fix: build a setup that doesn't trust "no errors"

After rewriting the two broken ones (n8n itself and the health monitor itself) as proper XML plists and recovering them, I set up a single script — resident via launchd, running every morning at a fixed time — that mechanically does only these three things, so the same failure would never slip past again.

Run plutil -lint against all of ~/Library/LaunchAgents/*.plist and judge validity.
Cross-check against the output of launchctl list to also catch ones that are valid but not loaded.
Reflect the results into an internal ledger file by fully rewriting it every time, and send a notification only when there is at least one anomaly (on days with no anomalies, send nothing — so as not to cause notification fatigue).

Running the same check against the actual machine as I write this article, the result is as follows.

$ ls ~/Library/LaunchAgents/*.plist | wc -l
13

$ for f in ~/Library/LaunchAgents/*.plist; do plutil -lint "$f"; done | grep -c ": OK"
13

$ tail -1 ~/Library/Logs/.../healthcheck.log
healthcheck done: anomalies=0

The 13 currently existing plists are all valid (plutil -lint is OK for 13/13). The healthcheck log has 10 runs recorded, and the anomaly count traces this path: first run 15 → seven consecutive runs at 14 (the period when the deferred-response portion remained) → 0 on the most recent run. Rather than an average, the truest picture comes from the three-point set: both ends (15 and 0) plus the fact that it stalled at 14 for seven runs in between. It wasn't "it'll fix itself eventually" — it dropped to 0 all at once on the run where processing of the deferred portion finished.

Adjacent traps: TCC and the Node.js version

This configuration had two more pitfalls specific to launchd-based automation.

The first is macOS's TCC (the privacy-protection access control). When a child process launched from launchd tries to read a protected folder under ~/Documents, the Full Disk Access you supposedly granted from the GUI may not be inherited, and it gets rejected with Operation not permitted. You need to grant Full Disk Access to the executable binary that launchd uses (in this case, the node binary itself); even inserting a shell wrapper does not make the child process inherit the permission.

The second is a trap rooted in the Node.js major version. Dependencies that include native addons (in this case isolated-vm) can build or fail to build depending on the Node.js version. In my environment, Node 26.x failed like this.

serializer_nortti.o Error 1

Switching to Node 22.x (keg-only, no interference with the default Node 26) let the build pass. It wasn't "upgraded to the latest and it stopped working" but "on the latest version it won't even build in the first place" — the kind of defect where the error message alone makes it hard to isolate which layer (TCC / launchd / Node.js) is at fault.

Reusable lessons

If you're running the same setup (launchd daemons + periodically executed automation), the following four make a checklist you can reuse as-is.

Right now, run plutil -lint against all your plists. If even one is invalid, it's dying silently without emitting any error.
Make sure the liveness of the health monitor itself can be confirmed through a path separate from the monitored target (a separate process, a separate log). A design where the monitor dies together with its target under the same failure mode does not function as a monitor.
OS-level configuration stores (launchd plists, cron tables, systemd unit files, etc.) are often outside the folders your everyday code and document searches cover. The more a location is off the inspection path, the more you need a separate job that actively goes and looks at it.
Don't base the evidence of "it's running" on "no errors are showing up." Base it on "the last success timestamp is recent" (the tail of a log, or the timestamp of a heartbeat file). The case of "never even started" and the case of "waiting normally, doing nothing" cannot be distinguished by error logs alone.

I cut subagents from 11 to 0 and cost dropped 87.7% — even though total tokens went UP 27.7%

bigkijimon — Tue, 21 Jul 2026 00:38:47 +0000

This is an English version of an article I originally published (in Japanese) on Zenn.

"Split the work across role-specific agents and both quality and cost will improve" — that was the assumption behind the automated tech-blog pipeline I built. The measurements said the opposite. When I cut subagents from 11 to zero, total token usage actually went up 27.7%, yet the cost of producing one article dropped 87.7%. This is a hands-on record of a person who writes no code building this pipeline with nothing but Claude Code prompts, and then flipping the design based on measured numbers.

The problem: I assumed more agents was better

This pipeline is an in-house system I built — purely with Claude Code prompts — to generate multiple blogs unattended. Not a single line was written by a programmer. I build reservation systems, games, and menu-bar apps the same way.

The first version of the tech-blog pipeline was a 7-agent setup: a chief coordinating a set of specialists.

chief (orchestration)
keyword (topic selection)
research (primary-source research)
outline (structure)
writer (drafting)
publish (formatting for submission)
qa (scoring — an independent process)

It felt natural. Human teams get more specialized when they divide roles; surely splitting "topic picker" and "writer" lets each focus on its job. That was the theory.

The measurement: where the $41.7 per article was actually going

I counted the token breakdown of one article that actually ran to completion under this 7-agent setup (a hands-on piece about local image generation, ~4,000 characters of body, 2 diagrams, published 2026-07-14). Here is what came out.

Segment	Tokens
Parent session	737,594
11 subagents (total)	6,216,660
Total	6,954,254

The final output (the article body) was only about 4,000 tokens. In other words, total tokens were roughly 1,738× the deliverable. And breaking it down further, 79% of the billed tokens (5,455,523) were "cache re-reads" — the same shared context (system prompt, skill definitions, role definitions) being re-read every time execution crossed an agent boundary.

The decisive thing was a design premise. Each stage ran "one at a time, in order." In other words, there was no parallel debate and no cross-checking. Splitting into 7 bodies didn't change the fact that the same model was making the calls on the same source material. The split produced cost and nothing else; it contributed nothing to the quality of the judgment.

The result: tokens up 27.7%, yet cost down 87.7%

So I scrapped the 7-agent setup (the sister pipeline used 9 agents) and consolidated the six stages — ① topic → ② primary sources → ③ outline → ④ drafting → ⑤ QA → ⑥ submission — into a single session that executes them top-to-bottom as "steps." Only QA stayed a separate process (more on that below). The chart below is the measured comparison of the same article run to completion under the old vs. new design.

One article, completed-run vs. completed-run (from an internal measurement record, 2026-07-17).

At a glance the numbers look contradictory. Total tokens went 6,954,254 → 8,880,984, up 27.7%. Cache reads also went 5,455,523 → 8,457,896, up 55.0% (with the whole workflow's context riding in one session, reads actually accumulate). And yet cost went $41.68 → $5.12, down 87.7%.

The reason is the price gap between cache "writes" and cache "reads." Every time execution crosses an agent boundary, a fresh context re-prefill (a cache write) occurs — and that went 1,402,348 → 334,689 tokens, down 76.1%. From our internal operational logs, a write worked out to be roughly 12.5× more expensive than a re-read ($3.75/M vs $0.30/M — an internal estimate, not Anthropic's official price table). No matter how much reads increase, if writes drop 76%, the net comes out ahead.

Why is a "write" so expensive? Prompt caching prefills the shared preamble (system prompt, skill definitions, role definitions) once, loads it into the KV cache, and from then on only "reads" it. A read is cheap because it reuses an already-cached prefix. But when you spawn a subagent, the parent's KV cache is not inherited as-is. The child has to load that same shared preamble again and "write" it back into the cache — that is the re-prefill, and it's why cache writes are billed at a premium. The high re-write piled up once per agent boundary. Consolidation cuts the number of those re-writes directly.

That said, to be honest, not all of that cost gap is the effect of consolidation. Our internal read is that consolidation itself accounted for about 40%, and the remaining ~60% was model choice (Opus → Sonnet). This isn't "delete the agents and it magically got cheap"; it's a combination of "cut the re-prefill cost at agent boundaries, and also revisit the model."

The one thing I kept split anyway

QA is the one stage I did not consolidate; I kept it as a separate process (independent scoring by a cheap model). The reason is simple: when you let the generating model score its own output, the evaluation gets pulled toward the convenience of generation. It's the question of whether you can honestly give your own article a 75. I treat this as one of the few exceptions worth the cost of splitting.

The general rule you can extract from this comes down to one sentence: "Is this stage genuinely debating and cross-checking in parallel, or is it just going around one at a time?" If the latter, the agent boundary is decoration that only generates prefill cost. If the former (a stage that needs an independent set of eyes), it's worth paying the cost to split.

A reproducible takeaway

If your pipeline "splits agents by role," first check whether that stage really makes parallel, independent judgments. If it doesn't, the agent boundary is just an expensive file hand-off that generates a context re-prefill. In a design where each stage runs serially, waiting its turn, splitting is nothing but cost.

Sort each stage with these two questions and the call comes fast:

Does this stage race multiple candidates in parallel? — If No, the split isn't producing parallelism; only the boundary's re-prefill cost remains. Consolidate it.
Does this stage need an independent verifier (a set of eyes whose interests differ from the generator's)? — If Yes, it's worth paying the cost to split, like QA.

Stages that are No on both: consolidate. Only stages that are Yes on either one keep a boundary. Conversely, if stages genuinely run concurrently and branch dynamically on each other's intermediate results — racing multiple candidates at once, switching the next stage based on partial results — then the boundary is doing more than prefill work. Consolidate stages that merely hand off one at a time, and split only the stages that truly need concurrency, independence, or dynamic branching. That's where the line is.

In fact, this very article is a record of that initial intuition — "more agents makes it smarter" — being overturned by measurement. Splitting is not free.

How many tok/s does a local LLM get on an M1 Max 64GB — I measured four models and the bigger one won

bigkijimon — Sun, 19 Jul 2026 04:46:16 +0000

Originally published on Zenn (Japanese). Cross-posted here.

How many tokens per second does a local LLM actually get on a four-year-old M1 Max (64GB) today? When I went looking for benchmark sites, they were all full of M4/M5-generation numbers — the M1 Max row was simply missing. If it doesn't exist, you have to measure it yourself, so I benchmarked four models I had on hand under identical conditions. The table that came out had one counter-intuitive line in it: a model that is 3.6× larger on disk runs 1.5× faster than a smaller one. This article is that measurement, and why it happens.

Every number here is measured on my own machine (M1 Max 64GB / Ollama 0.30.8). Each figure is the median of three runs — no guesses, no borrowing numbers from other machines. Where I couldn't measure something, I say so.

The bottom line: measured tok/s for four models on hand

The measurement conditions are the same for every model. I sent the same Japanese prompt to /api/generate (num_predict=300, temperature=0.7, think=false) and computed decode (generation) tok/s from the response's eval_count ÷ eval_duration. I took the median of three runs each. Before measuring, I confirmed GPU utilization was 0% with no other generation jobs running.

Model	Arch	Total params	active/token	Size	decode tok/s
qwen3.6	MoE	36.0B	~3B	23.9GB	60.4
qwen3.6-uncensored-cc	MoE	34.7B	~3B	21.2GB	59.5
gemma4	dense	8.0B	8.0B	9.6GB	56.6
qwen3.5	dense	9.7B	9.7B	6.6GB	40.5

The three runs were, in order: qwen3.6 at 60.4/60.1/60.5, uncensored at 59.5/59.6/59.1, gemma4 at 56.6/56.5/56.6, qwen3.5 at 40.6/40.5/40.5. The spread is tiny in every case — 0.1 to 0.5 tok/s. These are medians, not single shots, so they're trustworthy. All are Q4_K_M quantization.

Reading the table top to bottom doesn't parse naively. The largest model on disk, qwen3.6 (23.9GB), is the fastest (60.4), and the smallest, qwen3.5 (6.6GB), is the slowest (40.5). On-disk size and speed run in reverse order. That's the whole point.

Why the bigger one is faster: decode is governed by active params

An LLM's decode speed (the rate at which it emits tokens one at a time) is roughly "memory bandwidth ÷ the bytes of parameters actually read per token." On the same machine — same memory bandwidth — the fewer parameters you touch per token, the faster you go.

This is where the MoE (Mixture of Experts) vs. dense distinction matters. ollama show makes the architectures clearly different.

qwen3.6: qwen35moe, with expert_count=256 and expert_used_count=8. It has 36B total parameters, but to produce one token it uses only 8 of the 256 experts. The parameters actually in motion are about 3B.
qwen3.5: qwen35 (dense, no expert keys). It uses all 9.7B every token.
gemma4: gemma4, dense 8.0B. Also uses 8B every token.

So the "real work per token" is about 3B for qwen3.6, 8B for gemma4, and 9.7B for qwen3.5. The order of least work is exactly the order of fastest speed — and the measurements lined up that way. qwen3.6 is faster than qwen3.5 while carrying 3.6× the disk size because those 24GB of weights sit in storage (or rather in unified memory), but only a fraction of them (~3B) is read out per token.

Even ordered by disk size (largest at top), the order does not match decode speed. What determines speed is not total size but active params per token. The MoE qwen3.6 is "big but fast."

Dense vs. dense follows size, as expected

Set MoE aside and the two dense models line up by the textbook. gemma4 (8.0B) does 56.6, qwen3.5 (9.7B) does 40.5. The smaller dense model is faster. 8.0B vs. 9.7B is about a 1.2× ratio, but the measurement opened up to 56.6 vs. 40.5 — about 1.4×. The gap being larger than the parameter ratio is because per-model differences (attention implementation, KV-cache handling, etc.) ride on top; here I'll only say "roughly ordered by size." I make no claim of strict proportionality.

Put another way: "I want a lighter model = pick the one with the smaller disk size" is only correct within dense models. The moment you put an MoE in the running, that intuition collapses. qwen3.6 eats 3.6× the disk of qwen3.5 yet beats it on speed.

Prefill (prompt reading) is a separate story

Everything above is decode (output) speed. Prefill (prompt eval), which reads the input, behaves differently, so I measured it separately.

Model	prefill tok/s
gemma4	639
qwen3.6-uncensored	613
qwen3.6	543
qwen3.5	394

Prefill runs at roughly 10× decode speed (input tokens can be processed in parallel, batched). Here's one measurement pitfall, told honestly. When I first measured qwen3.6's prefill, I got an anomalous 4876 tok/s — about 8× the others. Obviously wrong. The cause: I had just run decode on the same model, so part of the prompt was still in cache and got treated as "already read." Re-measuring with a unique prompt settled it at 543 tok/s. Caching makes speed measurements lie, easily. So prefill should always be measured with fresh input (the table above is the re-measured value).

About the M1 Max "blank space"

The whole reason I started measuring was that searching benchmark sites turned up no M1 Max numbers. The tok/s tables for new models are usually filled with M4 Ultra / M5 Max / M4 Max, and the row for the 2021 M1 Max is blank, or at best a single value of dubious provenance. For someone weighing a used 64GB M1 Max, that's effectively nothing to go on.

These numbers are just a single point of measurement — one machine, M1 Max 64GB, Q4_K_M, Ollama 0.30.8 — and I'm not generalizing. Even so, the one point that "even on a four-year-old M1 Max, an active-3B MoE gets 60 tok/s, and 8B-class dense gets 40–57 tok/s" should be a far better clue than a blank. Subjectively, 60 tok/s streams output faster than you can read, and even at 40 tok/s there's almost no sense of waiting. It's practical for local use.

Reproducible takeaways

Decode speed is governed by active params/token, not disk size. If you're picking a model and think "small = fast," first check whether it's MoE or dense. An MoE can be "big but fast."
Watch for cache in speed measurements. Prefill in particular, if you fire the same prompt repeatedly, gives absurdly fast values from the previous run's cache. Measure with unique input every time.
Use the median of three runs. A single shot can catch an outlier. Here the spread stayed within 0.1–0.5, so I trust these four values.

If your environment (model, Ollama/MLX version, quantization) differs, the numbers will change. If anyone is running other models on an M1 Max, I'd love to know your measured values — especially MoE models (beyond qwen3.6) and tok/s at different quantizations. There simply isn't enough M1-Max-generation data out there yet.

DEV Community: bigkijimon

【夏、再構築中。#2】「遊べない」町を再構築した — 地形整地から小物配置までの全工程と実測値

はじめに

直接原因5個 — なぜ遊べなかったのか

整地前の商店街。地面の勾配が28%あり、目線を合わせると建物の傾きがそのまま見える。

対策 — レベルを触る操作は必ずファイルとして残す

項目実測値

小物配置 — 実測なしでは倍率がバラバラ

整地・小物配置・露出調整後の道路上ショット。看板95枚・小物318体が町に乗った状態。

まとめ — 持ち帰れる学び

mlx-whisperで生成曲の歌詞一致率を数値化する品質採点（uvx arm64罠込み）

問題: AI生成曲の品質をどう測るか

解法: 3層採点パイプライン

実装①: mlx-whisperローカル文字起こし

実装②: 独立ルーブリック採点

実測結果: 32テイクの分布

曲採用一致率裁定理由

Ollama 0.32.0の「ローカルAIエージェント」を本番機で試せなかった話 — 共有GPUインフラのバージョンを上げない判断と、リリースノートと現物のドリフト

本番機の実測 — バージョンは0.30.8、agentは無い

リリースノートは何を約束しているか

Homebrewを見ても本番機のバージョンは分からない

なぜ上げない判断をしたか（1）— 同じアプリの設定DBで7モデルが消えた前例

なぜ上げない判断をしたか（2）— このMacは検証機ではなく共有本番機

上げる/上げないをどう判断するか

Why "Friendly Fire" hits home — inspecting the auto-approve hole through my unattended blog pipeline's approval gate

What Friendly Fire targeted

Why I thought "we're fine"

Retraction — re-reading my scripts, there was an unprotected stretch

So what is actually serving as the defense

The accident that actually happened that same week was far more mundane

Takeaways

Ollama 0.30.8のバイナリには"MLXランナー"が埋め込まれている。だがGGUFモデルは一度もそこを通らなかった — M1 Max 64GBで2モデル実測

1. そもそも「MLXバックエンド」はOllamaのどこにあるのか

2. 実際にgenerateしてログを追ったら、llama-serverだった

3. 外のベンチマークは何を測っていたのか

4. 再現できる学びと、次に確かめること

Qwen3.5-9B（Q4/6.6GB）にM1 Maxで日本語を書かせたら、答えは131字なのに出力は3936トークンだった

実機のモデル仕様

実測ベンチマーク — 答えは131字、出力は3936トークン

正直な限界 — 中央値は取れなかった

M4/M5の公表値とM1 Maxの位置

まとめ — 再現できる学び

Can FLUX.2 dev (32B) run on an M1 Max 64GB? I looked at the disk before doing the math

1. What "64GB" actually is

2. What happens when you load FLUX.2 dev (32B) in BF16

3. What is actually on the disk

Memory requirement comparison

4. Why quantization is the answer

5. The M1 Max numbers are nowhere online

Summary: reproducible takeaways

Why photorealistic ComfyUI output goes soft on an M1 Mac: the culprit was the single-shot KSampler

The problem: a single-shot KSampler makes photorealistic images soft and broken

The overall solution: 2-pass Hires fix + FreeU_V2 + 4x-UltraSharp

The full node configuration and actual parameters (reproducible as-is)

The resolution chain: computed from actual values (matches the measured output)

Why these particular steps (design intent readable from the actual values)

The meaning of denoise 1.0 → 0.42

Why lift to 4× and then tighten with 0.5×

The two-stage approach of keeping the base at 896×1152 and stepping up with latent×1.5

[Retraction] The doctrine says "face locking is mandatory," but the actual WF has no face-locking node

The actual output and the evidence that it reproduces

Being honest: what I did not measure

Summary: the reproducible takeaways

Measuring the "LMNOP Problem" in AI Songs — Prompt Fixes Backfired Only on Enumeration Lyrics

What is the LMNOP problem

The countermeasures in practice — the prompt and lyrics we used

Measurement — why the numbers scattered despite the countermeasures

The main point — prompt fixes were counterproductive for enumeration lyrics only

Reproducible takeaways

Automation was dead for 3 days with zero errors — a broken launchd plist, and the "monitor of the monitor" that died too

Symptom: automation stops with zero errors

Root cause #1: the plist was a JSON-array stub

Root cause #2: the monitor itself was dead for the same reason

Permanent fix: build a setup that doesn't trust "no errors"

Adjacent traps: TCC and the Node.js version

Reusable lessons

I cut subagents from 11 to 0 and cost dropped 87.7% — even though total tokens went UP 27.7%

The problem: I assumed more agents was better

The measurement: where the $41.7 per article was actually going

The result: tokens up 27.7%, yet cost down 87.7%

本番機の実測 — バージョンは0.30.8、`agent`は無い