Raft разобрала, где MCP и Thin MCP добавляют лишнюю задержку AI-агентам

MCP часто подают как универсальный способ аккуратно подключить инструменты к LLM-приложению, но на практике за такую модульность приходится платить задержкой. В новом разборе Raft сравнила несколько архитектур и показала, что проблема обычно не в одном конкретном компоненте, а в том, как вообще устроен путь запроса от агента до инструмента и обратно.

Где рождается latency

Автор начал с базового вопроса: сколько задержки добавляет сам MCP, если убрать сеть и оставить всё в одном процессе. Для этого сравнили монолит без MCP и монолит с MCP in-process. Выяснилось, что сам паттерн даёт сравнительно небольшой overhead — в среднем около 10–11 мс, иногда до 35 мс.

Это важная отправная точка: если агент тормозит на сотни миллисекунд, виноват обычно не сам факт использования MCP, а внешний слой вокруг него. Дальше сравнение перенесли в более реалистичную архитектуру, где MCP-серверы вынесены в отдельные Docker-контейнеры. Здесь картина уже меняется заметно: средняя дополнительная задержка для основных инструментов выросла примерно до 169 мс на вызов.

При этом трейсы показали, что даже это не главный потребитель времени. Самые тяжёлые участки — получение эмбеддингов и работа reranker'a, а поиск по векторной базе занимает сравнительно немного. Иначе говоря, MCP добавляет цену, но не всегда он становится главным тормозом всей цепочки.

Что показали тесты В статье разобрали несколько сценариев, чтобы

отделить влияние транспорта, сериализации и самого runtime друг от друга. S1, MCP in-process: около 10–11 мс дополнительной задержки, то есть сам runtime относительно лёгкий. S2, раздельные MCP через Docker-сеть: в среднем около 169 мс overhead на вызов из-за сети, сериализации и межпроцессного взаимодействия.

S3a, Thin MCP через HTTP + JSON: в одной серии замеров overhead снизился примерно до 128 мс, но результат оказался нестабильным и в повторных прогонах мог быть заметно хуже. S3b, Thin MCP через HTTP + YAML: задержка выросла примерно до 274 мс, что указывает на дополнительную цену сериализации и десериализации. * S4 и S5: ZeroMQ дал около 200 мс, но с более предсказуемым поведением, а C++ runtime снизил overhead до примерно 130–145 мс без радикального перелома по порядку величин.

Главный вывод из этих цифр — интуитивные оптимизации не всегда работают так, как ожидаешь. Замена JSON на YAML не ускорила систему, а наоборот ухудшила её. Переход от HTTP к IPC тоже не дал автоматической победы: реализация на iceoryx2 не показала ожидаемого выигрыша, и только вариант с ZeroMQ оказался практически полезнее за счёт асинхронной модели.

Даже C++ помог умеренно, а не драматически.

Почему thin не спасает

Thin MCP в статье выглядит не как волшебная кнопка ускорения, а как способ упростить архитектуру. В этой схеме proxy-слой остаётся минимальным и только транслирует вызовы, а бизнес-логика уезжает в отдельные HTTP-сервисы. Такой подход даёт языковую независимость, упрощает масштабирование и позволяет писать исполнители хоть на Go, хоть на Rust или C++, даже если полноценного MCP SDK для них ещё нет.

Thin MCP — это скорее архитектурный инструмент, чем способ оптимизации latency.

Практический нюанс в том, что thin-подход может выглядеть быстрее в одном прогоне, но не воспроизводиться стабильно в другом. Для продовой системы это критично: иногда важнее не минимальный разовый p95, а предсказуемое поведение под повторной нагрузкой. Поэтому Raft делает довольно жёсткий, но полезный вывод: если хочется действительно ускорить AI-агента, надо не просто менять язык или протокол, а пересобирать саму схему взаимодействия между proxy, backend-компонентами и тяжёлыми вычислительными шагами.

Что это значит

Для команд, которые строят AI-агентов, это хороший антидот против поверхностной оптимизации. Если система медленная, сначала нужно смотреть на число переходов между компонентами, блокирующие операции, модель конкурентного исполнения и тяжёлые стадии вроде эмбеддингов и reranking. Thin MCP может сделать систему чище и гибче, а C++ или IPC могут дать дополнительный выигрыш, но решающий эффект появляется только тогда, когда сама архитектура перестаёт гонять запрос через лишние слои.