API LLM gratuites : le vrai comparatif (et l'option locale)

#Pourquoi ce comparatif

Chercher une free LLM API, c'est le premier réflexe quand on prototype : on veut tester une idée sans sortir la carte bleue, brancher un modèle sur un script et voir si ça tient la route. Bonne nouvelle, l'offre gratuite est réelle et parfois généreuse. Mauvaise nouvelle, « gratuit » recouvre des réalités très différentes selon qu'on parle d'un palier gratuit permanent, d'un crédit d'essai qui expire, ou d'un accès communautaire à débit bridé.

L'angle de ce guide n'est pas de vous dire « le local, c'est mieux ». C'est de vous donner les chiffres pour décider vous-même : ce que chaque offre gratuite autorise réellement, ce qu'elle prend en échange, et à partir de quel volume ou de quelle contrainte de confidentialité un endpoint local devient le choix rationnel. Souvent, la meilleure réponse n'est ni l'un ni l'autre, mais les deux, avec un routage selon la tâche.

#Le tour des API LLM gratuites

On peut ranger les offres gratuites en quatre familles. Comprendre à quelle famille appartient une offre évite les mauvaises surprises quand le compteur tombe à zéro au milieu d'un sprint.

Palier gratuit permanent

Un accès gratuit qui ne s'éteint pas, mais plafonné en requêtes par minute et par jour. C'est le cas de Google AI Studio (API Gemini) ou de Groq, qui proposent des modèles ouverts (Llama, Qwen, gpt-oss) à débit gratuit mais limité.

Agrégateurs et modèles :free

OpenRouter expose des dizaines de modèles, dont certains suffixés « :free ». L'accès est réel mais le débit dépend d'une réserve partagée et peut chuter aux heures de pointe.

Crédit d'essai

Un montant offert (souvent quelques dollars) à la création du compte, qui expire au bout de quelques semaines. Pratique pour un test ponctuel, inutile pour un projet qui dure.

Inference communautaire

Hugging Face Inference et consorts : accès gratuit à de nombreux modèles, mais froid au démarrage (cold start), files d'attente et débit non garanti.

#Les quotas réels, sans filtre

Le mot « gratuit » masque trois plafonds distincts qui, ensemble, décident si l'offre tient pour votre usage. Un palier peut être généreux sur l'un et étranglé sur les deux autres.

Requêtes par minute (RPM)

Le nombre d'appels autorisés dans la minute. Les paliers gratuits tournent souvent autour de quelques dizaines de RPM — largement assez pour un dev qui teste, trop peu pour servir plusieurs utilisateurs en parallèle.

Tokens par jour (TPD)

Le vrai plafond structurant. Un quota quotidien en tokens se vide très vite dès qu'on envoie de gros prompts, du contexte RAG ou qu'on boucle sur un jeu de données.

Débit et latence

Sur les offres gratuites partagées, la vitesse de génération n'est jamais garantie. Aux heures creuses c'est fluide ; en pic, la latence explose ou les requêtes sont rejetées (erreur 429).

Concrètement : pour du prototypage manuel, quelques requêtes de temps en temps, les quotas gratuits sont confortables. Dès que vous scriptez un traitement par lots — classifier mille tickets, résumer une boîte mail, générer des tests sur un dépôt — vous heurtez le mur du TPD en quelques minutes, et le débit bridé transforme un batch de 10 minutes en une attente d'une heure entrecoupée d'erreurs 429.

#Ce que vous payez vraiment

Une API gratuite n'est pas sans coût : le prix est simplement déplacé du portefeuille vers d'autres colonnes. Trois d'entre elles pèsent lourd pour un projet de dev.

Vos données

Sur beaucoup de paliers gratuits, les prompts et réponses sont conservés et peuvent servir à entraîner ou améliorer les modèles. Ce qui est acceptable pour un test avec des données factices ne l'est pas avec du code propriétaire, des données clients ou des informations personnelles (RGPD).

La dépendance

Bâtir sur un quota gratuit, c'est construire sur un sol qui peut se dérober : changement de conditions, modèle retiré, palier supprimé. Votre code, vos prompts et vos réglages sont calibrés pour un fournisseur ; migrer coûte du temps que vous n'aviez pas prévu.

L'imprévisibilité

Latence variable, files d'attente, coupures : difficile de tenir une promesse de qualité de service quand la brique centrale échappe à votre contrôle et n'offre aucun engagement sur le gratuit.

#L'option locale avec Ollama

En face du gratuit-avec-conditions, il y a le gratuit-pour-de-vrai : faire tourner le modèle sur votre propre machine. Ollama est l'outil le plus simple pour ça. C'est un daemon qui télécharge des modèles open-weight et expose une API HTTP locale sur http://localhost:11434 — dont un endpoint compatible OpenAI, ce qui veut dire que le code écrit pour une API cloud fonctionne souvent en changeant juste l'URL de base.

# Installer Ollama (Linux/macOS)
curl -fsSL https://ollama.com/install.sh | sh

# Tirer et lancer un modèle 7-8B quantifié Q4_K_M
ollama pull qwen2.5:7b
ollama run qwen2.5:7b

# Le daemon écoute sur http://localhost:11434

Côté code, l'endpoint compatible OpenAI se branche en trois lignes. Pas de clé d'API à gérer, pas de quota, pas de donnée qui sort de la machine.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",  # endpoint local Ollama
    api_key="ollama",  # ignoré en local, mais requis par le client
)

resp = client.chat.completions.create(
    model="qwen2.5:7b",
    messages=[{"role": "user", "content": "Explique la récursion en une phrase."}],
)
print(resp.choices[0].message.content)

La contrepartie, c'est le matériel. Un modèle local a besoin de VRAM (ou de mémoire unifiée sur Mac Apple Silicon). En quantification Q4_K_M, le repère mémoire est simple à retenir : un 3B tient dans ~2 Go, un 7B dans ~5 Go, un 14B dans ~9 Go, un 32B dans ~19 Go et un 70B demande ~40 Go. Une RTX 3060 12 Go fait tourner du 7-14B confortablement ; une RTX 4090 24 Go ou un Mac M4 Pro avec 24-48 Go de mémoire unifiée ouvre la porte aux modèles 32B.

Confidentialité totale

Aucun prompt ne quitte la machine. Code propriétaire, données clients, informations personnelles : tout reste chez vous, ce qui simplifie radicalement la conformité RGPD.

Pas de quota

Aucun RPM, aucun TPD. Vous bouclez sur dix mille documents la nuit sans compter et sans erreur 429.

Coût marginal nul

Une fois le matériel là, chaque requête est gratuite. L'électricité d'un GPU de bureau reste négligeable face à une facture d'API à l'usage.

Stabilité

Pas de conditions qui changent, pas de modèle retiré. La version que vous avez tirée reste identique tant que vous ne la mettez pas à jour.

#Le point de bascule vers le local

La question utile n'est pas « gratuit ou local ? » mais « à partir de quand le local devient-il le meilleur choix ? ». Quatre signaux indiquent que vous avez franchi le seuil.

1. 01
   Vous traitez des données que vous ne pouvez pas exposer

   Dès qu'il y a du code propriétaire, des données clients ou des informations personnelles dans le prompt, la clause d'entraînement d'une API gratuite devient rédhibitoire. Le local règle le problème à la racine : rien ne sort.
2. 02
   Vous heurtez les quotas régulièrement

   Si vos scripts se terminent par des erreurs 429, si vous fractionnez vos batchs pour rester sous le TPD, ou si vous jonglez entre plusieurs comptes gratuits, vous payez déjà en temps ce que le local vous rendrait.
3. 03
   Le volume est prévisible et soutenu

   Un usage régulier — génération de tests en continu, pipeline RAG interne, classification à demeure — se rentabilise vite en local. Le matériel est un coût fixe amorti ; l'API à l'usage est un coût variable qui grimpe avec le succès du projet.
4. 04
   Vous voulez une latence maîtrisée

   Sur une machine dédiée, la latence ne dépend que de vous, pas de la charge d'un service partagé. Pour un outil interne utilisé toute la journée, cette prévisibilité vaut cher.

#Garder les deux : le routage malin

L'architecture la plus saine pour un projet de dev n'est pas exclusive : elle route chaque tâche vers l'endpoint le plus adapté. Le local traite le gros du volume et tout ce qui est sensible ; le cloud est réservé aux tâches qui dépassent réellement la machine.

Vers le local

Tâches à fort volume, données sensibles, boucles de traitement, itérations de développement, tout ce qui doit rester confidentiel. Un modèle 7-14B local couvre l'immense majorité des besoins de dev courants.

Vers le cloud

Raisonnement complexe qui exige un très gros modèle, pic de charge ponctuel, ou fonctionnalité multimodale absente en local. On y envoie uniquement ce qui le justifie, et jamais de donnée sensible.

Comme Ollama expose une API compatible OpenAI, ce routage se code trivialement : deux clients, une règle de sélection selon la tâche. Pour aller plus loin, un proxy comme LiteLLM centralise plusieurs backends derrière une seule interface, avec fallback automatique du cloud vers le local (ou l'inverse) et suivi des coûts.

from openai import OpenAI

local = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
cloud = OpenAI(base_url="https://api.exemple.com/v1", api_key="VOTRE_CLE")

def router(sensible: bool, gros_raisonnement: bool):
    # Données sensibles OU volume : local par défaut
    if sensible or not gros_raisonnement:
        return local, "qwen2.5:7b"
    # Sinon, cloud pour un modèle plus puissant
    return cloud, "modele-frontiere"

client, model = router(sensible=True, gros_raisonnement=False)
resp = client.chat.completions.create(
    model=model,
    messages=[{"role": "user", "content": "Résume ce ticket interne..."}],
)

#Démarrer en local en 4 étapes

1. 01
   Installer Ollama

   Une commande sous Linux/macOS (curl -fsSL https://ollama.com/install.sh | sh) ou l'installeur officiel sous Windows. Le daemon démarre et écoute sur http://localhost:11434.
2. 02
   Choisir un modèle à la taille de votre matériel

   Repérez votre VRAM disponible et visez un modèle en Q4_K_M qui rentre avec de la marge pour le contexte : 7B (~5 Go) pour 8-12 Go de VRAM, 14B (~9 Go) pour 12-16 Go, 32B (~19 Go) pour 24 Go. En dessous, un 3B (~2 Go) reste utile pour des tâches simples.
3. 03
   Tirer le modèle et tester

   ollama pull qwen2.5:7b puis ollama run qwen2.5:7b pour vérifier qu'il répond. Un pull ne se fait qu'une fois ; ensuite le modèle est en cache local.
4. 04
   Brancher votre code

   Pointez votre client OpenAI existant sur http://localhost:11434/v1. Le reste du code — messages, streaming, function calling — fonctionne comme avec une API cloud, sans clé ni quota.

#Pour aller plus loin

Une fois Ollama en place, trois guides du site prolongent naturellement cette bascule. L'intégration de l'API REST d'Ollama en Python détaille streaming, JSON mode et function calling sur l'endpoint local. Le comparatif de coût d'un serveur GPU chiffre le seuil de rentabilité entre achat de matériel et API cloud. Et pour un routage industrialisé entre local et cloud, le guide LiteLLM montre comment unifier les deux derrière un proxy avec fallback et suivi des coûts.