От дообучения до GPU-ядер: как улучшать LLM на разных уровнях

При supervised fine-tuning, или SFT, модель обучается на подготовленных примерах. Для прикладного ассистента это могут быть запрос, контекст и качественный ответ: структура JSON, вызов инструмента, объяснение решения. Функция потерь увеличивает вероятность целевых токенов. Такой подход позволяет адаптировать поведение модели к задаче. В TRL можно обучать только на ответах ассистента, исключая пользовательские и системные сообщения из расчёта потерь. Документация TRL: SFT Trainer.

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

SFT и RL относятся к дообучению. Слово «дообучение» обозначает этап изменения модели после исходного обучения, а не один конкретный алгоритм.

В обучении с подкреплением модель генерирует ответы, получает оценку и обновляет параметры с учётом этого сигнала. Например, в GRPO для одного запроса создаётся группа ответов; их награды сравниваются внутри группы, чтобы оценить относительное преимущество. Отдельная модель ценности в базовой схеме GRPO не требуется. Награду может возвращать программная проверка, а не только другая нейросеть. Документация TRL: GRPO Trainer.

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

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

Возьмём условный сервис: двадцать одновременных пользователей, входы примерно по четыре тысячи токенов и ответы до пятисот токенов. Агент должен выдавать проверяемые преобразования данных. Эти числа описывают нагрузку для мысленного эксперимента; они не являются результатами проекта Exsada.

Для такого сервиса предлагаем вести два независимых набора метрик. Первый описывает результат: долю пройденных скрытых тестов, ошибки формата и корректные отказы. Второй описывает исполнение: время до первого токена, задержку между токенами, полное время ответа и пиковую память GPU. Для задержек полезны медиана и p95, чтобы видеть поведение под нагрузкой.

В RL-эксперименте стоит отдельно засекать генерацию кандидатов, работу проверяющего кода и обновление параметров. Если основное время занимает запуск тестов, ускорение одной операции модели почти не изменит длительность эксперимента. Это определяет следующий шаг: оптимизировать измеренное узкое место.

Под «кернелизацией» здесь понимается оптимизация вычислительных GPU-ядер: небольших программ, исполняющих операции над тензорами. Один из приёмов — fusion, объединение нескольких операций. Оно позволяет сократить число запусков ядер и промежуточных чтений и записей в память. Компилятор torch.compile может выполнять такое объединение автоматически, в том числе через Triton. PyTorch: как работает kernel fusion.

FlashAttention показывает другой аспект этой задачи: блочная организация вычислений уменьшает обмен между уровнями памяти GPU при вычислении attention. Алгоритм сохраняет точную математическую операцию attention, хотя порядок вычислений с плавающей точкой может давать численные расхождения. Это оптимизация исполнения, которую можно использовать в обучении и инференсе. Оригинальная работа FlashAttention.

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

При генерации трансформер хранит промежуточные ключи и значения attention в KV-cache. С ростом контекста и числа запросов этот кэш занимает существенную память. PagedAttention разбивает его на блоки и уменьшает потери от фрагментации и дублирования. В vLLM это сочетается с планированием запросов: освободившееся место можно использовать для новой работы, не ожидая завершения всей исходной группы. Оригинальная работа PagedAttention и vLLM.

Общий префикс запросов даёт ещё одну возможность. Prefix caching повторно использует рассчитанный KV-cache совпадающей начальной части входа. Это сокращает обработку входного контекста — prefill. Генерацию новых токенов, decode, этот механизм непосредственно не ускоряет. Польза зависит от повторяемости префиксов и соотношения длин входа и ответа. vLLM: Automatic Prefix Caching.

В нашем условном сервисе стоит сравнить одинаковые запросы с общим системным префиксом и без него. Отдельно — менять допустимую параллельность, наблюдая за пропускной способностью и p95. Максимум обработанных токенов и комфортное ожидание отдельного пользователя нужно оценивать совместно.

Квантизация уменьшает точность представления чисел, позволяя сократить занимаемую память. В зависимости от метода она затрагивает веса, активации или KV-cache. Поддержка конкретных форматов и реализаций зависит от оборудования и вычислительного backend. Поэтому название формата само по себе не определяет выигрыш на выбранном GPU. vLLM: квантизация и совместимость.

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

Для описанного сценария предлагаем следующую последовательность:

• Зафиксировать модель, набор задач, параметры генерации, оборудование и исходные метрики.
• Проверить SFT на качественных примерах, если требуется изменить формат или последовательность действий.
• Проверить RL, если есть надёжный сигнал результата и бюджет на генерацию и оценку кандидатов.
• По профилю нагрузки сравнить компиляцию, ядра, планирование запросов, кэширование и квантизацию.
• Повторить оценку качества и нагрузочный прогон для итоговой конфигурации, сохранив исходную как контроль.

В карточке эксперимента достаточно одной проверяемой гипотезы: какое ограничение меняем, каким измерением подтвердим эффект и какое ухудшение считаем неприемлемым. Тогда решение о следующем шаге опирается на результат конкретной системы.