Тест производительности Qwen3.5-35B в multi-agent задачах: почему он справился, а другие sub-100B модели — нет

Когда multi-agent системы превращаются в клоунаду

Ты настраиваешь цепочку агентов. Менеджер должен ставить задачи, разработчик - писать код, тестировщик - проверять. В теории звучит красиво. На практике получается диалог слепых. Менеджер генерирует бредовое ТЗ, разработчик пишет код, который не компилируется, а тестировщик хвалит работу, которую даже не запускал. Я видел это десятки раз.

Проблема не в frameworks - LangGraph, CrewAI и AutoGen стали достаточно зрелыми к 2026 году. Проблема в мозгах. В моделях, которые должны эти агенты оживлять. Большинство sub-100B моделей (те, что меньше 100 миллиардов параметров) просто не способны к последовательному, многошаговому рассуждению в команде. Они либо теряют контекст, либо начинают галлюцинировать, либо впадают в бесконечные циклы.

Эксперимент: семь моделей, один победитель

Я взял семь популярных sub-100B моделей, доступных на 28 февраля 2026 года, и запустил их через идентичный multi-agent workflow. Цель: создать простой веб-сервис на FastAPI для конвертации валют с кэшированием, включая написание кода, тестов и документации.

Qwen3.5-35B не просто выполнил задачу. Он сделал это с первой попытки, без ручного вмешательства. Агенты координировались, код компилировался, тесты проходили, документация была на месте. Почему? Не из-за размера - у него на 35 миллиардов параметров меньше, чем у провалившегося Llama 3.2 70B. И вот здесь начинается самое интересное.

Секретное оружие: reasoning effort и архитектура, которая не тупит

В Qwen3.5 команда Alibaba добавила параметр reasoning_effort, который на самом деле работает. Это не маркетинговая пустышка. Когда ты устанавливаешь reasoning_effort=8 (максимум), модель тратит дополнительные вычислительные ресурсы на планирование и самопроверку перед каждым действием. Она буквально думает: "А правильно ли я понял задачу? Что сделали предыдущие агенты? Какая следующая логическая ступень?"

Остальные модели либо не имеют такого параметра, либо он игнорируется в multi-agent контексте. Они выплевывают первый пришедший в голову ответ, не заботясь о согласованности цепочки.

Второй фактор - архитектура. Qwen3.5 использует улучшенный механизм внимания с более длительной памятью о межагентном взаимодействии. Когда разработчик получает задачу от менеджера, модель помнит не только текст задачи, но и контекст всей сессии: какие цели были поставлены изначально, какие ограничения упомянуты. В нашей статье про MoE-модели мы уже разбирали, как разреженные архитектуры выигрывают у плотных в multi-task сценариях.

1 Как повторить этот тест: железо и софт

Тебе не нужен суперкомпьютер. Я запускал тесты на системе с RTX 4090 (24GB VRAM) и 64GB RAM. Для Qwen3.5-35B в формате GGUF Q6_K этого хватает с запасом. Используй Ollama версии 0.5.6 (актуально на 28.02.2026) - она поддерживает параметр reasoning_effort для Qwen через модифицированный llama.cpp бэкенд.

# Устанавливаем и запускаем Ollama (если еще нет)
curl -fsSL https://ollama.ai/install.sh | sh

# Скачиваем Qwen3.5-35B в квантованном формате
ollama pull qwen3.5:35b-q6_K

# Проверяем, что модель загружена
ollama list

2 Настраиваем multi-agent workflow на LangGraph

Я использовал LangGraph 0.3.1 - на эту дату это стабильная версия с хорошей поддержкой Ollama. Не бери версию ниже 0.2.8 - там были баги с управлением состоянием в длинных цепочках.

from langgraph.graph import StateGraph, END
from typing import TypedDict
import subprocess
import ollama

# Определяем состояние, которое будут разделять агенты
class ProjectState(TypedDict):
    requirements: str
    api_code: str
    test_code: str
    docs: str
    feedback: list
    current_agent: str

# Функция агента-менеджера
def manager_agent(state):
    response = ollama.chat(
        model='qwen3.5:35b-q6_K',
        options={'reasoning_effort': 8},  # Ключевой параметр!
        messages=[{
            'role': 'system',
            'content': 'Ты менеджер проекта. Создай четкие требования для FastAPI сервиса конвертации валют с кэшированием.'
        }]
    )
    return {'requirements': response['message']['content']}

# Агент-разработчик и другие аналогично...
# Полный код в репозитории

# Строим граф
workflow = StateGraph(ProjectState)
workflow.add_node("manager", manager_agent)
workflow.add_node("developer", developer_agent)
workflow.add_node("tester", tester_agent)

workflow.set_entry_point("manager")
workflow.add_edge("manager", "developer")
workflow.add_edge("developer", "tester")
workflow.add_edge("tester", END)

app = workflow.compile()

Ошибки, которые гарантированно сломают твою multi-agent систему

За три месяца тестов я наступил на все грабли. Вот топ-3 ошибки, которые сведут на нет даже Qwen3.5-35B.

1. Не контролируешь контекстное окно. Каждый агент видит только последнее сообщение? Он забудет исходную цель. Передаешь всю историю? Модель утонет в токенах. Решение: используй сумарризацию ключевых точек после каждого шага. LangGraph для этого отлично подходит.
2. Игнорируешь temperature для разных агентов. Менеджеру нужна креативность (temperature=0.7), разработчику - точность (temperature=0.1), тестировщику - педантичность (temperature=0.2). Если всем поставить 0.7, код будет полон рандомных функций.
3. Забываешь про human-in-the-loop для критичных шагов. Полная автономность - это круто, пока агент не решит удалить продовую базу данных. Добавляй контрольные точки, где человек должен подтвердить действие.

И да, если твоя модель меньше 20B параметров, даже не пытайся строить сложные multi-agent цепочки. Она не потянет. Проверено на 11 маленьких моделях в нашей предыдущей статье.

FAQ: ответы на вопросы, которые ты еще не успел задать

Что дальше? Прогноз от того, кто видел 50 провальных тестов

К концу 2026 года multi-agent системы станут стандартом для автоматизации сложных workflows. Но не потому, что модели поумнеют (они и так уже умные), а потому, что frameworks наконец-то научатся компенсировать слабости LLM.

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

А пока что - бери Qwen3.5-35B, выставляй reasoning_effort=8 и начинай с простых цепочек из двух агентов. Первый успешный workflow, который сработает без твоего вмешательства, даст тебе больше понимания, чем десяток статей. Включая эту.

Подписаться на канал