TunePlane 的设计目标是在一台 GPU 服务器上和在受集中治理的多节点集群上都能工作，
而不是为两者各出一个产品。两者之间变的只是「下面这些东西你真正需要哪几样」。
无论如何都需要
团队部署还需要
控制台用哪个 psycopg。 发布镜像里编译的是 psycopg[c]，链基础镜像的 libpq——所以连接
托管 Postgres 时 TLS 校验用的是镜像信任的那套证书，libpq 的安全修复也随下一次镜像重建到位。
psycopg[binary] 是同一份 C 代码，只是把 libpq 和它自己的 OpenSSL 打包进了 wheel，开发环境
用它，因为不需要编译器。自己装 wheel 时二选一：tuneplane-server[c]（需要 libpq-dev 和
编译器）或 tuneplane-server[binary]。两个都不装也能跑，psycopg 会退回纯 Python 绑定：更慢，
但不会坏。
控制台副本多于一个又没有 Redis 的部署，后台角色是被禁用的——存储记账、诊断、
每日日报和看门狗根本不会运行。定时任务页有横幅提示，
但很容易被忽略。 按执行器分
local
agent
kuberay
slurm
一台机器。Docker 或 Podman，真正的 GPU 直通还需要 NVIDIA 容器运行时。别的都不需要。
即使是团队，这也是正确的起点——之后换执行器是改一项设置，不是一次迁移。
多台裸机，每台跑一个 tuneplane-node。要求存储根以同一路径挂载到控制台和每个节点，
并且两侧都持有同一个 Bearer token。缺 token 会拒绝启动，而不是无鉴权运行。
一个装了 KubeRay operator 的 Kubernetes 集群、一个 GPU device plugin，
以及一个承载存储根的 RWX PVC。RWO 的 claim 不会直接失败——
它给每个 Pod 各自一个卷，于是 checkpoint 分片散落在不同节点上，这次 run 再也续不了。
能通过 REST 访问的 slurmrestd，带 JWT。控制平面绝不回退到 sbatch 或 SSH。
容器镜像必须通过 TUNEPLANE_RUNTIME_REGISTRY_FILE 以 SIF 或 SQSH 提供，
容器运行时 profile 必须显式选择。
可选项，以及缺了各自会失去什么
