2026 年 Mac 雲 CI「冷啟動 vs 溫節點」怎麼選：佇列退避、DerivedData 親和與常駐基線的可執行設定
負責 iOS／macOS 流水線的同仁多半已會撰寫 GitHub Actions，卻仍被「第一次慢、第二次快、第三次又慢」的方差折磨：根因往往不是 Xcode 本身，而是冷啟動快取未命中與多 job 爭用同一 DerivedData 根目錄。本文面向 2026 年要把 Mac 雲當成可控 VPS 的平臺團隊：先拆四類痛點，再給冷／溫／常駐對照矩陣，接著落地 DerivedData 親和與佇列退避參數、三條可引用指標與 FAQ；讀完你能用一張表向團隊解釋何時該為溫節點付租金屬性，何時該讓冷啟動吃掉分鐘尖峰。
目錄
1. 痛點拆解：冷啟動方差、親和缺失、退避缺失與觀測盲區
當你把 Mac 雲節點接入 CI，本質是在複用「像管 Linux VPS 一樣」的心智：SSH、systemd／launchd、磁碟與出口都可控。但 Swift 大工程對 NVMe 與快取局部性極其敏感，若仍沿用「每台 runner 一個共用 DerivedData」的壞習慣，冷啟動與溫啟動的差異會被放大成 flaky。
- 冷啟動尾延遲：首次 checkout 後解析 SPM／CocoaPods、預熱索引、連結階段會把 P95 拉長；若財務只看總分鐘數，會誤判為程式變重，而根因是快取未命中。
- 親和缺失導致的漂移：同一分支連續建置若落到不同實體機或不同磁碟分割區，模組增量編譯收益驟降；團隊會誤以為是編譯器升級，實際是路徑漂移。
- 無退避的並發閘門：多個 Archive job 同時觸發時，若缺少 max parallel 與指數退避，NVMe 佇列深度飆升會讓失敗表現為「偶發連結逾時」，難以與業務缺陷區分。
- 觀測只看 CPU：macOS CI 的第一性原理往往是 IO 與中繼資料；忽略磁碟可用空間百分比與連結階段耗時分佈，會讓優化會議永遠停在「再加兩核」。
2. 決策矩陣：冷啟動池、溫節點、常駐基線三種形態怎麼選
下列矩陣刻意與「彈性池＋常駐基線」路由文章互補：那張表回答 PR／Nightly 走哪類 runner；本文回答同一台 Mac 雲內部如何把冷／溫／常駐參數寫進可執行設定。延伸閱讀：iOS CI 彈性池與 Mac 雲基線分工、建置資源池容量決策矩陣。
| 維度 | 冷啟動優先（按需短跑） | 溫節點（半常駐快取） | 常駐基線（獨佔槽位） |
|---|---|---|---|
| 典型負載 | lint、單測、輕量編譯矩陣 | 中等多模組增量、頻繁 PR | Archive、公證、長時 UI 矩陣 |
| 尾延遲敏感度 | 可接受分鐘換彈性 | 需要穩定 P95，但可容忍偶發遷移 | 要求連結階段方差極低 |
| 磁碟策略 | 每 job 獨立子目錄＋夜間 gc | sticky 路徑或短週期鏡像快照 | 雙分割區：建置域與成品域隔離 |
| 佇列策略 | 高並發＋嚴格退避上限 | 中並發＋佇列深度閾值 | 低並發＋人工變更視窗 |
3. DerivedData 親和：路徑設計、並發閘門與反 stampede
親和的目標不是「永遠同一台機器」，而是讓編譯器看到的模組快取與索引在統計意義上可複用。實務上至少做到三點：為每個並發槽位分配獨立 DERIVED_DATA_PATH；Archive 與輕量 job 分佇列；在磁碟低於約百分之十五可用空間時禁止新 Archive 入隊。
export DERIVED_DATA_PATH=/Volumes/ci/d12/$JOB_SLOT/dd
export COCOAPODS_CACHE_PATH=/Volumes/ci/d12/$JOB_SLOT/cocoapods
xcodebuild -scheme App -destination 'platform=iOS Simulator,name=iPhone 16' build
佇列退避建議與組織級重試策略對齊：對連結階段失敗使用較小最大重試次數並拉長間隔，避免在磁碟已紅時形成 thundering herd；對原始碼編譯失敗則快速失敗以節省佇列佔用。
4. 五步落地：從畫像到驗收
- job 畫像：把流水線拆成冷／溫／常駐三類，分別統計平均排隊、編譯、連結、上傳占比；若連結占比異常升高，優先檢查 DerivedData 爭用而非加 CPU。
- 路徑契約：寫清
JOB_SLOT或自託管 label 與目錄對應，禁止個人實驗分支預設寫入共用快取根。 - 並發閘門：為 Archive 設全域 max parallel＝1～2；為 PR 增量建置設更高上限但綁定退避曲線。
- 告警接線：把磁碟水位、佇列深度、重試分鐘占比接入與 CI 可觀測性一致的面板，避免只在失敗郵件裡看到症狀。
- 三次建置驗收：固定同一 commit 連續跑三次，比較 P95 與失敗類型叢聚；若方差仍高，再評估增加第二台常駐基線而非盲目擴並發。
5. 三條可引用指標：排隊、連結長尾、磁碟水位
- 排隊佔端到端比例：若持續高於約百分之十五且與提交頻率強相關，說明池子策略與工作混部需要調整，而非單純「機器不夠快」。
- 連結階段耗時方差：同一 commit 三次建置的連結 P95 差距若超過約百分之二十五，優先核查是否共用 DerivedData 根或磁碟水位過低。
- 重試分鐘占比：當重試消耗分鐘超過總量約四分之一時，多半是退避缺失或閘門過大導致的 IO stampede，應先降並發再擴容。
6. 與站內彈性池文章的銜接
若你已經在實踐「PR 走託管彈性、Nightly 走 Mac 常駐」，本文把第二層的「Mac 雲內部怎麼配」補齊：冷啟動負責吸收尖峰分鐘，溫節點負責穩住增量體驗，常駐基線負責 Archive 與上架鏈路的可預測性。把兩層策略疊在一起，財務與平臺才能用同一套語言討論成本與穩定性。
7. FAQ
問：只有一台 Mac 雲也能做溫節點嗎？ 可以，用目錄槽位與佇列深度模擬「邏輯溫區」；但要接受遷移視窗仍然存在，Archive 仍建議獨佔低並發佇列。
問：親和與安全性衝突怎麼辦？ 多租戶隔離應優先於盲目 sticky：不同專案使用不同 Unix 使用者與卷掛載點，避免金鑰與快取交叉污染。
問：是否需要自建分散式快取叢集？ 在團隊規模未到前，先把本機 NVMe 分割區與 job 級路徑做對，通常比過早引入遠端快取更能降低方差。
8. 結論與下一步
冷啟動不是敵人，無約束的混部才是；溫節點與常駐基線的價值在於把尾延遲從「隨機過程」變成「可設定參數」。當你已經能讀佇列與磁碟曲線，就能把 Mac 雲真正當成可程式化算力，而不是另一台會隨機變慢的共用 Mac。
僅依賴託管池時，磁碟佈局與並發閘門仍受平臺策略約束，難以把 macOS 當成完全屬於你的建置土地；純冷啟動堆疊在單台小磁碟節點上，又容易在 Archive 與 PR 增量之間互相踩踏。對要把 iOS 交付做成穩定產能、又希望繼續用 SSH 與 launchd 延續 Linux VPS 維運習慣的團隊，租賃 VPSMAC 的 Apple Silicon Mac 雲節點，用獨佔或低並發基線承載重鏈路，把冷啟動留給可接受方差的輕工作，通常比繼續在「同一 DerivedData 根目錄」上硬扛尖峰更接近問題本質。