企业 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 device plugin 和精细的资源配额。气隙环境下的 Kubernetes 部署更是出了名的难。

各流水线阶段的计算需求

数据准备不是单一负载，每个阶段的计算特征都不一样：

采集

主要受 I/O 限制。瓶颈在于从磁盘或网络存储读取文档，也就是 PDF 解析、图像解码和文本抽取。这里 SSD 比 CPU 主频更重要。现代 NVMe 硬盘的读取速度可达 3-7 GB/s，机械硬盘的上限只有 100-200 MB/s。面对大型文档归档，这个差距要用小时来衡量。

采集阶段的 CPU 占用属于中等。多数格式（PDF、DOCX、HTML）使用单线程解析库，因此只有在并行处理大量文件时，更多核心才有意义。

典型配置需求：4 核以上 CPU、16 GB 内存、NVMe SSD。

OCR（光学字符识别）

视引擎而定，可能是 CPU 密集型，也可能由 GPU 加速。Tesseract 跑在 CPU 上，大约每秒处理 1-3 页。GPU 加速的 OCR 引擎（PaddleOCR、EasyOCR）在中端 GPU 上能达到每秒 10-30 页。

对于扫描件归档，OCR 常常是整条流水线里最慢的一环。10 万页的归档按每秒 2 页计算，纯 CPU 的 OCR 大约要跑 14 小时。

典型配置需求：建议配 GPU（8 GB 以上显存），批处理场景需要 32 GB 内存。

清洗与去重

受 CPU 和内存限制。在大数据集上去重，需要把相似度哈希放在内存里。100 万篇文档的精确去重很轻松；规模化的模糊去重（MinHash、SimHash）则需要可观的内存。

PII 检测与脱敏会进一步增加 CPU 负载。基于正则的 PII 检测很快；基于 NER 的检测（用一个小语言模型）更慢，但也更准确。

典型配置需求：8 核以上 CPU、32-64 GB 内存，具体取决于数据集规模。

用本地 LLM 做标注

采用 AI 辅助标注时属于 GPU 密集型。一个 Q4 量化的 7B 参数模型大约需要 4-5 GB 显存，在分类任务下每分钟可处理 20-50 篇文档。Q4 量化的 14B 模型需要 8-10 GB 显存，速度大约减半。

人工标注对算力几乎没有压力，瓶颈是人的速度而不是计算。

典型配置需求：8 GB 以上显存的 GPU（推荐 16 GB）、32 GB 系统内存。

增强与合成生成

与标注类似，用本地 LLM 生成合成数据时受 GPU 限制。输出越长（生成合成文档远比生成标签长），每条数据占用的 GPU 时间就越多。用 7B Q4 生成 500 词的合成文档，视硬件不同，大约每分钟 5-15 篇。

典型配置需求：8-16 GB 显存的 GPU、32 GB 系统内存。

导出

受 I/O 限制。把处理好的数据转换成训练格式（JSONL、Parquet、HuggingFace datasets）受写入速度制约，压缩还会增加 CPU 负载。导出 100 GB 处理后的数据，在 NVMe 上需要 10-30 分钟，机械硬盘则更久。

典型配置需求：NVMe SSD、16 GB 内存、中等水平的 CPU。

三种硬件层级

并非每个数据准备项目都需要同样的基础设施。以下是各个规模下行之有效的配置：

层级 1：轻量（纯 CPU，数据量 100 GB 以内）

硬件：现代工作站或笔记本。8 核以上、32 GB 内存、1 TB NVMe SSD。
成本：1,500-3,000 美元
适用场景：小型文档集、以文本为主的数据、人工标注流程
LLM 推理：通过 llama.cpp 纯 CPU 运行。速度偏慢（7B 模型每秒 2-5 tokens），但用于小批量预标注是够用的。
OCR：纯 CPU 的 Tesseract。1 万页以内没问题。

这一层级适合概念验证项目和小规模的生产数据准备。很多企业合作都是从这里起步的。

层级 2：中端（GPU 加速，100 GB 到 1 TB）

硬件：配独立 GPU 的工作站。16 核以上、64 GB 内存、2 TB NVMe、NVIDIA RTX 4070/4080（12-16 GB 显存）或同级产品。
成本：5,000-10,000 美元
适用场景：生产环境的数据准备、AI 辅助标注、合成数据增强
LLM 推理：通过 Ollama 或 llama.cpp 做 GPU 加速。7B Q4 每秒 30-80 tokens，足以支撑交互式标注流程。
OCR：GPU 加速，每秒 10-30 页。

这是主力层级。这个级别的单台工作站，就能覆盖大多数企业 AI 项目的数据准备需求，包括那些客户以为非上 GPU 集群不可的项目。

层级 3：重载（多 GPU，1 TB 以上）

硬件：配 2-4 块 GPU 的服务器或高端工作站。32 核以上、128-256 GB 内存、4 TB 以上 NVMe（或 NVMe RAID）、NVIDIA RTX 4090 或 A6000（每块 GPU 24-48 GB 显存）。
成本：20,000-50,000 美元
适用场景：大规模企业数据准备、多个流水线阶段并发、14B 以上模型的推理
LLM 推理：多 GPU 可以跑更大的模型（30B 以上），或者在多个数据集上并行推理。
OCR：GPU 加速下的批处理优化，一夜之间就能处理完 10 万页以上的归档。

大多数组织最后会发现，数据准备并不需要这一层级。常见的误解是：「我们有 2 TB 文档，所以需要一个庞大的 GPU 集群。」实际情况是，数据准备按顺序或以小批量处理文档。这 2 TB 数据会在一台中端工作站上跑上几天而不是几分钟，而这个时间通常完全可以接受，因为数据准备是一次性或周期性的任务，而非实时服务。

本地 LLM 推理架构

本地 LLM 推理是对数据准备流程改变最大的一个组件。文档不再发往云端 API，模型就跑在数据准备工具所在的那台机器上，或者同一网络内的另一台机器上。

主要的推理后端有两个：

Ollama：负责管理模型下载、量化版本和 GPU 分配，并在 localhost 上提供 OpenAI 兼容的 API。上手容易，模型库丰富。开销很小，它只是在 llama.cpp 之上加了一层很薄的 HTTP。

llama.cpp：不带 HTTP 层的直接推理。配置略复杂一些，但对内存分配、批大小和线程数有更细的控制。在 Ollama 的模型仓库无法访问的气隙环境里，它是首选。

两者都支持 GGUF 模型格式。对于分类、实体抽取、预标注这类数据准备任务，7B 到 14B 区间的指令跟随模型在速度和准确率之间取得了最好的平衡。更大的模型（30B 以上）对标注质量的提升，很少能抵得上吞吐量的下降。

存储架构

数据准备要读取大量源数据、写入中间结果、产出最终输出。存储 I/O 在每个阶段都是瓶颈。

源数据：放在可用的最快介质上，首选 NVMe SSD。如果源数据存放在网络存储上（NFS、SMB），先复制到本地 SSD 再处理。网络 I/O 的延迟会在数百万次文件读取中累积起来。

中间数据：包括 OCR 结果、抽取出的文本、嵌入向量和各类中途产物。这些数据可能达到源数据的 2-5 倍，要确保本地 SSD 装得下完整的中间数据集。

输出数据：最终标注、增强并导出的数据集。通常比中间数据小，但体量依然可观。条件允许时直接导出到目标位置，比如训练服务器或共享存储。

经验法则：为一次完整的流水线运行，按源数据大小的 3-5 倍准备本地 NVMe 容量。

网络，或者说没有网络

在气隙环境里，根本没有网络需要配置。数据准备工具、本地 LLM 和数据全都待在同一台机器上，或者同一个物理隔离的网段内。这是可能存在的最简单的网络架构，而对许多受监管的环境来说，它本身就是一条硬性要求。

至于联网的本地部署，单用户的数据准备几乎不用考虑网络。如果团队其他成员需要访问结果，一个共享的 NFS/SMB 挂载点或简单的文件同步机制就够了。数据准备工具用不上复杂的服务网格、负载均衡器或 ingress 控制器。

原生桌面架构的实际形态

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 访问方式	直接访问	直通	Device plugin

对多数向企业客户交付 AI 方案的服务商来说，数据准备阶段就是 1 到 3 个人围绕一个确定的数据集干活，原生桌面模型完全应付得来。只有当你要为多个并行项目运营一个共享的数据准备平台时，Kubernetes 才真正相关，而那是另一个问题，跟为某一次具体交付准备数据不是一回事。