La estrategia híbrida que mencionas es sensata, pero en mi experiencia, el cuello de botella en multi-GPU local no es solo el PCIe, sino también la sincronización de gradientes en data parallelism. Si usas PyTorch con DistributedDataParallel, el ancho de banda de la red inter-GPU (NVLink en 3090) puede ser más crítico que los slots PCIe, aunque muchas placas base de consumo no lo soportan. En cloud, instancias con NVLink como AWS p4d son caras, pero para modelos que requieren comunicación frecuente, la diferencia en throughput puede justificar el coste a corto plazo.
Para eficiencia energética, medir vatios por época es útil, pero añadiría que en cloud, los precios de electricidad están incluidos, mientras que en local varían por región. Usar herramientas como powertop en Linux o APIs de proveedores cloud para métricas de consumo puede dar una comparación más realista. En refrigeración, los AIO líquidos reducen ruido, pero en sesiones de entrenamiento de días, el riesgo de fugas o fallos de bomba puede paralizar un proyecto; ventiladores Noctua de alta calidad en un caso bien ventilado suelen ser más fiables a largo plazo.
Respecto al lock-in, en cloud, usar contenedores Docker con todas las dependencias y almacenar datasets en formatos abiertos como Parquet facilita la migración. En local, si optas por 3090 usadas, prueba con FurMark y memtest para VRAM antes de comprar, y considera un presupuesto para repuestos. Para benchmarks, MLPerf es estándar, pero en workflows reales, simular aumentos de batch size hasta saturar la VRAM te da una idea mejor del límite práctico que métricas sintéticas.
