Choisir un fournisseur LLM en fonction des scores de benchmark, c'est comme choisir un restaurant en fonction des photos de son menu. Le modèle compte, mais tout ce qui l'entoure compte aussi, et c'est ce qui vous rattrape en production. Voici la liste de contrôle que j'applique à un fournisseur avant de pointer quoi que ce soit de réel vers lui.
Disponibilité et SLA
Un SLA est une promesse assortie de chiffres, alors lisez les chiffres. Les pourcentages de disponibilité semblent trompeusement proches jusqu'à ce qu'on les convertisse :
| SLA | Indisponibilité par an | Indisponibilité par mois |
|---|---|---|
| 99,9 % | 8,76 heures | 43,8 minutes |
| 99,95 % | 4,38 heures | 21,9 minutes |
| 99,99 % | 52,6 minutes | 4,4 minutes |
99,9 % semble excellent et autorise pourtant près d'une heure de panne mensuelle. Si votre produit dépend du point de terminaison, 99,9 % contre 99,99 %, c'est la différence entre « ennuyeux » et « oubliable ». Vérifiez aussi deux choses au-delà du chiffre affiché :
•Ce qui compte comme indisponibilité. Certains SLA ne couvrent que les pannes totales, pas la dégradation du débit ni les taux d'erreur élevés.
•Ce que vous obtenez en cas de manquement. Un crédit vaut peu s'il est plafonné ou s'il exige que vous déposiez une réclamation. Le recours doit être concret.
Un fournisseur qui refuse purement et simplement de publier un SLA vous dit quelque chose, et ce n'est pas bon signe.
Latence et débit
La latence comporte deux chiffres qui vous intéressent et qui mesurent des choses différentes :
•Temps jusqu'au premier token (TTFT). Le délai avant que la réponse commence à être diffusée en streaming. C'est ce que l'utilisateur perçoit comme « réactif ».
•Tokens par seconde (débit). La vitesse à laquelle le reste de la réponse arrive. C'est ce qui détermine si une réponse longue paraît lente.
Les deux varient selon le modèle et selon la charge, alors ne faites pas confiance à un chiffre marketing. Mesurez-le vous-même :
import time
from openai import OpenAI
client = OpenAI(base_url="https://api.token8341.com/v1",
api_key="sk-your-key")
start = time.perf_counter()
stream = client.chat.completions.create(
model="deepseek-chat",
messages=[{"role": "user", "content": "Write 200 words about caching"}],
stream=True,
)
ttft = None
tokens = 0
for chunk in stream:
if ttft is None:
ttft = time.perf_counter() - start
tokens += 1
elapsed = time.perf_counter() - start
print(f"TTFT: {ttft:.2f}s, total: {elapsed:.2f}s, "
f"{tokens / elapsed:.1f} tok/s")Exécutez cela à différents moments de la journée et sous votre propre concurrence attendue. Un fournisseur rapide à 10 h et lent à 19 h a un problème de capacité que vous devez connaître.
Coût
Le prix par token, c'est la partie facile. Le tableau complet des coûts inclut :
•Les prix en entrée vs en sortie, car la sortie coûte généralement plusieurs fois l'entrée.
•La tarification des hits de cache. Pour les charges de travail répétitives, un cache de prompt peut réduire le coût plus que n'importe quelle remise.
•Les limites de débit et la limitation. Un point de terminaison bon marché que vous ne pouvez solliciter que parcimonieusement n'est pas bon marché une fois que vous ajoutez la mise en file d'attente et les tentatives répétées.
•La devise et les frictions de paiement. Les frais de carte transfrontaliers et les coûts de conversion sont bien réels pour les petites équipes.
Demandez le prix de votre charge de travail réelle, pas le prix par million de tokens isolé.
Couverture des modèles et compatibilité
•L'API est-elle compatible avec OpenAI ? Si oui, vous pouvez utiliser les SDK standards et changer plus tard sans réécrire. Si elle est propriétaire, vous vous mariez avec le fournisseur.
•Pouvez-vous accéder à plusieurs familles de modèles avec une seule clé ? Un catalogue avec un ou deux modèles vous enferme aussi étroitement qu'une API propriétaire. Un catalogue avec de nombreux modèles vous donne une solution de repli et une voie vers un routage moins cher.
•Les embeddings, l'appel de fonctions et le streaming sont-ils pris en charge, et pas seulement le chat simple ? Ce sont les fonctionnalités qui déterminent si le point de terminaison convient à une véritable application ou juste à une démo.
Traitement des données et support
•Conservation des données. Le fournisseur conserve-t-il vos prompts et vos complétions pour l'entraînement ? Obtenez-le par écrit.
•Région et résidence. Où les requêtes sont-elles traitées ? Pour certains utilisateurs, c'est une exigence légale, pas une préférence.
•Qualité du support. Essayez d'ouvrir un ticket de support avant de vous engager. La rapidité et l'utilité de la première réponse sont un fort indicateur de ce que sera une panne.
•Transparence du statut. Une page de statut publique et un historique d'incidents vous disent si le fournisseur est honnête sur sa propre fiabilité.
La version courte
Faites passer chaque candidat par ces cinq questions :
1.Quel est le SLA, et quel est le recours en cas de manquement ?
2.Quels sont le TTFT et le débit mesurés sous ma charge ?
3.Combien coûte ma charge de travail réelle, hits de cache inclus ?
4.L'API est-elle compatible avec OpenAI, avec plusieurs modèles derrière une seule clé ?
5.Vont-ils me dire où les données sont traitées et comment le support répond ?
Aucune de ces questions n'exige une expertise pointue. Elles exigent que vous posiez la question avant la panne, pas après. Les fournisseurs qui y répondent sans difficulté tendent à être ceux qui ont réellement exploité du trafic de production, plutôt que simplement listé un modèle.
SiCore TokenWorks répond facilement à la plupart de ces points : un SLA de 99,9 %, un point de terminaison compatible avec OpenAI à https://api.token8341.com/v1, une seule clé couvrant GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao, Spark et Pangu, et une facturation au token avec tarification des hits de cache.