Глава 14 — Бенчмаркинг, тестирование и производительность

Пятнадцатый и финальный пост поглавного разбора LLM Primer IV: Designing AI Cognition with MCP. В котором архитектуре наконец приходится ответить на бесстрастный вопрос — действительно ли система работает? — и ответ приходит через реальные бенчмарки, два системных режима отказа и десятикратный обрыв пропускной способности, который большинство команд обнаруживает в день продакшен-раскатки.

Почему существует эта глава

Тщательно спроектированный, безопасно закалённый и чисто завёрнутый во фреймворк протокол всё равно должен ответить на бесстрастный вопрос: действительно ли система работает? Решает ли агент задачи, под которые он был построен? Держится ли он, когда нагрузка удваивается? Где обрывы производительности, превращающие плавную деградацию в простой? Предыдущие главы были о том, как правильно построить архитектуру; эта — о том, как измерить, доставляет ли она результат, когда построена. Глава проходит MCP-Universe Benchmark — первый публичный test-harness, прогоняющий реальные LLM против реальных MCP-серверов, — два системных режима отказа, которые бенчмарк раскрыл, и смягчения, начавшие работать, — и сторону пропускной способности, где разрыв между хорошо инженерным пулом сессий и наивным пер-запросным паттерном — порядок величины.

14.1 MCP-Universe: измерение агентов на реальных серверах

Большую часть 2024 и начала 2025 года публичная оценка агентов жила в странном месте. Бенчмарки использования инструментов мерили, синтаксически ли корректные вызовы модель эмитирует против синтетических API. Агентные бенчмарки мерили завершение задач в песочничных средах. Чего не хватало — бенчмарка, прогоняющего модели против реальных MCP-серверов с реальной аутентификацией, реальными rate-limit-ами, реальными схемами, дрейфующими во времени, реальными инструментами, иногда возвращающими пустые результаты. MCP-Universe, выпущенный Salesforce AI Research в 2025 году, был первой серьёзной попыткой. Шесть оценочных доменов, охватывающих одиннадцать реальных продакшен MCP-серверов — Google Maps, GitHub, Yahoo Finance, Blender, Playwright, реальные поисковые движки — и 231 задача, каждая с автоматическим оценщиком, проверяющим, совпадает ли финальное состояние с ожидаемым исходом, а не «правильные» ли вызовы инструментов модель эмитировала по пути.

Заголовочный результат устоял через релизы моделей. Claude 3.5 Sonnet, набирающий восьмидесятые на синтетических бенчмарках, добрался лишь до нижне-средних сороковых на MCP-Universe в целом. GPT-4o, Gemini 1.5 Pro и варианты Llama-3 70B сгруппировались на схожей территории. Разрыв между производительностью в закрытом курсе и реальной MCP-производительностью был около сорока абсолютных пунктов, и масштаб сам по себе его не закрыл. Отказы кластеризуются в узнаваемые категории: деградация на длинном контексте по мере заполнения окна выходами инструментов; исследование неизвестных инструментов, когда модель неправильно читает незнакомые схемы; координация между серверами, где форматы выходов не совпадают и нет семантического моста; и task-specific-рассуждение, где модель выбирает правильный инструмент, корректно его вызывает, получает правильный ответ и всё равно приходит к неверному финальному выводу, потому что не интегрировала выход инструмента в более широкое рассуждение. Структурные решения, делающие MCP-Universe серьёзным инструментом: execution-based-оценка (прогон вызовов против реальных серверов, а не сравнение с эталонной трассой), живые данные (живые рыночные данные, причём оценщик отслеживает, каким был ответ на момент прогона), и мультитёрновая оценка (оценивается финальное состояние, а не каждый шаг). Полезный побочный эффект: бенчмарк действует как косвенный сигнал качества дизайна серверов, и авторы серверов, которым небезразлична агентная производительность, теперь имеют публичную цель.

14.2 Два системных вызова и что работает

Деградация на длинном контексте и исследование неизвестных инструментов — два режима отказа, достаточно крупных, чтобы заслуживать аккуратного рассмотрения, потому что смягчения неочевидны. У деградации на длинном контексте в MCP-агентах конкретная форма: контекст заполняется выходами инструментов, которые все в каком-то смысле релевантны — каждый был результатом вызова, который модель решила сделать, — но каждый объёмен, а реально нагруженный факт внутри каждого мал. Смягчения работают на уровне презентации информации. Резюмирование результатов инструментов прогоняет дешёвую модель (Haiku, GPT-4o-mini, Gemini Flash) поверх сырого выхода инструмента до того, как результат попадёт в контекст агента; продакшен-развёртывания сообщают об улучшении доли завершения на длинном контексте в 2–3 раза, и стоимость на вызов доминируется дешёвой моделью. Структурированный выход инструментов с полем summary рядом с JSON-payload — формализованный в редакции протокола 2025 года — делает похожую работу без дополнительного вызова модели. Сжатие контекста в агентном цикле в паре с управляемым агентом черновиком, дословно переживающим сжатие, обрабатывает случай, когда сам разговор стал слишком длинным; продакшен-развёртывания запускают сжатие каждые двадцать-сорок шагов и сохраняют примерно треть исходного контекста.

У исследования неизвестных инструментов другая форма. Когда агент подключается к серверу с инструментами, на которых он не обучался, первые вызовы модели часто проваливаются — неверные типы, неверный порядок, иногда вовсе неверный инструмент. Смягчение — фаза исследования до основного цикла: фреймворк просит модель прочитать описание каждого инструмента, резюмировать, что он делает, сгенерировать пример вызова и пометить параметры, в которых она не уверена. Получившаяся заметка предваряет контекст агента. Цена — несколько дешёвых вызовов в начале сессии; выгода — двадцать-тридцать процентных пунктов улучшения завершения на бенчмарках вроде MCP-Universe и аудируемая запись заявленного понимания агента, помогающая атрибутировать поздние отказы. Паттерн расширяется до изменившихся инструментов: хешировать поверхность инструментов при подключении, запускать прогрев при изменении хеша, — и режим тихого дрейфа (сервер обновился, агенты падают неделями, прежде чем кто-то заметит) исчезает. Третий связанный вопрос, который стоит назвать, — качество описаний инструментов. Многие серверы отгрузили описания, написанные для людей-разработчиков — лаконичные, перегруженные жаргоном, предполагающие контекст. Серверы, переписанные как бы для интерна, никогда не видевшего систему, показывают измеримые улучшения против тех же моделей без изменения кода агента. Единственное окно модели на инструмент — описание, и описание, не стоящее само по себе, производит модель, которая инструментом пользоваться не может.

14.3 Обрыв пропускной способности пула сессий

Корректность — половина истории; продакшен-реальность в том, что проектные выборы, делающие агента быстрым, часто имеют последствия для корректности и наоборот. Самый крупный вопрос пропускной способности в MCP-развёртываниях 2025–2026 годов — разрыв между двумя способами управления Streamable HTTP-сессиями, и разрыв этот примерно десять к одному. Session-per-request открывает новую сессию на каждый агентный запрос, гоняет внутри неё вызовы инструментов, закрывает по завершении. Shared-session-pool держит пул долгоживущих сессий и назначает каждому запросу одну из пула. Разница пропускной способности на стандартном сервере с репрезентативной нагрузкой стабильно ложится около десятикратной — примерно тридцать запросов в секунду для session-per-request, примерно 290–300 для пула, на товарном железе. Команды, не знающие о разрыве, обнаруживают его жёстким способом: staging бежит хорошо, продакшен-раскатка упирается в стену на rate-е запросов, где доминирует overhead создания сессии.

Механизм прост. Создание сессии дорого — аллокация состояния, согласование возможностей, валидация учётных данных, регистрация очистки, структурированное логирование — и MCP-уровневое рукопожатие добавляет протокольные round-trip-ы, которых транспорт избежать не может. Session-per-request платит эту цену на каждом запросе; пул платит её один раз на сессию и амортизирует. Детали реализации, решающие, реально ли пул работает: изоляция (пер-запросное состояние — суб-контекст внутри сессии, создаваемый и уничтожаемый под запрос, тогда как пер-сессионное состояние общее), размер пула (p95 одновременных с автомасштабированием под всплески), проверка здоровья (фоновые проверки на простаивающих сессиях, быстрые при назначении), и аффинитет запроса через sticky-сессии для инструментов, чьё состояние спанит через несколько вызовов. Поверх — мультиплексирование соединений HTTP/2 или HTTP/3 — одно подлежащее соединение, несущее много одновременных потоков — даёт цитируемые цифры пропускной способности; один только слой пула даёт куда меньшее улучшение. Хвостовая латентность имеет значение: у session-per-request-сервера длинные хвостовые латентности от неудачных моментов во время создания, у пула — тугие, потому что стоимость создания асинхронна вне горячего пути запроса. P99 обычно улучшается в три-четыре раза — больший выигрыш, чем пропускная способность, и тот, что реально формирует пользовательский опыт.

14.4 Что построила серия

Четыре тома прошли намеренную дугу. Том I был о внутренней стороне модели. Том II — о промптах и рассуждении. Том III — о retrieval-augmented generation. Этот том был об агентах и инструментах, организованный вокруг MCP, потому что MCP — техническая подложка, сделавшая агентную архитектуру связной. Через него прошли три нити. Первая — отделение когниции от операций: модель — когнитивный слой, фреймворк и MCP-серверы — операционный слой, и большинство продакшен-отказов происходят от схлопывания двух в одно. Вторая — конечный бюджет контекста: контекст — дефицитный ресурс, и архитектурные выборы, производящие надёжных агентов, — те, что уважают этот дефицит. Третья — протокол-как-граница: MCP не просто проводной формат, а граница, через которую текут возможности, через которую нужно согласовывать доверие, и через которую будет продолжать происходить будущая эволюция. Протокол, выдерживающий инженерное давление, становится инфраструктурой; MCP, похоже, ею становится.

Что подготавливает том IV

Это последняя глава тома, поэтому подготавливает она не следующую главу, а следующий том. Том V — Создание реальных LLM-приложений — берёт основания, заложенные через тома I–IV, и собирает их в конкретные архетипы приложений: ассистенты для инженерии ПО, агенты для бизнес-автоматизации, copilot-ы внутри вертикальных приложений, автономные исследовательские инструменты. Рассмотрение будет меньше о подлежащих механизмах (которые покрыли предыдущие тома) и больше об инженерных выборах прикладного уровня — как масштабировать LLM-приложение под надёжную поставку ценности, как оценивать его в продакшене, как управлять жизненным циклом промптов, инструментов и памяти по мере эволюции приложения. Читатель, завершивший том V, пройдёт путь от единственной головы внимания до развёрнутого приложения, прогоняющего агента над реальным стеком MCP-серверов на реальной инфраструктуре, — с инженерным суждением, чтобы знать, почему каждый слой был построен так, как был.

Серия продолжается в LLM Primer V — Создание реальных LLM-приложений.