M7 v2 — 最終スタック独立再計測 (post S4b) は session 汚染で +6.4%、paired control 122.77s を維持。多 scene (ficus/materials/drums) で退行なし確認

sample σ = 2.257s (1.727% of mean)。個別偏差: r1 +1.71s (0.76σ)、r2 +0.84s (0.37σ)、r3 -2.56s (1.13σ) — いずれも `p3-tier1-bit-exact.toml` §5 の事前登録条件 (load 証拠 AND 自 arm内 3σ 超) の後半を満たさないため、**この規約に従う限り 3 run とも棄却/再試行の対象にならない**。しかし §2 で示すとおり、3 run すべてが同じ iter3000-9000 区間で一貫して減速しており (=相関した底上げ)、単一 run の外れ値を検出する設計のこの規約は「session 全体が相関して汚染される」パターンを検出できない構造的な穴を持つ。

10s 間隔 load sampler (`runs-logs/finalv2-12500-loadsamples.log`) を r1/r2 window の epoch timestamp と突き合わせると: r1 window (pre 1788100979.56 → post 1788101115.01) 内で load1 が 1788101039.64 に **5.77** まで上昇 (window 開始から +59.4s、r1 の iter6000 (elapsed 51.36s) 〜 iter7000 (elapsed 64.71s) の区間に相当)。r2 window (pre 1788101165.15 → post 1788101299.60) 内でも 1788101239.96 に **4.22** まで上昇 (window 開始から +74.8s、r2 の iter7000 (61.00s) 〜 iter8000 (73.33s) 付近)。r3 window はサンプル値が終始 2.1〜3.0 で最も低く、実測 wallclock も 3 run 中最速 (128.10s) — load スパイクのタイミングと ms/iter の減速タイミング・run 間の速度順位がいずれも整合する。

Part 2 (ficus) 実行直後の `uptime` で load average が 9.96→16.88→32.58 まで跳ね上がったため `ps aux | sort -rk3` で原因を確認したところ、/System/Library/CoreServices/Finder.app が **147.3%CPU**、ユーザーの別プロジェクト (/Users/otkrickey/dev/otksynth/target/debug/deps/analyze_queue-*、matsudalab とは無関係な Rust バイナリ) が **35.7%CPU**、音声処理プロセス (dj-lab) が **24.8〜49.9%CPU** で稼働しているのを直接確認した。これらは本タスクの一部ではなく、ユーザー自身が同じ機体上で並行して行っていた無関係な作業であり、Part 1 series (23:42〜23:51) の後半・Part 2 の ficus/materials (23:54〜00:13) にかけて発生・持続していたと推定される (Part 1 の load スパイクのタイミングと符合)。GPU 権の取り決め (「他 agent は GPU を使わない」) は agent 間の話であり、ユーザー自身の CPU 作業は対象外だった — Apple Silicon の unified memory 帯域は CPU/GPU で共有されるため、CPU 側の重い並行負荷が GPU バウンドな学習の host-side critical path (host_schedule=forward_shadow 等) を遅らせうる。

advisor レビューでの指摘: r3 (128.10s) の window 内 load サンプルは終始 2.1〜3.0 (最大 3.00) で、M7 が『クリーン』と判定した r2-r4 の window (0.93〜3.46) と同水準であるにもかかわらず、control (122.768s) より **+4.3%**・M7 の r2 (123.34s) より **+3.9%** 遅い。segment 単位でも iter11000-12000 (12.51ms/iter、M7 3-run 平均 11.88ms/iter 比 **+5.3%**) に load スパイクの証拠なしに減速が見える。**したがって load スパイクは r1>r2>r3 という 3 run 間の『ばらつき』の順位は説明するが、3 run 全てに共通する ~4〜6% の『底上げ』の全量までは説明できていない**。念のため 2 点を確認した: (1) `git diff --stat 2cb044bde530a425b89c3e90d2532d0e37673021 9bb4ea5 -- splat/crates/` は rasterize.rs / ssim.rs / tile_bin.rs / config.rs / refine.rs の 5 file に diff を持つが、内容を確認すると**全て gate 完了後の verdict 追記という doc comment のみ** (raw struct 初期値・実行ロジックは無変更、`git diff` は `git log` と異なりマージの履歴簡約を経ないため、この空でない diff の中身が doc-only であることを確認できて初めて『事実上同一コード』の主張が成立する)。(2) `diff splat/configs/2026-08-30-rnd-12500-off-r1.toml splat/configs/2026-08-30-finalv2-12500-r1.toml` は `[backend] refine_gpu_snapshot = false` の明示 vs 無指定 (どちらも解決値は `false`) のみで、他の `[backend]` field 差は無い。**この 2 点はいずれもクリーンで、control が本 session の HEAD と機能的に同一コードであることを裏づける** — が、これは「なぜ r3 でも+4%遅いか」を説明しない。残る有力候補は thermal/DVFS drift (本機は series 開始時点で既に 11h+ 連続稼働、当日を通じて M0〜M8 の多数の GPU gate を実行済み) だが、`sudo powermetrics` が使えない環境のため確認できていない。結論を『130.657s は完全に session 汚染で説明される』から『load スパイクは run 間のばらつきを説明するが、3 run 共通の残差 ~4〜6% は未解明で thermal/DVFS drift が有力候補 (未検証)』に修正する — この修正は milestones.md の headline (paired control 122.77s を採用) には影響しない、unpaired series が paired control に劣後するという結論はどちらの読み方でも同じだからである。

事前登録した 2 分岐判定のどちらにも単純には当てはまらない。(1) 「10分 cooldown で control ±1.5% に戻れば thermal drift 確定」は不成立 — finalv3 mean 129.75s は control から 5.7% 乖離したままで、cooldown 前 (finalv2) とほぼ同水準 (finalv2 as-measured 130.657s との差はわずか 0.7%)。load は同時に測った sampler 上で finalv2 r3 より更にクリーンなので、cooldown 実施・同時プロセス不在という 2 条件をどちらも満たしてなお速度が戻らなかった。(2) 「130s 圏のままなら binary/環境の恒久的変化を疑う」に従い `git log --oneline -8` と `git diff 4405bb4 HEAD --stat -- splat/` を確認したところ、S4b gate (4405bb4) 以降に `splat-metal`/`splat-train-v1` の複数ファイル (`refine.rs` +598 行など) に実コード変更 (`refine_gpu_snapshot` flag 新設、C2 施策#4) があった。しかし該当 flag の default は `false` (config.rs Default impl で確認)、かつこの機能一式が **finalv2/finalv3 と bit-identical な binary (sha256 c804b349...)** で既に組み込み済みの状態のまま `p3-refine-nondrain` gate の off-arm が同日 23:30 に **122.6467s** を記録している (§2 既存記載)。つまり『遅い』finalv2/finalv3 と『速い』refine-nondrain off-arm は **文字通り同一バイナリ** であり、コード差分では今回の +5.7% を説明できないことを再確認した。結論: cooldown 前後で速度は変化せず (thermal drift の単純な仮説は反証)、コード差分でも説明できない (binary/環境の恒久的変化の単純な仮説も反証) — 残る説明は『10 分では解消しない、より長い時定数を持つ電源/サーマル状態のヒステリシス』(`pmset -g therm` がこの機体で無効なため直接確認不能) であり、これは未解決のまま残す。 最終値としては引き続き **paired control 122.77s (S4b on-arm) を採用**する — この判断は §2/§3 の既存結論と変わらない (unpaired 単発測定は paired control に劣後する)。今後の追加検証をするなら、10 分ではなく数十分〜完全な reboot 後の cooldown で再試行するのが次の一手になる。

125.19s は ~122s 陣営 (+1.97%) の方に ~130s 陣営 (-3.85%) より 2 倍近く近い。加えて本 rerun は §8 の finalv3 (完全クリーンな load) より重い contamination (`bfs` 500-600%CPU) を run 終盤に受けながらも finalv3 より速く完走している。もし『今この機体は時刻に依存して一律 130s 圏まで遅くなっている』という単純な普遍的 drift が真であれば、contamination で下駄を履かされたはずの本 rerun がむしろ finalv3 を上回って速く終わる理由がない。したがって本結果は「explicit backend flag 明示の config は §8 以降も一貫して 122-125s 帯を保っており、backend flag 無指定 (default 依存) の config だけが 130s 圏に留まっている」という『flag 経路依存』説をわずかに支持する一方、rerun 自体が contamination を受けているため 122.77s ちょうどには戻っておらず、explicit flag 説を確定させるにも至らない。結論は「引き続き未確定」だが、§8 で立てた「10分では解消しない普遍的な電源/サーマルヒステリシス」という仮説の優先順位はやや後退し、次の一手としては『explicit flag config』と『default flag config』を同一 session・同時間帯・load クリーンな状態で back-to-back 実行する A/B が、cooldown 再試行より優先度が高いと判断する。milestones.md の現在地は引き続き §2/§8 の判断 (paired control 122.77s を採用) を変更しない。

2026-06 spike が使っていた「本実装11m48s/36.26dB (12.5k) vs msplat3m40s/35.48dB (30k)」という比較は、iter数の非対称 (12,500 vs 30,000) に加え、msplat側の219.8s/35.48dBという数値自体がinit点群・holdout・解像度スケジュール不明の条件非対称な初期spike値である (`p2-msplat-parity-lego.toml`、2026-08-16の同日対称条件再計測で判明) という二重の限定を持つ。iter数を揃え、msplat側もp2-msplat-parity-legoの対称値 (167.7s (n=2 mean) / native 36.53dB / brush ce 33.05-34.47dB) に置き換えると、比較は「本実装 n=2 mean 7m28s(448.26s)/36.45dB(self, convention相違につき参考)・36.49dB(brush ce) (30k) vs msplat 167.7s(n=2 mean)/36.53dB(native, convention相違につき参考)・33.76-34.47dB(brush ce) (30k)」に置き換えられる。gap は r1(413.56s) で2.47×、n=2 mean(448.26s) で2.67× (旧3.22×はspike基準・iter数非対称の二重非対称値であり参考扱いに降格)。PSNR は同一convention (brush) でのみ優劣を判定でき、本実装が+2.02dB(best比)〜+2.73dB(mean比)優位 — ただしmsplat側のbrush ceは非決定性1.4dBを含む。self-eval/native convention同士の比較 (36.45 vs 36.53) はconvention相違のため優劣を断定しない — p1-a-3のconvention couplingの再確認である。final splatsは489,679 vs 192,830 (対称mean比) で2.54×。卒論§5のdirect comparison表・Paretoナラティブを更新する際はこの対称断面 (msplat側も対称条件)を優先すべきである。ただし r2 (482.96s) は r1 (413.56s) より+16.8%遅く、post-run load1=24.44 (`mds_stores` = Spotlight indexing 起因と推定、機体ディスク残 1.9GiB という逼迫も一因の可能性) の影響が疑われるため n=2 σ (10.95%) は §1 の n=3 (σ1.727%) より大きい。n=2 のみでは load 汚染を統計的に切り分けられないため、公式headline化するには (1) n=3 以上への拡張 (できれば load クリーンな条件での paired 実行)、(2) msplat側の同日再実行 (p2-msplat-parity-lego と同様のinterleave手順、本節では2026-08-16実測を借用しており本実装30k runとは別日) の両方を推奨する。PSNR (self-eval / brush cross-eval) と final splats は load 非依存でσが小さく (0.03-0.34%)、こちらは n=2 でも安定した根拠として扱ってよい。「6月708s/36.26dBはPhase H 12,500 iterであり、本節の30k比較 (本実装/msplat双方とも30,000 iter) とは別条件」という点を卒論反映時にも明記すること。

msplat 30K = 165.65s / native 36.462dB / brush ce (q8) 33.927dB / 191,941 splats (2026-08-31 真の同日実測、本実装 30k r1/r2 と同一日・同一 M4 Max)。本実装 30k r1 (413.56s / self 36.457dB / brush ce 36.501dB / 490,866 splats、§10) との完全対称 gap は wallclock 2.497× (n=1) / 2.706× (n=2 mean)、brush cross-eval PSNR +2.574dB。この値は §10 が用いた 2026-08-16 借用値基準 (2.466×/2.673×、+2.02〜2.73dB) とほぼ同水準 (差 1-2%) であり、非同日借用によるバイアスは実質的に無視できる大きさだったと確認された。卒論 §5 の direct comparison 表・Pareto v3 系列の headline gap は、より厳密な根拠を持つ本節の 2.497×(n=1)/2.706×(n=2 mean) を正式値として採用すべきである。native/self PSNR 断面では両者ほぼ互角 (msplat +0.005dB) という事実は、品質優位の主張が brush convention (本実装の学習 convention) に限定されるという p2-msplat-parity-lego §4 の結論を 30k iter 断面・真の同日条件下でも裏づける。

事前登録した 2 分岐 (control バンド 120.93-124.61s / finalv2-finalv3 圏 ~129-130s) のどちらにも該当しない。3 run 全てが control バンド上限 (124.61s) を超えている (r1 +1.75% / r2 +3.63% / r3 +2.74%、control 122.768s 比)。mean±σ = 124.93-127.24s — この区間は control バンド (120.93-124.61s) の直上に隙間 (0.32s) を空けて存在し、重ならない。finalv2 (130.657s) / finalv3 (129.750s) の側とも重ならない (最短距離は finalv3 との 2.51s = mean+σ からの差)。相対距離で見ると、mean (126.087s) は control (122.768s) から +2.70%、finalv2/finalv3 mean (130.204s) からは -3.16% — control 側にやや近いが、control バンド自体には入っていない。§9 の単発 rerun (125.19s、bfs contamination あり) とは +0.72% で近く、本 n=3 の結果はその単発値をおおむね裏づける形になった。結論: 静穏条件 (load1 終始2.1-3.2、LOAD_LIMIT=4.0 を維持、突発的 contamination なし) を確保してもなお、control config は元の paired gate 値 (122.77s) を再現できず、恒常的に +2.7% 程度遅い状態が続いている。一方で、backend flag 無指定の finalv2/finalv3 が示した +5.7〜6.5% ほど極端ではなく、ほぼ半分程度の drift 幅にとどまる。§9 で切り分けた「explicit flag config は default-flag config より drift 幅が小さい」というパターンは本節でも再現されており (explicit flag: 122.77→126.09s、+2.70%。default flag: 124.39(M7)→130.657(finalv2)、+5.05%)、『flag 経路依存』ではなく『環境の時間依存 drift が config 種別に関わらず存在し、その絶対量が session ごとに変動する』という §8/§11 の結論を補強する。今回新たに観測された dj-lab の断続的な起動/停止 (r1→r2 の間で新規プロセスが立ち上がった) は、load average だけでは捉えきれない低〜中負荷の同時実行プロセスが依然として drift の一因でありうることを示唆するが、その寄与度を本 n=3 だけで定量化することはできない。milestones.md の「現在地」は §2/§8/§9 の判断を変更せず、paired control 122.77s (S4b on-arm) を引き続き採用する — 本節は「静穏条件でも drift は完全には消えない」という追加の計測論的事実を記録するにとどめる。次の一手としては、§9 が提案した『explicit flag config』と『default flag config』の同一 session・同時間帯 back-to-back A/B に加え、dj-lab のような低負荷バックグラウンドプロセスの有無を意図的に制御した A/B が優先度が高い。

静穏 config は diff で [data]/[trainer]/[refine]/[adam]/[backend] が §6 の config と完全一致 (name/description/run_dir のみ変更) しており、BackendConfig ログも一致するため config 起因ではないことは確認済み。コードの RNG は StdRng::seed_from_u64(cfg.output.seed) (config の seed フィールドのみに依存、splat-cli/src/cmd/train.rs) で、run 名や run_dir をハッシュに含む経路は grep で確認した限り存在しない — 「run_dir の違いが結果に影響した」という仮説は事前に排除した上で、同一 config を -q2 として再度 splat check validate・quiesce (60秒 load1<4) を経て再実行した。結果は 34.279dB (baseline 34.281dB 比 -0.002dB) で、q1 の -1.4dB 台とは全く異なり baseline/§6 と整合した。final splats も q1 228,147 / q2 228,595 と近く (0.2%差)、wallclock も q1 254.09s / q2 256.21s と近い (0.8%差) — 不安定だったのは PSNR のみで、wallclock・splats は 2 run で再現性がある。事前登録した 2 分岐のうち「~34.2 に着地」が的中したため、「ficus は GPU 非決定性に特に脆弱な scene である」という強い仮説 (機構の特定) は撤回する。q1 の -1.4dB 自体は a-10-variance-baseline が報告する SIMD backward の atomic_fetch_add 順序非決定性 (→ refine の split/clone 判定 flip → splat trajectory 分岐 → PSNR drift) の一事例である可能性が高い。ただし機構の特定とは別に、§6/q1/q2 の同一 modern-stack config・3 run で観測された range は 1.443dB (34.261/32.836/34.279) であり、これは a-10 が Lego 30k・4 run で確立した range 0.885dB の 1.6 倍 — materials の同条件 3 run range (0.028dB) とは対照的に、ficus では a-10 の σ±0.32dB / range 0.885dB を「退行判定の noise floor」としてそのまま転用するのは無効である。§6 の「3 scene とも ΔPSNR は σ±0.32dB の1/10以下」という記述、および §6 退行判定callout の「±0.1dB を超えたら scoped gate」という基準は、ficus に限っては n=1 の ΔPSNR -0.020dB がこの range (1.443dB) 内に埋もれる程度の情報量しか持たないことを意味する — M4/A7/S4b が PSNR-neutral な設計 (grad/param 更新を変えない) であるという §6 の結論そのものは変わらないが、「ficus の n=1 ΔPSNR が小さいことをもって退行なしと確度高く言える」という強さの主張はできない。本 finding では追加 run による σ の確定は行わない (観測された range を記録し、multi-scene gate 閾値の見直しが必要という指摘にとどめる)。