Solo una delle 33 regioni di AWS Bedrock — us-west-2 — permette di effettuare il fine-tuning del modello Llama 3.3 da 70 miliardi di parametri. Gli sviluppatori devono scegliere se comporre pipeline cross-region o sopportare un workaround macchinoso.

Perché questa scoperta è importante

La pagina pubblica dei prezzi di AWS elenca ancora i costi di addestramento per la vecchia serie Llama 2. Le più recenti famiglie Llama 3.1 e 3.3 mancano completamente. Gli ingegneri sono costretti a tirare a indovinare quali regioni supportino effettivamente il fine-tuning, quanto tempo i job rimarranno in coda e se il tempo di inattività verrà fatturato.

I numeri reali

  • us-west-2 – l'unica regione in cui il fine-tuning di Llama 3.3 70B funziona.
  • us-east-1 – solo modelli creati da Amazon; nessun fine-tuning per Llama o Anthropic.
  • eu-west-2 (Londra) – permette il fine-tuning di un singolo modello non Llama.
  • Tutte le altre regioni – restituiscono errori di tipo “model not available” per Llama 3.3 70B.

Se hai bisogno di un Llama 3.3 70B personalizzato tramite fine-tuning, esegui il job in us-west-2 e sposta i dati tra le regioni, oppure prova la strada del “Custom Model Import”, che il tentativo dell'autore ha fatto fallire con un generico errore hardware.

Custom Model Import: una deviazione rischiosa

La documentazione AWS afferma che il “Custom Model Import” può importare pesi inferiori a 200 GB in qualsiasi regione, inclusa eu-central-1. In realtà, i tentativi di importare Llama 3.3 70B (che supera ampiamente tale dimensione) si sono ripetutamente scontrati con un “hardware error”. Per ora, l'opzione più sicura rimane l'endpoint nativo di fine-tuning in us-west-2.

Due trucchi per risparmiare (denaro e salute mentale)

  1. Non fidarti del flag “InProgress” di primo livello. Un job può rimanere in una coda gestita da AWS per ore con quello stato, mentre non viene eseguita alcuna computazione. La fatturazione inizia solo quando il campo annidato trainingDetails passa a “Running”. Controlla il flag interno per evitare di pagare per il tempo di inattività in coda.
  2. La pazienza batte l'impazienza. Un job di test è rimasto in coda per 23 ore prima che l'addestramento iniziasse, completandosi poi senza problemi. Interromperlo e riavviarlo lo ha mandato in fondo alla fila, estendendo il tempo di attesa totale. Il tempo in coda è gratuito; i costi iniziano quando le istanze GPU vengono avviate.

Altre lezioni sul campo

  • Gli schemi dei modelli sono diversi. Llama 3.3 e Llama 3.1 utilizzano oggetti di configurazione distinti. Copiare e incollare uno schema JSON da una versione all'altra genera errori di validazione, anche se i limiti come la lunghezza dei token coincidono.
  • Particolarità delle quote. Il limite sui “Custom models with a creating status” è spesso molto più basso della quota totale dei job. Se ricevi un errore di “quota exceeded” mentre un job precedente mostra ancora “creating”, elimina la voce obsoleta prima di lanciarne uno nuovo.
  • Lo storage si accumula. Ogni checkpoint sottoposto a fine-tuning consuma spazio di archiviazione S3, fatturato alle tariffe standard. Lasciare le vecchie versioni intatte gonfia la bolletta mensile senza apportare alcun valore.

In sintesi

Se il tuo progetto dipende da un modello Llama 3.3 70B sottoposto a fine-tuning, pianifica di eseguire questo passaggio in us-west-2, oppure preparati a un processo di tentativi ed errori con gli import personalizzati. Verifica lo stato della coda a livello granulare, evita di interrompere i job in attesa prolungata e monitora attentamente l'uso dello storage e delle quote.