Prima di eseguire un job di Neural Architecture Search di Agent Platform per cercare un modello ottimale, definisci l'attività proxy. Stage1-search utilizza una rappresentazione molto più piccola di un addestramento del modello completo, che in genere termina entro due ore. Questa rappresentazione è chiamata attività proxy e riduce notevolmente il costo di ricerca. Ogni prova durante la ricerca addestra un modello utilizzando le impostazioni dell'attività proxy.
Le sezioni seguenti descrivono cosa comporta l'applicazione della progettazione delle attività proxy:
- Approcci alla creazione di un'attività proxy.
- Requisiti di una buona attività proxy.
- Come utilizzare i tre strumenti di progettazione delle attività proxy per trovare l'attività proxy ottimale, che riduce i costi di ricerca mantenendo la qualità della ricerca.
Approcci per la creazione di un'attività proxy
Esistono tre approcci comuni per la creazione di un'attività proxy, che includono:
- Utilizza meno passaggi di addestramento.
- Utilizza un set di dati di addestramento sottocampionato.
- Utilizza un modello ridotto.
Utilizza meno passaggi di addestramento
Il modo più semplice per creare un'attività proxy è ridurre il numero di passaggi di addestramento per l'addestratore e segnalare un punteggio al controller in base a questo addestramento parziale.
Utilizza un set di dati di addestramento sottocampionato
Questa sezione descrive l'utilizzo di un set di dati di addestramento sottocampionato sia per una ricerca dell'architettura sia per una ricerca della policy di miglioramento.
Ricerca dell'architettura
È possibile creare un'attività proxy utilizzando un set di dati di addestramento sottocampionato durante la ricerca dell'architettura. Tuttavia, quando esegui il sottocampionamento, segui queste linee guida:
- Mescola i dati in modo casuale tra gli shard.
- Se i dati di addestramento non sono bilanciati, esegui il sottocampionamento per bilanciarli.
Ricerca di policy di miglioramento utilizzando l'aumento automatico
Salta questa sezione se non stai eseguendo una ricerca solo di miglioramento, ma solo la ricerca di architettura standard. Utilizza auto-augment per cercare la policy di miglioramento. È preferibile eseguire il sottocampionamento dei dati di addestramento ed eseguire un addestramento completo piuttosto che ridurre il numero di passaggi di addestramento. L'esecuzione dell'addestramento completo con un'ampia quantità di dati di miglioramento mantiene i punteggi più stabili. Inoltre, utilizza i dati di addestramento ridotti per mantenere più basso il costo della ricerca.
Attività proxy basata su un modello ridotto
Puoi anche fare lo scale down del modello rispetto al modello di riferimento per creare un'attività proxy. Questo può essere utile anche quando vuoi separare la ricerca di progettazione dei blocchi dalla ricerca di scalabilità.
Tuttavia, quando fai fare lo scale down del modello e vuoi utilizzare un vincolo di latenza, utilizza un vincolo di latenza più rigido per il modello sottoposto a scale down. Suggerimento: puoi fare lo scale down del modello di riferimento e misurarne la latenza per impostare questo vincolo di latenza più restrittivo.
Per il modello ridotto, puoi anche ridurre la quantità di augmentation e regolarizzazione rispetto al modello di riferimento originale.
Esempi di un modello ridotto
Per le attività di visione artificiale in cui l'addestramento viene eseguito sulle immagini, esistono tre modi comuni per fare lo scale down di un modello:
- Riduzione della larghezza del modello: un numero di canali.
- Riduzione della profondità del modello: un numero di strati e ripetizioni di blocchi.
- Ridurre leggermente le dimensioni delle immagini di addestramento (in modo da non eliminare le caratteristiche) o ritagliarle, se consentito dall'attività.
Lettura consigliata: il paper su EfficientNet fornisce ottimi approfondimenti sulla scalabilità dei modelli per le attività di visione artificiale. Inoltre, spiega come i tre modi di scalare sono correlati tra loro.
Spinenet search è un altro esempio di scalabilità dei modelli utilizzato con Neural Architecture Search di Agent Platform. Per la ricerca di fase 1, fa lo scale down del numero di canali e delle dimensioni dell'immagine.
Attività proxy basata su una combinazione
Gli approcci funzionano in modo indipendente e possono essere combinati in modi diversi per creare un'attività proxy.
Requisiti di una buona attività proxy
Un'attività proxy deve soddisfare determinati requisiti prima di poter restituire una ricompensa stabile al controller e mantenere la qualità della ricerca.
Correlazione del ranking tra la ricerca della fase 1 e l'addestramento completo della fase 2
Quando si utilizza un'attività proxy per la ricerca di architetture neurali di Agent Platform, un'ipotesi chiave per una ricerca di successo è che se il modello A ha un rendimento migliore del modello B durante l'addestramento dell'attività proxy della fase 1, il modello A ha un rendimento migliore del modello B per l'addestramento completo della fase 2. Per convalidare questa ipotesi, devi valutare la correlazione di ranking tra i premi della ricerca della fase 1 e dell'addestramento completo della fase 2 su circa 10-20 modelli nel tuo spazio di ricerca. Questi modelli sono chiamati correlation-candidate-models.
La figura seguente mostra un esempio di correlazione scarsa (punteggio di correlazione = -0,03), che rende questa attività proxy un candidato non idoneo per una ricerca:
Ogni punto del grafico rappresenta un modello candidato alla correlazione.
L'asse x rappresenta i punteggi di addestramento completo della fase 2 per i modelli,
mentre l'asse y rappresenta i punteggi delle attività proxy della fase 1 per gli stessi modelli.
Osserva il punto più alto. Questo modello ha ottenuto il punteggio più alto per l'attività proxy (asse y), ma ha prestazioni scarse durante l'addestramento completo della fase 2 (asse x) rispetto ad altri modelli. Al contrario, la figura seguente mostra un esempio di buona correlazione (punteggio di correlazione = 0,67), che rende questa attività proxy un buon candidato per una ricerca:
Se la ricerca prevede un vincolo di latenza, verifica anche una buona correlazione per i valori di latenza.
Tieni presente che i premi dei modelli candidati alla correlazione hanno un buon intervallo e un campionamento decente dell'intervallo dei premi. In caso contrario, non puoi valutare la correlazione di ranking. Ad esempio, se tutti i premi della fase 1 dei modelli candidati alla correlazione sono incentrati su solo due valori, 0,9 e 0,1, non viene fornita una variazione di campionamento sufficiente.
Controllo della varianza
Un altro requisito di un'attività proxy è che non deve presentare una grande variazione nell'accuratezza o nel punteggio di latenza quando viene ripetuta più volte per lo stesso modello senza modifiche. In questo caso, il segnale inviato al controller è disturbato. Viene fornito uno strumento per misurare questa varianza.
Vengono forniti esempi per mitigare l'elevata varianza durante l'addestramento. Un modo è utilizzare cosine decay come programmazione del tasso di apprendimento. Il grafico seguente mette a confronto tre strategie di tasso di apprendimento:
Il grafico più basso corrisponde a un tasso di apprendimento costante. Quando il punteggio oscilla alla fine dell'addestramento, una piccola modifica nella scelta del numero ridotto di passaggi di addestramento può causare una grande variazione nella ricompensa finale dell'attività proxy. Per rendere più stabile la ricompensa dell'attività proxy, è meglio utilizzare un decadimento del tasso di apprendimento del coseno, come mostrato dai punteggi di convalida corrispondenti nel grafico più alto. Nota come il grafico più alto diventa più uniforme verso la fine dell'addestramento. Il grafico centrale mostra il punteggio corrispondente al decadimento del tasso di apprendimento graduale. È migliore del tasso costante, ma non è ancora fluido come il decadimento del coseno e richiede anche l'ottimizzazione manuale.
Le pianificazioni del tasso di apprendimento sono mostrate di seguito:
Ulteriore smoothing
Se utilizzi un miglioramento intensivo, la curva di convalida potrebbe non diventare sufficientemente uniforme con il decadimento del coseno. L'utilizzo di un'augmentation intensiva indica una mancanza di dati di addestramento. In questo caso, l'utilizzo di Neural Architecture Search di Agent Platform non è consigliato e suggeriamo di utilizzare augmentation-search.
Se il problema non è l'augmentation eccessiva e hai già provato il decadimento del coseno, ma vuoi comunque ottenere una maggiore fluidità, utilizza la media mobile esponenziale per TensorFlow-2 o la media ponderata stocastica per PyTorch. Consulta questo indicatore di codice per un esempio di utilizzo dell'ottimizzatore della media mobile esponenziale con TensorFlow 2 e questo esempio di media ponderata stocastica per PyTorch.
Se i grafici di accuratezza/epoca per le prove sono simili a questo:
puoi applicare le tecniche di smoothing menzionate sopra (come la media ponderata stocastica o l'utilizzo della media mobile esponenziale) per ottenere un grafico più coerente, ad esempio:
Errori relativi alla memoria esaurita (OOM) e al tasso di apprendimento
Lo spazio di ricerca dell'architettura può generare modelli molto più grandi della tua base di riferimento. Potresti aver ottimizzato le dimensioni del batch per il modello di riferimento, ma questa impostazione potrebbe non funzionare quando vengono campionati modelli più grandi durante la ricerca, causando errori OOM. In questo caso, devi ridurre le dimensioni del batch.
L'altro tipo di errore che viene visualizzato è un errore NaN (not-a-number). Devi ridurre il tasso di apprendimento iniziale o aggiungere il taglio del gradiente.
Come indicato nel tutorial-2, se più del 20% dei modelli dello spazio di ricerca restituisce punteggi non validi, non esegui la ricerca completa. I nostri strumenti di progettazione di attività proxy forniscono un modo per valutare il tasso di errore.
Strumenti di progettazione di attività proxy
Le sezioni precedenti illustrano i principi della progettazione di attività proxy. Questa sezione fornisce tre strumenti di progettazione delle attività proxy per trovare automaticamente l'attività proxy ottimale in base ai diversi approcci di progettazione e che soddisfa tutti i requisiti.
Modifiche al codice richieste
Innanzitutto, devi modificare leggermente il codice del trainer in modo che possa interagire con gli strumenti di progettazione delle attività proxy durante un processo iterativo.
tf_vision/train_lib.py mostra un esempio. Devi prima importare la nostra libreria:
from google.cloud.visionsolutions.nas.proxy_task import proxy_task_utils
Prima che inizi un ciclo di addestramento nel loop di addestramento, controlla se devi interrompere l'addestramento in anticipo, perché lo strumento di progettazione delle attività proxy vuole che tu utilizzi la nostra libreria:
if proxy_task_utils.get_stop_training(
model_dir,
end_training_cycle_step=<last-training-step-idx done so far>,
total_training_steps=<total-training-steps>):
break
Al termine di ogni ciclo di addestramento nel loop di addestramento, aggiorna il nuovo punteggio di accuratezza, il passaggio di inizio e fine del ciclo di addestramento, la durata del ciclo di addestramento in secondi e i passaggi di addestramento totali.
proxy_task_utils.update_trial_training_accuracy_metric(
model_dir=model_dir,
accuracy=<latest accuracy value>,
begin_training_cycle_step=<beginning training step for this cycle>,
end_training_cycle_step=<end training step for this cycle>,
training_cycle_time_in_secs=<training cycle time (excluding validation)>,
total_training_steps=<total-training-steps>)
Tieni presente che la durata del ciclo di addestramento non deve includere il tempo per la valutazione del punteggio di convalida. Assicurati che l'addestratore calcoli i punteggi di convalida frequentemente (evaluation-frequency) in modo da avere un campionamento sufficiente della curva di convalida. Se utilizzi il vincolo di latenza, aggiorna la metrica di latenza dopo aver calcolato la latenza:
proxy_task_utils.update_trial_training_latency_metric(
model_dir=model_dir,
latency=<measured_latency>)
Lo strumento di selezione del modello richiede il caricamento del checkpoint precedente per l'iterazione successiva.
Per abilitare il riutilizzo di un checkpoint precedente, aggiungi un flag al trainer, come mostrato in tf_vision/cloud_search_main.py:
parser.add_argument(
"--retrain_use_search_job_checkpoint",
type=cloud_nas_utils.str_2_bool,
default=False,
help="True to use previous NAS search job checkpoint."
)
Carica questo checkpoint prima di addestrare il modello:
if FLAGS.retrain_use_search_job_checkpoint:
prev_checkpoint_dir = cloud_nas_utils.get_retrain_search_job_model_dir(
retrain_search_job_trials=FLAGS.retrain_search_job_trials,
retrain_search_job_dir=FLAGS.retrain_search_job_dir)
logging.info("Setting checkpoint to %s.", prev_checkpoint_dir)
# Now set your checkpoint using 'prev_checkpoint_dir'.
Devi anche avere il metric-id corrispondente ai valori di accuratezza e latenza
indicati dal trainer. Se la ricompensa del trainer (che a volte è una combinazione di accuratezza e latenza) è diversa dall'accuratezza, assicurati di segnalare anche la metrica basata solo sull'accuratezza utilizzando other_metrics dal trainer.
Ad esempio, l'esempio seguente mostra le metriche di sola accuratezza e di latenza
riportate dal nostro trainer predefinito:
Misurazione della varianza
Dopo aver modificato il codice del trainer, il primo passaggio consiste nel misurare la varianza per il trainer. Per la misurazione della varianza, modifica la configurazione di addestramento di riferimento per quanto segue:
- riduci i passaggi di addestramento in modo che l'esecuzione duri solo un'ora circa con una o due GPU. Abbiamo bisogno di un piccolo campione di addestramento completo.
- utilizza il tasso di apprendimento del decadimento del coseno e imposta i relativi passaggi in modo che corrispondano a questi passaggi ridotti, in modo che il tasso di apprendimento diventi quasi zero verso la fine.
Lo strumento di misurazione della varianza campiona un modello dallo spazio di ricerca, si assicura che questo modello possa iniziare l'addestramento senza generare errori OOM o NAN, esegue cinque copie di questo modello con le tue impostazioni per circa un'ora, quindi segnala la varianza e la fluidità del punteggio di addestramento. Il costo totale per l'esecuzione di questo strumento è approssimativamente lo stesso dell'esecuzione di cinque modelli con le tue impostazioni per circa un'ora.
Avvia il job di misurazione della varianza eseguendo il seguente comando (è necessario un service account):
DATE="$(date '+%Y%m%d_%H%M%S')"
project_id=<your project-id>
# You can choose any unique docker id below.
trainer_docker_id=${USER}_trainer_${DATE}
trainer_docker_file=<path to your trainer dockerfile>
region=<your job region such as 'us-central1'>
search_space_module=<path to your search space module>
accelerator_type="NVIDIA_TESLA_V100"
num_gpus=2
# Your bucket should be for your project and in the same region as the job.
root_output_dir=<gs://your-bucket>
####### Variance measurement related parameters ######
proxy_task_variance_measurement_docker_id=${USER}_variance_measurement_${DATE}
# Use the service account that you set-up for your project.
service_account=<your service account>
job_name=<your job name>
############################################################
python3 vertex_nas_cli.py build \
--project_id=${project_id} \
--region=${region} \
--trainer_docker_id=${trainer_docker_id} \
--trainer_docker_file=${trainer_docker_file} \
--proxy_task_variance_measurement_docker_id=${proxy_task_variance_measurement_docker_id}
# The command below passes 'dummy' arguments for the training docker.
# You need to modify them for your own docker.
python3 vertex_nas_cli.py measure_proxy_task_variance \
--proxy_task_variance_measurement_docker_id=${proxy_task_variance_measurement_docker_id} \
--project_id=${project_id} \
--service_account=${service_account} \
--region=${region} \
--trainer_docker_id=${trainer_docker_id} \
--job_name=${job_name} \
--search_space_module=${search_space_module} \
--accelerator_type=${accelerator_type} \
--num_gpus=${num_gpus} \
--root_output_dir=${root_output_dir} \
--search_docker_flags \
dummy_trainer_flag1="dummy_trainer_val"
Una volta avviato questo job di misurazione della varianza, riceverai un link al job. Il nome del job deve iniziare con il prefisso Variance_Measurement. Di seguito è riportato un esempio di UI del job:
variance_measurement_dir conterrà tutti gli output e puoi controllare i log facendo clic sul link Visualizza log.
Per impostazione predefinita, questo job utilizza una CPU sul cloud per l'esecuzione in background come job personalizzato, quindi avvia e gestisce i job NAS secondari.
In Job NAS, vedrai un job denominato Find_workable_model_<your job name>. Questo job campionerà lo spazio di ricerca per trovare un modello che non genera errori. Una volta trovato un modello di questo tipo, il job di misurazione della varianza avvia un altro job NAS <your job name>, che esegue cinque copie di questo modello per il numero di passaggi di addestramento impostati in precedenza. Una volta completato l'addestramento di questi modelli, il job di misurazione della varianza misura la varianza del punteggio e la fluidità e le riporta nei log:
Se la varianza è elevata, puoi esplorare le tecniche elencate qui.
Selezione del modello
Dopo aver verificato che il trainer non ha una varianza elevata, i passaggi successivi sono:
- per trovare circa 10 modelli candidati alla correlazione
- calcola i punteggi di addestramento completo, che fungeranno da riferimento quando calcolerai i punteggi di correlazione delle attività proxy per diverse opzioni di attività proxy in un secondo momento.
Il nostro strumento trova automaticamente ed efficacemente questi modelli candidati alla correlazione e garantisce che abbiano una buona distribuzione dei punteggi sia per l'accuratezza che per la latenza, in modo che il calcolo della correlazione futura abbia una buona base. A questo scopo, lo strumento esegue le seguenti operazioni:
- Campiona in modo casuale
N_beginmodelli dal tuo spazio di ricerca. Per l'esempio qui, supponiamoN_begin = 30. Lo strumento li addestra per 1/30 del tempo di addestramento completo. - Rifiuta cinque dei 30 modelli, che non aggiungono altro alla distribuzione di accuratezza e latenza. La figura seguente mostra un esempio. I modelli rifiutati sono mostrati come punti rossi:
- Addestra i 25 modelli selezionati per 1/25 del tempo di addestramento completo, quindi rifiuta altri cinque modelli in base ai punteggi ottenuti finora. Tieni presente che l'addestramento dei 25 modelli continua dal checkpoint precedente.
- Ripeti questa procedura finché non rimangono solo
Nmodelli con una buona distribuzione. - Addestra questi ultimi
Nmodelli fino al completamento.
L'impostazione predefinita per N_begin è 30 e può essere trovata come START_NUM_MODELS
nel file proxy_task/proxy_task_model_selection_lib_constants.py.
L'impostazione predefinita per N è 10 e può essere trovata come FINAL_NUM_MODELS nel file proxy_task/proxy_task_model_selection_lib_constants.py.
Il costo aggiuntivo di questo processo di selezione del modello viene calcolato come segue:
= (30*1/30 + 25*1/25 + 20*1/20 + 15*1/15 + 10*(remaining-training-time-fraction)) * full-training-time
= (4 + 10*(0.81)) * full-training-time
~= 12 * full-training-time
Tuttavia, rimani al di sopra dell'impostazione N=10. Lo strumento di ricerca delle attività proxy esegue successivamente questi modelli N in parallelo. Pertanto, assicurati di disporre di una quota GPU sufficiente. Ad esempio, se l'attività proxy utilizza due GPU per un modello, devi avere una quota di almeno 2*N GPU.
Per il job di selezione del modello, utilizza la stessa partizione del set di dati del job di addestramento completo della fase 2 e utilizza la stessa configurazione del trainer per l'addestramento completo di base.
Ora puoi lanciare il job di selezione del modello eseguendo il seguente comando (è necessario un service account):
DATE="$(date '+%Y%m%d_%H%M%S')"
project_id=<your project-id>
# You can choose any unique docker id below.
trainer_docker_id=${USER}_trainer_${DATE}
trainer_docker_file=<path to your trainer dockerfile>
latency_calculator_docker_id=${USER}_model_selection_${DATE}
latency_calculator_docker_file=${USER}_latency_${DATE}
region=<your job region such as 'us-central1'>
search_space_module=<path to your search space module>
accelerator_type="NVIDIA_TESLA_V100"
num_gpus=2
# Your bucket should be for your project and in the same region as the job.
root_output_dir=<gs://your-bucket>
# Your latency computation device.
target_device_type="CPU"
####### Proxy task model-selection related parameters ######
proxy_task_model_selection_docker_id=${USER}_model_selection_${DATE}
# Use the service account that you set-up for your project.
service_account=<your service account>
job_name=<your job name>
# The value below depends on your accelerator quota. By default
# the model-selection job runs 30 trials. However, depending on
# your quota, you can choose to only run 10 trials in parallel at a time.
# However, lowering this number can increase the overall runtime for the job.
max_parallel_nas_trial=<num parallel trials>
# The value below is the 'metric-id' corresponding to the accuracy ONLY
# metric reported by your trainer. Note that this metric may
# be different from the 'reward'.
accuracy_metric_id=<set accuracy metric id used by your trainer>
latency_metric_id=<set latency metric id used by your trainer>
############################################################
python3 vertex_nas_cli.py build \
--project_id=${project_id} \
--region=${region} \
--trainer_docker_id=${trainer_docker_id} \
--trainer_docker_file=${trainer_docker_file} \
--latency_calculator_docker_id=${latency_calculator_docker_id} \
--latency_calculator_docker_file=${latency_calculator_docker_file} \
--proxy_task_model_selection_docker_id=${proxy_task_model_selection_docker_id}
# The command below passes 'dummy' arguments for trainer-docker
# and latency-docker. You need to modify them for your own docker.
python3 vertex_nas_cli.py select_proxy_task_models \
--service_account=${service_account} \
--proxy_task_model_selection_docker_id=${proxy_task_model_selection_docker_id} \
--project_id=${project_id} \
--region=${region} \
--trainer_docker_id=${trainer_docker_id} \
--job_name=${job_name} \
--max_parallel_nas_trial=${max_parallel_nas_trial} \
--accuracy_metric_id=${accuracy_metric_id} \
--latency_metric_id=${latency_metric_id} \
--search_space_module=${search_space_module} \
--accelerator_type=${accelerator_type} \
--num_gpus=${num_gpus} \
--root_output_dir=${root_output_dir} \
--latency_calculator_docker_id=${latency_calculator_docker_id} \
--latency_docker_flags \
dummy_latency_flag1="dummy_latency_val" \
--target_device_type=${target_device_type} \
--search_docker_flags \
dummy_trainer_flag1="dummy_trainer_val"
Una volta avviato questo job del controller di selezione del modello, viene ricevuto un link al job. Il nome del job inizia con il prefisso Model_Selection_. Di seguito è riportato un esempio di UI del job:
model_selection_dir contiene tutti gli output. Controlla i log facendo clic sul link View logs.
Per impostazione predefinita, questo job del controller di selezione del modello utilizza una CPU su Google Cloud per l'esecuzione in background come job personalizzato, quindi avvia e gestisce i job NAS secondari per ogni iterazione della selezione del modello.
Ogni job NAS secondario ha un nome come <your_job_name>_iter_3 (ad eccezione dell'iterazione 0). Viene eseguita una sola iterazione alla volta. A ogni iterazione, il numero di modelli (numero di prove) diminuisce e la durata dell'addestramento aumenta. Al termine di ogni iterazione, ogni job NAS salva un file gs://<job-output-dir>/search/filtered_trial_scores.png che mostra visivamente quali modelli sono stati rifiutati in questa iterazione.
Puoi anche eseguire questo comando:
gcloud storage cat gs://<path to 'model_selection_dir'>/MODEL_SELECTION_STATE.json
che mostra un riepilogo delle iterazioni e dello stato attuale del job del controller di selezione del modello, il nome del job e i link per ogni iterazione:
{
"start_num_models": 30,
"final_num_models": 10,
"num_models_to_remove_per_iter": 5,
"accuracy_metric_id": "top_1_accuracy_without_latency",
"latency_metric_id": "latency_milli_seconds",
"iterations": [
{
"num_trials": 30,
"trials_to_retrain": [
"27",
"16",
...,
"14"
],
"search_job_name": "projects/123456/locations/europe-west4/nasJobs/2111217356469436416",
"search_job_link": "https://console.cloud.google.com/agent-platform/locations/europe-west4/training/2111217356469436416/cpu?project=my-project",
"latency_calculator_job_name": "projects/123456/locations/europe-west4/customJobs/6909239809479278592",
"latency_calculator_job_link": "https://console.cloud.google.com/agent-platform/locations/europe-west4/training/6909239809479278592/cpu?project=my-project",
"desired_training_step_pct": 2.0
},
...,
{
"num_trials": 15,
"trials_to_retrain": [
"14",
...,
"5"
],
"search_job_name": "projects/123456/locations/europe-west4/nasJobs/7045544066951413760",
"search_job_link": "https://console.cloud.google.com/agent-platform/locations/europe-west4/training/7045544066951413760/cpu?project=my-project",
"latency_calculator_job_name": "projects/123456/locations/europe-west4/customJobs/2790768318993137664",
"latency_calculator_job_link": "https://console.cloud.google.com/agent-platform/locations/europe-west4/training/2790768318993137664/cpu?project=my-project",
"desired_training_step_pct": 28.57936507936508
},
{
"num_trials": 10,
"trials_to_retrain": [],
"search_job_name": "projects/123456/locations/europe-west4/nasJobs/2742864796394192896",
"search_job_link": "https://console.cloud.google.com/agent-platform/locations/europe-west4/training/2742864796394192896/cpu?project=my-project",
"latency_calculator_job_name": "projects/123456/locations/europe-west4/customJobs/1490864099985195008",
"latency_calculator_job_link": "https://console.cloud.google.com/agent-platform/locations/europe-west4/training/1490864099985195008/cpu?project=my-project",
"desired_training_step_pct": 101.0
}
]
}
L'ultima iterazione ha il numero finale di modelli di riferimento con una buona distribuzione dei punteggi. Questi modelli e i relativi punteggi vengono utilizzati per la ricerca di attività proxy nel passaggio successivo. Se l'intervallo dei punteggi finali di accuratezza e latenza per i modelli di riferimento sembra migliore o vicino al modello di riferimento esistente, questo fornisce una buona indicazione iniziale sullo spazio di ricerca. Se l'intervallo finale dei punteggi di accuratezza e latenza è significativamente peggiore rispetto alla base di riferimento, rivedi lo spazio di ricerca.
Tieni presente che se più del 20% delle prove nella prima iterazione non va a buon fine, devi annullare il job di selezione del modello e identificare la causa principale degli errori. Potrebbe trattarsi di un problema con lo spazio di ricerca o con le impostazioni relative alle dimensioni del batch e al tasso di apprendimento.
Utilizzo del dispositivo di latenza on-premise per la selezione del modello
Per utilizzare il dispositivo di latenza on-premise per la selezione del modello, esegui il comando select_proxy_task_models senza i flag latency docker e latency-docker, perché non vuoi avviare il Docker di latenza su Google Cloud. Quindi, utilizza il comando run_latency_calculator_local descritto nel Tutorial 4 per avviare il job del calcolatore della latenza on-premise. Anziché passare il flag --search_job_id, passa il flag --controller_job_id con l'ID job di selezione del modello numerico che ottieni dopo aver eseguito il comando select_proxy_task_models.
Ripresa del job del controller di selezione del modello
Nelle seguenti situazioni è necessario riprendere il job del controller di selezione del modello:
- Il job del controller di selezione del modello principale si interrompe (caso raro).
- Annulli accidentalmente il job del controller di selezione del modello.
Innanzitutto, non annullare il job di iterazione NAS secondario (scheda NAS) se è già in esecuzione. Poi, per riprendere il job del controller di selezione del modello principale, esegui il comando select_proxy_task_models come prima, ma questa volta passa il flag --previous_model_selection_dir e impostalo sulla directory di output del job del controller di selezione del modello precedente. Il job del controller di selezione del modello ripreso carica lo stato precedente dalla directory e continua a funzionare come prima.
Ricerca di attività proxy
Dopo aver trovato i modelli candidati alla correlazione e i relativi punteggi di addestramento completo, il passaggio successivo consiste nell'utilizzarli per valutare i punteggi di correlazione per diverse scelte di attività proxy e scegliere l'attività proxy ottimale. Il nostro strumento di ricerca delle attività proxy può trovare automaticamente un'attività proxy, che offre quanto segue:
- Il costo di ricerca NAS più basso.
- Soddisfa una soglia minima di requisiti di correlazione dopo aver fornito una definizione dello spazio di ricerca delle attività proxy.
Ricorda che esistono tre dimensioni comuni per cercare un'attività proxy ottimale, tra cui:
- Numero ridotto di passaggi di addestramento.
- Quantità ridotta di dati di addestramento.
- Scala del modello ridotta.
Puoi creare uno spazio di ricerca di attività proxy discreto campionando queste dimensioni come mostrato di seguito:
Le percentuali riportate sopra sono solo un suggerimento e un esempio approssimativi. In pratica, puoi scegliere qualsiasi opzione discreta.
Tieni presente che non abbiamo incluso la dimensione training-steps nello spazio di ricerca riportato sopra. Questo perché lo strumento di ricerca delle attività proxy determina il passaggio di addestramento ottimale in base alla scelta dell'attività proxy.
Prendi in considerazione una scelta di attività proxy di [50% training data, 25% model scale]. Imposta il numero di passaggi di addestramento sullo stesso valore dell'addestramento di base completo.
Durante la valutazione di questa attività proxy, lo strumento di ricerca delle attività proxy avvia l'addestramento per i modelli candidati alla correlazione, monitora i loro punteggi di accuratezza attuali e calcola continuamente il punteggio di correlazione del ranking (utilizzando i punteggi di addestramento completo precedenti per i modelli di riferimento):
Pertanto, lo strumento di ricerca delle attività proxy può interrompere l'addestramento delle attività proxy una volta ottenuta la correlazione desiderata (ad esempio 0,65) o può anche interrompersi in anticipo se viene superata la quota di costo di ricerca (ad esempio un limite di 3 ore per attività proxy). Pertanto, non è necessario eseguire una ricerca esplicita nei passaggi di addestramento. Lo strumento di ricerca delle attività proxy valuta ogni attività proxy dello spazio di ricerca discreto come una ricerca a griglia e ti fornisce l'opzione migliore.
Di seguito è riportato un esempio di definizione dello spazio di ricerca delle attività proxy MnasNet
mnasnet_proxy_task_config_generator,
definito nel file proxy_task/proxy_task_search_spaces.py,
per mostrare come definire il tuo spazio di ricerca:
# MNasnet training-data size choices.
MNASNET_TRAINING_DATA_PCT_LIST = [25, 50, 75, 95]
# Training data path regex pattern.
_TRAINING_DATA_PATH_REGEX = r"gs://.*/.*"
def update_mnasnet_proxy_training_data(
baseline_docker_args_map: Dict[str, Any],
training_data_pct: int) -> Optional[Dict[str, Any]]:
"""Updates MNasnet baseline docker to use a certain training_data_pct."""
proxy_task_docker_args_map = copy.deepcopy(baseline_docker_args_map)
# Imagenet training data path looks like:
# gs://<path to imagenet data>/train-00[0-7]??-of-01024.
if not re.match(_TRAINING_DATA_PATH_REGEX,
baseline_docker_args_map["training_data_path"]):
raise ValueError(
"Training data path %s does not match the desired pattern." %
baseline_docker_args_map["training_data_path"])
root_path, _ = baseline_docker_args_map["training_data_path"].rsplit("/", 1)
if training_data_% == 25:
proxy_task_docker_args_map["training_data_path"] = os.path.join(
root_path, "train-00[0-1][0-4]?-of-01024*")
elif training_data_% == 50:
proxy_task_docker_args_map["training_data_path"] = os.path.join(
root_path, "train-00[0-4]??-of-01024*")
elif training_data_% == 75:
proxy_task_docker_args_map["training_data_path"] = os.path.join(
root_path, "train-00[0-6][0-4]?-of-01024*")
elif training_data_% == 95:
proxy_task_docker_args_map["training_data_path"] = os.path.join(
root_path, "train-00[0-8][0-4]?-of-01024*")
else:
logging.warning("Mnasnet training_data_% %d is not supported.",
training_data_pct)
return None
proxy_task_docker_args_map["validation_data_path"] = os.path.join(
root_path, "train-009[0-4]?-of-01024")
return proxy_task_docker_args_map
def mnasnet_proxy_task_config_generator(
baseline_docker_args_map: Dict[str, Any]
) -> List[proxy_task_utils.ProxyTaskConfig]:
"""Returns a list of proxy-task configs to be evaluated for MNasnet.
Args:
baseline_docker_args_map: A set of baseline training-docker arguments in
the form of a dictionary of {'key', val}. The different proxy-task
configs to try can be built by modifying this baseline.
Returns:
A list of proxy-task configs to be evaluated for this
proxy-task search space.
"""
proxy_task_config_list = []
# NOTE: Will not search over model-scale for MNasnet.
for training_data_% in MNASNET_TRAINING_DATA_PCT_LIST:
proxy_task_docker_args_map = update_mnasnet_proxy_training_data(
baseline_docker_args_map=baseline_docker_args_map,
training_data_pct=training_data_pct)
if not proxy_task_docker_args_map:
continue
proxy_task_name = "mnasnet_proxy_training_data_pct_{}".format(
training_data_pct)
proxy_task_config_list.append(
proxy_task_utils.ProxyTaskConfig(
name=proxy_task_name, docker_args_map=proxy_task_docker_args_map))
return proxy_task_config_list
In questo esempio, creiamo un semplice spazio di ricerca su training-data-percent
25, 50, 75 e 95 (tieni presente che il 100% dei dati di addestramento
non viene utilizzato per stage1-search).
La funzione mnasnet_proxy_task_config_generator prende un modello di base comune di argomenti Docker di addestramento e poi li modifica per ogni dimensione dei dati di addestramento dell'attività proxy desiderata. Quindi restituisce un elenco di proxy-task-config che viene poi elaborato dallo strumento di ricerca proxy-task uno alla volta nello stesso ordine. Ogni configurazione proxy-task ha un name e un docker_args_map, ovvero una mappa chiave-valore per gli argomenti Docker proxy-task.
Puoi implementare la tua definizione dello spazio di ricerca in base ai tuoi requisiti e progettare i tuoi spazi di ricerca delle attività proxy anche per più delle due dimensioni di dati di addestramento ridotti o scala del modello ridotta. Tuttavia, non è consigliabile eseguire una ricerca esplicita nei passaggi di addestramento perché ciò comporterebbe uno spreco di calcolo ripetuto. Lascia che sia lo strumento di ricerca delle attività proxy a gestire questa dimensione per te.
Per la prima ricerca di attività proxy, puoi provare
a ridurre solo i dati di addestramento (come nell'esempio MnasNet)
e saltare la riduzione della scala del modello, perché la scalabilità del modello può coinvolgere
più parametri su image-size, num-filters o num-blocks.
Nella maggior parte dei casi, i dati di addestramento ridotti (e la ricerca implicita su passaggi di addestramento ridotti) sono sufficienti per trovare un'attività proxy valida.
Imposta il numero di passaggi di addestramento sul numero utilizzato nell'addestramento della base di riferimento completa.
Esistono differenze tra le configurazioni di addestramento completo della fase 2 e quelle di addestramento delle attività proxy della fase 1. Per l'attività proxy, devi ridurre batch-size rispetto alla configurazione di addestramento della base di riferimento completa per utilizzare solo 2 o 4 GPU.
In genere, l'addestramento completo utilizza 4 GPU, 8 GPU o più, ma l'attività proxy utilizza solo 2 GPU o 4 GPU.
Un'altra differenza è la suddivisione tra addestramento e convalida.
Ecco un esempio di modifiche alla configurazione di MnasNet per passare da 4 GPU per l'addestramento completo della fase 2 a 2 GPU e una suddivisione di convalida diversa per la ricerca di attività proxy:
Avvia il job del controller di ricerca proxy-task eseguendo questo comando (è necessario un service account):
DATE="$(date '+%Y%m%d_%H%M%S')"
project_id=<your project-id>
# You can choose any unique docker id below.
trainer_docker_id=${USER}_trainer_${DATE}
trainer_docker_file=<path to your trainer dockerfile>
latency_calculator_docker_id=${USER}_model_selection_${DATE}
latency_calculator_docker_file=${USER}_latency_${DATE}
region=<your job region such as 'us-central1'>
search_space_module=<path to your NAS job search space module>
accelerator_type="NVIDIA_TESLA_V100"
num_gpus=2
# Your bucket should be for your project and in the same region as the job.
root_output_dir=<gs://your-bucket>
# Your latency computation device.
target_device_type="CPU"
####### Proxy task search related parameters ######
proxy_task_search_controller_docker_id=${USER}_proxy_task_search_${DATE}
job_name=<your job name>
# Path to your proxy task search space definition. For ex:
# 'proxy_task.proxy_task_search_spaces.mnasnet_proxy_task_config_generator'
proxy_task_config_generator_module=<path to your proxy task config generator module>
# The previous model-slection job provides the candidate-correlation-models
# and their scores.
proxy_task_model_selection_job_id=<Numeric job id of your previous model-selection>
# During proxy-task search, the proxy-task training is stopped
# when the following correlation score is achieved.
desired_accuracy_correlation=0.65
# During proxy-task search, the proxy-task training is stopped
# if the runtime exceeds this limit: 4 hrs.
training_time_hrs_limit=4
# The proxy-task is marked a good candidate only if the latency
# correlation is also above the required threshold.
# Note: This won't be used if you do not have a latency job.
desired_latency_correlation=0.65
# Early stop a proxy-task evaluation if you already have a better candidate.
# If False, evaluate all proxy-taask candidates.
early_stop_proxy_task_if_not_best=False
# Use the service account that you set-up for your project.
service_account=<your service account>
###################################################
python3 vertex_nas_cli.py build \
--project_id=${project_id} \
--region=${region} \
--trainer_docker_id=${trainer_docker_id} \
--trainer_docker_file=${trainer_docker_file} \
--latency_calculator_docker_id=${latency_calculator_docker_id} \
--latency_calculator_docker_file=${latency_calculator_docker_file} \
--proxy_task_search_controller_docker_id=${proxy_task_search_controller_docker_id}
# The command below passes 'dummy' arguments for trainer-docker
# and latency-docker. You need to modify them for your own docker.
python3 vertex_nas_cli.py search_proxy_task \
--service_account=${service_account} \
--proxy_task_search_controller_docker_id=${proxy_task_search_controller_docker_id} \
--proxy_task_config_generator_module=${proxy_task_config_generator_module} \
--proxy_task_model_selection_job_id=${proxy_task_model_selection_job_id} \
--proxy_task_model_selection_job_region=${region} \
--desired_accuracy_correlation={$desired_accuracy_correlation}\
--training_time_hrs_limit=${training_time_hrs_limit} \
--desired_latency_correlation=${desired_latency_correlation} \
--early_stop_proxy_task_if_not_best=${early_stop_proxy_task_if_not_best} \
--project_id=${project_id} \
--region=${region} \
--trainer_docker_id=${trainer_docker_id} \
--job_name=${job_name} \
--search_space_module=${search_space_module} \
--accelerator_type=${accelerator_type} \
--num_gpus=${num_gpus} \
--root_output_dir=${root_output_dir} \
--latency_calculator_docker_id=${latency_calculator_docker_id} \
--latency_docker_flags \
dummy_latency_flag1="dummy_latency_val" \
--target_device_type=${target_device_type} \
--search_docker_flags \
dummy_trainer_flag1="dummy_trainer_val"
Dopo aver avviato questo job del controller di ricerca delle attività proxy,
viene ricevuto un link al job. Il nome del job inizia con il prefisso Search_controller_. Di seguito è riportato un esempio di UI del job:
search_controller_dir conterrà tutti gli output e puoi controllare i log facendo clic sul link View logs.
Per impostazione predefinita, questo job utilizza una CPU nel cloud per l'esecuzione in background come job personalizzato, quindi avvia e gestisce i job NAS secondari per ogni valutazione dell'attività proxy.
Ogni job NAS dell'attività proxy ha un nome come ProxyTask_<your-job-name>_<proxy-task-name>, dove <proxy-task-name> è ciò che il modulo del generatore di configurazione dell'attività proxy fornisce per ogni attività proxy. Viene eseguita una sola valutazione dell'attività proxy alla volta.
Puoi anche eseguire questo comando:
gcloud storage cat gs://<path to 'search_controller_dir'>/SEARCH_CONTROLLER_STATE.json
Questo comando mostra un riepilogo di tutte le valutazioni delle attività proxy e lo stato attuale del job del controller di ricerca, il nome del job e i link per ogni valutazione:
{
"proxy_tasks_map": {
"mnasnet_proxy_training_data_pct_25": {
"proxy_task_stats": {
"training_steps": [
1249,
2499,
...,
18749
],
"accuracy_correlation_over_step": [
-0.06666666666666667,
-0.6,
...,
0.7857142857142856
],
"accuracy_correlation_p_value_over_step": [
0.8618005952380953,
0.016666115520282188,
...,
0.005505952380952381
],
"median_accuracy_over_step": [
0.011478611268103123,
0.04956454783678055,
...,
0.32932570576667786
],
"median_training_time_hrs_over_step": [
0.11611097933475001,
0.22913257125276987,
...,
1.6682701704073444
],
"latency_correlation": 0.9555555555555554,
"latency_correlation_p_value": 5.5114638447971785e-06,
"stopping_state": "Met desired correlation",
"posted_stop_trials_message": true,
"final_training_time_in_hours": 1.6675102778428197,
"final_training_steps": 18512
},
"proxy_task_name": "mnasnet_proxy_training_data_pct_25",
"search_job_name": "projects/123456/locations/europe-west4/nasJobs/4173661476642357248",
"search_job_link": "https://console.cloud.google.com/agent-platform/locations/europe-west4/training/4173661476642357248/cpu?project=my-project",
"latency_calculator_job_name": "projects/123456/locations/europe-west4/customJobs/8785347495069745152",
"latency_calculator_job_link": "https://console.cloud.google.com/agent-platform/locations/europe-west4/training/8785347495069745152/cpu?project=my-project"
},
...,
"mnasnet_proxy_training_data_pct_95": {
"proxy_task_stats": {
"training_steps": [
1249,
...,
18749
],
"accuracy_correlation_over_step": [
-0.3333333333333333,
...,
0.7857142857142856,
-5.0
],
"accuracy_correlation_p_value_over_step": [
0.21637345679012346,
...,
0.005505952380952381,
-5.0
],
"median_accuracy_over_step": [
0.01120645459741354,
...,
0.38238024711608887,
-1.0
],
"median_training_time_hrs_over_step": [
0.11385884770307843,
...,
1.5466042930547819,
-1.0
],
"latency_correlation": 0.9555555555555554,
"latency_correlation_p_value": 5.5114638447971785e-06,
"stopping_state": "Met desired correlation",
"posted_stop_trials_message": true,
"final_training_time_in_hours": 1.533235285929564,
"final_training_steps": 17108
},
"proxy_task_name": "mnasnet_proxy_training_data_pct_95",
"search_job_name": "projects/123456/locations/europe-west4/nasJobs/2341822328209408000",
"search_job_link": "https://console.cloud.google.com/agent-platform/locations/europe-west4/training/2341822328209408000/cpu?project=my-project",
"latency_calculator_job_name": "projects/123456/locations/europe-west4/customJobs/7575005095213924352",
"latency_calculator_job_link": "https://console.cloud.google.com/agent-platform/locations/europe-west4/training/7575005095213924352/cpu?project=my-project"
}
},
"best_proxy_task_name": "mnasnet_proxy_training_data_pct_75"
}
proxy_tasks_map memorizza l'output per ogni valutazione dell'attività proxy e best_proxy_task_name registra l'attività proxy migliore per la ricerca. Ogni voce di attività proxy contiene dati aggiuntivi come proxy_task_stats, che registra l'avanzamento della correlazione di accuratezza, i relativi valori p, l'accuratezza mediana e il tempo di addestramento mediano nei passaggi di addestramento. Registra anche la correlazione relativa alla latenza, se applicabile, e il motivo dell'interruzione del job (ad esempio il superamento del limite di tempo di addestramento) e il passaggio di addestramento in cui si interrompe. Puoi anche visualizzare queste statistiche
come grafici copiando i contenuti di search_controller_dir nella
tua cartella locale eseguendo questo comando:
gcloud storage cp gs://<path to 'search_controller_dir'>/* /your/local/dir
e ispezionare le immagini dei grafici. Ad esempio, il grafico seguente mostra la correlazione tra accuratezza e tempo di addestramento per la migliore attività proxy:
La ricerca è completa e hai trovato la migliore configurazione dell'attività proxy. Ora devi:
- Imposta il numero di passaggi di addestramento sul valore
final_training_stepsdell'attività proxy vincente. - Imposta i passaggi di decadimento del coseno come
final_training_steps, in modo che il tasso di apprendimento diventi quasi zero verso la fine. - [Facoltativo] Esegui una valutazione del punteggio di convalida alla fine dell'addestramento, in modo da risparmiare sui costi di più valutazioni.
Utilizzo del dispositivo di latenza on-premise per la ricerca di attività proxy
Per utilizzare il dispositivo di latenza on-premise per la ricerca di attività proxy, esegui il comando search_proxy_task senza i flag latency docker e latency-docker, perché non vuoi avviare il docker di latenza su Google Cloud. Quindi, utilizza il comando run_latency_calculator_local descritto nel Tutorial 4 per avviare il job del calcolatore della latenza on-premise. Anziché passare il flag --search_job_id, passa il flag --controller_job_id con l'ID job proxy-task-search numerico che ottieni dopo aver eseguito il comando search_proxy_task.
Ripresa del job del controller di ricerca delle attività proxy
Le seguenti situazioni richiedono la ripresa del job del controller di ricerca delle attività proxy:
- Il job del controller di ricerca dell'attività proxy principale si interrompe (caso raro).
- Annulli accidentalmente il job del controller di ricerca delle attività proxy.
- Vuoi estendere lo spazio di ricerca delle attività proxy in un secondo momento (anche dopo molti giorni).
Innanzitutto, non annullare il job di iterazione NAS secondario (scheda NAS) se è già in esecuzione. Poi, per riprendere il job del controller di ricerca dell'attività proxy principale, esegui il comando search_proxy_task come prima, ma questa volta passa il flag --previous_proxy_task_search_dir e impostalo sulla directory di output del job del controller di ricerca dell'attività proxy precedente. Il job del controller di ricerca dell'attività proxy ripreso carica lo stato precedente dalla directory e continua a funzionare come prima.
Controlli finali
Due controlli finali per l'attività proxy includono l'intervallo di ricompensa e il salvataggio dei dati per l'analisi post-ricerca.
Intervallo di premi
La ricompensa segnalata al controller deve essere compresa nell'intervallo [1e-3, 10]. In caso contrario, puoi scalare artificialmente la ricompensa per raggiungere questo obiettivo.
Salva i dati per l'analisi post-ricerca
Il codice dell'attività proxy deve salvare eventuali metriche e dati aggiuntivi nella posizione di Cloud Storage, che potrebbe essere utile per analizzare lo spazio di ricerca in un secondo momento. La nostra piattaforma di agenti Neural Architecture Search supporta solo la registrazione di un massimo di cinque rappresentazioni in virgola mobile other_metrics.
Eventuali metriche aggiuntive devono essere salvate nella posizione di Cloud Storage per un'analisi successiva.