一個可直接影響成本判斷的基準是：GitHub 官方目前列出的標準 macOS Runner 費率為每分鐘 0.062 美元，macOS arm64 M2 Pro 的大型 Runner 為每分鐘 0.102 美元；每個工作階段不足一分鐘的部分，會進位到完整分鐘計算。GitHub Actions Runner 計費文件
因此，低頻、波動大、沒有固定環境依賴的建置，優先使用 GitHub 託管 Runner；穩定高負載、需要私有網路、持久快取或固定簽署環境的任務，則適合自託管遠端 Mac。多數企業不應二選一，而應讓託管 Runner 承接彈性任務，自託管 Runner 承接受控的生產任務。
這篇文章適合以下讀者：
- 管理多個 iOS 專案，正在控制 GitHub Actions 用量與建置排隊時間的平台負責人。
- 需要讓建置任務存取私有依賴、簽署憑證或企業內部網路的 IT 與安全負責人。
- 正在評估購買、託管或租用 Mac 建置節點的 CTO、技術總監與採購決策者。
[ SECTION_01 ] 先用工作負載畫出 Runner 邊界
GitHub Actions macOS Runner 選型不應從「哪一種 Runner 比較快」開始，而應先統計工作負載。建議至少連續記錄兩週，包含每月建置分鐘數、尖峰併發數、任務波動、私有網路需求、Xcode 固定版本與快取依賴。
以下指標能先排除一部分錯誤選擇：
- 建置頻率低、尖峰明顯：託管 Runner 通常較容易吸收波動，不必長期保留閒置硬體。
- 建置量穩定且每日持續執行：自託管節點可以把固定資源轉為可預測的週期成本。
- 需要私有套件庫、內部 API 或 VPN：應優先評估自託管遠端 Mac，或確認託管大型 Runner 是否符合企業網路邊界。
- 需要固定 Xcode、SDK、系統設定或簽署環境：持久節點通常比每次重新初始化的臨時環境更容易驗證。
- 需要大量短時間併發：託管 Runner 的彈性通常較有利，但仍須檢查方案的併發上限與實際排隊狀況。
GitHub 官方文件指出，大型 macOS Runner 以虛擬機形式執行；目前列出的 macOS 大型規格包含 Intel 12 核心、30 GB 記憶體，以及 arm64 M2、5 核心加硬體加速、14 GB 記憶體等選項。macOS 大型 Runner 規格
[ SECTION_02 ] 成本不是每分鐘費率，而是完整 TCO
託管 Runner 的表面成本容易計算，但企業比較時不能只把「每分鐘費率 × 建置分鐘」當成總成本。自託管側還要計入硬體或租用資源、閒置容量、初始設定、macOS 更新、Runner 軟體更新、故障處理與維運工時。
託管 Runner 的成本公式
月成本 =
可計費建置分鐘 × Runner 每分鐘費率
+ 額外併發或方案費用
+ 重複安裝工具鏈的時間成本
+ 快取失效造成的額外建置時間
GitHub 官方文件說明，工作階段會按使用時間計費，且大型 Runner 只有在工作流程實際執行時收費；未使用的 Runner 不會因建立資源本身而產生同類使用費。Actions Runner pricing
自託管 Runner 的成本公式
月成本 =
Mac 資源週期費用
+ 閒置容量成本
+ 初始化與工具鏈安裝工時
+ macOS、Xcode、Runner 更新工時
+ 監控、備份、故障處理與替換成本
+ 私有網路與安全控制成本
企業應把每項變數填入同一份試算表，而不是用購買價格對比單月建置費。若一台節點每天只執行少量任務，閒置時間就是自託管方案的隱性成本；若節點長期高負載，託管 Runner 的每分鐘費率則可能成為主要支出。
GitHub 每個工作階段的不足一分鐘部分會進位，因此大量短工作階段、重複安裝依賴與快取命中率偏低，都可能放大託管成本。
[ SECTION_03 ] 吞吐量要看排隊、初始化與快取
單次建置時間不是完整吞吐指標。平台負責人更應觀察以下四項：
- 工作進入佇列後，到 Runner 真正接手的等待時間。
- 啟動後安裝 Xcode 工具、套件與 CocoaPods 依賴所需的時間。
- 建置快取的命中率，以及快取失效後的重建時間。
- 尖峰時段能否平行處理多個 Pull Request 與正式發佈工作。
託管 Runner 的優點是可以把資源彈性拉高，適合短時間大量 Pull Request 或版本發佈。但大型 macOS Runner 的資源池可能較小，首次建立虛擬機時也可能增加指派佇列時間；資源使用後，後續工作階段才較可能受益於保溫資源。
自託管遠端 Mac 則可以保留工具鏈與專案快取，減少重複初始化。不過節點數量不足時，所有專案會排在同一組資源後面；節點故障、磁碟空間不足或 Xcode 更新失敗，也會直接影響吞吐。
建議採用同一個專案、同一個 Xcode 版本、同一套建置步驟，分別執行冷快取與熱快取測試。不要拿不同專案、不同 SDK 或不同簽署流程的結果直接比較。穩定高負載可交給自託管節點；突發任務則回退至託管 Runner。
[ SECTION_04 ] Apple Silicon 與工具鏈相容性需要逐項驗證
Apple Silicon 不代表所有 Action、腳本與二進位工具都已經完全相容。GitHub 官方表示，GitHub 提供的 Action 可在 arm64 託管 Runner 上使用，但社群 Action 可能仍需要在工作階段中手動安裝或調整。
企業檢查時應分成三層：
- 平台層：確認
runs-on標籤、macOS 映像、Apple Silicon 架構與 Xcode 版本。 - Action 層：檢查第三方 Action 是否包含 arm64 可執行檔，並以目標專案實測，不把社群相容性當成平台保證。
- 專案層：確認 Ruby、Node.js、CocoaPods、Swift Package Manager、私有 SDK 與簽署腳本是否依賴特定路徑或系統設定。
若團隊需要固定 Xcode、冷門 SDK、內部工具鏈、長期保留的 Derived Data 或自訂系統設定，自託管環境通常更容易建立可重現的基線。若只是執行標準測試、封裝與上傳流程，託管 Runner 的環境更新反而能減少自行維護的負擔。
還有一項容易被忽略的限制：GitHub 文件指出，arm64 macOS Runner 沒有靜態 UUID/UDID；Intel macOS Runner 則提供固定 UDID。若簽署流程依賴固定 UDID，必須在採購前驗證 Apple Developer 設定與建置流程，不能只看 CPU 架構。Runner UDID 與簽署限制
[ SECTION_05 ] 私有網路與簽署憑證決定安全邊界
自託管 Runner 的最大優勢是網路與環境控制，最大風險也是持久環境會保留更多權限與工作痕跡。GitHub 官方建議自託管 Runner 優先用於私有儲存庫，因為公開儲存庫的 Fork 可能透過 Pull Request 觸發危險程式碼，在主機上執行未預期操作。自託管 Runner 安全警告
企業至少應完成以下控制：
- 把生產簽署節點放進專用 Runner Group，不與一般測試專案共用。
- 只允許指定儲存庫與指定 reusable workflow 使用該群組。
- 不讓公開儲存庫或未受信任 Pull Request 直接進入持久自託管主機。
- 將 App Store Connect、簽署憑證與私有套件庫憑證分開管理，採最小權限與定期輪換。
- 工作完成後清理暫存檔、Derived Data、日誌中的 Token 與匯出封裝檔。
- 監控 Runner 在線狀態、工作失敗率、磁碟容量、macOS 更新狀態與異常網路連線。
Runner Group 可限制哪些組織、儲存庫與工作流程使用特定 Runner，也能設定併發限制來控制容量與成本。Runner Group 權限與併發控制
自託管 Runner 本身也必須持續連線至 GitHub，並能透過 HTTPS 443 埠進行通訊。官方文件列出，主機至少需要具備每秒 70 kilobits 的上傳與下載頻寬，以及對指定 GitHub 網域的連線能力。自託管 Runner 通訊要求
安全提醒： 自託管 Runner 不應無條件接受公共儲存庫或不受信任 Pull Request 的工作流程。即使程式碼未直接存取秘密，主機上的環境變數、快取、檔案系統與網路權限仍可能成為攻擊面。
[ SECTION_06 ] 第一步：建立兩週工作負載資料
先從 GitHub Actions 匯出兩週資料，至少填入：
- 每個專案的建置分鐘數。
- 每小時最大併發數。
- 平均排隊時間與 P95 排隊時間。
- 冷快取、熱快取的建置時間。
- 是否需要私有套件庫、VPN、內部 API。
- 是否需要固定 Xcode、固定 UDID 或持久簽署環境。
不要先購買 Mac，再反過來尋找使用場景。先確認哪一類工作會長期佔用節點，才能避免以少量建置需求支撐一台長期閒置的主機。
[ SECTION_07 ] 第二步：把工作流程拆成三類
建議將 iOS CI/CD 工作分成：
- 一般 Pull Request 驗證：測試、Lint、基本編譯。這類任務通常適合託管 Runner。
- 固定環境建置：指定 Xcode、私有 SDK、內部 API 或企業簽署。這類任務適合自託管遠端 Mac。
- 正式發佈與高峰任務：需要固定簽署，但可能在版本發佈時突然增加。適合採混合架構，由自託管節點處理生產流程，託管 Runner 吸收非敏感的彈性工作。
[ SECTION_08 ] 第三步：建立 Runner Group 與標籤策略
不要只用 macos-latest 做所有路由。可按用途建立例如：
runs-on: [self-hosted, macos, ios-production]
再把測試、簽署與發佈工作分到不同群組。GitHub 文件支援透過群組與標籤指定工作所需的 Runner，並可對群組設定儲存庫存取政策。使用標籤與群組指定 Runner
[ SECTION_09 ] 第四步：以相同專案做基準測試
固定以下條件：
- 相同 Commit。
- 相同 Xcode 與 SDK。
- 相同依賴鎖定檔。
- 相同簽署步驟。
- 分開記錄冷快取與熱快取。
- 至少觀察正常時段與尖峰時段。
最後比較的不是單次最快時間，而是平均建置時間、P95 建置時間、排隊時間、失敗重試率與每次成功建置的實際成本。
[ SECTION_10 ] 第五步：設定故障回退與容量警戒線
混合部署不等於把兩套環境隨意並排。應在工作流程中明確區分：
- 生產簽署失敗時，不自動把秘密工作流程轉到一般託管 Runner。
- 一般測試佇列超過警戒值時，才將非敏感任務轉送託管 Runner。
- 自託管節點離線時，通知平台值班人員並啟用備援節點。
- Xcode 或 macOS 更新前，先複製建置基線並完成回歸測試。
- 每個節點保留外部日誌，避免主機故障後無法追查。
自託管 Runner 可設定為服務，在主機啟動時自動執行；但更新、監控與故障處理仍由企業或其基礎設施供應方負責。自託管 Runner 管理方式
[ SECTION_11 ] 三種方案的決策評分
以下評分不是平台保證，而是依企業常見工作負載建立的選型工具。評分越高，代表該方案在該維度越有利；實際結果仍應以同一專案的基準測試為準。
| 決策維度 | GitHub 託管 Runner | 自託管遠端 Mac | 混合部署 |
|---|---|---|---|
| 低頻與突發任務 | 5/5 | 2/5 | 5/5 |
| 固定 Xcode 與持久快取 | 2/5 | 5/5 | 5/5 |
| 私有網路與內部依賴 | 2-3/5，視方案而定 | 5/5 | 5/5 |
| 尖峰擴容 | 5/5 | 3/5 | 5/5 |
| 初期導入速度 | 5/5 | 3/5 | 4/5 |
| 維運責任 | 5/5，企業負擔較低 | 2/5 | 3/5 |
| 簽署環境控制 | 2-3/5 | 5/5 | 5/5 |
[ SECTION_12 ] TCO 填寫表：不要先假設哪邊更便宜
下表只提供計算口徑。企業應將實際 GitHub 帳單、Runner 使用分鐘、Mac 資源週期費用與維運工時填入，不應使用未核實的節省比例。
| 成本項目 | 託管 Runner 填寫欄 | 自託管遠端 Mac 填寫欄 |
|---|---|---|
| 每月建置分鐘 | 月建置分鐘 × 官方費率 | 分配至節點的實際使用分鐘 |
| 閒置容量 | 通常反映在工作流程使用量與併發需求 | 節點未執行工作時的週期成本 |
| 初始化成本 | 工具重裝、依賴下載、快取失效時間 | 初次設定、Xcode 與憑證初始化工時 |
| 網路成本 | 私有依賴存取與額外網路需求 | VPN、Firewall、私有網段與出口設定 |
| 維運成本 | 工作流程與權限管理 | macOS、Runner、磁碟、監控與故障處理 |
| TCO 公式 | 建置費 + 併發與重複初始化成本 | 資源費 + 閒置費 + 維運工時 + 故障成本 |
GitHub 官方目前列出的參考費率包括標準 macOS 3 或 4 核心 Runner 每分鐘 0.062 美元，macOS 5 核心 M2 Pro 大型 Runner 每分鐘 0.102 美元。費率、映像與方案可能調整，正式採購前應再次核對官方頁面與企業帳單。官方 Runner 費率表
[ SECTION_13 ] 企業採購與架構決策矩陣
| 工作負載狀態 | 優先方案 | 主要理由 | 需要先驗證的風險 |
|---|---|---|---|
| 低頻、小團隊、任務波動大 | GitHub 託管 Runner | 不必長期保留閒置 Mac，導入速度快 | 併發上限、每月分鐘數、工具初始化時間 |
| 穩定生產建置、固定 Xcode | 自託管遠端 Mac | 可保留環境、快取與簽署流程 | 節點故障、更新、備援與憑證隔離 |
| 多專案、尖峰明顯、同時需要私有網路 | 混合部署 | 將敏感固定任務與彈性任務分流 | 路由規則、Runner Group、回退權限 |
| 需要固定 UDID 的簽署流程 | 先驗證 Intel 或受控自託管節點 | arm64 Runner 可能沒有靜態 UDID | Apple Developer 設定與實際簽署測試 |
| 公開儲存庫或不受信任 PR | 不使用持久自託管 Runner | 避免工作流程在敏感主機執行危險程式碼 | Fork、秘密、快取與主機權限 |
當前方案若只依賴 GitHub 託管 Runner，常見缺點是固定環境控制較弱、私有網路整合需要額外確認，且大量穩定建置會持續累積按分鐘計費。若自行購買 Mac，則又會承擔硬體折舊、閒置容量、故障替換與值班維運。對需要臨時擴充、驗證 Apple Silicon、建立固定 Xcode 節點或測試混合架構的團隊，NOVAKVM 的遠端 Mac 可作為受控自託管節點，讓團隊先以週期性資源驗證容量，而不必立即把硬體採購與長期維護綁在一起。正式評估可先參考 NOVAKVM 遠端 Mac 方案 與 NOVAKVM 香港節點選擇。
建議平台負責人先用本文工作負載表統計兩週資料，再依固定 Xcode、持久快取、私有網路與尖峰併發四項條件作判斷。若生產任務確實需要受控環境，下一步應是建立遠端 Mac 建置節點的容量與故障回復方案；若只是低頻、波動明顯的測試工作，則維持 GitHub 託管 Runner，避免為閒置資源支付長期成本。