Mistral Vibe + Devstral2 Small: локальный монстр на 256k токенов и трех GPU

Почему 256k контекст перестал быть роскошью

Запустить модель с контекстом в 256 тысяч токенов локально - звучит как безумие. Особенно если у тебя не DGX A100, а просто несколько бывших в употреблении RTX 3090. Но безумие - это когда пробуешь запустить Llama 3.1 405B на такой связке.

Mistral Vibe (7B параметров) плюс Devstral2 Small (3B параметров) - это не просто две модели. Это идеальный тандем. Vibe для общего понимания и креатива, Devstral2 для точности и фактов. А вместе они умещаются в 10B параметров. Это ключевой момент.

Зачем эта связка и почему именно сейчас

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

С 256k все иначе. Модель помнит начало разговора. Помнит все документы, которые ты загрузил. Не нужно постоянно напоминать: "Мы обсуждаем проект X, вот техническое задание, вот требования..." Она уже все знает.

Но есть проблема. Чем больше контекст, тем больше оперативной памяти нужно. И не просто RAM, а VRAM. Один RTX 4090 с 24 ГБ - маловато. Два RTX 3090 по 24 ГБ - уже лучше. Три - вот где начинается магия.

Железо: что нужно на самом деле

Забудь про рекомендации вроде "минимум 128 ГБ RAM". Это для CPU-инференса. Мы говорим о GPU.

NVLink? Не обязательно. В статье про NVLink для RTX 3090 я уже разбирал, что для инференса разница минимальна. Тратить деньги на мосты - спорное решение.

Q4KL: секретное оружие

Q4KL - это не просто квантование. Это Q4_K_L в терминологии llama.cpp. Буква L значит "Low". Но не в смысле качества, а в смысле использования специальных алгоритмов, которые сохраняют больше точности при том же размере.

Чем Q4KL лучше обычного Q4?

• Лучше сохраняет редкие токены (имена, термины)
• Меньше деградация на математических задачах
• Более стабильное качество на длинных контекстах

Разница в размере? Практически нулевая. А качество может быть на 5-10% выше в некоторых задачах. Зачем отказываться?

1 Скачиваем и конвертируем модели

Первая ошибка - качать готовые GGUF файлы. Часто их делают с неправильными настройками квантования. Лучше конвертировать самому.

# Устанавливаем llama.cpp
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make -j$(nproc)

# Конвертируем Mistral Vibe в GGUF
python3 convert.py --outfile mistral-vibe.Q4KL.gguf \
  --outtype q4kl \
  models/mistral-vibe/

# Конвертируем Devstral2 Small
python3 convert.py --outfile devstral2-small.Q4KL.gguf \
  --outtype q4kl \
  models/devstral2-small/

Обрати внимание на флаг --outtype q4kl. Это важно. Без него получится обычное Q4 квантование.

2 Создаем config.toml - сердце системы

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

Сначала покажу, как НЕ надо делать:

# ПЛОХОЙ ПРИМЕР
[models]
model = "mistral-vibe.Q4KL.gguf"

[gpu]
devices = "0,1,2"  # Просто перечислил карты

[sampling]
temp = 0.7

Что не так? Карты перечислены, но как распределять слои - не указано. Модель загрузится на первую карту, а остальные будут простаивать.

Вот правильная конфигурация:

# config.toml для 3 GPU и 256k контекста
[models]
model = [
  { path = "mistral-vibe.Q4KL.gguf", ratio = 0.7 },
  { path = "devstral2-small.Q4KL.gguf", ratio = 0.3 }
]

[gpu]
# Распределение по картам: 40% на 0, 30% на 1, 30% на 2
split = "40,30,30"
# Явно указываем, какие карты использовать
devices = [0, 1, 2]
# Кеш для контекста - обязательно для 256k
cache_size = 32768  # в MB

[context]
# Вот он, главный параметр
context_size = 262144  # 256k
# Батч для обработки - влияет на скорость
batch_size = 512
# Кешируем ключи-значения для ускорения
flash_attention = true

[sampling]
temp = 0.8
top_k = 40
top_p = 0.95
repeat_penalty = 1.1

[server]
# Если используем через API
host = "127.0.0.1"
port = 8080
parallel_requests = 2  # Для 3 GPU можно 3, но осторожно

Ключевые моменты:

• split = "40,30,30" - распределение слоев. Первая карта получает больше, потому что на ней часть системных процессов
• cache_size = 32768 - 32 ГБ кеша. Для 256k контекста нужно много памяти под KV-кеш
• ratio = 0.7 и 0.3 - Mistral Vibe главная, Devstral2 вспомогательная

3 Запускаем и тестируем

Команда запуска зависит от того, какой бэкенд используешь. Я предпочитаю llama.cpp-совместимые серверы вроде text-generation-webui или ollama.

Для text-generation-webui:

# Запускаем с нашей конфигурацией
python server.py \
  --model-dir ./models \
  --config config.toml \
  --api \
  --listen

Для чистого llama.cpp:

./llama-cli \
  -m mistral-vibe.Q4KL.gguf \
  --mmproj devstral2-small.Q4KL.gguf \
  -c 262144 \
  -ngl 99 \
  -t 8 \
  -b 512 \
  --split 40,30,30 \
  --host 0.0.0.0 \
  --port 8080

Цифры производительности: чего ждать

Я тестировал на трех RTX 3090 (не оверклок, stock частота).

12-18 токенов в секунду на полном контексте - это много или мало? Для сравнения: GPT-4 через API на 128k контексте дает 3-5 токенов в секунду. И стоит десятки долларов за час работы.

Здесь - локально, бесплатно после покупки железа, и с полной приватностью.

Ошибки, которые убьют производительность

1. Неправильный split. Если поставить "33,33,33", первая карта будет перегружена системными процессами. Результат - просадка скорости на 20%.

2. Маленький batch_size. Для 256k нужно минимум 512. При 128 скорость падает в 1.5 раза. При 64 - в 2.5 раза.

3. flash_attention = false. Без этого KV-кеш ест память как ненормальный. Включай всегда.

4. Кеш на медленном SSD. Если система пытается сбрасывать кеш на диск (а при нехватке VRAM будет), нужен быстрый NVMe. Иначе паузы по 2-3 секунды каждые 100 токенов.

А если карт всего две?

Можно. Но контекст придется урезать. Вот рабочая конфигурация для 2×RTX 3090 (48 ГБ VRAM):

[models]
model = [
  { path = "mistral-vibe.Q4KL.gguf", ratio = 0.8 },
  { path = "devstral2-small.Q4KL.gguf", ratio = 0.2 }
]

[gpu]
split = "55,45"  # Первая карта получает больше
devices = [0, 1]
cache_size = 24576  # 24 ГБ

[context]
context_size = 131072  # 128k вместо 256k
batch_size = 384
flash_attention = true

128k вместо 256k - все еще огромное окно. Большинству хватит. А если нужно больше - добавляй третью карту или переходи на кластерные решения.

Зачем вообще такой длинный контекст?

Пример из реальной задачи. Юридическая фирма анализирует договор на 150 страниц плюс 50 страниц прецедентов. Им нужно найти противоречия.

С контекстом 8k они загружают документ по частям. Теряют связь между разделами. Пропускают важные детали.

С 256k - загружают все сразу. Модель видит весь документ целиком. Находит ссылки из параграфа 3 на приложение 5. Замечает, что определение термина в начале противоречит его использованию в конце.

Или разработка. Загружаешь всю кодовую базу проекта (десятки тысяч строк). Просишь: "Найди все места, где используется функция X, и предложи рефакторинг". Модель видит все файлы одновременно. Понимает связи.

Это меняет правила игры.

Что будет, если добавить четвертую карту

С четырьмя RTX 3090 (96 ГБ VRAM) можно попробовать более тяжелые модели. Или увеличить batch_size до 1024. Или использовать менее агрессивное квантование (Q5_K_M вместо Q4KL).

Но закон убывающей отдачи работает. От 3 к 4 картам прирост скорости будет 20-25%, а не 33%. Потому что накладные расходы на синхронизацию.

Если собираешь систему с нуля - три карты оптимальны. Если уже есть две - докупай третью. Четвертая - для энтузиастов.

И да, блок питания на 1600W обязателен. Три 3090 под нагрузкой едят 1000-1100W. Плюс процессор, память, диски. Не экономь на питании - сгоревшая карта стоит дороже хорошего БП.

P.S. Через месяц после настройки такой системы начинаешь замечать странное. 32k контекст кажется тесным. 8k - смешным. А GPT-4 через API раздражает своей медлительностью. Это точка невозврата.