Tek cümle: PDF veri çıkarım aracı olarak seçilen Marker'ın H100 GPU üzerinde paralel işleme sınırları ölçüldü; 8 worker ~280 sn'de 17/17 başarı ile en iyi süre / verim / başarı kombinasyonunu verdi, 12 worker OOM ile 15/17'ye düştü.
1. Amaç
Üretim korpusu (~96K PDF) için Marker'ın paralel ölçeklenebilirliğini somut olarak ölçmek; "hangi worker sayısı stabil ve verimli?" sorusuna H100 üzerinde sayısal yanıt üretmek. Karşılaştırmalı araç değerlendirmesinin (Tika · MarkItDown · PyMuPDF4LLM · Docling · MinerU · Marker) Marker'ı seçen kalitatif sonucunun, operasyonel performansı doğrulanmış olmalı.
2. Parametre / Kurulum
| Bileşen |
Değer |
| Donanım |
Google Colab, NVIDIA H100 80GB |
| PDF sayısı |
17 dijital PDF (OCR ihtiyacı yok) |
TORCH_DEVICE |
cuda |
OCR_ENGINE |
None (dijital olduğu için kapalı) |
| Görsel çıkarımı |
--disable_image_extraction |
| Ölçüm |
nvidia-smi ile periyodik GPU% + VRAM örnekleme; timeline CSV |
| Değişken |
workers ∈ {4, 6, 8, 10, 12} |
| Sabit |
Aynı 17 PDF, aynı sürüm, aynı oturum |
3. Sonuç ve Bulgu
3.1 Worker Taraması
| Workers |
Süre (sn) |
Ort. GPU % |
Ort. VRAM (GB) |
Tepe VRAM (GB) |
Başarı |
| 4 |
398.54 (en yavaş) |
60.13 |
~18.5 |
~34.4 |
17 / 17 |
| 6 |
281.32 |
87.38 |
~37.4 |
~49.1 |
17 / 17 |
| 8 |
279.57 (en iyi) |
88.95 |
~50.0 |
~63.1 |
17 / 17 |
| 10 |
294.78 |
84.13 |
~60.0 |
~78.0 (riskli) |
17 / 17 |
| 12 |
281.33 |
— |
— |
~81.2 (OOM) |
15 / 17 (eksik) |
3.2 Yorum
- 4 worker: GPU
~%60'ta beslenemiyor; paralelizm yetersiz.
- 6 → 8 worker: GPU
~%88'e çıkar, fakat süre kazancı az (281 → 280 sn) iken VRAM artışı belirgin (~37 → ~50 GB). 8 worker, boyut/zaman dengesinin döndüğü kırılma noktası.
- 10 worker: Süre kötüleşir (280 → 295 sn). Sebepler: GPU doygunluğu, proses zamanlaması, model kopyaları, VRAM parçalanması, CPU koordinasyonu. Paralellik sınırsız değil.
- 12 worker: CUDA OOM; 17 yerine 15 dosya üretilir → operasyonel olarak kabul edilemez.
3.3 Önerilen Üretim Konfigürasyonu
| Profil |
workers |
Süre |
VRAM |
Başarı |
Durum |
| Üretim (varsayılan) |
8 |
en iyi |
~50 GB |
17/17 |
Kullanılır |
| Güvenli (yedek) |
6 |
+0.6% |
~37 GB |
17/17 |
Yedek slot |
| Riskli |
10 |
+5% |
~78 GB |
17/17 |
Önerilmez |
| Kullanılmamalı |
12 |
— |
OOM |
15/17 |
Yasak |
4. Karara Etkisi
- Marker, üretim PDF→MD aracı olarak konfirme edildi. Bölüm 5 testleri olmadan "kalite tek başına yetmez" itirazına yanıt veremiyorduk; benchmark bu boşluğu kapattı.
- Üretim için sabit kural:
workers = 8, dijital PDF'lerde OCR None, görsel kapalı (downstream gerekmediği sürece).
- Mimari kısıtlar:
- PDF→MD adımı GPU bağımlı; CPU fallback yok.
- Bir node 80 GB VRAM'a ihtiyaç duyar; işin küme tasarımına yansıması var.
- 96K dosyanın tek seferlik işleme süresi tahmini:
(96.000 / 17) × 280 sn ≈ ~440 saat ≈ ~18 gün (tek H100, kesintisiz). Çoklu node ile lineer ölçeklendirilebilir.
- Kalite riskleri pipeline'a not edildi: Kaynakça başlığı kaybı, tablo bozulması, OCR karakter ayrışması — Qwen metadata extraction (Deney 05) ve embedding kalitesini doğrudan etkileyebileceği PDF-Cikarim-Araclari.md sayfasında listelendi.
- Sonraki adım:
- Üretim sırasında
workers=8 kuralının CI / runner config'ine sabitlenmesi.
- 96K dosya üzerinde fail-rate ölçümü (deney 17 dosyaylaydı; gerçek korpusta dağılım farklı olabilir).
- Marker LLM düzelti modunun, tablo / kaynakça kaybı yaşanan örneklerde selektif olarak denenmesi.
- Taranmış PDF korpusu için ayrı profil: OCR açık,
workers=4–6, ayrı bir benchmark.
5. Detay Bağlantılar
