veilletech.frCe qui se passe
Mohamed Moustafa exploite Olly, un assistant qui vit dans iMessage et tourne sur des modèles ouverts via OpenRouter : plus de 18 millions de messages transmis, dont environ un tiers par cette voie. Assez de volume, dit-il, pour rencontrer chaque cas limite au moins une fois. Il en a tiré une liste de dix pièges.
Le vocabulaire d'abord, parce qu'il porte tout le problème. Le modèle, ce
sont les poids. Le fournisseur, c'est qui les héberge : sur ses GPU, à la
précision qu'il a choisie, avec ses optimisations « propriétaires » et ses
propres analyseurs XML et d'appels d'outils — donc sa propre liste de bugs. En
demandant deepseek/deepseek-v4-flash, on tombe sur l'une d'une vingtaine de
sociétés. Mêmes poids sur le papier, modèles très différents en pratique.
Les écarts mesurés
Le même modèle ne se comporte pas pareil. OpenRouter publie ses propres mesures par fournisseur. Sur DeepSeek V4 Flash 0731 au 7 septembre : DeepSeek en direct obtient 90,2 % sur GPQA Diamond et 81,3 % sur TAU-Bench Airline (appel d'outils) ; DigitalOcean, avec les mêmes poids, 75,3 % et 58,4 %. La plupart des hébergeurs se tiennent 5 à 7 points sous le premier sur l'appel d'outils. Pour un agent, c'est ce score-là qui compte.
Un modèle de vision peut avoir des fournisseurs aveugles. Sur MiniMax M3, Venice et Together répondent « no image provided » aux trois images de test, pendant que les autres les lisent. Sur Qwen3.5 122B, DeepInfra lit un K comme un R et appelle « bleu » du rouge, là où quatre autres hôtes des mêmes poids répondent juste.
Le bouton d'effort est facultatif. reasoning.effort est accepté partout ;
en mesurant les jetons de raisonnement produits à low, high et max, on voit
que DigitalOcean, GMICloud, Mancer et Venice n'en tiennent pas compte.
La quantification déclarée ne prédit pas la qualité. Les hôtes fp4 tombent au
milieu du peloton fp8, et le meilleur fournisseur de GLM 5.3 sur les deux bancs,
Wafer, ne déclare rien du tout. Filtrer sur quantizations réduit surtout le
vivier de repli quand un fournisseur tombe.
Les pannes qui ne disent pas leur nom
- L'appel d'outils reste dans le texte quand l'analyseur du fournisseur le
rate : la réponse utilisateur contient
<use_skills><parameters>{"skills":["search"]}</parameters></use_skills>. Il faut le traiter côté client. - HTTP 200 sans réponse : un modèle de raisonnement met tout dans le champ
de raisonnement et renvoie
content: null,finish_reason: "stop", après 345 jetons facturés. Un 200 dit que la requête a été servie, pas qu'il y a une réponse dedans. - Complétions creuses : 200, contenu nul, raisonnement nul, aucun objet
usage. En juillet, StreamLake représentait 20 % du trafic de l'auteur et 92 % de ses complétions vides ; Together a fait de même le mois suivant. - L'historique obéit au fournisseur, pas au modèle : SiliconFlow refuse par
une erreur 20015 un
reasoning_contentvide que Baidu, Alibaba et Cloudflare acceptent sans broncher. - Testez depuis la production : Venice et Novita répondaient parfaitement depuis le Mac de l'auteur et renvoyaient des 429 depuis son infrastructure, même clé, même minute. Limitation par IP, probablement.
Ce que ça change
Épingler ne suffit pas. L'auteur avait figé
provider.order: [cloudflare, baidu, alibaba] avec allow_fallbacks: false,
soit trois fournisseurs réputés fiables. Deux semaines plus tard, Baidu limitait
tout, Cloudflare ne servait plus ce modèle, et Alibaba, qui absorbait 100 % du
trafic, s'est mis à limiter aussi. Le modèle le plus utilisé d'OpenRouter, épinglé
sur ses trois meilleurs hôtes, était indisponible.
Source : Mohamed Moustafa, repéré par Simon Willison.