2026 GitHub Actions iOS 並行建置要幾台 Mac？按團隊規模估算

GitHub 的工作流工作 API 會提供工作項目的 queued_at、started_at 與 completed_at 時間戳記，可用來分辨排隊時間與執行時間（工作流工作 API 欄位說明）。沒有適用所有團隊的固定 Mac 台數：先從 Actions 記錄目標時段的同時執行數、排隊時間與節點占用時長，再按可接受的等待目標估算並發槽位；小批試運行確認有效後才擴容，避免把短暫高峰變成長期閒置容量。

小型 iOS 團隊：希望判斷目前排隊是否值得增加 Mac 執行節點。
多儲存庫團隊：需要按專案或工作流分配 macOS CI 並發。
平台負責人：想用可複核的資料規劃自我管理 Runner 數量。

個人專案：先確認排隊是偶發還是持續瓶頸

個人專案的短暫排隊，可能只是多個工作流剛好同時觸發；若只根據一次慢建置增加 Mac Runner，容易在大部分時段留下閒置節點。應先挑一段能代表平常開發節奏的觀察期間，記下每個工作流的觸發時間、開始執行時間、完成時間，以及所使用 Runner 的標籤或群組。

用工作項目的 started_at 減去 queued_at，可整理等待時間；以 completed_at 減去 started_at，可整理工作項目占用執行資源的時間。這些計算是估算方法，不是 GitHub 對建置容量或等待時間的承諾。若排隊只集中在提交、合併或發布時段，應優先評估高峰容量或排程；若不同時段都持續排隊，再檢查可用 Runner 是否不足。

注意：工作流「執行時間」不一定等於 Mac 忙碌時間。工作流可能在工作項目之間等待相依任務，也可能包含非建置步驟；估算時要以實際占用 Runner 的工作項目為準。

小型團隊：用可接受等待時間換算並發槽位

團隊人數不是 Runner 數量的替代指標。多人若分散提交，工作流可能不重疊；人數較少的團隊若常在合併或發布時集中觸發測試，也可能短時間出現隊列。較可靠的做法，是整理團隊常見觸發時段內同時等待及執行的工作項目，並先約定可接受的等待目標，再比較現有槽位能否承接。

如何由排隊時間估算 Mac Runner 數量？

把每個工作項目的排隊、執行及觸發資料放在同一時間軸，找出等待反覆出現的時段。估算時，可用「目標時段內需要執行的工作量」與「每個 Runner 可提供的有效工作時間」形成容量區間；工作量要按實際工作項目占用時間計算，而非只看完整工作流從開始到結束的總時長。

這套方法不應被解讀成精確預測。若採樣期間缺少發布高峰，結果可能低估容量；若恰好包含大量失敗重試，則可能高估常態需求。將高峰工作流與一般工作流分開計算，再用等待目標檢查不同容量下的隊列變化，比直接把平均值當成固定配置更穩妥。

想要取得可複核的資料，可以透過 GitHub 的自我管理 Runner 監控與疑難排解說明，檢查 Runner 是否在線、工作是否持續分派，以及是否存在執行端問題。若工作流含有併發控制，還要確認設定是否主動限制同時執行的工作；GitHub 的工作流併發設定文件說明了相關控制方式。受限制的工作即使有空閒 Mac，也可能仍在等待。

多儲存庫團隊：先拆工作負載，再設共享池

多個 iOS 儲存庫共用 Runner 時，不能只把所有工作流的執行時長加總。單元測試、完整建置與發布流程可能有不同的資源占用、相依步驟和觸發密度；若發布工作與日常測試互相擠占，單看總利用率會掩蓋真正的排隊來源。應先按工作流類型和儲存庫整理資料，再判斷是否需要分流。

共享 Runner 組方便集中管理和路由，但必須確認工作流選擇的群組與標籤符合預期；隔離專案則有助於區分責任與容量，卻可能讓某些節點在其他專案排隊時仍然閒置。GitHub 官方文件說明了Runner 組的管理與存取方式，而自我管理 Runner 的選擇規則可用於核對工作流如何指定可用執行環境。不要把團隊估算直接當成平台配額，也不要假設不同儲存庫的 Runner 一定能互相接手。

團隊有多個 iOS 儲存庫時怎麼分配 macOS CI 並發？

先區分不可延後的發布任務與可排程的測試，再檢查工作流是否因群組、標籤或相依條件被固定導向特定 Runner。若測試和發布都能使用同一共享池，可比較集中分派的隊列與專案隔離後的等待情況；若有存取權限、憑證或環境隔離要求，則應先滿足這些限制，再以觀察到的高峰需求安排容量。

工作流設定也會影響結果。GitHub 的工作流語法文件可協助核對工作項目、相依關係與 Runner 指定方式。若容量看似足夠卻仍有工作項目長時間排隊，先確認工作流是否被併發規則限制，以及所需標籤是否與實際 Runner 一致。

容量估算與試運行：用檢查清單驗證擴容

Runner 應按平均工作流還是高峰並發配置？

平均工作量適合用來估算長期資源占用，但不能單獨回答高峰等待問題。高峰並發適合檢查特定時段的隊列壓力，卻不應直接變成全天常駐容量。對需要穩定等待時間的團隊，可同時保留常態需求與高峰需求兩種估算，再按等待目標和節點閒置情況決定容量區間。

如何判斷排隊來自 Runner 數量還是建置步驟？

如果工作項目尚未開始，應先檢查 Runner 是否在線、是否符合指定標籤、是否被群組路由，以及工作流是否受併發規則或相依工作限制。如果工作項目已開始但耗時增加，則要分析建置、測試、依賴安裝、快取命中和重試等步驟。增加節點不能縮短單一工作項目內部的串行步驟，也不能修正錯誤的路由設定。

擴容前後應使用相同的工作流範圍與相近的觀察條件，比較排隊時間、Runner 忙碌情況及失敗或重試狀況。若增加容量後隊列沒有改善，先查路由標籤、工作流相依關係和串行步驟，不要直接繼續增加 Mac。

• [ ] 按工作流類型和儲存庫整理觸發、開始與完成時間。
• [ ] 區分等待 Runner 的時間與 Runner 實際執行工作項目的時間。
• [ ] 標記提交、合併、測試及發布時段，避免用平均數掩蓋高峰。
• [ ] 核對 Runner 群組、標籤、在線狀態及併發控制設定。
• [ ] 設定可接受的排隊目標，並記錄擴容前的等待與失敗情況。
• [ ] 先試行有限的新增容量，再以相同口徑比較結果。
• [ ] 確認等待改善後才調整常態容量；若沒有改善，先修正工作流或路由。

模型 API 用量成本與 Mac 建置資源成本應分開核算：前者取決於模型呼叫，後者取決於 Runner 占用、運行方式及所需容量，混算會讓擴容判斷失真。容量估算不需要假設每個工作流都同樣耗時，也不應把快取命中率視為固定值；快取狀態、任務組成與異常重試都可能改變觀察結果。

團隊型態	優先觀察資料	容量判斷重點
個人專案	觸發是否集中、排隊是否反覆發生	區分偶發高峰與跨時段持續等待
小型團隊	合併與發布時的重疊工作流	依可接受等待目標估算高峰槽位
多儲存庫團隊	各工作流占用、路由與相依關係	比較共享池和隔離配置的隊列及閒置情況

觀察結果	優先檢查	下一步
工作項目尚未開始且持續排隊	Runner 狀態、標籤、群組及併發設定	修正路由或小批增加槽位，再比較等待
工作項目已開始但執行變慢	建置步驟、快取、重試及相依任務	找出耗時步驟，避免以加 Runner 取代效能排查
擴容後等待沒有改善	工作流限制、串行步驟及工作項目分派	暫停擴容，先排除設定與流程瓶頸

在本機或既有 CI 環境中維持現有方案，可能遇到高峰時資源不足、共享主機難以隔離，以及自行維護 Runner 環境的管理負擔；但若工作負載長期穩定且繁重，或必須直接連接特定實體介面，租用也未必合適。先完成自己的 Actions 容量估算，再按實際需求核對 Mac mini 租用選項與價格資訊；若只是需要可調整的遠端 Mac 測試或建置環境，可再評估 Zutcloud 的租用方案，並以頁面可核實的配置與交付說明為準。