1.**Costo cero de GPU**: La RTX 3060 ya está disponible en el equipo de desarrollo
2.**Sin límites de tiempo**: AWS y Colab tienen timeouts de sesión
3.**Acceso instantáneo**: Sin tiempo de aprovisionamiento de instancias
4.**Almacenamiento local**: Dataset y resultados en disco sin costos de transferencia
5.**Iteración rápida**: Reinicio inmediato de contenedores Docker
### Conclusión
Para un proyecto de investigación con múltiples iteraciones de ajuste de hiperparámetros y desarrollo, **la ejecución local ahorra ~$10-50/mes** comparado con cloud, además de ofrecer mayor flexibilidad y velocidad de iteración
## Resumen Ejecutivo
| Servicio | CER | WER | Tiempo/Página | Tiempo Total | VRAM |
Este documento presenta resultados de dos fases experimentales distintas realizadas durante el desarrollo del TFM. La primera fase corresponde a la optimización de hiperparámetros utilizando Ray Tune, ejecutada en CPU debido a las limitaciones de hardware iniciales. La segunda fase corresponde a la validación práctica con aceleración GPU para evaluar la viabilidad en escenarios de producción.
**Tabla.** *Fases experimentales y sus características.*
| Fase | Dataset | Hardware | Resultado Principal |
La fase de optimización representa el **resultado principal del TFM** (CER 1.49%, precisión 98.51%). La fase de validación GPU confirma la viabilidad práctica del enfoque, demostrando una aceleración de 126x respecto a CPU.
| **PaddleOCR** | PP-OCRv5_mobile_det | PP-OCRv5_mobile_rec | Sí |
| **DocTR** | db_resnet50 | crnn_vgg16_bn | No (entrenado en inglés/francés) |
| **EasyOCR** | CRAFT | latin_g2.pth | Sí |
### Notas sobre Modelos
- **PaddleOCR**: Modelos server más precisos disponibles pero requieren >5.3 GB VRAM (OOM en RTX 3060)
- **DocTR**: Se probó modelo `parseq` como alternativa, resultó 2% peor CER y 2x más lento. El problema de diacríticos es de datos de entrenamiento, no de arquitectura
- **EasyOCR**: Modelo `latin_g2.pth` es correcto. Los problemas son del detector CRAFT, no del reconocimiento
> **Conclusión sobre Fine-tuning:** Para documentos en español, **usar PaddleOCR directamente**. El fine-tuning de DocTR/EasyOCR no se justifica dado que PaddleOCR ya ofrece 31-36% mejor precisión sin configuración adicional.
| **45 páginas** | ~52 min | ~25 seg | **126x más rápido** |
```mermaid
xychart-beta
title "Tiempo de Procesamiento por Página: CPU vs GPU"
x-axis ["CPU", "GPU (RTX 3060)"]
y-axis "Segundos" 0 --> 80
bar [69.4, 0.55]
```
> **Conclusión:** GPU es esencial para uso práctico de OCR. El procesamiento en CPU es 126x más lento, haciéndolo impráctico para procesamiento por lotes.
