Amazon Bedrock : la couche qui rend le modèle remplaçable
ArchitecturePlateformeRéversibilitéCoût2023-04-1310 min
Une API unique devant plusieurs modèles. Ce n'est pas une commodité de facturation : c'est ce qui décide si votre système survivra au prochain changement de génération.
Ce que Bedrock met sur la table
AWS propose d'accéder à plusieurs modèles de fondation derrière une seule interface. Présenté comme un catalogue, c'est en réalité une proposition d'architecture : ne pas coder contre un fournisseur.
L'intérêt n'est pas conceptuel, il est comptable. Un modèle est remplacé en moyenne deux à trois fois par an, parce que le fournisseur déprécie une version, parce qu'un modèle moins cher fait aussi bien, ou parce qu'une nouvelle génération sort et change le rapport qualité-prix. Ce qui coûte cher n'est pas le remplacement : c'est la réécriture qu'il impose quand rien ne l'a anticipé.
J'ai repris des systèmes où le nom du modèle apparaissait dans quarante fichiers, où le format de réponse était supposé partout, et où changer de fournisseur était devenu un projet de six semaines. Le même changement, sur un système correctement isolé, prend une heure.
Ce que la couche doit isoler, précisément
Elle doit masquer trois choses : le format d'appel, le format de réponse, et le comportement en erreur. C'est moins évident qu'il n'y paraît, parce que les deux premiers sont documentés et le troisième ne l'est jamais.
Un fournisseur renvoie une erreur structurée, un autre une réponse vide, un troisième un texte d'excuse en langue naturelle qui ressemble à une réponse valide. Une couche qui ne normalise pas ces cas laisse passer les différences là où elles font le plus de dégâts : dans le traitement automatique de la sortie, où une réponse vide traitée comme un succès produit une donnée fausse.
J'y ajoute systématiquement un quatrième élément : la comptabilisation. Le nombre de jetons consommés et le coût par appel doivent être mesurés au même endroit, quel que soit le fournisseur. Sans cela, personne ne sait ce que coûte réellement une fonctionnalité, et l'arbitrage décrit dans le coût réel d'un système IA en production devient impossible à instruire.
Ce que la réversibilité rend possible
- Comparer deux modèles sur les mêmes cas, avec le même prompt, et décider sur des chiffres plutôt que sur une impression. Voir l'évaluation continue.
- Router par tâche : un petit modèle pour la classification, un grand pour l'analyse. À facteur cent entre les tarifs, ce routage devient la principale source d'économie du système.
- Basculer par paliers : dix pour cent du trafic sur le nouveau modèle, comparaison du taux de correction humaine, puis élargissement. Voir migrer un agent sans régression.
- Absorber une dépréciation sans projet. Le fournisseur retire une version : on change une ligne de configuration au lieu d'ouvrir un chantier.
Le piège de l'abstraction trop ambitieuse
Une couche qui prétend masquer toutes les différences entre modèles finit par empêcher d'utiliser ce que chacun a de mieux. C'est l'erreur symétrique, et je l'ai vue coûter cher.
Certaines capacités ne sont pas portables : un mode de raisonnement étendu, un format de sortie structuré natif, un traitement d'image particulier, une gestion fine du cache de contexte. Vouloir les uniformiser produit un plus petit dénominateur commun médiocre, où l'on paie le prix d'un grand modèle pour n'en utiliser qu'une fraction.
La bonne mesure : la couche normalise l'appel, la réponse, l'erreur et le coût. Elle laisse passer les capacités spécifiques par une porte explicite, utilisée en connaissance de cause, et couverte par le jeu de tests. Ce qui compte est que le recours à une capacité non portable soit visible dans le code, pas dissimulé au fond d'une fonction utilitaire.
La décision à prendre dès la première semaine
Écrire la couche d'abstraction avant d'avoir choisi le modèle. Elle coûte une demi-journée au démarrage et évite une réécriture au douzième mois. C'est l'investissement au meilleur rendement que je connaisse sur ce type de système.
Ce que ça change pour l'hébergement interne
Une couche d'abstraction rend le débat « API ou modèle hébergé » réversible, donc beaucoup moins risqué. On peut commencer par une API pour établir la valeur d'usage, mesurer le volume réel pendant trois mois, puis rejouer le calcul avec des chiffres constatés au lieu d'hypothèses.
C'est la séquence que je recommande, et elle évite deux erreurs symétriques : investir dans du matériel pour un usage qui ne décollera pas, et rester sur une facturation à l'usage qui devient déraisonnable quand il décolle. Le calcul complet est détaillé dans modèles ouverts et souveraineté.
Dans les deux cas, le déclencheur du basculement doit être écrit à l'avance : au-delà de tel volume mensuel, on rejoue l'arbitrage. Sans ce seuil posé au départ, la question ne se repose jamais, et l'organisation paie pendant deux ans un tarif qui n'était justifié que la première année.
Questions fréquentes
- Faut-il passer par une plateforme comme Bedrock ou écrire sa propre couche ?
Les deux fonctionnent. Une plateforme apporte la facturation unifiée et la conformité contractuelle ; une couche maison, écrite en une demi-journée, apporte l'indépendance vis-à-vis de la plateforme elle-même. Le point important est qu'une couche existe.
- L'abstraction fait-elle perdre en performance ?
Marginalement en latence, jamais en qualité de réponse, elle ne touche pas au modèle. Le vrai risque est fonctionnel : une couche trop ambitieuse empêche d'utiliser les capacités spécifiques d'un fournisseur.
- À quelle fréquence change-t-on de modèle en pratique ?
Deux à trois fois par an sur les systèmes que j'exploite. C'est ce rythme qui rend l'abstraction et le jeu de tests indispensables dès le départ, et non au moment du premier changement.
- Peut-on mélanger plusieurs fournisseurs en production ?
Oui, et c'est souvent le réglage le plus économique : un petit modèle pour les tâches simples, un grand pour les cas difficiles. Le routage se décide sur des mesures, pas sur une préférence, et il exige que la couche mesure le coût par appel.