Inference и обучение: где на самом деле расходуются ресурсы
Обучение и inference — разные этапы жизни нейросети, хотя в разговоре их часто смешивают. Во время обучения параметры модели меняются на примерах: система ищет закономерность и корректирует ошибку. Во время inference параметры уже зафиксированы, а модель вычисляет ответ на новый вход. От этой границы зависят память, оборудование, стоимость и способ диагностики сбоя. Если ответ стал медленным, не всегда нужно добавлять данные; если он неверен, замена видеокарты тоже не гарантирует улучшение.
Обучение: что происходит с данными
Датасет проходит через модель, полученный результат сравнивается с эталоном, а параметры немного изменяются. Цикл повторяется по партиям и эпохам. Кроме весов нужны память для градиентов, контрольные версии и место для журналов. Ошибки в разметке, дубли и перекос классов закрепляются на этом этапе и проявляются позже на новых запросах.
Дообучение меняет поведение, стиль или формат, но не превращает модель в надёжное хранилище обновляемого регламента. За качество датасета отвечает отдельный процесс: выборка, проверка эталонов, разделение теста и контроль утечек. Подробный порядок такого эксперимента описан в материале о fine-tuning.
Inference: использование готовых весов
На вход подаются инструкция, контекст и вопрос. Модель последовательно вычисляет вероятности следующего токена, но параметры не меняет. Расход зависит от размера весов, длины входа и ответа, кэша контекста и числа одновременных пользователей.
Для локального запуска важны объём VRAM/RAM, пропускная способность и время загрузки. Для API добавляются сетевой путь, тариф токенов, лимиты и возможная очередь провайдера. Один и тот же checkpoint может иметь разную задержку в разных движках.
Минимальный бенчмарк inference
Зафиксируйте модель, формат запроса и длину контекста. Измерьте четыре точки: время до первого токена, скорость после прогрева, полную задержку и пиковую память. Повторите тест с пустым кэшем, после прогрева и при двух-трёх параллельных запросах.
| Режим | Что измеряем | Что может исказить вывод |
|---|---|---|
| Холодный старт | загрузка весов и первый токен | медленный диск |
| Прогретый одиночный | скорость генерации | слишком короткий ответ |
| Параллельный | очередь и стабильность | размер батча |
| Длинный контекст | KV-cache и пик памяти | скрытое усечение входа |
Не сравнивайте только токены в секунду. Быстрый ответ, который требует трёх повторов и долгой проверки, может проиграть более медленной модели по времени до принятого результата.
Батч и интерактивный поток
Одиночный запрос удобен для чата, а батч объединяет несколько входов и лучше загружает ускоритель. Цена — ожидание самого медленного элемента и сложнее обработка ошибок. Для редакционного конвейера выбирайте размер батча по допустимой задержке и числу операторов, а не по максимальной загрузке GPU.
Проверьте очередь, тайм-аут и повтор. При перегрузке система должна вернуть понятный статус и сохранить исходный запрос, а не запускать бесконечные дубли. Для агента отделите inference от выполнения функции: модель предлагает параметры, приложение проверяет права и диапазоны.
Память, кэш и квантование
Память расходуется на веса, промежуточные вычисления и KV-cache. Квантование уменьшает размер весов, но может ухудшить редкие слова, числа и код. Подкачка части модели в RAM снижает требования к VRAM и одновременно увеличивает задержку. Поэтому тестируйте тот формат, который реально будет использоваться в продакшене.
Кэширование стабильного префикса уменьшает повторные вычисления, но персональные данные и секреты нельзя помещать в общий кэш без политики доступа. При изменении системной инструкции очищайте или версионируйте кэш, иначе старый контекст исказит сравнение.
Как обучение меняет inference
После дообучения повторите не только тест качества, но и производительности. Новый адаптер может изменить длину ответа, формат токенизации, поведение отказа или расход памяти. Дистилляция переносит поведение в меньшую модель, а квантование сжимает существующие веса — это разные компромиссы и разные источники ошибок.
Храните базовую модель, адаптер и конфигурацию запуска. Новую версию сначала включайте в теневом режиме, сравнивая ответы без влияния на пользователей. При ухудшении фактов, отказов или задержки возвращайтесь к предыдущей версии.
Проверка качества на новых данных
Закрытая выборка должна содержать опечатки, длинный контекст, отрицательные примеры и запросы вне области. Оценивайте факты, формат, корректные отказы и число ручных исправлений. Для каждого сбоя укажите слой: данные, инструкция, модель или инфраструктура. Не лечите инфраструктурную задержку расширением датасета.
Стоимость владения
Для своего сервера учитывайте железо, электричество, охлаждение, обновления и время поддержки. Для API — входные и выходные токены, повторы, хранение и сеть. Сравнивайте стоимость принятого результата с ручным процессом, а не цену одной генерации. Ночная пакетная обработка может быть выгоднее интерактивного режима даже при той же модели.
Безопасность и обновления
Ограничьте размер запроса, время выполнения и права функций. Логи храните с техническими метаданными, но без секретов и исходных персональных документов. После обновления драйвера, движка, модели или промпта запускайте контрольный набор заново: изменение задержки может быть инфраструктурным, а изменение ответа — модельным.
Итоговый чек-лист
- Обучение и inference разделены по ответственности.
- Сохранены версии модели, датасета и движка.
- Измерены холодный старт, прогрев, параллельная нагрузка и контекст.
- Учтены батч, KV-cache, квантование и подкачка.
- Качество проверено на закрытой выборке.
- Стоимость включает повторы и поддержку.
- Вызовы функций проходят валидацию прав.
- Обновления имеют теневой запуск и план отката.
Как читать метрики без самообмана
Разделите отчёт на три строки: модель, окружение и процесс. Для модели укажите качество и корректные отказы; для окружения — память, задержку и очередь; для процесса — число повторов, ручных исправлений и стоимость принятого результата. Если всё свести к одной средней скорости, станет незаметно, что ускорение произошло за счёт более частых ошибок.
Сравнивайте версии на одном зафиксированном наборе запросов и не меняйте одновременно движок, размер батча и системную инструкцию. Отдельно отметьте холодный запуск: он важен для редких задач, но не должен смешиваться с прогретым интерактивным сценарием. После изменения модели повторите минимум один отрицательный тест — запрос вне области должен приводить к аккуратному отказу, а не к быстрому выдуманному ответу.
Такой отчёт помогает выбрать следующий шаг. Рост задержки при прежнем качестве требует работы с очередью или кэшем; падение качества при той же скорости — проверки датасета, промпта и версии весов. Не стоит лечить разные причины одной настройкой, иначе эксперимент перестаёт быть воспроизводимым.
Обучение меняет параметры, inference использует их на новых данных. Понимание этой границы помогает не путать проблему качества с проблемой задержки и строить измеримый, а не рекламный процесс эксплуатации.