Comparatif LLM en polonais : 4 modèles ouverts face à 12 tests
J'ai soumis quatre grands modèles ouverts à un banc d'essai de 12 requêtes courtes en polonais. Voici les résultats détaillés de mes tests de vitesse, de coût et de complétion.

👁 119 lectures
Les versions de modèles à poids ouverts parues en octobre 2026 m’ont fourni le terrain idéal pour un comparatif LLM rigoureux : quatre architectures, les mêmes requêtes courtes et une langue exclue des habituels classements anglophones. Mon banc d’essai en polonais a eu lieu le 19 octobre via l’API. DeepSeek V4.1 Flash 1017 et Nemotron 3.5 Super VL ont obtenu 12/12, Muse Spark Open 11/12 et Step 5 Preview 9/12.
En résumé
- Cet essai a été réalisé intégralement en polonais, et non en anglais ni sur un panier multilingue.
- Chaque modèle a reçu les 12 tâches une seule fois, avec une température de 0.
- L’allocation de 6 000 jetons englobait à la fois le raisonnement interne et la réponse finale.
- Chaque échec correspond à une réponse vide renvoyée pile à cette limite de jetons.
- Une règle d’évaluation orthographique corrigée a validé l’expression « Weź parasol » en polonais.
Méthodologie de mon comparatif LLM sur tâches vérifiables
J’ai envoyé 48 requêtes au total, sans répétition pour une même tâche. Les mêmes prompts et réglages de génération ont été appliqués aux quatre candidats. Un script a ensuite évalué le texte produit en regard de critères stricts. Les journaux enregistrés contiennent la durée de traitement, le nombre de jetons générés, le coût, le texte de la réponse et la validation finale. Pour savoir ce que représente chaque modèle, sa taille exacte et sa licence, consultez mon dossier sur les modèles IA open source d’octobre 2026.
Les consignes étaient volontairement concises. Certaines appelaient une réponse arithmétique unique, tandis que les exercices de grammaire et de formatage acceptaient plusieurs formulations valides. Qualifier chaque tâche d’exercice à réponse unique serait inexact. Le but était de vérifier si une IA open source pouvait renvoyer un résultat recevable sous un budget de calcul identique.
- Calculer 37 fois 48 moins 125.
- Donner le génitif pluriel polonais du mot « przyjaciel » (ami).
- Compter les occurrences de la lettre « ż » dans une phrase en polonais.
- Extraire le numéro fiscal, le montant brut et la date d’une facture sous format JSON.
- Calculer la clé de contrôle d’un numéro d’identité polonais à partir de chiffres et de coefficients fournis.
- Identifier la personne la plus jeune dans une énigme d’ordre d’âge.
- Donner le jour de la semaine correspondant au 11 novembre 1918.
- Écrire exactement trois mots polonais en minuscules sur le thème de l’automne.
- Indiquer le nombre de régions administratives de la Pologne.
- Convertir 2,5 heures en secondes.
- Corriger une phrase polonaise truffée de fautes d’orthographe et de ponctuation.
- Poursuivre la suite logique : 2, 6, 12, 20, 30.
L’API pouvait acheminer les appels successifs vers différentes machines serveurs. Une température fixée à 0 n’efface pas cette variabilité matérielle et ne remplace pas des essais répétés. Les durées mesurées reflètent fidèlement les appels exécutés ce jour-là, et non une mesure en laboratoire sur du matériel identique isolé.
Résultats et coûts réels pour exécuter la série
| Modèle | Validées | Temps médian | Coût relevé |
|---|---|---|---|
| DeepSeek V4.1 Flash 1017 | 12/12 | 0,95 s | $0.0006 |
| Nemotron 3.5 Super VL | 12/12 | 1,20 s | $0.0022 |
| Muse Spark Open | 11/12 | 8,05 s | $0.0542 |
| Step 5 Preview | 9/12 | 2,15 s | $0.0537 |
Les coûts de ce tableau sont les sommes arrondies de mes relevés d’utilisation réels. L’exécution complète m’a coûté $0.11081294, soit environ $0.11. Ces montants décrivent ce test historique via l’API. Ils ne constituent pas des devis actuels ni des estimations pour d’autres volumes de travail.
La consommation de jetons de génération a montré d’immenses écarts : DeepSeek a consommé 1 283 jetons, Nemotron 3 868, Muse 12 241 et Step 19 672. Ces totaux englobent les réflexions internes et pas seulement le texte affiché dans la réponse finale. Un LLM open source peut donc générer moins de texte utile tout en absorbant une part bien plus lourde de l’enveloppe allouée.
Les médianes masquent aussi des délais d’attente importants. Les requêtes les plus lentes ont atteint 2,4 secondes pour DeepSeek, 11,7 secondes pour Nemotron, 126,3 secondes pour Muse et 230,1 secondes pour Step. Dans un logiciel interactif, le traitement avorté le plus lent dégrade l’expérience, même si la réponse type arrive vite.
Les échecs étaient tous des réponses vides
Muse Spark Open a calé sur la conversion des heures en secondes (2,5 h = 9 000 s). Step 5 a échoué sur la consigne des trois mots d’automne, la question sur les régions administratives et la correction orthographique. Chacun de ces enregistrements présente une réponse vide et exactement 6 000 jetons de génération au compteur. Le test indique que le plafond a été épuisé durant la phase de réflexion avant l’émission de la moindre réponse finale.
La distinction est fondamentale. L’échec constaté n’était ni un calcul erroné ni une phrase fautive. C’était l’absence pure et simple de résultat exploitable. Le journal ne conserve pas le texte de raisonnement interne ni de champ de motif d’arrêt (« finish-reason »), ce qui empêche de reconstituer la boucle interne qui a provoqué ce blocage au plafond.
Augmenter ce plafond ou ajuster les réglages de raisonnement modifierait sans doute ces résultats. Je n’ai testé aucune de ces options ici. Il serait hâtif d’y voir une solution acquise ou de supposer que le modèle aurait répondu juste avec un temps illimité.
Pourquoi j’ai modifié la notation de l’exercice d’orthographe
La phrase à corriger était : « Wziąść parasol bo napewno bedzie padać ». Au départ, mon script exigeait l’infinitif corrigé « wziąć », accompagné des graphies correctes « na pewno » et « będzie ». Or, Muse, DeepSeek et Nemotron ont tous écrit : « Weź parasol, bo na pewno będzie padać ».
« Weź parasol » représente un impératif grammatical tout à fait naturel qui signifie « Prends un parapluie ». C’est une révision très pertinente de la tournure d’origine. J’ai donc validé cette forme en modifiant la règle de notation, ce qui a accordé un point de plus à chacun de ces trois modèles. La réponse de Step étant vide, son total n’a pas bougé.
Cette correction dépasse la simple attribution d’un point. Un banc d’essai linguistique pénalise vite des tournures parfaitement justes si son vérificateur n’attend qu’une unique formule figée. Rendre compte de cette retouche méthodologique apporte bien plus d’informations que de remplacer silencieusement les notes initiales.
D’autres tests ont fait preuve d’une tolérance calculée. Mon script d’extraction JSON a récupéré l’objet même entouré de balises de code Markdown. Le vérificateur de somme de contrôle a validé le chiffre final au milieu du texte sans exiger que la réponse se résume à un caractère isolé. Les notes reflètent l’exactitude de la réponse demandée plutôt qu’une obéissance aveugle au gabarit d’affichage.
Ce que vous pouvez en retenir hors de l’anglais
Le constat pratique le plus frappant est que DeepSeek V4.1 Flash 1017 et Nemotron 3.5 Super VL ont accompli toute cette série sans la moindre réponse vide, tandis que Muse Spark Open n’a manqué qu’un seul point pour cause de dépassement de jetons. Sur le plan méthodologique, la gestion des plafonds de réflexion et une correction sensible aux spécificités de la langue doivent impérativement s’intégrer à toute évaluation. Une fiche technique élogieuse publiée par un fabricant ne garantit rien pour votre cas d’usage précis.
Si vous évaluez une autre langue, bâtissez vos épreuves autour de sa grammaire réelle, de ses prénoms, de ses dates, de ses formats numériques et de ses tournures idiomatiques. Traduire littéralement ce jeu de données supprimerait la difficulté ciblée : le comptage de lettres s’appuyait sur un caractère diacrité polonais, tout comme l’exercice de déclinaison reposait sur la morphologie locale.
- Vérifiez toujours si une réponse a été émise, si elle est juste et si son format est directement utilisable.
- Inspectez manuellement les réponses rejetées avant de figer vos scores.
- Conservez la trace des limites de réflexion et des paramètres d’échantillonnage associés aux résultats.
- Répétez les tâches représentatives afin d’estimer la dispersion des mesures.
- Séparez nettement les tests de texte pur des évaluations de documents scannés, de captures d’écran, d’audio ou de vidéo.
Je n’ai mesuré ici aucune performance en français, en anglais, en allemand, en italien, en espagnol ou en néerlandais. L’intérêt pour d’autres langues réside dans la méthode d’évaluation hors de la sphère anglophone, et non dans une quelconque extrapolation universelle de ces notes. La rédaction longue, la traduction, la programmation, l’appel d’outils et le rappel en contexte géant n’étaient pas au menu du jour. Si vous préférez des architectures plus compactes capables de tourner sur une seule carte graphique grand public, lisez mon banc d’essai précédent consacré à l’écriture non anglophone sur modèles locaux avec une RTX 4090. Vous retrouverez l’ensemble de mes bancs d’essai indépendants dans le Labo Promptif.
FAQ
Un modèle a-t-il donné une réponse factuellement fausse ?
Après l’ajustement sur la consigne d’orthographe, chaque réponse non vide a validé les critères du script de contrôle. Comme certains vérificateurs toléraient du formatage autour du résultat, cela ne garantit pas un respect maniaque de chaque instruction de mise en page.
Les modèles ont-ils tourné en local sur votre machine ?
Non. Toutes les requêtes ont été transmises via l’API. Mes relevés ne mesurent pas l’inférence en local, le comportement sur un GPU particulier ou la vitesse brute des fichiers de poids téléchargés sur un ordinateur personnel.
Un score de 12/12 garantit-il la fiabilité d’un modèle en production ?
Non. Ce résultat constate seulement la réussite sur 12 tâches très brèves essayées une seule fois. Une mise en production exige des mesures répétées et des jeux d’épreuves fidèles aux cas réels de votre application.
Sources
- Script de test de l’auteur, résultats bruts et résultats corrigés du 19 octobre 2026 ; révision du 20 octobre 2026.
- Fiche officielle du modèle DeepSeek
- Fiche officielle du modèle Meta
- Fiche officielle du modèle StepFun
- Fiche officielle du modèle NVIDIA
More on this from PROMPTIF
benchmarks·Nouveaux modèles sur fal.ai en octobre 2026 : 18 testsEntre le 25 septembre et le 20 octobre 2026, 61 nouveaux endpoints sont apparus sur fal.ai.

