Skip to content

models-help.md

Latest commit

 

History

History
259 lines (167 loc) · 11.5 KB

models-help.md

File metadata and controls

259 lines (167 loc) · 11.5 KB

Модели

1) Какие модели можно запускать в llm-runner

llm-runner запускает модели в формате GGUF

Практически это значит:

  • можно использовать любые совместимые GGUF-веса (chat/instruct/code/embedding);
  • модель должна лежать в каталоге model_path (из config.yaml) или в его подкаталогах;
  • выбор модели идёт по имени файла (.gguf) или через YAML-манифест.

Проверка списка локальных моделей:

./build/gen-runner models

Проверка у запущенного сервиса:

./build/gen-runner remote models

2) Как понять 8B, 14B, 70B

B = billion (миллиард параметров модели).

  • 8B = примерно 8 миллиардов параметров;
  • 14B = примерно 14 миллиардов;
  • 70B = примерно 70 миллиардов.

Общее правило:

  • больше B -> обычно выше качество/знания/стабильность;
  • но больше B -> выше требования к RAM/VRAM и ниже скорость.

3) Что значит Q4, Q5, Q8, FP16

Это тип квантования: сколько бит выделяется на хранение весов модели.

Простая идея:

  • чем меньше бит на вес -> меньше размер файла и ниже требования к памяти;
  • чем меньше бит -> сильнее теряется точность -> может падать качество ответа;
  • чем больше бит -> ближе к исходному качеству, но тяжелее по RAM/VRAM.

Что значит bit в названии

  • Q4 ~ около 4 бит на вес (сильная компрессия);
  • Q5 ~ около 5 бит на вес;
  • Q8 ~ около 8 бит на вес;
  • FP16 = 16-битные веса (почти "полноценная" точность относительно квантизированных вариантов).

Важно: в реальности там есть служебные данные, блоки и коэффициенты масштабирования, поэтому это не "идеальные" 4/5/8 бит на каждый параметр. Но как практичный ориентир это работает.

Как это влияет на запуск

  • Память: Q4 < Q5 < Q8 < FP16;
  • Скорость: обычно легкие кванты (Q4) быстрее на слабом железе;
  • Качество: обычно Q8/FP16 стабильнее на сложных задачах, Q4 чаще упрощает/ошибается в деталях.

Частые варианты в GGUF

  • Q4_K_M - популярный баланс памяти/качества, хороший старт;
  • Q5_K_M - немного тяжелее, обычно качественнее;
  • Q8_0 - ближе к высокому качеству, но заметно больше расход памяти.

Что значат суффиксы вроде _K_M, _0

Это подварианты схемы квантования (группировка блоков, внутренние коэффициенты, формат хранения).

Практически:

  • смотрите на бенчмарки и свой сценарий, а не только на "красивость" суффикса;
  • в одном и том же семействе обычно Q5_K_M качественнее Q4_K_M, но медленнее/тяжелее;
  • Q8_0 часто выбирают, когда памяти достаточно и нужен запас качества.

Короткое правило выбора

  1. Мало памяти -> начинайте с Q4_K_M.
  2. Память есть, качество не хватает -> пробуйте Q5_K_M.
  3. Нужен максимум качества и есть запас памяти -> Q8_0 (или менее сжатые варианты).

4) Как читать полное имя файла модели

Пример:

Qwen2.5-7B-Instruct-Q4_K_M.gguf

Расшифровка:

  • Qwen2.5 - семейство модели;
  • 7B - размер (параметры);
  • Instruct - версия для диалога/инструкций;
  • Q4_K_M - тип квантования;
  • .gguf - формат файла.

5) Vision-модели (картинки)

Если хотите отправлять изображения, нужен не только основной .gguf, но и файл проектора mmproj (тоже обычно .gguf), который указывается в YAML-манифесте:

from: Qwen2.5-VL-7B-Instruct-Q4_K_M.gguf
mmproj: mmproj-Qwen2.5-VL-f16.gguf

Без mmproj запросы с изображениями не заработают.

6) Рекомендации по выбору модели

Быстрый ориентир:

  • мало памяти (обычный ноутбук/CPU): 7B/8B + Q4_K_M;
  • средний ресурс: 7B/14B + Q5_K_M;
  • мощная GPU/много RAM: 14B+ или 32B/70B, кванты Q8 или выше.

Практика:

  1. Начните с 7B/8B в Q4_K_M.
  2. Если качество недостаточно - переходите на Q5_K_M или больший B.
  3. Если хватает памяти - пробуйте Q8_0 для лучшего качества.

7) Что важно помнить

  • B (размер модели) и Q* (квантование) - это разные оси выбора.
  • 8B Q8 может быть тяжелее, чем 14B Q4 - всегда смотрите фактический размер файла и расход памяти.
  • Для продакшена лучше протестировать 2-3 соседних варианта на ваших реальных запросах.

8) Минимальный чеклист перед запуском

  1. Файл модели есть в model_path и имеет расширение .gguf.
  2. Модель видна в ./build/gen-runner models.
  3. Для vision добавлен mmproj в YAML.

9) Как понять, запустится ли модель на текущем железе

Ниже практичный способ оценить запуск до долгих экспериментов.

Шаг 1. Смотрите на размер файла .gguf

Размер файла - самый быстрый и полезный индикатор требований к памяти.

Правило для CPU/RAM:

  • минимум нужен объем RAM больше размера файла;
  • комфортно: RAM >= размер модели x 1.5..2.0.

Примеры:

  • модель 4 GB -> минимум около 6 GB свободной RAM, комфортно 8+ GB;
  • модель 12 GB -> минимум около 16 GB свободной RAM, комфортно 24+ GB.

Почему не 1:1:

  • кроме весов, память нужна на контекст (n_ctx), KV-cache, служебные структуры и сам процесс.

Шаг 2. Отдельно оцените VRAM (если используете GPU)

Если модель частично или полностью оффлоадится на GPU (gpu_layers > 0), нужна свободная VRAM.

Базовое правило:

  • для полного размещения модели на GPU обычно нужно примерно размер gguf + запас 20..40%;
  • если VRAM мало - уменьшайте gpu_layers, и часть модели уйдет в RAM.

Проверка в Linux/NVIDIA:

nvidia-smi

Признаки, что оффлоад идет:

  • при загрузке модели растет занятая VRAM;
  • во время генерации видна активность GPU.

Шаг 3. Контекст (n_ctx) сильно влияет на память

Чем выше n_ctx, тем больше память под KV-cache.

  • n_ctx=4096 - базовый безопасный старт;
  • n_ctx=8192+ - ощутимо тяжелее по памяти;
  • для слабого железа сначала снижайте n_ctx, а не только размер модели.

В gen-runner контекст задается через:

  • глобально - max_context_tokens / настройки раннера;
  • на модель - num_ctx в YAML-манифесте.

Шаг 4. Оцените, потянет ли CPU по скорости

На CPU модель может "запуститься", но быть слишком медленной.

На скорость влияют:

  • размер модели (B);
  • квантование (Q4 быстрее, Q8 медленнее);
  • число потоков (threads, threads_batch);
  • тип железа (частота, кэш, память).

Практичный критерий:

  • если скорость слишком низкая, сначала переходите на более легкий квант (Q5 -> Q4) или меньший размер (14B -> 7B/8B).

Шаг 5. Учтите, что vision-модели тяжелее

Для мультимодальных моделей дополнительно загружается mmproj.

Это значит:

  • дополнительная память (RAM/VRAM);
  • более медленная обработка;
  • для слабого железа лучше text-only модель.

10) Быстрый алгоритм выбора под ваше железо

  1. Начните с 7B/8B в Q4_K_M.
  2. Поставьте n_ctx=4096.
  3. Если есть GPU - выставьте умеренный gpu_layers и проверьте nvidia-smi.
  4. Если упирается в память:
    • уменьшите n_ctx;
    • уменьшите gpu_layers;
    • возьмите более легкий квант/меньший B.
  5. Если памяти хватает, но качество низкое:
    • сначала Q4 -> Q5/Q8,
    • затем 7B/8B -> 14B+.

11) Типичные симптомы и что делать

  • out of memory / падение процесса:
    • модель слишком тяжелая для RAM/VRAM;
    • уменьшайте B, квант или n_ctx.
  • Модель грузится очень долго и "тормозит":
    • слишком тяжелая модель для CPU;
    • берите меньший размер или более легкий квант.
  • GPU почти не используется:
    • проверьте сборку с CUDA и параметр gpu_layers;
    • смотрите логи и nvidia-smi.

12) Команды для быстрой самопроверки

Показать доступные модели:

./build/gen-runner models

Проверить, что раннер видит модели:

./build/gen-runner remote models

Проверить состояние NVIDIA GPU:

nvidia-smi