Инференс нейросети: что происходит после запуска модели

Обучение подбирает параметры модели, а инференс применяет их к новому запросу. Но в продукте это не одна математическая операция. До модели стоят проверка входа и очередь, после — декодирование, валидация формата, фильтры и сохранение результата.

Выбор размера разобран в статье про малые языковые модели, локальная установка — в руководстве локальная нейросеть. Здесь настраиваем сам путь запроса под нагрузкой.

Параметры batching, кэша и квантования зависят от выбранного рантайма. Сверяйте их с официальной документацией версии, которую реально разворачиваете.

Нарисуйте путь запроса

Сначала очертите рабочий объект: этапы от API до готового ответа. Инференс — эксплуатация уже обученной модели, где качество встречается с ограничениями времени и ресурсов. Ошибка «всю задержку приписывают модели» здесь означает, что действие «поставить таймеры на каждый участок» запускают без исходного доказательства «трассировка запроса».

• Рабочее действие: поставить таймеры на каждый участок.
• Сохраняемый артефакт: трассировка запроса.
• Контрольная ситуация: очередь занимает больше времени, чем вычисление.
• Показатель решения: доля времени по этапам.

До настройки сохраните трассировка запроса для объекта «этапы от API до готового ответа». Затем выполните «поставить таймеры на каждый участок» и разберите случай «очередь занимает больше времени, чем вычисление». Этап «Нарисуйте путь запроса» принят, если инженер платформы подтверждает показатель «доля времени по этапам», а риск «всю задержку приписывают модели» не проявляется на пограничной выборке.

За этот участок отвечает инженер платформы. В журнале он связывает объект «этапы от API до готового ответа» с артефактом «трассировка запроса», записывает версию входных данных, условия запуска и принятое решение. Если показатель «доля времени по этапам» улучшается ценой нового риска «всю задержку приписывают модели», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «поставить таймеры на каждый участок» должен воспроизводиться на примере «очередь занимает больше времени, чем вычисление».

Разберите пример отдельно: очередь занимает больше времени, чем вычисление. Полезно попросить второго специалиста повторить шаг «поставить таймеры на каждый участок» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «этапы от API до готового ответа» владелец «инженер платформы» сверяет артефакт «трассировка запроса» с метрикой «доля времени по этапам».

Разделите холодный и тёплый старт

Этап «Разделите холодный и тёплый старт» рассматривает загрузка весов и повторный вызов. Инференс — эксплуатация уже обученной модели, где качество встречается с ограничениями времени и ресурсов. Сбой возникает, когда первый запрос смешивают с обычными; поэтому сначала готовят профиль старта, а затем выполняют «измерять режимы отдельно».

• Рабочее действие: измерять режимы отдельно.
• Сохраняемый артефакт: профиль старта.
• Контрольная ситуация: редко используемая модель выгружается из памяти.
• Показатель решения: время загрузки и тёплый p95.

Раздел «Разделите холодный и тёплый старт» проверяют обратным порядком: сначала фиксируют риск «первый запрос смешивают с обычными», затем воспроизводят «редко используемая модель выгружается из памяти» и только после этого выполняют «измерять режимы отдельно». Вывод опирается на профиль старта; метрику «время загрузки и тёплый p95» подписывает SRE.

За этот участок отвечает SRE. В журнале он связывает объект «загрузка весов и повторный вызов» с артефактом «профиль старта», записывает версию входных данных, условия запуска и принятое решение. Если показатель «время загрузки и тёплый p95» улучшается ценой нового риска «первый запрос смешивают с обычными», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «измерять режимы отдельно» должен воспроизводиться на примере «редко используемая модель выгружается из памяти».

Разберите пример отдельно: редко используемая модель выгружается из памяти. Полезно попросить второго специалиста повторить шаг «измерять режимы отдельно» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «загрузка весов и повторный вызов» владелец «SRE» сверяет артефакт «профиль старта» с метрикой «время загрузки и тёплый p95».

Считайте первый токен

Для раздела «Считайте первый токен» рабочая граница — время до начала потокового ответа. Риск формулируется как «быстрый первый символ скрывает длинное завершение». Инференс — эксплуатация уже обученной модели, где качество встречается с ограничениями времени и ресурсов. Проверяемый ход — мерить TTFT и total latency, результат фиксируется в артефакте «отчёт двух задержек».

• Рабочее действие: мерить TTFT и total latency.
• Сохраняемый артефакт: отчёт двух задержек.
• Контрольная ситуация: чат начинает быстро, но дописывает минуту.
• Показатель решения: TTFT и полное время.

Для объекта «время до начала потокового ответа» соберите обычный, крайний и ошибочный вход. Действие «мерить TTFT и total latency» должно дать проверяемый отчёт двух задержек. В сценарии «чат начинает быстро, но дописывает минуту» роль продуктовый аналитик принимает решение по значению «TTFT и полное время» и отдельно записывает, возник ли риск «быстрый первый символ скрывает длинное завершение».

За этот участок отвечает продуктовый аналитик. В журнале он связывает объект «время до начала потокового ответа» с артефактом «отчёт двух задержек», записывает версию входных данных, условия запуска и принятое решение. Если показатель «TTFT и полное время» улучшается ценой нового риска «быстрый первый символ скрывает длинное завершение», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «мерить TTFT и total latency» должен воспроизводиться на примере «чат начинает быстро, но дописывает минуту».

Разберите пример отдельно: чат начинает быстро, но дописывает минуту. Полезно попросить второго специалиста повторить шаг «мерить TTFT и total latency» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «время до начала потокового ответа» владелец «продуктовый аналитик» сверяет артефакт «отчёт двух задержек» с метрикой «TTFT и полное время».

Настройте batching

Исходная точка пункта «Настройте batching»: объединение запросов в пакет. До изменения сохраните нагрузочный тест. Если сразу перейти к шагу «построить кривую throughput—latency», может проявиться ошибка «крупный batch ухудшает ожидание одного пользователя». Инференс — эксплуатация уже обученной модели, где качество встречается с ограничениями времени и ресурсов.

• Рабочее действие: построить кривую throughput—latency.
• Сохраняемый артефакт: нагрузочный тест.
• Контрольная ситуация: ночная обработка использует пакет, чат — малый batch.
• Показатель решения: запросы в секунду при p95.

Приёмка этапа «Настройте batching» начинается с независимого повтора. Второй специалист получает нагрузочный тест, применяет «построить кривую throughput—latency» к контуру «объединение запросов в пакет» и сверяет «запросы в секунду при p95». Случай «ночная обработка использует пакет, чат — малый batch» считается обязательным; ошибка «крупный batch ухудшает ожидание одного пользователя» останавливает выпуск.

За этот участок отвечает инженер производительности. В журнале он связывает объект «объединение запросов в пакет» с артефактом «нагрузочный тест», записывает версию входных данных, условия запуска и принятое решение. Если показатель «запросы в секунду при p95» улучшается ценой нового риска «крупный batch ухудшает ожидание одного пользователя», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «построить кривую throughput—latency» должен воспроизводиться на примере «ночная обработка использует пакет, чат — малый batch».

Разберите пример отдельно: ночная обработка использует пакет, чат — малый batch. Полезно попросить второго специалиста повторить шаг «построить кривую throughput—latency» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «объединение запросов в пакет» владелец «инженер производительности» сверяет артефакт «нагрузочный тест» с метрикой «запросы в секунду при p95».

Управляйте очередью

В задаче «Управляйте очередью» ожидаемый объект — приоритеты, лимиты и отказ. Инференс — эксплуатация уже обученной модели, где качество встречается с ограничениями времени и ресурсов. Команда отдельно записывает опасение «длинные задачи блокируют интерактивные», выполняет «разделить классы нагрузки» и оставляет политика очереди для повторной проверки.

• Рабочее действие: разделить классы нагрузки.
• Сохраняемый артефакт: политика очереди.
• Контрольная ситуация: отчёт получает низший приоритет, чем ответ клиенту.
• Показатель решения: время ожидания по классам.

Не демонстрируйте раздел «Управляйте очередью» на одном удобном примере. Возьмите «отчёт получает низший приоритет, чем ответ клиенту», сохраните политика очереди и попросите роль владелец сервиса выполнить «разделить классы нагрузки». Решение по объекту «приоритеты, лимиты и отказ» принимают по метрике «время ожидания по классам», учитывая риск «длинные задачи блокируют интерактивные».

За этот участок отвечает владелец сервиса. В журнале он связывает объект «приоритеты, лимиты и отказ» с артефактом «политика очереди», записывает версию входных данных, условия запуска и принятое решение. Если показатель «время ожидания по классам» улучшается ценой нового риска «длинные задачи блокируют интерактивные», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «разделить классы нагрузки» должен воспроизводиться на примере «отчёт получает низший приоритет, чем ответ клиенту».

Разберите пример отдельно: отчёт получает низший приоритет, чем ответ клиенту. Полезно попросить второго специалиста повторить шаг «разделить классы нагрузки» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «приоритеты, лимиты и отказ» владелец «владелец сервиса» сверяет артефакт «политика очереди» с метрикой «время ожидания по классам».

Используйте кэш осторожно

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

• Рабочее действие: определить ключ и срок.
• Сохраняемый артефакт: тест изоляции.
• Контрольная ситуация: общая справка кэшируется, персональный контекст — нет.
• Показатель решения: hit rate и ошибки изоляции.

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

За этот участок отвечает специалист безопасности. В журнале он связывает объект «повторяемые безопасные части запроса» с артефактом «тест изоляции», записывает версию входных данных, условия запуска и принятое решение. Если показатель «hit rate и ошибки изоляции» улучшается ценой нового риска «ответ другого пользователя возвращается из кэша», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «определить ключ и срок» должен воспроизводиться на примере «общая справка кэшируется, персональный контекст — нет».

Разберите пример отдельно: общая справка кэшируется, персональный контекст — нет. Полезно попросить второго специалиста повторить шаг «определить ключ и срок» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «повторяемые безопасные части запроса» владелец «специалист безопасности» сверяет артефакт «тест изоляции» с метрикой «hit rate и ошибки изоляции».

Контролируйте память

На собственном материале проверьте веса, KV-cache и параллельные сессии. Инференс — эксплуатация уже обученной модели, где качество встречается с ограничениями времени и ресурсов. Если возникает «одна длинная сессия вытесняет остальные», вернитесь к шагу «ставить лимиты контекста» и пересоберите профиль памяти, не меняя одновременно остальные условия.

• Рабочее действие: ставить лимиты контекста.
• Сохраняемый артефакт: профиль памяти.
• Контрольная ситуация: рост одновременных чатов заполняет VRAM.
• Показатель решения: пик памяти на сессию.

В разделе «Контролируйте память» сравните две версии на одинаковом входе «рост одновременных чатов заполняет VRAM». Свидетельство профиль памяти связывает объект «веса, KV-cache и параллельные сессии» с действием «ставить лимиты контекста». Итоговый показатель — «пик памяти на сессию»; владелец DevOps отдельно проверяет ошибку «одна длинная сессия вытесняет остальные».

За этот участок отвечает DevOps. В журнале он связывает объект «веса, KV-cache и параллельные сессии» с артефактом «профиль памяти», записывает версию входных данных, условия запуска и принятое решение. Если показатель «пик памяти на сессию» улучшается ценой нового риска «одна длинная сессия вытесняет остальные», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «ставить лимиты контекста» должен воспроизводиться на примере «рост одновременных чатов заполняет VRAM».

Разберите пример отдельно: рост одновременных чатов заполняет VRAM. Полезно попросить второго специалиста повторить шаг «ставить лимиты контекста» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «веса, KV-cache и параллельные сессии» владелец «DevOps» сверяет артефакт «профиль памяти» с метрикой «пик памяти на сессию».

Проверяйте декодирование

Владельца для этапа «Проверяйте декодирование» назначают до работы с объектом «температура, stop-токены и длина». Инференс — эксплуатация уже обученной модели, где качество встречается с ограничениями времени и ресурсов. Он не допускает ошибку «бесконечная генерация съедает очередь», требует выполнить «ограничить выход и условия остановки» и принять набор тестов завершения.

• Рабочее действие: ограничить выход и условия остановки.
• Сохраняемый артефакт: набор тестов завершения.
• Контрольная ситуация: JSON заканчивается до поясняющего текста.
• Показатель решения: доля корректных остановок.

Для решения по этапу «Проверяйте декодирование» недостаточно слов автора. Сначала роль ML-инженер получает набор тестов завершения, затем повторяет «ограничить выход и условия остановки» и проверяет объект «температура, stop-токены и длина» на ситуации «JSON заканчивается до поясняющего текста». Метрика «доля корректных остановок» принимается только без проявления риска «бесконечная генерация съедает очередь».

За этот участок отвечает ML-инженер. В журнале он связывает объект «температура, stop-токены и длина» с артефактом «набор тестов завершения», записывает версию входных данных, условия запуска и принятое решение. Если показатель «доля корректных остановок» улучшается ценой нового риска «бесконечная генерация съедает очередь», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «ограничить выход и условия остановки» должен воспроизводиться на примере «JSON заканчивается до поясняющего текста».

Разберите пример отдельно: JSON заканчивается до поясняющего текста. Полезно попросить второго специалиста повторить шаг «ограничить выход и условия остановки» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «температура, stop-токены и длина» владелец «ML-инженер» сверяет артефакт «набор тестов завершения» с метрикой «доля корректных остановок».

Валидируйте ответ

Контрольный пример раздела «Валидируйте ответ» должен раскрывать схема, права и допустимый результат. Риск — сырой вывод сразу выполняет действие. Инференс — эксплуатация уже обученной модели, где качество встречается с ограничениями времени и ресурсов. Пример проходит действие «добавить проверку и подтверждение», после чего команда получает журнал отклонений.

• Рабочее действие: добавить проверку и подтверждение.
• Сохраняемый артефакт: журнал отклонений.
• Контрольная ситуация: невалидная команда не доходит до инструмента.
• Показатель решения: доля заблокированных опасных выходов.

Контроль «Валидируйте ответ» включите в регрессионный набор. Он хранит журнал отклонений, вход «невалидная команда не доходит до инструмента» и ожидаемую величину «доля заблокированных опасных выходов». При повторе действия «добавить проверку и подтверждение» специалист владелец интеграции должен подтвердить объект «схема, права и допустимый результат» и отсутствие сбоя «сырой вывод сразу выполняет действие».

За этот участок отвечает владелец интеграции. В журнале он связывает объект «схема, права и допустимый результат» с артефактом «журнал отклонений», записывает версию входных данных, условия запуска и принятое решение. Если показатель «доля заблокированных опасных выходов» улучшается ценой нового риска «сырой вывод сразу выполняет действие», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «добавить проверку и подтверждение» должен воспроизводиться на примере «невалидная команда не доходит до инструмента».

Разберите пример отдельно: невалидная команда не доходит до инструмента. Полезно попросить второго специалиста повторить шаг «добавить проверку и подтверждение» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «схема, права и допустимый результат» владелец «владелец интеграции» сверяет артефакт «журнал отклонений» с метрикой «доля заблокированных опасных выходов».

Считайте стоимость нагрузки

Свяжите пункт «Считайте стоимость нагрузки» с решением человека о контуре «оборудование или тариф на реальном профиле». Инференс — эксплуатация уже обученной модели, где качество встречается с ограничениями времени и ресурсов. Без шага «моделировать p50 и p95 длины» и артефакта «калькуляция месяца» нельзя исключить ошибку «стоимость выводят из одного короткого запроса».

• Рабочее действие: моделировать p50 и p95 длины.
• Сохраняемый артефакт: калькуляция месяца.
• Контрольная ситуация: длинные документы дают основную часть расходов.
• Показатель решения: стоимость тысячи успешных задач.

Перед закрытием пункта «Считайте стоимость нагрузки» воспроизведите цепочку: оборудование или тариф на реальном профиле; моделировать p50 и p95 длины; калькуляция месяца. На примере «длинные документы дают основную часть расходов» измерьте «стоимость тысячи успешных задач». Роль финансовый владелец выбирает запуск, исправление или отказ, если обнаруживается риск «стоимость выводят из одного короткого запроса».

За этот участок отвечает финансовый владелец. В журнале он связывает объект «оборудование или тариф на реальном профиле» с артефактом «калькуляция месяца», записывает версию входных данных, условия запуска и принятое решение. Если показатель «стоимость тысячи успешных задач» улучшается ценой нового риска «стоимость выводят из одного короткого запроса», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «моделировать p50 и p95 длины» должен воспроизводиться на примере «длинные документы дают основную часть расходов».

Разберите пример отдельно: длинные документы дают основную часть расходов. Полезно попросить второго специалиста повторить шаг «моделировать p50 и p95 длины» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «оборудование или тариф на реальном профиле» владелец «финансовый владелец» сверяет артефакт «калькуляция месяца» с метрикой «стоимость тысячи успешных задач».

Матрица приёмки

Что изучить дальше

• малые языковые модели
• локальная нейросеть
• токенизация текста
• контекстное окно
• большие языковые модели
• системный промпт
• аудит ИИ-систем

Чек-лист запуска