Топ вопросов с NLP собеседований: архитектуры LLM, инференс и оптимизация

На NLP/LLM собеседованиях все чаще проверяют не только знание трансформеров, но и понимание того, как устроены современные GPT-like модели: почему большинство генеративных LLM используют decoder-only архитектуру, чем LLaMA отличается от ванильного Transformer, зачем нужны RoPE, RMSNorm, SwiGLU и GQA. Почему инференс LLM дорогой и какие оптимизации помогают его ускорять.

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

Содержание:

• Современные архитектуры LLM и их особенности

  • Pre-Norm, RMSNorm

  • SwiGLU, MoE

• Почему инференс LLM дорогой

  • compute / memory bound

  • prefill, decode stage

• Способы ускорения инференса

  • kv-cache, paged attention

  • continuous batching, speculative decoding

  • квантизация, дистилляция

• Итоговый чеклист вопросов с собесов

• Полезные материалы

Какие LLM бывают?

Большинство современных генеративных LLM — это decoder-only трансформеры. Внутри них выделяют разные семейства моделей: GPT, LLaMA, Mistral, Qwen, Gemma и др.

Они отличаются друг от друга (и в том числе от моделей из своего же семейства) по разным параметрам:

• открытая или проприетарная модель

  • во многих компаниях служба безопасности не дает разрешение на использования llm по api из-за передачи чувствительных данных — так что возникает необходимость разворачивать open-source модель внутри контура компании

• количество параметров

LLM бывают в размерах от нескольких сотен млн параметров до сотен млрд. Выбор конретного размера будет зависеть от ваших ресурсов и требований к скорости и качеству.

• детали архитектуры (раскроем ниже в статье)

  • Dense или MoE

  • тип attention

  • тип нормализации

  • тип positional encoding

  • особенности MLP

Это напрямую влияет на качество / скорость LLM. Многие видеокарты и фреймворки обучения/инференса специально оптимизируют свой перфоманс для конкретных архитектур.

• длина контекстного окна

  • У всех трансформерных архитектур есть ограничение на длину токенизированного текста, например, 4k, 8k, 32k, 128k токенов и больше.

  • Длина контекста для модели критична важна:

    • качество: способность переваривать длинные тексты без нарезки на чанки и потери важного смысла

    • скорость: с длинной контекста количество вычислений растет квадратично из-за механизма внимания

• поддержка мультимодальности

  • Например, отвечать на вопросы по изображению, читать текст на картинке, анализировать скриншоты, описывать происходящее на фото, связывать визуальный контекст с текстовой инструкцией

  • Это требует дополнительных компонентов: vision encoder, projection layer, специальные токены или другой способ передать визуальные признаки в LLM

• особенности обучения

  • код

  • математика

  • общие способности

  • сила алаймента на безопасность / открытость

• лицензия

  • возможность коммерческого использования / типа задач

  • или только под ресерч

  • ограничения по размеру компании / числу пользователей

• точность весов (раскроем ниже в статье)

  • некоторые модели уже доступны с разными вариантами квантизации — это трейд офф между скоростью и качеством

Чем современные LLM отличаются от классического Transformer?

Если грубо и коротко:

• Больше параметров

• Pre-Norm вместо Post-Norm

• RMSNorm вместо LayerNorm

• SwiGLU или другой gated FFN вместо простого ReLU/GELU FFN

• RoPE вместо абсолютных позиционных эмбеддингов

• MQA/GQA вместо полного Multi-Head Attention

• иногда MoE вместо dense FFN

• увеличенная длина контекста

• оптимизации под эффективный inference

То есть современные LLM — это концептуально все тот же трансформер, но в котором больше инженерных изменений под стабильное обучение, длинный контекст и быстрый инференс.

Ну и конечно: больше данных во время обучения, больше мощных GPU.

Зачем нужен Pre-Norm и чем он отличается от Post-Norm?

• Post-Norm

нормализация применяется после основного блока и residual connection

• Pre-Norm

нормализация применяется до основного преобразования

Pre-Norm часто стабильнее при обучении глубоких трансформеров. Градиенту проще проходить через residual path, поэтому большие модели обучаются устойчивее.

Чем RMSNorm отличается от LayerNorm?

LayerNorm нормализует hidden state через среднее и дисперсию:

RMSNorm не вычитает среднее, а нормализует вектор через корень из среднего квадратов:

Где:

• — размерность hidden state

• — компонента вектора

• — обучаемый scale

• — маленькая константа для стабильности

LayerNorm центрирует и масштабирует вектор, а RMSNorm только масштабирует его по длине.

RMSNorm дешевле вычислительно. Для больших LLM, где нормализация применяется в каждом блоке и на каждом токене, даже такая оптимизация имеет значение.

Что такое SwiGLU и зачем в LLM используют gated-активации?

В стандартном, «ванильном» MLP 2 линейных слоя и нелинейность, например, gelu между ними.

import torchfrom torch import nnimport torch.nn.functional as Fclass StandardFFN(nn.Module):    def __init__(self, d_model: int, d_ff: int) -> None:        super().__init__()        self.up_proj = nn.Linear(d_model, d_ff, bias=False)        self.down_proj = nn.Linear(d_ff, d_model, bias=False)    def forward(self, x: torch.Tensor) -> torch.Tensor:        hidden = self.up_proj(x)        hidden = F.gelu(hidden)        output = self.down_proj(hidden)        return output

В gated активациях появляются две ветки:

• одна ветка вычисляет признаки

• вторая ветка работает как gate и управляет тем, какие признаки пропускать дальше

Один из популярных вариантов — SwiGLU

Где:

• — гладкая нелинейная функция (создаёт признаки)

  • , где — сигмоида

• — поэлементное умножение (масштабирует их как gate)

• — активации с предыдущего слоя

• — параметры в слое функции активации

class SwiGLUFFN(nn.Module):    def __init__(self, d_model: int, d_ff: int) -> None:        super().__init__()        self.gate_proj = nn.Linear(d_model, d_ff, bias=False)        self.up_proj = nn.Linear(d_model, d_ff, bias=False)        self.down_proj = nn.Linear(d_ff, d_model, bias=False)    def forward(self, x: torch.Tensor) -> torch.Tensor:        gate = F.silu(self.gate_proj(x))        values = self.up_proj(x)        hidden = gate * values        output = self.down_proj(hidden)        return output

Gated-активация позволяет MLP-блоку не просто преобразовывать признаки, а динамически регулировать, какие компоненты усиливать или подавлять.

Это делает FFN блок выразительнее. Но есть trade-off — gated FFN обычно требует больше параметров и вычислений, чем простой FFN с ReLU или GELU, потому что вместо 2х линейных слоев добавляет третий gate linear слой.

Что такое MoE?

MoE: Mixture of Experts — это архитектурное улучшение трансформера, где мы часть dense слоёв заменяем набором экспертов. Обычно применимо к FNN блокам.

В MoE вместо одного MLP есть несколько экспертов. Для каждого токена специальный router (линейный слой) выбирает, каких экспертов активировать.

Например:

• всего есть 8 экспертов

• для каждого токена выбираются 2 эксперта (через роутер)

• токен проходит только через выбранных экспертов

• активации после экспертов складываем пропорционально коэффициентам роутера

Для MoE моделей вводят:

• total parameters — все параметры модели

• active parameters — параметры, которые реально используются для конкретного токена

MoE модель может иметь очень много total parameters, но на каждом токене активировать только небольшую часть, это дает качество большой модели при скорости маленькой.

Но у MoE есть проблема того, что роутер может неравномерно распределять токены по экспертам. А также нужно в gpu памяти держать все равно всю модель.

RoPE эмбеддинги, MHA vs MQA

Подробно эти вопросы разбирались в прошлых статьях вместе со всей архитектурой трансформера.

Также чтобы не пропустить выход статей и видео по ML, NLP, LLM, подпишись на мои соц. сети:

• В Telegram канале — регулярный контент по ML и Data Science

• На Ютуб канале — видеоразборы вопросов с собеседований (и по этой статье)

• На Boosty — разборы задач по математике, реальных собеседований и еще больше обучающих материалов

• Полная карта со всем моим контентом

• Вкат с нуля или повышение грейда в ML — менторство

Почему инференс LLM такой вычислительно дорогой?

Инференс LLM требует много вычислений и GPU памяти по нескольким причинам.

• для генерации каждого нового токена нужно прочитать веса модели и выполнить вычисления во всех её слоях. Чем больше модель, тем выше требования к памяти и вычислительной мощности GPU

• генерация идёт авторегрессивно: каждый следующий токен зависит от предыдущего, поэтому весь ответ нельзя вычислить параллельно

• во время генерации хранится kv-кэш для уже обработанных токенов. Его размер растёт вместе с длиной контекста, батчем и числом слоёв модели, ограничивая количество одновременных запросов

• запросы имеют разную длину, поэтому без эффективного batching и управления памятью часть ресурсов GPU может простаивать

При этом разные этапы/фазы инференса упираются в разные ограничения.

Из каких фаз состоит инференс LLM? В чем их отличие?

• prefill (compute-bound)

• decode (memory-bound)

prefill — это этап, когда модель обрабатывает входной prompt по всем токенам, строит hidden states и заполняем начальный kv-cache

• входная последовательность уже известна целиком

• вычисления хорошо параллелятся по токенам

• attention считается по всему prompt-у

• стоимость сильно зависит от длины входного контекста

• bottleneck ближе к compute-bound, особенно на больших батчах и длинных промптах

decode — это этап, когда модель генерирует ответ токен за токеном, каждый следующий токен зависит от предыдущих, поэтому нельзя полностью распараллелить генерацию по времени

• генерация идёт авторегрессивно

• за один шаг обычно появляется один новый токен

• нужно читать веса модели и kv-cache

• bottleneck ближе memory-bound, особенно на небольших батчах

• latency зависит от размера батча, длины контекста, длины генерации

На prefill фазе модель обрабатывает много токенов одновременно, поэтому большие матричные операции хорошо загружают вычислительные блоки GPU. В этом режиме скорость часто ограничена compute throughput.

На decode фазе за шаг обрабатывается лишь один новый токен на последовательность, но при этом нужно читать веса всех слоёв и растущий kv-cache. Поэтому decode при небольшом батче часто ограничен пропускной способностью GPU памяти, то есть становится memory-bound.

Compute-bound означает, что узким местом являются сами вычисления. Данные поступают достаточно быстро, но GPU не успевает выполнять необходимые матричные операции. (данные есть — вычислительные блоки заняты — ждём compute)

Memory-bound означает, что вычислительной мощности GPU достаточно, но она простаивает в ожидании данных из памяти. Узким местом становится пропускная способность HBM. (вычислительные блоки свободны — ждём данные из памяти)

Чем latency отличается от throughput в LLM инференсе?

Latency — сколько времени ждёт конкретный пользователь. Например, в чат ботах важно отвечать в течение 3х секунд. Обычно требует небольшого батча.

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

Для LLM также вводят несколько отдельных метрик:

• TTFT — Time To First Token
  Это время от отправки запроса до первого сгенерированного токена.
  Зависит от prefill фазы.

• TPOT — Time Per Output Token
  Это среднее время генерации одного следующего токена после первого.
  Зависит от decode фазы.

Теперь разберём основные способы ускорения LLM-инференса и то, на какую часть системы влияет каждый из них.

Что такое fused kernels и зачем они нужны?

На GPU есть разные уровни памяти:

• HBM/VRAM — основная память GPU, где хранятся веса модели, активации и kv-кэш

• On-chip память — небольшая, но значительно более быстрая память внутри GPU, в основном реализованная на SRAM:

  • L2-кэш — более быстрая память, общая для вычислительных блоков GPU

  • L1-кэш и shared memory — быстрая память внутри отдельных вычислительных блоков

  • registers — самая быстрая память для локальных значений отдельных потоков

Обычные вычисления происходят так:

1. считываем данные из HBM

2. делаем вычисления

3. результат сохраняем в HBM

4. снова считываем из HBM, в том числе то, что только что сохраняли

5. делаем следующие вычисления

У нас тут очень много чтений и записей между разными видами памяти — это сильно замедляет вычисления.

Чтобы решить эту проблему есть так называемые fused kernels, которые не делают избыточных чтений/записей.

Например, в pytorch (документация) есть torch.compile(model), который возвращает скомпилированную версию модели, что может сильно оптимизировать вычисления.

Flash Attention (FA, 2nd version, 3rd version) — это тоже fused kernel.

Что такое Flash Attention?

Классический attention может много читать и писать промежуточные матрицы в HBM. Это дорого.

Flash Attention оптимизирует вычисление attention так, чтобы меньше гонять данные между HBM и быстрой GPU памятью SRAM.

Идея:

• разбиваем Q, K, V на блоки (tiling)

• считаем attention по блокам

• не материализовываем полную attention matrix в HBM

• храним промежуточные результаты в быстрой SRAM

• считаем softmax блочно, сохраняя численную стабильность (softmax online trick)

Важно, что Flash Attention — это не новый тип attention и не новая архитектура модели. Это алгоритм вычисления точного attention (без какой либо потери в качестве), но существенно более эффективный.

Поэтому везде, где железо позволяет использовать FA — по умолчанию используйте его.

Что такое kv-cache?

kv-cache — одна из главных оптимизаций inference для LLM.

Во время авторегрессивной генерации нужно при каждом следующем шаге генерации токена прогонять через модель весь контекст и заново считать k и v для предыдущих токенов.

Но в self-attention для уже обработанных токенов k и v не меняются, поэтому их можно сохранить.

kv-cache — это сохранение key и value тензоров для уже обработанных токенов, чтобы на следующих decode шагах не пересчитывать их заново.

На каждом decode шаге модель:

• получает новый токен

• считает для него новые q, k, v

• добавляет новые k, v в cache

• считает attention, используя:

  • q — только для текущего токена, которые вот только что посчитали

  • k — для текущего токена + из кэша берем по старым токенам

  • v — для текущего токена + из кэша берем по старым токенам

Но у kv-cache возникает trade off между скоростью и занимаемой памятью. Потому что мы можем закэшировать столько k, v, что не останется GPU памяти под большой батч, длинный контекст и тд.

Поэтому во время выкатки важно подбирать следующие параметры движка инференса:

• максимальную длину контекста

• максимальное число одновременных последовательностей

• максимальное число токенов в batch

• точность kv-cache

• долю GPU памяти, доступную под kv-cache

Упрощённая оценка памяти под KV-cache:

Где:

• — потому что храним и k, и v

• — batch size

• — длина последовательности

• — число слоёв

• — число KV-heads

• — размерность одной головы

• — число байт на одно значение

Из этой формулы видно, почему GQA и MQA важны — они уменьшают , а значит высвобождают больше памяти.

Что такое PagedAttention?

kv-cache ускоряет генерацию, но им нужно эффективно управлять

Представим реальный сервис, у нас будет много запросов, с разным моментом начала и конца генерации, с разной длиной промпта и самого ответа.

Если хранить KV-cache каждого запроса как один большой непрерывный блок памяти, возникают проблемы:

• память выделяется с запасом

• часть памяти простаивает

• появляется фрагментация

• сложно быстро освобождать и переиспользовать память, когда отдельные запросы завершились

Paged Attention решает эту проблему через идею, похожую на виртуальную память в операционных системах.

kv-cache разбивается на блоки, или “страницы”. У каждого запроса есть логическое пространство kv-cache, но физические блоки GPU памяти выделяются динамически.

Paged Attention помогает:

• лучше обслуживать запросы разной длины

• уменьшать потери памяти

• эффективнее использовать GPU память, динамически выделять и высвобождать ее

• повышать throughput

• поддерживать continuous batching

Что такое continuous batching?

В классическом ML инференсе батчинг выглядит просто: накопили несколько запросов, собрали батч, прогнали модель, вернули ответы.

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

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

С continuous batching не нужно ждать, пока завершится весь батч. Можно динамически добавлять новые запросы в работу, а завершившиеся — удалять из батча прямо во время decode фазы.

Конечно, это накладывает следующие трудности:

• нужно управлять kv-cache

• нужно отслеживать активные последовательности

• нужно ограничивать батч по токенам, а не только по числу запросов

Но это даёт:

• выше утилизацию GPU, меньше простаивания

• выше throughput

• лучше работа с запросами разной длины

Что такое speculative decoding?

Speculative decoding пытается ускорить генерацию за счёт использования дополнительной маленькой draft модели.

Идея:

• Маленькая быстрая модель предлагает несколько следующих токенов

  • авторегрессивно, токен за токеном, генерирует часть последовательности

• Большая модель проверяет эти токены

  • получив черновик, одним forward pass параллельно считает логиты для всех позиций

• Если предложенные токены согласуются с распределением большой модели, принимаем сразу несколько токенов

  • согласованность распределений проверяем через rejection sampling

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

Ускорение достигается за счет того, что нам не нужно генерировать токен за токеном именно большой моделью, а нужно только проверить одним форвардом сразу все токены от маленькой модели. Даже если какие-то токены будут отклоняться и нужно будет генерировать большой моделью — в среднем по всем запросам все равно будет прирост (конечно, надо экспериментировать с конкретными моделями, но идея такая).

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

Конечно, есть и другие варианты спекулятивного декодинга:

• дополнительные decoding heads, например, Medusa или MTP

• feature-level drafter, например, EAGLE

• lightweight MLP speculator

• parallel draft methods, например, PARD

Какая бывает точность весов модели?

Веса LLM могут храниться в FP32, FP16, BF16, FP8 и более низкобитных форматах. Чем меньше бит занимает параметр, тем меньше GPU памяти требуется модели и тем меньше данных нужно читать из HBM. При поддержке формата на GPU это также может ускорить вычисления.

Экспонента определяет диапазон представимых чисел, а мантисса — насколько точно можно различать близкие значения.

Память только под веса можно грубо оценить так:

FP16 и BF16 при одинаковом размере ведут себя по-разному:

• FP16 имеет более точную мантиссу, но меньший динамический диапазон. Слишком большие активации, градиенты или промежуточные значения могут переполниться до inf, а слишком маленькие — округлиться до нуля. Последующие операции с inf могут привести к NaN.

• BF16 сохраняет 8 бит экспоненты, как FP32, поэтому имеет почти такой же динамический диапазон и обычно стабильнее при обучении LLM. Но приходится платить меньшей точностью мантиссы.

Что такое квантизация?

Квантизация — это понижение точности представления чисел у модели.

Вместо того чтобы хранить веса в FP32 или FP16/BF16, можно хранить их в более компактном формате: INT8, INT4, FP8, NF4 и др.

Главная цель:

• уменьшить потребление памяти GPU

• улучшить latency и/или throughput

Но это trade off между качеством и занимаемой памятью / скоростью.

Можно квантизовать:

• только веса (weight-only quantization)

Самый понятный и популярный вариант для инференса, потому что веса занимают много памяти и постоянно читаются. Активации при этом не трогаем, они остаются в fp32/fp16/bf16.

• веса + активации

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

• kv-cache

Так как kv-cache может занимать много памяти при длинном контексте и большом batch size, его тоже можно хранить в более низкой точности.

Есть два базовых подхода к квантизации:

• Post-Training Quantization — квантизацию применяем к уже обученной модели, обычно дешевле и проще

• Quantization-Aware Training — обучаем или дообучаем с учётом квантизации, дороже, но может лучше сохранять качество при агрессивном снижении точности

Важно, что более низкая точность не гарантирует ускорение сама по себе. Мы можем уменьшить потребление памяти, но реальная скорость зависит от поддержки видеокарты вычислений в этой точности, kernel-ов фреймворков инференса и других факторов.

Как именно выглядит процесс квантизации (на примере простой симметричной квантизации)?

Алгоритм следующий:

• пусть есть веса

• квантовать будет в INT8, поэтому диапазон следующий:

• Вычисляем scale фактор (делим максимальное абсолютное число на максимальное число диапазона):

• Квантуем (делим на scale и округляем):

• Если надо восстановить приближение в исходной точности (умножаем на scale):

Где:

• — исходные float-ы

• — максимальное абсолютное значение в группе

• — число бит

• — scale фактор

• q — квантованное целое значение

• — восстановленное приближение

Ошибка квантизации тогда будет:

Чем меньше бит, тем грубее сетка значений и тем выше риск потери качества.

Это пример самого простого алгоритма квантизации, например, он предполагает центрированность исходных весов относительно нуля. Есть ассиметричная квантизация, там вводим еще дополнительный zero_point.

Главная проблема квантизации — выбросы (outlier): одно большое значение растягивает общий диапазон, из-за чего остальные веса квантуются слишком грубо. Поэтому вместо одного scale на весь тензор используют отдельный scale на канал или небольшую группу весов, например по 32–128 значений. Чем меньше группа, тем точнее адаптируется scale, но тем больше метаданных и сложнее kernel.

Что такое knowledge distillation?

Knowledge distillation — это перенос поведения большой модели в меньшую.

Большая teacher модель генерирует ответы, logits или распределения вероятностей, а меньшая student модель учится воспроизводить это поведение.

Есть два базовых варианта:

• hard labels

Teacher выдаёт готовый ответ или класс, и student учится на этом как на разметке. Это похоже на обучение на синтетической разметке от более сильной модели.

• soft labels

Student учится не только на финальном ответе, но и на распределении вероятностей teacher модели, минимизируя KL-дивергенцию между распределениями. Сигнал от модели учителя больше, качество потенциально лучше.

Например, teacher считает logits по словарю. После softmax получаем распределение:

p_T(y \mid x)

Student выдаёт своё распределение:

p_S(y \mid x)

И можно минимизировать KL-divergence:

D_{KL}(p_T || p_S) = \sum_y p_T(y \mid x) \log \frac{p_T(y \mid x)}{p_S(y \mid x)}

Классический пример дистилляции — DistilBERT, где большая BERT-base выступает teacher-моделью, а уменьшенная шестислойная модель — student. Во время предобучения student повторяет распределение вероятностей и скрытые представления teacher-модели. В результате DistilBERT стал на 40% меньше и на 60% быстрее, сохранив около 97% качества BERT. paper

А еще из-за дистилляции регулярно возникают споры между разработчиками LLM: компания может массово собирать ответы чужой закрытой модели и использовать их как синтетический датасет для обучения своей)))

Итоговый чеклист вопросов с собесов

Полезные материалы

• курс ШАДа

• Статьи на хабре раз и два

• очень хороший блогпост про fused kernel

• блогпост по квантизации

• статья конспект — виды операций и управление памятью GPU

• peft, lora и немного про точность и квантизацию раз и два

• Гайд по vLLM

Чтобы не пропустить выход статей и видео по ML, NLP, LLM, подпишись на мои соц. сети:

• В Telegram канале — регулярный контент по ML и Data Science

• На Ютуб канале — видеоразборы вопросов с собеседований (и по этой статье)

• На Boosty — разборы задач по математике, реальных собеседований и еще больше обучающих материалов

• Полная карта со всем моим контентом

• Вкат с нуля или повышение грейда в ML — менторство