Self-host ou API cloud ? La checklist opérationnelle MulerTech pour choisir votre LLM

Depuis que DeepSeek a publié son modèle R1 en open-weight en janvier 2025, le paysage des LLM s'est profondément reconfiguré. Comme le souligne MIT Technology Review, les grands laboratoires chinois (Alibaba Qwen, MiniMax, Moonshot, Z.ai) ont adopté une stratégie radicalement différente de celle de leurs concurrents américains : distribuer leurs meilleurs modèles en open-weight, téléchargeables et adaptables sans passer par un fournisseur cloud. Le résultat ? Des modèles aux performances comparables aux systèmes américains, à une fraction du coût, et une adoption développeur en forte croissance.

Pour les équipes comme la nôtre chez MulerTech, cette évolution n'est pas anodine. Le vrai débat n'est plus « quel modèle est le meilleur ? » mais « self-host ou API cloud : qu'est-ce qui est réellement adapté à mon projet ? ». Voici notre checklist opérationnelle.

1. 📊 Benchmark latence & coût GPU avant tout

Avant toute décision d'architecture, posez les chiffres sur la table.

Côté API cloud :

• Coût variable à la requête (tokens in/out)
• Latence réseau + cold start selon le fournisseur
• Pas d'investissement infrastructure initial
• Idéal pour des volumes imprévisibles ou faibles

Côté self-host :

• Coût fixe GPU (location ou achat) + électricité + maintenance
• Latence contrôlée, sans dépendance réseau externe
• Break-even typique autour de quelques millions de tokens/mois selon le modèle

Action concrète : Estimez votre volume mensuel de tokens, calculez le coût API équivalent, puis comparez avec le coût horaire d'un GPU A100/H100 sur votre hébergeur (IONOS, Hetzner, OVH). Si le self-host est 2× moins cher sur 6 mois, c'est un signal fort.

2. ⚙️ Quantization et contraintes mémoire : choisir le bon format

Un modèle à 70B paramètres en FP16 requiert environ 140 Go de VRAM, inaccessible sur la plupart des configurations standard. La quantization permet de réduire drastiquement l'empreinte mémoire.

Les formats à connaître :

Pour des projets RAG ou de classification métier, Q4_K_M offre le meilleur compromis qualité/ressources dans la plupart des cas d'usage.

Action concrète : Testez votre cas d'usage avec llama.cpp ou ollama en Q4 avant d'investir dans du matériel supplémentaire. Si les réponses sont satisfaisantes, vous économisez potentiellement 50% de VRAM.

3. 🐳 Conteneurisation Docker et intégration pgvector pour RAG

Si vous passez au self-host, la conteneurisation est non négociable pour garantir la reproductibilité et la maintenabilité.

Stack recommandée chez MulerTech :

# docker-compose.yml (extrait)
services:
  ollama:
    image: ollama/ollama
    volumes:
      - ollama_models:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]

  postgres:
    image: pgvector/pgvector:pg16
    environment:
      POSTGRES_DB: rag_db
    volumes:
      - pgdata:/var/lib/postgresql/data

  app:
    build: ./app
    depends_on:
      - ollama
      - postgres

Pour l'intégration RAG avec pgvector :

1. Activez l'extension dans PostgreSQL : CREATE EXTENSION vector;
2. Créez une table de chunks avec colonne embedding : embedding vector(1024)
3. Indexez avec HNSW pour des recherches ANN performantes : CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);
4. Côté Symfony, utilisez le composant HTTP Client pour interroger l'API locale d'Ollama et stockez les embeddings via Doctrine.

Attention : Prévoyez un volume Docker dédié aux modèles (souvent 4-40 Go selon le modèle). Sur un serveur IONOS dédié, isolez le service LLM dans son propre réseau Docker pour limiter la surface d'attaque.

4. ✅ La checklist de décision finale

Avant de trancher, passez en revue ces critères :

Optez pour le self-host si :

• Vos données sont sensibles ou soumises à des contraintes RGPD strictes (on-premise obligatoire)
• Votre volume de requêtes justifie économiquement l'infrastructure GPU
• Vous avez besoin de fine-tuning sur des données métier propriétaires
• La latence est critique (< 200ms) et le réseau est un goulot d'étranglement
• Votre équipe peut gérer la maintenance et les mises à jour de modèles

Optez pour l'API cloud si :

• Le volume est faible ou très variable
• Vous prototypez et avez besoin de rapidité de mise en production
• Vous n'avez pas de GPU disponible ni de budget infrastructure immédiat
• Le modèle cible (GPT-4o, Claude) n'a pas d'équivalent open-weight satisfaisant

Premiers tests à lancer dès aujourd'hui :

1. ollama run qwen2.5:32b, testez Qwen sur votre machine ou serveur
2. Comparez la qualité des réponses sur 20 prompts représentatifs de votre cas d'usage
3. Mesurez le temps de réponse moyen (tokens/seconde)
4. Calculez le coût API équivalent sur LiteLLM ou OpenRouter pour le même volume

Conclusion

La montée en puissance des modèles open-weight chinois n'est pas une anecdote géopolitique : c'est un changement structurel qui redonne aux développeurs le contrôle sur leurs outils IA. Pour MulerTech, cela se traduit concrètement par de nouvelles options d'architecture qui étaient inaccessibles il y a 18 mois, notamment pour des projets RAG sur infrastructure PostgreSQL existante.

La décision self-host vs API n'est pas idéologique : elle se prend sur des critères mesurables : coût, latence, conformité, volume. Appliquez cette checklist à votre prochain projet IA, et vous éviterez les mauvaises surprises en production.

Source : China's open-source bet, MIT Technology Review, avril 2026