Llama для продакшена ломается не на размере, а на неправильном выборе конфигурации

Llama для продакшена ломается не на размере, а на неправильном выборе конфигурации

У Llama обычно смотрят только на «сколько миллиардов параметров», но в проде важнее три вещи: контекст, квантизация и режим инференса. 8B в fp16 может быть отличной моделью для быстрых ассистентов, а 70B в int4 — уже рабочий вариант для сложных цепочек, если хватает VRAM и терпит latency. Для длинных диалогов проверяйте не маркетинговый контекст, а деградацию качества после 16k–32k токенов: у многих пайплайнов дальше начинается заметная просадка в извлечении фактов и следовании инструкциям.

Если нужен дешёвый throughput, сначала считайте не «качество модели», а токены на секунду на одной GPU. Для batch-генерации и массовых ответов vLLM обычно удобнее из-за paged attention и нормальной утилизации памяти; для локальных сценариев и узких железок llama.cpp часто выигрывает простотой и GGUF-квантизацией; TGI имеет смысл, когда нужна предсказуемая серверная обвязка и интеграция в существующий стек.

Практическая схема отбора такая: 1) берёте 2–3 размера одной линейки; 2) гоняете один и тот же набор промптов; 3) смотрите не только ответ, но и стабильность формата, склонность к галлюцинациям и поведение на длинном контексте; 4) отдельно считаете стоимость 1M токенов при своём железе. Частая ошибка — брать самую большую Llama и пытаться запихнуть её в слабую инфраструктуру: итогом становится не рост качества, а рост очередей и падение SLA.

Если модель нужна для арбитражной автоматизации, чаще выигрывает не максимальный размер, а стабильная средняя модель с хорошей квантизацией и предсказуемым latency. Сначала выберите железо и сервер инференса, потом уже размер Llama — иначе вы оптимизируете не задачу, а самообман.