Senior AI/ML Engineer — Питання на співбесіді AI/ML-інженера

Поясніть KV-кешування та квантування в інференсі LLM — чому вони важливі?

KV-кеш зберігає вектори key і value, пораховані для попередніх токенів, тож генерація кожного нового токена потребує attention лише для цього одного нового токена замість перерахунку всієї послідовності — без цього авторегресивна генерація була б квадратично повільнішою. Квантування знижує точність ваг (наприклад, з FP16 до INT8 чи INT4), зменшуючи споживання памʼяті й підвищуючи пропускну здатність, обмінюючи невелику, зазвичай прийнятну втрату якості на суттєве зниження вартості serving. Саме ці два прийоми роблять економічно можливим обслуговування моделі на 70 мільярдів параметрів узагалі.

Що таке RLHF і яку проблему він насправді вирішує?

RLHF (reinforcement learning from human feedback) бере модель, уже навчену передбачати наступний токен, і додатково налаштовує її видавати те, що люди справді віддають перевагу, — зазвичай навчаючи reward-модель на порівняннях відповідей людьми, а потім використовуючи цю reward-модель для файнтюнінгу політики алгоритмом на кшталт PPO. Він закриває розрив між "передбачає правдоподібний текст" і "корисний, чесний і виконує інструкції", який чисте передбачення наступного токена взагалі не оптимізує. Новіші підходи на кшталт DPO дають подібний результат без окремої reward-моделі та RL-циклу, тому команди дедалі частіше пропускають класичний пайплайн RLHF.

Чим різняться data, model і pipeline parallelism і як обирати між ними?

Data parallelism реплікує всю модель на пристроях і ділить батч — це просто, але вимагає, щоб уся модель вміщалася на одному пристрої. Model parallelism ділить саму модель між пристроями, коли вона занадто велика для одного: tensor parallelism ділить окремі шари, pipeline parallelism ділить модель на стадії, оброблювані послідовно. На практиці навчання великої моделі використовує всі три одночасно, і реальна інженерна задача — мінімізувати накладні витрати на комунікацію між пристроями, що й визначає реальну пропускну здатність.

Як вирішити, будувати на API фундаментальної моделі, файнтюнити відкриту модель чи навчати з нуля?

Навчання з нуля майже ніколи не виправдане поза жменькою добре профінансованих лабораторій — вартість даних і обчислень величезна, а отримувана базова здатність гірша за вже наявну. Справжній вибір — між API і self-hosted відкритою моделлю: API швидше запустити і не потрібно володіти інфраструктурою, але витрати ростуть лінійно з використанням, і ви залежите від чужого аптайму та лімітів; self-hosted файнтюнена модель потребує інженерних витрат заздалегідь, але дає контроль над даними, передбачувану юніт-економіку на масштабі та незалежність від змін політики зовнішнього вендора. Чутливість і обсяг даних зазвичай вирішують суперечку швидше, ніж чисте моделювання вартості.

Як ви обираєте між файнтюнінгом, retrieval-augmented generation (RAG) і самим лише промпт-інжинірингом?

Починають з промптингу — він найдешевший в ітераціях і часто закриває 80% задачі, якщо проблема просто в кращих інструкціях чи прикладах. За RAG йдуть, коли моделі потрібні факти, на яких її не навчали або які часто змінюються: ретрив тримає знання актуальними без перенавчання і дозволяє цитувати джерела. Файнтюнінг потрібен, щоб прищепити стійкий стиль, формат чи спеціалізовану навичку, з якою базова модель помиляється навіть за гарного промпту й контексту, — і це найдорожчий варіант в ітераціях, бо кожна зміна означає новий прогін навчання та оцінку. Більшість продакшн-систем зрештою поєднують RAG для фактів із злегка дотренованою моделлю для тону й формату, а не обирають щось одне.