llama.cpp RPC : distribuer l'inférence LLM, oui, mais pas sans garde-fous

Le backend RPC de llama.cpp permet de répartir l'inférence sur plusieurs hôtes, mais reste annoncé comme proof-of-concept fragile et non sécurisé sur réseau ouvert.

Le backend RPC de llama.cpp est une piste très intéressante pour exécuter des modèles plus gros en répartissant la charge entre plusieurs machines. Mais il y a un point critique à ne pas ignorer : la documentation officielle le présente comme un proof-of-concept fragile et insecure.

Autrement dit : c'est puissant pour un lab privé, mais dangereux si vous l'exposez sans contrôle strict.

Ce que permet concrètement le backend RPC

  • Exposer des devices (GPU/CPU) d'hôtes distants via rpc-server ;
  • Piloter l'inférence depuis un hôte principal avec llama-cli ou llama-server ;
  • Distribuer poids et KV cache entre devices locaux et distants ;
  • Ajuster la répartition avec --tensor-split.

En POC, c'est une manière rapide de mutualiser des ressources hétérogènes sans réécrire toute la stack.

Le warning officiel à prendre au sérieux

Important : la doc tools/rpc de llama.cpp indique explicitement de ne jamais exécuter le RPC server sur un réseau ouvert ou un environnement sensible.

Pourquoi ? Parce que le focus actuel est la faisabilité technique, pas une sécurité “production-grade” complète (authn, hardening, contrôle d'accès fin, etc.).

Architecture minimale recommandée

  1. Réseau privé dédié (VLAN ou segment isolé).
  2. Aucune exposition Internet directe du rpc-server.
  3. Filtrage strict IP/ports entre nœuds.
  4. Observabilité des appels et erreurs RPC.
  5. Plan de rollback vers une exécution locale mono-nœud.

Exemple de flux de démarrage

# Sur chaque hôte distant: build avec RPC activé
cmake .. -DGGML_RPC=ON
cmake --build . --config Release

# Démarrer le serveur RPC
bin/rpc-server -p 50052

# Sur l'hôte principal: lancer llama-cli avec deux hôtes distants
llama-cli -hf ggml-org/gemma-3-1b-it-GGUF \
  --rpc 192.168.88.10:50052,192.168.88.11:50052

Pour améliorer le temps de chargement, le cache local RPC (-c) peut réduire les transferts de gros tenseurs.

Quand utiliser (et quand éviter)

  • À utiliser : labo R&D, benchmark interne, prototype cluster Mac pour IA privé.
  • À éviter : production exposée, contexte réglementé sans couche sécurité dédiée.

Conclusion

Le RPC de llama.cpp est une excellente brique pour expérimenter l'inférence guide MLX Distributede locale. Mais en 2026, c'est encore un outil d'ingénieur prudent, pas une solution “plug-and-play” de prod ouverte.

Source :

Cet article vous a plu ?

Commentaires

Morgann Riu
Morgann Riu

Expert en cybersécurité et administration Linux. J'aide les entreprises à sécuriser et optimiser leurs infrastructures critiques.

Retour au blog

Checklist Sécurité Linux

30 points essentiels pour sécuriser un serveur Linux. Recevez aussi les nouveaux tutoriels par email.

Pas de spam. Désabonnement en 1 clic.