项目与配置
源文件和自动化配置应保留在团队自己的版本与备份流程中。云端 Mac 上的工作副本不应成为唯一版本。
工程排查手册
云端 Mac 出现问题，先按顺序缩小范围
这里集中处理首次连接、macOS 使用、Xcode 构建、MLX 推理、存储扩展和订单问题。先完成对应检查，再提交订单标识、发生时间与脱敏日志，支持团队就能减少重复确认。
- 支持范围
- 6 类问题
- 在售配置
- 3 档机型
- 服务节点
- 4 个节点
排查派单
先定位层级，再收集证据
可提交工单
A
连接前
入口层
核对交付状态、节点、连接资料与本地网络。
B
任务中
运行层
按版本、依赖、磁盘、内存和日志逐项排除。
C
提交前
证据层
保留时间线与复现步骤，移除密码、私钥和敏感内容。
建议材料
订单标识 + 机型 + 节点 + 时间 + 脱敏日志
按问题所在环节开始检查
六类入口同时可见。选择最接近当前现象的一类，不要把连接失败、构建报错和订单问题混在同一条描述里。
下单前自查
先把用途、配置和连接条件说清楚
如果订单尚未创建，先完成这六项。用途和资源边界越明确，越容易在三档在售配置中做出判断，也能避免把存储容量、网络条件或租期选择误当成机器故障。
节点目录
新加坡、日本（东京）、韩国（首尔）、香港均提供三档机型。最终可用状态以控制台实时返回为准。
订单准备清单
6 / 6 项
- 用途明确构建、测试、持续集成或 MLX 推理
- 机型选定M4 16GB、M4 24GB 或 M4 Pro 64GB
- 节点选定按团队时区和数据传输路径判断
- 计费周期确认按天、周、月或季核对订单
- 存储需求确认区分系统、项目、依赖缓存和模型文件
- 远程连接环境就绪本地网络允许所需连接并保持稳定
连接失败时，从交付状态开始，不要先反复改密码
首次进入云端 Mac 的问题通常发生在订单状态、连接资料、本地网络或输入过程。按下面顺序检查，每一步只改变一个变量。
-
01
订单层
确认订单已经进入可连接状态
登录控制台查看当前订单。若仍处于处理流程，先等待状态更新；不要使用旧截图或其他订单的连接资料进行尝试。
-
02
资料层
逐字段读取连接资料
确认节点、主机地址、连接方式和账号属于同一份订单。复制时检查首尾空格，不要把真实凭据写进聊天记录、截图文件名或公开仓库。
-
03
网络层
排除本地网络限制
确认本地网络、防火墙或代理没有阻断连接。可切换到另一条可信网络做一次对照测试，但不要同时更换账号、客户端和网络。
-
04
输入层
重新核对账号输入
区分大小写和易混字符，确认键盘布局符合预期。若问题可复现，只记录错误类型与发生时间，不记录密码原文。
Xcode 构建报错，按工具链到日志的顺序检查
先确认实际执行构建的环境，再处理依赖和签名。直接清空全部缓存或连续更换 Xcode 版本，会让原始问题更难复现。
-
1
锁定 Xcode 版本
记录当前选择的 Xcode 路径、版本和项目要求，确认命令行任务与图形界面使用同一套工具链。
-
2
核对签名文件
确认所需文件由团队自己的秘密管理流程注入，路径和权限正确。不要把签名文件内容复制到支持请求。
-
3
缩小依赖缓存范围
先判断失败发生在下载、解析、编译还是链接阶段。只清理对应依赖的缓存，并保留清理前后的日志对照。
-
4
检查磁盘空间
分别查看项目目录、构建产物、归档和依赖缓存占用。空间不足时先导出必要产物，再清理可重建内容。
-
5
截取最小日志
保留首次错误前后的必要行、执行命令和退出状态。移除令牌、用户名、内部仓库地址和签名信息。
MLX 推理
先确认模型能加载，再测试服务并发
MLX 推理问题要区分模型格式、统一内存、服务监听和请求压力。先用单请求建立可复现基线，再逐步增加并发，避免把加载失败和服务拥塞混为一谈。
FORMAT
模型格式
先检查
确认模型文件完整、转换方式一致，并记录所用框架与版本。
MEMORY
统一内存占用
再测量
记录加载前、加载后和首次请求后的读数，避免只看瞬时峰值。
LISTEN
服务监听地址
查入口
确认监听范围和端口符合访问设计，并设置必要的访问控制。
LOAD
请求并发
渐进测试
从单请求开始，固定输入后逐级提高并发并记录延迟和失败类型。
LOG
模型加载日志
留证据
保留版本、启动参数和错误上下文，删除业务输入与敏感路径。
按数据角色规划容量，不要把节点当作唯一备份
系统、项目源文件、依赖缓存、构建产物和模型权重的生命周期不同。先分组，再决定是否增加存储附加项。
依赖与构建缓存
缓存可以提高重复任务效率，但应设置清理边界。排查磁盘问题时先按目录统计，不要直接删除全部内容。
模型与数据文件
记录模型来源、格式、版本和占用空间。大文件上传前核对节点路径，并为租期结束前的导出预留时间。
归档与产物
构建归档、测试报告和推理输出应按任务批次命名。完成验收后，将必须保留的内容导出到团队控制的存储。
让第一条请求直接具备排查条件
请求内容应能回答发生在哪份订单、哪台机器、哪个节点、什么时间、如何复现以及日志显示了什么。只写“无法连接”或“构建失败”通常不足以定位。
订单标识
填写控制台中的订单标识，不要使用自定义机器昵称代替。
机型与节点
写明 VMCache M4 16、VMCache M4 24 或 VMCache M4 Pro 64，以及对应节点。
发生时间
注明时区，并说明是持续发生、间歇发生还是只出现过一次。
复现步骤
从已知正常状态起逐步列出操作、输入类型、预期结果和实际结果。
影响范围
说明影响单个任务、单个项目还是全部任务，并列出可正常工作的对照项。
脱敏日志
保留错误上下文、版本和退出状态，移除密码、私钥、令牌与业务数据。
两种联系路径
提交支持工单
已有订单优先登录控制台提交工单；无法进入控制台或属于售前问题时，可发送邮件至 support@vmcache.com。
下一步
先完成检查，再把证据交给支持团队
需要新资源时比较三档配置；已有订单出现问题时，带上订单标识、节点、发生时间、复现步骤与脱敏日志提交工单。