Почему Gemma 4b оказалась лучше Mistral 7B для пакетной оценки сообщений на слабом железе

Разработчик столкнулся с задачей пакетной оценки сообщений на видеокарте с 6 ГБ видеопамяти — и выяснил, что размер контекстного окна важнее количества параметров модели.

Лучшая модель — не та, у которой больше параметров, а та, что укладывается в жёсткие ограничения конкретной задачи. Mistral 7B может превосходить Gemma 4b на общих бенчмарках, но модель, которая не удерживает нужный контекст, выдаёт бесполезный результат — вне зависимости от её «интеллекта».

Суть эксперимента

Разработчик Маянк Деванган опубликовал на dev.to подробный разбор того, как он выбирал локальную языковую модель для задачи пакетной (batch) оценки сообщений. Аппаратные ограничения жёсткие: NVIDIA RTX 4050 с 6 ГБ видеопамяти и процессор Intel i7. Задача звучит тривиально — оценить сообщения по заранее заданной схеме, — но на практике оказалось, что даже 7-миллиардная модель может проиграть 4-миллиардной.

Разберём, что именно пошло не так и почему.

Критерии отбора

Автор сформулировал три жёстких требования к модели:

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

Последний пункт, как выяснится, стал решающим.

Фаза 1: phi-4-mini — слишком маленький, слишком «разговорчивый»

Начали с самой компактной модели — phi-4-mini. Логика была простой: задача элементарная, зачем грузить крупную модель?

При оценке по одному сообщению phi-4-mini справлялась, но это означало отдельный вызов LLM для каждого сообщения. Результат: рост количества вызовов на 71%, дополнительная задержка более 10 минут на 130 сообщений и неэффективное использование ресурсов. На слабом железе такое расточительство — роскошь.

При переходе к пакетной обработке модель и вовсе сломалась: только 60% ответов соответствовали заданной JSON-схеме. Конвейер падал посередине выполнения. Автор пробовал дорабатывать системный промпт и добавлять обработку ошибок, но в итоге пришёл к выводу: phi-4-mini изначально не предназначена для генерации длинных структурированных ответов. Это фундаментальное ограничение архитектуры, а не вопрос «донастройки».

Фаза 2: Mistral 7B — больше параметров, но контекста не хватает

Переход к Mistral 7B решил проблему схемы: на тестовом наборе из 40 сообщений пакетная обработка работала безупречно. Но когда на вход пошли реальные данные — смесь коротких и длинных сообщений — модель начала генерировать бессвязный вывод, повторяя поведение phi-4-mini.

Отладка выявила причину: среднее потребление контекста составляло около 16 тысяч токенов (вход + выход), а Mistral 7B в той конфигурации предлагал окно всего на 8 тысяч. Модель буквально «забывала» инструкции, не дочитав до конца входные данные.

Это важный момент: контекстное окно (context window) — это суммарный объём токенов, который модель может одновременно «держать в голове». Сюда входят системный промпт, входные данные и генерируемый ответ. Если задача требует 16K токенов, а окно модели 8K, результат предсказуем: модель теряет нить и выдаёт мусор.

Интересно, что стандартный контекст Mistral 7B составляет 32K токенов, но на практике реальный доступный объём зависит от выбранного уровня квантования и доступной видеопамяти. При 6 ГБ VRAM и агрессивном квантовании реальное рабочее окно может оказаться значительно меньше спецификации. Автор, к сожалению, не уточняет точную модель и уровень квантования — а это критически важные детали, от которых зависят и потребление памяти, и качество вывода.

Фаза 3: Gemma 4b — золотая середина

Gemma 4b оказалась тем самым компромиссом. На тестовом наборе из 52 сообщений модель выполнила все три критерия. На том же оборудовании с 6 ГБ VRAM она обеспечивала контекстное окно в 32K токенов. В реальном прогоне максимальное потребление контекста составило 28K — укладывается с запасом.

Почему 4-миллиардная модель даёт больше контекста, чем 7-миллиардная? Ответ — в архитектуре и квантовании. Чем меньше параметров, тем меньше видеопамяти уходит на хранение весов модели, и тем больше остаётся на хранение контекста (KV-кэш). Это фундаментальный trade-off: больше параметров — выше «интеллект» модели, но меньше памяти на контекст. На 6 ГБ VRAM этот компромисс становится определяющим.

Почему «лучшая модель» — не всегда лучший выбор

Главный вывод эксперимента — контринтуитивный для тех, кто привык ориентироваться на бенчмарки. Mistral 7B стабильно показывает лучшие результаты на общих тестах (MMLU, HellaSwag и прочих). Но если задача требует обработки длинных последовательностей на ограниченном оборудовании, модель с бóльшим количеством параметров, но меньшим контекстным окном проиграет.

Автор справедливо подчёркивает: задача оценки сообщений сама по себе несложная — с ней справлялась даже phi-4-mini в режиме поштучной обработки. Проблема возникала именно при пакетном режиме, где критичен объём контекста.

Оговорки и неизвестные

Стоит отметить несколько слабых мест в описании эксперимента:

• Не указана точная модификация Gemma 4b. Семейство Gemma от Google включает несколько поколений (Gemma 1, Gemma 2, и предположительно более новые версии к 2026 году). Контекстные окна у них различаются: Gemma 2 2B имеет стандартные 8K, Gemma 2 9B — 8K с возможностью расширения. Заявленные 32K для 4-миллиардной модели указывают на обновлённую архитектуру, но без точного обозначения трудно верифицировать.

• Не указан уровень квантования. Это критически важно: GGUF-квантованная модель Q4_K_M займёт значительно меньше памяти, чем Q8 или FP16, но при этом может деградировать качество вывода. Для задачи со строгой JSON-схемой это не мелочь.

• Размер тестовой выборки невелик. 52 сообщения — слишком мало для статистически значимых выводов о стабильности. На 130 сообщениях (основной прогон) результаты могли бы быть другими.

• Не приведены данные по скорости инференса. На 6 ГБ VRAM время генерации — не менее важный параметр, чем точность.

Практический вывод

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

Для тех, кто работает на ограниченном оборудовании — ноутбуковые GPU, десктопные карты с 6–8 ГБ VRAM, — ключевым параметром при выборе модели становится не количество параметров, а реальное доступное контекстное окно после загрузки весов. Именно этот параметр определяет, сможете ли вы вообще решить поставленную задачу, или модель начнёт «забывать» инструкции на середине генерации.

Gemma 4b в данном случае выиграла не за счёт качества рассуждений, а за счёт архитектурного баланса: достаточно компактная, чтобы поместиться в 6 ГБ с запасом на контекст, и достаточно «умная», чтобы генерировать структурированный JSON. Для конкретной задачи пакетной оценки этого оказалось достаточно.