Топ вопросов с NLP‑собеседований: архитектуры LLM, инференс и оптимизация
На собеседованиях по NLP/LLM сегодня редко ограничиваются базовым "как работает attention". Чаще проверяют, понимаете ли вы устройство современных GPT‑like моделей: почему в генеративных задачах доминирует decoder‑only, чем условная LLaMA отличается от "ванильного" Transformer, зачем в архитектуре появились RoPE, RMSNorm, SwiGLU и групповые варианты внимания. Отдельный пласт - практическая инженерия: почему инференс большой модели дорогой, где узкие места (compute vs memory), и какие приемы реально ускоряют выдачу токенов на GPU.
Ниже - переработанный чеклист "вопрос → что важно уметь объяснить", который помогает закрыть пробелы в формулировках перед техническим интервью. Это не лекция с нуля, а компактная карта тем: архитектуры, инференс, KV‑кэш, батчинг, квантизация и дистилляция.
---
1) Какие LLM бывают и чем они различаются
Большинство современных генеративных LLM - это decoder‑only трансформеры. К ним относятся разные семейства и линейки (GPT‑подобные, LLaMA‑подобные, Mistral‑подобные, Qwen‑подобные, Gemma‑подобные и т. п.). На практике модели отличаются не "брендом", а набором инженерных решений и ограничений:
1) Открытая vs проприетарная.
Для многих компаний критично, где обрабатываются данные. Если служба безопасности не разрешает отправлять чувствительную информацию во внешние API, приходится разворачивать open‑source модель внутри корпоративного контура.
2) Число параметров и требования к памяти.
Размер модели напрямую связан с качеством, скоростью и ценой инфраструктуры. Приблизительные оценки занимаемой памяти (только веса) часто обсуждают прямо на собеседовании:
| Размер | FP16/BF16 веса | INT8 веса |
|---|---:|---:|
| 1B | ~2 GB | ~1 GB |
| 7B | ~14 GB | ~7 GB |
| 13B | ~26 GB | ~13 GB |
| 30B | ~60 GB | ~30 GB |
| 70B | ~140 GB | ~70 GB |
3) Детали архитектуры.
Внутри decoder‑only модели важны: dense или MoE, тип attention (MHA/MQA/GQA), тип нормализации, positional encoding (например, RoPE), особенности MLP (например, SwiGLU). Эти решения влияют и на качество, и на скорость, а фреймворки обучения/инференса часто оптимизируются под конкретные "популярные" конфигурации.
4) Длина контекстного окна.
Контекст может быть 4k, 8k, 32k, 128k токенов и больше. Это критично по трем причинам:
- Качество: длинные тексты можно "переваривать" без агрессивной нарезки на чанки и потери смысла.
- Скорость: вычисления внимания растут квадратично по длине контекста, поэтому длинный контекст быстро делает инференс тяжелым.
- Продуктовые сценарии: поиск по документам, анализ логов, многопользовательские чаты - везде контекст решает.
5) Мультимодальность.
Если модель должна отвечать по изображению или читать текст на картинке, одного decoder‑only блока мало. Обычно добавляют vision encoder, затем projection layer (проекцию визуальных признаков в пространство эмбеддингов LLM) и специальные токены/протокол "склейки" визуального и текстового контекста.
6) Особенности обучения и "специализация".
Модели могут быть сильнее в коде, математике, диалогах, следовании инструкциям и т. д. Отдельно оценивают "alignment": насколько модель безопасна, склонна ли к утечкам, как реагирует на провокации.
7) Лицензия.
На интервью это часто всплывает как практический вопрос: что можно использовать в коммерческих продуктах, что можно дообучать, а что накладывает ограничения.
---
2) Чем современные LLM отличаются от классического Transformer
В "учебном" Transformer (encoder‑decoder) часто фокус на переводе и задачах seq2seq. В генеративных LLM наиболее распространен decoder‑only: он естественно соответствует автогрессии - предсказываем следующий токен по предыдущим.
Кроме выбора "только декодер", современные LLM обычно отличаются:
- схемой нормализации (Pre‑Norm),
- видом positional encoding (часто RoPE),
- заменой MLP на gated‑варианты (SwiGLU),
- оптимизацией внимания (MQA/GQA),
- иногда использованием MoE вместо плотных слоев.
---
3) Pre‑Norm и Post‑Norm: что спрашивают и как отвечать
Post‑Norm - исторически распространенная схема, где LayerNorm ставится после резидуального сложения.
Pre‑Norm - LayerNorm (или аналог) ставится перед блоком (перед attention и перед MLP).
Почему Pre‑Norm стал стандартом в LLM:
- обычно стабильнее обучение на больших глубинах,
- проще масштабировать число слоев,
- меньше проблем с градиентами при больших моделях.
На собеседовании важно не только дать определение, но и связать его с практикой: "Pre‑Norm - это про устойчивость оптимизации и масштабирование глубины, поэтому его повсеместно используют в больших decoder‑only моделях".
---
4) RMSNorm vs LayerNorm: в чем разница
LayerNorm нормализует активации с учетом среднего и дисперсии по признакам.
RMSNorm упрощает нормализацию: фактически нормирует по RMS (корню из среднего квадрата) и не вычитает среднее.
Почему RMSNorm любят в LLM:
- проще вычислительно,
- часто дает сопоставимое качество,
- хорошо ложится в оптимизации инференса на GPU.
---
5) SwiGLU и gated‑активации: зачем это нужно
Классический Transformer использовал ReLU/GELU в MLP. В LLM распространены gated‑варианты, например SwiGLU: часть каналов играет роль "ворот" и модулирует основную ветку.
Интервьюер обычно хочет услышать:
- gated‑MLP часто улучшает качество при близких FLOPs,
- может быть более "выразительным" блоком,
- это один из типичных штрихов "современной" LLM‑архитектуры.
---
6) MoE (Mixture of Experts): что это и какие компромиссы
MoE заменяет плотный FFN на набор "экспертов", из которых роутер выбирает 1-2 на токен (или другое малое число).
Плюс: можно резко увеличить число параметров и емкость модели без пропорционального роста вычислений на токен.
Минусы, которые полезно упомянуть:
- сложнее обучение и балансировка нагрузки,
- сложнее инференс и распределение по устройствам,
- возможны "узкие места" по коммуникациям.
---
7) RoPE, MHA vs MQA/GQA: частые вопросы по attention
RoPE (rotary positional embeddings) - способ внедрить позиционную информацию через вращение компонент в запросах/ключах, что удобно масштабируется и хорошо работает на длинном контексте.
По attention часто спрашивают различия:
- MHA (multi‑head attention): у каждой головы свои Q/K/V.
- MQA (multi‑query attention): ключи/значения общие для голов (сильно экономит память на KV‑кэше).
- GQA (grouped‑query attention): компромисс между MHA и MQA: несколько групп запросов разделяют K/V.
Практическая мотивация MQA/GQA почти всегда одна: ускорение инференса и уменьшение памяти KV‑кэша, особенно на длинных диалогах.
---
8) Почему инференс LLM такой дорогой
Главная причина - автогрессивная генерация. Вы не "вычисляете сразу ответ целиком", вы многократно прогоняете модель, добавляя по одному токену.
Важно различать два режима нагрузки:
- Compute‑bound: упираемся в матмулы и FLOPs (например, большие GEMM в MLP/attention).
- Memory‑bound: упираемся в пропускную способность памяти и перемещение данных (часто актуально из‑за KV‑кэша и чтения весов).
На интервью полезно уметь объяснить, почему на коротких запросах все "летает", а на длинном контексте деградирует: растет объем внимания и раздувается KV‑кэш.
---
9) Из каких фаз состоит инференс: prefill и decode
Инференс LLM обычно делят на две стадии:
Prefill (прогрев, обработка промпта).
Модель "прочитывает" входной контекст и строит KV‑кэш для всех токенов промпта. Это может быть относительно тяжелая стадия, потому что обрабатывается сразу много токенов.
Decode (генерация).
Дальше модель выдает токены по одному. На каждом шаге вы используете накопленный KV‑кэш и добавляете новый элемент. Эта стадия чувствительна к оптимизациям памяти и к тому, насколько эффективно вы обслуживаете параллельные запросы.
---
10) Latency vs throughput: ключевые метрики сервинга
На собеседованиях часто просят разнести понятия:
- Latency - задержка (например, время до первого токена или время получения полного ответа).
- Throughput - пропускная способность (например, токенов/сек на GPU или запросов/сек).
В реальных системах эти метрики конфликтуют: увеличение батча обычно улучшает throughput, но может ухудшить latency, особенно "время до первого токена".
---
11) Fused kernels и зачем они нужны
Fused kernels - это объединение нескольких операций в один GPU‑kernel, чтобы:
- уменьшить число запусков kernels,
- снизить накладные расходы,
- сократить чтение/запись в глобальную память (меньше memory traffic).
В контексте LLM это особенно заметно на нормализациях, активациях, linear‑слоях и attention‑блоках.
---
12) Flash Attention: что именно ускоряет
Flash Attention - подход к вычислению attention, который уменьшает потребление памяти и число обращений к глобальной памяти за счет тайлинга и более "кэш‑дружелюбного" вычисления softmax‑внимания.
Обычно от кандидата ждут понимания идеи: на длинных последовательностях классический attention может упираться в память, а Flash‑подход переносит акцент на эффективное использование GPU‑памяти и снижает memory‑bottleneck.
---
13) KV‑cache: что хранится и почему это важно
KV‑cache - это сохраненные ключи и значения (K и V) для предыдущих токенов на каждом слое. Благодаря этому на decode‑шаге вы не пересчитываете прошлый контекст, а лишь добавляете "хвост" для нового токена.
Что часто спрашивают:
- почему KV‑кэш ускоряет decode,
- почему KV‑кэш раздувает память на длинном контексте,
- как MQA/GQA уменьшают этот кэш за счет разделения K/V.
---
14) PagedAttention: зачем "страницы" памяти
PagedAttention - техника управления KV‑кэшем, где память организуют "страницами" и выделяют/освобождают более гибко. Это снижает фрагментацию и помогает эффективно обслуживать много запросов с разной длиной контекста, особенно в режиме сервинга.
---
15) Continuous batching: как повысить загрузку GPU
Обычный батчинг предполагает, что все запросы стартуют одновременно и идут синхронно. В LLM‑сервинге это неудобно: пользователи приходят в разное время, ответы разной длины.
Continuous batching (непрерывный батчинг) позволяет:
- динамически добавлять новые запросы в "текущий" батч,
- поддерживать высокую загрузку GPU,
- лучше балансировать latency/throughput.
---
16) Speculative decoding: ускорение генерации "с подстраховкой"
Speculative decoding - стратегия, где более маленькая (быстрая) модель предлагает несколько следующих токенов, а большая модель проверяет и подтверждает их пачкой. Если все ок - вы экономите шаги decode; если нет - откатываетесь и продолжаете.
На интервью важно подчеркнуть, что метод ускоряет именно автогрессивную часть, где токены генерируются по одному, и что итоговая корректность контролируется "большой" моделью.
---
17) Точность весов: FP16/BF16/INT8 и почему это обсуждают
Часто спрашивают, в какой точности хранят веса и считают матмулы:
- FP16/BF16 - стандартный компромисс качества и скорости на GPU,
- INT8 и ниже - путь к ускорению и экономии памяти, но требует аккуратной калибровки/методов, чтобы не потерять качество.
---
18) Квантизация: что это и как выглядит на простом примере
Квантизация - перевод весов (иногда и активаций) из более высокой точности в более низкую (например, FP16 → INT8), чтобы уменьшить память и ускорить вычисления.
Пример простой симметричной квантизации весов:
1) Берем тензор весов `W` (в float).
2) Находим масштаб `s`, например `s = max(|W|) / 127` для INT8.
3) Получаем квантизованные веса: `W_q = round(W / s)` и клиппинг в диапазон `[-127, 127]`.
4) При вычислениях используем `W_q`, а масштаб учитываем как множитель (де‑квантизация на лету или в аккумуляторах).
На собеседовании ценится, если вы упомянете trade‑off: меньше памяти и часто выше скорость, но есть риск деградации качества и нюансы с выбросами/калибровкой.
---
19) Knowledge distillation: зачем "перегонять" знания
Дистилляция - подход, где компактная модель‑студент учится воспроизводить поведение большой модели‑учителя. Используют, чтобы:
- уменьшить модель для продакшена,
- снизить latency и стоимость,
- сохранить приемлемое качество на целевых задачах.
---
20) Дополнительные параграфы, которые часто помогают на интервью (и в работе)
Как выбирать модель под задачу, а не "самую большую".
В продакшене выигрывает не максимальный размер, а баланс: нужное качество при ограничениях по памяти, стоимости и времени ответа. Иногда 7B‑модель с правильной инструкционной настройкой и хорошим промптом обходит "сырой" 30B‑вариант в конкретном домене.
Почему длинный контекст не бесплатный, даже если модель его поддерживает.
Поддержка 32k/128k не означает, что это можно включать по умолчанию. Увеличение контекста резко повышает требования к памяти под KV‑кэш и может ухудшить latency, особенно при одновременном обслуживании многих пользователей.
Что важнее в сервинге: время до первого токена или скорость потока токенов.
Для чат‑интерфейсов критично "время до первого токена" - пользователь должен увидеть, что система "думает". Для пакетной генерации (суммаризации, офлайн‑обработки) важнее стабильный throughput.
Почему оптимизации инференса - это не только про GPU.
Даже с идеальными kernels можно упереться в очереди запросов, сетевые накладные расходы, сериализацию/десериализацию, токенизацию и пост‑процессинг. В интервью иногда проверяют, понимаете ли вы всю цепочку и где реальные bottleneck'и.
Как объяснить разницу между оптимизациями "модели" и "системы".
Квантизация/дистилляция/архитектурные изменения - это оптимизации модели. Flash Attention, fused kernels, paged KV‑cache, continuous batching - оптимизации системного уровня. Хороший кандидат умеет разделять эти уровни и комбинировать подходы.
Почему MoE усложняет эксплуатацию.
Даже если MoE экономит вычисления, он может усложнить распределение нагрузки по GPU и сделать производительность менее предсказуемой из‑за роутинга токенов. На интервью это хороший пункт, чтобы показать инженерную зрелость.
---
Итоговый чеклист вопросов с собеседований
Архитектура LLM
- Почему decoder‑only доминирует в генерации?
- Чем современные LLM отличаются от классического Transformer?
- Pre‑Norm vs Post‑Norm: зачем и к чему приводит?
- RMSNorm vs LayerNorm.
- SwiGLU и другие gated‑MLP: смысл и эффект.
- MoE: как работает роутинг, плюсы/минусы.
Attention и позиционные эмбеддинги
- RoPE: идея и зачем нужно.
- MHA vs MQA vs GQA: что меняется и почему это ускоряет инференс.
Инференс и метрики
- Почему инференс дорогой: compute‑bound vs memory‑bound.
- Prefill vs decode: где тратится время.
- Latency vs throughput: как меряют и что оптимизируют.
Оптимизация инференса
- Fused kernels: что дают.
- Flash Attention: в чем ускорение.
- KV‑cache: как устроен и чем ограничен.
- PagedAttention: зачем "страницы".
- Continuous batching: как повышают загрузку GPU.
- Speculative decoding: как ускоряют генерацию.
Оптимизация модели
- Точности весов (FP16/BF16/INT8).
- Квантизация: базовый алгоритм и риски.
- Knowledge distillation: когда применяют.
Если нужно, могу дополнить текст блоком "типовые формулировки ответов на интервью" - короткими речевыми заготовками на 30-60 секунд под каждый вопрос.
