2026年租用裸金属远程 Mac 做 iOS CI/CD：
自托管 Runner、构建队列与 1TB/2TB 缓存规划

很多团队第一次上远程 Mac CI，会把失败简单归因到「机器不够快」。但在 Apple Silicon 上，真正决定体验分布的往往是资源独占程度、缓存是否可复用、以及 Runner 进程模型是否与 Xcode 的并发假设匹配。裸金属的价值在于把「邻居干扰」从变量里拿掉，但你仍需要把下列痛点逐条写进评审材料，否则预算会花在错误档位上。

• 缓存雪崩：多台 Runner 若各自冷启动 DerivedData，会把编译时间拉长到不可接受的尾延迟；没有磁盘预算时，缓存还会被系统清理策略误伤。
• 签名上下文漂移：钥匙串、描述文件、团队 ID 与机器绑定策略不一致时，失败会表现为随机 redacted error，难以用日志对比。
• 制品跨区：仓库与 npm 源、容器 registry、内网制品库若与 Runner 不在同一地理与网络路径上，拉取阶段会吃掉大量 wall time。
• 单节点多 Job 的内存护栏：并行跑 UI 测与编译时，M4 16GB 更容易触发内存压力与换页，从而把「偶发慢」变成「每天固定时段慢」。
• 队列策略缺失：没有 label 与并发上限时，重型任务会插队，导致轻量 PR 检查失去「几分钟反馈」的意义。
• 运维边界不清：自托管 Runner 需要有人对 macOS 升级、Xcode 多版本并存、磁盘水位与日志轮转负责；否则会出现「流水线能跑但不稳定」。

结论先行：先定缓存与制品同区，再定 Runner 数量与租期组合。否则你会用更高配掩盖结构性问题。

下面矩阵用于评审会对齐：它不是替你做最终答案，而是把「并发模型」与「内存/磁盘」绑定起来，便于把预算拆到正确维度。若你们以 PR 检查为主、Archive 为辅，通常会更偏向队列化与缓存复用；若以夜间大批量 UI 测为主，则更偏向高配与磁盘余量。

当你把矩阵落到 CALMVPS 的产品结构时，重点不是「买最贵」，而是让节点区域覆盖与配置梯度覆盖同一套决策链：亚太与美东美西都有节点时，更容易把制品与 Runner 放在同一大洲内；需要把重任务临时并行时，再用并联资源把队列宽度拉开，而不是把单台机器推到极限。

自托管 Runner 的工程化核心，是把「可复用资产」与「不可复用机密」分层管理。缓存层应尽量共享且可重建；签名层必须可审计且最小权限；网络层则应尽量让 Runner 到制品库的路径短且稳定。下面给出一条常用的目录规划思路：把 DerivedData 与自定义缓存根放到独立分区或大目录上，并在流水线里显式传入 -derivedDataPath 或等价封装，避免默认目录在系统升级后被清理策略影响。

GitHub Actions 自托管 Runner 的概念模型与限制应以官方文档为准。发版后请再次打开链接核对标题与条款。

https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners

若你们使用其它 CI 控制器，仍建议把「Runner 进程生命周期」与「Xcode 会话生命周期」拆开思考：Runner 负责拉代码与上报；Xcode 负责编译与测试；两者之间的环境变量、钥匙串解锁时机与并行上限必须在同一页 runbook 里写清。

export RUNNER_ALLOW_RUNASROOT=0
defaults read com.apple.dt.Xcode.plist
df -h
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
xcodebuild -showsdks

这组命令的价值是值班时能快速判断「慢来自磁盘水位」还是「来自 SDK 选择错误」。在远程裸金属上，磁盘写放大往往来自日志、测试产物与索引文件；因此把水位阈值写进告警比单纯扩容更重要，否则 2TB 也会被无轮转日志吃光。

制品同区还意味着：如果你的源码托管在某一云厂商的 Git 服务，而内网制品库在另一区域，Runner 应该优先选能把两段延迟同时压低的落点。CALMVPS 提供多区域节点时，你可以用「同一大洲优先」作为第一性原则，再用 远程桌面与排障页面里的接入方式完成人工验收与 UI 复核，而不是把 VNC 只当成临时救急通道。

下面清单假设你已获得 SSH 管理入口，并且目标是在裸金属上长期运行自托管 Runner。每一步都应留下可审计输出，便于后续把环境从 A 区域迁移到 B 区域时复用。

1. 冻结基线：记录 macOS 版本、Xcode 版本、Swift 工具链版本与 Runner 版本，形成变更单的「前后对比字段」。
2. 创建专用账户：Runner 与人工排障账户分离，降低钥匙串与 Token 泄露面；同时把 sudo 边界写清。
3. 磁盘分区策略：为 DerivedData、测试产物与日志分配独立目录或大容量挂载点；把清理策略写成定时任务或流水线步骤。
4. 安装与注册 Runner：按平台官方流程注册到对应仓库或组织；为不同队列配置 label，避免重任务插队。
5. 签名与描述文件注入：把「哪些密钥允许在 CI 使用」与「哪些必须禁止导出」写成表格，避免用同一台机器同时承担开发与发布。
6. 最小流水线验证：先跑编译与单元测试，再逐步打开 UI 测与 Archive；每一步记录 p95 与 p99 耗时。
7. 上线告警：磁盘水位、Runner offline、队列堆积与失败率突增要进同一套值班入口；并把扩容触发条件对齐到 定价页可采购的档位与租期。

第七步的关键是把扩容变成可采购动作：当队列堆积持续超过阈值时，优先增加并行节点或短租并联资源，而不是无限提高单节点并发，否则你会把不稳定写进尾延迟分布。

• 自托管 Runner 的软件边界：GitHub 文档明确自托管 Runner 可用于私有仓库自动化，但对机器管理与安全补丁责任在组织侧；这意味着你必须把 macOS 升级与 Xcode 升级纳入同一套变更窗口。
• Xcode 缓存路径的工程语义：Apple 开发者文档对 DerivedData 与相关数据位置有说明；把它写进 runbook 能减少「换机后缓存丢失」导致的不可解释变慢。
• Apple Silicon 统一内存模型的约束：Apple 平台文档将 Apple Silicon 描述为统一内存架构；在 CI 场景里，它更直接地转化为「并行峰值内存压力会同时影响编译与 UI 测」的耦合关系，因此档位选择必须与并发模型绑定评审。

Apple 平台技术说明请以 Apple 开发者网站为准。

https://developer.apple.com/documentation/

把三条门槛写进变更单的意义在于：它们能把讨论从「感觉慢」拉回到「可验证资源边界」。

脉冲型构建团队常见结构是：平时用较低并发完成 PR 检查，发版周把夜间批量测与 Archive 并行化。此时成本护栏应同时包含「队列宽度」和「磁盘保留周期」：短租并联资源负责扩宽度，月租或季租负责稳定 Hub 与缓存热集合；1TB 与 2TB 扩容则决定你能保留多少历史 Xcode 版本与多少套 DerivedData 以便回滚对比。

FAQ：M4 16GB 能不能跑 UI 测？ 可以，但建议把 UI 测与重编译错峰，或拆队列到不同节点；否则尾延迟会被内存压力放大。

FAQ：为什么裸金属比「看起来便宜的共享环境」更适合生产 CI？ 生产 CI 的关键是尾延迟与可重复性；独占 CPU 与稳定磁盘更容易把失败归因到代码与配置，而不是平台邻居干扰。

FAQ：日租/周租适合解决什么问题？ 适合验证新 Xcode 版本、临时扩容峰值、以及跨区域对比构建耗时；验证结束后再决定是否转入月租或季租锁住环境。

分时虚拟化与超卖环境的主要风险是尾延迟与资源争抢，且更难把问题定位到单一变量；家庭宽带与非专业机房则常见上行抖动与睡眠策略导致的离线。需要把 iOS CI 当成稳定生产面时，CALMVPS 的 Mac Mini 云端裸金属租赁更容易把「节点区域、配置梯度、并联资源价格」对齐到同一套采购与扩容语言里：独占 Apple Silicon、7×24 在线、按月弹性下单，120 秒交付。请打开 CALMVPS 定价页对照目标区域与档位，并把队列与缓存策略一并写进评审附件。