Инференс модели: что это, скорость и память локального запуска

Что такое инференс модели?

Инференс — применение уже полученных весов модели к новым данным. Обучение меняет веса; при обычной генерации ответа задача другая: модель использует вход и предыдущий вывод, чтобы выбрать следующие токены. Документация Transformers описывает эту последовательность для текстовой генерации и интерфейс generate() s1. Для OCR или классификации выход иной, но вопрос тот же: какой результат даёт конкретная модель на новом входе. Не путайте инференс с дообучением модели.

В локальном сценарии цепочка выглядит так: задача и пример входа → конкретная модель и формат её весов → устройство и runtime → загрузка → обработка входа → ответ и проверка. Если нужен простой старт, откройте запуск Ollama; для серверной нагрузки отдельно изучите vLLM. Названия runtimes сами по себе не гарантируют скорость или качество на вашем устройстве: без одинакового задания сравнение невалидно.

Из каких этапов складывается ответ LLM?

Первый этап — загрузка весов, если модель ещё не размещена в памяти. Далее модель обрабатывает входные токены; при последовательной генерации использует предыдущие токены и может повторно использовать key/value-состояния внимания через KV-кеш s1 s2. Это не отдельная модель и не замена весов: стратегия кеша влияет на использование памяти и скорость, причём документация различает динамический, статический и квантованный варианты s2.

Поэтому «модель отвечает медленно» — неоднозначный диагноз. В завершённом ответе Ollama /api/generate отдельно перечислены load_duration, prompt_eval_count, prompt_eval_duration, eval_count, eval_duration; документация определяет длительности в наносекундах s3. Долгая загрузка, обработка длинного входа и медленная выдача последующих токенов требуют разных проверок. Токены объясняют единицу счёта, а контекстное окно — предел и рабочую настройку длины запроса.

Что означает «быстрый инференс»?

Для интерактивного запроса важна задержка до первого токена (TTFT), а при длинном ответе — время между последующими токенами. NVIDIA определяет TTFT как время от отправки запроса до первого непустого токена и предупреждает, что определения инструментов различаются s7. Руководство benchmark CLI vLLM выводит TTFT и метрики времени на выходной токен отдельно s6. Пропускная способность сервера — суммарный выход при потоке одновременных запросов, а не скорость ответа одному человеку; NVIDIA описывает system TPS отдельно от задержки отдельного запроса s7.

Не сопоставляйте чужие «токены/с» без одинаковой модели, кванта, входной и выходной длины, числа одновременных запросов, железа и условий измерения. Само по себе меньшее TTFT не доказывает лучшую точность ответа. Для одного пользовательского сценария достаточно записать время появления первого полезного фрагмента, полный ответ и счётчики runtime; для сервера дополнительно важны параллельная нагрузка и задержки на ней s3 s6 s7. Это метод сравнения, а не опубликованный тест Modelium.

Сколько памяти нужно для инференса?

Одной цифры из размера файла весов недостаточно. Во время генерации требуется место для весов и рабочих состояний; KV-кеш для длинного контекста может занимать существенную память, а разные стратегии экономят память с возможной ценой по скорости s2. В Ollama рабочий контекст можно задать через OLLAMA_CONTEXT_LENGTH либо параметр num_ctx API; документация отдельно описывает влияние параллельной обработки запросов на потребность в памяти s5. Поэтому объём файла весов не является минимальным требованием RAM или VRAM для вашего режима.

Если модель уже загружена, /api/ps показывает size, size_vram и context_length конкретного запущенного экземпляра s4. Уточните, какие части размещены на GPU, какое окно настроено и есть ли другие одновременно загруженные модели; сравните наблюдение с разбором железа для LLM. Эти поля — свидетельство состояния данного запуска, не универсальная гарантия для соседнего компьютера. Без прогона на целевом железе Modelium не называет минимум памяти и не обещает заданные токены в секунду.

Как проверить результат на своей задаче?

1. Зафиксируйте задачу, модель с тегом/ревизией, формат и квант весов, версию runtime, железо и рабочее окно. Откройте гайд Ollama для конкретной процедуры запуска, если это ваш runtime.
2. Возьмите два собственных входа: короткий запрос с проверяемым ответом и длинный пример в пределах настроенного окна. В обоих случаях оцените верность ответа по исходным данным, а не только ощущение скорости. Входные токены и требуемая длина выхода меняют нагрузку s1 s5.
3. Запишите отдельно загрузку, обработку входа и генерацию выхода по завершённому ответу /api/generate; не превращайте примерные поля документации в результаты своего запуска s3. При интерактивном использовании отметьте также фактическое время до первого непустого токена s7.
4. Проверьте загруженную модель и размещение через /api/ps или описанный в FAQ ollama ps s4 s5. Если длинный вход не помещается, сперва уточните фактический контекст; если место или скорость не подходят, сравните другой квант, устройство или runtime на тех же входах, не выдавая изменение качества за ускорение.

Основной следующий шаг: откройте проверенный путь запуска Ollama и выполните один контролируемый запрос на своём компьютере. Если нужна конкурентная нагрузка нескольких пользователей, после одиночной проверки переходите к серверному сценарию vLLM и измеряйте задержку и пропускную способность отдельно s6 s7.