Meta AI представила Matrix — децентрализованный фреймворк для синтетической генерации данных, в котором управление и данные сериализованы в сообщения, перемещающиеся по распределённым очередям. Это решение разработано для поддержки современных моделей, которые всё чаще обучаются на синтетических диалогах, трассах вызовов инструментов и цепочках рассуждений. По заявлению разработчиков, Matrix обеспечивает от двух до пятнадцати раз большую пропускную способность по токенам на реальных нагрузках при сохранении сопоставимого качества выходных данных.
Традиционные фреймворки агентов хранят состояние рабочих процессов и логику управления в центральном оркестраторе, через который проходят все вызовы агентов, инструментов и повторные попытки. Такая модель удобна для отладки, но плохо масштабируется при попытке одновременно поддерживать десятки тысяч параллельных синтетических диалогов или траекторий использования инструментов.
Matrix использует иной подход: и поток управления, и поток данных представляются объектом-сообщением, называемым оркестратором. Оркестратор содержит состояние задачи, включая историю диалога, промежуточные результаты и логику маршрутизации. Стейтлес-агенты, реализованные как Ray-акторы, извлекают оркестратор из распределённой очереди, выполняют роль-специфичную логику, обновляют состояние и отправляют сообщение следующему агенту, выбранному оркестратором.
Во внутреннем цикле отсутствует центральный планировщик: каждая задача продвигается независимо на уровне строк (row-level), а не ожидает барьеров пакетной обработки, как это происходит в Spark или Ray Data. Такая архитектура уменьшает простой при вариативной длине траекторий и делает обработку сбоев локальной — падение одного оркестратора не блокирует всю партию задач.
Matrix работает на кластере Ray, обычно запускаемом через SLURM; Ray обеспечивает распределённые акторы и очереди. Ray Serve разворачивает LLM-эндпойнты поверх vLLM и SGLang и при необходимости маршрутизирует запросы к внешним API через прокси-сервера. Это позволяет интегрировать разные бекэнды инференса в единую систему обслуживания запросов.
Вызовы инструментов и сложные сервисы выполняются внутри контейнеров Apptainer, что изолирует среду агентов от песочниц для выполнения кода, HTTP-инструментов и кастомных оценщиков. Управление конфигурацией ролей агентов, типов оркестраторов и распределения ресурсов ведёт Hydra. Метрики кластера и очередей собираются в Grafana для мониторинга длины очередей, отложенных задач, пропускной способности по токенам и загрузки GPU в реальном времени.
Для снижения сетевой нагрузки Matrix вводит выгрузку сообщений: когда история диалога превышает порог, большие полезные нагрузки сохраняются в объектном хранилище Ray, а в оркестраторе остаются только идентификаторы объектов. Это уменьшает потребление пропускной способности кластера, при этом агенты могут реконструировать подсказки по необходимости.
В одном из кейсов, Collaborative Reasoner (Coral), где два LLM-агента ведут обсуждение и приходят к финальному ответу, Matrix переосмыслил протокол, заменив централизованный контролёр p2p-оркестраторами и стейтлес-агентами. На конфигурации с 31 узлом A100 и моделью LLaMA 3.1 8B Instruct система была настроена на 248 GPUs с 50 запросами на GPU (итого около 12 400 параллельных разговоров). При одинаковом оборудовании Matrix сгенерировала примерно 2 миллиарда токенов за ~4 часа, тогда как базовый Coral выдал около 0,62 миллиарда токенов за ~9 часов, что соответствует увеличению пропускной способности приблизительно в 6,8 раза при почти одинаковой точности соглашения (~0,47).
В задаче NaturalReasoning Matrix моделирует пайплайн из трёх агентов: фильтр, скорер и агент для извлечения вопросов и цепочек рассуждений. Фильтр использует более лёгкую модель для отбора английских фрагментов с потенциалом рассуждений, скорер применяет более крупную инструкционно настроенную модель для оценки качества, а агент вопросов извлекает пары «вопрос‑ответ» и связанные рассуждения. Из 25 миллионов документов DCLM примерно 5,45% прошли все фильтры, что дало около 1,19 миллиона пар «вопрос‑ответ» с шагами рассуждений.
Для экспериментов на подмножестве в 500 тысяч документов оптимальная конфигурация сочетала параллелизм по данным и по задачам: 20 разделов данных и 700 параллельных задач на раздел, что дало ≈1,61× повышение пропускной способности по сравнению с настройкой только по конкарренси задач. При полном прогоне по 25 миллионам документов Matrix достигла примерно 5 853 токенов в секунду против 2 778 токенов в секунду у пакетного baseline на Ray Data с 14 000 параллельных задач, то есть выигрыш ≈2,1×, обусловленный peer‑to‑peer планированием на уровне строк.
В бенчмарке Tau2‑Bench, моделирующем сценарий поддержки клиентов с использованием инструментов и базы данных, Matrix представляет среду четырьмя агентами: симулятором пользователя, ассистентом, исполнителем инструментов и калькулятором вознаграждений, а также сборщиком метрик. API инструментов и логика вознаграждений переиспользованы из эталонной реализации и обёрнуты в контейнеры. На кластере с 13 узлами H100 и десятками реплик LLM Matrix сгенерировала 22 800 траекторий примерно за 1,25 часа (~41 000 токенов/с). Базовая реализация Tau2 на одном узле с 500 потоками достигала около 2 654 токенов/с и 1 519 траекторий; среднее вознаграждение осталось сопоставимым, что подтверждает, что рост производительности не достигался за счёт упрощения среды. В результате Matrix продемонстрировала ≈15,4× повышение пропускной способности по токенам на этом бенчмарке.
Matrix заменяет централизованные оркестраторы на p2p архитектуру, где каждую задачу рассматривают как независимую конечную машину состояний, перемещающуюся между стейтлес-агентами посредством сообщений. Такой подход снижает накладные расходы координации и улучшает разнообразие и использование вычислительных ресурсов.
Фреймворк построен на открытом стеке — SLURM, Ray, vLLM, SGLang и Apptainer — и спроектирован для масштабирования до десятков тысяч параллельных мультиагентных рабочих процессов для генерации синтетических данных, оценки и обработки данных. Это позволяет применять систему в широком спектре задач без привязки к проприетарным компонентам.
По результатам трёх рассмотренных кейсов, Collaborative Reasoner, NaturalReasoning и Tau2‑Bench, Matrix обеспечивает от примерно 2× до 15,4× больше токенов в секунду по сравнению со специализированными базовыми решениями при идентичном оборудовании, сохраняя сопоставимое качество выходов и метрик вознаграждения. Существенная часть выигрыша оценивается как следствие системного дизайна, а не изменений архитектур моделей.
Важной практической оптимизацией является выгрузка больших историй диалогов в объектное хранилище Ray с сохранением в оркестраторах лишь лёгких ссылок на эти объекты. Это уменьшает пиковую сетевую нагрузку и поддерживает высокую пропускную способность при обслуживании LLM через gRPC‑ориентированные модельные бекэнды.
В целом Matrix представляет собой прагматичный системный вклад, переводящий мультиагентную генерацию синтетических данных из набора специализированных скриптов в эксплуатационную среду. Кодирование потока управления и данных в оркестраторы и исполнение в стейтлес p2p‑агентах на Ray разграничивает задачи планирования, инференса моделей и работы с инструментами. Представленные кейсы показывают, что тщательное проектирование системы теперь является ключевым рычагом для масштабирования пайплайнов синтетических данных.
Комментариев