Une seule des 33 régions d'AWS Bedrock — us-west-2 — permet d'affiner le modèle Llama 3.3 à 70 milliards de paramètres. Les développeurs doivent soit assembler des pipelines multi-régions, soit se contenter d'une solution de contournement peu pratique.

Pourquoi cette découverte est importante

La page publique des tarifs d'AWS liste encore les coûts d'entraînement pour l'ancienne série Llama 2. Les nouvelles familles Llama 3.1 et 3.3 sont totalement absentes. Les ingénieurs sont contraints de deviner quelles régions supportent réellement l'affinage, combien de temps les tâches resteront en file d'attente, et si le temps d'inactivité sera facturé.

Les chiffres concrets

  • us-west-2 – la seule région où l'affinage de Llama 3.3 70B fonctionne.
  • us-east-1 – uniquement les modèles conçus par Amazon ; pas d'affinage pour Llama ou Anthropic.
  • eu-west-2 (Londres) – permet l'affinage d'un seul modèle, non issu de Llama.
  • Toutes les autres régions – renvoient des erreurs « model not available » pour Llama 3.3 70B.

Si vous avez besoin d'un modèle Llama 3.3 70B personnalisé, lancez la tâche dans us-west-2 et transférez les données entre les régions, ou tentez la voie de l'« Custom Model Import », bien que la tentative de l'auteur ait échoué avec une erreur matérielle générique.

Custom Model Import : un détour risqué

La documentation d'AWS affirme que le « Custom Model Import » peut importer des poids de moins de 200 Go dans n'importe quelle région, y compris eu-central-1. En réalité, les tentatives d'importation de Llama 3.3 70B (qui dépasse largement cette taille) se soldent systématiquement par une « hardware error ». Pour l'instant, l'option la plus sûre reste le point de terminaison d'affinage natif de us-west-2.

Deux astuces pour économiser de l'argent (et votre santé mentale)

  1. Ne faites pas confiance au flag « InProgress » de premier niveau. Une tâche peut rester dans une file d'attente gérée par AWS pendant des heures avec ce statut alors qu'aucun calcul n'est effectué. La facturation ne commence que lorsque le champ imbriqué trainingDetails passe à « Running ». Vérifiez le flag interne pour éviter de payer pour le temps d'attente en file d'attente.
  2. La patience l'emporte sur l'impatience. Une tâche de test est restée en file d'attente pendant 23 heures avant que l'entraînement ne commence, puis s'est terminée sans problème. L'annuler et la relancer l'a renvoyée en fin de file, prolongeant le temps d'attente total. Le temps en file d'attente est gratuit ; les coûts commencent dès que les instances GPU sont activées.

Autres leçons du terrain

  • Les schémas de modèles diffèrent. Llama 3.3 et Llama 3.1 utilisent des objets de configuration distincts. Le copier-coller d'un schéma JSON d'une version à l'autre déclenche des erreurs de validation, même si les limites comme la longueur des tokens sont identiques.
  • Particularités des quotas. La limite sur les « Custom models with a creating status » est souvent bien inférieure au quota global de tâches. Si vous rencontrez une erreur « quota exceeded » alors qu'une tâche précédente affiche toujours « creating », supprimez l'entrée obsolète avant d'en lancer une nouvelle.
  • Le stockage s'accumule. Chaque checkpoint affiné consomme du stockage S3 facturé aux tarifs standards. Laisser les anciennes versions sans modification gonfle votre facture mensuelle sans apporter de valeur ajoutée.

L'essentiel

Si votre projet repose sur un modèle Llama 3.3 70B affiné, prévoyez d'exécuter cette étape dans us-west-2, ou préparez-vous à procéder par tâtonnements avec les imports personnalisés. Vérifiez le statut de la file d'attente au niveau granulaire, évitez d'interrompre les tâches en attente prolongée, et surveillez de près l'utilisation du stockage et des quotas.