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