Sael против MCP: мы замерили протокол — −89% round-trips
Цифры, а не прилагательные. Поставили эталонный сервер Sael против spec-корректного MCP — те же тулзы, тот же датасет, тот же транспорт. Вот сколько реально стоит форма протокола.
Мы всё повторяли, что Sael быстрее MCP. Потом надоело говорить это без цифры — и мы собрали бенчмарк.
Как меряли (почему это честно)
Фокус протокольного бенчмарка — убрать всё, что не относится к протоколу. Поэтому:
- Одни и те же тулзы и детерминированный датасет на обоих серверах.
- Один транспорт — WebSocket для обоих. Никакого перекоса HTTP/2-vs-WS в байтах.
- Со стороны Sael — настоящий эталонный Go-сервер, не мок.
- Со стороны MCP — spec-корректный JSON-RPC 2.0 сервер:
initialize→tools/list→tools/call, стандартный envelope результата. - Счётчики исключают рукопожатие — меряем маржинальную стоимость задачи.
Считаем round-trips, сырые байты на проводе и время до первого байта. Всё структурное — от железа не зависит.
Результат 1 — многошаговые цепочки
Реалистичный агентный паттерн: fetch → transform → transform → …, где каждый шаг зависит от предыдущего. У MCP нет серверной композиции, поэтому каждый зависимый шаг — отдельный round-trip, который тащит промежуточные данные обратно через клиента.
| Метрика (цепочка из 8 шагов) | MCP | Sael |
|---|---|---|
| Round-trips | 9 | 1 |
| Байт на проводе | 139 KB | 8 KB |
Это −89% round-trips и −94% байт. Sael описывает всю цепочку одним фреймом pipeline; сервер её исполняет и возвращает только финал.
Результат 2 — параллельный fan-out
Шесть независимых веток обогащения над одними данными, по 50 мс. MCP гоняет их последовательно. Sael — конкурентно внутри одного запроса.
| Метрика | MCP | Sael |
|---|---|---|
| Round-trips | 7 | 1 |
| Wall-clock | 312 мс | 53 мс |
Wall-clock — это самая медленная ветка, а не сумма: ~6× быстрее, и ветки вообще не касаются клиента.
Результат 3 — delta-стримы
Дашборд из 30 метрик, 60 обновлений. Наивный подход шлёт всё состояние на каждый тик. Sael стримит снапшот один раз, затем merge-patch (RFC 7386).
| Метрика | Слать целиком | Delta-стрим |
|---|---|---|
| Трафик | 28.1 KB | 3.6 KB |
−87% трафика. Стоимость пропорциональна изменению, а не размеру состояния — ровно то, что нужно real-time дашбордам.
Результат 4 — латентность стриминга и MessagePack
- Нативный стриминг отдаёт первый элемент ~в 10× раньше (1012 мс → 101 мс на стриме из 10 элементов) — MCP ждёт готовности всей пачки.
- Опциональные бинарные фреймы MessagePack срезают ~12% трафика на типичном payload (больше на числовых данных).
Честные оговорки
Это меряет протокольный оверхед — round-trips, байты, латентность до первого байта — а не LLM-токены и не реальный сетевой RTT. Выигрыш растёт с глубиной агентного цикла и размером данных; одиночный tool-вызов преимущества в round-trips не даёт. На реальной сети (RTT 20–100 мс на хоп) схлопывание N round-trips в один умножает выигрыш по латентности ещё сильнее — здесь он скрыт, потому что оба сервера крутились локально.
Весь harness воспроизводим. Протокол source-available (BUSL-1.1). Спека и живое демо — на unyly.org/sael.