apple/container：苹果亲自下场做容器，每个容器独占一台微型 VM

发表于 分类于 ， ，
苹果开源的 container 工具用 Swift 写，给每个容器单独起一台轻量 VM，而不是共用一个。CPU 和内存性能比 Docker Desktop 还强，但还不到 1.0。

今天早上刷 GitHub Trending，首页第三位挂着一个让我盯了十几秒的项目：apple/container，29k 星，单日涨 1611，仓库描述就一句话：

A tool for creating and running Linux containers using lightweight virtual machines on a Mac. It is written in Swift, and optimized for Apple silicon.

「苹果官方做的容器工具，Swift 写」，这八个字放在 2026 年的 Mac 开发者圈子里已经够炸了。我打开 README 第一遍没看进去，第二遍才反应过来 —— 它不是一个新 runtime，它是 Apple 自己下场重写了「在 macOS 上跑 Linux 容器」这件事。装下来跑了半天，我得认真聊聊这件事。

先说它到底干了什么

大部分 Mac 上的容器方案（Docker Desktop、OrbStack、Colima、Podman）都长一个样：起一台 Linux 虚拟机，在那台虚拟机里跑 containerd /dockerd，所有容器共享这一个 Linux 内核。简单、成本低，但代价是「共享内核」—— 一旦某个容器逃逸，影响的是同一台 VM 里所有的容器。

apple/container 不这么干。它的核心架构是 每个容器独占一台轻量 VM，内核都不共享。README 写得很直白：

While most macOS container tools launch a single Linux VM hosting all containers, container takes a different approach using the open source Containerization package: It runs a lightweight VM for each container that you create.

这个能力来自 Apple 开源的另一个 Swift 包 Containerization，直接调用 macOS 的 Virtualization.framework 框架。这件事能成立，是因为 Apple Silicon 的硬件虚拟化已经做到「每开一台 VM 都几乎不花什么钱」的程度。

我之前写过的 whichllm 解决「该跑哪个模型」，今天这个解决的是更上游的问题 —— 模型要装在容器里跑在 Mac 上，那个「容器」本身到底是什么。

装一下看看

我这台机器正好是 Apple Silicon + macOS26.5（sw_vers 出来 26.5.1），官方说必须 macOS26，刚好踩线。

1
2
3
4
5
6
# 1. 从 release page 下安装包双击装
# 2. 启动系统服务
container system start

# 3. 拉个镜像跑跑
container run --rm -it alpine:latest sh

第一次跑 container run 的时候能看到 macOS 在后台开了一个 VZ（Virtualization）进程。启动速度感觉跟 OrbStack 差不多，并没有 Docker Desktop 那种「点了图标等三秒」的感觉。

几个用下来让我有点意外的细节：

  • OCI 兼容。container 不是苹果搞私有协议，它拉的是标准 OCI 镜像（Docker Hub、GHCR、quay.io 都没问题），构建出来的镜像也能推回这些 registry。README 直接写：「can pull and run images from any standard container registry」。
  • 多架构构建一行命令：container build --arch arm64 --amd64，跑 uname -a 在 amd64 模式下还能看到是 Rosetta 在翻译。
  • --cpus 和 --memory 跟 Docker 长得一样：container run --cpus 8 --memory 32G big，单位支持缩写。我之前给本地 LLM 容器分内存常用的那套写法，直接搬过来。
  • 网络隔离默认就有。container system start 会创建一个 default vmnet 网络，容器之间互相不可见。想要互通可以 container network create foo 建一个自己的。
  • stats 命令长得像 top，能实时看每个容器的 CPU / 内存。

整体命令风格很熟悉 ——container run、container exec、container logs、container build、container image list，写惯 Docker 的人不用查文档就能用。

性能到底怎么样

RepoFlow 11 月在 M4 Mac mini 上做了一轮三方对比（Apple Container v0.6.0 vs Docker Desktop 4.47 vs OrbStack 2.0.4），Sysbench + FIO 全跑了一遍，每个测试重复 20 次：

维度 apple/container Docker Desktop OrbStack
CPU 单线程 强 强 中
CPU 全线程 强 强 中
内存吞吐 强 中 中
容器启动速度 中 最快 中
文件系统 / 小文件 中 慢 最快

简单总结：苹果在 CPU 和内存上已经追上甚至超过 Docker Desktop，但启动延迟不如 Docker（毕竟每开一个容器都要开一台 VM，物理上就是比 fork 慢），文件系统密集型工作负载则被 OrbStack 吊打。

这跟架构直觉对得上：

  • 每容器一台 VM → 隔离性极强，但启动要进 VM 引导 → 启动慢
  • bind mount 走 virtiofs → 小文件性能受 virtiofs 实现质量影响

我自己最看重的反而是 CPU 和内存那一栏。本地起 LLM、跑 Postgres 测试、做点数据处理，这些场景下 CPU / 内存吞吐才是瓶颈。Docker Desktop 在 macOS 上虚拟化 Linux 一直有点吃亏，现在 Apple 用自己的 Virtualization.framework 补上了这件事。

但它还没到能替代 Docker Desktop

写到这里要说几个我装下来撞到的硬限制：

  1. 必须在 macOS26 上。仓库 MAINTAINERS 直接说：macOS 15 上的问题不修。这件事不怪苹果 ——vmnet 在 macOS26 上才支持真正的网络隔离，container-to-container 通信、多个网络、subnet 配置这些都要 macOS26 才能完整工作。
  2. Pre-1.0，目前 0.6.x。README 写得很清楚：「stability is only guaranteed within patch versions … Minor version releases may include breaking changes until we reach a 1.0.0 release」。生产环境锁版本，别追最新 minor。
  3. 没有 Docker Compose。container compose 还没出来（issue 列表里排着，但优先级不高）。我现在本地起的几个项目都是 docker-compose.yml，迁过来要拆成多个 container run 命令或者写 shell 脚本。短期不爽。
  4. 内存 balloon 不完整。官方文档承认：如果你给容器分了 16G 但它只用 2G，剩下那 14G 不会归还给 macOS。要靠偶尔重启容器来回收。这条对 M 系列机器内存本来就紧的用户比较扎心。
  5. amd64 镜像走 Rosetta 翻译。这条对 arm64 原生优先的项目没影响，但如果你的依赖里塞了一堆只有 x86_64 的二进制，启动速度会比原生更慢。

所以它现在的定位很清晰：「Mac 开发者愿意尝鲜、能接受偶尔撞坑」。还不是给运维同事直接顶上去的工具。

那现在该不该切

我自己给三个不同人群的建议：

  • 如果你是 Apple Silicon + macOS26 用户，平时主要跑 Linux 服务做开发 —— 装一个跑跑看。它对你唯一的成本是 30 分钟装 + 适应期。
  • 如果你重度依赖 docker-compose，项目里有一堆 compose 文件 —— 再等等，至少等 container compose 出 preview。
  • 如果你的团队有非 macOS 同事 —— 别切。container 只能跑在 Mac 上，跨平台一致性是零。这事跟 Apple Silicon 是「Apple-only 体验」的性质一样。

我自己现在的工作流是：长期项目还是 OrbStack（文件系统性能太好，开发体验稳），新的、需要「真隔离」或者「跑个边界场景」的小项目用 container—— 比如本地跑一个 untrusted 二进制、或者测多租户隔离。它用起来让人安心，VM-per-container 这个架构本身比「共享内核」让人安心。

为什么这件事值得写

回到主题：GitHub Trending 上每天都有几十个项目冒出来，大部分是「又一个 XXX」或者「又一个 AI wrapper」。apple/container 不一样的地方在于 —— 它是平台方下场重新做了一件大家都认为已经做完的事情。Docker 已经存在 13 年了，所有人都默认「容器等于共享内核」，Apple 现在告诉你这件事在 Mac 上可以重做。

这件事让我有点感慨：macOS 虚拟化这两年进化太快了。Virtualization.framework 在 Apple Silicon 上从「勉强能用」变成「拿来做生产容器 runtime」也就三年时间。Apple 一直不直接做 DevTools，但当他们做了，通常是带着硬件优势来的 —— 这次的 Swift + Virtualization.framework + Apple Silicon，三件套叠在一起，Docker Desktop 真的该紧张了。

今天先写到这。如果你装了发现什么我没遇到的问题，欢迎留言。下一篇准备聊聊 Hermes Agent 里那个 delegate_task 的真实体验 —— 这个东西我用了两周，越用越觉得它不像一个工具，更像是在「雇」一个独立工作的同事。

参考：