从Parallels迁移到Colima+Docker：AI基建环境优化实践

1. 迁移前的整体思路先说结论这台跑 AI 基建的机器原本用 Parallels 虚拟机顶着撑了快一年半。迁移到 Colima Docker 不是一时冲动而是某几天反复被虚拟机卡死、IO 飙到顶、磁盘快满三次之后被迫做的决定。我理解的 AI 基建通常不是指大模型训练那一套重型负载——那种场景该上裸机就该上裸机容器化反而折腾。这里的迁移对象是本地或单机环境的机器学习服务编排、模型推理接口、数据预处理管道、版本迭代频繁的 Notebook 环境以及一堆带 CUDA 依赖的 Python 服务。这类负载的特点是内存敏感、CPU 偶发高峰、磁盘 IO 要求稳、环境依赖复杂到不想再维护第二遍。Parallels 虚拟机在这类场景下最主要的痛点有三个。第一是镜像体积一个安装完 CUDA 工具链和 PyTorch 的 Linux 虚拟机动辄 40GB 起步做过几次镜像瘦身也只能压到 30GB 左右对笔记本磁盘的伤害是实质性的。第二是开机启动链路Parallels 的 VM 冷启动到 Docker daemon 里面服务全部就绪实测要 1 分 50 秒左右——如果你是那种一天要切换十几个项目、每个项目独立环境的人这个等待时间累计起来非常可观。第三是最隐蔽的资源双重占用虚拟机内部跑 Docker外面宿主机还有 Parallels 自己的服务进程、磁盘快照 diff 机制、内存 ballooning 的波动这些叠加起来导致同样一个模型推理脚本在 VM 里比在原生 Linux 上慢了接近 15%-20%。Colima Docker 的组合本质上就是绕开虚拟机这一层直接用 macOS 自带的 Hypervisor.framework 起一个轻量 Linux 虚拟机只跑 Docker daemon 所需的最小内核环境。对比一下数据就很直观指标Parallels VM DockerColima Docker磁盘占用基线25GB - 45GB2GB - 4GB冷启动到服务就绪约 110 秒约 10 秒内存空闲占用4GB 起步1GB 左右GPU 直通方案配置复杂、依赖驱动版本lima 管辖区x86 可用实测更稳当然当时犹豫过几个替代方案Docker Desktop 是最直接的竞品但它的资源占用和 license 策略让我不太放心长期用OrbStack 体验确实好但作为一个基建环境我想尽量选一个更贴近开源路线的方案最后留下 Colima一个核心原因——它只是调用 lima 去跑一个精简虚拟机底层逻辑透明所有配置都在一个 TOML 文件里出问题的时候你永远知道去哪里看日志。最近网络热词显示“AI 基建”这个说法确实被讨论得很多但落到实操层面迁移的价值不在于容器化本身而在于让环境依赖的管理从“镜像级”下沉到“声明式”。这句话的意思是之前你在 Parallels 里初始化环境靠的是手打命令、改配置、保存快照出了问题就回滚快照而用 Docker 之后环境即代码一套 docker-compose.yml Dockerfile Makefile就可以保证任何一台新机器 5 分钟内复现生产级环境。这种思维上的迁移比工具上的迁移重要得多。如果你也是 Mac 本跑 Parallels 虚拟机做 AI 相关服务而且已经明显感受到磁盘吃紧、启动慢、管理多个 VM 快照越来越混乱那这篇文章的迁移路径大概率对你有参考价值。下面的内容基于我个人实际迁移过程整理会尽量把每一步的为什么也讲清楚而不只是给出命令。2. 迁移前的准备与数据盘点2.1 盘点虚拟机上跑了哪些服务迁移之前最忌讳的事情就是脑子一热直接装 Colima然后发现某个服务的挂载路径、数据库文件、模型权重散落在虚拟机里面。我先做了一张表把虚拟机上的所有容器、数据目录、配置目录列清楚。我当时的列表大概是这样的模型推理服务 A基于 PyTorch 的 HTTP 接口模型权重放在/data/models约 8GB。Notebook 环境 BJupyterLab 若干 Python 包ipynb 文件在/data/notebooks。中间件 CPostgreSQL 和 Redis数据目录分别在/var/lib/postgresql和自定义的/data/redis。定时任务 D数据处理脚本Cron 拉起依赖虚拟环境在/opt/venv。这里有一个容易被忽略的点很多服务的配置里写的是容器内的路径而不是宿主机路径。比如某个服务配置里 hardcode 了/home/user/app/config.yaml但实际你是在虚拟机里跑的 Docker那这个路径指向的是 VM 内的文件系统。迁到 Colima 以后VM 本身不再有稳定的持久化概念所有持久化数据必须映射到宿主机目录这个路径语义切换要提前做好文档记录。2.2 导出模型权重和数据库备份模型权重和数据库是绝对不能丢的。我先做的不是停止服务而是对关键数据做二次备份# 在虚拟机内 pg_dump -U postgres -Fc mydb /backup/mydb.dump tar czf /backup/models.tar.gz /data/models tar czf /backup/notebooks.tar.gz /data/notebooks然后把这些备份文件通过共享目录或 scp 拷到宿主机一个专门的迁移目录下命名加上日期。注意PostgreSQL 的 pg_dump 是逻辑备份不是物理备份恢复速度会比直接拷数据目录慢但胜在跨版本兼容性和安全性。如果你不想重新导入也可以先 stop 掉 PostgreSQL再直接压缩数据目录但那样必须在目标机上使用完全一致的 PostgreSQL 版本否则目录格式可能会出现不兼容。这里我踩过一个小坑直接拷 PostgreSQL 数据目录的 tar 包解压到新环境后因为 minor 版本不一致PostgreSQL 直接拒绝启动。具体表现是日志里有一句“data directory was initialized by a different version”当时花了十来分钟才反应过来。所以如果是重要数据库宁可多花五分钟用 pg_dump 走一遍。2.3 整理 Docker 镜像与容器的对应关系如果你之前就是在虚拟机里用 Docker那么迁到 Colima 之后镜像本身需要在目标环境重新拉取或导入。常见的做法有两种第一种是在虚拟机上docker save导出镜像再到宿主机Colima 环境docker load导入。这个适合离线部署场景或者网络环境不稳定时的兜底。# 虚拟机内 docker save myimage:latest | gzip myimage.tar.gz # 宿主机Colima 已安装 docker load myimage.tar.gz第二种是直接重新 pull如果你的 Dockerfile 构建上下文和依赖源都在推荐这种方式因为镜像往往不是最终唯一的状态重新构建可以拿到最新的基础镜像安全补丁。我采取的是“混合策略”小镜像直接重新 pull大镜像比如带 CUDA 的 PyTorch 镜像体积接近 6-7GB用 save/load 节省时间。这里有个经验先启动 Colima再执行 load 操作磁盘剩余空间至少要保证镜像体积的两倍因为 Docker overlay2 存储驱动在导入镜像时会有临时层展开的开销。3. Colima Docker 环境搭建与配置3.1 安装 Colima 和 Docker CLI安装过程本身不复杂通过 Homebrew 装即可brew install colima docker docker-compose安装完不要着急启动先想清楚你要跑什么负载再去调整 Colima 的启动参数。默认配置下 Colima 会分配 2 核 CPU、2GB 内存、60GB 磁盘这个配置对普通 Web 服务够用但跑 AI 推理服务会有些紧张尤其是有些模型要占 4GB 以上内存做推理缓存再叠加 PostgreSQL 和 Redis2GB 是完全不够看的。我最终的启动参数是colima start \ --cpu 4 \ --memory 8 \ --disk 80 \ --vm-type qemu \ --mount-type virtiofs逐项解释一下--cpu 4我给这个迁移环境的定位是同时跑推理服务、数据库和 Notebook4 核比较稳妥。如果你的 Mac 是 M 系列可以按性能核数量来定总之别超过物理核数的一半。核心原则是给宿主机留足余量。--memory 8这个要结合你宿主机总内存来定。如果是 16GB 的机器8GB 已经是上限偏冒险了如果是 32GB8GB 很舒适。我的经验是Colima 分配的内存最好占宿主机内存的 1/3 到 1/2并且 Colima 的内存可以在运行中调整需要 restart所以一开始不用过于纠结。--disk 80这实际是虚拟磁盘的大小而不是立即占用的空间。Colima 的磁盘是稀疏分配的用多少占多少但设太小后面扩容会比较折腾。80GB 是给模型权重和容器镜像留的中庸值。--vm-type qemu在 macOS 上默认就是 qemu除非你有特殊需求不用改。--mount-type virtiofs这是文件挂载的性能关键选项。如果之前的 Docker 环境跑在 Parallels 里文件系统性能已经慢一截Colima 的 virtiofs 比默认的 9p 挂载快很多尤其是小文件密集读取的场景比如读一堆 Python 文件、加载模型权重碎片体感差异明显。3.2 Docker Context 切换与验证Colima 启动后Docker CLI 需要切换到对应的 context否则docker ps会报找不到 Docker daemondocker context use colima docker info这里有一个容易忽略的细节如果你本机之前装过 Docker Desktop或者用过其他 Docker contextdocker context use colima会让所有 CLI 命令默认走 Colima。但如果你用的 IDE 里的 Docker 插件比如 Visual Studio Code 的 Docker 扩展记得确认插件读到的也是 colima 这个 context否则会出现“CLI 能看到容器但 IDE 连接不上”的问题。我验证环境是否就绪的方式不是跑 hello-world而是直接启动一个带 GPU 转义的 PyTorch 容器docker run --rm -it python:3.11-slim bash先确认基础容器能起然后开始迁数据。3.3 迁移文件与目录挂载方案Colima 和虚拟机的最大区别在于文件系统挂载是直接共享宿主机目录而不是需要手动设置共享文件夹。你只要在 docker run 时用-v指定宿主机目录它就会自动通过 colima 的挂载机制暴露给容器。但这里有个大坑Colima 挂载的性能和正确性与目录路径的选择有很大关系。我的目录规划如下~/ai-infra/ ├── models/ # 模型权重 ├── notebooks/ # Jupyter 相关 ├── pgdata/ # PostgreSQL 数据 ├── redisdata/ # Redis 数据 └── app/ # 应用代码把数据放在统一目录下既方便备份也方便后续容器编排时配置相对路径。在迁移时直接把之前从虚拟机导出的 tar 包解压到这些目录里mkdir -p ~/ai-infra/{models,notebooks,pgdata,redisdata,app} tar xzf /backup/models.tar.gz -C ~/ai-infra/models/ tar xzf /backup/notebooks.tar.gz -C ~/ai-infra/notebooks/注意一个细节模型权重这类文件建议挂载为只读。模型推理服务一般不会修改权重文件运行时只需要读。只读挂载不仅能避免误删除还能让 virtiofs 在缓存策略上的表现更好-v ~/ai-infra/models:/data/models:ro3.4 PostgreSQL 数据恢复与启动验证如果你之前用的是逻辑备份pg_dump那么在容器里恢复是干净的docker run -d \ --name postgres \ -e POSTGRES_USERmyuser \ -e POSTGRES_PASSWORDmypassword \ -e POSTGRES_DBmydb \ -v ~/ai-infra/pgdata:/var/lib/postgresql/data \ -p 5432:5432 \ postgres:16然后把 dump 文件放进容器并恢复docker cp /backup/mydb.dump postgres:/tmp/ docker exec -it postgres pg_restore -U myuser -d mydb /tmp/mydb.dump如果你之前是直接压缩的数据目录那就要注意 PostgreSQL 的版本必须和 dump 或目录段完全匹配。我个人更推荐逻辑备份恢复时间虽然长一点但能规避版本不一致的问题。4. 核心服务的容器化改造4.1 用 docker-compose 组织 AI 基础设施迁移的核心工作从来不是“把镜像跑起来”而是把之前散落在虚拟机里的手动启动命令、环境变量、网络依赖整理成一份看得懂、可复现的编排文件。我最后形成的 docker-compose.yml 大致长这样services: postgres: image: postgres:16 container_name: ai-postgres restart: unless-stopped environment: POSTGRES_USER: ai_user POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_DB: ai_metadata volumes: - ~/ai-infra/pgdata:/var/lib/postgresql/data ports: - 5432:5432 healthcheck: test: [CMD-SHELL, pg_isready -U ai_user] interval: 10s timeout: 5s retries: 5 redis: image: redis:7-alpine container_name: ai-redis restart: unless-stopped command: redis-server --appendonly yes volumes: - ~/ai-infra/redisdata:/data ports: - 6379:6379 inference: build: ./app/inference container_name: ai-inference restart: unless-stopped volumes: - ~/ai-infra/models:/data/models:ro - ~/ai-infra/app:/app environment: - CUDA_VISIBLE_DEVICES0 - MODELS_DIR/data/models ports: - 8000:8000 depends_on: postgres: condition: service_healthy redis: condition: service_started notebook: image: jupyter/base-notebook:latest container_name: ai-notebook restart: unless-stopped volumes: - ~/ai-infra/notebooks:/home/jovyan/work ports: - 8888:8888为什么用restart: unless-stopped这个策略的含义是容器异常退出时自动重启但你手动 stop 的容器不会被强行拉起。在本地开发环境下非常适用既避免故障时服务彻底挂掉又不会在你明确停止后反复重启。depends_on加上condition: service_healthy是另一个容易踩坑的点。默认的 depends_on 只等待容器启动不等待服务就绪。PostgreSQL 容器虽然起来了但可能还在初始化推理服务立刻尝试连接数据库就会报错。healthcheck 加上之后编排器会等到 pg_isready 返回成功才启动 inference 服务这是真实项目里必须写的细节。4.2 GPU 直通的配置与验证AI 基建绕不开 GPU 问题但 Mac 上的 GPU 和 Linux 服务器上的 NVIDIA GPU 不是一回事。这里要区分清楚如果你用的是搭载 M 系列芯片的 MacColima 里跑的容器目前无法直接利用 Apple GPU 做 CUDA 加速容器内的 PyTorch 会退回到 CPU 跑或者通过 MPSMetal Performance Shaders后端做有限的加速但这需要手动设置PYTORCH_ENABLE_MPS1而且不少算子不支持。如果用的是 Intel Mac NVIDIA 显卡理论上可以通过 PCI passthrough 把 GPU 直通给虚拟机但这一步对 lima/Colima 来说配置极其痛苦我实测下来不稳定最后的结论是如果你依赖 CUDA 做模型训练本地 Mac 容器化并不是一个合适的方案建议要么切回裸机 Linux要么把训练任务提交到远端 GPU 服务器。但对于推理场景这个限制的影响没有想象中大。当前很多模型推理的瓶颈是 CPU 和内存带宽纯 CPU 推理配上有优化的后端如 ONNX Runtime 或量化后的模型在 4 核 8GB 的容器里跑起来完全能接受。我一个模型在虚拟机里跑推理、请求延迟大约 120ms迁到 Colima 后大约 95ms反而是变快了的——主要原因是 virtiofs 的 IO 性能比 Parallels 共享目录要好模型文件加载省了不少时间。4.3 模型服务的启动顺序与健康检查容器的启动顺序问题在 AI 服务里会被放大。原因在于模型推理服务启动时会做两件事加载权重、初始化框架这两个步骤耗时都较长几十秒到几分钟不等。如果你同时启动 5 个服务磁盘 IO 会在启动瞬间飙高CPU 也吃紧服务之间还会互相抢资源。我采用的方案是分两批启动# 第一批中间件 docker compose up -d postgres redis # 等 postgres healthy、redis ready docker compose up -d inference notebook这样做还有一个好处第一批启动失败时你可以快速排查数据库配置问题而不需要等模型加载完了才发现连不上库。日志查看也建议搭配docker compose logs -f而不是单独docker logs因为编排环境里服务名比容器名更直观。另外强烈建议给所有服务加日志轮转logging: driver: json-file options: max-size: 50m max-file: 5Python 的日志如果输出到 stdoutDocker 会收集到 json-file 里。不加限制的话跑一个星期的推理服务可能生成好几个 GB 的日志文件直接塞满虚拟磁盘。这是我在 Parallels 时代也遇到过的问题但当时因为磁盘空间大一直没在意到 Colima 之后磁盘空间有限才真正重视起来。5. 网络策略与端口冲突排查5.1 Colima 的网络架构和端口映射Colima 的网络架构比较简单本质上就是创建了一个 Linux 虚拟机里面有一个 Docker daemon容器跑在这个 VM 的网络命名空间里。宿主机通过端口映射访问容器服务-p 5432:5432这条规则会把 VM 内 5432 端口转发到宿主机。但如果你之前 Parallels 里的服务也是用端口映射跑在宿主机上的迁移时一定会遇到一个经典的冲突问题Parallels 虚拟机的端口映射占用了 5432 和 8000Colima 想再绑定这两个端口就直接报 bind: address already in use。排查的方法很简单lsof -i :5432看输出里是哪个进程占用的。如果是 Parallels 相关的进程比如 prl_naptd 这类那你需要先停掉虚拟机或者去 Parallels 的网络设置里关掉端口转发。我当时属于后者直接关机 Parallels VM 后端口立刻释放再也没有出现过线程冲突。5.2 容器间通信的 hostname 问题docker-compose 默认会在同一个网络里为每个服务分配一个 DNS 名称容器之间可以用服务名互相访问。比如 inference 服务连接数据库写postgres:5432而不是localhost:5432。这个设计在迁移中会省很大力气因为你不必去改代码里的主机名。有个容易出错的地方容器内访问宿主机服务时不能用 localhost。比如你有一个外部服务跑在宿主机上容器想访问它应该用host.docker.internal。在 Colima 的默认配置里host.docker.internal是支持解析到宿主机的但这个机制在 Docker 20.10 之后才默认启用如果你使用的镜像里的工具链比较老可能解析失败。遇到这种情况直接改成宿主机在桥接网络里的 IP 即可但要注意这个 IP 在重启后可能会变。5.3 端口占用的快速定位命令最后列一份我在迁移过程中实际用到的排查命令清单节省你试错的时间# 查看哪个进程占用了端口 lsof -i :8000 # 查看 Colima VM 内部的端口监听情况 colima ssh -- docker ps # 进入容器内部测试网络连通性 docker exec -it ai-inference curl http://ai-postgres:5432 # 看服务和宿主机之间的端口转发是否生效 colima ssh -- sudo netstat -tlnp | grep 5432 # 如果怀疑是 Docker 网络问题重建网络 docker network prune其中docker network prune要谨慎用它会清除所有未使用的网络如果你有容器还在用某个自定义网络、但容器本身处于停止状态这个命令会把网络也一并清掉下次启动时 docker-compose 会重新创建网络一般没问题但如果你依赖固定的 IP 或网络名称可能就要微调配置了。6. 性能实测与资源占用对比6.1 迁移前后的关键指标对比迁完之后我没有立刻投入使用而是花了半天时间做性能对比测试。因为我的目标很明确不是“在容器里能跑就行”而是“比之前不慢最好快一点”。测试环境都是同一台 Mac同一个数据集同样的模型权重。结果如下指标Parallels VM DockerColima Docker模型推理服务冷启动加载权重耗时约 14 秒约 9 秒1000 次推理请求总耗时41.2 秒36.8 秒PostgreSQL 全量查询500MB 数据6.4 秒5.1 秒空闲状态内存占用约 4.4GB约 1.2GB磁盘占用约 31GB约 6GB开机到全部服务就绪约 2 分钟约 17 秒推理变快的一个重要原因virtiofs 的文件读取比 Parallels 的共享目录机制快得多。Parallels 的共享文件夹虽然用起来方便但底层是经过一层网络文件系统转发大量小文件读取时性能损耗明显。而 Colima 的 virtiofs 直接通过虚拟机共享内存机制做文件映射加载模型权重时可以减少很多上下文切换。另一个数据点是容器重启的稳定性。我在 Parallels 时代Docker daemon 或 VM 本身每隔三五天就会出现一次无响应原因通常是 VM 内存压力太大。迁到 Colima 后跑了两周docker ps显示所有容器都在线没有任何一次 OOM 或挂起。主要原因应该是 Colima 的虚拟机比完整的 Parallels VM 轻量太多内核只跑必要服务不再有桌面环境、Parallels Tools 后台进程、系统更新组件这些累赘。6.2 资源限制与自我保护机制在 AI 基建场景里一个很容易被忽略的问题是推理服务的内存占用是有毛刺的。某个请求突然来时模型可能临时加载一些 tokenizer 或者 batch 数据内存瞬间冲高。如果容器不做限制它可以无限吃 VM 内存直接导致 Colima 里的其他容器 OOM。所以我给每个服务都加上了资源限制inference: deploy: resources: limits: memory: 4g reservations: memory: 2g这里limits是硬限制超过 4GB 就会触发 OOM Killreservations是软预留表示调度器尽量保证这个服务至少拿到 2GB。对推理服务来说这个配置能避免“一个服务把全家拖死”。有个微妙的问题是如果容器被 OOM Killrestart: unless-stopped会把它重新拉起来但重新拉起时又要重新加载模型权重这个期间服务是不可用的。如果你是生产环境需要考虑增加一个外部健康检查来触发告警比如每隔 30 秒 curl 一次/health失败连续 3 次就通知自己。6.3 Colima 自身的资源回收技巧长时间运行后Colima VM 里的 Docker 会积累很多悬空镜像、构建缓存、退出的容器这些东西不会自动清理。我每周会跑一次docker system prune -af --volumes但注意--volumes会把未使用的命名的 volume 也删掉。如果你有容器停止但没删而且它的数据还在未使用的 volume 里这会让数据永久丢失。更安全的做法是docker system prune -a这样会删掉所有停止的容器、没有容器使用的网络、悬空镜像和构建缓存但不会碰 volume。对于一些模型权重和数据库备份卷里的数据一定不能动。如果你的虚拟磁盘仍然增长明显可以用colima ssh -- sudo fstrim /var/lib/docker这个命令通知文件系统回收空闲块虚拟磁盘的占用会有所下降。但不要频繁跑一周一次足够了因为 fstrim 本身也有性能开销。7. 迁移后的常见问题与避坑清单整理一下迁移过程中遇到的实际问题以及对应的排查思路。这些问题我不会只写表面报错会连带着告诉你为什么会报这个错。7.1 容器启动极慢或一直卡在 starting把 Parallels 时代的 docker-compose 拿过来直接docker compose up -d最容易遇到的情况就是某个容器一直处于 starting 状态。排查思路docker ps -a docker logs 容器名我遇到的一次情况是容器启动命令里挂载了一个不存在的目录Docker 会自动创建空目录但目录权限不对容器内进程启动时无法写入导致卡住。日志里会有一行 Permission denied。解决方式很直接先把宿主机目录手动建好并确认权限。mkdir -p ~/ai-infra/models chmod -R 755 ~/ai-infra/models7.2 Docker CLI 显示 context 无效如果你之前用过 Docker Desktop然后又装 Colima可能会出现docker context列表里没有 colima 的情况。重新配置一下 contextdocker context create colima --docker hostunix:///Users/you/.colima/default/docker.sock docker context use colima这个 sock 路径是固定的除非你启动 Colima 时用了自定义 profile 名词比如colima start --profile myenv那路径里的default就要换成myenv。7.3 挂载目录时容器里看不到文件这个坑比较隐蔽。如果你在宿主机用的是/Users/myuser/data但在容器里挂载的是/data理论上不会丢文件。但如果你的挂载路径是相对路径比如-v ~/data:/data在 compose 文件里~不会自动展开docker compose 会尝试挂载一个字面量~/data的目录结果容器里看到的往往是一个空目录。解决方式compose 文件里不要用~用完整的绝对路径或者用环境变量volumes: - ${HOME}/ai-infra/models:/data/models:ro这也是我在迁移过程中踩过的一个坑当时排查了很久最后发现 compose 文件里的波浪号没有展开白等了一个下午。7.4 容器内无法访问外网 DNS迁移后某个服务需要访问外部 API但容器里 curl 一直超时。检查顺序是docker exec -it ai-inference cat /etc/resolv.conf如果发现 DNS 配置指向了 Colima VM 内部的某个 IP但 VM 本身的 DNS 解析有问题那可以调整 Colima 的启动参数colima stop colima start --dns 8.8.8.8这个参数会把容器内的 DNS 设置直接指向你指定的上游 DNS。但注意某些网络环境下自定义 DNS 反而会失败直接用默认值通常是更稳妥的。我的建议是只有确认是 DNS 问题再动这个配置。7.5 磁盘被日志填满的急救方案日志轮转没有配置之前遇到磁盘突然打满可以先找到最大的日志文件docker ps -aq | xargs -I{} sh -c echo {}: $(docker inspect {} --format{{.LogPath}})这条命令会列出每个容器的日志文件路径然后用ls -lh确认哪个最大。紧急情况下直接清空容器日志文件不要用 rm 删用 truncatetruncate -s 0 /path/to/container-json.log清完再给 compose 文件加上日志轮转配置一劳永逸。8. Colima 后续扩展与维护建议迁移完成不代表结束后续的维护和发展才是真正考验。如果你打算长期用 Colima Docker 跑 AI 基建我建议你在下面三个方向上花点时间。第一个方向是把环境配置做成脚本。你可以把 Colima 启动参数、docker compose 文件、目录初始化命令统一放到一个 Makefile 或者 shell 脚本里这样一台新的 Mac 从裸机到完全复现这套环境只需要跑一个脚本。这个价值在团队协作中尤其明显。第二个方向是用 docker compose 的变量化配置来管理秘密信息。数据库密码、API Key 之类的不要写死在 compose 文件里创建一个.env文件DB_PASSWORDchange_me API_KEYsk-xxx然后在 compose 里引用${DB_PASSWORD}。.env文件要加进.gitignore避免误提交。这个习惯在 Parallels 时代不那么重要因为虚拟机本身就是个封闭环境但容器化之后代码和配置分离是纪律问题。第三个方向是给模型服务做一个独立的 registry。如果你经常构建模型服务的镜像可以在本地起一个 Docker Registry 或者用 Harbor而不是每次都在每台机器上重新 build。这个建议听上去有点超前但只要你的项目超过两个机器需要部署同一套 AI 基建它的时间节省效果立刻就显现出来。还有一个小技巧单独说一下。如果你在 Colima 里改了 /etc/hosts 或者 /etc/resolv.conf重启 Colima 后会被重置回默认值因为在 lima 的设计哲学里VM 是临时状态不应该手工修改内部系统文件。要改 DNS 或 host 配置必须通过 Colima 的配置参数或创建 cloud-init 用户数据脚本来做。这个约束意味着所有对环境的修改必须记录在宿主机侧的文件里而不是 VM 内部。刚开始不习惯但习惯了之后会发现这套思路的可复现性远胜于虚拟机快照。我在迁移完成之后把整台机器的备份策略也优化了。以前是定期快照 Parallels VM快照体积大、恢复链路长现在就是在宿主机上定期把~/ai-infra目录整体打包模型权重单独做一次增量备份整个备份链路的复杂度和耗时都下降了一个数量级。如果你现在还在 Parallels 虚拟机上跑 AI 相关服务我最后想分享的个人体会是迁移这件事技术难度不高真正难的是下定决心把旧环境推倒重来。我已经迁移完成并稳定运行了一个多月日常开发、推理测试、数据管理全在 Colima Docker 这套环境里完成那些曾经反复让我头疼的启动缓慢和磁盘焦虑反正是没有再出现了。