企業 AI 資料準備的本地端運行時架構

大多數企業 AI 項目將其 60 到 80% 的時間花在資料準備上。攝入、清理、標記、增強、導出——這些步驟在單次訓練運行開始之前發生。對於受監管行業的組織，這項工作必須在他們控制的基礎設施上進行。

您為本地端資料準備選擇的架構決定了您的吞吐量、操作複雜性，以及領域專家是否實際上可以在沒有 ML 工程師陪同的情況下使用工具。本指南涵蓋在實踐中有效的部署模型、計算要求和基礎設施模式。

部署模型：第一個決定

三種部署方法主導了本地端資料準備工具：

原生桌面應用程式

應用程式像任何其他程式一樣安裝。它作為本地進程運行，可以直接訪問 CPU、GPU 和文件系統。沒有容器，沒有編排層，沒有 Web 伺服器。安裝需要幾分鐘。更新是應用程式級別的——下載並安裝。

優點：零 DevOps 開銷。領域專家可以自己安裝和運行工具。氣隔操作是內置的——安裝後應用程式完全離線運行。直接的硬體訪問意味著 GPU 推理不需要通過虛擬化層。

局限性：單機範圍。在團隊中擴展需要共享存儲或工具外的協調。

Docker 容器

工具以一個或多個容器映像發布。部署需要 Docker（或 Podman），複雜的工具通常需要 Docker Compose 或類似的編排。GPU 訪問需要 NVIDIA Container Toolkit 和正確的驅動程序配置。

優點：可重複的環境。在不同主機作業系統之間保持一致的行為。DevOps 團隊熟悉的部署模型。

局限性：GPU 直通增加了配置複雜性。Docker 本身是一個安全面。氣隔部署需要預拉映像和所有依賴項——這個過程通常因缺少層或運行時依賴項而失敗。領域專家無法自助服務；他們需要工程支援來部署和排查問題。

自主託管 Web 應用程式（有或無 Kubernetes）

工具作為 Web 服務運行，通常在 Nginx 或 Traefik 後面。Kubernetes 部署增加了服務發現、擴展和健康監控。

優點：通過瀏覽器的多用戶訪問。集中式計算資源。Kubernetes 為批次工作負載啟用自動擴展。

局限性：最高的操作複雜性。需要網路、TLS 配置、身份驗證和持續的集群管理。Kubernetes 中的 GPU 調度需要 NVIDIA 設備插件和仔細的資源配額。氣隔的 Kubernetes 部署出了名地困難。

按管道階段的計算要求

資料準備不是單一的工作負載。每個階段都有不同的計算特性：

攝入

主要是 I/O 密集型。瓶頸是從磁盤或網路存儲讀取文件——PDF 解析、圖像解碼、文字提取。SSD 存儲比 CPU 速度更重要。現代 NVMe 驅動器可以以 3 至 7 GB/s 的速度讀取，而旋轉磁盤的上限為 100 至 200 MB/s。對於大型文件存檔，這個差異是以小時計算的。

攝入期間的 CPU 使用率是中等的。大多數格式（PDF、DOCX、HTML）使用單線程解析庫，因此更多核心只有在並行處理許多文件時才有幫助。

典型要求：4 個以上 CPU 核心、16 GB RAM、NVMe SSD。

OCR（光學字元識別）

CPU 密集型或 GPU 加速，取決於引擎。Tesseract 在 CPU 上運行，每秒處理約 1 至 3 頁。GPU 加速的 OCR 引擎（PaddleOCR、EasyOCR）在中階 GPU 上可以達到每秒 10 至 30 頁。

對於掃描文件存檔，OCR 通常是管道中最慢的階段。以每秒 2 頁計算，100,000 頁的存檔僅使用 CPU OCR 大約需要 14 小時。

典型要求：建議使用 GPU（8 GB 以上 VRAM），批次處理 32 GB RAM。

清理和去重複

CPU 和記憶體密集型。大型資料集的去重複需要在記憶體中保存相似度雜湊值。100 萬文件的精確去重是直接的；大規模的模糊去重（MinHash、SimHash）需要大量 RAM。

個人識別資訊偵測和編輯增加了 CPU 負載。基於正則表達式的個人識別資訊偵測速度很快；基於 NER 的偵測（使用小型語言模型）速度較慢但更準確。

典型要求：8 個以上 CPU 核心，32 至 64 GB RAM 取決於資料集大小。

使用本地 LLM 標記

使用 AI 輔助標記時為 GPU 密集型。Q4 量化的 70 億參數模型大約需要 4 至 5 GB VRAM，對於分類任務每分鐘可以處理 20 至 50 個文件。Q4 的 140 億模型需要 8 至 10 GB VRAM，速度大約是前者的一半。

手動標記在計算上是微不足道的——瓶頸是人的速度，而非計算資源。

典型要求：8 GB 以上 VRAM 的 GPU（建議 16 GB），32 GB 系統 RAM。

增強和合成生成

類似於標記——使用本地 LLM 進行合成資料生成時為 GPU 密集型。較長的輸出（生成合成文件 vs. 生成標籤）增加了每個項目的 GPU 時間。在 70 億 Q4 硬體上生成 500 字的合成文件，根據硬體每分鐘大約產生 5 至 15 個文件。

典型要求：8 至 16 GB VRAM 的 GPU，32 GB 系統 RAM。

導出

I/O 密集型。將處理後的資料轉換為訓練格式（JSONL、Parquet、HuggingFace 資料集）受限於寫入速度。壓縮增加了 CPU 負載。在 NVMe 上導出 100 GB 處理後的資料需要 10 至 30 分鐘，在 HDD 上更長。

典型要求：NVMe SSD、16 GB RAM、中等 CPU。

三個硬體層級

並非每個資料準備項目都需要相同的基礎設施。以下是在每個規模下的有效方案：

第一層：輕量級（僅 CPU，低於 100 GB 資料）

硬體：現代工作站或筆記型電腦。8 個以上核心、32 GB RAM、1 TB NVMe SSD。
成本：1,500 至 3,000 美元
使用案例：小型文件集、以文字為主的資料、手動標記工作流程
LLM 推理：通過 llama.cpp 僅使用 CPU。速度較慢（70 億模型每秒 2 至 5 個 Token），但對小批次預標注是可行的。
OCR：僅 CPU 的 Tesseract。適合低於 10,000 頁。

這一層處理概念驗證項目和小規模生產資料準備。許多企業合作從這裡開始。

第二層：中階（GPU 加速，100 GB 至 1 TB）

硬體：帶有專用 GPU 的工作站。16 個以上核心、64 GB RAM、2 TB NVMe、NVIDIA RTX 4070/4080（12 至 16 GB VRAM）或等效。
成本：5,000 至 10,000 美元
使用案例：生產資料準備、AI 輔助標記、合成增強
LLM 推理：通過 Ollama 或 llama.cpp 進行 GPU 加速。70 億 Q4 每秒 30 至 80 個 Token。對交互式標記工作流程足夠快。
OCR：GPU 加速。每秒 10 至 30 頁。

這是主力層。這個層次上的單個工作站處理大多數企業 AI 項目的資料準備需求——包括客戶認為需要 GPU 集群的那些。

第三層：重型（多 GPU，超過 1 TB）

硬體：帶有 2 至 4 個 GPU 的伺服器或高端工作站。32 個以上核心、128 至 256 GB RAM、4 TB 以上 NVMe（或 NVMe RAID）、NVIDIA RTX 4090 或 A6000（每個 GPU 24 至 48 GB VRAM）。
成本：20,000 至 50,000 美元
使用案例：大規模企業資料準備、並行管道階段、140 億以上模型推理
LLM 推理：多 GPU 使更大的模型（300 億以上）或跨多個資料集的並行推理成為可能。
OCR：帶 GPU 加速的批次優化。隔夜處理 100,000 頁以上的存檔。

大多數組織發現資料準備不需要這一層。常見的誤解：「我們有 2 TB 的文件，所以我們需要一個大型 GPU 集群。」實際上，資料準備按順序或小批次處理文件。2 TB 在幾天而非幾分鐘內通過中階工作站——而這個時間表通常是可以的，因為資料準備是一次性或定期的任務，而非實時服務。

本地 LLM 推理架構

本地 LLM 推理是最大改變資料準備工作流程的組件。不是將文件發送到雲端 API，而是模型在與資料準備工具相同的機器（或相同網路上的機器）上運行。

兩種主要的推理後端：

Ollama：管理模型下載、量化變體和 GPU 分配。在 localhost 提供 OpenAI 相容的 API。設置簡單；良好的模型庫。開銷最小——Ollama 在 llama.cpp 上添加了一個薄的 HTTP 層。

llama.cpp：無 HTTP 層的直接推理。配置稍微複雜，但對記憶體分配、批次大小和線程提供更精細的控制。在 Ollama 的模型倉庫無法訪問的氣隔環境中更受青睞。

兩者都支援 GGUF 模型格式。對於資料準備任務——分類、實體提取、預標注——70 億至 140 億範圍的指令跟隨模型提供了速度和準確性的最佳平衡。更大的模型（300 億以上）很少能提升足夠的標記品質來證明吞吐量減少是合理的。

存儲架構

資料準備涉及讀取大量源資料、寫入中間結果，以及生成最終輸出。存儲 I/O 在每個階段都是瓶頸。

源資料：存儲在最快的可用媒體上。NVMe SSD 是首選。如果源資料在網路存儲（NFS、SMB）上，在處理前將其複製到本地 SSD。網路 I/O 延遲在數百萬次文件讀取中積累。

中間資料：OCR 結果、提取的文字、嵌入和部分處理輸出。這些可以是源資料大小的 2 至 5 倍。確保完整中間資料集有足夠的本地 SSD 容量。

輸出資料：最終標記、增強和導出的資料集。通常比中間資料小，但仍然很重要。盡可能直接導出到目標（訓練伺服器、共享存儲）。

經驗法則：為完整管道運行配備本地 NVMe 容量為源資料大小的 3 至 5 倍。

網路——或其缺失

在氣隔環境中，沒有網路需要配置。資料準備工具、本地 LLM 和資料都駐留在同一台機器或物理隔離的網路段上。這是最簡單的網路架構——對許多受監管環境來說，這是一個要求。

對於連接的本地端部署，單用戶資料準備的網路考量是最小的。如果多個團隊成員需要訪問結果，共享的 NFS/SMB 掛載或簡單的文件同步機制就足夠了。資料準備工具不需要複雜的服務網格、負載均衡器或入口控制器。

原生桌面架構在實踐中的應用

Ertas Data Suite 對這個問題採用了原生桌面方法。基於 Tauri 2.0（Rust 後端，React 前端）構建，它作為標準桌面應用程式安裝，完全在本地機器上運行。五個管道模組——攝入、清理、標記、增強、導出——共享一個通用的本地資料存儲，並通過作業系統直接訪問 CPU、GPU 和 NPU 硬體。

本地 LLM 推理通過 Ollama 或 llama.cpp 在同一台機器上整合運行。標記界面和模型之間沒有網路跳轉——應用程式通過 localhost 與推理後端通訊。

這種架構消除了使 Label Studio（Docker/Docker Compose）和 IBM Data Prep Kit（Python 環境 + Docker）等工具對領域專家不可訪問的部署複雜性。合規官或主題專家可以安裝應用程式、打開資料集，並在不等待 ML 工程師設置基礎設施的情況下開始標記。

選擇您的架構

決策矩陣比供應商所說的更簡單：

因素	原生桌面	Docker	Kubernetes
用戶數	1 至 3	3 至 10	10 以上
設置時間	幾分鐘	幾小時	幾天
操作開銷	無	低至中	高
氣隔相容	是	可能	困難
領域專家訪問	直接	需要支援	需要支援
GPU 訪問	直接	直通	設備插件

對於大多數為企業客戶提供 AI 解決方案的服務提供商，資料準備階段涉及 1 至 3 人在定義的資料集上工作。原生桌面模型處理這個問題。當您為多個並行項目運行共享資料準備平台時，Kubernetes 變得相關——這是一個與為特定合作準備資料不同的問題。