Почему мультиагентные системы тормозят и что с этим делать

Пользователь нажимает «Отправить» и смотрит на спиннер 35 секунд. Внутри за это время оркестратор опросил планировщик, тот вызвал трёх исполнителей, каждый сходил в свою модель, один из них дважды дёрнул поиск, а финальный агент собрал всё в ответ. Каждый шаг сам по себе занимает 2-6 секунд, но выстроенные в цепочку они дают те самые 35. Латентность мультиагентной системы — это почти всегда не «модель медленная», а «мы построили последовательную цепочку там, где могла быть параллельная».

Откуда берётся задержка

Разложим типовой запрос по слагаемым. Числа ниже — порядки величин для облачных LLM среднего размера, они меняются от провайдера и нагрузки, но пропорции устойчивы.

• TTFT (time to first token)¹ — задержка до первого токена. Для крупных моделей это 0,3-1,5 с на каждый вызов, и она не зависит от длины ответа.
• Генерация токенов — скорость вывода. При 40-80 токенах в секунду ответ на 600 токенов — это 8-15 секунд чистой генерации.
• Сетевой round-trip — на каждый вызов API уходит от десятков до сотен миллисекунд, а при холодном соединении и TLS-хендшейке больше.
• Инструменты — поиск, вызов внешнего API, запрос к базе. Здесь разброс огромный: от 100 мс до нескольких секунд.
• Оркестрация — сериализация состояния, валидация схем, логирование. По отдельности мелочь, но в цикле из десятков шагов набегает.

Главная беда в том, что эти слагаемые складываются, а не идут параллельно. Пять агентов, вызванных строго друг за другом, дают сумму пяти самых медленных путей. И чем «умнее» вы делаете систему — добавляете рефлексию, самопроверку, повторный вызов при неуверенности — тем длиннее становится цепочка.

Где именно теряется время

Последовательность вместо параллелизма

Классический антипаттерн: оркестратор запрашивает у агента-исследователя факты, ждёт ответ, потом передаёт агенту-аналитику, ждёт, потом агенту-редактору. Если эти три роли не зависят друг от друга — а часто исследователь и аналитик могут работать по одному входу параллельно, — вы теряете время на ровном месте.

Латентность мультиагентной системы почти никогда не равна времени работы самого медленного агента. Она равна сумме всех агентов на критическом пути. Ваша задача — сделать критический путь короче, а не агентов быстрее.

Раздутый контекст

Каждый агент часто получает на вход всю историю диалога плюс результаты предыдущих шагов. Контекст растёт, растёт TTFT, растёт стоимость. Агент, которому нужен один параметр, получает 12 тысяч токенов «на всякий случай» и обрабатывает их дольше.

Лишние раунды рассуждений

Паттерны reflection и self-critique удваивают или утраивают число вызовов. Иногда это оправдано, чаще — нет. Если агент и так уверенно отвечает в 90% случаев, гонять рефлексию на всех — это платить латентностью за 10% пограничных ситуаций.

Холодные старты и очереди

Если агенты живут в serverless-функциях, первый вызов после простоя добавляет секунды на инициализацию рантайма. Плюс очереди у провайдера модели в часы пик — та же модель, что ночью отдаёт первый токен за 0,4 с, днём может отдавать за 2 с.

Что с этим делать

По убыванию отдачи на вложенные усилия:

1. Распараллельте независимые ветки. Определите, какие агенты не зависят от результатов друг друга, и запускайте их одновременно (asyncio.gather, промисы, любой ваш примитив конкурентности). Это самая большая одномоментная победа.
2. Стримьте ответ пользователю. Даже если внутри ещё идёт работа, финальный агент может отдавать токены по мере генерации. Воспринимаемая задержка падает в разы, хотя суммарное время то же.
3. Режьте контекст. Передавайте каждому агенту только то, что ему нужно. Суммаризируйте промежуточные результаты вместо того, чтобы таскать сырые логи.
4. Стройте маршрутизацию по сложности. Простые запросы — на маленькую быструю модель без оркестрации вообще. Полный пайплайн запускайте только когда роутер решил, что задача этого стоит.
5. Кэшируйте. Промпт-кэш у провайдера снижает TTFT для повторяющихся системных промптов. Семантический кэш ответов ловит одинаковые по смыслу запросы.
6. Ставьте бюджеты и таймауты. Ограничьте число раундов рефлексии и время на инструмент. Медленный агент не должен блокировать весь ответ.

Как выглядит выигрыш от параллелизма

Простой набросок на Python: три независимых агента последовательно против того же набора параллельно.

import asyncio, time

async def agent(name, seconds):
    await asyncio.sleep(seconds)  # имитация вызова модели
    return f"{name} готов"

# Последовательно: 2 + 3 + 2.5 = 7.5 c
async def sequential():
    t = time.perf_counter()
    await agent("research", 2)
    await agent("analyze", 3)
    await agent("draft", 2.5)
    return time.perf_counter() - t

# Параллельно: max(2, 3, 2.5) = 3 c
async def parallel():
    t = time.perf_counter()
    await asyncio.gather(
        agent("research", 2),
        agent("analyze", 3),
        agent("draft", 2.5),
    )
    return time.perf_counter() - t

print(asyncio.run(sequential()))  # ~7.5
print(asyncio.run(parallel()))    # ~3.0

Разница — 7,5 против 3 секунд на одних и тех же вызовах. Оговорка: параллелить можно только по-настоящему независимые шаги. Если draft зависит от analyze, вы связаны их последовательностью, и остаётся только резать каждый из них.

Чем измерять

Оптимизировать вслепую — значит гонять латентность из одного места в другое. Прежде чем что-то менять, нужна трассировка каждого шага.

Смотрите на p95 и p99, а не на среднее. Пользователь, попавший в 5% медленных запросов, судит о продукте именно по своему опыту, а не по вашей красивой медиане.

¹ TTFT (time to first token) — время от отправки запроса до появления первого токена ответа. Отражает задержку до начала генерации: постановку в очередь, обработку промпта (prefill) и сеть. От TTFT зависит, как быстро пользователь видит, что «что-то происходит».