Les décisions à prendre avant toute mise en service : comment le modèle est hébergé, quel modèle et quel GPU conviennent à la charge, si le calcul de mémoire tombe juste, et quel framework de service l’exécute.
Un fournisseur héberge le modèle et facture au jeton. Démarrage le plus rapide, aucune exploitation de GPU, élasticité par défaut. Vous acceptez ses modèles, ses limites, ses conditions sur les données et sa courbe de prix ; à volume soutenu, c’est en général la voie la plus coûteuse.
Vous louez des GPU et exploitez une pile de service (vLLM, SGLang, TensorRT-LLM). Contrôle total sur les modèles, les versions et les optimisations comme le prefix caching ou la désagrégation, en échange d’une vraie charge DevOps : la capacité, les mises à niveau et la réponse aux incidents vous reviennent.
Un éditeur exploite sa plateforme de service à l’intérieur de votre compte cloud : son plan de contrôle, votre plan de données. Les données restent dans votre VPC pour la souveraineté et la conformité, vos crédits et vos remises d’engagement sont utilisés, les frais de sortie diminuent, et l’essentiel de l’exploitation est externalisé.
Votre matériel, votre centre de données. Le meilleur contrôle des données et des dépenses d’investissement prévisibles ; convient aux charges régulières, à fort volume ou régulées. Le prix à payer : l’investissement GPU initial, les délais d’approvisionnement, le vieillissement du matériel, ainsi que l’exploitation et les compétences nécessaires.
Décidez sur quatre axes : confidentialité des données et conformité, coût à votre échelle réelle, besoin de personnalisation (poids issus d’un fine-tuning, optimisations au niveau du service) et capacité d’exploitation de votre équipe. Comparez les options avec un TTFT, un throughput et un coût par tâche réussie mesurés, pas avec des prix catalogue ; la page fournisseurs propose une checklist d’évaluation.
Estimez avant de louer quoi que ce soit. Trois consommateurs se partagent la mémoire GPU :
Validez ensuite par un test de charge aux longueurs réelles de prompt et de sortie, car la fragmentation et le comportement de l’ordonnanceur placent la limite pratique en dessous de la limite arithmétique.
Le framework prend en charge le batching, la gestion du cache KV, le streaming et l’exécution multi-GPU, et la plupart exposent une API compatible OpenAI pour que les applications restent portables.
vLLM et SGLang sont les moteurs open source de référence (batching continu, gestion mémoire de type PagedAttention, prise en charge des sorties structurées). TensorRT-LLM tire la performance maximale du matériel NVIDIA au prix d’une intégration plus coûteuse ; LMDeploy met l’accent sur un service quantifié à forte concurrence.
llama.cpp (et Ollama par-dessus) couvre les usages CPU et mono-machine avec la quantification GGUF ; MLC-LLM compile les modèles pour téléphones et navigateurs. Ces outils privilégient l’empreinte et la portabilité sur le throughput agrégé.