Addestra su un server GPU, un cluster SLURM o una macchina dietro NAT

Novità nella v2.14.0

Questo tutorial sposta l'addestramento di modelli di Potato dal server di annotazione a una macchina con una GPU. Il tutorial è per l'amministratore di uno studio il cui server di annotazione è una piccola VM cloud o un portatile, e le cui GPU si trovano su un server di laboratorio, su un cluster universitario o su una workstation a cui il server non riesce a connettersi. Per ciascuno dei tre backend remoti, la pagina tratta quando sceglierlo, che cosa deve essere installato sulla macchina remota, la configurazione, il comando di verifica, che cosa accade durante un'esecuzione, come annullare un'esecuzione e i guasti più probabili. Il tutorial presuppone un progetto che già si addestra sul server di annotazione, come il progetto sulle recensioni di Addestra il tuo primo modello.

Quattro posti in cui può girare un'esecuzione

Un backend è il luogo in cui gira un'esecuzione di addestramento. Potato ha sempre il backend local, un sottoprocesso sul server di annotazione. Gli altri backend si indicano sotto model_training.backends:

Scegli ssh quando il server di annotazione può accedere alla macchina GPU con una chiave ssh. Scegli slurm quando le GPU stanno dietro lo scheduler SLURM e la macchina a cui puoi accedere è un nodo di login. Scegli agent quando dal server non si può aprire alcuna connessione verso la macchina GPU, perché l'agente apre da solo ogni connessione. Una workstation dietro un router domestico o un firewall universitario è il caso tipico di un agente. Le predizioni e il risultato dell'esecuzione raggiungono il server da ogni backend, quindi il write-back e il punteggio held-out funzionano allo stesso modo ovunque abbia girato il trainer. Ogni trainer tranne decision-calibrate gira su qualsiasi backend.

La configurazione del progetto

La configurazione seguente è il progetto sulle recensioni del primo tutorial con tutti e tre i backend remoti aggiunti. Un progetto reale ha bisogno solo dei backend che usa, e ogni backend ha una propria sezione più sotto. max_wall_seconds: 3600 ferma ogni esecuzione che non è terminata entro un'ora. Su un backend ssh o agent il server controlla il limite ogni secondo, quindi un'esecuzione che si blocca su una macchina remota non occupa la coda delle esecuzioni oltre il limite:

annotation_task_name: "Review Sentiment"
task_dir: "."
data_files:
  - "data/reviews.json"
item_properties:
  id_key: "id"
  text_key: "text"
output_annotation_dir: "annotation_output"
admin_api_key: "change-me"
 
annotation_schemes:
  - annotation_type: "radio"
    name: "sentiment"
    description: "Is this review positive or negative?"
    labels: ["positive", "negative"]
 
model_training:
  enabled: true
  backend: gpu-server        # the default for runs; leave out to keep runs local
  max_wall_seconds: 3600
  writeback:
    schemas: ["sentiment"]
    include_unlabeled: true
    min_confidence: 0.6
  backends:
    gpu-server:
      type: ssh
      host: gpu.example.org
      python: /opt/conda/bin/python3
      gpus: auto
      min_free_gpu_mb: 4000
    cluster:
      type: slurm
      host: login.cluster.example.org
      python: /opt/conda/bin/python3
      job_python: /shared/envs/train/bin/python
      remote_dir: /shared/projects/me/potato-training
      gres: gpu:1
      time: "04:00:00"
      prelude: ["module load cuda/12.4"]
    lab-workstation:
      type: agent
      queue_timeout_s: 3600

Convalida la configurazione prima di avviare il server:

potato validate config.yaml --strict

Il validatore segnala una chiave che il tipo di backend non accetta, un backend ssh o slurm senza host, un remote_dir di SLURM sotto /tmp e un model_training.backend che non indica alcun backend. Il server non si avvia per gli stessi errori, quindi un pyhton scritto male ferma il server all'avvio invece di inviare le esecuzioni al python3 predefinito.

Il menu Runs on e l'API

La pagina Training in /admin/training ha un menu Runs on che elenca ogni backend con il suo tipo e il suo host, ad esempio gpu-server (ssh to gpu.example.org). model_training.backend stabilisce la voce che il menu seleziona per prima, e la tabella Runs registra dove ha girato ogni esecuzione nella colonna Ran on. Un'esecuzione avviata tramite l'API indica il proprio backend nel campo backend del corpo della richiesta:

curl -X POST -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  http://localhost:8000/admin/training/api/runs \
  -d '{"trainer": "hf-text-classification", "schemas": ["sentiment"], "backend": "cluster"}'

Un nome di backend che non è nella configurazione viene rifiutato con 409. Il riaddestramento automatico usa model_training.backend a meno che auto_retrain.backend non indichi un altro backend, e Il modello nel ciclo tratta auto_retrain per intero. Un'esecuzione alla volta gira qualunque sia il backend, e un'esecuzione avviata mentre un'altra è in corso aspetta nella coda.

Addestrare su questa macchina

Controlla quale dispositivo riceve un'esecuzione locale prima di spostare le esecuzioni altrove. Con device: auto predefinito, un'esecuzione locale prende prima CUDA, poi Metal di Apple (mps), poi la CPU, e device: cuda:1 indica una GPU precisa. Il comando di verifica stampa il dispositivo che un'esecuzione locale userebbe:

potato training check local config.yaml

Su un Mac con Apple silicon, il comando stampa local: this machine, Apple Metal (mps). Un dispositivo richiesto che non è presente ripiega sulla CPU o su un altro acceleratore, con un avviso nel log dell'esecuzione. Quando la risposta è CPU e il trainer esegue il fine-tuning di un transformer, sposta l'esecuzione su un backend remoto tra quelli qui sotto. La configurazione elenca device, num_threads e max_ram_mb per le esecuzioni locali.

Un server GPU via ssh

Un backend ssh esegue il trainer su una macchina che il server di annotazione raggiunge via ssh, tipicamente un server GPU di laboratorio. Potato avvia da solo tutto sul lato remoto, quindi lì non si installa né si avvia nulla a mano oltre a Python e ai pacchetti del trainer. L'host GPU non ha bisogno di Potato installato, perché Potato copia il proprio codice sorgente Python sull'host alla prima esecuzione e riutilizza la copia finché il sorgente non cambia.

Requisiti di un backend ssh

L'account con cui gira il server di annotazione ha bisogno di una chiave ssh che acceda all'host GPU senza richieste. Potato esegue ssh con BatchMode=yes, quindi una richiesta di password fa fallire subito l'esecuzione invece di bloccarla. Eseguire ssh gpu.example.org true con quell'account deve riuscire, e una chiave con passphrase funziona quando ssh-agent detiene la chiave. Il valore host è un qualunque nome che ssh accetta, e funziona un alias di ~/.ssh/config. Le chiavi user, port e identity_file vengono passate a ssh come -l, -p e -i.

L'host GPU ha bisogno di Python 3.8 o successivo e dei pacchetti del trainer che esegui. Per hf-text-classification quei pacchetti sono torch, transformers e peft, il contenuto dell'extra potato-annotation[train-text]. La pagina Trainer indica l'installazione di ogni trainer. Quando all'interprete dell'host manca un pacchetto, punta python a un interprete che lo ha, oppure elenca il pacchetto sotto packages. Con packages impostato, Potato crea un ambiente virtuale sotto remote_dir con --system-site-packages e vi installa una sola volta i pacchetti elencati. La build CUDA di torch dell'host resta visibile all'interno dell'ambiente:

model_training:
  enabled: true
  backends:
    gpu-server:
      type: ssh
      host: gpu.example.org
      python: /opt/conda/bin/python3
      packages: ["transformers>=4.46.0", "peft>=0.13.0"]
      gpus: auto
      min_free_gpu_mb: 4000
      num_threads: 8

Con gpus: auto, ogni esecuzione prende la GPU con più memoria libera e si rifiuta di partire quando nessuna GPU ha min_free_gpu_mb liberi (2000 per impostazione predefinita). Potato confronta la memoria libera e non l'utilizzo, perché una scheda con utilizzo basso su un server condiviso può comunque avere poca memoria libera. Imposta min_free_gpu_mb vicino alla memoria di cui il tuo trainer ha bisogno. gpus: "1" fissa la GPU 1, "0,1" ne fissa due e gpus: none addestra sulla CPU. Anche un host senza alcuna GPU si addestra sulla sua CPU con auto. num_threads imposta OMP_NUM_THREADS, MKL_NUM_THREADS e OPENBLAS_NUM_THREADS per l'esecuzione. Alcuni server condivisi impostano OMP_NUM_THREADS=1 nelle shell di login, e num_threads sostituisce il valore della shell di login.

Il comando di verifica per un backend ssh

Esegui la verifica dal server di annotazione, con l'account con cui gira il server:

potato training check gpu-server config.yaml

Il comando si connette e riporta la versione di Python remota, ogni GPU con la sua memoria libera e il suo utilizzo, la GPU che un'esecuzione riceverebbe e i pacchetti di addestramento che mancano all'interprete remoto. Una GPU per cui il torch installato non ha kernel è contrassegnata con (torch there has no kernels for it), e gpus: auto salta una GPU simile. --json stampa lo stesso rapporto come JSON. Il comando termina con 0 quando un'esecuzione potrebbe partire e con 1 altrimenti. Il pulsante Check accanto al menu Runs on esegue la stessa verifica dalla pagina Training.

I passi di un'esecuzione ssh

Per ogni esecuzione, Potato compie questi passi:

1. Si connette con ssh e apre un reverse forward da un socket unix nel /tmp remoto verso il server di annotazione.
2. Controlla l'interprete, legge nvidia-smi e sceglie la GPU.
3. Copia il sorgente di Potato in remote_dir/code/<hash> quando all'host manca quella versione, e crea l'ambiente virtuale quando packages è impostato e l'ambiente non esiste. remote_dir vale per impostazione predefinita ~/.cache/potato-training.
4. Avvia python -m potato.training.agent per l'esecuzione. Il token dell'esecuzione raggiunge l'agente su stdin e non compare mai su una riga di comando, perché le righe di comando sono visibili a ogni account di un server condiviso.
5. L'agente scarica il bundle di item, etichette e media dell'esecuzione. L'agente esegue lo stesso worker di addestramento che esegue il backend locale e rimanda attraverso il socket avanzamento, predizioni e risultato.
6. Quando l'esecuzione riesce, Potato copia la directory degli artefatti in artifacts/ dell'esecuzione, elimina la directory remota del job e chiude la connessione.

La riga dei passi nella pagina Training segue quelle fasi, ad esempio copying Potato's code to gpu.example.org e waiting for the agent on gpu.example.org. Il log dell'esecuzione riporta il Python dell'host e la GPU ricevuta dall'esecuzione.

Un fine-tuning completo copia indietro l'intero modello, e su un collegamento lento un modello da 330 MB richiede minuti. La riga dei passi mostra quanta parte del modello è arrivata. I file più grandi di max_artifact_mb (2048 per impostazione predefinita) restano sull'host GPU e sono nominati nel log dell'esecuzione. fetch_artifacts: false lascia ogni file del modello sull'host GPU, e keep_remote: true conserva la directory remota del job per l'ispezione. L'invio a Hugging Face Hub dalla pagina dell'esecuzione richiede i file del modello sul server di annotazione, quindi un modello lasciato sull'host GPU non viene inviato dalla pagina dell'esecuzione.

Il socket unix viene creato con modalità 0600, quindi solo l'account con cui Potato ha effettuato l'accesso può connettersi attraverso il socket. Le richieste attraverso il socket arrivano al server di annotazione come richieste di loopback. Un server avviato con debug: true concede l'accesso di amministrazione alle richieste di loopback. Chiunque possa usare quell'account sull'host GPU ha allora accesso di amministrazione a un server in debug mentre un'esecuzione è in corso. Tieni debug disattivato su un server che si addestra via ssh.

Annullamento e timeout dell'heartbeat

Cancel run nella pagina Training raggiunge l'agente attraverso il socket, nella risposta al successivo rapporto di avanzamento dell'agente. L'agente invia SIGTERM al worker, e SIGKILL se il worker è ancora in esecuzione dopo model_training.grace_seconds (20 per impostazione predefinita), che il server invia insieme al job. Un job proveniente da un server Potato più vecchio non porta grace_seconds, e l'agente allora attende 20 secondi. Sul server, l'esecuzione termina come annullata una volta trascorsi grace_seconds, e il server chiude la sessione ssh dell'agente. Un'esecuzione il cui agente non invia nulla per heartbeat_timeout_s (120 per impostazione predefinita) fallisce, e agent.log nella directory dell'esecuzione contiene l'ultimo output dell'agente.

Un cluster SLURM

Un backend slurm è per un cluster le cui GPU stanno dietro lo scheduler SLURM. Su un cluster simile la macchina che Potato raggiunge via ssh è un nodo di login senza GPU, e i nodi di calcolo non possono raggiungere affatto Potato. Potato avvia quindi l'agente sul nodo di login, come fa un backend ssh, e l'agente invia con sbatch solo il worker di addestramento a un nodo di calcolo. L'avanzamento torna attraverso un file su uno storage condiviso dal nodo di login e dai nodi di calcolo.

Requisiti di un backend SLURM

Il nodo di login ha bisogno di una chiave ssh senza richieste e di Python 3.8 o successivo per l'agente, come l'host di un backend ssh. Il nodo di login ha bisogno anche di sbatch, squeue e scancel nel PATH. L'agente chiama anche scontrol dove il cluster ha il comando. Potato non chiama mai srun né sacct, quindi funziona anche un cluster con srun disattivato e senza database di accounting. remote_dir è obbligatorio e deve stare su uno storage condiviso dai nodi di calcolo, perché il job legge il bundle e vi scrive il modello. Il validatore segnala un errore per un remote_dir sotto /tmp o /var/tmp, perché quelle directory sono locali a ciascun nodo.

I nodi di calcolo hanno bisogno di un interprete con i pacchetti del trainer, indicato da job_python. packages non è supportato su un backend SLURM, perché un ambiente virtuale creato sul nodo di login può non funzionare sui nodi di calcolo. Punta job_python a un ambiente che i nodi di calcolo hanno, e metti i caricamenti di moduli o l'attivazione di un ambiente in prelude:

model_training:
  enabled: true
  backends:
    cluster:
      type: slurm
      host: login.cluster.example.org
      python: /opt/conda/bin/python3                    # on the login node, for the agent
      job_python: /shared/envs/train/bin/python         # on the compute nodes, for the worker
      remote_dir: /shared/projects/me/potato-training   # storage the compute nodes share
      partition: gpu
      gres: gpu:1
      time: "04:00:00"
      prelude: ["module load cuda/12.4"]

Ogni chiave ssh vale per un backend SLURM tranne gpus e packages. Le GPU vengono da gres, e lo scheduler imposta CUDA_VISIBLE_DEVICES per le GPU che concede. Un job senza gres non riceve alcuna GPU. Le impostazioni di SLURM corrispondono ai flag di sbatch:

Un time superiore a 6 ore fa riportare a potato validate e all'avvio del server model_training.backends.cluster.time is 12:00:00. A job that holds a GPU for more than 6 hours is long on a shared cluster; check its policy, e potato validate --strict fallisce sull'avviso. Quando la policy del cluster consente il job più lungo, riconosci l'avviso per quel solo backend in un blocco validation di primo livello, che solo potato validate legge:

validation:
  acknowledge:
    - "model_training.backends.cluster.time is"

Ogni voce viene confrontata con il testo dell'avviso come sottostringa con distinzione tra maiuscole e minuscole di almeno 12 caratteri, e un avviso corrispondente passa all'elenco di quelli riconosciuti e non fa più fallire --strict. Una voce che nomina il backend riconosce l'avviso solo per quel backend. Una voce troppo corta o che non corrisponde ad alcun avviso diventa essa stessa un avviso.

Il comando di verifica per un backend SLURM

potato training check cluster config.yaml

La verifica accede al nodo di login e conferma che sbatch, squeue e scancel sono nel PATH e che remote_dir non è sotto /tmp. Il rapporto riporta la versione di Python sul nodo di login e il job_python che il job eseguirà. La verifica non può vedere quali pacchetti hanno i nodi di calcolo, quindi un pacchetto mancante su un nodo di calcolo emerge come un'esecuzione fallita con l'errore di importazione nel log dell'esecuzione. Esegui un primo job breve con un time piccolo per trovare presto problemi simili.

I passi di un'esecuzione SLURM

Potato si connette al nodo di login e vi copia il proprio codice, come per un backend ssh. L'agente compie poi questi passi:

1. Scarica il bundle in remote_dir/jobs/<run>/.
2. Scrive job.sh e invia lo script con sbatch --parsable. Il log dell'esecuzione registra Submitted SLURM job con l'ID del job e i flag.
3. Nella directory del job, il worker sul nodo di calcolo scrive i propri eventi in events.jsonl, i propri errori in stderr.log e il proprio codice di uscita in exit_code. L'output di SLURM va in slurm.out.
4. L'agente legge events.jsonl mentre il file cresce e inoltra l'avanzamento al server. L'agente esegue squeue una volta ogni poll_interval_s, e il log dell'esecuzione registra ogni cambio dello stato del job in coda, ad esempio SLURM job 4242: PENDING (Priority) e poi RUNNING on node07.
5. Quando il job termina, l'agente carica le predizioni e riporta il risultato. Gli artefatti tornano al server e la directory del job viene rimossa, come per un backend ssh.

Cancel run invia scancel --full --signal=TERM al job, poi un semplice scancel se il worker non si è fermato. Quando la sessione ssh verso il nodo di login cade, l'agente annulla il proprio job e l'allocazione della GPU viene rilasciata. Quando è lo scheduler a terminare un job, l'esecuzione fallisce con il motivo dello scheduler, letto da scontrol show job o da slurm.out. I motivi che Potato riporta includono il limite di tempo, il guasto di un nodo, la prelazione, l'esaurimento della memoria e uno scancel dall'esterno di Potato.

La suite di test di Potato esegue la sequenza SLURM contro un sostituto di sbatch, squeue e scancel, e copre l'invio del job, lo stato in coda, l'inoltro dell'avanzamento e l'annullamento. I limiti delle partizioni e la politica di prelazione differiscono da cluster a cluster, quindi osserva il log dell'esecuzione del tuo primo job su un nuovo cluster.

Anche un agente avviato a mano su un nodo di login che raggiunge il server può inviare a SLURM, con potato training agent --server ... --backend <name> --workdir <shared dir> --slurm-config slurm.json. Il file slurm.json contiene come oggetto JSON le impostazioni della tabella qui sopra, e --workdir deve stare su uno storage condiviso dai nodi di calcolo.

Una macchina che Potato non riesce a raggiungere

Un backend agent è per una macchina a cui il server di annotazione non riesce a connettersi, come una workstation dietro NAT. Qualcuno avvia potato training agent su quella macchina, e l'agente interroga il server per i job. L'agente non ha bisogno di alcuna porta in ingresso, perché l'agente apre ogni connessione. Un annullamento raggiunge l'agente nella risposta del server al successivo rapporto di avanzamento dell'agente. I file del modello restano sulla macchina di addestramento, e tornano solo le predizioni e il risultato.

Requisiti di un backend agent

La macchina di addestramento ha bisogno di Potato installato, dei pacchetti del trainer che esegui e di un percorso di rete verso l'URL del server di annotazione. Per hf-text-classification, una sola installazione copre Potato e i pacchetti del trainer:

pip install "potato-annotation[train-text]"

Il server ha bisogno solo della voce del backend. Un backend agent accetta type, description, heartbeat_timeout_s (120 per impostazione predefinita) e queue_timeout_s, e nessun'altra chiave:

model_training:
  enabled: true
  backends:
    lab-workstation:
      type: agent
      queue_timeout_s: 3600

Registrare e avviare l'agente

Emetti un token per il backend sul server di annotazione:

potato training register lab-workstation config.yaml

Il comando stampa il token una sola volta, con i comandi da eseguire sulla macchina di addestramento:

Token for backend 'lab-workstation' (shown once; registering again replaces it):
 
  <token>
 
On the training machine:
 
  export POTATO_TRAINING_TOKEN=<token>
  potato training agent --server http://<this-server>:8000 --backend lab-workstation

Avvia l'agente sulla macchina di addestramento con l'URL reale del server:

export POTATO_TRAINING_TOKEN=<the token>
potato training agent --server https://annotate.example.org --backend lab-workstation

L'agente esegue i job del proprio backend finché non lo fermi. --token-file legge il token da un file invece che da POTATO_TRAINING_TOKEN, --python indica l'interprete in cui gira il worker di addestramento, e il valore predefinito è l'interprete dell'agente stesso. --once termina dopo un job, --workdir sposta i file dell'agente da ~/.cache/potato-training, e --keep conserva il bundle di ogni job. Registrare di nuovo lo stesso nome emette un nuovo token e invalida quello vecchio.

potato training check lab-workstation config.yaml stampa il record del token del backend, con last_seen valorizzato una volta che un agente si è connesso. Prima della registrazione il comando stampa no token issued yet e il comando di registrazione da eseguire.

I passi di un'esecuzione agent

Un'esecuzione per un backend agent aspetta nello stato queued finché un agente non chiede lavoro. Con queue_timeout_s: 3600, l'esecuzione fallisce dopo un'ora senza agente, e senza queue_timeout_s l'esecuzione aspetta finché non la annulli. L'agente scarica il bundle come file tar.gz e riprende da dove si era fermato un download interrotto, fino a cinque tentativi. L'agente poi esegue il worker, invia l'avanzamento, carica predictions.jsonl e riporta il codice di uscita. Il server risponde 413 a un file di predizioni più grande di max_predictions_mb (512 per impostazione predefinita).

I file del modello restano sulla macchina di addestramento sotto --workdir, e artifact_uri nel record dell'esecuzione indica l'host e la directory. Se l'agente non raggiunge il server per 300 secondi durante un'esecuzione, l'agente annulla da solo l'esecuzione. Un'esecuzione il cui agente non invia nulla per heartbeat_timeout_s fallisce sul server con No word from the agent on lab-workstation for 120 seconds.

Guasti comuni

Ogni voce riporta il messaggio nel log dell'esecuzione o nel rapporto di verifica, poi la correzione. L'elenco completo per ogni backend e trainer si trova nella sezione di risoluzione dei problemi di Potato.

• ssh to gpu.example.org failed: Permission denied. Potato ha bisogno di una chiave che funzioni senza richieste. ssh gpu.example.org true dall'account del server deve riuscire.
• /opt/conda/bin/python3 was not found on gpu.example.org. Imposta python nel backend a un interprete che esiste sull'host.
• No GPU has 4000 MB free. Ogni GPU dell'host è più occupata di quanto min_free_gpu_mb consenta. potato training check gpu-server config.yaml elenca le GPU. Aspetta, abbassa la soglia o fissa una GPU con gpus: "1".
• Trainer 'hf-text-classification' could not be imported. All'interprete remoto manca un pacchetto di cui il trainer ha bisogno. Punta python a un interprete che lo ha, oppure elenca il pacchetto sotto packages. Su un backend SLURM, correggi l'ambiente indicato da job_python.
• This host's torch has no kernels for any of its GPUs. Il torch remoto è stato compilato per GPU più recenti di quelle dell'host. Installa una build di torch per quelle GPU, oppure usa un altro host.
• No word from the agent on gpu-server for 120 seconds. La macchina remota o la rete sono scomparse. Su un backend ssh, agent.log nella directory dell'esecuzione contiene l'ultimo output dell'agente.
• The copy from gpu.example.org sent nothing for 180 s. La rete verso l'host si è fermata mentre il modello veniva copiato indietro. Le predizioni dell'esecuzione sono già memorizzate, e mancano in artifacts/ solo i file del modello.
• login.cluster.example.org has no sbatch on PATH, so it cannot submit jobs. L'host non è il nodo di login del cluster, oppure i comandi stanno in un PATH che solo una shell di login imposta. Imposta PATH sotto env del backend.
• SLURM job 4242 ended before the worker finished: it reached its time limit. Aumenta time nel backend, oppure addestra su meno item. Imposta keep_remote: true per conservare slurm.out e leggerlo dopo altri guasti dello scheduler.
• Un'esecuzione su un backend agent resta in coda. Nessun agente con quel nome di backend sta interrogando il server. Avvia un agente con potato training agent --backend lab-workstation e controlla il token con Check nella pagina Training.
• nvrtc: error: failed to open libnvrtc-builtins.so.13.0. Il torch dell'host e il suo pacchetto nvidia-cuda-nvrtc sono per versioni CUDA diverse. Installa il nvidia-cuda-nvrtc che corrisponde alla build di torch, oppure punta python a un altro interprete.

Ulteriori letture

• La panoramica dell'addestramento di modelli tratta la pagina Training, il ciclo di addestramento e la pubblicazione di un modello su Hugging Face Hub.
• La configurazione elenca ogni chiave di model_training, i punteggi held-out e dove vengono memorizzate le esecuzioni.
• Fine-tuning di LLM tratta i trainer che più spesso hanno bisogno di una GPU remota, con LoRA e pesi di base a 4 bit.
• Il riferimento di Potato su dove girano le esecuzioni contiene la tabella completa delle chiavi di ogni backend, e la sezione sul protocollo dell'agente documenta le route per chi scrive un proprio agente.