Не ставьте 70B в оркестратор: как выбрать размер модели для ReAct-агента на llama.cpp

Когда оркестратор жрёт больше, чем генератор

Наблюдал картину: парень поднимает локального ReAct-агента на llama.cpp. В качестве оркестратора — Llama 70B. Результат: агент думает по 3 минуты на шаг, падает контекст, и в итоге он просто пишет «Выполняю...» и зависает. Вопрос: зачем?

Для оркестрации (Thought -> Action -> Observation) не нужна тяжелая артиллерия. Планирование, выбор инструмента, анализ результата — это задачи на логику и следование схеме, а не на генерацию кода. 70B модель в этом случае — как трактор для перевозки одного яблока. Вы не получите прироста качества, а получите тормоза и лишний расход электричества.

В этой статье разберу, какой размер модели реально нужен для оркестратора ReAct-агента, какие модели 2-7B действительно показывают результат, и как настроить llama.cpp, чтобы цикл работал быстро и стабильно. Без воды, с тестами и граблями.

Почему размер имеет значение (и когда он не имеет)

ReAct-агент делает несколько последовательных вызовов LLM за один запрос. Средний цикл: 3-5 итераций. На каждой итерации мы передаём модельке текущий контекст (историю действий и наблюдений) и просим сгенерировать следующее действие. Если модель весит 70B и требует 140GB памяти, то на consumer-железе это будет работать через offloading или с огромным latency. На RTX 4090 24GB вы просто не сможете загрузить 70B целиком — только часть слоёв на GPU, остальное на CPU. Скорость упадёт до 2-3 токенов в секунду. Агент будет думать минутами.

С другой стороны, модели 2-7B спокойно помещаются в VRAM одной видеокарты и дают 20-60 токенов/с. Разница в скорости — порядок. Но не потеряем ли мы в качестве? Тут нюанс: для оркестрации точность нужна не на уровне написания сложной функции, а на уровне: «Какой инструмент выбрать?», «Какой следующий шаг?», «Верный ли ответ получен?». С этим справляются и 3B модели, если они нормально обучены следовать инструкциям.

Что вы реально ждёте от оркестратора

Давайте отделим мух от котлет. Оркестратор — это не кодогенератор. Он не пишет вам деплой-скрипт и не выводит сложную логику. Его задачи:

• Прочитать prompt с описанием инструментов и текущего состояния.
• Сгенерировать Thought — текстовое рассуждение, какой инструмент применить.
• Сгенерировать Action — вызов функции с правильными аргументами.
• Прочитать Observation (результат), решить, достаточно или продолжать.

Для всего этого нужна способность модели следовать шаблону и держать контекст, а не креативность. Здесь можно смело использовать маленькие модели. Даже 2B модель, если она нормально дообучена на инструкциях, справится.

В качестве примера — проект автоматизированного AI-исследователя, где оркестратор — как раз 3B модель, и это работает. Там не нужно генерировать отчёты — только выбирать поисковые запросы.

Практический выбор: какие модели брать

Ниже таблица с моделями, которые я тестировал для оркестрации в ReAct. Все они работают через llama.cpp, квантизованы в Q4_K_M или Q5_K_M, чтобы уложиться в 8-12GB VRAM.

Лидер для меня — Qwen2.5-3B. Он отлично держит системный промпт с описанием инструментов, редко сходит с рельсов. Phi-4-mini чуть тяжелее, но тоже хорош, особенно если нужна большая точность в извлечении аргументов. Gemma-2-2B — вариант для совсем слабых машин, но иногда тупит на сложных цепочках действий.

Если у вас больше 12GB VRAM — можете взять Mistral 7B. Но я не вижу в этом необходимости, разве что агент использует много инструментов и требует высокой точности на каждом шаге. Для простых задач (2-3 инструмента) 3B хватает за глаза.

Настройка ReAct цикла с llama.cpp

Допустим, выбрали модель. Теперь нужно правильно организовать цикл. Я использую llama.cpp в режиме сервера, через HTTP-запросы. Так можно легко переиспользовать модель для нескольких агентов и контролировать контекст.

Пример запуска сервера (версия b4371+ на момент мая 2026):

./server -m models/qwen2.5-3b-instruct-q4_k_m.gguf 
          --host 127.0.0.1 --port 8080 
          --ctx-size 8192 --batch-size 512 
          --no-mmap --temp 0.3 --top-p 0.95 
          --repeat-penalty 1.1

Обратите внимание: --temp 0.3. Если оставить 0.8, модель начнёт придумывать несуществующие действия. Для оркестрации нужно детерминированное поведение, поэтому temperature низкий. --ctx-size 8192 — запас на историю итераций. Если агент делает 5 шагов по ~1000 токенов контекста, этого хватит.

Теперь Python-код для звонка к агенту. Минимальный цикл:

import requests, json

def call_llm(prompt):
    r = requests.post('http://127.0.0.1:8080/completion', 
        json={"prompt": prompt, "n_predict": 512, "stop": ["Observation:", "\n\n"]})
    return r.json()['content']

# System prompt с описанием инструментов
system = """You are an agent. You have tools: 
- read_file(path) -> content
- search(query) -> results
Respond with Thought: ... If you need to act, write Action: tool_name(input)"""

state = "User: Find the file config.yaml and show its content."
for _ in range(5):
    full_prompt = f"<|im_start|>system\n{system}\n<|im_end|>\n<|im_start|>user\n{state}\n<|im_end|>\n<|im_start|>assistant\n"
    answer = call_llm(full_prompt)
    if 'Final Answer:' in answer:
        print(answer)
        break
    # парсим Action, выполняем, обновляем state
    # ...

Важно: стоп-слова stop: ["Observation:", "\n\n"] — это не даёт модели галлюцинировать продолжение. Она вынуждена остановиться после генерации одного Thought-Action.

Для ещё большей скорости используйте обзор фреймворков, где сравнивается производительность. Если железо слабое, можно задействовать RPC-сервер на старом железе для распределения нагрузки.

Ошибки, которые я видел (и совершал сам)

Ошибка 1: Гигантский контекст

ReAct-агент может бесконечно накапливать историю. Если не чистить старые шаги, контекст распухнет до 16K+ токенов, и модель 3B начнёт «забывать» начальные инструкции. Решение: ограничьте количество итераций (например, 10 максимум) и обрезайте историю до последних N шагов.

Ошибка 2: Высокая температура

При temp=0.7 модель может решить, что вместо вызова инструмента нужно просто написать «Я подумаю об этом позже». Это беда для оркестрации. Ставьте 0.1-0.3.

Ошибка 3: Одна модель на всё

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

Ошибка 4: Игнорирование llama-eval

В llama.cpp есть инструмент llama-eval, который помогает оценить качество и скорость. Используйте его, чтобы подобрать оптимальную квантизацию и размер контекста.

Ошибка 5: Запуск оркестратора на CPU, если есть GPU

Маленькие модели типа 3B отлично бегут на GPU. Если у вас всего 4GB VRAM — можно всё равно запустить на GPU с offloading большей части слоёв. На CPU та же Qwen2.5-3B будет выдавать 5 токенов/с, на GPU — 50+. В LXC-контейнере Proxmox это легко настроить.

FAQ: быстрые ответы

Не гонитесь за размером. Для оркестрации ReAct-агента на llama.cpp 3B-модель — золотая середина. Быстро, дёшево, эффективно. А если нужна максимальная надёжность на сложных инструментах — поднимите Mistral 7B, но не ждите чуда. Тестируйте, замеряйте лучшие LLM для кодирования — для оркестрации они избыточны.

Следующие пару лет нас ждёт появление маленьких специализированных моделей, обученных именно на трейсах ReAct-агентов. Уже сейчас оцениваю Qwen2.5-3B как основной, а к концу 2026 появятся Phi-5 и Gemma-3, которые, возможно, сделают планирование ещё точнее. Держите руку на пульсе — ваш оркестратор должен быть лёгким.

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