Exécuter des modèles d'IA localement vs via API : quel choix faire ?

TL;DR

L'IA locale fonctionne sur votre propre matériel, ne coûte rien par requête et maintient la confidentialité des données. L'IA basée sur API est plus rapide à démarrer, plus performante et évolue sans infrastructure. La plupart des équipes ont besoin des deux. Ce guide explique quand chaque approche est avantageuse, avec des chiffres concrets.

Introduction

Gemma 4 fonctionnant nativement sur un iPhone. Une extension de navigateur qui intègre un modèle de langage complet sans clé API. Cela n'était pas possible il y a 18 mois. Aujourd'hui, on les retrouve sur HackerNews.

La décision était auparavant simple : les modèles de pointe étaient uniquement accessibles via API, tout le reste était trop faible pour être pertinent. Cela a changé. Des modèles locaux comme Qwen2.5-72B, Gemma 4 et DeepSeek-V3 sont désormais compétitifs sur de véritables benchmarks. Les développeurs qui par défaut utilisaient l'API d'OpenAI reconsidèrent leur choix, en particulier pour les applications sensibles à la confidentialité ou les tâches à fort volume où les coûts par token s'accumulent rapidement.

Cet article va au-delà du marketing. Vous obtiendrez des chiffres concrets sur les coûts, la latence et les capacités afin de prendre la bonne décision pour votre cas d'utilisation.

Ce que signifie réellement "exécuter l'IA localement"

L'IA locale n'est pas une seule chose. Il existe trois configurations distinctes :

Inférence sur l'appareil : le modèle s'exécute entièrement sur l'appareil, sans serveur. Gemma Gem dans un onglet de navigateur, Gemma 4 sur le Neural Engine d'un iPhone, ou un modèle Ollama sur votre MacBook. Aucune connexion Internet n'est requise après le téléchargement.

Serveur auto-hébergé : vous exécutez un modèle sur votre propre matériel (un poste de travail, une VM cloud que vous contrôlez, ou un serveur sur site) et exposez une API. Le modèle ne s'exécute pas sur l'appareil de l'utilisateur final, mais il n'est pas non plus chez OpenAI. Des outils comme llama-server, Ollama et vLLM gèrent cela.

Cloud privé : vous déployez un modèle sur votre propre infrastructure cloud (modèles personnalisés AWS Bedrock, endpoints privés Azure, modèles personnalisés GCP Vertex AI). Plus de contrôle qu'une API publique, moins de tracas qu'un auto-hébergement complet.

La comparaison dans cet article se concentre sur l'auto-hébergement vs. l'API publique, car c'est la décision à laquelle la plupart des développeurs sont confrontés.

Comparaison des coûts

C'est là que l'IA locale l'emporte clairement pour les charges de travail à fort volume.

Tarification de l'API publique (avril 2026) :

Estimation des coûts d'auto-hébergement (Qwen2.5-72B sur une seule A100 80GB) :

Une A100 80GB de Lambda Labs coûte environ 1,99 $/heure à la demande. Qwen2.5-72B avec une quantification INT4 tient sur une A100 et traite environ 200 tokens/seconde.

À 200 tokens/seconde avec 100 % d'utilisation, cela représente 720K tokens/heure, soit environ 0,0028 $ par 1K tokens au total (entrée + sortie). À titre de comparaison, GPT-4o facture 0,01 $ par 1K tokens de sortie seulement.

Point d'équilibre : si vous traitez plus de ~70K tokens de sortie par jour de manière constante, l'auto-hébergement est plus économique que GPT-4o. En dessous de ce seuil, l'API est plus avantageuse car vous ne payez pas pour le temps GPU inactif.

Pour les modèles plus légers : un Gemma 4 (12B) quantifié en 4 bits fonctionne sur une seule RTX 4090 (600-800 $ d'occasion). À 0,40 $/heure pour un temps GPU cloud équivalent, l'auto-hébergement atteint le point d'équilibre par rapport à GPT-4o mini à environ 15K tokens de sortie par jour.

Comparaison de la latence

C'est là que les choses deviennent plus nuancées.

Temps de premier token (TTFT) : sur une A100 dédiée, le TTFT pour une invite de 1K tokens avec un modèle de 72B est d'environ 800 ms à 1,5 s. L'API d'OpenAI renvoie généralement le premier token en 300 à 800 ms pour des entrées similaires sous une charge normale.

Pour l'inférence sur l'appareil (iPhone Neural Engine, Apple Silicon), le TTFT pour Gemma 4 est de 200 à 400 ms car il n'y a aucune surcharge réseau. C'est là que l'exécution sur l'appareil l'emporte clairement.

Débit : une seule A100 exécutant un modèle de 72B en INT4 sert bien un utilisateur, mais se dégrade sous une charge concurrente sans traitement par lots (batching). Les API publiques gèrent la concurrence de manière transparente.

Streaming : les deux approches prennent en charge le streaming. Pour les modèles sur l'appareil, la génération entière se produit localement, il n'y a donc pas de gigue réseau. Pour les modèles API, vous êtes à la merci des conditions réseau.

Résumé : l'exécution sur l'appareil l'emporte pour la latence la plus faible (pas de réseau). L'auto-hébergement l'emporte pour le débit à grande échelle (avec un traitement par lots approprié via vLLM). L'API publique l'emporte pour la capacité de pointe et la simplicité.

Comparaison des capacités

C'est là que les API publiques conservent l'avantage pour les tâches les plus exigeantes.

Raisonnement et tâches complexes : GPT-4o et Claude 3.5 Sonnet restent en avance sur les modèles open-weight pour le MMLU, HumanEval et le raisonnement multi-étapes complexe. L'écart s'est considérablement réduit avec Qwen2.5-72B et DeepSeek-V3, mais il est toujours réel.

Génération de code : proche. DeepSeek-Coder-V2 et Qwen2.5-Coder-32B égalent GPT-4o sur de nombreux benchmarks de code. Pour les tâches spécifiques au code sur une configuration auto-hébergée, vous pouvez utiliser un modèle de code spécialisé plutôt qu'un modèle à usage général.

Longueur de contexte : les modèles API de pointe prennent en charge des contextes de 128K à 1M de tokens. La plupart des modèles auto-hébergés plafonnent à 32K-128K en pratique (des contextes plus longs nécessitent proportionnellement plus de mémoire).

Multimodalité : GPT-4o et Gemini 1.5 Pro gèrent les entrées d'images, d'audio et de vidéo. Des modèles multimodaux open-weight existent (LLaVA, Qwen-VL) mais sont en retard.

Appel de fonction / Utilisation d'outils : OpenAI et Anthropic offrent le support le plus fiable pour l'utilisation d'outils. Les modèles open-weight avec utilisation d'outils fonctionnent mais sont moins cohérents sur des chaînes d'outils complexes. Voir [internal: how-ai-agent-memory-works] pour comprendre comment cela affecte les architectures d'agents.

Confidentialité et contrôle des données

C'est là que l'IA locale l'emporte sans conteste.

Avec une API publique : - Vos invites quittent votre réseau - La politique de conservation des données du fournisseur s'applique (OpenAI conserve les entrées pendant 30 jours par défaut, sauf si vous désactivez cette option via l'API) - Vous êtes soumis aux conditions de service du fournisseur concernant les contenus sensibles - Dans les secteurs réglementés (santé, finance, juridique), cela peut constituer un obstacle à la conformité.

Avec un modèle auto-hébergé : - Les invites restent sur votre infrastructure - Pas de conservation de données par un tiers - Contrôle total sur ce que le modèle peut et ne peut pas traiter - La conformité RGPD/HIPAA est plus facile à maintenir.

Pour les applications traitant des données de santé personnelles, des documents juridiques ou du code propriétaire, l'auto-hébergement n'est souvent pas facultatif.

Comment tester les intégrations d'IA quel que soit l'endroit où le modèle s'exécute

Que vous accédiez à https://api.openai.com/v1/chat/completions ou à http://localhost:11434/api/chat (Ollama) ou à http://localhost:8080/v1/chat/completions (llama-server), la surface de l'API est compatible OpenAI. C'est important car les Scénarios de Test d'Apidog fonctionnent avec n'importe quel endpoint HTTP.

Un seul Scénario de Test peut s'exécuter sur les deux :

{
  "scenario": "Chat completion smoke test",
  "environments": {
    "local": {"base_url": "http://localhost:11434"},
    "production": {"base_url": "https://api.openai.com"}
  },
  "steps": [
    {
      "name": "Basic completion",
      "method": "POST",
      "url": "{{base_url}}/v1/chat/completions",
      "body": {
        "model": "{{model_name}}",
        "messages": [{"role": "user", "content": "Say 'test passed' and nothing else"}],
        "max_tokens": 20
      },
      "assertions": [
        {"field": "status", "operator": "equals", "value": 200},
        {"field": "response.choices[0].message.content", "operator": "contains", "value": "test passed"},
        {"field": "response.usage.total_tokens", "operator": "less_than", "value": 50}
      ]
    }
  ]
}

Exécutez ce scénario sur votre instance Ollama locale pendant le développement et sur l'API OpenAI en CI. Si votre code fonctionne avec le modèle local, il devrait fonctionner avec l'API. Si ce n'est pas le cas, la différence réside généralement dans : - Le format du nom du modèle (Ollama utilise qwen2.5:72b, OpenAI utilise gpt-4o) - La structure de la réponse d'appel de fonction (différences subtiles entre les fournisseurs) - Le format des événements de streaming (données vs. delta vs. objets de réponse complets)

Le Smart Mock d'Apidog est utile pour simuler le comportement d'un modèle local en CI sans avoir besoin d'un GPU en ligne. Configurez un mock qui renvoie des réponses valides compatibles OpenAI et exécutez vos scénarios de test dessus. Voir [internal: how-to-build-tiny-llm-from-scratch] pour comprendre pourquoi les structures de réponse diffèrent au niveau du modèle.

Mettre en place un serveur de modèles local en 10 minutes

Si vous souhaitez essayer l'auto-hébergement avant de vous engager, Ollama est le chemin le plus rapide :

# Installer Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Télécharger un modèle (Gemma 4 12B, tient dans 10 Go de VRAM)
ollama pull gemma4:12b

# Démarrer le serveur (API compatible OpenAI sur le port 11434)
ollama serve

# Le tester
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4:12b",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Pour l'auto-hébergement en production avec une concurrence multi-utilisateurs, vLLM est le meilleur choix :

pip install vllm
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-72B-Instruct-AWQ \
  --quantization awq \
  --max-model-len 32768

Ceci expose une API compatible OpenAI sur le port 8000. Pointez Apidog vers http://votre-serveur:8000 et exécutez directement vos Scénarios de Test.

Quand choisir chaque approche

La réponse honnête pour la plupart des équipes : utilisez une API publique pour la production (Claude ou GPT-4o pour les tâches de qualité, Haiku ou 4o-mini pour les tâches à fort volume moins chères), et Ollama localement pour le développement et les tests. Cela vous offre le meilleur des deux mondes : une qualité de pointe en production, un coût nul en développement, et une surface d'API compatible OpenAI cohérente partout.

Voir [internal: open-source-coding-assistants-2026] pour comprendre comment les assistants de codage open source s'intègrent dans le paysage de l'IA locale.

Conclusion

La décision entre l'IA locale et l'API n'est pas binaire. La bonne réponse dépend de votre volume, de vos exigences en matière de confidentialité, de vos besoins en latence et du niveau de capacité dont vous avez besoin.

Pour la plupart des développeurs qui créent des applications basées sur l'IA : commencez par une API publique, passez à l'auto-hébergement lorsque votre facture mensuelle dépasse 200 à 300 $, et utilisez Ollama dans votre environnement local dès le premier jour. Gardez votre code indépendant des fournisseurs en utilisant la surface d'API compatible OpenAI partout.

Testez les deux environnements de manière cohérente avec Apidog pour détecter les différences subtiles entre le comportement des modèles locaux et ceux du cloud avant qu'elles ne deviennent des bugs en production.

FAQ

Quelle est la GPU minimale pour exécuter un modèle local utile ?Une RTX 3060 (12 Go de VRAM) exécute Qwen2.5-7B ou Gemma 4 4B en pleine qualité. Une RTX 4090 (24 Go de VRAM) gère la plupart des modèles 14B-20B en quantification INT4 et les modèles 34B en INT2. Pour les modèles 72B, vous avez besoin de 2 GPU 24 Go ou d'une seule A100/H100.

Puis-je exécuter l'IA locale sur Apple Silicon ?Oui. Ollama prend en charge nativement Apple Silicon et utilise le Neural Engine pour l'accélération. Un M3 Pro (18 Go de mémoire unifiée) exécute confortablement Qwen2.5-14B. Un M4 Max (128 Go) gère les modèles 70B.

La qualité de la sortie du modèle local est-elle suffisante pour la production ?Cela dépend de la tâche. Pour la génération de code, la summarisation et l'extraction de données structurées : oui, avec un modèle 32B+. Pour le raisonnement complexe, l'écriture nuancée ou les tâches nécessitant une connaissance approfondie du monde : les modèles d'API de pointe ont toujours un net avantage.

Les modèles locaux prennent-ils en charge l'appel de fonction ?Oui, mais de manière incohérente. Llama 3.1, Qwen2.5 et Mistral prennent tous en charge l'utilisation d'outils. La fiabilité est inférieure à celle de GPT-4o ou Claude 3.5 Sonnet sur des chaînes d'outils complexes. Testez minutieusement avec les scénarios de test Apidog avant de vous fier à l'utilisation d'outils par un modèle local en production. Voir [internal: claude-code] pour savoir comment les modèles de pointe gèrent l'utilisation d'outils dans des contextes de codage.

Combien coûte l'auto-hébergement d'un modèle 70B sur AWS ?Une p4d.24xlarge (8x A100 40 Go) coûte 32,77 $/heure à la demande. Exécute un modèle 70B INT8 avec un débit élevé. Une g5.2xlarge (1x A10G 24 Go) à 1,21 $/heure exécute un modèle 14B INT4 pour des charges de travail plus légères. Les instances réservées réduisent ces coûts de 30 à 40 %.

Quelle est la différence entre Ollama et llama.cpp ?llama.cpp est le moteur d'inférence sous-jacent. Ollama enveloppe llama.cpp avec une API REST, la gestion des modèles (pull, list, delete) et une simple CLI. Utilisez Ollama pour le développement. Utilisez llama.cpp directement (via llama-server) si vous avez besoin de plus de contrôle sur les formats de quantification ou la configuration matérielle.

Puis-je basculer entre les modèles locaux et API sans modifier mon code ?Oui, si vous utilisez un client compatible OpenAI. En Python : openai.OpenAI(base_url='http://localhost:11434/v1', api_key='ollama') se connecte à Ollama. Modifiez base_url en https://api.openai.com/v1 et mettez à jour api_key pour basculer vers le cloud. Définissez-les via des variables d'environnement et votre code ne changera jamais.