Groq a traité cinq avis en 2 secondes, Ollama en 81 : ce que le test ne dit pas

Imaginons que vous souhaitiez séparer automatiquement les avis clients en positifs et négatifs. Deux options s'offrent à vous : exécuter un modèle sur votre propre ordinateur ou envoyer les textes via une API cloud. La question est très concrète : combien de temps faudra-t-il attendre une réponse, quel sera le coût du traitement et où iront les données des clients ?

Machine Learning Mastery a publié un exemple pédagogique de cette comparaison. Lors de l'essai de l'auteur, le modèle local a traité cinq avis en 80,71 secondes, le modèle cloud en 2,02 secondes. L'écart est de près de quarante fois. Il est toutefois trop tôt pour s'appuyer sur ces chiffres afin de choisir une infrastructure : l'expérience compare des modèles différents et les conditions de l'exécution locale sont insuffisamment documentées.

Comment la comparaison est construite

L'auteur construit deux classificateurs avec les méthodes fit() et predict(), familières aux utilisateurs de scikit-learn. Le premier utilise Scikit-Ollama et Llama 3 en local. Le second fonctionne via Scikit-LLM et envoie les requêtes au modèle gpt-oss-20b par l'API de Groq. Les deux reçoivent les mêmes cinq phrases en anglais et deux catégories possibles : positif et négatif.

Une fonction commune lance le classificateur, mesure le temps total et compare les réponses à des étiquettes définies à l'avance. C'est une base pratique : à la place des phrases de démonstration, on peut insérer les avis de sa boutique, des demandes de support ou de courts messages d'utilisateurs. L'interface permet de conserver la même logique de mesure en changeant d'exécutant.

Dans les résultats présentés, le modèle local a correctement classé quatre phrases sur cinq, le modèle cloud les cinq. Cela donne 80 % et 100 % de précision. Le temps inclut les appels à fit() et à predict() : les secondes indiquées décrivent donc l'ensemble de la passe mesurée, et non la latence d'une requête isolée.

Pourquoi il n'y a pas encore de vainqueur

Le principal problème est que le modèle et le lieu d'exécution changent en même temps. L'expérience ne permet donc pas de distinguer l'effet de l'infrastructure des différences entre Llama 3 et gpt-oss-20b. Une fonction de mesure identique rend la procédure plus commode, mais ne garantit pas à elle seule la comparabilité des systèmes.

Par ailleurs, l'article ne fournit ni les caractéristiques du matériel local, ni une série d'exécutions répétées, ni de résultats distincts après préchauffage du modèle. Sans cela, impossible de savoir dans quelle mesure les 80,71 secondes seraient représentatives sur un autre ordinateur. Un chiffre total unique ne montre pas non plus la dispersion des latences, qui peut influencer l'expérience utilisateur.

Le cas de la précision est encore plus parlant. Le seul désaccord porte sur un avis que l'on pourrait traduire par « Correct, rien de spécial, mais ça marche ». L'auteur l'a étiqueté positif, le modèle local l'a jugé négatif. La consigne ne prévoit pas de classe neutre. L'écart de vingt points de pourcentage tient donc à une seule phrase ambiguë et au schéma d'étiquetage retenu.

Le coût n'est pas davantage mesuré. La fonction se contente d'afficher la chaîne « $0 ». Pour l'exécution locale, cela ignore le matériel et l'électricité ; pour le cloud, cela ne précise ni les conditions de l'accès gratuit ni les limites de charge. L'affirmation d'une confidentialité absolue appelle aussi une réserve : l'exécution dans Google Colab, que les instructions autorisent, se fait déjà sur une infrastructure externe.

Ce qu'il faut retenir pour votre projet

La valeur pratique de l'article réside dans le squelette de l'expérience. Commencez par un échantillon représentatif de messages réels et des règles d'étiquetage claires. Si des avis neutres existent dans votre produit, décidez à l'avance s'ils nécessitent une catégorie à part. Sinon, une partie des « erreurs du modèle » ne sera qu'un désaccord sur le sens des étiquettes.

Ensuite, figez les versions des modèles, les paramètres d'exécution et le matériel. Effectuez des mesures répétées, en évaluant séparément la première requête et le fonctionnement après préchauffage. Pour un service, il est utile de connaître non seulement le temps moyen, mais aussi la latence des réponses lentes, le comportement sous charge parallèle et le taux d'échec.

Enfin, calculez le coût sur le volume de requêtes attendu et vérifiez les exigences relatives au transfert de données. Le test présenté montre comment assembler rapidement un premier prototype de comparaison. La décision entre exécution locale et cloud doit se fonder sur les résultats obtenus sur votre propre tâche : les cinq avis publiés ne fournissent pas cette base.