AWS montre comment réduire le coût du text-to-SQL avec Amazon Nova Micro et Bedrock

AWS a montré comment obtenir du text-to-SQL pour des bases de données internes sans payer l'hébergement permanent et coûteux d'un modèle. L'entreprise a affiné Amazon Nova Micro pour des dialectes SQL non standard et l'a déployé via Amazon Bedrock, en ne payant que les requêtes réellement effectuées.

Pourquoi c'est important

Dans les usages en entreprise, un modèle généraliste ne suffit souvent pas : il écrit plutôt bien du SQL standard, mais se met à commettre des erreurs dès que l'entreprise a ses propres conventions, des fonctions rares, des schémas de tables particuliers et des règles métier. La requête textuelle de l'utilisateur doit donc être adaptée à un dialecte et à une structure de base précis, ce qui implique de réentraîner le modèle sur ses propres exemples. C'est particulièrement visible dans les systèmes de BI et les chats analytiques internes, où une erreur de syntaxe casse aussitôt tout le scénario.

Le problème, c'est que l'affinage entraîne généralement aussi des coûts d'infrastructure permanents. Si le modèle personnalisé tourne sur des serveurs dédiés, l'entreprise paie même quand il n'y a aucune requête. Dans son analyse, AWS propose une autre option : affiner Amazon Nova Micro avec LoRA et l'exécuter dans Amazon Bedrock en mode d'inférence on-demand, où la facturation se fait au token et non à la capacité réservée en permanence.

Les deux approches d'AWS

AWS décrit deux scénarios pour la même tâche.

Le premier est l'affinage géré au sein d'Amazon Bedrock. Il convient aux équipes qui privilégient la simplicité, un démarrage rapide et un minimum de tracas avec l'infrastructure de ML. Les données sont chargées dans S3, la tâche de fine-tuning est lancée depuis la console ou l'API, puis AWS gère l'entraînement et le déploiement de la version personnalisée de Nova Micro. Cette option vise plutôt une équipe applicative qu'une plateforme ML dédiée.

La seconde voie passe par l'entraînement avec Amazon SageMaker AI. Elle est plus complexe, mais offre plus de contrôle sur la recette d'entraînement : on peut modifier la taille de lot, le dropout, les paramètres de l'optimiseur, la fenêtre de contexte, les réglages LoRA et la stratégie de warmup du learning rate. Dans l'exemple, AWS a utilisé le jeu de données sql-create-context, bâti à partir de WikiSQL et Spider, et converti les paires question-SQL au format bedrock-conversation-2024 pour l'entraînement et la validation. Le prix à payer est une configuration plus complexe et un travail plus explicite sur l'infrastructure.

Voici comment les deux options se distinguent en pratique :

• Bedrock : moins de charge opérationnelle et un chemin plus rapide vers un prototype fonctionnel
• SageMaker AI : plus de contrôle sur les hyperparamètres et l'intégration dans le MLOps
• Les deux schémas utilisent le même pipeline de préparation des données, puis sont déployés dans Bedrock
• L'inférence finale s'exécute sur un modèle serverless facturé au token, sans hébergement permanent

Prix et latence

AWS donne des chiffres précis. Pour l'affinage géré de Bedrock, le coût d'entraînement est calculé à 0,001 $ pour 1 000 tokens par époque : dans l'exemple avec 2 000 échantillons, cinq époques et environ 800 tokens par enregistrement, cela représente environ 8 $. La variante SageMaker a utilisé une instance ml.g5.48xlarge à 16,288 $ de l'heure ; l'entraînement sur un jeu de 20 000 lignes a pris environ quatre heures et coûté approximativement 65,15 $.

La thèse centrale de l'article n'est pas le prix ponctuel de l'entraînement, mais le coût d'exploitation. AWS a estimé une charge de production type de 22 000 requêtes par mois, soit 100 utilisateurs à 10 requêtes par jour pendant 22 jours ouvrés. Avec une taille moyenne de 800 tokens en entrée et 60 en sortie, l'inférence mensuelle de ce modèle text-to-SQL personnalisé s'est élevée à 0,80 $. C'est possible parce que Nova Micro personnalisé dans Bedrock est facturé comme le modèle de base, sans surcoût pour le déploiement serverless.

Sur la vitesse, il y a un compromis, mais modéré. Lors d'un démarrage à froid, le délai moyen avant le premier token est monté à 639 ms, soit 34 % de plus que le modèle de base. En fonctionnement normal, le TTFT moyen était de 380 ms sur 50 appels, seulement 7 % de moins bien que la base. La latence totale de génération était d'environ 477 ms, et le débit de sortie s'est maintenu à 183 tokens par seconde. AWS a évalué la qualité non seulement par la latence, mais aussi avec LLM-as-a-Judge, en comparant le SQL généré à des réponses de référence.

Ce que cela signifie

Pour les équipes qui veulent intégrer le text-to-SQL dans des produits analytiques, des outils de BI internes ou des interfaces de chat avec une base de données, le cas d'AWS paraît pragmatique : on peut obtenir un générateur de SQL personnalisé sans coûts permanents d'infrastructure dédiée. Si la rapidité de mise en route compte davantage, il est logique de se tourner vers Bedrock ; si l'on a besoin d'un contrôle total sur l'entraînement, l'association avec SageMaker AI semble plus solide.