本地批量處理大型文件存檔：性能調整指南

企業文件存檔以數百 GB 到 TB 計算。中型律師事務所可能有 500 GB 的合同 PDF。醫院系統可能有 2 TB 的臨床記錄。建築公司可能有 300 GB 的工程圖紙和規格。

通過數據準備管線處理這些存檔——攝入、OCR、清洗、標注、匯出——需要數小時到數天，而不是幾分鐘。調整良好的管線和樸素管線之間的差異可以在總處理時間上達到 3-5 倍。本指南涵蓋實際中重要的性能調整策略。

隔夜處理模式

在優化之前，值得承認大型批量處理的主要工作流模式：晚上開始作業，早上查看結果。

這種模式有效是因為：

數據準備是定期任務，不是實時服務
在批量處理期間沒有人在等待交互式響應
長時間運行的作業受益於不間斷的計算（沒有競爭的工作負載）
無論如何，結果都需要人工審查——而人工在工作時間審查

性能調整的目標不是讓 12 小時的作業在 12 分鐘內完成。而是讓 48 小時的作業在 12 小時內完成，這樣它可以在隔夜完成而不是跨越週末。

並行攝入策略

文件攝入是第一個管線階段，通常是最受 I/O 限制的。關鍵優化：

文件級並行性

同時處理多個文件。每個文件是獨立的——解析 PDF 不依賴於解析前一個 Word 文件。

最佳並行性：將並發文件操作的數量與您的存儲吞吐量匹配，而不是您的 CPU 核心。在 NVMe SSD 上，8-16 個並發文件讀取通常會使驅動器飽和。在 HDD 上，即使 2-4 個並發讀取也會導致尋道競爭，使一切變慢。

存儲類型	推薦並行文件數	備注
NVMe SSD	8-16	受 CPU 解析速度限制
SATA SSD	4-8	受順序帶寬限制
HDD	1-2	隨機 I/O 破壞並行性
網絡（NFS/SMB）	4-8	受網絡帶寬和延遲限制

按大小排序文件

先處理大文件。這避免了「長尾」問題，即除了一個線程在最後處理單個大文件之外，管線都處於空閒狀態。

簡單策略：按大小降序排序文件列表，然後並行處理。第一批選取最大的文件，後續批次用較小的文件填充。

按文件類型預過濾

不是存檔中的每個文件都需要處理。常見的過濾器：

跳過低於最小大小的文件（例如，低於 1 KB——可能是空文件或存根文件）
跳過非文件類型（.exe、.dll、.tmp）
在解析之前按文件哈希跳過重複文件

預過濾 500 GB 的存檔通常會刪除 5-15% 的文件，節省不會產生有用數據的內容的解析時間。

大型 PDF 的記憶體管理

PDF 是企業存檔中最常見的文件類型，也是記憶體最有問題的。

為什麼 PDF 消耗記憶體

帶嵌入圖像的 200 頁 PDF 在解析期間可以在記憶體中解壓縮為 500 MB-2 GB。PDF 格式使用內部壓縮（Flate、JPEG2000）和對象引用，需要將整個文件結構保存在記憶體中以進行隨機訪問。

掃描 PDF 更糟：每頁都是全分辨率圖像（通常 300 DPI，2550×3300 像素，24 位顏色 = 每頁約 24 MB 未壓縮）。200 頁掃描 PDF 解壓縮為約 4.8 GB。

緩解策略

頁面級處理：不是將整個 PDF 加載到記憶體中，而是一次處理一頁（或一小批頁面）。大多數 PDF 庫支持在不加載完整文件的情況下進行頁面範圍提取。

每個工作者的記憶體限制：為每個處理工作者設置記憶體上限。如果單個 PDF 超過限制，順序處理它（一次一頁）而不是並行處理。這防止單個大文件消耗所有可用 RAM 並導致記憶體不足崩潰。

流式提取：對於純文本 PDF（不是掃描的），使用流式解析器提取文本而不完全解壓縮嵌入的對象。PyMuPDF（fitz）支持此方法，對於文本提取使用的記憶體顯著少於 pdfplumber 或 PyPDF2。

實際記憶體預算

並發文件數	平均文件大小	每個工作者峰值 RAM	所需總 RAM
8	10 MB（文本 PDF）	約 200 MB	約 1.6 GB
8	50 MB（混合 PDF）	約 500 MB	約 4 GB
4	200 MB（掃描 PDF）	約 2 GB	約 8 GB
2	500 MB+（大型掃描）	約 4 GB	約 8 GB

為操作系統、應用程序和 LLM（如果同時運行）添加 8-16 GB。具有 64 GB RAM 的系統可以輕鬆處理大多數並行攝入場景。

I/O 優化

SSD 與 HDD：數字

這個比較值得重複，因為性能差異是顯著的：

操作	NVMe SSD	SATA SSD	HDD
順序讀取	3,500-7,000 MB/s	500-550 MB/s	100-200 MB/s
隨機讀取（4K）	500K-1M IOPS	50K-100K IOPS	100-200 IOPS
延遲	約 10 μs	約 50 μs	約 5,000 μs

對於數據準備，隨機讀取 IOPS 與順序吞吐量同樣重要。解析文件涉及在文件內的不同位置尋道、加載元數據、讀取嵌入的對象——所有隨機訪問模式。

具體示例：從不同存儲攝入 100,000 個混合文件（10 GB 總量）：

存儲	估計攝入時間
NVMe SSD	8-15 分鐘
SATA SSD	25-45 分鐘
HDD	3-6 小時
千兆以太網上的 NFS	1-3 小時

RAID 配置

對於生產層（多 TB 存檔）：

RAID 0（條帶化）：通過在兩個驅動器之間分散數據來使讀取吞吐量翻倍。沒有冗餘——單個驅動器故障會丟失一切。對於可以重新生成的中間處理數據是可以接受的。

RAID 1（鏡像）：沒有吞吐量改善，但提供冗餘。用於不能輕易替換的源數據。

RAID 10（鏡像的條帶）：吞吐量和冗餘都有。最少四個驅動器。當速度和數據安全都重要時的最佳選項。

對於 NVMe，RAID 不那麼必要——單個 Gen4 NVMe 驅動器已經提供了比大多數數據準備管線能夠飽和的更多吞吐量。RAID 在 HDD 層或單個驅動器上的總容量不足時變得相關。

網絡存儲最佳實踐

如果源數據存在於網絡存儲（NAS、SAN、NFS）上：

在處理之前複製到本地 SSD。 每次文件讀取的網絡延遲在數百萬次操作中積累。
如果複製不實際，使用適當的選項掛載：noatime（跳過訪問時間更新）、rsize=1048576,wsize=1048576（NFS 的大讀/寫緩衝區）和禁用客戶端緩存鎖。
接受網絡存儲將是瓶頸。相應計劃——與本地 SSD 相比，使您的時間估算翻倍或翻三倍。

進度追蹤和可恢復性

長時間運行的批量作業會失敗。驅動器會填滿，電源中斷會發生，軟體會在畸形文件上崩潰。無法從停止位置恢復的管線會浪費數小時已完成的工作。

基於檢查點的可恢復性

最低可行方法：維護已完成文件的日誌。管線重啟時，它讀取日誌並跳過已處理的文件。

# 簡單的檢查點日誌格式
timestamp | filepath | status | duration_ms
2026-03-11T22:15:03 | /data/contracts/2024-Q1/contract_0001.pdf | completed | 1250
2026-03-11T22:15:04 | /data/contracts/2024-Q1/contract_0002.pdf | completed | 890
2026-03-11T22:15:05 | /data/contracts/2024-Q1/contract_0003.pdf | error:corrupt_pdf | 45

關鍵實施細節：

每個文件後同步寫入檢查點（刷新到磁盤）。異步寫入有在進程崩潰時丟失檢查點數據的風險。
以足夠的上下文記錄錯誤以便以後調查——錯誤類型、文件路徑和管線階段。
將檢查點與輸出數據分開存儲，這樣它們可以在輸出目錄清理後仍然存在。

進度報告

對於隔夜運行的批量作業，進度報告比實時儀表板更重要。要點：

總文件數 / 已處理文件數 / 剩餘文件數：了解您在哪裡。
當前吞吐量（文件/分鐘）：了解您的速度。
估計剩餘時間：了解何時完成。
錯誤計數：了解是否在規模上出現問題（100K 個文件中的幾個錯誤是正常的；10,000 個錯誤意味著系統性問題）。

將進度寫入可以在不中斷進程的情況下查看的日誌文件。像 [2026-03-11 03:45:12] 進度：45,230 / 100,000 文件（45.2%）| 23.5 文件/分鐘 | 預計完成時間：38.8 小時 | 錯誤：12 這樣的簡單行比沒有人在凌晨 3 點看的精心設計的儀表板更有用。

損壞文件的錯誤處理

企業文件存檔包含損壞的文件。總是如此。常見的失敗模式：

截斷的 PDF：文件在上傳或複製期間被中斷。解析器讀取標題，然後遇到意外的 EOF。
加密/密碼保護的文件：解析器可以偵測加密標誌，但無法提取內容。
格式錯誤的 XML（在 DOCX/XLSX 中）：具有無效 XML 結構的損壞 Office 文件。
零字節文件：存在於存檔中但不包含任何數據。
不支持的格式：帶有誤導性擴展名的文件（實際上是 TIFF 的 .pdf）。

錯誤處理策略

按文件捕獲：永遠不要讓單個損壞的文件使整個管線崩潰。將每個文件的處理包裝在錯誤處理中。
記錄並跳過：記錄錯誤並移動到下一個文件。累積錯誤以供運行後審查。
隔離：將失敗的文件移動或連結到單獨的目錄以進行手動檢查。
設置閾值：如果錯誤率超過閾值（例如，超過 5% 的文件），暫停管線並發出警報。高錯誤率通常表明系統性問題——錯誤的解析器、字符編碼問題或損壞的源。

調整常見瓶頸

瓶頸：OCR 太慢

OCR 通常是最慢的階段。調整選項：

切換到 GPU 加速 OCR：如果運行僅 CPU 的 Tesseract，切換到帶 GPU 的 PaddleOCR 或 Surya 可以將吞吐量提高 5-10 倍。
降低 OCR 分辨率：以 200 DPI 而不是 300 DPI 處理大致使吞吐量翻倍，對標準印刷文本的準確性損失適中。
在不必要時跳過 OCR：如果 PDF 有可提取的文本層，使用文本提取而不是 OCR。許多「掃描的」PDF 實際上已經嵌入了 OCR 文本層。
批量頁面處理：每次 GPU 推理調用處理多個頁面，而不是一次一個。

瓶頸：LLM 標注太慢

減小模型大小：從 14B 切換到 7B。如果標注品質仍在您的閾值之上，接受準確性的取捨。
增加量化：從 Q8 移動到 Q4_K_M。大致吞吐量提高：40-60%。
減少上下文窗口：如果您使用 16K 上下文但文件平均 2K token，降至 4K 上下文。
增加並行請求：如果 VRAM 允許，運行 2-4 個並發推理請求。

瓶頸：記憶體耗盡

減少並行性：同時處理更少的文件。以速度換穩定性。
按文件類型處理：將大型掃描 PDF 與小型文本文件分開處理，為每種類型使用不同的並行性設置。
增加交換空間：臨時措施，不是解決方案。交換到 SSD 比 RAM 慢 100 倍，但可以防止崩潰。

瓶頸：磁盤空間

分波處理：攝入一批，通過所有階段處理它，匯出，然後在下一批之前清理中間文件。
壓縮中間數據：中間輸出上的 gzip 或 zstd 壓縮用 CPU 換磁盤空間。
主動監控磁盤使用：在 12 小時作業的第 10 小時出現磁盤滿錯誤是可以通過監控避免的。

監控長時間運行的批量作業

對於隔夜或週末運行的作業：

記錄到文件：編寫包含時間戳、吞吐量指標和錯誤計數的結構化日誌。睡前和早上第一件事就是查看日誌文件。

進程監控：使用基本的操作系統工具——htop 用於 CPU 和記憶體，nvidia-smi 用於 GPU 利用率，iostat 用於磁盤 I/O。如果 GPU 利用率在作業運行時降至 0%，說明有什麼東西停滯了。

警報（可選）：對於在專用服務器上運行的作業，一個簡單的腳本，檢查進程活躍性並在失敗時發送通知（電子郵件、Slack），值得花 10 分鐘設置。

實際應用

Ertas Data Suite 通過內置進度追蹤、按文件錯誤處理和自動可恢復性處理批量處理。應用程序維護一個處理日誌，記錄每個文件通過每個管線階段的狀態。如果進程被中斷——電源中斷、應用程序崩潰或有意暫停——重新啟動會從停止的地方繼續。

對於處理客戶文件存檔的服務提供商，隔夜處理模式加上可恢復性意味著您可以按可預測的計劃交付結果。下班時開始批量作業，必要時遠程查看進度日誌，第二天早上審查結果。本指南中的性能調整策略幫助您在一次隔夜運行而不是三次中獲得這些結果。

更廣泛的圖景

批量處理性能直接影響業務時間表和成本。調整良好的管線在 8 小時內處理 500 GB 存檔（一次隔夜運行），在兩天內交付結果——一天運行，一天審查。調整不良的管線需要 48 小時，將相同的可交付成果推遲到一週。

有關影響批量處理性能的基礎設施決策的更多信息，請參見企業 AI 數據準備的本地運行時架構和本地數據準備的硬體規模設計。