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

當服務提供商贏得企業資料準備合約時，第一個技術決策不是使用哪個模型或如何構建標記方案。而是工具如何部署在客戶的基礎設施上。

這個決策有連鎖反應：關於時間線（幾天 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 專業知識。

硬體訪問

直接。應用程式通過操作系統的原生 API 訪問 CPU、GPU 和 NPU。沒有虛擬化層，沒有直通配置。GPU 記憶體完全可供應用程式使用。

更新管理

標準應用程式更新。在氣隙環境中，更新通過物理媒體或內部軟件分發系統交付。

---

Docker 容器

基於 Docker 的工具以一個或多個容器映像交付，通常使用 Docker Compose 協調。例如，Label Studio 以 Docker 映像交付，帶有單獨的 PostgreSQL 容器用於元資料。

安裝複雜性

中等。先決條件包括 Docker Engine（或 Docker Desktop）、Docker Compose，以及用於 GPU 工作負載的 NVIDIA Container Toolkit 和兼容驅動。在企業 Linux 系統上，這通常意味著協調 IT 團隊進行軟件包安裝和 Docker 守護程序配置。

總設置時間：對於直接部署 1-4 小時，當企業代理設置、倉庫鏡像或驅動問題使事情複雜化時更長。

運維開銷

中等。Docker 容器需要監控：它們在運行嗎？它們消耗了太多記憶體嗎？卷掛載是否正確配置？Docker Compose 重啟處理基本恢復，但持久狀態管理（卷、綁定掛載）需要注意。

Docker 守護程序更新有時會破壞容器兼容性。NVIDIA Container Toolkit 更新有時會破壞 GPU 訪問。這些不是日常問題，但它們在最糟糕的時刻出現。

安全面積

比原生桌面大。Docker 引入了幾個元件：Docker 守護程序（以 root 運行）、容器網絡、公開端口和卷掛載。每個都是潛在的攻擊向量。容器逃逸漏洞雖然罕見，但對於安全意識強的組織來說是真實的關注點。

許多企業安全團隊要求在批准部署之前審閱 Docker 映像、其基礎層和任何網絡暴露。

氣隙兼容性

可能但困難。氣隙 Docker 部署需要：

1. 在連接互聯網的機器上預先拉取所有容器映像
2. 將映像保存為 tarball（docker save）
3. 通過批准的媒體將 tarball 傳輸到目標機器
4. 加載映像（docker load）
5. 確保所有運行時依賴（模型權重、配置）都已包含

由於缺少映像層、缺少運行時依賴（例如在容器啟動時下載的模型文件），或 Docker Engine 版本之間的版本不匹配，這個過程經常失敗。

領域專家可訪問性

低。非技術用戶無法自助完成 Docker 部署。即使運行工具也需要了解 Docker 命令或包裝腳本。故障排除（容器崩潰、卷問題、端口衝突）需要 Docker 專業知識。

硬體訪問

間接。GPU 訪問需要 NVIDIA Container Toolkit 和適當的設備直通配置。容器內可用的 GPU 記憶體可能少於主機的完整容量，具體取決於配置。2026 年容器內的 NPU 訪問支持較差。

更新管理

拉取新映像，重啟容器。在氣隙環境中，這重複完整的映像傳輸過程。

---

Kubernetes 協調

當多個團隊需要並發訪問資料準備工具，或者工具是更大 ML 平台的一部分時，通常使用 Kubernetes 部署。

安裝複雜性

高。Kubernetes 集群需要托管服務（這是雲端，不是本地端）或使用 kubeadm、k3s 或商業發行版的自管理部署。本地端 Kubernetes 還需要存儲供應商（Rook-Ceph、Longhorn 或 NFS）、負載均衡器（裸金屬的 MetalLB）和入口控制器。

GPU 調度需要 NVIDIA GPU Operator 或手動設備插件配置。設置 GPU 時間切片或 MIG（多實例 GPU）增加了進一步的複雜性。

總設置時間：幾天到幾週，取決於團隊的 Kubernetes 經驗和組織的變更管理流程。

運維開銷

高。Kubernetes 集群需要持續維護：節點更新、憑證輪換、存儲管理、監控（Prometheus/Grafana 堆疊）、日誌聚合和備份。專門的平台工程團隊是規範，而不是例外。

安全面積

大。Kubernetes 引入了 API 服務器、etcd、kubelet、容器運行時、Pod 網絡、服務網格（如果使用）、入口和 RBAC 配置。每個元件都是潛在的漏洞。Kubernetes 安全加固本身就是一門學科。

氣隙兼容性

非常困難。氣隙 Kubernetes 需要：

1. 將所有容器映像預加載到本地倉庫
2. 在氣隙網絡上運行本地倉庫
3. 將 Helm 圖表或清單修改為指向本地倉庫
4. 預加載所有 Operator 映像和依賴
5. 在沒有外部 CA 訪問的情況下進行憑證管理

成功運行氣隙 Kubernetes 的組織通常擁有具有深厚 Kubernetes 專業知識的專門平台團隊。

領域專家可訪問性

非常低。最終用戶通過瀏覽器訪問工具，這沒問題。但部署、維護和故障排除完全是平台工程師的領域。

硬體訪問

由集群管理。GPU 訪問需要 NVIDIA 設備插件，每個 Pod 指定資源請求/限制。多 GPU 配置需要謹慎調度以避免資源爭用。GPU 記憶體在 Pod 層面管理。

更新管理

Helm 圖表升級或清單重新部署。在氣隙環境中，這意味著在升級之前用新映像更新本地倉庫。

---

比較摘要

---

誰需要什麼

單用戶資料準備（大多數企業合約）

企業資料準備的現實：大多數專案涉及 1-3 人為特定用例準備資料。服務提供商派一名 ML 工程師和一名領域專家（或培訓客戶的領域專家）來標記、清理和增強用於微調專案的資料。

對於這種情況，原生桌面是正確的部署模型。設置是即時的。領域專家可以獨立工作。氣隙操作是內置的。合約結束後沒有基礎設施需要維護。

小團隊協作（3-10 人）

當多人需要同時處理相同的資料集時（例如一組標注者標記不同的子集），選項是：

• 帶共享存儲的原生桌面：每個用戶在本地運行應用程式，從共享的 NFS 或 SMB 掛載讀取和寫入。簡單但需要在文件鎖定和任務分配上進行協調。
• Docker 部署：團隊成員通過瀏覽器訪問的集中式實例。當組織已經有 Docker 基礎設施時效果良好。增加了部署開銷但提供了集中狀態。

企業規模多團隊（10 個以上並發用戶）

當一個組織同時運行多個資料準備專案，每個都有專門的團隊時，Kubernetes 就變得相關了。平台團隊為每個專案提供命名空間，管理跨團隊的 GPU 調度，並提供集中監控。

這是 Kubernetes 設計的用例。但它也是資料準備中最罕見的場景。大多數組織並沒有同時運行 10 個資料準備專案。

---

實踐中的工具

幾個流行的資料準備工具說明了這些部署模型的權衡：

Label Studio：以 Docker 映像交付。需要 Docker Compose 用於完整堆疊（應用程式 + PostgreSQL）。氣隙部署需要預先拉取映像並確保資料庫在沒有網絡訪問的情況下正確初始化。非技術用戶無法獨立部署。

IBM Data Prep Kit：基於 Python 的工具包。需要 Python 環境（或 Docker）以及特定管道元件的額外依賴。不是獨立應用程式；它是工程師集成到定制管道中的庫。

Prodigy：基於 Python 但在用戶機器上作為本地 Web 服務器運行。在實踐中更接近原生桌面模型，儘管安裝仍然需要 Python 環境管理。

Ertas Data Suite：使用 Tauri 2.0 構建的原生桌面應用程式。安裝為標準應用程式，除 GPU 驅動（用於加速推理）外沒有先決條件。五個管道模塊（Ingest、Clean、Label、Augment、Export）完全在本地機器上運行，具有可選的 Ollama/llama.cpp 集成用於 AI 輔助標記。

---

做出決定

從滿足你當前實際需求的最簡單部署模型開始，而不是從你未來可能有的需求開始。對於大多數企業資料準備合約，帶有像樣 GPU 的工作站上的原生桌面應用程式是正確的答案。它在幾分鐘內部署，在氣隙環境中無需修改即可運行，並讓領域專家直接訪問他們需要的工具。

當你需要小團隊的集中訪問時，Docker 就變得相關了。當你在平台規模上運營時，Kubernetes 就變得相關了。大多數資料準備專案永遠達不到任何一個門檻。

到準備資料的最快路徑，是在你的團隊和實際工作之間部署障礙最少的那條。