Я спроектировал архитектуру команды из 9 ИИ-агентов, где каждый агент — это отдельная open-source модель, подобранная под конкретную роль по бенчмаркам. Цель — полный цикл генерации агентов: от пользовательского запроса до кода с тестами и security review.

Дисклеймер: это исследование и проектирование архитектуры, а не готовый продукт. Дашборд — визуализация на статических данных. Playground с живым инференсом на кластере — следующий этап. Статья отвечает на вопрос «какую модель на какую роль и почему» — не на вопрос «вот оно работает в проде».

Ниже — конкретика: какие модели, на какие роли, почему именно эти, как они шарят GPU, сколько стоят в гигабайтах и какие бенчмарки реально определяют выбор. С конфигурациями развёртывания от одной RTX 4090 до кластера A100.

TL;DR: 9 логических агентов = 3-4 физических модели. Минимальный сетап — 24 GB VRAM (одна RTX 4090). Полный продакшен — 211 GB (четыре A100). Интерактивный дашборд для визуализации маппинга роль→модель→GPU.

---

Зачем 9 агентов вместо одного GPT-5

Первый вопрос, который задают: зачем 9 моделей, когда можно одну большую?

Ответ в бенчмарках. У каждой модели есть суперсила — и слабое место:

Ни одна модель не покрывает всё. Kimi K2.5 — бог HumanEval, но весит 125 GB и посредственно чинит реальные баги. Qwen3.5-397B — лучший reasoning, но не лучший кодер. GLM-4.7 — единственная модель с по-настоящему хорошим tool use — и она вообще не про кодогенерацию. DeepSeek V3.2 — везде в топ-5, но нигде не первый.

Не бывает «лучшей модели». Бывает лучшая модель для конкретной роли. Классическая софтверная команда — это специализация: аналитик не пишет код, тестировщик не проектирует архитектуру. С LLM — то же самое.

---

Архитектура: от запроса до деплоя

Вот как устроен пайплайн. Пользователь говорит: «Сделай мне агента поддержки, который интегрируется с Jira», и дальше:

User Request
     │
     ▼
[1. Оркестратор] ─── декомпозиция задачи, маршрутизация
     │
     ├──► [2. Аналитик] ─── ARD (Agent Requirement Document)
     │         │
     │         ▼
     ├──► [3. Исследователь] ─── Context Package (API, доки, паттерны)
     │         │
     │         ▼
     ├──► [4. Архитектор] ─── TDD (Technical Design Document)
     │         │
     │         ▼
     ├──► [5. Промпт-инженер] ─── Prompt Package (системный промпт, guardrails, tool configs)
     │         │
     │         ▼
     ├──► [6. Билдер] ─── код агента + конфигурации
     │         │
     │         ▼
     │    [7. Тестировщик] ─── тесты провалены?
     │         │         │
     │         │ да      │ нет
     │         ▼         ▼
     │    [6. Билдер]   [8. Критик] ─── «это хорошо сделано?»
     │    (fix & retry)       │
     │                        ▼
     └──────────────► [9. Безопасник] ─── Security Audit
                              │
                              ▼
                     Production-ready Agent

Каждый агент коммуницирует через структурированные артефакты (ARD, TDD, Prompt Package), а не через свободный текст. Это критично: передача контекста через free-form текст между агентами — это «испорченный телефон» в квадрате. Артефакты со строгой схемой решают эту проблему.

Два обязательных feedback loop:

• Builder ↔ Tester: код не считается готовым, пока тесты не пройдены

• Builder ↔ Critic: тесты могут пройти, но код при этом быть плохим — Критик ловит именно это

---

9 ролей: детальный маппинг модель → задача

Теперь — самое интересное. Для каждой роли я выбрал модель по принципу: какой бенчмарк критичен для этой роли, и кто в нём лидер.

1. Оркестратор — Qwen3.5-397B (17B active)

Мозг системы. Принимает запрос, декомпозирует на подзадачи, маршрутизирует между агентами, собирает результат.

Критические бенчмарки: GPQA (глубокое рассуждение) и IFEval (точность следования инструкциям).

Почему Qwen3.5-397B: лучший GPQA 88.4% среди всех open-source + лучший IFEval 92.6%. Оркестратор должен точно понимать, что хочет пользователь, и умно решать, кому делегировать. Любая ошибка оркестратора ломает весь пайплайн по цепочке.

397 миллиардов параметров, но благодаря MoE активны только 17B на каждый токен. ~50 GB VRAM в INT4.

Бюджет: QwQ-32B (16 GB) — сильный reasoning при 32B dense.

2. Аналитик требований — Qwen3-8B

Превращает расплывчатый запрос пользователя в структурированный ARD.

Для этой роли не нужен deep reasoning или кодогенерация — нужно хорошо понимать intent и формировать structured output. Qwen3-8B с его thinking/non-thinking mode — оптимальный баланс: достаточно умный для анализа требований, достаточно лёгкий (4 GB), чтобы не отъедать GPU у более требовательных ролей.

3. Исследователь — Qwen3.5-397B (shared с Оркестратором)

Собирает контекст до проектирования: существующие решения, API-документация, reference implementations.

Шарит инстанс с Оркестратором — они никогда не работают одновременно. Оркестратор делегирует и ждёт, пока Исследователь закончит. Ноль дополнительных GPU.

Альтернатива, когда нужен огромный контекст: Llama 4 Scout с окном 10M токенов.

4. Архитектор — DeepSeek V3.2 (37B active, 685B total)

Проектирует систему: компоненты, API, data flow, error handling, выбор фреймворка.

Критические бенчмарки: нужен одновременно и хороший reasoning, и понимание кода.

Почему V3.2: MMLU-Pro 85.0 (широкая эрудиция) + SWE-bench 73.1% (понимает реальные кодовые базы) + LiveCodeBench 83.3. Это единственная модель в топ-5 одновременно по reasoning И coding бенчмаркам. ~85 GB в INT4.

Бюджет: DeepSeek-R1-Distill-Qwen-32B (16 GB) — MATH-500 94.3, CodeForces 1691.

5. Промпт-инженер — Qwen3.5-397B (shared с Оркестратором)

Создаёт системные промпты, guardrails, few-shot examples, tool configurations.

Логика выбора: модель с лучшим IFEval (92.6%) лучше всех понимает, что делает инструкции эффективными. Она знает, как LLM реагируют на формулировки — потому что сама лучше всех им следует. Шарит инстанс с Оркестратором.

6. Билдер — Qwen2.5-Coder-32B (dense)

Пишет код. Много кода. Быстро.

Специализированная coding-модель. HumanEval 92.7% (уровень GPT-4o), Aider 73.7 (polyglot — работает с разными языками и фреймворками). Dense-модель — предсказуемое качество, нет MoE-джиттера.

При INT4 — всего 16 GB. Влезает на одну consumer-карточку.

Бюджет: Qwen2.5-Coder-7B (4 GB) — HumanEval 88.4, бьёт CodeStral-22B.
Перспектива: Qwen3-Coder-Next (3B active, 80B total) — SWE-bench 70.6% при 10 GB.

7. Тестировщик — Devstral Small 2 (24B dense)

Генерирует тесты, ищет edge cases, валидирует acceptance criteria из ARD.

Ключевое: SWE-bench 68.0%. Эта модель обучена на real-world software engineering задачах. Она понимает не изолированные функции, а целые кодовые базы — контексты, зависимости, интеграции. 12 GB в INT4.

Бюджет: Falcon H1R-7B (4 GB) — AIME 83.1% reasoning при 7B. Маленькая, но думает как большая.

8. Критик — GLM-4.7 (32B active, 355B total)

Оценивает результат не по принципу «тесты прошли», а «это хорошо сделано»: качество кода, ясность промптов, надёжность guardrails, соответствие архитектуре.

Критический бенчмарк: tau-bench — оценка качества tool use в реальных сценариях. GLM-4.7: 87.4% — лучший показатель среди всех open-source моделей. Критик должен понимать, как агенты используют инструменты, и оценивать качество этого использования.

44 GB в INT4.

Бюджет: Ministral 14B Reasoning (7 GB) — AIME ~85%, GPQA 71.2.

9. Безопасник — DeepSeek V3.2 (shared с Архитектором)

Prompt injection, утечки данных, избыточные permissions, API key management, adversarial тестирование.

Шарит инстанс с Архитектором — они работают в разных фазах пайплайна (Архитектор до кода, Безопасник после). Широкая база знаний (MMLU-Pro 85.0) + понимание кода = adversarial thinking.

Бюджет: DeepSeek-R1-Qwen3-8B (4 GB) — AIME 87.5% reasoning. Adversarial thinking за 4 гигабайта.

---

Шаринг инстансов: 9 агентов ≠ 9 GPU

Это, пожалуй, главный архитектурный трюк. Агенты работают последовательно в пайплайне: пока Билдер пишет код, Оркестратор ждёт. Пока Тестировщик проверяет — Билдер свободен.

Модели, которые никогда не работают одновременно, разделяют один инстанс:

Итого: 9 логических агентов → 5 физических инстансов → 207 GB VRAM.

Для бюджетного варианта (3 модели, 5 агентов) — 24 GB. Одна RTX 4090.

---

Бенчмарки, которые реально определяют выбор

Забудьте про MMLU и HellaSwag — они давно упёрлись в потолок, лидерборды стоят на месте. В 2026 году для агентных систем критичны совсем другие метрики:

Источники: SWE-bench Verified, LiveBench, Berkeley Function Calling Leaderboard V4, Aider LLM Leaderboards, LMSYS Arena.

---

MoE: почему frontier-качество стало доступным

Mixture-of-Experts — главное архитектурное изменение, сделавшее этот проект возможным. Объясню на конкретных числах:

Как это работает: Все 397B параметров загружены в VRAM, но на каждый токен работает маленькая часть — 17B. Это как офис на 400 человек, где над каждой задачей работают 17, но каждый раз — другие 17 специалистов.

Для VRAM это значит: вы платите за хранение всех параметров (VRAM = total params). Но при вычислениях платите за инференс только активных (скорость ≈ dense-модель размера active params).

Для агентной фабрики, где агенты работают последовательно, MoE идеален:

• VRAM заняты, но один инстанс обслуживает 4 роли

• Compute на токен — как у 17B-модели, а не 397B

• Качество — frontier-уровня

Именно MoE позволяет запустить 9 агентов frontier-качества на нескольких GPU.

---

Self-hosted vs. API: честное сравнение

Реальные цены API (март 2026)

Сначала — факты. Open-source модели доступны через API-провайдеров по ценам, которые делают self-hosting экономически невыгодным при малых объёмах:

Один агентный запрос (9 агентов, ~100K input + ~30K output суммарно) обходится в $0.03-0.15 через API — не $0.50-2.00, как было бы на проприетарных моделях (Claude Opus / GPT-5). При 10-50 запросах в день — это $0.30-7.50/день. OpenRouter даёт 1000 бесплатных запросов в день при балансе от $10.

Вывод: для MVP и прототипирования API дешевле self-hosting. Покупать GPU ради экономии на API — нерентабельно при малых объёмах.

Когда self-hosting оправдан

Self-hosting начинает иметь смысл при:

1. Latency. Оркестратор на критическом пути каждого запроса. Каждый вызов API — сетевой roundtrip (50-200ms). При 5-10 внутренних вызовах на запрос задержки складываются в 0.5-2 секунды только на сеть. На локальном железе — UNIX socket или shared memory.

2. Приватность данных. Если агенты работают с внутренней документацией, кодом, credentials — отправлять это через сторонний API может быть неприемлемо. Self-hosting = данные не покидают периметр.

3. Независимость от rate limits. API-провайдеры ставят ограничения на запросы в секунду. Агентный пайплайн из 9 агентов генерирует пачки запросов — на бесплатных тирах это проблема. Своё железо = нет лимитов.

4. Объём. При 500+ запросах в день self-hosting на существующем кластере (если GPU уже есть и простаивают) становится дешевле API.

Слон в комнате: скорость инференса

Честно о throughput. Qwen3.5-397B на одной A100 в INT4 выдаёт ~7-15 tok/s. Один агентный запрос через пайплайн из 9 агентов генерирует суммарно ~100-200K токенов. При 10 tok/s это 3-6 часов на один запрос.

Для сравнения: тот же Qwen3.5-397B через API (OpenRouter) отвечает за секунды, потому что провайдер раскидывает модель на десятки GPU с tensor parallelism.

Что это значит на практике:

Вывод: self-hosting на MoE-гигантах — это batch-режим, не интерактивный. Для «ввёл запрос — получил агента через 10 минут» нужен либо API, либо 8+ GPU с tensor parallelism, либо компромисс на качестве (QwQ-32B вместо 397B). Статья описывает архитектуру, а не «запустил и всё летает» — и throughput это главная причина, по которой практическая валидация ещё впереди.

Паритет качества

Open-source модели в марте 2026 достигли паритета с проприетарными:

Все модели — MIT или Apache 2.0. Зависимость от проприетарных API больше не оправдана разницей в качестве — но может быть оправдана удобством и стоимостью инфраструктуры при малых объёмах.

---

Развёртывание: от домашнего GPU до продакшена

Конфигурация A: MVP на одной карточке

5 агентов, 3 модели, 24 GB VRAM. Влезает на RTX 4090 (24 GB) или RTX 5090 (32 GB):

На A100 (80 GB) те же модели оставляют ~56 GB свободных под KV cache — можно обрабатывать длинные контексты без свопа.

Ограничения MVP: QwQ-32B вместо Qwen3.5-397B — заметно слабее reasoning (нет frontier-уровня GPQA/IFEval). Coder-7B вместо Coder-32B — проще код, меньше языков. Это proof-of-concept, не продакшен.

Конфигурация B: Quality Team (2x A100 80GB)

7 агентов, 4 модели, 73 GB VRAM:

┌──────────────────────────┐  ┌──────────────────────────┐
│    GPU 1 (80 GB)         │  │    GPU 2 (80 GB)         │
│                          │  │                          │
│  Qwen3.5-397B (~50 GB)   │  │  Qwen2.5-Coder-32B       │
│  → Оркестратор           │  │  (16 GB)                 │
│  → Аналитик              │  │  → Билдер                │
│  → Промпт-инженер        │  │  → Тестировщик (shared)  │
│  → Исследователь         │  │  → Безопасник (shared)   │
│                          │  │                          │
│  Ministral 14B (~7 GB)   │  │  Свободно: ~64 GB        │
│  → Критик                │  │                          │
└──────────────────────────┘  └──────────────────────────┘

Появляется frontier-качество Оркестратора (Qwen3.5-397B вместо QwQ-32B), отдельный Критик и Промпт-инженер.

Конфигурация C: Full Production (4x A100 80GB)

9 агентов, 6 моделей, все «best picks», 211 GB VRAM:

┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ GPU 1 (80GB)     │ │ GPU 2 (80GB)     │ │ GPU 3 (80GB)     │ │ GPU 4 (80GB)     │
│                  │ │                  │ │                  │ │                  │
│ Qwen3.5-397B     │ │ DeepSeek V3.2    │ │ Qwen2.5-Coder    │ │ GLM-4.7          │
│ ~50 GB           │ │ ~85 GB           │ │ -32B ~16 GB      │ │ ~44 GB           │
│                  │ │                  │ │                  │ │                  │
│ Оркестратор      │ │ Архитектор       │ │ Билдер           │ │ Критик           │
│ Аналитик         │ │ Безопасник       │ │                  │ │                  │
│ Исследователь    │ │                  │ │ Devstral 24B     │ │ Falcon H1R-7B    │
│ Промпт-инженер   │ │                  │ │ ~12 GB           │ │ ~4 GB            │
│                  │ │                  │ │                  │ │                  │
│                  │ │                  │ │ Тестировщик      │ │ Router/Eval      │
└──────────────────┘ └──────────────────┘ └──────────────────┘ └──────────────────┘

Каждая роль получает оптимальную модель. Все feedback loops работают с лучшими пиками.

---

Квантизация: что, чем и зачем

A100 не поддерживает FP8 нативно (в отличие от H100/B200), поэтому INT4 — основной формат.

Marlin kernels — ключевая оптимизация для A100: 10.9x ускорение INT4 инференса. Без Marlin INT4 на A100 работает медленнее, чем FP16 — потому что A100 нативно не оптимизирована под INT4.

Правило: Q5_K_M для Оркестратора/Архитектора/Критика (quality-critical), Q4_K_M для Билдера/Тестировщика (throughput-critical).

---

Инфраструктура инференса

SGLang особенно важен для агентных систем: его RadixAttention хранит KV cache между multi-turn вызовами агентов. Когда Оркестратор многократно обращается к модели в рамках одной задачи, каждый вызов переиспользует кеш предыдущих — экономия compute до 40-60% на повторных обращениях.

Архитектура деплоя: одна модель на GPU (или MIG-партицию). Не пытайтесь запускать несколько моделей на одном GPU одновременно — тулинг для этого ещё незрел. Неактивные модели — на CPU offload.

---

Tier S: ландшафт open-source моделей (март 2026)

Для контекста — вот полная картина лидеров, из которых я выбирал:

Все Tier S модели — из китайских лабораторий: Alibaba (Qwen), DeepSeek, Zhipu (GLM), Moonshot (Kimi), MiniMax. Все — MIT или Apache 2.0. Это новая реальность open-source AI.

---

Принципы проектирования агентной фабрики

Шесть правил, выведенных из исследований Anthropic, MetaGPT, metaswarm и собственных экспериментов:

1. Точное делегирование вместо «разбирайся сам». Каждый агент получает: цель, формат вывода, доступные инструменты, границы задачи. Исследование Anthropic показало, что размытое делегирование — главная причина провала multi-agent систем.

2. Spec-driven, не code-driven. ARD и TDD — первичные артефакты. Код — производный. Если спецификация правильная, код генерируется надёжно. Если спецификация плохая, никакой билдер не спасёт.

3. Обязательные feedback loops. Builder ↔ Tester и Builder ↔ Critic — неотключаемые циклы. «Я написал код, тесты пройдены» — это необходимое, но не достаточное условие качества.

4. Минимальный доступ. Сгенерированные агенты получают только необходимые permissions. Security Auditor — не опциональная роль. Агент с доступом к API и credentials — это высокорисковый артефакт.

5. Fail fast. Если агент не может выполнить задачу — он немедленно сообщает об этом Оркестратору. Никакого «сделаю плохо, но сделаю». Низкокачественный артефакт хуже, чем отсутствие артефакта — он портит всё дальше по цепочке.

6. Сохранение артефактов. Все промежуточные артефакты сохраняются. Это не опция — это обязательное условие. Без этого нет debugging, нет rollback, нет обучения из ошибок.

---

Интерактивный дашборд

Всё это визуализировано в интерактивном дашборде:

• RolePanel — 9 ролей, клик для выбора

• NeuralTopology — визуальная карта связей между агентами

• ModelMatrix — сортируемая таблица 14+ моделей с бенчмарками, подсветкой рекомендаций

• ComputePlan — конфигуратор GPU (A100 / H100 / B200): VRAM, bandwidth, стоимость, tokens/sec

Это единственный инструмент, который соединяет все три слоя:

Роль агента → Лучшая open-source модель → Конфигурация GPU

HuggingFace Leaderboard даёт бенчмарки, но не маппинг на роли. CrewAI/LangGraph даёт фреймворки, но не выбор моделей. Этот дашборд отвечает на вопрос, который задаёт каждая команда, строящая агентов: «Какую модель на какую роль? Сколько GPU нужно?»

---

Tool calling: уже не самое слабое место

В первой версии статьи я писал, что tool use — слабое звено open-source. Это устарело. Вот актуальные данные по τ²-Bench (март 2026):

Источники: τ²-Bench, Step 3.5 Flash paper, BFCL v4.

Разрыв между лучшим проприетарным (92.5) и лучшим open-source (88.2) — 4.3%. Полгода назад он был ~10%. Tool calling перестаёт быть блокером.

Structured Outputs как альтернатива

Отдельно стоит упомянуть подход Structured Outputs — режим, гарантирующий валидный JSON на выходе. Для агентного пайплайна, где каждый агент передаёт структурированные артефакты следующему, это может быть надёжнее, чем общий function calling.

• OpenAI gpt-oss-120b (117B / 5.1B active, Apache 2.0) — поддерживает Structured Outputs нативно, помещается на одну A100. HuggingFace

• gpt-oss-20b (21B / 3.6B active) — для consumer GPU (16 GB). HuggingFace

Недостаток: гарантированный structured output — фича конкретных моделей, а не универсальный стандарт. Привязка к экосистеме.

Рекомендация для продакшена

Fine-tune на своих tool schemas. Общий function calling — это «знание языка», но ваши конкретные API — это «знание жаргона». Модели быстро учатся на десятках примеров реальных инструментов. А для MVP — Step 3.5 Flash бесплатно на OpenRouter уже даёт 88.2% на τ²-Bench.

---

Что из этого следует

Компоненты для сборки multi-agent систем на open-source моделях есть:

• Модели — frontier-уровня, MIT-лицензия, все на HuggingFace

• Инфра — SGLang/vLLM/Ollama, от consumer GPU до серверных кластеров

• Паттерны — orchestrator-worker, artifact-based communication, feedback loops

• Экономика — MoE дал frontier-качество при доступных вычислительных затратах

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

Что осталось — валидировать это на практике. Следующий шаг — playground на кластере с реальными прогонами и метриками: сколько времени занимает полный цикл, какое качество генерируемого кода, где пайплайн ломается. Когда будут результаты — напишу отдельный пост.

---

Все модели доступны на HuggingFace. Бенчмарки взяты с SWE-bench Verified, LiveBench, BFCL v4, Aider Leaderboards, LMSYS Arena (февраль–март 2026). Интерактивный дашборд: agent-factory-design.

Исследования: Anthropic Multi-Agent Systems, MetaGPT (ICLR 2024), metaswarm.