SageMaker contre Bedrock n'est pas une comparaison technique. C'est une question sur le fait de savoir si votre organisation emploie des gens dont le métier est de posséder des modèles. Si vous avez une équipe qui entraîne, évalue, et prend l'astreinte pour un artefact de modèle, SageMaker décrit un travail qu'elle fait déjà. Si vous n'avez pas cette équipe, et la plupart des entreprises qui livrent des fonctionnalités IA ne l'ont pas, Bedrock n'est pas un compromis. C'est une lecture correcte de votre organigramme.

La comparaison se fait généralement sous forme de tableau de fonctionnalités : contrôle, coût par token, choix de modèle, fine-tuning, latence. Ces lignes sont réelles, mais elles sont en aval. Chacune d'elles se résout différemment selon qui est censé porter la chose à 3 heures du matin, et c'est un fait organisationnel, pas technique.

Ce que chacun vous demande réellement

Retirez le marketing et les deux services exigent des choses très différentes.

Bedrock vous demande de posséder des appels. Vous obtenez une API, un ID de modèle, et une facture. Vous êtes responsable des prompts, du retrieval, de l'évaluation des sorties, et du coût. Vous n'êtes pas responsable de la capacité, du matériel, des mises à jour du modèle, ou du déploiement des poids. L'unité de travail est une requête.

SageMaker vous demande de posséder des artefacts. Vous obtenez l'infrastructure pour entraîner, ajuster, héberger et surveiller un modèle dont vous êtes responsable. Vous possédez la traçabilité des données d'entraînement, le harnais d'évaluation qui conditionne une release, le parc d'instances de l'endpoint, la politique d'autoscaling, la détection de dérive, et la décision de déployer une nouvelle version. L'unité de travail est une version de modèle, et les versions de modèle ont des propriétaires, des changelogs et des rollbacks.

Cette seconde liste est un métier. Pas une tâche, un métier permanent, avec astreinte attachée. La question est de savoir si ce métier existe aujourd'hui dans votre entreprise.

L'argument de la topologie d'équipe

Classez les organisations réelles en trois formes.

Équipes produit qui consomment de l'intelligence

L'équipe livre une fonctionnalité. Personne n'a le mot « modèle » dans son titre. La partie IA de la roadmap, c'est « résumer le ticket » et « extraire ces champs ». Pour cette forme, Bedrock est la réponse et ce n'est même pas discutable. Donner à cette équipe un endpoint SageMaker lui donne une surface opérationnelle qu'elle ne maintiendra pas : le moniteur de dérive que personne ne lit, l'endpoint dimensionné lors d'un lancement et jamais revisité, le pipeline d'entraînement qui casse quand la seule personne qui le comprenait change d'équipe. Le mode de défaillance de SageMaker dans une équipe produit n'est pas un mauvais modèle. C'est un modèle sans propriétaire.

Une équipe plateforme au service des équipes produit

Ici, l'équipe plateforme possède une passerelle, des quotas, une infrastructure d'évaluation et l'attribution des coûts, tandis que les équipes produit possèdent les prompts et les fonctionnalités. L'instinct de l'équipe plateforme est que posséder des modèles est l'étape naturelle suivante. Ce n'est généralement pas le cas. Ce qu'elle apporte de précieux, c'est la couture entre les équipes produit et l'inférence : routage, clés, budgets, évaluations, audit. Cette couture vaut la peine d'être construite sur Bedrock, et c'est exactement la forme que j'ai décrite dans LLM Gateways: Why Every Platform Team Builds One Eventually. Ajouter SageMaker revient à ajouter « on fait tourner les modèles » à une équipe déjà goulot d'étranglement pour six autres équipes.

Une équipe ML qui possède déjà des modèles

L'équipe a un pipeline d'entraînement, un feature store, un registre de modèles, et un endpoint existant sur lequel elle est d'astreinte. Pour elle, SageMaker n'est pas un fardeau nouveau, c'est le fardeau qu'elle porte déjà, outillé. Le mouvement intéressant ici n'est généralement pas de choisir, c'est d'admettre qu'elle fera tourner les deux : SageMaker pour les modèles qui sont le produit, Bedrock pour le travail de langage générique autour. Personne ne devrait faire du fine-tuning d'un modèle pour écrire des résumés de commit dans une entreprise qui fait aussi tourner un vrai modèle de ranking.

Les raisons qui imposent vraiment SageMaker

Trois, dans mon expérience, et elles sont toutes précises.

  • Le modèle est le produit, ou son différenciateur. Scoring de fraude, ranking, prévision, tout ce où vos poids encodent quelque chose qu'un concurrent ne peut pas acheter. Vous ne pouvez pas sous-traiter ce que vous vendez.
  • Les poids ou les données ne peuvent pas quitter une frontière que vous contrôlez d'une manière qu'une API d'inférence managée ne peut pas satisfaire, et vous avez lu l'exigence réelle plutôt que de la répéter. C'est celle qu'on invoque bien plus souvent qu'elle ne résiste à l'examen.
  • Vous avez besoin d'un modèle que personne ne sert pour vous, un checkpoint open-weight précis ou une variante adaptée au domaine, et vous avez mesuré un vrai écart par rapport aux options hébergées plutôt que de le supposer.

Remarquez ce qui n'est pas sur la liste : le coût. L'auto-hébergement est moins cher par token à forte utilisation stable, et considérablement plus cher partout ailleurs, parce que vous payez une instance qu'elle serve du trafic ou non, et parce que vous payez désormais des salaires pour la planification de capacité. L'argument du coût est un argument d'utilisation déguisé, et il a besoin d'un chiffre attaché pour compter.

Comment la décision tourne mal en général

L'échec le plus courant est une architecture choisie pour une organisation aspirationnelle. Une équipe choisit SageMaker parce qu'une slide de roadmap dit qu'elle construira des modèles propriétaires l'an prochain. Elle construit le pipeline, livre un fine-tune, l'effectif de l'équipe ML n'arrive jamais, et deux ans plus tard un ingénieur produit ajuste nerveusement un type d'instance sur un endpoint que personne ne sait expliquer. La technologie allait bien. L'organisation qu'elle supposait n'est jamais arrivée.

L'échec inverse existe mais il est plus léger et plus facile à corriger. Une équipe sur Bedrock découvre un vrai besoin d'un modèle qu'elle doit posséder, et migre cette seule charge de travail. Déplacer une charge de travail d'une API managée vers un artefact possédé est un projet. Démanteler une plateforme ML sans propriétaire est une fouille archéologique.

Le test

Posez une seule question en revue de conception : qui est appelé quand la qualité de ce modèle se dégrade, et que fait-il alors ?

Si la réponse nomme une personne, décrit une suite d'évaluation qui déclenche un rollback, et que le manager de cette personne est d'accord, SageMaker vous est accessible. Si la réponse est « on regarderait ça » ou nomme une équipe qui n'existe pas encore, vous venez de découvrir que votre organisation consomme de l'intelligence plutôt qu'elle n'en produit. Construisez pour ça. Ce n'est pas une ambition plus petite, c'est une ambition exacte, et la contrainte qui lie ces équipes n'est presque jamais la possession du modèle. C'est l'évaluation, une discipline dont vous avez besoin dans les deux cas et que je considère comme le vrai prérequis des deux voies.

Ce qu'il faut retenir

Choisissez SageMaker quand une équipe possède des artefacts de modèle comme responsabilité permanente, avec astreinte et suite d'évaluation derrière. Choisissez Bedrock quand votre organisation consomme des sorties de modèle pour construire des fonctionnalités, ce qui est le cas de la plupart des organisations, la plupart du temps. Le mode de défaillance quand on se trompe n'est pas un mauvais benchmark. C'est une infrastructure sans propriétaire, qui se dégrade silencieusement jusqu'à échouer bruyamment. Choisissez selon l'organigramme que vous avez.

À lire ensuite

La version plateforme de cet argument, sur qui possède les clusters et les pipelines plutôt que les modèles, est sur ercan.cloud. Le hub est sur ercanermis.com.