Что теперь нужно знать современному LLM-инженеру

Все мы иногда меняем работу. Я вот тоже недавно решил. Походил по собеседованиям и удивился. Спрашивать стали больше, шире, детальнее.

Кажется, что это не новость. IT всегда было местом, где обучаться чему-то новому приходилось гораздо часто. Но кажется раньше скоуп экспертизы не сдвигался так сильно за такое короткое время.

Хочу в этой статье немного порассуждать про то, что изменилось с экспертизой в LLM сфере за последние годы и что теперь нужно знать современному LLM инженеру. Опираюсь на свой личный опыт и общение с людьми из сферы из наших и зарубежных компаний.

Мне удобно смотреть на это как на стек слоёв:

• Post-training — как модель обучается на поздних этапах;

• Inference и сервинг — как эти вычисления реально крутятся в проде;

• Прикладной слой — что происходит вокруг модели: контекст, RAG, агенты.

Раньше «разбираться в LLM» означало освоить единственный по-настоящему трудный слой - архитектуру, фундаментальное устройство модели (self-attention, cross-attention, transformer-block и так далее). Сегодня архитектура - это базовый минимум, а экспертиза размазалась по всему стеку: от обучения до сервинга/инференса и агентской обвязки. Дальше пройдусь по этим слоям и по каждому скажу, что важно знать и в чём нужно разбираться.

Слой 1. Post-training

Первое, что стало массовым - доступный post-training. До этого всего достаточно было понимать разницу между pre-training и SFT. Это все еще фундаментальные вещи, которые являются основной, но в случае LLM теперь невозможно строить продукты без post-training стадии.

Базовый RLHF даёт отличный результат и до сих пор остаётся самым сильным по обобщающей способности методом выравнивания. Но он тяжёлый: кроме самой модели нужны reward-модель и, в случае PPO, ещё и value-модель; отсюда reward hacking и целый букет проблем со стабильностью. Позволить себе полноценный RLHF-пайплайн могут в основном только топовые лаборатории и тех корпорации с нужной инфраструктурой.

Дальше появились методы попроще, и вот это уже поменяло расклад.

DPO выкидывает отдельную reward-модель и учит политику напрямую на парах «хороший ответ / плохой ответ» к одному запросу — по сути, оптимизирует неявную награду в замкнутой форме.

GRPO идёт другим путём: сэмплит группу ответов на запрос и использует их относительные оценки как бейзлайн, за счёт чего избавляется от value-модели. Часто используется, если имеется легкий спобов вычисления качества ответов (например, простые математические задачи. Нужно просто проверить, совпадает ли финальный ответ.)

У всех этих упрощений есть цена: убирая обобщённую reward-модель, ты получаешь более простой и управляемый процесс, но, как правило, менее общее «понимание» того, что вообще такое хороший ответ. Т.е. решение становится более контролируемым и лучше в близких доменах, но немного теряет в обобщающей способности на доменах, далёких от твоих данных.

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

Слой 2. Inference и сервинг

Второй слой — то, что раньше многие ML-инженеры вообще считали проблемой бэкендеров. Теперь инференс стал частью экспертизы ML Engineer’а и перестал быть чисто инфраструктурной деталью.

Три самые важные технологии и практики:

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

FlashAttention: точный (не приближённый) attention, переписанный с учётом иерархии памяти GPU — за счёт тайлинга и пересчёта он не материализует полную матрицу внимания в медленной памяти, что даёт и скорость, и экономию. 

PagedAttention в vLLM: управление KV-кэшем страницами, как виртуальная память в ОС, — меньше фрагментации и выше заполняемость батча; на этом стоит continuous batching, когда запросы влетают в батч и вылетают из него на лету.

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

Слой 3. Контекст и агенты

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

Кодинг-агент вроде Cursor или Claude Code — это уже не чат-бот, которому ты закидываешь файлики. Он получает право на чтение всего репозитория или хотя бы релевантной его части, держит историю диалога, помнит отдельные инструкции (в том числе оформленные как скиллы и субагенты), достаёт нужное через RAG и умеет в мультиагентные пайплайны с разделением труда. Сами модели под капотом при этом бывают вполне обычные — вся разница в обвязке.

Это полезно не только в контексте работы над своими проектами, но и как LLM инженеру. RAG и Embedding движки для баз знаний — важный плюс в послужной список. RAG сейчас пытаются использовать и вклеить куда угодно не без причины — это по сути законный data-leak, который очень хорошо улучшает качество ответов. 

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

Ну и, возможно, самое приятное – теперь меньше спрашивают про алго-кодинг и больше про кодинг с агентом. Даже компании из РФ стали всё чаще устраивать сессии с ИИ кодингом вместо стандартного leetcode собеса. Из иностранных компаний, кажется, теперь только самые большие гиганты не успели адаптироваться, но даже там уже алго собеседование - нечастый гость. Во время него проверяют не только сам факт того, что ты умеешь пользоваться ИИ-инструментами, но и понимаешь детали: какими моделями пользуешься и почему, как следишь за квотой токенов, как задаёшь контекст и задачу, пользуешься ли планированием и так далее.

Что это значит для требований сферы

Сложив слои, получаем главное. Планка того, что значит «разбираться в LLM», сместилась не в сторону от устройства модели, а вширь - на весь стек. Раньше ожидалось, что специалист разбирается в базовой теории ML + деталях с архитектурой и базовым претрейном DL части. Если ты мог хорошо пояснить за attention, то ты уже был в когорте качественных специалистов. 

Теперь же это базовый минимум. Сегодня требуется более широкое знание по всему, что перечислено выше. По моему мнению, сдвиг происходит не только из-за развития технологий. Одна из причин: требования к разработчику быть «универсальным бойцом», готовым делать всё end-to-end самостоятельно. Мини-революция ИИ + не самая простая экономическая ситуация в мире привели к срезанию костов, а это значит меньше команда -> шире ответственность на одного специалиста.