Как работает инференс LLM: внимание, KV-кеш и рассуждения

Один запрос — несколько инженерных задач

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

В статье рассматривается авторегрессионный Transformer с архитектурой decoder-only, на которой построены многие используемые текстовые модели. Мультимодальные энкодеры, слои mixture-of-experts и другие архитектуры обработки последовательностей добавляют свои особенности. Приведённые расчёты — явно заданные примеры, а не результаты измерений системы Nikba.

От диалога к распределению вероятностей следующего токена

Приложение сериализует инструкции, сообщения диалога, найденные документы и результаты инструментов в формат, ожидаемый моделью. Токенизатор преобразует это представление в идентификаторы токенов. Границы зависят от токенизатора: слово, фрагмент кода или выражение на другом языке могут занимать несколько токенов.

Модель объединяет представления токенов с информацией о позиции и преобразует их через последовательные слои. В причинном механизме самовнимания позиция может учитывать предыдущие позиции и саму себя, а будущие позиции маскируются. Проекции query, key и value определяют вклад информации из доступных позиций в текущее представление.

Attention(Q, K, V) = softmax(QKᵀ / √dₖ + causal_mask)V

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

У prefill и декодирования разные узкие места

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

Поэтому время до первого токена и число выходных токенов в секунду характеризуют разные этапы работы. Очередь запросов, поиск документов, передача по сети и операции приложения также влияют на задержку для пользователя. Быстрый декодер не компенсирует перегруженную очередь. Анализ инференса от NVIDIA описывает вычислительные ограничения и расход памяти на этих этапах.

Для условного ассистента по документам измеряйте поиск отдельно от prefill модели. Если и короткие, и длинные ответы начинаются с задержкой, проверяйте очередь, поиск и длину входа. Если первый токен появляется быстро, но завершение затягивается, проверяйте длину ответа, скорость декодирования и число одновременных запросов. Это диагностические гипотезы, которые нужно сопоставлять с трассировками выполнения.

KV-кеш сокращает повторные вычисления за счёт памяти

При авторегрессионном инференсе можно сохранять ранее вычисленные ключи и значения, а не пересчитывать их на каждом шаге. KV-кеш — оптимизация инференса. Это не хранилище проверенных фактов, не база знаний компании и не замена контексту модели.

Для модели с полным вниманием первую оценку объёма кеша одной последовательности можно получить так:

Память KV в байтах ≈ 2 × слои × сохранённые_токены × головы_KV × размерность_головы × байты_на_элемент

Допущения примера:
32 слоя × 32 768 токенов × 8 голов KV × 128 измерений
2 массива (K и V), в каждом по 2 байта на элемент

2 × 32 × 32 768 × 8 × 128 × 2 = 4 294 967 296 байт ≈ 4 GiB

Оценка не включает веса модели, активации, накладные расходы распределения памяти и другие запросы. Иные схемы внимания, форматы кеша и квантование меняют результат. Расчёт объясняет, почему модель, помещающаяся в память ускорителя, всё же может не справиться с несколькими одновременными длинными диалогами. Документация Hugging Face о стратегиях кеширования описывает варианты с разными требованиями к памяти, задержке и компиляции; выбор зависит от нагрузки сервера.

Декодирование управляет вариативностью, а не достоверностью

Жадное декодирование на каждом шаге выбирает токен с максимальной оценкой. Сэмплирование добавляет вариативность; температура и фильтрация кандидатов изменяют распределение для выбора. Низкая температура не превращает правдоподобное утверждение в проверенный факт. Повторяемый ответ по-прежнему может содержать фактическую ошибку.

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

Спекулятивное декодирование позволяет предложить несколько токенов и проверить их целевой моделью. Алгоритмы с сохранением распределения могут ускорить генерацию, не меняя целевое распределение, но скорость зависит от доли принятых предложений и накладных расходов сервера. Универсального множителя ускорения нет. Метод описан в работе о спекулятивном декодировании.

Рассуждения добавляют ещё один бюджет инференса

Некоторые модели рассуждений обучены разворачивать промежуточную генерацию перед выдачей ответа. DeepSeek-R1 — документированный пример применения обучения с подкреплением к такому поведению. Этот результат не доказывает, что любая задача выигрывает от более долгого рассуждения или что сгенерированное объяснение точно отражает внутренние вычисления модели.

В продукте сравнивайте бюджеты рассуждений на типичных задачах. Классификация с жёсткими ограничениями и многоэтапное планирование могут требовать разных настроек. Сопоставляйте дополнительную задержку и стоимость с долей правильных, пригодных к использованию результатов. Включайте случаи, когда системе следует запросить недостающие данные или отказаться от неподтверждённого утверждения.

Что измерить до выбора более крупной модели

Подготовьте небольшой версионируемый набор запросов: короткие обращения, длинные документы, код, многоязычный ввод и ожидаемые результаты инструментов. Проверяйте его при реалистичном числе одновременных запросов. Записывайте время в очереди, входные и выходные токены, время до первого токена, задержку завершения, нагрузку на память и успешность задачи. Анализируйте p50 и p95 задержки, чтобы средние значения не скрывали медленные запросы.

Меняйте по одному фактору: модель, длину контекста, найденные материалы, настройки декодирования или конфигурацию сервера. Пример критерия приёмки — засчитывать только правильный ответ с подходящим подтверждающим источником. Численный порог следует определять по требованиям продукта и исходным измерениям, а не по универсальному целевому числу токенов в секунду.

Следующее архитектурное решение разбирается в статье RAG или fine-tuning. Для систем, выполняющих действия, читайте о надёжных AI-агентах.