原生 vs Docker vs Kubernetes：本地 ML 部署对比

当服务提供商赢得企业数据准备项目时，第一个技术决策不是使用哪个模型或如何构建标注 schema。而是工具如何部署在客户的基础设施上。

这个决策有连锁效应：影响时间线（天 vs 周的设置时间）、谁能操作工具（仅 ML 工程师 vs 也包括领域专家）、安全态势（攻击面）、以及客户的 IT 团队是否会批准部署。

三种部署模型主导了本地数据准备领域。每种做出不同的权衡。

---

原生桌面应用

原生桌面应用像任何其他程序一样安装在目标机器上。在 macOS 上是 .dmg 或 .app。在 Windows 上是 .msi 或 .exe 安装程序。在 Linux 上是 .deb、.rpm 或 AppImage。

安装复杂度

最低。下载安装程序，运行，启动应用。整个过程需要 2-10 分钟。除了操作系统本身（如果需要 GPU 推理则还需 GPU 驱动）外，不需要前置软件。

运维开销

接近零。应用管理自己的数据目录、配置和进程生命周期。更新是应用级别的：下载新版本并覆盖安装。没有守护进程需要监控，没有容器仓库需要维护，没有集群需要保持健康。

安全攻击面

小。应用作为单个用户空间进程运行。它不监听网络端口（除非本地 LLM 推理使用 localhost）。没有 Web 服务器，没有认证层，没有暴露给网络的 API。

离线环境兼容性

原生支持。安装后，应用不需要网络连接。本地 LLM 推理的模型权重可通过 USB 或批准的介质传输。

领域专家可访问性

高。合规官、法律审查员或医疗编码员可以在没有 DevOps 支持的情况下安装和使用原生桌面应用。这很重要，因为数据准备质量取决于领域专业知识，而非 ML 专业知识。

---

Docker 容器

基于 Docker 的工具以一个或多个容器镜像形式交付，通常使用 Docker Compose 编排。

安装复杂度

中等。前置条件包括 Docker Engine、Docker Compose，对于 GPU 工作负载还需要 NVIDIA Container Toolkit 和兼容驱动。总设置时间：1-4 小时。

运维开销

中等。Docker 容器需要监控：它们是否在运行？是否消耗了太多内存？Docker 守护进程更新有时会破坏容器兼容性。NVIDIA Container Toolkit 更新有时会破坏 GPU 访问。

安全攻击面

比原生桌面大。Docker 引入了几个组件：Docker 守护进程（以 root 运行）、容器网络、暴露端口和卷挂载。

离线环境兼容性

可能但困难。离线 Docker 部署需要预拉取所有容器镜像、保存为 tarball、传输到目标机器、加载镜像，并确保所有运行时依赖都包含在内。

领域专家可访问性

低。非技术用户无法自助 Docker 部署。

---

Kubernetes 编排

Kubernetes 部署通常用于多个团队需要并发访问数据准备工具的场景。

安装复杂度

高。需要自管理的 Kubernetes 集群加上存储供应商、负载均衡器和入口控制器。总设置时间：天到周。

运维开销

高。需要持续维护：节点更新、证书轮换、存储管理、监控。需要专门的平台工程团队。

离线环境兼容性

非常困难。需要本地镜像仓库、预加载所有操作员镜像、修改 Helm chart 指向本地仓库。

---

对比总结

---

谁需要什么

单用户数据准备（大多数企业项目）

企业数据准备的现实：大多数项目涉及 1-3 人为特定用例准备数据。对于这种场景，原生桌面是正确的部署模型。

小团队协作（3-10 人）

当多人需要同时处理同一数据集时，选择带共享存储的原生桌面或 Docker 部署。

企业级多团队（10+ 并发用户）

当组织同时运行多个数据准备项目时，Kubernetes 变得相关。但这也是数据准备中最罕见的场景。

---

做出决策

从满足当前实际需求的最简单部署模型开始，而不是从你将来可能有的需求开始。对于大多数企业数据准备项目，配备不错 GPU 的工作站上的原生桌面应用是正确的答案。它在几分钟内部署，无需修改即可在离线环境中运行，并让领域专家直接使用他们需要的工具。

到达准备好数据的最快路径是在团队和实际工作之间障碍最少的路径。