在 X 平台上，一段关于在数据中心部署数百台 MacBook Pro 的视频引发热议。乍看之下令人震惊，但对于云基础设施提供商 Namespace 而言，这是在 Apple 供应链混乱背景下的合理选择。
Namespace 近日分享了构建定制化 Mac 机柜的技术细节，展示了如何实现秒级启动 macOS 实例，并在 Apple 发布新版 Xcode 后数小时内完成更新交付。
为何选择 MacBook？
核心驱动力在于客户需求与供应链现实。iOS 应用的构建与测试必须依赖 Mac 环境，且 Apple 要求使用最新版 Xcode 才能发布应用至 App Store。尽管 Mac Mini 理论上更适合数据中心，但其远程管理功能基础、缺乏冗余电源且散热设计受限。
更关键的是供应链瓶颈。Namespace 曾尝试订购数百台 Mac Mini，却面临“一月下单、七月交货”的漫长等待。此外，Apple 并未同步向所有设备推送最新 CPU 型号，Mac Mini 曾长达 10 个月未获得 M5 芯片更新。为确保客户能获得最新算力，Namespace 启动了“MacBook-in-Datacenter”项目。
定制化机柜与挑战
每台 MacBook 均连接 IP KVM 进行远程管理，以应对笔记本固件对图形界面的依赖。同时，每台设备配备外部 10G 以太网网卡以确保连接速度。机柜布线极为复杂，每台笔记本连接四条线缆，加之严格的散热管理，团队设计了定制支架以引导热空气远离相邻设备。
实际部署中遭遇了意想不到的硬件挑战。相比 MagSafe 电源接口，HDMI 线缆因厚重且不灵活，极易在触碰机架时脱落，团队最终通过买断特定型号库存解决了这一问题。软件层面，FileVault 磁盘加密在非计划重启后会要求输入密码，若五分钟内无操作提示将消失，迫使运维人员物理重启并争分夺秒解锁。此外，部分外部 USB 网卡会出现假死状态，需重置网络服务才能恢复。
虚拟化架构与限制
Namespace 的底层实例由虚拟机支持，集成多种引擎以运行 Linux、Windows 和 Mac。Mac 解决方案基于 Apple Virtualization 框架，该框架类似 Firecracker，能端到端实现通用 VM 操作。
然而，Apple 限制每台物理 Mac 仅能运行两个 macOS VM，无论硬件配置多高。这意味着在 14 核 Mac Mini 上只能运行 6 或 12 核实例，在 18 核 MacBook 上运行 8 或 16 核实例，其余核心用于管理开销。此外，虚拟 CPU 由独立的 VMM 进程执行，与主机进程的每次交互均涉及 IPC（进程间通信）往返，这在系统设计中必须被纳入考量。
在网络方面，为隔离不受信任的代码，Namespace 基于 Google gVisor 项目构建了用户空间 TCP/IP 栈，以实现精细的流量控制。尽管涉及 IPC 开销，MacOS 实例仍能达到 4 Gbps 的上行带宽。
镜像构建与分发优化
随着 iOS 运行时和 Xcode 版本的迭代，单个 VM 镜像体积可膨胀至 500 GB 甚至更大。为解决数百台机器间的镜像存储与分发难题，Namespace 采取了多项优化措施：
首先，构建过程完全自动化，通过 YAML 工作流驱动，确保镜像生成的可重复性。其次，开发了一种保留“稀疏性”的存储格式，未分配的数据跨度仅占用极少字节。同时，利用镜像间的相似性，采用分层存储策略，基础层共享，后续层仅存储修改块。
在分发环节，为避免从中央注册表下载产生的巨大网络压力，Namespace 采用了类似 BitTorrent 的 P2P 交付机制。节点间相互传输数据块，实现机队的指数级快速填充。在本地存储上，利用 APFS 文件系统的稀疏文件和克隆（clonefile）特性，进一步节省磁盘空间，仅在实际写入时分配物理块。
未来展望
目前，Namespace 已建立起标准化的 MacBook 机柜装配线与运维流程。团队正探索更集成的硬件方案，例如通过单根 USB-C 线缆提供电源、网络和 KVM 连接的定制设备。此外，Namespace 暗示未来可能将手机部署至数据中心，以应对更多样化的计算需求。