Настройка Agent Zero: распределение моделей по GPU, борьба с галлюцинациями | AiManual
AiManual Logo Ai / Manual.
19 Янв 2026 Гайд

Agent Zero на 84 ГБ VRAM: как заставить агента не врать и не тормозить

Детальный гайд по настройке Agent Zero на мощном железе. Распределение моделей между Ollama и llama.cpp, выбор квантований, борьба с галлюцинациями LLM.

Когда 84 ГБ VRAM недостаточно

Запустил Agent Zero на конфигурации с 84 ГБ видеопамяти и сразу столкнулся с парадоксом. Железо топовое, но агент работает медленнее, чем хотелось бы, а иногда просто врёт. Проблема оказалась не в железе, а в том, как мы его используем.

Самая частая ошибка: думать, что больше VRAM = лучше производительность. На деле нужно правильно распределять модели между GPU и выбирать оптимальные квантования.

Распределение моделей: зачем делить и властвовать

Agent Zero по умолчанию пытается засунуть всё в одну модель. Это как если бы один человек пытался одновременно писать код, планировать задачи и искать информацию. Получается плохо во всём.

1 Определяем роли моделей

В моей конфигурации я разделил задачи между тремя моделями:

  • Основной агент (GPToss 34B) - планирование и координация
  • Специалист по коду (Llama 3.2 11B) - только программирование
  • Эмбеддер (GLM 4B) - векторное представление текста
💡
Не пытайтесь найти одну модель, которая хорошо делает всё. Разделение труда между специализированными моделями даёт прирост производительности в 2-3 раза.

2 Ollama vs llama.cpp: где что запускать

Здесь начинается самое интересное. Ollama удобен для быстрого старта, но для продакшена нужен контроль. Вот моё распределение:

Модель Движок Почему VRAM
GPToss 34B Q4_K_M llama.cpp Полный контроль над слоями и контекстом ~24 ГБ
Llama 3.2 11B Q8_0 Ollama Быстрый старт, удобное API для кодирования ~12 ГБ
GLM 4B Q4_K_S llama.cpp Минимальная задержка при инференсе ~3 ГБ

Борьба с галлюцинациями: не верьте своей модели

Галлюцинации в Agent Zero - это не баг, это фича, которую нужно отключить. Особенно когда агент "помнит" файлы, которых никогда не существовало.

3 Системный промпт как противоядие

Вот промпт, который снизил галлюцинации на 70%:

system_prompt = """
Ты - практичный ИИ-агент. Твои ответы должны быть:
1. Фактически точными - если не уверен, говори "не знаю"
2. Краткими - без лишних рассуждений
3. Проверяемыми - включай конкретные команды или пути

Критическое правило: НИКОГДА не придумывай файлы, команды или API, которых нет.
Если нужно проверить - сначала проверь, потом отвечай.
"""

Самый опасный тип галлюцинаций - когда агент "помнит" предыдущие действия, которых не было. Всегда проверяйте историю выполнения.

4 Температура и повторяемость

Настройки генерации важнее, чем выбор модели:

# Так НЕ надо делать
{
    "temperature": 0.7,  # Слишком творчески
    "top_p": 0.9,
    "repeat_penalty": 1.1
}

# А вот так - правильно
{
    "temperature": 0.3,  # Более детерминировано
    "top_p": 0.95,       # Шире выбор, но контролируемо
    "repeat_penalty": 1.2,  # Сильнее наказываем повторения
    "mirostat": 2,       # Включаем контроль сложности
    "mirostat_tau": 5.0,
    "mirostat_eta": 0.1
}

Выбор квантований: где можно сэкономить, а где нельзя

Квантование - это искусство баланса между качеством и производительностью. И здесь есть свои правила.

5 Квантование для каждой задачи

Разные задачи требуют разной точности:

  • Планирование (GPToss): Q4_K_M - достаточно для логических цепочек
  • Кодирование (Llama): Q8_0 - ошибки в коде дороже памяти
  • Эмбеддинг (GLM): Q4_K_S - скорость важнее точности векторов

Проверяем качество квантования простым тестом:

# Запускаем модель с разными квантованиями
./llama-cli -m gptoss-34b-q4_k_m.gguf -p "Что такое Docker Compose?" -n 100
./llama-cli -m gptoss-34b-q8_0.gguf -p "Что такое Docker Compose?" -n 100

# Сравниваем не только ответы, но и:
# 1. Время первого токена
# 2. Общее время генерации
# 3. Когерентность длинных ответов
💡
Q8_0 для кодирующих моделей - это не роскошь, а необходимость. Одна ошибка в синтаксисе из-за плохого квантования может стоить часов отладки.

Распределение по GPU: как не устроить драку за память

С 84 ГБ VRAM можно было бы расслабиться, но если всё свалить в кучу, производительность упадёт.

6 Изоляция моделей на разных GPU

# Запускаем каждую модель на своём GPU

# GPU 0: Основной агент
CUDA_VISIBLE_DEVICES=0 ./llama-cli \
  -m gptoss-34b-q4_k_m.gguf \
  --n-gpu-layers 40 \
  --ctx-size 8192 \
  --host 0.0.0.0 --port 8081

# GPU 1: Модель для кода
CUDA_VISIBLE_DEVICES=1 ollama serve
# В отдельном терминале
CUDA_VISIBLE_DEVICES=1 ollama run llama3.2:11b-q8_0

# GPU 2: Эмбеддер
CUDA_VISIBLE_DEVICES=2 ./llama-cli \
  -m glm-4b-q4_k_s.gguf \
  --n-gpu-layers 99 \  # Все слои на GPU
  --embeddings \
  --host 0.0.0.0 --port 8083

Оптимизация эмбеддера: самая незаметная проблема

GLM 4B в роли эмбеддера тормозил всю систему. Проблема была в том, что он обрабатывал тексты последовательно.

7 Пакетная обработка эмбеддингов

# Медленно - так НЕ делать
embeddings = []
for text in documents:
    embedding = embedder.encode(text)  # Один запрос за раз
    embeddings.append(embedding)

# Быстро - пакетная обработка
batch_size = 32  # Зависит от VRAM эмбеддера
embeddings = []

for i in range(0, len(documents), batch_size):
    batch = documents[i:i+batch_size]
    batch_embeddings = embedder.encode(batch)  # Весь пакет за раз
    embeddings.extend(batch_embeddings)

Это дало ускорение в 8-10 раз для больших документов.

Конфигурация Agent Zero: финальная сборка

Вот итоговая конфигурация, которая работает стабильно:

# config.yaml
models:
  planner:
    name: "gptoss-34b-q4_k_m"
    endpoint: "http://localhost:8081"
    engine: "llamacpp"
    gpu: 0
    context: 8192
    
  coder:
    name: "llama3.2:11b-q8_0"
    endpoint: "http://localhost:11434"
    engine: "ollama"
    gpu: 1
    context: 16384  # Больше контекста для кода
    
  embedder:
    name: "glm-4b-q4_k_s"
    endpoint: "http://localhost:8083"
    engine: "llamacpp"
    gpu: 2
    batch_size: 32

generation:
  temperature: 0.3
  top_p: 0.95
  repeat_penalty: 1.2
  mirostat: 2
  mirostat_tau: 5.0
  mirostat_eta: 0.1

system_prompt: |
  Ты - практичный ИИ-агент. Отвечай точно, кратко и проверяемо.
  Не придумывай информацию. Если не знаешь - говори "не знаю".

Что делать, если всё равно тормозит

Даже с оптимизациями Agent Zero может работать медленно. Вот что проверять в первую очередь:

  1. Контекстные окна - уменьшите context_size для некритичных задач
  2. Кэширование эмбеддингов - не вычисляйте повторно одни и те же векторы
  3. Ограничение параллелизма - слишком много одновременных запросов к моделям
  4. Теплый старт - держите модели загруженными, а не перезагружайте для каждого запроса

Если агент работает с переменной скоростью, проверьте, не происходит ли переключение слоев между GPU и RAM. Используйте nvidia-smi для мониторинга.

Чего не хватает в Agent Zero

После недели работы с системой стало понятно, что не хватает двух вещей:

  • Динамического распределения моделей - сейчас конфигурация статическая
  • Встроенного мониторинга качества - чтобы автоматически детектировать галлюцинации
  • Адаптивного квантования - возможность переключаться между версиями модели в зависимости от задачи

Но даже в текущем виде правильно настроенный Agent Zero на 84 ГБ VRAM - это мощнейший инструмент. Главное - не пытаться заставить одну модель делать всё, а создать команду специалистов, где каждый отвечает за свою часть работы.

Интересно, как другие справляются с похожими задачами? В статье про локальных агентов на трёх 3090 тоже разделяют модели по GPU, но с другим подходом к квантованию. А если у вас меньше видеопамяти, посмотрите как запустить 30B модель на 8 ГБ VRAM - там свои хитрости.