Последовательность — это потерянное время
Возьмём типичную задачу: подготовить обзор по трём независимым подтемам — например, разобрать конкурентов A, B и C. Каждый разбор — это поиск, чтение, выжимка, скажем по несколько секунд (агент почти всё это время ждёт ответов от LLM и веба). Если один агент делает их по очереди, время складывается: A, потом B, потом C — итог равен сумме.
Но конкуренты друг от друга не зависят: чтобы разобрать B, не нужен результат по A. Значит, три разбора можно запустить одновременно — тремя агентами. Тогда общее время по «настенным часам» (wall-clock) станет равно не сумме, а самой долгой из частей. Это та же идея, что у asyncio.gather из модуля по Python, но на уровне команды агентов.
Агенты выигрывают от параллелизма потому, что они I/O-bound: бо́льшую часть времени ждут ответа LLM или сети. Пока агент A ждёт модель, агенты B и C тоже могут ждать своих моделей — одновременно. Это не ускоряет «мышление» каждого, но убирает простой. Для чисто вычислительных задач выигрыша бы не было.
Условие параллелизма: независимость
Параллелить можно только независимые задачи — те, где результат одной не нужен другой. Это ключевая проверка перед тем, как раздавать работу разным агентам.
- разбор трёх конкурентов
- перевод документа на 5 языков
- проверка текста на грамматику, факты и тон
- опрос N источников по одному вопросу
- сначала найти → потом проанализировать
- написать текст → затем его отредактировать
- план → исполнение шага → следующий шаг
- любая цепочка, где B берёт вход у A
На практике задачи редко бывают целиком параллельными или целиком последовательными — чаще это смесь: внутри пайплайна есть и зависимые этапы (идут по очереди), и независимые ветки (идут разом). Хороший дизайн команды распараллеливает то, что можно, и выстраивает в цепочку то, что нельзя.
Где параллелизм возникает в командах
В мультиагентных системах параллельная работа появляется в трёх характерных формах:
Обрати внимание: первая форма опирается на разделение ответственности из прошлого урока — именно потому, что роли независимы, их можно запустить разом. Параллелизм и специализация усиливают друг друга.
Точка сборки: кто-то должен дождаться всех
Параллельные ветки рано или поздно надо свести воедино. Появляется точка синхронизации — агент или шаг-агрегатор, который дожидается завершения всех веток и объединяет их результаты: склеивает разборы в общий отчёт, выбирает лучший вариант, считает голоса.
старт ├─▶ агент A ─┐ ├─▶ агент B ─┼─▶ агрегатор ─▶ итог └─▶ агент C ─┘ (параллельно) (ждёт всех)
Важное свойство: агрегатор стартует только когда закончилась самая медленная ветка — он не может собрать неполный результат. Поэтому общее время = (время самой долгой ветки) + (время сборки). Если одна ветка тормозит, она тормозит весь join — это называют «проблемой отстающего» (straggler).
Параллельные агенты редко выдают финальный результат «каждый сам по себе» — обычно их выводы надо объединить. Не забывай про этот шаг при проектировании: без агрегатора у тебя три отдельных куска, а не один ответ. И продумай, что делать, если одна ветка упала или зависла, — ждать вечно нельзя.
Пределы и цена параллелизма
Параллелизм ускоряет, но не бесплатно. Что важно держать в голове:
- Параллелится не всё. Зависимые этапы остаются последовательными — закон Амдала: ускорение ограничено долей работы, которую нельзя распараллелить.
- Стоимость токенов не падает. Три агента сделают столько же вызовов LLM, сколько один последовательный, — ты экономишь время, а не деньги. Суммарный расход тот же (а с ансамблем — даже больше).
- Rate limits. Сто параллельных агентов разом упрутся в лимиты API. Нужен потолок одновременности (как
max_concurrencyв модуле 03). - Сложность отладки. Параллельные трейсы переплетаются; понять, что и когда происходило, труднее — снова важна наблюдаемость.
Запомни главный размен: параллелизм покупает скорость ценой пиковой нагрузки (много одновременных запросов), но не снижает суммарную стоимость. Берут его там, где важна задержка для пользователя; если важнее всего дешевизна и время терпит — последовательное выполнение спокойнее.
Как это реализуется
Этот урок — про зачем. Как технически запускать узлы и агентов одновременно, мы подробно разобрали в модуле 03:
- Статический параллелизм (известное число веток) — fan-out/fan-in и супершаги: несколько рёбер из узла, агрегатор на сборке с reducer.
- Динамический (число веток в рантайме) — map-reduce через Send: по ветке на каждый элемент списка.
Фреймворки мультиагентов (AutoGen, CrewAI — следующие разделы) тоже умеют параллельную оркестрацию, но под капотом у них та же модель: независимые задачи → одновременный запуск → точка сборки.
Типичные ошибки
Если ветка B использует результат A, запустить их одновременно нельзя — B получит пустоту. Перед распараллеливанием проверь независимость.
Три параллельных агента без агрегатора дают три отдельных куска, а не ответ. Точка синхронизации, которая ждёт всех и объединяет, — обязательна.
Параллелизм экономит время, а не токены. Если цель — снизить расход, он не поможет; для скорости — да.
Сотни параллельных агентов с LLM-вызовами упрутся в rate-limit или память. Ставь потолок одновременных задач.
Шпаргалка
ИДЕЯ: независимые задачи → разным агентам разом
время: последовательно = СУММА → параллельно = MAX(части) + сборка
УСЛОВИЕ: независимость
✅ разные подтемы, перевод на N языков, опрос N источников
❌ A→B→C, где B берёт вход у A (цепочка зависимостей)
ФОРМЫ В КОМАНДАХ:
• разные подзадачи — специалисты делают разное одновременно
• fan-out по элементам — один агент на каждый элемент списка
• ансамбль / гонка — N агентов решают одно → лучший/голосование
ТОЧКА СБОРКИ (агрегатор):
• ждёт ВСЕ ветки (стартует после самой долгой)
• объединяет: склейка / выбор / голоса
• продумай отстающего (straggler) и упавшие ветки
ПРЕДЕЛЫ:
• параллелится не всё (закон Амдала)
• токены НЕ экономятся — экономится ВРЕМЯ
• rate limits → потолок одновременности (max_concurrency)
Механика → модуль 03: Parallelization (статика) / map-reduce (Send)
Практическое задание
Потренируй поиск параллелизма (упражнение на декомпозицию):
Задание: распараллель пайплайн
- Возьми задачу «подготовь сравнительный обзор 4 фреймворков». Распиши её как набор подзадач (по фреймворку: найти → разобрать; затем общий вывод; затем редактура).
- Отметь, какие подзадачи независимы (можно параллельно), а какие зависимы (только по очереди). Обоснуй каждую.
- Нарисуй схему: где fan-out на параллельных агентов, где точка сборки (агрегатор), где последовательные этапы.
- Прикинь время: сколько займёт чисто последовательный вариант и сколько — с распараллеливанием независимых частей. Где «потолок» ускорения (самая долгая ветка)?
- Подумай про отстающего: что если один из четырёх разборов завис? Как должен повести себя агрегатор?
- Со звёздочкой: добавь ансамбль — пусть финальный вывод делают два агента независимо, а третий выбирает лучший. Что это даёт и чего стоит?