Raft a Analysé Où MCP et Thin MCP Ajoutent de la Latence aux Agents IA

MCP est souvent présenté comme une façon universelle de connecter proprement les outils aux applications LLM, mais en pratique, cette modularité a un coût de latence. Dans une nouvelle analyse, Raft a comparé plusieurs architectures et montré que le problème réside généralement non pas dans un composant spécifique, mais dans la façon dont le chemin de la requête de l'agent à l'outil et vice-versa est structuré au global.

Où naît la latence

L'auteur a commencé par une question de base: combien de latence MCP ajoute-t-il lui-même si vous supprimez le réseau et gardez tout dans un seul processus. Pour cela, ils ont comparé un monolithe sans MCP et un monolithe avec MCP in-process. Il s'est avéré que le modèle lui-même ajoute une surcharge relativement faible — environ 10–11 ms en moyenne, parfois jusqu'à 35 ms. C'est un point de référence important: si un agent ralentit de centaines de millisecondes, le coupable n'est généralement pas l'utilisation de MCP elle-même, mais la couche externe autour d'elle.

Ensuite, ils ont transposé la comparaison dans une architecture plus réaliste, où les serveurs MCP sont déployés dans des conteneurs Docker séparés. Ici, la situation change sensiblement: la latence supplémentaire moyenne pour les outils principaux a augmenté à environ 169 ms par appel. Parallèlement, les traces ont montré que ce n'est même pas le principal consommateur de temps. Les parties les plus lourdes sont l'obtention d'embeddings et le travail du reranker, tandis que la recherche dans la base de données vectorielle prend relativement peu. En d'autres termes, MCP ajoute un coût, mais ce n'est pas toujours le principal goulot d'étranglement de toute la chaîne.

Ce que les tests ont révélé

L'article analyse plusieurs scénarios pour séparer les effets du transport, de la sérialisation et de l'exécution elle-même.

• S1, MCP in-process: environ 10–11 ms de latence supplémentaire, ce qui signifie que l'exécution elle-même est relativement légère.
• S2, MCP séparé via le réseau Docker: environ 169 ms de surcharge par appel en moyenne en raison du réseau, de la sérialisation et de la communication inter-processus.
• S3a, Thin MCP via HTTP + JSON: dans une série de mesures, la surcharge a diminué à environ 128 ms, mais le résultat s'est avéré instable et pouvait être sensiblement pire dans les exécutions répétées.
• S3b, Thin MCP via HTTP + YAML: la latence a augmenté à environ 274 ms, indiquant un coût supplémentaire de sérialisation et de désérialisation.
• S4 et S5: ZeroMQ a donné environ 200 ms, mais avec un comportement plus prévisible, tandis que l'exécution C++ a réduit la surcharge à environ 130–145 ms sans changement radical d'ampleur.

La principale conclusion de ces chiffres est que les optimisations intuitives ne fonctionnent pas toujours comme prévu. Remplacer JSON par YAML n'a pas accéléré le système, mais l'a plutôt aggravé. Passer de HTTP à IPC n'a pas non plus donné des gains automatiques: l'implémentation sur iceoryx2 n'a pas montré l'amélioration attendue, et seule la variante avec ZeroMQ s'est avérée pratiquement plus utile grâce à son modèle asynchrone. Même C++ a aidé modérément, pas dramatiquement.

Pourquoi thin ne sauve pas la mise

Thin MCP dans l'article n'apparaît pas comme un bouton magique d'accélération, mais comme un moyen de simplifier l'architecture. Dans ce schéma, la couche proxy reste minimale et ne fait que traduire les appels, tandis que la logique métier va vers des services HTTP séparés. Cette approche offre l'indépendance des langages, simplifie la mise à l'échelle et permet d'écrire des exécuteurs en Go, Rust ou C++, même si un SDK MCP complet n'existe pas encore pour eux.

Thin MCP est plutôt un outil architectural qu'une méthode

d'optimisation de latence.

La nuance pratique est que l'approche thin peut paraître plus rapide dans une exécution, mais ne pas se reproduire de manière stable dans une autre. Pour un système de production, c'est critique: parfois un comportement prévisible sous charge répétée est plus important qu'un p95 unique minimal. C'est pourquoi Raft tire une conclusion plutôt stricte mais utile: si vous voulez vraiment accélérer un agent IA, ce n'est pas seulement changer le langage ou le protocole, mais reconstruire le schéma d'interaction entre le proxy, les composants backend et les étapes computationnelles lourdes.

Ce que cela signifie

Pour les équipes qui construisent des agents d'IA, c'est un bon antidote contre l'optimisation superficielle. Si le système est lent, vous devez d'abord examiner le nombre de transitions entre les composants, les opérations bloquantes, le modèle d'exécution concurrente et les étapes lourdes comme les embeddings et le reranking. Thin MCP peut rendre un système plus propre et plus flexible, et C++ ou IPC peuvent fournir des gains supplémentaires, mais l'effet décisif n'apparaît que lorsque l'architecture elle-même cesse de pousser les requêtes à travers des couches inutiles.