Trente-quatre paliers gratuits derrière un seul endpoint : ce que FreeLLMAPI vend vraiment

Il existe un type de développeur bien précis qui, en lisant « 34 fournisseurs LLM gratuits », se met aussitôt à compter les heures avant la première panne. FreeLLMAPI s'adresse à ce développeur-là, et il faut lui rendre cette justice : le README ne prétend pas le contraire. Les chiffres sont annoncés d'entrée, dans une taille de police qu'on réserve d'habitude aux annonces de levée de fonds : 7,4 milliards de tokens par mois, 34 fournisseurs, 635 endpoints gratuits, 474 familles de modèles, une seule URL compatible OpenAI.

Le dépôt a gagné environ 15 600 étoiles le mois dernier et en compte aujourd'hui à peu près 45 400. Ce genre de croissance est un signal en soi. Les gens ne mettent pas une étoile parce que c'est élégant. Ils la mettent parce que ça fait un an qu'ils font la même chose à la main, mal : ouvrir six tableaux de bord, copier six clés dans un fichier de config, et découvrir à deux heures du matin que le quota du seul fournisseur dont leur script dépend vraiment a été réinitialisé il y a trois heures.

Ce que c'est, concrètement

FreeLLMAPI est un routeur local qui s'intercale entre votre client et un empilement de paliers gratuits. Vous pointez votre client vers http://localhost:PORT/v1, vous lui donnez n'importe quelle chaîne de clé, et il décide quel modèle en amont utiliser pour chaque requête. Quand un fournisseur commence à renvoyer des erreurs de limite de débit, il bascule sur le suivant. Il suit la consommation par clé pour vous éviter de foncer dans un plafond qui ne se réinitialisera pas avant le premier du mois. Les clés sont stockées chiffrées.

C'est toute l'astuce, et elle est réelle. Quiconque a essayé de maintenir un projet perso en vie sur des paliers gratuits connaît le vrai mode de défaillance : ce n'est pas un fournisseur qui tombe. C'est de construire toute votre logique de retry autour du format d'erreur spécifique d'un fournisseur, puis de découvrir que le suivant en utilise un autre, puis de découvrir que le troisième ne fait pas le streaming de la même façon.

L'installation

Quatre chemins possibles, ce qui en dit long sur le public attendu.

Le plus rapide, c'est l'application de bureau : téléchargement macOS ou Windows depuis la page des releases, lancement, ajout des clés. Pour un homelab ou une petite équipe, il y a un Docker Compose pointant vers ghcr.io/freellmapi/freellmapi, l'option que je choisirais si la chose doit tourner pendant des mois. Il existe aussi des apps Android et iOS, ce qui paraît excessif jusqu'à ce qu'on se rappelle que des gens veulent sincèrement un modèle de secours sur leur téléphone sans payer 20 $ par mois pour ce privilège.

Une fois lancé, la configuration tient en une ligne dans le client de votre choix. Tout ce qui parle l'API OpenAI fonctionne : agents de code, interfaces de chat, les SDK Python et TypeScript habituels. Vous réglez l'URL de base, vous mettez une fausse clé, et les requêtes commencent à circuler. La liste de compatibilité du README est longue et inclut les agents en ligne de commande que les gens utilisent vraiment au quotidien.

La partie qui coûte de l'argent

C'est là que ça devient intéressant. Le catalogue se met à jour depuis un flux signé. Nouveaux modèles gratuits, changements de quota, correctifs de compatibilité arrivent sans git pull. C'est la plomberie que personne ne veut maintenir à la main, et c'est aussi la partie qui n'est pas entièrement gratuite.

Une installation gratuite reçoit un instantané mensuel. Un modèle qui rejoint le flux en direct n'apparaît sur votre machine que 30 jours plus tard. Si vous voulez le catalogue du jour même, c'est 19 $ par an. Voilà le modèle économique : ni le routage, ni le logiciel (sous licence MIT), mais la fraîcheur de la liste.

Le modèle est raisonnable, et il trahit aussi quelque chose. La valeur, dans cette catégorie, n'a jamais été le code du proxy. C'est de savoir, cette semaine, lequel des 635 endpoints est encore vivant et lequel a discrètement coupé la génération d'images dans son palier gratuit. C'est un problème de données, et les données vieillissent vite.

Ce que ça ne règle pas

Les paliers gratuits sont gratuits parce que quelqu'un a jugé que le coût marginal de votre trafic valait la dépense marketing. Ils ne sont pas gratuits parce que les conditions d'utilisation vous autorisent à en agréger trente-quatre derrière un seul endpoint pour revendre l'accès. Le README comporte une section sur les limites et un avertissement : les deux méritent d'être lus avant de pointer quoi que ce soit de production vers cet outil.

Il y a aussi la question de la qualité. Les paliers gratuits, ce sont généralement les petits modèles, les versions quantifiées, les checkpoints plus anciens. Si votre workflow exige qu'un modèle précis se comporte d'une manière précise, un routeur qui en substitue silencieusement un autre quand le premier est limité produira des résultats incohérents d'une manière difficile à déboguer. Le routeur a une logique de bascule ; il n'a pas la notion de « ces deux modèles sont interchangeables pour ma tâche ».

Et puis il y a la latence. Chaque saut ajoute une décision. Quand tout va bien, vous ne le remarquerez pas. Quand trois de vos trente-quatre fournisseurs passent un mauvais après-midi, vous le remarquerez sous la forme d'une requête qui met onze secondes à échouer avant de réussir ailleurs.

Le détail peu glamour qui fait que ça marche

La comptabilité par clé est la partie que je copierais si je construisais quelque chose de similaire. Les paliers gratuits n'échouent généralement pas bruyamment. Ils échouent par dégradation lente : votre script marche lundi, ralentit mercredi, et vendredi commence à renvoyer un 429 que votre code traite comme une erreur générique et réessaie à l'infini. Un routeur qui connaît le plafond de chaque clé et cesse d'envoyer des requêtes avant de taper dans le mur fait le travail ennuyeux et essentiel de maintien en vie d'un système.

L'autre choix de conception à noter, c'est qu'il n'essaie pas d'être malin sur la sélection de modèle d'une façon qui vous surprendrait. Vous pouvez épingler un modèle si vous voulez. Le routeur existe pour absorber les pannes, pas pour éditorialiser sur le modèle qui convient le mieux à votre prompt. Cette retenue est rare dans la catégorie, où les projets ont tendance à rajouter une couche de « routage intelligent » qui rend les sorties non reproductibles et le débogage pénible.

À qui ça s'adresse

Si vous construisez quelque chose qui doit être fiable, ce n'est pas votre infrastructure. Payez une bonne API et passez à autre chose. Le coût d'un modèle instable en production se mesure en tickets de support, pas en dollars par million de tokens.

Si vous construisez quelque chose pour vous, ou si vous prototypiez une idée à une heure du matin un samedi, c'est réellement utile, d'une manière que la plupart des dépôts d'outillage IA ne sont pas. Ça retire la partie fastidieuse (gestion des clés, suivi des quotas, bascule) et vous laisse la partie qui compte (est-ce que l'idée tient debout). Le chiffre de 7,4 milliards de tokens par mois, c'est du marketing, mais l'affirmation de fond est vraie : la capacité gratuite répartie sur trente-quatre fournisseurs est bien plus grande que celle de n'importe lequel d'entre eux, et elle est en grande partie inutilisée.

La question inconfortable que pose le projet concerne l'année à venir. Chaque palier gratuit est un budget d'acquisition client, et ces budgets sont en train d'être rabotés. Un routeur qui dépend de trente-quatre d'entre eux est un pari : au moins quelques-uns continueront à offrir de l'inférence. Ce pari a payé un moment. Il serait étrange qu'il paie pour toujours.

Pour l'instant, 45 000 personnes ont jugé que l'échange en valait la peine, et l'honnêteté du README sur les limites est la raison pour laquelle je lui ferais davantage confiance qu'aux alternatives qui promettent tout et ne documentent rien.