Une carte-titre portant « ghfind met MiniCPM-V 4.7 derrière ses roasts GitHub », sous-titrée « et sa propre doc ne s’accorde pas sur ce que cela change », avec trois libellés en pastille — score déterministe, sponsor de modèle nommé, deux docs contradictoires — et un motif de trois cartes arrondies reliées par de fines lignes, chacune contenant une petite grille de contributions plate.
Engineering & Research

ghfind Placez MiniCPM-V 4.7 derrière ses propres critiques acerbes GitHub — et sa propre documentation ne s’accorde pas sur ce que cela change

Auteur

Magnus Corvin

Date de publication

Derniers modèles · 20Voir tous les modèles →
Benchmarks : Artificial Analysis · mis à jour quotidiennement
Retour à tous les articles

Faites défiler jusqu'en bas de ghfind.com et vous verrez une petite ligne qui n'y était pas auparavant : Sponsor du modèle, une marque MiniCPM et un lien vers modelbest.cn. Le modèle derrière cette marque est MiniCPM-V 4.7, la version vision-langage d'OpenBMB publiée le 12 octobre 2026. Pour un produit dont toute la promesse est un score reproductible de 0 à 100 de « valeur et confiance » pour n'importe quel compte GitHub, le parrainage d'un modèle n'est pas un détail cosmétique — c'est une question de ce que le modèle est autorisé à toucher. Et la documentation de ghfind donne deux réponses différentes à cette question. Les défaillances de l'IA et incidents d'agents documentés derrière des versions comme celle-ci sont recueillis dans l'archive des incidents d'IA OrcaRouter où chaque entrée comporte ses propres sources, son niveau de gravité, sa note de confiance et un indicateur de contestation.

Voilà l’histoire qui vaut la peine d’être écrite, car la version superficielle — « un site de roast de GitHub a changé de modèle » — est un communiqué de presse. La version qui se trouve dessous parle d’un produit de notation qui doit convaincre les gens que son chiffre ne relève pas du ressenti, tout en adoptant un modèle de langage.

Ce que la page montre réellement, et ce qu’elle ne montre pas

Le bandeau de sponsorisation est bien réel et visible sur la page d'accueil publique en anglais. Il se trouve à côté de deux autres contrôles : une option « Utilisez votre propre modèle / clé API », et des emplacements de logo vides marqués Votre logo ici. La structure que ghfind met donc en avant n'est pas « notre modèle, obligatoire » — c'est un sponsor par défaut auquel s'ajoute une échappatoire de type « apportez votre propre clé », ce qui est une conception raisonnable pour un produit qui dépense du crédit de modèle à chaque roast.

Trois choses qui sont répétées à propos de ce changement ne figurent pas sur la page. Premièrement, ghfind ne publie aucun chiffre de trafic nulle part sur le site, donc tout nombre décrivant ses visites quotidiennes vient d’ailleurs que de ghfind. Deuxièmement, l’expression « modèle principal » n’est pas celle de ghfind — la page indique Sponsor du modèle. Troisièmement, et c’est le plus utile, le dépôt open source livre encore une valeur par défaut entièrement différente : son .env.example configure le LLM de roast sur le modèle de StepFun step-3.7-flash, avec un repli D​eepSeek pour le cas où le fournisseur principal tombe ou limite le débit avant que le moindre texte ne soit diffusé. Quiconque auto-héberge ghfind à partir des sources obtient cette configuration, et non un point de terminaison MiniCPM.

Donc l’affirmation exacte est étroite et plus intéressante que la générale : sur le produit hébergé, MiniCPM est le sponsor nommé du modèle. Dans le code ouvert, ce n’est pas le modèle par défaut. Ce sont des affirmations différentes et seule la première est étayée par ce qu’un lecteur peut voir.

Le produit, avant le modèle

ghfind est une application Next.js, sous AGPL-3.0, avec environ 260 étoiles sur GitHub, et des commits continus tout au long de la semaine où ces lignes ont été écrites. Son cœur n’est pas du tout un LLM. Un moteur TypeScript déterministe — porté ligne par ligne depuis une compétence Python open source appelée github-account-value, avec des tests de parité qui verrouillent l’équivalence des deux implémentations — lit des données GitHub publiques et produit un score selon six dimensions pondérées : maturité du compte, qualité des projets originaux, qualité des contributions, impact sur l’écosystème, influence communautaire et authenticité de l’activité. Dix signaux d’alerte liés à des comportements de farming sont soustraits de ce score, avec un poids plus fort accordé aux signaux coûteux à falsifier, comme les pull requests fusionnées dans des dépôts que le compte ne possède pas, et un poids plus faible pour les signaux faciles à acheter, comme les étoiles et les abonnés.

L’objectif même de cette conception, c’est l’auditabilité. Pour un même compte GitHub et une même date de collecte, le nombre est censé être identique à chaque fois, pour tout le monde. C’est ce qui rend un score utilisable pour des choses comme le tri d’une file de tickets, ce que ghfind fait aussi via une GitHub App qui étiquette les tickets entrants avec la tranche de l’auteur.

L’intervention du modèle se fait en aval : transformer un résultat fixe en une phrase de roast, un ensemble de tags et un rapport écrit. C’est la partie que les utilisateurs capturent en screenshot et partagent, et c’est celle à laquelle un parrainage s’attacherait naturellement.

La contradiction qui mérite d'être relevée

C'est ici que les deux documents divergent.

Le README du dépôt décrit deux passes LLM séparées : un juge factuel peut appliquer une calibration bornée de ±10, puis un rédacteur transforme le résultat fixé en tags, la meilleure phrase de roast et le rapport. Le rédacteur ne peut pas modifier le score. Lisez cette phrase deux fois. Il est explicitement interdit au rédacteur de déplacer le nombre, et il est explicitement permis au juge de le déplacer jusqu’à dix points — sur une échelle de cent points, cela représente un dixième de toute l’étendue.

Le llms.txt propre au site, écrit pour les agents et les machines, affirme quelque chose de plus fort : un moteur entièrement déterministe … Les mêmes entrées produisent toujours le même score ; aucun LLM ne touche au nombre.

Les deux ne peuvent pas être vrais en même temps. Soit la passe du juge existe dans le chemin par défaut et la borne de ±10 est réelle, auquel cas le score est déterministe à une calibration dépendante du modèle près — soit le juge n’est pas dans le chemin par défaut et le README décrit un mode optionnel. Ce qui n’est pas contesté, c’est que le texte du dépôt lui-même envisage qu’un modèle ait une influence bornée sur le nombre, tandis que la description lisible par machine destinée au public dit qu’il n’en a aucune.

Cela compte davantage, et non moins, parce qu’un sponsor de modèle est désormais nommé sur la page. Si un modèle peut faire varier un score de dix points, alors savoir quel modèle effectue l’évaluation est une question qu’un utilisateur est en droit de poser — non pas parce que quiconque triche, mais parce que les affirmations de reproductibilité ne sont jamais plus solides que leur exception documentée la plus fragile. Un produit qui publie une page de méthodologie doit à ses lecteurs une phrase qui détermine laquelle de ses deux descriptions est la version actuelle.

Pourquoi un modèle de vision, pour un produit textuel ?

Le choix d’un modèle multimodal pour un site de notation GitHub paraît étrange jusqu’à ce qu’on regarde ce qui est réellement transmis au modèle. On ne demande pas à MiniCPM-V 4.7 de lire des dépôts ; on lui demande de lire un prompt. Les modèles vision-langage sont de plus en plus utilisés comme juges généraux bon marché parce qu’ils sont entraînés sur des entrées entrelacées et tendent à bien respecter les instructions de sortie structurée, et parce qu’un modèle unique capable d’accepter aussi une capture d’écran est utile dès qu’un utilisateur colle une capture de profil dans un parcours de support.

Il y a aussi une logique de coût. La variante 35B-A3B active environ trois milliards de paramètres par token au sein d’un mélange de 256 experts, et la variante 1B est un modèle dense suffisamment petit pour tourner sur un téléphone. Pour un produit dont la passe de roast se déclenche à chaque scan de profil, un modèle que l’on peut servir à moindre coût — ou faire tourner soi-même — constitue une proposition économique différente d’un appel à une API de pointe par roast. C’est la même raison pour laquelle le site propose un parcours bring-your-own-key : la facture de modèle évolue avec le trafic, et le trafic est précisément ce qu’un site de scoring cherche à développer.

Si vous construisez vous-même ce type de pipeline — un cœur déterministe avec, par-dessus, une couche de narration adossée à un modèle —, la question opérationnelle est de savoir pour combien de fournisseurs vous voulez détenir des clés. OrcaRouter met plus de 200 modèles hébergés derrière un seul point de terminaison compatible OpenAI avec 0 % de marge, avec le prix catalogue de chaque fournisseur répercuté tel quel et un basculement automatique lorsqu’un fournisseur se dégrade ; son DSL de routage peut envoyer la passe de juge peu coûteuse et la passe de rédaction plus coûteuse vers des modèles différents au sein d’un même appel. Une limite, en toute honnêteté : MiniCPM-V 4.7 ne figure pas dans notre catalogue, donc si c’est le modèle que vous voulez, il faut passer par la plateforme propre à OpenBMB. Le routeur est la pièce qui garde un chemin de secours prêt lorsqu’un seul point de terminaison sponsorisé est la seule chose qui vous sépare d’une boîte de rôtissage vide.

Ce qu’est réellement MiniCPM-V 4.7, cette semaine

Le côté modèle mérite la même précision. Le dépôt d’OpenBMB contient une entrée News datée du 12 octobre 2026 portant la mention « MiniCPM-V 4.7 publié », et les dépôts Hugging Face ont été créés dans les jours précédents — le 6 octobre pour le 1B et le 7 octobre pour le 35B-A3B — ce qui correspond à un téléversement de poids par étapes. La fiche du modèle a suivi. Une deuxième entrée News, le 15 octobre 2026, a annoncé des têtes de décodage spéculatif DSpark en BF16 et GGUF pour les deux tailles.

• Tailles — mélange d'experts creux 35B-A3B comptant 35,21 milliards de paramètres au total, et une variante dense 1B de 1,55 milliard

• Licence — Apache 2.0 pour les deux, poids téléchargeables, aucun accès verrouillé

• Contexte — 262 144 tokens sur les deux variantes

• Architecture — 256 experts avec 8 actifs par jeton dans le 35B ; un schéma d’attention linéaire/complete dans un rapport 3:1 sur 40 couches ; tour de vision d’une largeur cachée de 1152 avec des tuiles d’entrée de 980 pixels

• Quantification — versions GGUF, bitsandbytes, AWQ, GPTQ, FP8 et int4 publiées aux côtés des poids BF16

• Service — SGLang, vLLM, llama.cpp et Ollama sont indiqués comme pris en charge ; Ollama dispose d’une entrée officielle

• Selon le fournisseur — plus de 13 tokens par seconde avec environ 3 Go de mémoire sur un iPhone 17 Pro Max, et une accélération de 5× sur l’appareil grâce à Lookahead Expert Scheduling

• Distribution — environ 95 000 téléchargements mensuels sur le dépôt 35B-A3B et 46 000 sur le 1B, avec environ 1 079 et 398 mentions J’aime

Tout ce qui figure dans cette liste est vérifiable à partir de la fiche et du fichier de configuration. Ce qui n’est pas encore disponible, c’est une évaluation indépendante. Le catalogue de modèles d’Artificial Analysis ne comporte aucune entrée pour aucune des deux variantes de MiniCPM-V 4.7 à l’heure où nous écrivons, de sorte que le chiffre de 13 tokens par seconde, l’accélération de 5× et l’affirmation selon laquelle 35B-A3B « obtient un score global plus élevé en moins de temps d’inférence que Qwen3.6 35B-A3B » sont tous des éléments déclarés par le fournisseur et non reproduits. C’est normal pour un modèle âgé de huit jours, et c’est la raison de considérer le placement du sponsor comme un indicateur de la structure de coûts de ghfind plutôt que de la qualité du modèle.

A cropped capture of the Hugging Face model card for MiniCPM-V-4.7-35B-A3B under the OpenBMB organisation, showing the benchmark chart images and the quick-start sections of the card.

La partie que personne ne peut encore vérifier

Ce qui réunit les deux moitiés de cette histoire. La crédibilité de ghfind repose sur un chiffre qu'il présente comme reproductible. Celle de MiniCPM-V 4.7 repose sur des benchmarks que son fournisseur a publiés il y a une semaine. Le sponsoring les unit sans aucune preuve publiée quant au comportement du modèle en tant que juge — aucun taux d'accord avec des évaluateurs humains, aucune mesure de dérive entre les versions du modèle, aucune indication de savoir si le remplacement du sponsor modifierait le score de qui que ce soit.

Ce sont toutes des choses peu coûteuses à publier et coûteuses à devoir justifier plus tard. La mesure précise qui trancherait est un test de re-scoring : prendre un échantillon fixe de comptes, exécuter le pipeline avec la passe du juge activée puis désactivée, et rapporter la distribution de la différence. Si elle se concentre autour de zéro, le ±10 est un garde-fou que personne ne déclenche et l’affirmation « aucun LLM ne touche au chiffre » est effectivement vraie. Si elle se disperse, la calibration joue réellement son rôle et la page de méthodologie doit le dire.

En attendant, la lecture honnête est celle-ci. ghfind est un évaluateur déterministe bien conçu, avec une séparation inhabituellement claire entre son chiffre et sa prose, et il a désormais un sponsor de modèle nommé dont le rôle dans le pipeline est documenté de manière incohérente dans ses propres fichiers. MiniCPM-V 4.7 est une véritable publication multimodale sous licence Apache, réellement peu gourmande en mémoire, arrivée il y a huit jours avec une fiche de modèle, un suivi DSpark et aucun benchmark indépendant. Aucun de ces faits n'est un scandale. Les deux sont le genre de chose que l'on remarque seulement lorsqu'on lit le dépôt plutôt que la page d'accueil — ce qui, pour un produit qui évalue le travail des autres, est le minimum qu'un lecteur puisse faire.

A scoreboard titled "MiniCPM-V 4.7 — the scoreboard" listing eight rows: 35B-A3B MoE with a 1B dense sibling, 262,144-token context, Apache 2.0 licence, SGLang, vLLM, llama.cpp and Ollama serving, 13-plus tokens per second at about 3 GB on-device, GGUF, AWQ, GPTQ, FP8 and int4 quantisation, no independent score published, and charts rather than a table for the published evaluation.

Comment vérifier votre propre score, concrètement

Si vous avez un profil sur le site, c’est le chemin déterministe qu’il faut tester. ghfind expose un point de terminaison de score qui ne nécessite ni authentification ni appel à un modèle, et la compétence de notation sous-jacente est open source, donc le nombre obtenu via l’API et celui obtenu sur le site devraient concorder. S’ils ne concordent pas, la différence tient soit au moment de la collecte — le site met en cache pendant un jour — soit à la passe de calibration, et on peut les distinguer en se demandant si l’écart est stable sur des exécutions répétées.

Pour quiconque construit un outil similaire, la leçon architecturale de ghfind vaut plus que l’actualité du modèle : gardez le nombre dans le code, gardez la prose dans un modèle, et rendez la frontière entre les deux suffisamment explicite pour qu’un lecteur puisse l’inspecter. Le mode de défaillance n’est pas d’utiliser un LLM. Le mode de défaillance, c’est de documenter la frontière à deux endroits et de laisser les deux descriptions diverger.

The ghfind.com English homepage, showing the username entry field, the "value and trust score" pitch, scan counters, the Model sponsor strip naming MiniCPM, and the bring-your-own-key control.

Ce qu’il faut surveiller ensuite est limité. ghfind dispose d’un changelog public et d’un dépôt mis à jour presque tous les jours, si bien qu’une note méthodologique conciliant le calibrage à ±10 avec la ligne « sans LLM » apparaîtrait rapidement. Côté modèle, le premier benchmark indépendant de MiniCPM-V 4.7 — ou le premier rapport sur ce qu’il coûte par torréfaction à volume — est le chiffre qui transformerait un parrainage en argument. Aucun des deux n’existe encore. Il ne manque qu’une publication à chacun.