独享物理 Mac · 上手手册

从第一次 SSH
到推理端点上线

先连上机器，再搬运工程与模型，最后把服务留在节点上运行。本页的命令面向已交付的 Mac mini；公网地址、用户名与凭据以控制台中的实例信息为准。

立即租用云端 Mac 打开控制台

已下单？先在控制台确认实例已交付，再按下方顺序操作。

连接封签SSH → MLX

XCODEOPS / RUNBOOK

先建立可信连接，
再开放服务。

01取凭据控制台核对节点与公网地址

02建隧道SSH 承载命令行与远程桌面

03启端点MLX 默认仅监听本地回环

访问路径已规划物理节点 · 单租户

按任务跳转

建议首次使用时顺序阅读连接、迁移和 MLX 三节；已有运行环境的团队可直接查看网络选点与故障排查。

01 / 建立访问

先用 SSH 连上独享物理机

连接信息只从控制台的实例详情领取。不要把首次凭据写进仓库、CI 日志或团队群消息；先验证密钥连接，再收紧登录方式。

核对实例

登录控制台，打开已交付实例，记录节点、公网 IP、SSH 端口与登录用户名。确认实例状态后再发起连接；实际可用性以控制台实时返回为准。

加入公钥

在本地生成专用密钥，将公钥添加到控制台提供的密钥入口或实例账户的授权密钥中。只上传公钥；私钥始终留在自己的设备。

验证再加固

先在第二个终端确认密钥登录成功，再按团队策略关闭密码 SSH 登录。修改前保留当前会话，并检查配置语法，避免把自己锁在实例外。

本地连接清单

生成密钥后，将 .pub 文件内容上传。下列配置中的示例地址属于文档保留地址，使用前须替换为控制台显示的实际 IP、端口和用户名。

ssh-keygen -t ed25519 -f ~/.ssh/xops_node

cat ~/.ssh/xops_node.pub

~/.ssh/config

Host xops-node
  HostName 192.0.2.10
  User mac-user
  Port 22
  IdentityFile ~/.ssh/xops_node
  IdentitiesOnly yes

保存后执行 chmod 600 ~/.ssh/config，再运行 ssh xops-node。首次连接应核对主机指纹；连接异常先检查 IP、端口、密钥权限和实例状态。

02 / 图形界面

远程桌面走 SSH 隧道，不直接暴露 VNC

需要运行 Xcode 图形界面或检查构建产物时，先确认实例已启用屏幕共享，再把远端 5900 端口转发到本地。SSH 会话断开后，隧道也会关闭。

在本地终端执行

ssh -N -L 5901:127.0.0.1:5900 xops-node

保持这个终端打开。在本地 Mac 的「屏幕共享」或兼容 VNC 的客户端中连接 vnc://127.0.0.1:5901。图形界面的登录权限与 SSH 权限分别核对，不要假设两者使用相同凭据。

开始前检查

优先使用系统自带的屏幕共享客户端；其他客户端须支持所选的连接与认证方式。
画面卡顿时先降低远程分辨率和色深，再检查本地到节点的链路；不要靠公开 VNC 端口换取速度。
剪贴板同步由客户端和远端会话共同决定。传模型权重、证书或大型工程，请改用 rsync 等文件同步方式。
在共享电脑上结束工作时，同时退出远程桌面、关闭 SSH 隧道，并清理本地留下的敏感文件。

03 / 环境迁移

从本地 Mac 到云端 Mac，分三批搬

先同步可重建的项目文件，再恢复工具链，最后接入 CI。模型权重、签名材料和构建缓存的处理方式不同；不要把整台本地机器的用户目录不加筛选地复制过去。

01 / DATA

数据与模型

用 rsync 增量同步项目和模型权重，先跑一次试传，再确认目标目录、文件权限及可用存储。外置盘镜像只适合事先核对格式和容量后的离线迁移。

rsync -avh --progress ./project/ \
  xops-node:~/work/project/

大权重分批传输；传完比较文件大小和校验值。不要把私钥、临时令牌混入工程目录。

预计操作时间15–60 分钟起随数据量和上传链路变化

02 / TOOLCHAIN

工具链与签名

本地用 Homebrew Bundle 导出 Brewfile，在节点上导入；再核对 Xcode 版本、命令行工具和依赖锁文件。签名证书单独传递，导入后限制钥匙串访问。

brew bundle dump --file=./Brewfile
rsync -av ./Brewfile xops-node:~/work/
ssh xops-node 'brew bundle --file=~/work/Brewfile'

不要把本地 Python 虚拟环境直接复制过去；依赖应在目标机器重装。

预计操作时间20–45 分钟起视软件包与下载速度而定

03 / CI

流水线接入

在现有 CI 项目中注册 self-hosted runner，将它绑定到指定仓库或团队。把构建缓存放在独立目录，并按统一内存与构建负载设置并发。

先执行一次不含发布密钥的测试构建。
记录缓存路径、磁盘占用与清理策略。
确认 runner 以专用账户运行。

预计操作时间15–30 分钟起不含首次完整构建

这些是迁移操作的规划区间，不是实例交付时间。首次同步前先检查可用磁盘空间；需要扩容时，可在机型与附加项中核对可选配置。

04 / MLX 推理

让推理端点先在本机跑通，再交给团队

Apple Silicon 的统一内存同时服务 CPU 与 GPU。模型是否放得下，还取决于量化格式、上下文长度及其他进程的占用；选型时给系统和服务留余量，不把标称内存全部算作权重空间。

安装、启动、验证

在实例上为服务创建独立 Python 环境。下面的模型路径指向已经同步到该实例的本地目录；启动后先在实例内部验证 OpenAI 兼容接口。

python3 -m venv ~/mlx-service/.venv
~/mlx-service/.venv/bin/python -m pip install mlx-lm

~/mlx-service/.venv/bin/python -m mlx_lm.server \
  --model ~/models/quantized-model \
  --host 127.0.0.1 --port 8080

curl http://127.0.0.1:8080/v1/models

先确认模型文件完整、Python 环境可用、端口没有被其他进程占用。不同版本的 mlx-lm 参数可能变化，正式部署前应以实例上安装版本的命令帮助为准。

ACCESS / 01

给团队访问

默认只监听 127.0.0.1。少量内部调用可由成员各自建立 SSH 隧道；需要集中入口时，用有认证、访问控制和 TLS 的反向代理，不要把未经保护的推理端点直接暴露到公网。

ssh -N -L 8080:127.0.0.1:8080 xops-node

STARTUP / 02

保持重启后运行

验证前台命令稳定后，为服务创建用户级 launchd 配置，指定虚拟环境中的 Python、模型路径、工作目录与日志文件。先检查配置，再加载到当前用户会话；重启实例后复核进程和端点。

plutil -lint ~/Library/LaunchAgents/com.xcodeops.mlx.plist
launchctl bootstrap gui/$(id -u) \
  ~/Library/LaunchAgents/com.xcodeops.mlx.plist

内存参考：16GB 适合小型量化模型实验，24GB 可用于常见 7B–8B 量化模型的单服务验证，64GB 为更大模型或多任务留出空间。实际吞吐取决于模型、上下文和负载，请在自己的请求样本上测量。

05 / 开发与交付

把 Xcode 构建留在节点上，把真机验证留在可控流程里

独享物理机适合跑 Xcode 编译、模拟器测试与自托管 runner：同一台机器的 CPU、GPU 和统一内存不会被其他租户的任务占用。但模拟器通过，不等于实体设备上的摄像头、蓝牙或性能测试通过。

模拟器矩阵

固定 Xcode 和模拟器运行时版本，再为关键设备尺寸与系统版本建立测试矩阵。先用 xcrun simctl list devices available 核对实际可用设备，避免流水线引用未安装的运行时。

核对项：版本 / 设备 / 测试报告

归档与分发

先让 runner 完成确定性的测试和归档，再按团队现有签名流程上传 TestFlight 构建。证书、描述文件及上传凭据使用受控存储；不要写入仓库或持久化的构建日志。

核对项：签名 / 归档 / 上传结果

实体设备边界

涉及传感器、实际网络切换、功耗或配件交互的用例，仍需团队控制的实体设备验证。云端节点可以负责构建与分发，再由本地设备完成最终回归和问题复现。

核对项：设备日志 / 复现步骤

06 / 节点与链路

先量到四个节点的链路，再决定把任务放哪里

新加坡、东京、首尔、香港均在目录内。团队成员所在地、运营商路由和晚高峰拥塞会改变实际体验；推理接口更应同时测量请求往返与模型生成耗时，不要只看 ping。

亚太链路参考样本

下表单位为毫秒，展示按指定口径整理的参考样本，不代表对任一用户链路的实时保证。请在自己的网络环境中重复测量后选点。

八个来源城市到新加坡、东京、首尔、香港节点的 ICMP 平均往返延迟参考样本，单位毫秒
来源城市	新加坡	东京	首尔	香港
上海	76 ms	58 ms	53 ms	41 ms
深圳	62 ms	72 ms	65 ms	29 ms
台北	64 ms	46 ms	54 ms	39 ms
曼谷	43 ms	109 ms	98 ms	66 ms
雅加达	38 ms	109 ms	115 ms	74 ms
悉尼	101 ms	132 ms	146 ms	141 ms
大阪	75 ms	32 ms	47 ms	65 ms
釜山	85 ms	44 ms	24 ms	71 ms

测试口径：ICMP 往返时间平均值、每条链路连续 100 次、工作日晚高峰、家庭宽带接入；仅用于初步选节点。数据会随运营商和线路变化，不能替代从你的办公地点对实际实例进行的测试。

01 / 选点

按团队主要使用地测

先比较实际实例的连续 ping，再看丢包与抖动。团队分散在多地时，以最频繁操作远程桌面或调用推理接口的成员为主要参考，而不是只挑地理上最近的城市。

02 / 同步

大文件避开链路高峰

模型权重、媒体素材和构建缓存适合增量同步。把大批量传输排在业务低峰，失败后续传；交互式 VNC 卡顿时，也检查是否有后台同步占满上行。

03 / 扩展

按工作负载考虑并联

Thunderbolt 5 并联适用于确有多机协作需求、且应用工作流能够利用多台物理机的场景。它不会自动把单机统一内存合并成一个模型可用的内存池，配置前先核对软件架构。

07 / 排查与工单

复现信息给齐，比反复描述“连不上”更快

实例或订单问题通过控制台提交工单。发单前先确认本地网络、实例状态、连接方式与故障出现时间；不要在截图或日志中附上私钥、完整令牌和未遮盖的敏感数据。

建议附上的四项信息

01订单与节点订单号、实例所属的新加坡、东京、首尔或香港节点，以及受影响的服务。
02操作与报错执行的命令、完整错误提示、出现问题的步骤及可脱敏的截图。
03时间与范围首次发生时间、是否持续发生、是否仅影响某位团队成员。
04已完成的检查实例状态、密钥权限、端口、隧道和本地网络的排查结果。

接下来做什么

登录控制台，在对应订单或实例处提交工单并附上排查材料。尚未下单的选型问题可发邮件至 support@xcodeops.com；已有实例的问题优先走工单，以便关联订单与节点。

登录控制台提交工单查看常见问题

准备部署

选定节点，把第一条命令跑起来

三档独享物理 Mac mini，按天、周、月或季计费。先选机型，再按实际网络测量结果选节点；交付后的连接步骤，就从本页开始。

立即租用 Mac mini 比较机型与价格

从第一次 SSH到推理端点上线

先建立可信连接，再开放服务。