開發者人數只是任務來源，不是同時執行數。你應把工作拆成以下幾類：

• PR 建置：到達頻率高，通常可重試，也最適合進入共享建置池。
• 模擬器測試：可能長時間佔用 CPU、記憶體與儲存空間，不能只用編譯時間估算。
• 夜間回歸：任務集中在固定窗口，會形成短時間峰值。
• 歸檔與簽名：受憑證、Keychain、發布鎖及權限影響，不應與不受信任的普通工作共用同一安全邊界。
• 正式發布：優先級高，但常受到外部服務、審批和人工鎖定影響。

至少要收集任務到達率、執行時間、隊列長度、峰值窗口、失敗重試、工作區清理時間與發布鎖等待時間。資料應按提交時間和任務類型保存，不能只取平均值。

可使用以下變數建立初版模型：

• 保底並發：穩定工作時段內，同時執行的必要任務數。
• 峰值並發：發布、夜間回歸或大量 PR 合併時的有效任務數。
• 有效容量：可用節點數 × 每節點可承受的並行任務數，再扣除簽名隔離、重啟、快取失效與維護保留量。
• 安全餘量：只有在企業記錄或容量測試證明後，才把餘量寫入採購模型；不要自行套用固定百分比。

典型錯誤是「任務數增加，但節點並未真正飽和」。例如 CPU 使用率不高，隊列卻變長，原因可能是簽名資源被鎖定、套件下載受頻寬限制，或工作區清理尚未完成。這時增加 Mac 只會增加閒置設備，不能縮短關鍵等待。

容量判讀要同時看三件事：單任務是否變快、多任務吞吐是否增加，以及隊列等待是否下降。升級單一 Mac 可能縮短乾淨建置時間，卻不能處理同時湧入的多個測試工作；增加節點則可能改善隊列，卻把快取、簽名或私有網路瓶頸放大。

GitHub Actions 的工作可以依需求指定 Runner；官方文件列出 xcode-27 與 arm64 Runner 相關能力，但鏡像、計費與組織限制應在採購前重新核對（Runner 選擇文件）。較大型 Runner 的硬體與標籤也不能直接等同於你的專案可用容量，仍要用實際流水線驗收（larger runners 文件）。

建議的基線測試矩陣

同一份程式碼、相同依賴版本與相同 Xcode 設定，才有比較價值。測試時要記錄提交版本、任務類型、並發條件、節點狀態與失敗原因。若只記錄「工作成功」，無法判斷容量是否足夠。

建議把 CI 基礎設施分成三個容量池，而不是讓所有工作競爭同一批 Mac：

遠端 Mac 適合補上波動容量，但要先確認四個邊界：

• 節點啟動後，Xcode、SDK、依賴與 Runner 能否在預定窗口內完成交付。
• 快取是否能跨節點復用；若每次都重新下載，新增並發可能轉化為頻寬競爭。
• 私有套件庫、內部 API、憑證服務及通知系統是否可從遠端節點連線。
• 節點失敗時，任務能否回到固定池；若不能，彈性池只是另一個單點故障。

GitHub 對工作流並發控制、排程與取消策略有獨立說明（Concurrency 文件）。你應將「同一分支只保留最新 PR」與「正式發布不可被取消」分開設定，否則隊列數字會掩蓋真正的容量需求。

用條件分支決定買節點還是擴容

• 若 CPU 或記憶體在相同任務下長時間接近企業記錄的上限，且隊列隨任務增加，則增加 Apple Silicon 節點。
• 若單任務變慢主要來自快取失效、套件下載或工作區清理，則先修正流水線，不要立即採購。
• 若普通 PR 與簽名工作互相阻塞，則建立專用簽名池，重新設定憑證和工作區權限。
• 若峰值只出現在短暫發布窗口，且工作可重試、私有依賴可連線，則用遠端 Mac 彈性池補足。
• 若遠端節點不能穩定交付環境，或任務依賴固定硬體介面，則回退至固定 Mac 節點。
• 若固定池已承擔穩定基礎負載，彈性池只在可證明的峰值啟用，則採用混合節點池，而非購買一台規格極高但長期閒置的單機。

企業 Mac 基礎設施 TCO 分析不應只比較設備數量。固定採購要計入硬體折舊、備援、維護、人力、機房或辦公室條件，以及閒置容量；托管 Runner 或遠端 Mac 則要計入按量費用、啟動延遲、資料傳輸、環境重建與私有網路成本。

GitHub Actions 的計費方式、免費額度與超出後費率應以當日官方文件核對（Actions Runner Pricing）。組織層級的作業限制與並發邊界，也要對照官方限制文件，而不是沿用舊專案經驗（Actions limits 文件）。

把成本換算成「每次成功建置成本」或「每個有效歸檔成本」時，要排除被取消的重複任務，並單獨記錄失敗重試。否則表面上較便宜的方案，可能只是把失敗與人工排障成本藏在平台團隊工時裡。

若你正在評估企業 Mac 採購與遠端方案，可以先參考企業遠端 Mac 方案的地區與交付選項。如果團隊已鎖定特定 Apple Silicon 機型，也可查看Mac mini M4 遠端訂購方案，再把可用地域、交付方式與測試週期放入同一份容量模型。實際節點能力、租用週期、地域與交付條件，應以 KVMNODE 當日可核實的方案頁及 PoC 結果為準，不應在預算表中預填未確認的固定價格。

放量採購前，至少按以下步驟執行：

1. 匯出一段完整週期的 CI 記錄，按 PR、測試、歸檔及發布分類。
2. 計算每類任務的到達率、執行時間、峰值並發與失敗重試。
3. 用同一專案執行乾淨建置、增量建置、並行測試、歸檔和簽名基線。
4. 分別測試共享池、專用簽名池及彈性節點，不要只測單一成功案例。
5. 模擬節點重啟、快取失效、環境重建、憑證不可用與網路中斷。
6. 觀察擴容後隊列是否下降，並驗證任務能否回退到固定池。
7. 將結果寫成通過、限期整改、增加彈性節點或暫緩採購的明確結論。

GitHub-hosted Runner 的使用量與計費資料也應納入同一份驗收報告（Billing and usage 文件）。不要用「節點已註冊」或「工作偶爾成功」作為生產准入條件。

如果固定 Mac 池已承擔全天候基礎負載，而發布高峰使隊列突然拉長，遠端 Mac 彈性擴容通常比一次購買大量設備更容易試點。但自有固定節點在長期穩定重載、嚴格私網依賴和低延遲簽名工作上仍有優勢；遠端方案並非所有企業都適合。

FAQ 已整理 Xcode 27 是否需要 Apple Silicon、iOS CI 並發計算、Mac 打包伺服器峰值擴容、Apple Silicon 節點規劃，以及遠端 Mac 是否能處理排隊。若你要進一步做企業 PoC，建議先把基礎負載、峰值並發、簽名隔離、回退路徑與驗收記錄整理成同一份需求表，再向 KVMNODE 核對可交付的節點條件。

當前方案若只依賴單一自有 Mac，常見缺點是閒置容量由你承擔、發布高峰難以快速補機，而且硬體故障、憑證隔離與維護時間都會直接影響 CI。若完全依賴托管 Runner，則可能受計費規則、Runner 可用性、私有網路連線及環境重建時間限制。對需要短期遷移、峰值擴容或災備節點的團隊，租用 KVMNODE 的遠端 Mac 先做容量 PoC，通常比立即鎖定長期設備採購更容易驗證；但長期固定重載或需要實體介面的工作，仍應保留自有 Mac 池。