多數團隊同時有 GitLab CI 與 GitHub Actions，若兩邊都想吃滿一台高規格裸金屬 Apple Silicon，風險在並發、標籤、金鑰與磁碟快取同時失控。本篇收成可寫進 Runbook 的對照條目；混合託管與獨佔節點選型見 企業 iOS CI 混合分流 FAQ；Actions 多機權限習慣見 OpenClaw 與 GitHub Actions 多機協作手冊。
一、為什麼要「同一台裸金屬」而不是拆兩台
合併節點常為映像／Xcode 一致與簽章環境單點治理，且 Apple Silicon 的記憶體與 NVMe較適合單機吃滿。代價是必須用配額＋車道把兩套 Runner 變成可觀測的鄰居，而非互搶資源的黑盒。
二、並發配額：GitLab 與 GitHub Actions 怎麼對齊同一張「預算表」
GitLab Runner 看 concurrent 與群組／專案上限；GHA 自託管看 --max-jobs 與矩陣展開。兩邊勿各自拉滿：以「效能核心 − 系統保留 − 模擬器尖峰」為總封頂再切分，儀表板同看兩邊佇列深度與執行中位數。
- 重型 Job（Archive、全量 UI 測試）與輕量 lint 分開並發池。
- 兩套 Runner 的工作目錄與暫存目錄分樹，避免同一個
DerivedData路徑被並寫。
三、標籤路由：讓流水線「主動選對鄰居」
GitLab 用 tags；GHA 用 runs-on。建議命名空間化（如 mac-m4-bare＋lane-heavy／lane-pr），避免語意重疊卻配額不同。與 Agent 共用標籤時必加費率限制與逾時，以免重型 Job 飢餓輕量 PR。
四、金鑰隔離：同一個 macOS 上兩套「憑證邊界」
最穩為不同 macOS 使用者或至少分鑰匙圈與 provisioning，讓兩邊簽章上下文互不可讀；OIDC／短期權杖優於長效 PAT；~/.netrc 與套件 token 分檔，稽核能對應到哪一邊 Runner。混裝 brew／npm／Docker 時把「憑證面先失敗快讀」寫進 Runbook。
五、NVMe 快取分區：誰讀共用、誰寫隔離
建議四類路徑：（1）唯讀共用快取；（2）GitLab 可寫工作樹；（3）GHA _work 與本機快取鏡像；（4）每 Job 隔離的 DerivedData／模擬器資料（TTL／租約回收）。APFS 多卷宗做軟隔離；告警須能一眼看出哪一邊打滿哪顆卷。
- 共用唯讀：降低重複下載；升級依賴時走變更單與版本釘選。
- 可寫隔離：每 Job 子目錄＋結束清理；逾時 Job 強制回收避免磁碟鎖死。
- IOPS 預算：兩套 Runner 同時全量編譯時，NVMe 比 CPU 更早成為瓶頸。
六、落地 FAQ（精簡版）
- Q：可以同一個使用者跑兩邊嗎？ 可以，但不建議上生產簽章；至少分鑰匙圈與工作目錄。
- Q：哪邊該吃較多並發？ 依儲存庫數與 PR 頻率定權重，並以 SLO 反推而非平均負載。
- Q：快取能共用嗎？ 唯讀層可共用；可寫層務必分庫分鍵，避免 cache poisoning 與競態；變更依賴版本時走變更單。
在 Apple Silicon Mac mini 上校準雙 Runner 模型
配額與分區須在真實 macOS／Xcode上壓測。Mac mini 適合作對照或外溢節點：Apple Silicon 統一記憶體利於編譯與快取並行，待機約 4W；Gatekeeper、SIP、FileVault 利於無人值守，TCO 常優於拼裝 PC。獨佔驗證機可從 Macstripe 首頁 比對節點。Mac mini M4 是 2026 驗證雙 Runner 與 NVMe 分區的高性價比起點；想一次校準 Runbook 數字，現在即可從首頁選型銜接上線。
