Modele hybride : CNN sur ZeroGPU, reste du Space sur CPU

Mesures reelles sur CPU basic apres le dernier commit : MLP par defaut
252s (vs 66.6s GPU, x3.8, tolerable), extraction ResNet18 sur 352 images
<10s (inference pure, negligeable), mais CNN par defaut 601s / 10min
(vs 65.3s GPU, x9.2) -- une convolution entrainee sur plusieurs epoques
ne beneficie pas du meme overhead fixe qui masquait le cout GPU des
autres etapes, contrairement a l'hypothese du commit precedent.

Sur un Space materiel ZeroGPU, seules les fonctions decorees @spaces.GPU
empruntent un vrai GPU (et consomment le quota du visiteur) ; le reste
tourne sur le CPU du conteneur sans toucher au quota. Seul train_cnn_callback
reprend son decorateur et sa duree dynamique calibree ; MLP, extraction de
features, evaluation, prediction et test restent non decores (CPU, quota
zero). Le changement de materiel du Space (CPU basic -> ZeroGPU) se fait
cote Settings HF, pas dans ce commit.

app.py

@@ -1,6 +1,7 @@
 import json
 
 import gradio as gr
+import spaces
 
 from backbone_utils import extract_all_features, get_cached_features
 from classical_ml_utils import train_classical_model
@@ -77,7 +78,40 @@ def train_mlp_callback(
 # ---------------------------------------------------------------------------
 # Tab 3 — SimpleCNN
 # ---------------------------------------------------------------------------
-
+# Seul le CNN reste sur ZeroGPU : entraîner un vrai CNN (convolutions, plusieurs
+# époques de backward) s'est révélé ~9x plus lent sur CPU basic (601s vs 65s
+# mesurés) alors que le MLP (~3.8x, 252s vs 66.6s) et tout ce qui n'est que de
+# l'inférence (extraction de features, évaluation, prédiction) restent
+# raisonnables sur CPU. Sur un Space matériel ZeroGPU, seules les fonctions
+# décorées @spaces.GPU empruntent un vrai GPU (et consomment le quota du
+# visiteur) ; tout le reste de ce fichier tourne sur le CPU du conteneur
+# sans jamais toucher au quota.
+
+def cnn_gpu_duration(
+    num_conv_blocks, base_filters, kernel_size, use_batchnorm,
+    dropout, fc_dim,
+    learning_rate, weight_decay, batch_size, epochs,
+    model_tag,
+    request: gr.Request,
+):
+    # Calibré sur deux exécutions réelles :
+    #   3 blocs, filtres=32,  noyau=3, epochs=30 -> 65.3s  (2.18 s/époque)
+    #   5 blocs, filtres=128, noyau=5, epochs=50 -> 153.9s (3.08 s/époque)
+    # Le nombre de paramètres varie de ~130x entre ces deux essais mais le temps
+    # par époque seulement de 40% : sur ce jeu de données minuscule, le coût est
+    # dominé par un overhead fixe (chargement/augmentation), pas par les FLOPs
+    # du réseau — le nombre de paramètres surestimerait donc très largement.
+    # On interpole plutôt sur un score d'architecture simple. Plafond 180s :
+    # nettement sous le quota journalier d'un compte gratuit (300s).
+    score = int(num_conv_blocks) * int(base_filters) * (int(kernel_size) / 3)
+    baseline_score, worst_score = 96.0, 1066.7
+    frac = max(0.0, min(1.0, (score - baseline_score) / (worst_score - baseline_score)))
+    per_epoch = 2.18 + 0.9 * frac
+    estimated = 15 + per_epoch * int(epochs)
+    return min(180, max(45, int(estimated * 1.4)))
+
+
+@spaces.GPU(duration=cnn_gpu_duration)
 def train_cnn_callback(
     num_conv_blocks, base_filters, kernel_size, use_batchnorm,
     dropout, fc_dim,

requirements.txt

@@ -2,6 +2,7 @@ torchvision
 datasets
 huggingface_hub
 pillow
+spaces
 scikit-learn
 pandas
 matplotlib