AWS montre comment exécuter llama.cpp sur SageMaker et obtenir des probabilités par option

Le blog AWS Machine Learning a publié un guide pas à pas pour déployer des modèles de décision sur Amazon SageMaker AI avec le moteur llama.cpp. L'architecture repose sur deux couches. On commence par monter un endpoint basé sur l'AWS Deep Learning Container officiel pour llama.cpp, qui expose des chat completions compatibles OpenAI. On étend ensuite le runtime avec la bibliothèque SemIf : au lieu de texte généré, le modèle renvoie des probabilités pour des options déclarées à l'avance. Le tout fonctionne aussi bien sur CPU que sur GPU.

Le contenu est orienté pratique : il s'agit d'un tutoriel, pas de l'annonce d'un nouveau produit. Il montre toutefois comment AWS propose de traiter l'un des cas d'usage les plus courants en entreprise, la classification et la prise de décision sur de petits modèles, sans lourde infrastructure GPU.

Les briques de la pile

llama.cpp est un moteur d'inférence open source en C/C++. Il sait exécuter des modèles quantifiés au format GGUF et n'exige pas de GPU. C'est pourquoi il est populaire partout où l'on veut des endpoints bon marché et prévisibles. AWS l'a intégré à son propre Deep Learning Container, afin d'éviter de construire l'image à la main et de se débattre avec les dépendances.

Les éléments clés de la solution, d'après la description d'AWS :

• Plateforme : Amazon SageMaker AI, endpoints d'inférence managés.
• Runtime : AWS Deep Learning Container pour llama.cpp.
• Interface : chat completions compatibles OpenAI, ce qui permet de connecter les clients et SDK existants sans les réécrire.
• Extension : SemIf, qui renvoie des probabilités pour les options déclarées.
• Matériel : CPU ou GPU, au choix du développeur.

La compatibilité avec le format OpenAI résout un problème concret de migration. Si l'application interroge déjà une API de chat, passer à son propre endpoint revient à changer l'adresse et la clé.

Pourquoi des probabilités plutôt que du texte

Un modèle de décision répond à une question dont les issues sont en nombre fini : approuver ou refuser une demande, envoyer un ticket à la facturation ou au support technique, signaler un message comme abusif ou le laisser passer. Une LLM classique produit une chaîne de caractères qu'il faut ensuite analyser. Le format de réponse varie, le modèle ajoute des explications et invente parfois une option absente de la liste.

D'après la description, SemIf règle ce problème au niveau du runtime. Le développeur déclare les options admises et reçoit en retour une distribution de probabilités sur ces options. On peut retenir la valeur maximale, mais l'intérêt est ailleurs : cela permet de fixer un seuil de confiance. Si la meilleure option atteint 0,92, l'action s'exécute automatiquement. À 0,48, le dossier part vers un humain. La modèle de langage devient ainsi un composant à calibration mesurable, qu'on peut intégrer dans un processus métier ordinaire.

Pour les ingénieurs, c'est aussi une question de tests. On peut journaliser les probabilités, les comparer d'une version du modèle à l'autre et en tirer des métriques, ce qui est impossible avec du texte libre.

Ce que l'annonce ne dit pas

La courte présentation ne contient ni benchmarks, ni tarifs, ni liste des modèles pris en charge, ni détails d'implémentation de SemIf. On ignore comment les probabilités sont calculées exactement : à partir des logits des premiers tokens des options, ou autrement. Or, cela détermine le degré de confiance qu'on peut leur accorder sur des options longues ou composées. Il n'y a pas non plus de comparaison CPU/GPU en termes de latence et de coût par requête. Ces données, il faudra les produire soi-même.

Par où commencer

Voici un ordre d'action pratique pour une équipe qui veut tester l'approche :

• Choisissez une tâche étroite avec 3–10 issues, par exemple le routage de demandes.
• Prenez un petit modèle quantifié au format GGUF et déployez-le sur une instance CPU. C'est le démarrage le moins cher.
• Constituez un échantillon annoté et mesurez dans quelle mesure les probabilités de SemIf correspondent à la précision réelle. Ajustez les seuils de décision automatique et d'escalade.
• Ce n'est qu'ensuite qu'il faut comparer avec une instance GPU, en latence et en prix pour mille requêtes.

Si la calibration s'avère mauvaise, mieux vaut le savoir avant la production. Si elle est bonne, l'équipe disposera d'un endpoint maîtrisé, avec une API familière et une économie claire.