基準測試：100GB 以上企業資料集的本地端資料準備管道吞吐量
本地端資料準備的實際吞吐量基準——按文件類型和硬體配置分類的攝入、OCR、清理、標記和導出速度。
每個為企業 AI 項目提供資料準備的 服務提供商在範疇界定期間都面臨同樣的問題：「這需要多長時間？」
答案取決於文件類型、資料集大小、管道階段和硬體。「幾週」這樣模糊的估計在撰寫具有固定時間表的工作說明書時沒有幫助。具體的吞吐量數字才有幫助。
本指南為不同文件類型和硬體配置的每個管道階段提供了實際基準資料。這些數字來自常見配置，而非理想化的實驗室條件。將它們作為範疇界定的基準。
方法說明
所有基準測試假設：
- 單機處理（非分佈式）
- 文件按順序通過管道階段處理（全部攝入 → 全部清理 → 全部標記 → 全部導出）
- OCR 引擎和推理後端的預設配置（無奇異調整）
- 吞吐量以初始暖機後的持續速率衡量，而非峰值突發
參考硬體配置：
| 配置 | CPU | RAM | GPU | 存儲 |
|---|---|---|---|---|
| 入門 | Ryzen 7 7700（8核/16線程） | 32 GB | RTX 4060 Ti 16GB | 2 TB NVMe |
| 中階 | Ryzen 9 7950X（16核/32線程） | 64 GB | RTX 4080 16GB | 4 TB NVMe |
| 生產 | Threadripper 7970X（32核/64線程） | 128 GB | 2× RTX 4090 24GB | 8 TB NVMe |
第一階段：攝入吞吐量
攝入涵蓋讀取源文件、解析其結構並提取原始內容（文字、圖像、元資料）。
按文件類型
| 文件類型 | 平均大小 | 入門（文件/分鐘） | 中階（文件/分鐘） | 生產（文件/分鐘） |
|---|---|---|---|---|
| 原生 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 以上。並行處理受 RAM 限制。
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%，卻主導了時間表。
第二階段：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 吞吐量決定了您的項目時間表。
第三階段：清理吞吐量
清理包括去重複、格式規範化、個人識別資訊偵測/編輯和品質過濾。
按操作
| 操作 | 方法 | 吞吐量（中階） | RAM 使用 |
|---|---|---|---|
| 精確去重 | SHA-256 雜湊 | 每分鐘 50,000 至 100,000 個文件 | 低（100 萬文件低於 1 GB） |
| 模糊去重（MinHash） | 128 排列 | 每分鐘 5,000 至 15,000 個文件 | 每 100 萬文件 2 至 4 GB |
| 個人識別資訊偵測（正則表達式） | 模式匹配 | 每分鐘 10,000 至 30,000 個文件 | 低 |
| 個人識別資訊偵測（NER 模型） | GLiNER / SpaCy NER | 每分鐘 500 至 2,000 個文件 | 2 至 4 GB VRAM |
| 個人識別資訊編輯 | 替換偵測的個人識別資訊 | 與偵測相同 | 與偵測相同 |
| 格式規範化 | Unicode、空白清理 | 每分鐘 20,000 至 50,000 個文件 | 低 |
| 品質過濾 | 長度、語言、連貫性 | 每分鐘 10,000 至 30,000 個文件 | 低 |
清理時間估計
對於 150,000 個文件的存檔（上面 100 GB 混合中的那個）：
| 操作 | 中階時間 |
|---|---|
| 精確去重 | 2 至 3 分鐘 |
| 模糊去重 | 10 至 30 分鐘 |
| 正則表達式個人識別資訊偵測 | 5 至 15 分鐘 |
| NER 個人識別資訊偵測 | 1.5 至 5 小時 |
| 格式規範化 | 3 至 8 分鐘 |
| 品質過濾 | 5 至 15 分鐘 |
| 總計（含 NER 個人識別資訊） | 約 2 至 6 小時 |
| 總計（僅正則表達式個人識別資訊） | 約 25 至 70 分鐘 |
基於 NER 的個人識別資訊偵測是清理瓶頸。對於基於正則表達式的個人識別資訊偵測足夠的項目（具有結構化個人識別資訊如 SSN、帳號的金融文件），清理速度很快。對於敘述文字中的非結構化個人識別資訊，NER 增加了大量時間。
第四階段：標記吞吐量
手動標記
人工標記速度因任務複雜性和標注者經驗而有很大差異：
| 任務 | 速度（有經驗的標注者） | 文件/天（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 倍。
第五階段：增強吞吐量
合成資料生成吞吐量取決於輸出長度：
| 任務 | 模型 | 硬體 | 輸出長度 | 文件/小時 |
|---|---|---|---|---|
| 改述生成 | Mistral 7B Q4 | RTX 4070 | 約 100 個 Token | 1,500 至 2,500 |
| 合成文件生成 | Qwen 2.5 14B Q4 | RTX 4080 | 約 500 個 Token | 100 至 200 |
| 增強範例（分類） | Mistral 7B Q4 | RTX 4070 | 約 50 個 Token | 3,000 至 5,000 |
| 問答對生成 | Qwen 2.5 14B Q4 | RTX 4080 | 約 200 個 Token | 400 至 700 |
第六階段：導出吞吐量
導出很少是瓶頸：
| 格式 | 大小（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 資料集 | 5 至 20 GB | 5 至 15 秒 | 30 至 120 秒 |
| CSV | 5 至 20 GB | 1 至 5 秒 | 10 至 40 秒 |
端對端管道估計
情境 A：100 GB 混合企業文件（150K 文件）
中階硬體（Ryzen 9、64 GB RAM、RTX 4080）：
| 階段 | 時間估計 |
|---|---|
| 攝入 | 4 至 8 小時 |
| OCR（掃描子集：約 50K 頁） | 35 至 55 分鐘 |
| 清理（使用正則表達式個人識別資訊） | 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 個人識別資訊） | 4 至 12 小時 |
| AI 輔助標記（多類別） | 3 至 5 小時（預標注）+ 5 至 10 天（人工審查） |
| 導出 | 低於 10 分鐘 |
| 總計算時間 | 約 24 至 50 小時 |
| 總項目時間 | 1 至 2 週 |
情境 C：1 TB 混合企業存檔（100 萬以上文件）
生產硬體（Threadripper、128 GB RAM、2× RTX 4090）：
| 階段 | 時間估計 |
|---|---|
| 攝入 | 24 至 48 小時 |
| OCR（掃描子集：約 200K 頁） | 1 至 2 小時 |
| 清理（使用 NER 個人識別資訊） | 8 至 24 小時 |
| AI 輔助標記（實體提取） | 12 至 24 小時（預標注）+ 2 至 4 週（人工審查） |
| 導出 | 低於 30 分鐘 |
| 總計算時間 | 約 2 至 4 天 |
| 總項目時間 | 3 至 5 週 |
如何從資料量估計時間表
用於範疇界定提案的快速估計框架：
- 評估文件類型：掃描與原生文字的百分比是多少？掃描文件每個文件花費 5 至 10 倍的時間。
- 估計文件數量：總量 ÷ 平均文件大小。100 GB 存檔可能是 10,000 個大文件或 500,000 個小文件。文件數量影響攝入時間；總量影響 OCR 時間。
- 確定標記任務：二元分類？多標籤？實體提取？任務複雜性決定了 LLM 推理時間和人工審查時間。
- 計算人工審查小時數：預標注吞吐量 × 準確率級別 → 審查小時數。這通常是最長的階段。
- 添加緩衝：真實世界的存檔包含損壞的文件、意外格式和邊界案例。在計算時間估計上添加 20 至 30%。
在不添加硬體的情況下提高吞吐量
在購買更多硬體之前，優化您現有的：
- 修復存儲瓶頸：如果源資料在 HDD 或網路存儲上，將其複製到本地 NVMe。僅此一項就可以將攝入時間縮短 5 至 20 倍。
- 跳過不必要的 OCR：檢查掃描 PDF 是否已有文字層。許多企業掃描器生成帶有嵌入 OCR 的 PDF。提取現有文字層比重新運行 OCR 快 100 倍。
- 使用正確的量化：對分類任務使用 Q4_K_M 而不是 Q8_0。在準確率損失最小的情況下提高 40 至 60% 的吞吐量。
- 增加推理並行性：如果 VRAM 允許，運行 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.
Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Keep reading
Batch Processing Large Document Archives On-Premise: Performance Tuning Guide
Performance tuning guide for batch processing 100GB–1TB+ document archives on-premise — parallel ingestion, memory management, I/O optimization, and resumability strategies.
Running Ollama for AI-Assisted Data Prep in Air-Gapped Enterprise Environments
Step-by-step guide to deploying Ollama for AI-assisted data labeling in air-gapped environments — model transfer, offline setup, GPU configuration, and common failure modes.
How to Build an On-Premise Data Preparation Pipeline for LLM Fine-Tuning
A complete guide to building on-premise data preparation pipelines for LLM fine-tuning — covering the 5 stages from ingestion to export, tool comparisons, and architecture for regulated environments.