Apple 官方規格頁列出 Mac mini 的 M4 與 M4 Pro 配置，但規格本身不能換算成某個專案每小時可完成多少次建置。Mac mini 官方技術規格只能界定候選硬體範圍；真正的 Mac mini M4 建置機容量規劃，必須使用高峰任務到達量、各類工作的 P95 建置時間、目標排隊時間、有效利用率與故障冗餘計算。
因此，非關鍵試點先用單節點驗證；正式流水線則以基線節點加獨立冗餘，或固定節點加彈性遠端 Mac。不要按開發者人數、CPU 核心數或月平均利用率直接決定數量。
這篇適合三類讀者：
- 正在為新增 iOS 團隊編列 Mac 建置資源預算的 IT 負責人。
- 建置佇列已經影響合併或發佈效率，正要判斷擴容時機的研發效能負責人。
- 需要在固定採購、遠端租用與混合容量之間做選擇的 CTO 或技術總監。
[ SECTION_01 ] 先填好四項容量輸入，再回答要幾台
建議先從 CI 日誌整理出以下資料。每一項都要限定在高峰時段，而不是以整月平均值代替。
| 容量輸入 | 建議取值 | 資料來源 | 對決策的作用 |
|---|---|---|---|
| 峰值任務到達量 λ | 單位時間內進入佇列的任務數 | CI 排程與 Runner 日誌 | 判斷需求強度 |
| 各類任務 P95 時長 tᵢ | 代碼檢查、測試、Archive、簽署分開統計 | 原始 CI 日誌 | 避免平均值掩蓋慢任務 |
| 目標排隊時間 W | 合併驗證與發佈窗口分開設定 | 團隊 SLA | 決定可接受的容量緩衝 |
| 有效利用率 U 與冗餘 R | 由壓力測試及維護要求確定 | 企業測試、維運紀錄 | 防止節點長期滿載或單點故障 |
資料不足時，答案應是「暫不能可靠估算」，而不是先報一個主機數量。尤其要先排除依賴下載、快取失效、簽署憑證錯誤與流水線重試。若一個任務只是因腳本重複執行而變慢，增加 Mac 並不能修正根因。
一個 iOS 開發團隊需要幾台 Mac mini M4 做 CI？
不能由團隊人數直接回答。正確做法是把高峰到達量與每類工作的 P95 時長代入產能模型，再按排隊目標向上取整。小規模、非關鍵試點可以從一台開始，但該節點不應被直接視為正式發佈環境的完整容量。
[ SECTION_02 ] 第一個指標：峰值工作量，而不是開發者人數
iOS CI/CD 通常同時包含代碼檢查、單元測試、UI 測試、Archive、簽署與發佈。這些工作對 CPU、磁碟、模擬器、Keychain 及外部依賴的壓力不同。把它們混成一個「平均建置時間」，會低估發佈時段的需求。
可用以下方式換算高峰工作量：
D = Σ(λᵢ × tᵢ)
其中：
λᵢ是第i類任務在高峰期間的到達量。tᵢ是該類任務的 P95 實測時間。D是同一時間單位內需要消化的總工作量。
定時掃描、Pull Request 驗證與發佈任務重疊時，必須把重疊時段相加。不能因為某些任務在夜間執行，就從日間合併高峰的計算中刪掉；只要它們競爭同一批 Runner，就屬於同一個容量池。
提醒：月平均任務量只適合估算長期使用量，不適合判斷發佈窗口是否會排隊。容量規劃應優先採用最忙時段的連續紀錄，並把偶發尖峰與持續高峰分開標記。
[ SECTION_03 ] 第二個指標：用相同環境測出單節點有效產能
M4 與 M4 Pro 可以作為硬體候選，但不能直接推導建置吞吐。Apple 的硬體頁面沒有替企業專案保證固定的每小時建置數；專案的目標依賴、Swift 編譯、腳本、測試資料與快取狀態都會改變結果。Xcode 的目標依賴與平行建置說明也顯示，平行化受專案結構約束。
測試時應固定以下條件：
- 鎖定相同的程式碼 commit、Xcode 版本與 SDK。
- 固定依賴來源、套件版本及網路快取狀態。
- 分別執行冷建置、增量建置、測試與 Archive。
- 記錄成功任務的 P50、P95，以及失敗與重試原因。
- 連續執行多輪，分開標記首次建置與後續快取命中。
- 用另一台候選 Mac 重複相同命令，避免單一節點狀態造成誤判。
Xcode 建議的建置計時摘要方法可用來定位慢的編譯步驟。另應檢查 Xcode Build Phases 的任務構成，找出串行腳本、重複產物處理與不必要的資源複製。
如何根據建置佇列計算 Mac 建置節點數量？
先求出單節點在可接受並發下的有效產能 C_eff，再計算：
N_base = ceil(D / C_eff)
若有排隊目標，還要加入高峰緩衝：
N_required = ceil(N_base × B_queue × B_failure)
B_queue 代表排隊目標所需的容量緩衝，B_failure 代表節點維護、失聯或升級時仍要維持服務的冗餘。兩個緩衝值不能憑經驗硬填，應由壓力測試、維護窗口與發佈 SLA 共同決定。
[ SECTION_04 ] 第三個指標：排隊目標決定擴容門檻
不同任務不應共用同一個服務目標。夜間批次可以容許較長等待；Pull Request 驗證需要較短等待；發佈窗口則要優先保留可用產能。
| 工作類型 | 主要觀察值 | 容量判斷 | 適合的節點策略 |
|---|---|---|---|
| 夜間批次 | 任務是否在下一個工作時段前完成 | 偶發等待未超過目標即可 | 單節點或小型固定池 |
| 日常合併驗證 | 佇列 P95 是否持續超過團隊目標 | 連續多輪超標才觸發擴容 | 固定基線節點池 |
| 發佈與簽署 | 發佈窗口的等待、重試與故障恢復 | 必須保留獨立冗餘 | 固定節點加彈性遠端 Mac |
Mac 構建機利用率達到多少時應該擴容？
不應套用一個通用百分比。企業應先定義 U_target，再觀察高峰期間是否同時出現「利用率接近上限、佇列 P95 超標、任務重試增加」三項訊號。只有利用率高但佇列仍符合目標時，才不必立即擴容；只有某次 CPU 峰值而沒有持續排隊，也不足以支持採購決定。
[ SECTION_05 ] 第四個指標：並發槽位會折減紙面產能
Mac mini M4 能同時執行多少個 Xcode 建置任務？
沒有適用所有專案的固定答案。可接受的並發數必須透過企業自己的壓力測試取得。當多個任務共用 DerivedData、模擬器、Keychain、簽署憑證或工作區時，增加槽位可能只會讓每個任務變慢，甚至造成產物互相污染。
單機多任務與多節點單任務的差異如下：
- 單機多任務：硬體利用率可能較高，但資源競爭、清理成本與故障影響面較大。
- 多節點單任務：吞吐較容易觀測，環境隔離較清楚，但固定節點數與維運項目增加。
- 共用簽署環境：憑證暴露面與 Keychain 鎖定風險較高，不能只看 CPU 使用率。
- 共用快取：命中率可能提升，但快取失效、版本切換與回滾需要明確規則。
Runner 分組與標籤可以把特定 Xcode、簽署或發佈任務送往指定節點。GitHub Actions 自託管 Runner 的標籤與群組規則可作為調度設計參考，但標籤本身不會創造額外產能。
[ SECTION_06 ] 第五個指標：冗餘必須獨立於日常容量
基線容量是為正常高峰服務；冗餘容量則用於計劃維護、Xcode 升級、主機失聯與發佈突發量。把備用節點算入日常滿載，會讓平時看似節省，真正需要切換時卻沒有餘量。
可勾選以下驗收條件：
- [ ] 已從 CI 日誌分離合併、測試、Archive 與發佈任務。
- [ ] 每類任務都有冷建置與增量建置的 P95 時間。
- [ ] 高峰任務到達量取自實際佇列，而非開發者人數。
- [ ] 已測量單節點在不同並發槽位下的
C_eff。 - [ ] DerivedData、模擬器、Keychain 與簽署憑證有隔離方案。
- [ ] 已定義合併驗證與發佈窗口的排隊目標。
- [ ] 節點維護或失聯時，仍有可執行關鍵任務的冗餘。
- [ ] 連續觀察到排隊目標超標後，才啟動擴容審查。
- [ ] 所有容量示例都能追溯到 commit、命令、環境與原始日誌。
[ SECTION_07 ] 按成本邊界選擇固定、彈性或混合容量
企業 iOS CI 基礎設施的成本，不只有 Mac 主機費用。還包括待機節點、儲存與快取、網路傳輸、簽署環境維護、故障處理，以及開發者等待造成的工時損失。
| 方案 | 固定節點成本 | 彈性容量成本 | 故障域 | 適用條件 | 評分 |
|---|---|---|---|---|---|
| 單一固定節點 | 低至中 | 無 | 集中 | 非關鍵試點、低峰值需求 | ★★★ |
| 固定節點池 | 中至高 | 低 | 可分散 | 穩定日常流水線、持久快取 | ★★★★ |
| 固定節點加彈性遠端 Mac | 基線可控 | 隨峰值增加 | 較易分散 | 發佈高峰明顯、需求波動 | ★★★★★ |
| 全部彈性節點 | 低待機成本 | 依使用量變動 | 依供應而定 | 低頻任務、環境不需長駐 | ★★★ |
iOS CI 應增加高配 Mac，還是增加建置節點？
若瓶頸是單一任務的記憶體壓力、不可平行的腳本或單一 Archive 流程，應先評估更高配置。若瓶頸是多個獨立任務同時進入佇列，增加節點通常比把所有工作集中到一台高配 Mac 更容易隔離故障。最終仍要以相同基準任務的 C_eff 與排隊結果判斷，不能用規格表代替測試。
非關鍵試點可接受單節點；穩定日常流水線應採固定節點池；發佈關鍵型流水線則適合「固定基線＋獨立冗餘」，在峰值與日常需求差距明顯時，再接入彈性遠端 Mac。需要先取得實測資料的團隊，可參考 NOVAKVM 的 M4 遠端 Mac 方案，用同一組基準命令測量後再代入公式。
經驗判斷：若新增節點只能消除一次偶發尖峰，卻沒有改善連續觀察期內的排隊 P95，採購很可能是在替流水線缺陷買單。先修正依賴、腳本與簽署隔離，再重新計算容量。
[ SECTION_08 ] 固定採購與遠端 Mac 的實際取捨
固定採購的優點是環境長駐、快取可持久保存，且硬體位置與維護責任較明確；缺點是閒置時仍要承擔折舊、保固外維修、備機與機房資源。當發佈高峰只集中在少數時段，固定節點池可能長時間沒有充分利用。
遠端 Mac 的優點是可按需求增加容量，並把硬體失效、待機成本與部分機房管理移出團隊；限制則包括網路延遲、資料傳輸、供應地域、權限設計與供應商服務條款。若建置必須連接現場 USB、內部封閉網路或特殊硬體，單純遠端方案未必適合。
NOVAKVM 提供可透過 VNC、SSH 或網頁控制台存取的真實 Mac，並以 root 權限讓團隊自行配置 Xcode、Runner 與簽署環境。這不代表所有企業都應放棄自購；更合理的用法，是先用一台遠端 Mac 跑同一組冷建置、增量建置、測試與 Archive 基準，取得可追溯的 C_eff，再判斷固定基線與彈性容量的比例。若團隊需要比較不同地域的遠端連線條件，也可查看 NOVAKVM 的港台 M4 遠端 Mac 選項。
當前的自購方案若直接承擔峰值，常見缺點是：需要預留閒置備機、Xcode 升級時要自行安排維護窗口，並且在高峰過後仍持續承擔硬體與機房成本。全數依賴單一固定節點，也會把失聯與簽署故障集中在同一個故障域。若需求具有明顯峰谷，租用 NOVAKVM 的遠端 Mac 作為基準測試或彈性節點，通常比一開始就購買足以覆蓋最高峰值的固定數量更容易控制風險；但長期穩定重負載或需要實體介面的團隊，仍應保留自購或混合架構的選項。