先明确任务，再决定租多久
MLX 推理验证可能按天推进，发布期构建队列可能覆盖一周，持续集成执行器通常需要按月或按季运行。用户可以按任务长度选择周期，不必为了短期峰值长期保有闲置设备。
关于 VMMini
把短期 Mac 算力，交付成边界清楚的物理节点
VMMini 专注提供云端 Mac 独享物理机。每个订单对应一台 Apple Silicon 物理节点，适合 MLX 推理、Mac AI 部署、iOS/macOS 构建与远程自动化，不是从共享资源中切分出的虚拟机。
我们只公开实际在售的 VMMini M4 配置与新加坡、日本（东京）、韩国（首尔）、香港四个节点。配置、周期价格和目录范围在公开页面与控制台保持一致。
VMMini
物理节点
- 目录配置
- M4 / 16GB / 256GB
- 运行方式
- 独享物理机，非虚拟机
- 计费周期
- 按天、周、月、季
- 运行目标
- 99.9%
为什么只做这一类服务
设备应该服务于任务周期，而不是变成长期维护项目
短期推理实验、版本发布冲刺和构建峰值往往只持续数天或数周，但自购设备会把采购、上架、网络、远程访问、系统更新和故障处理变成长期工作。VMMini 把这些基础设施动作收进可选择周期的云端 Mac 服务中。
把物理资源边界写在订单前
在选择节点之前即可核对芯片、内存、硬盘、周期价格和附加项。VMMini M4 固定为 M4、16GB RAM 与 256GB SSD，不使用模糊档名隐藏实际规格。
让退出计划与部署计划同时存在
任务开始前就应确定产物如何导出、日志保存多久、密钥何时撤销、数据如何清理。这样按天或按周使用云端 Mac 时，结束阶段不会变成临时补救。
产品原则
四件事必须在创建订单前说清楚
工程团队判断一项基础设施服务，依赖的是可核对信息。我们用固定目录约束页面、控制台和支持流程，不用模糊包装替代事实。
配置写清
唯一在售配置是 VMMini M4：M4、16GB RAM、256GB SSD。需要更多存储或 Thunderbolt 5 并联时，附加项单独计价，不混入基础规格。
节点写全
目录覆盖新加坡、日本（东京）、韩国（首尔）和香港四个节点。选择时应结合团队位置、代码源位置和用户访问链路，而不是只看城市名称。
价格一致
基础配置严格为 $20.5/天、$55.4/周、$102.6/月、$279.1/季。页面出现的周期价格必须与订单目录一致，全部以 USD 标示和结算。
状态可查
目录内机型与节点组合常态可订，实际可用状态以控制台实时返回为准。节点事件、订单记录和支持处理应能关联到具体时间与订单标识。
明确边界：
共享计算资源不会被包装成独享物理节点。节点硬件、外部网络路径与用户自身软件是三个不同层次，排查时必须分别验证。
目标用户
为需要真实 macOS 执行环境的工程任务提供资源
不同团队使用同一台云端 Mac 时，关注点并不相同。我们按工作负载说明输入、运行方式和需要带走的产物，避免把所有需求压成一句“远程开发”。
iOS / macOS 开发
BUILD
把构建峰值从个人工作站移出
开发者通常需要固定 Xcode 工具链、稳定的依赖缓存、可追踪的归档产物和可复现的失败日志。痛点不是单次编译，而是发布期多人争用本地设备、环境漂移和产物散落。
- 输入
- 代码、锁定文件、构建配置、受控凭据
- 运行
- 命令行构建、测试、归档与日志留存
- 产物
- 归档文件、测试报告、符号文件与构建记录
CI/CD 团队
QUEUE
让 self-hosted runner 有明确的资源所有权
持续集成团队关心队列吞吐、项目隔离、缓存清理、执行器撤销和失败重试。共享环境容易把缓存污染与权限问题扩散到多个项目，独享物理节点则便于按机器建立运行基线。
- 输入
- Runner 注册信息、仓库权限与任务标签
- 运行
- 隔离工作目录、限制并发、清理临时文件
- 产物
- 流水线日志、测试结果、安装包与校验信息
AI 实验用户
MLX
在 Apple Silicon 上复现实验与服务部署
MLX 推理与 Mac AI 部署需要关注模型文件、内存占用、服务监听地址、健康检查和日志采集。常见管理成本来自模型缓存膨胀、端口暴露过多以及实验结束后缺少清理计划。
- 输入
- 模型、推理脚本、依赖版本与测试样本
- 运行
- 本地监听、健康检查、资源观测与批量任务
- 产物
- 响应结果、性能日志、模型配置与复现说明
运行目标
99.9% 服务目标，按订单记录与时间窗口核对
所有节点全年 365 天正常运行，不设置定期停机安排。服务目标用于衡量节点服务可用性，但不把外部网络路径、用户自身软件错误或不可控事件混入硬件节点结论。
99.9%
服务可用率目标
- 计算窗口、可用状态定义和申请流程以服务条款为准。
- 核对材料包括订单标识、节点、发生时间、连接测试和脱敏日志。
- 赔付依据服务条款中的可用率口径、排除项与审核结果确定。
90 天观测窗口
每个短格代表一个自然日
目标覆盖日
01–10
11–20
21–30
31–40
41–50
51–60
61–70
71–80
81–90
此仪表说明计算结构与目标口径，不代替订单级事件记录。具体节点状态和关联时间以控制台返回的信息为准。
节点运营边界
四个在售节点，三层问题必须分开判断
节点城市决定物理部署位置，但不能单独预测每位用户的访问体验。下单前应从节点可用性、实际网络路径和工作负载自身状态三个层次测试。
SG新加坡
面向东南亚团队与工作负载。适合先从团队出口、代码源和目标用户网络分别测试。
选择新加坡节点JP日本（东京）
面向日本及东亚访问链路。应同时检查办公网络、自动化平台与依赖下载路径。
选择东京节点KR韩国（首尔）
面向韩国及东北亚任务。持续集成团队应从 Runner 到代码源的实际路径判断。
选择首尔节点HK香港
面向华南与东南亚访问需求。跨地区团队应分别采集各办公网络的连接结果。
选择香港节点| 层次 | 先检查什么 | 需要记录什么 | 如何继续 |
|---|---|---|---|
| 节点可用性 | 主机是否响应、系统是否启动、订单状态是否正常 | 订单标识、节点、发生时间、连接结果 | 在控制台核对状态，异常时提交关联工单 |
| 网络路径 | 本地出口、运营商路由、代码源与目标服务链路 | 来源网络、目标地址、连续测试结果与路由信息 | 更换来源网络复测，区分单一路径与节点问题 |
| 用户软件 | 进程、端口、权限、依赖、磁盘和任务日志 | 复现步骤、版本、脱敏日志与最近变更 | 先回滚最近变更，再按任务层逐项恢复 |
安全与访问责任
独享硬件不等于可以省略权限管理
物理节点减少了资源共享边界，但代码、凭据、服务端口、日志和导出数据仍由用户控制。安全动作应覆盖任务开始、运行期间和结束阶段。
按最小权限拆分访问
只向执行任务的人员和自动化流程分配必要权限。项目凭据与个人访问信息分开保存，不把私钥直接写进仓库、构建脚本或镜像层。
- 建立人员、Runner 与服务进程的权限清单
- 仅开放工作负载实际使用的端口
- 为撤销访问预留负责人和操作路径
轮换密钥并让日志可安全共享
长期任务应按团队规则轮换访问密钥。日志用于排查时，先移除令牌、私钥、环境变量值和可识别个人的信息，再附到支持请求中。
- 记录密钥创建、使用范围与撤销状态
- 限制日志读取权限和保存周期
- 异常发生时保留时间线而不是复制全部环境
导出产物后执行数据清理
订单结束前确认构建产物、模型配置、测试结果和必要日志已经导出。随后撤销 Runner、删除临时凭据、清理模型与构建缓存，并验证自动化任务不再指向该节点。
- 核对产物完整性与校验信息
- 撤销项目访问和机器关联
- 记录清理结果与未完成事项
责任边界：VMMini 负责订单对应的物理节点服务与控制台记录；用户负责自身代码、访问凭据、软件配置、开放端口、工作负载内容和数据迁出安排。
透明更新机制
事实变更要能找到来源，也要在多语言页面保持一致
配置、价格、节点目录、服务状态和政策会影响采购与运行决策。相关变更通过明确渠道发布，避免一个页面已经更新、另一个语言或控制台仍保留旧信息。
CATALOG产品目录
机型规格、节点范围、周期价格和附加项先进入正式目录，再同步到方案页、下单流程和帮助内容。目录外组合不会以灰色选项展示。
核对方案目录GUIDE操作文档
连接步骤、MLX 服务检查、持续集成排查与数据迁出方法在帮助中心维护。操作变化应同时说明适用场景和需要重新验证的步骤。
打开帮助中心ORDER订单记录
与具体订单相关的节点、周期、支付、事件和支持记录在控制台关联。已有订单的问题优先从控制台提交，以便减少重复描述。
进入控制台POLICY政策条款
数据处理、服务目标、使用责任和争议处理等规则分别写入隐私政策与服务条款。影响用户权利或责任的调整会更新对应正文。
多语言一致性检查
机型规格、四节点目录、价格数字、支付方式、服务目标和联系渠道属于关键事实。更新时按同一来源同步，不因语言版本不同而改变产品边界。
下一步
用实际任务、节点和周期完成一次部署判断
先确认工作负载需要的运行时长、代码源位置、存储容量和退出计划，再选择按天、周、月或季使用。订单统一以 USD 结算。