AWS a montré comment réduire le coût du text-to-SQL pour les entreprises avec Amazon Nova Micro et Bedrock

AWS a montré comment obtenir du text-to-SQL pour les bases de données internes sans coûts élevés d'hébergement permanent de modèles. L'entreprise a ajusté Amazon Nova Micro pour les dialectes SQL non standards et l'a déployée via Amazon Bedrock avec une tarification au paiement par requête.

Pourquoi c'est important

Pour les scénarios d'entreprise, un modèle standard ne suffit souvent pas : il écrit correctement le SQL standard, mais commence à faire des erreurs quand une entreprise a ses propres conventions, des fonctions rares, des schémas de tables spéciaux et des règles spécifiques au domaine. C'est pourquoi les requêtes texte de l'utilisateur doivent être adaptées au dialecte spécifique et à la structure de la base de données, ce qui signifie ajuster le modèle sur vos propres exemples. C'est particulièrement visible dans les systèmes BI et les chats analytiques internes, où une erreur de syntaxe casse immédiatement tout le flux de travail.

Le problème est que l'ajustement fin entraîne généralement des coûts d'infrastructure supplémentaires. Si vous maintenez un modèle personnalisé sur des serveurs dédiés, l'entreprise paie même quand il n'y a pas de requêtes. AWS propose une approche différente dans son analyse : ajuster Amazon Nova Micro via LoRA et l'exécuter dans Amazon Bedrock en mode d'inférence à la demande, où la facturation se fait par token plutôt que par capacité pré-réservée.

Deux approches AWS

AWS décrit deux scénarios pour la même tâche. Le premier est l'ajustement fin géré au sein d'Amazon Bedrock. Il convient aux équipes qui valorisent la simplicité, un démarrage rapide et une complexité minimale de l'infrastructure ML.

Les données sont chargées dans S3, un travail d'ajustement fin est lancé via la console ou l'API, et AWS gère l'entraînement et le déploiement ultérieur de la version personnalisée de Nova Micro. Cette approche cible les équipes d'applications plutôt qu'une plateforme ML séparée. Le deuxième chemin est l'entraînement via Amazon SageMaker AI.

C'est plus complexe mais offre plus de contrôle sur la recette d'entraînement : vous pouvez ajuster la taille du lot, le dropout, les paramètres de l'optimiseur, la fenêtre de contexte, les paramètres LoRA et la stratégie de préchauffage du taux d'apprentissage. Dans l'exemple d'AWS, ils ont utilisé l'ensemble de données sql-create-context basé sur WikiSQL et Spider, convertissant les paires question-SQL au format bedrock-conversation-2024 pour l'entraînement et la validation. Cela s'accompagne d'une plus grande complexité de configuration et d'un travail d'infrastructure plus explicite.

• Bedrock — moins de charge opérationnelle et chemin plus rapide vers un prototype fonctionnel
• SageMaker AI — plus de contrôle sur les hyperparamètres et l'intégration MLOps
• Les deux schémas utilisent le même pipeline de préparation de données puis se déploient dans Bedrock
• L'inférence finale s'exécute sur un modèle sans serveur avec facturation par token, sans hébergement constant

Coût et latence

AWS fournit des chiffres spécifiques. Pour l'ajustement fin géré de Bedrock, le coût d'entraînement est calculé comme $0,001 par 1.000 tokens par époque : dans l'exemple avec 2.

000 échantillons, cinq époques et environ 800 tokens par enregistrement, cela a coûté environ $8. Pour l'option SageMaker, une instance ml.g5.

48xlarge à $16,288 par heure a été utilisée ; l'entraînement sur un ensemble de données de 20.000 lignes a pris environ quatre heures et a coûté environ $65,15. La thèse clé de l'article n'est pas le coût unique d'entraînement, mais le coût opérationnel.

AWS a estimé une charge de production typique de 22.000 requêtes par mois, soit 100 utilisateurs effectuant 10 requêtes par jour pendant 22 jours ouvrables. Avec une taille moyenne de requête de 800 tokens en entrée et 60 tokens en sortie, l'inférence mensuelle pour un tel modèle text-to-SQL personnalisé s'est élevée à $0,80.

C'est possible parce qu'un Nova Micro personnalisé dans Bedrock est facturé de la même manière que le modèle de base, sans prime supplémentaire pour le déploiement sans serveur. En termes de vitesse, il y a un compromis, mais il est modéré. Au démarrage à froid, le temps moyen jusqu'au premier token a augmenté à 639 ms, ce qui est 34% supérieur au modèle de base.

En fonctionnement normal, le TTFT moyen était de 380 ms sur 50 appels — seulement 7% pire que la ligne de base. La latence complète de génération était d'environ 477 ms, avec une vitesse de sortie maintenue à 183 tokens par seconde. AWS a validé la qualité non seulement par la latence, mais via LLM-as-a-Judge, en comparant le SQL généré aux réponses de référence.

Ce que cela signifie

Pour les équipes qui souhaitent intégrer du text-to-SQL dans les produits d'analyse, les outils BI internes ou les interfaces de chat vers les bases de données, l'étude de cas d'AWS semble pratique : vous pouvez obtenir un générateur SQL personnalisé sans coûts constants d'infrastructure dédiée. Si la vitesse de lancement compte davantage, Bedrock est le choix logique ; si vous avez besoin d'un contrôle total sur l'entraînement, la combinaison SageMaker AI semble plus forte.