基准测试：100GB+ 企业数据集的本地数据准备管道吞吐量
本地数据准备的真实吞吐量基准——按文档类型和硬件配置的摄入、OCR、清洗、标注和导出速度。
每一家为企业 AI 项目交付数据准备服务的服务商，在需求梳理阶段都会遇到同一个问题：「这要做多久？」
答案取决于文档类型、数据集规模、管道阶段和硬件。在编写带固定时间线的工作说明书时，「几周吧」这类模糊估算帮不上忙。具体的吞吐量数字才管用。
本指南给出各个管道阶段在不同文档类型和硬件配置下的真实基准数据。这些数字来自常见配置，而非理想化的实验室环境。把它们当作项目定价与排期的基线来用。
方法说明
所有基准测试均基于以下假设：
- 单机处理（非分布式）
- 文档按管道阶段顺序批量处理（全部摄入 → 全部清洗 → 全部标注 → 全部导出）
- OCR 引擎和推理后端使用默认配置（无特殊调优）
- 吞吐量按初始预热之后的持续速率计算，而非峰值瞬时速率
涉及的硬件配置：
| 配置 | CPU | 内存 | GPU | 存储 |
|---|---|---|---|---|
| 入门级 | Ryzen 7 7700 (8c/16t) | 32 GB | RTX 4060 Ti 16GB | 2 TB NVMe |
| 中端 | Ryzen 9 7950X (16c/32t) | 64 GB | RTX 4080 16GB | 4 TB NVMe |
| 生产级 | Threadripper 7970X (32c/64t) | 128 GB | 2× RTX 4090 24GB | 8 TB NVMe |
阶段 1：摄入吞吐量
摄入阶段负责读取源文件、解析其结构，并抽取原始内容（文本、图像、元数据）。
按文档类型
| 文档类型 | 平均大小 | 入门级（文档/分钟） | 中端（文档/分钟） | 生产级（文档/分钟） |
|---|---|---|---|---|
| 原生 PDF（文本型） | 500 KB | 200-400 | 400-800 | 800-1,500 |
| 扫描 PDF（图像型） | 5 MB | 60-120 | 120-250 | 250-500 |
| Word（.docx） | 200 KB | 300-600 | 600-1,200 | 1,200-2,000 |
| Excel（.xlsx） | 1 MB | 100-200 | 200-400 | 400-800 |
| 纯文本 / CSV | 50 KB | 1,000-3,000 | 3,000-8,000 | 8,000-15,000 |
| 图像（JPEG/PNG） | 2 MB | 150-300 | 300-600 | 600-1,200 |
| HTML | 100 KB | 500-1,000 | 1,000-2,000 | 2,000-4,000 |
| 邮件（.eml/.msg） | 100 KB | 200-400 | 400-800 | 800-1,500 |
摄入瓶颈分析
原生 PDF：受限于 CPU。单个文件的 PDF 解析是单线程的，因此吞吐量随并行工作进程数增长（上限由 CPU 核心数和 I/O 决定）。
扫描 PDF：受限于 I/O。每一页都是一张需要解压的大图，存储速度起决定作用。
Excel 文件：处理大型表格时受限于内存。一个 50 MB 的 Excel 文件在内存中可能膨胀到 500 MB 以上，并行处理能力由内存容量决定。
100 GB 到底是多少
一份 100 GB 的企业档案通常混合了多种文档类型。一个有代表性的分布如下：
| 类型 | 占比 | 文件数（约） | 总大小（约） |
|---|---|---|---|
| 原生 PDF | 40% | 80,000 个文件 | 40 GB |
| 扫描 PDF | 25% | 5,000 个文件 | 25 GB |
| Word/Excel | 20% | 40,000 个文件 | 20 GB |
| 图像 | 10% | 5,000 个文件 | 10 GB |
| 其他（文本、HTML、邮件） | 5% | 20,000 个文件 | 5 GB |
| 合计 | 约 150,000 个文件 | 100 GB |
该组合在中端硬件上的摄入耗时：约 4-8 小时。扫描 PDF 只占 25% 的体量，却主导了整条时间线。
阶段 2：OCR 吞吐量
OCR 只作用于扫描件和图像，文本型文档会跳过这一阶段。
按引擎和硬件
| 引擎 | 硬件 | 页/秒 | 准确率（清晰扫描件） | 准确率（低质量扫描件） |
|---|---|---|---|---|
| Tesseract 5 | CPU（8 核） | 1-3 | 90-95% | 70-80% |
| Tesseract 5 | CPU（16 核） | 2-5 | 90-95% | 70-80% |
| PaddleOCR | CPU（16 核） | 3-6 | 92-96% | 75-85% |
| PaddleOCR | GPU（RTX 4070） | 15-25 | 92-96% | 75-85% |
| PaddleOCR | GPU（RTX 4090） | 25-40 | 92-96% | 75-85% |
| EasyOCR | GPU（RTX 4070） | 10-18 | 90-94% | 70-82% |
| Surya OCR | GPU（RTX 4070） | 20-30 | 94-97% | 80-88% |
| Surya OCR | GPU（RTX 4090） | 30-50 | 94-97% | 80-88% |
OCR 耗时估算
| 档案规模（扫描页数） | 仅 CPU（Tesseract） | GPU 中端 | GPU 生产级 |
|---|---|---|---|
| 10,000 页 | 1-3 小时 | 7-12 分钟 | 4-7 分钟 |
| 50,000 页 | 5-14 小时 | 35-55 分钟 | 17-33 分钟 |
| 100,000 页 | 10-28 小时 | 1.1-1.8 小时 | 0.6-1.1 小时 |
| 500,000 页 | 2-6 天 | 5.5-9.2 小时 | 2.8-5.5 小时 |
| 1,000,000 页 | 4-12 天 | 11-18 小时 | 5.5-11 小时 |
关键结论：在包含扫描件的管道里，OCR 是最大的单项耗时。如果客户的档案以扫描 PDF 为主，OCR 吞吐量就决定了整个项目的时间线。
阶段 3：清洗吞吐量
清洗包括去重、格式规范化、PII 检测与脱敏，以及质量过滤。
按操作类型
| 操作 | 方法 | 吞吐量（中端） | 内存占用 |
|---|---|---|---|
| 精确去重 | SHA-256 哈希 | 50,000-100,000 文档/分钟 | 低（100 万文档占用不到 1 GB） |
| 模糊去重（MinHash） | 128 个排列 | 5,000-15,000 文档/分钟 | 每 100 万文档 2-4 GB |
| PII 检测（正则） | 模式匹配 | 10,000-30,000 文档/分钟 | 低 |
| PII 检测（NER 模型） | GLiNER / SpaCy NER | 500-2,000 文档/分钟 | 2-4 GB 显存 |
| PII 脱敏 | 替换检测到的 PII | 与检测阶段相同 | 相同 |
| 格式规范化 | Unicode 与空白字符清理 | 20,000-50,000 文档/分钟 | 低 |
| 质量过滤 | 长度、语言、连贯性 | 10,000-30,000 文档/分钟 | 低 |
清洗耗时估算
以一份 150,000 份文档的档案为例（即上文那份 100 GB 的组合）：
| 操作 | 中端耗时 |
|---|---|
| 精确去重 | 2-3 分钟 |
| 模糊去重 | 10-30 分钟 |
| 正则 PII 检测 | 5-15 分钟 |
| NER PII 检测 | 1.5-5 小时 |
| 格式规范化 | 3-8 分钟 |
| 质量过滤 | 5-15 分钟 |
| 合计（含 NER PII 检测） | 约 2-6 小时 |
| 合计（仅正则 PII 检测） | 约 25-70 分钟 |
基于 NER 的 PII 检测是清洗阶段的瓶颈。如果项目里用正则做 PII 检测就够了（例如金融文档中社会保障号、账号这类结构化 PII），清洗会很快。而对叙述性文本中的非结构化 PII，NER 会显著拉长耗时。
阶段 4：标注吞吐量
人工标注
人工标注速度因任务复杂度和标注员经验差异巨大：
| 任务 | 速度（有经验的标注员） | 文档/天（8 小时） |
|---|---|---|
| 二分类 | 5-10 秒/文档 | 2,800-5,700 |
| 多分类（5-10 个类别） | 10-30 秒/文档 | 960-2,800 |
| 命名实体标注 | 1-5 分钟/文档 | 96-480 |
| 片段级标注 | 2-10 分钟/文档 | 48-240 |
| 复杂多标签 | 30-120 秒/文档 | 240-960 |
AI 辅助标注（预标注 + 人工审核）
预标注阶段使用本地 LLM 推理，人工审核耗时取决于预标注的准确率。
预标注吞吐量（LLM 推理）：
| 任务 | 模型 | 量化 | 硬件 | 文档/小时 |
|---|---|---|---|---|
| 二分类 | Mistral 7B | Q4_K_M | RTX 4070 | 2,500-3,500 |
| 多分类（5 类） | Mistral 7B | Q4_K_M | RTX 4070 | 2,000-3,000 |
| 多分类（5 类） | Qwen 2.5 14B | Q4_K_M | RTX 4080 | 1,000-1,800 |
| 实体抽取 | Qwen 2.5 14B | Q5_K_M | RTX 4080 | 800-1,400 |
| 文档摘要 | Qwen 2.5 14B | Q4_K_M | RTX 4080 | 300-500 |
人工审核吞吐量（审核预标注结果）：
| 预标注准确率 | 审核速度 | 相对人工标注的有效吞吐量 |
|---|---|---|
| 正确率 >90% | 3-5 秒/文档（确认或修正） | 比纯人工快 5-10 倍 |
| 正确率 80-90% | 5-15 秒/文档 | 比纯人工快 3-5 倍 |
| 正确率 70-80% | 10-30 秒/文档 | 比纯人工快 1.5-3 倍 |
| 正确率低于 70% | 15-60 秒/文档 | 提升微乎其微 |
盈亏平衡点：当预标注准确率低于约 70% 时，审核员花在理解和纠正错误上的时间会超过从零开始标注。此时 AI 辅助反而成了干扰，而不是加速器。
综合标注时间线
以 150,000 份文档做二分类为例：
| 方式 | 时间估算 |
|---|---|
| 人工（2 名标注员） | 13-27 个工作日 |
| AI 辅助（准确率 90%，2 名审核员） | 2-4 个工作日 |
| AI 辅助（准确率 80%，2 名审核员） | 4-8 个工作日 |
预标注准确率高于 80% 的 AI 辅助标注，可以把标注速度提升 3-10 倍。
阶段 5：增强吞吐量
合成数据生成的吞吐量取决于输出长度：
| 任务 | 模型 | 硬件 | 输出长度 | 文档/小时 |
|---|---|---|---|---|
| 改写生成 | Mistral 7B Q4 | RTX 4070 | 约 100 tokens | 1,500-2,500 |
| 合成文档生成 | Qwen 2.5 14B Q4 | RTX 4080 | 约 500 tokens | 100-200 |
| 增强样本（分类） | Mistral 7B Q4 | RTX 4070 | 约 50 tokens | 3,000-5,000 |
| 问答对生成 | Qwen 2.5 14B Q4 | RTX 4080 | 约 200 tokens | 400-700 |
阶段 6：导出吞吐量
导出很少成为瓶颈：
| 格式 | 大小（150K 文档） | NVMe 写入耗时 | SATA SSD 写入耗时 |
|---|---|---|---|
| JSONL | 5-20 GB | 1-5 秒 | 10-40 秒 |
| JSONL（gzip 压缩） | 1-5 GB | 30-120 秒 | 60-240 秒 |
| Parquet | 3-12 GB | 1-5 秒 | 10-40 秒 |
| HuggingFace Dataset | 5-20 GB | 5-15 秒 | 30-120 秒 |
| CSV | 5-20 GB | 1-5 秒 | 10-40 秒 |
端到端管道估算
场景 A：100 GB 混合企业文档（150K 个文件）
中端硬件（Ryzen 9、64 GB 内存、RTX 4080）：
| 阶段 | 时间估算 |
|---|---|
| 摄入 | 4-8 小时 |
| OCR（扫描件子集：约 50K 页） | 35-55 分钟 |
| 清洗（正则 PII 检测） | 25-70 分钟 |
| AI 辅助标注（二分类） | 50-75 分钟（预标注）+ 2-4 天（人工审核） |
| 导出 | 不到 5 分钟 |
| 计算总耗时 | 约 6-10 小时 |
| 项目总耗时（含人工审核） | 3-5 个工作日 |
场景 B：500 GB 扫描文档档案（500K 页）
中端硬件：
| 阶段 | 时间估算 |
|---|---|
| 摄入 | 12-24 小时 |
| OCR（500K 页，GPU） | 5.5-9 小时 |
| 清洗（NER PII 检测） | 4-12 小时 |
| AI 辅助标注（多分类） | 3-5 小时（预标注）+ 5-10 天（人工审核） |
| 导出 | 不到 10 分钟 |
| 计算总耗时 | 约 24-50 小时 |
| 项目总耗时 | 1-2 周 |
场景 C：1 TB 混合企业档案（1M+ 个文件）
生产级硬件（Threadripper、128 GB 内存、2× RTX 4090）：
| 阶段 | 时间估算 |
|---|---|
| 摄入 | 24-48 小时 |
| OCR（扫描件子集：约 200K 页） | 1-2 小时 |
| 清洗（NER PII 检测） | 8-24 小时 |
| AI 辅助标注（实体抽取） | 12-24 小时（预标注）+ 2-4 周（人工审核） |
| 导出 | 不到 30 分钟 |
| 计算总耗时 | 约 2-4 天 |
| 项目总耗时 | 3-5 周 |
如何从数据体量推算时间线
一套用于方案定价的快速估算框架：
- 判断文档类型构成：扫描件和原生文本各占多少？扫描件的单份文档耗时是原生文本的 5-10 倍。
- 估算文件数量：总体量 ÷ 平均文件大小。同样是 100 GB 的档案，可能是 10,000 个大文件，也可能是 500,000 个小文件。文件数量影响摄入耗时，总体量影响 OCR 耗时。
- 明确标注任务：二分类？多标签？实体抽取？任务复杂度同时决定了 LLM 推理耗时和人工审核耗时。
- 计算人工审核工时：预标注吞吐量 × 准确率水平 → 审核工时。这通常是整个项目里最长的一段。
- 留出缓冲：真实档案里总有损坏文件、意料之外的格式和各种边缘情况。在计算耗时估算上再加 20-30%。
不加硬件也能提升吞吐量
在采购新硬件之前，先把手 上的资源优化到位：
- 解决存储瓶颈：如果源数据放在机械硬盘或网络存储上，先复制到本地 NVMe。仅这一步就能把摄入速度提升 5-20 倍。
- 跳过不必要的 OCR：先检查扫描 PDF 是否已经带有文本层。很多企业级扫描仪产出的 PDF 已内嵌 OCR 结果，直接抽取现有文本层比重跑一遍 OCR 快 100 倍。
- 选对量化方式：分类任务用 Q4_K_M 而不是 Q8_0，吞吐量提升 40-60%，准确率损失极小。
- 提高推理并行度：显存允许的话，同时跑 2-4 个并发 LLM 请求。
- 提前做激进过滤：在进入处理流程之前就剔除重复和无关文件。文件数量减少 10%，管道耗时也就省下 10%。
Ertas Data Suite 的性能表现
Ertas Data Suite 采用原生桌面架构，避开了容器化工具引入的开销：没有 Docker 网络层，没有卷挂载的 I/O 损耗，也没有容器运行时开销。应用直接访问文件系统和 GPU，因此实测吞吐量落在本指南各区间的上沿。
内置管道按摄入 → 清洗 → 标注 → 增强 → 导出的顺序处理文档，自动分批并跟踪进度。对服务提供商来说，这意味着管道可以整夜运行，吞吐量可预期，并且详细记录哪些已处理、哪些失败、哪些已经可以交给人工审核。
怎么用这些数字
这些基准只为回答一个问题：「数据准备阶段要花多久？」在给项目做定价梳理时，用上面这些表格估算计算耗时，再根据标注任务和团队规模加上人工审核时间，最后套上 20-30% 的缓冲。得到的就是一份经得起推敲的工作说明书时间线。
想进一步了解这些数字背后的硬件与架构决策，可以阅读本地数据准备的硬件选型和企业 AI 数据准备的本地运行时架构。
Ship AI that runs on your users' devices.
Free plan with 30 credits/mo, no card required. Paid plans from $10/mo USD.