我拆出 Worker 的理由很实际：VPS 要一直响应网页请求，模型推理则希望用上我手边更合适的机器。两边的资源需求不一样。
要解决什么
让一台不适合承担长时间推理的 VPS，仍然能提供稳定的任务入口。边缘机器暂时不在线时，任务可以等待，页面还能查状态。
有哪些方案
| 方案 | 得到什么 | 要付出什么 |
|---|---|---|
| 全部放 VPS | 部署简单 | 推理与在线请求争用资源 |
| VPS 调用外部推理 API | 运维较少 | 成本和能力依赖外部服务 |
| VPS 管任务，自己的设备执行 | 能使用现有硬件 | 要处理网络和节点离线 |
我选第三种。先保留当前云端服务划分，不为了这个目标再增加数据库或网关。
第一版怎样落地
VPS 运行 API、任务协调和队列；对象存储保存文件；边缘 Worker 主动连接队列和上报接口，不要求家庭网络接受云端主动入站。
第一步只接一台机器。确认它能访问队列、上报服务和签名文件地址。开发环境里的 api、minio、host.minikube.internal 不是跨网络通用地址。现有默认账号和明文内部连接也不能原样暴露到公网；先通过私有网络连通，再配独立凭证与最小权限。
NVIDIA 节点和 Mac 节点分别准备运行包。whisper.cpp 提供对应的 GPU 加速能力，但我会固定版本，并用启动日志与一次基准确认实际启用的后端。Mac 的 Metal 验证先使用原生进程，不能把 Linux 容器跑起来当成已经用上 Metal。whisper.cpp 说明
当前转码主要是音轨提取和重采样，不预设它也必须用 GPU。先测耗时，再决定放普通 CPU 节点还是与转写共置。
第一次部署只设一个执行槽位。节点停止接单后允许当前任务收尾。心跳、租约和多节点分配放到后面的步骤实现。
怎么知道有效
在边缘机器开始转写时，持续请求 VPS 的任务列表，记录延迟与 VPS 内存。停止所有 Worker，提交的新任务应保持等待；恢复一个 Worker 后继续执行。
这证明了计算和在线请求可以分开部署。它还不能证明容灾，也不能证明成本一定降低，后面要把传输和维护成本一起测进去。
先交付一份两台机器的运行记录：地址如何配置、模型怎样加载、任务怎样回来。别急着接第二种硬件。