AI як великий пазл: нейромережі, CUDA-ядра, трансформери.

Зміст

1. Термінологічна каша: AI vs ML vs DL vs LLM
2. Нейромережа з нуля: як математика стає “інтелектом”
3. Чому MLP не вистачило: Attention і трансформери
4. Як народжується LLM: pretraining, fine-tuning, RLHF
5. Залізо: CUDA-ядра, Tensor Cores, чому без GPU це неможливо
6. Тренування vs Inference: де гроші, де вати
7. Як з цим працюють зараз: API, RAG, агенти, MCP, LLMOps
8. Глосарій для співбесіди
9. Реальні питання на співбесідах + відповіді
10. Від мене особисто: що насправді важливо

Термінологічна каша

Перш ніж лізти в математику — наведемо порядок у термінах, бо саме тут 80% людей.

Artificial Intelligence (AI)          ← найширше поняття, будь-яка імітація "розумної" поведінки
  └── Machine Learning (ML)           ← система навчається на даних, а не на жорстких if/else
        └── Deep Learning (DL)        ← ML через багатошарові нейромережі
              └── LLM (Large Language Model) ← DL-модель, навчена на тексті, побудована на архітектурі Transformer
                    └── GPT, Claude, Gemini, Llama, Mistral... ← конкретні реалізації

Аналогія з твоєї області: AI — це “high availability”, ML — це “active-passive failover”, DL — це “active-active з consensus”, а LLM — це конкретний кластер на конкретному стеку (kubeadm + Flannel, скажімо). Рівень абстракції падає, конкретика росте.

Окремо варто розрізняти:

• Discriminative модель — класифікує/передбачає (це спам чи не спам?).
• Generative модель — генерує новий контент (текст, картинка, код). LLM — це generative модель.
• Narrow AI — все, що існує зараз (включно з GPT-5, Claude, Gemini) — система, заточена під конкретний клас задач.
• AGI (Artificial General Intelligence) — гіпотетична система з людським рівнем загального інтелекту в будь-якій сфері. Не існує. На співбесіді, якщо запитають “чи це AGI?” — впевнено кажи “ні, це narrow AI, незважаючи на широкий спектр задач”.

Нейромережа з нуля

Забудь магію. В основі — лінійна алгебра і похідні.

Один нейрон

        x1 ──╮
              ×w1
        x2 ──┤×w2──► Σ(xi·wi) + b ──► активація f() ──► вихід y
              ×w3
        x3 ──╯

• x1, x2, x3 — вхідні значення (фічі: піксель, токен-ембединг, цифра).
• w1, w2, w3 — ваги (weights) — те, що мережа “вчить”. Це просто числа.
• b — bias (зсув), дозволяє зсунути функцію активації, навіть коли всі x = 0.
• Σ(xi·wi) + b — звичайна лінійна комбінація. На цьому етапі мережа поки що еквівалентна лінійній регресії.
• f() — функція активації: ReLU, GELU, sigmoid, tanh. Без неї багатошарова мережа математично згортається в одну лінійну функцію — тобто нелінійність — це те, що взагалі дає мережі сенс мати кілька шарів.

Шари і forward pass

Стек таких нейронів = шар (layer). Стек шарів = мережа. Дані проходять зліва вправо — це і називається forward pass:

input layer → hidden layer 1 → hidden layer 2 → ... → output layer

Кожен шар — це матричне множення + bias + активація. Тобто вся нейромережа — це послідовність:

y = f_n( W_n · f_{n-1}( ... f_1(W_1·x + b_1) ... ) + b_n )

Це і пояснює, чому GPU тут критичні: матричне множення (W·x) — це саме та операція, яку GPU виконують паралельно в тисячі разів швидше за CPU. Детальніше — в розділі про залізо.

Як мережа вчиться: loss, backpropagation, gradient descent

1. Forward pass — пропускаємо вхід, отримуємо передбачення y_pred.
2. Loss function — порівнюємо y_pred з правильною відповіддю y_true (наприклад, через Cross-Entropy для класифікації або MSE для регресії). Отримуємо одне число — “наскільки ми помилились”.
3. Backpropagation — рахуємо, як зміна кожної ваги вплинула би на loss. Це робиться через chain rule (ланцюгове правило диференціювання), розповсюджуючи градієнт від виходу назад до входу.
4. Gradient Descent — оновлюємо кожну вагу в напрямку, протилежному градієнту, з кроком learning rate:

w_new = w_old − learning_rate × dLoss/dw

5. Повторюємо мільйони разів на мільйонах прикладів.

Це і є все “навчання”. Жодної магії — це оптимізаційна задача в просторі з мільярдами вимірів (=параметрів), де ми шукаємо локальний мінімум функції втрат через градієнтний спуск. SGD, Adam, AdamW — це просто різні стратегії, як саме робити цей крок (з моментумом, з адаптивним learning rate і т.д.).

Чому це важливо для співбесіди: якщо можеш на пальцях намалювати ланцюжок forward → loss → backward → update — ти вже на голову вище 70% кандидатів, які говорять про AI лише на рівні “воно вчиться на даних”.

Attention і трансформери

До 2017 року для тексту використовували RNN/LSTM — мережі, що обробляли слова послідовно, одне за одним, тримаючи “пам’ять” у скритому стані. Проблема: при довгих послідовностях градієнт або зникає (vanishing gradient), або вибухає, і паралелити обчислення неможливо — слово №50 чекає на слово №49.

Стаття “Attention Is All You Need” (Google, 2017) вирішила це через механізм self-attention: замість послідовної обробки кожен токен одразу “дивиться” на всі інші токени одночасно і вирішує, на які з них варто звернути більше уваги.

Як працює self-attention (інтуїтивно)

Кожен токен породжує три вектори через навчені матриці:

• Query (Q) — “що я шукаю?”
• Key (K) — “що я можу запропонувати?”
• Value (V) — “ось власне інформація, яку я несу”

Формула:

Attention(Q, K, V) = softmax( Q·Kᵀ / √d_k ) · V

• Q·Kᵀ — наскільки кожен токен “релевантний” кожному іншому (просто скалярний добуток векторів).
• softmax — перетворює ці скори в розподіл ймовірностей, що сумується до 1 (хто отримує скільки “уваги”).
• множення на V — зважена сума значень, де вага = увага.

Аналогія з твоєї роботи: це майже як weighted backend в HAProxy — кожен запит (Query) “дивиться” на всі сервери (Key) і розподіляє вагу (softmax) пропорційно релевантності, а потім бере дані (Value) з тих серверів, що отримали найбільше ваги. Тільки тут це робиться для кожного токена з кожним іншим токеном одночасно — звідси й квадратична складність O(n²) по довжині послідовності, і чому контекстне вікно — це не просто “налаштування”, а реальний compute-bottleneck.

Multi-head attention + позиційне кодування

• Multi-head attention — той самий механізм рахується паралельно кілька разів (8, 16, 32 “голови”) з різними навченими матрицями Q/K/V, кожна голова вчиться “дивитись” на різні типи зв’язків (граматика, кореференції, семантика). Результати конкатенуються.
• Оскільки attention сам по собі не знає порядку слів (це по суті множина, не послідовність) — додається positional encoding (синусоїдальні функції в оригінальній статті, RoPE — Rotary Position Embedding — у сучасних LLM), щоб модель знала, що слово стоїть на позиції 5, а не 50.

Токенізація і ембединги

Текст не подається в мережу як текст — спочатку:

1. Tokenizer (BPE, SentencePiece) розбиває текст на підслова: "переговори" → ["перего", "вори"]. Це чому одне слово іноді = кілька токенів, і чому “кількість токенів” ≠ “кількість слів”.
2. Кожен токен → embedding vector (наприклад 4096 чисел) через таблицю, яку модель вивчила під час тренування. Слова зі схожим значенням опиняються близько одне до одного в цьому векторному просторі (звідси й працює semantic search — про це нижче, в RAG).

Архітектура трансформера повністю

[Текст] → Tokenizer → Embeddings + Positional Encoding
        → [N × (Self-Attention → Feed-Forward → LayerNorm + residual)]
        → Linear → Softmax → розподіл ймовірностей наступного токена

Сучасні LLM — це decoder-only трансформери (GPT, Claude, Llama): модель просто навчена передбачати наступний токен, маючи всі попередні (causal mask забороняє “бачити майбутнє”). Звідси й назва задачі: next-token prediction.

Як народжується LLM

1. Pretraining

Модель з випадковими вагами годують трильйонами токенів тексту (інтернет, книги, код) із завданням: передбач наступний токен. Це чисто self-supervised — розмітка не потрібна, бо “правильна відповідь” — це просто наступне слово в реальному тексті. Саме тут формуються “знання” моделі і левова частка вартості тренування (мільйони GPU-годин).

Параметри моделі (ваги w з розділу 2) — це те число, яке всі люблять згадувати: 7B, 70B, 405B… Це просто кількість навчених чисел у всіх матрицях мережі. Більше параметрів ≠ автоматично краще — важлива ще архітектура (dense vs MoE — Mixture of Experts, де активується лише підмножина “експертів” на кожен токен, що дає великий ефективний розмір при меншому compute на інференсі — так зроблені сучасні топові моделі).

2. Supervised Fine-Tuning (SFT)

Базова pretrained-модель вміє лише “продовжувати текст” — вона не вміє “відповідати на питання” в зручному форматі. На цьому етапі модель донавчають на парах (інструкція → правильна відповідь), написаних людьми/іншими моделями. Звідси модель стає instruct-моделлю.

3. RLHF / RLAIF (alignment)

• Людські оцінювачі (або інша AI-модель — Constitutional AI, підхід Anthropic) ранжують декілька відповідей моделі за якістю/безпечністю.
• На цих ранжуваннях тренується окрема reward model.
• Базову модель донавчають через reinforcement learning (PPO, або простіший DPO) максимізувати reward — тобто бути більш корисною, безпечною, менш токсичною.

Це і є різниця між “сирою” GPT-моделлю (передбачає текст) і ChatGPT/Claude (слухняно відповідає, відмовляється від шкідливих запитів, тримає формат).

Контекстне вікно і “пам’ять”

Модель не має пам’яті між запитами за замовчуванням — кожен виклик API stateless. “Пам’ять” в чаті — це просто весь попередній діалог, який щоразу заново передається в контекстне вікно (128K, 200K, 1M токенів залежно від моделі). Звідси й вартість: довгий діалог = дорожчий і повільніший кожен наступний запит, бо self-attention рахується по всій довжині знову.

Залізо: CUDA-ядра

Це той розділ, де твій DevOps-бекграунд реально допомагає — бо це питання про architecture & capacity planning, тільки на рівні кремнію.

Чому CPU не годиться

CPU оптимізований під послідовні, гетерогенні інструкції з low-latency (кілька потужних ядер, великий кеш, branch prediction). GPU оптимізований під масовий паралелізм однакових операцій — саме те, що потрібно для матричного множення в нейромережах, де мільйони незалежних операцій множення-додавання можна рахувати одночасно.

CPU:  8-64 потужних ядра    →  добре для: послідовна логіка, розгалуження
GPU:  тисячі простих ядер   →  добре для: однакова операція × мільйони даних (SIMT)

Що таке CUDA-ядро насправді

CUDA core — це найменший обчислювальний блок NVIDIA GPU, здатний виконати одну операцію множення-додавання за такт (FMA — fused multiply-add) на FP32. Сучасний GPU має десятки тисяч таких ядер, об’єднаних у Streaming Multiprocessors (SM) — це як “под” в Kubernetes: SM — це нода, CUDA-ядра всередині — контейнери, які виконують однакову роботу паралельно (модель виконання називається SIMT — Single Instruction, Multiple Threads).

Tensor Cores — окремий, спеціалізований тип ядра (з’явились в архітектурі Volta, 2017), заточений саме під одну операцію: матричне множення-накопичення (matrix multiply-accumulate) одним тактом для цілого блоку 4×4 чи більше, на змішаній точності (FP16/BF16/FP8/FP4 вхід → FP32 акумуляція). Тренування і inference LLM йде майже виключно через Tensor Cores, не звичайні CUDA-ядра — звідси, до речі, чому “кількість CUDA cores” у специфікаціях GPU давно вже не головна метрика для AI-навантаження, головне — TFLOPS на Tensor Cores відповідної точності.

Точність обчислень (precision) і чому це важливо

FP32 → FP16/BF16 → FP8 → FP4   (точність ↓, швидкість ↑, пам'ять ↓)

• Тренування зазвичай йде в mixed precision (BF16 + FP32 для накопичення градієнтів) — компромис швидкість/стабільність.
• Inference все агресивніше йде у FP8/FP4 квантизацію — модель “стискають”, округлюючи ваги до меншої точності, втрачаючи трохи якості, але виграючи в рази по швидкості, пам’яті і вартості. Це той самий принцип, що ти використовуєш, коли тюниш буфери чи стискаєш метрики — trade-off точність/ресурс, тільки тут трейдоф в математиці моделі.

Пам’ять: чому VRAM — це bottleneck

LLM повинен тримати всі параметри + KV-cache (про нього нижче) у відеопам’яті (VRAM/HBM) одночасно, бо кожен forward pass читає кожну вагу. 70B-модель у FP16 = ~140GB лише на ваги — більше за один GPU, звідси необхідність NVLink/InfiniBand для з’єднання кількох GPU в один логічний обчислювальний пул (концептуально дуже схоже на те, як ти агрегуєш bond0 між інтерфейсами для пропускної здатності >1Gbps — тут та сама ідея, тільки interconnect між GPU, а не NIC).

Поточний стан заліза (2026)

Blackwell додав нативні Tensor Cores з підтримкою FP4, подвоїв пропускну здатність NVLink до 1.8 TB/s і збільшив пам’ять до 192-288 ГБ HBM3e, тоді як архітектура Rubin переходить на пам’ять HBM4 з пропускною здатністю до 22 ТБ/с і використовує 224 Streaming Multiprocessors із шостим поколінням Tensor Cores.

Тренд, який варто розуміти на співбесіді: індустрія рухається не просто “більше ядер”, а в бік chiplet-дизайну (кілька кристалів в одному пакеті GPU) і оптичних interconnect — бо мережа між GPU стала таким же бутылочним горлом, як колись мережа між мікросервісами в твоєму кластері.

Тренування vs Inference

Це фундаментальна різниця, яку плутають навіть досвідчені кандидати.

KV-cache — найважливіша inference-оптимізація, яку треба знати

Коли модель генерує токен за токеном, для кожного нового токена не потрібно перераховувати Key/Value-вектори для всіх попередніх токенів заново — вони кешуються (KV-cache) і просто доповнюються. Без цього кожен новий токен вимагав би O(n²) перерахунку всієї історії — генерація стала б нестерпно повільною на довгих контекстах. Саме розмір KV-cache (а не тільки ваги моделі) — головний споживач VRAM при великому контекстному вікні і батчингу багатьох користувачів одночасно.

Throughput vs Latency — знайома тобі дилема

Provider-и LLM (OpenAI, Anthropic, тощо) батчать запити багатьох користувачів разом на одному GPU для максимізації throughput (token/sec на весь GPU) — точно та сама логіка, що в тебе з weighted backend pooling у HAProxy: максимізувати утилізацію пулу, балансуючи між latency окремого запиту і загальною пропускною здатністю.

Як з цим працюють зараз

Тут — практична частина: що насправді роблять інженери з LLM сьогодні, не на рівні дослідження, а на рівні продакшну.

1. Просто API-виклик

import anthropic

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1000,
    messages=[{"role": "user", "content": "Поясни KV-cache в двох рядках"}]
)

Stateless HTTP-запит — модель не “пам’ятає” тебе, кожен запит несе повний контекст.

2. Prompt Engineering

Інженерія того, як сформулювати запит, щоб отримати кращий результат: чіткі інструкції, приклади (few-shot), structured output (попроси JSON-схему), chain-of-thought (“думай крок за кроком”). Це найдешевший спосіб покращити результат — без жодного тренування.

3. RAG (Retrieval-Augmented Generation)

Модель не “знає” твою внутрішню документацію чи свіжі дані після training cutoff. RAG вирішує це так:

Запит користувача
   → embedding-модель перетворює запит у вектор
   → пошук найближчих векторів у vector DB (Qdrant, Pinecone, Weaviate, pgvector)
   → знайдені релевантні фрагменти документів вставляються в контекст
   → LLM генерує відповідь, маючи перед собою ці фрагменти

Це по суті семантичний пошук + генерація: vector DB зберігає embedding кожного документа, і пошук йде не по ключових словах, а по “близькості сенсу” у векторному просторі (та сама ідея ембедингів з розділу про трансформери). Для тебе як інфраструктурної людини: vector DB — це ще один stateful-сервіс, який треба деплоїти, моніторити і шардувати, як і будь-яку БД.

4. Fine-tuning vs RAG — коли що

В індустрії практичне правило: спочатку RAG + хороший промпт, fine-tuning — тільки якщо це не вистачає.

5. Агенти і tool use

Сучасні LLM вміють не просто відповідати текстом, а викликати функції (tool calling): модель повертає не текст, а структурований запит “виклич такий-то інструмент з такими параметрами”, застосунок виконує реальну дію (запит в БД, виклик API, виконання bash-команди) і повертає результат назад моделі для продовження. Це основа всіх “AI-агентів” — по суті LLM в циклі: think → act → observe → think…

MCP (Model Context Protocol) — відкритий стандарт (від Anthropic), що стандартизує, як LLM-застосунки підключаються до зовнішніх інструментів і джерел даних (схоже на те, як LSP стандартизував зв’язок IDE з мовними серверами) — замість того, щоб кожен інструмент писав власну, унікальну інтеграцію під кожну модель.

6. LLMOps / MLOps — твоя майбутня територія

Це природне продовження DevOps в AI-світ, і фактично ти вже маєш 80% потрібних навичок:

• Моніторинг inference: latency (TTFT — time to first token, та token/sec), GPU utilization, VRAM usage — той самий Prometheus + Grafana stack, тільки експортер тепер NVIDIA DCGM-exporter замість haproxy-exporter.
• Autoscaling inference-серверів (vLLM, TGI, Triton) під Kubernetes — ті самі HPA/VPA принципи, тільки скейлиться по GPU-метриках, а не CPU.
• Cost optimization: квантизація моделей, routing легких запитів на дешевші/менші моделі, кешування однакових промптів (prompt caching) — концептуально дуже схоже на твоє тюнінг squid/HAProxy для зменшення навантаження.
• CI/CD для моделей: версіонування ваг моделі, A/B тестування нової версії моделі на частині трафіку, rollback при регресії якості — той самий GitOps-підхід, тільки артефакт — не Docker-образ, а файл ваг.

Глосарій для співбесіди

Реальні питання на співбесідах

Q: Чим відрізняється AI від ML від Deep Learning? A: AI — найширше поняття (будь-яка імітація розумної поведінки). ML — підмножина AI, де система навчається на даних, а не на жорстко закодованих правилах. DL — підмножина ML, де навчання відбувається через багатошарові нейромережі.

Q: Що таке backpropagation простими словами? A: Алгоритм, що обчислює, як зміна кожної ваги в мережі вплинула би на помилку (loss), використовуючи ланцюгове правило диференціювання, рухаючись від виходу мережі назад до входу.

Q: Навіщо потрібен attention-механізм, якщо є RNN? A: RNN обробляють послідовність токен за токеном, що не масштабується паралельно і страждає від vanishing/exploding gradient на довгих послідовностях. Attention дозволяє кожному токену напряму “дивитись” на будь-який інший токен одночасно, що паралелиться на GPU і краще тримає довгі залежності.

Q: Чим CUDA-ядра відрізняються від Tensor Cores? A: CUDA-ядра — універсальні обчислювальні блоки для скалярних FP32-операцій. Tensor Cores — спеціалізовані блоки саме під матричне множення-накопичення на змішаній точності (FP16/FP8/FP4), що є основною операцією тренування і inference нейромереж — і працюють на порядок швидше для цієї конкретної операції.

Q: Чому LLM “забуває” контекст у довгому діалозі? A: Технічно модель нічого не “забуває” — у неї просто немає пам’яті між запитами взагалі. Кожен запит передає весь попередній діалог заново, обмежений контекстним вікном (наприклад 200K токенів) — коли діалог перевищує цей ліміт, старіші частини просто відсікаються або стискаються.

Q: Що краще: RAG чи fine-tuning? A: Залежить від задачі. RAG — коли потрібна свіжість даних і прозорість джерел, дешевше і швидше впровадити. Fine-tuning — коли потрібна стабільна зміна стилю/поведінки моделі на рівні, якого промптом не досягнути. На практиці часто комбінують.

Q: Що таке hallucination і чому це відбувається? A: Модель навчена передбачати ймовірний наступний токен, а не “перевіряти факти” — коли немає достатньо сигналу в тренувальних даних або контексті, вона все одно генерує граматично і стилістично правдоподібний текст, який може бути фактично невірним.

Від мене особисто

Декілька речей, які я б сказав чесно, виходячи за межі підручникового пазлу:

1. “Розуміння трансформера” і “розуміння продакшн LLM-систем” — це дві різні компетенції, і друга зараз цінується вище. Більшість співбесід на DevOps/Infra-ролі з AI-компонентом не питають вивести формулу attention — питають, чи розумієш ти, чому inference дорогий, де бутылочне горло (VRAM, не compute, в більшості випадків при низькому батчингу), і як збудувати моніторинг/autoscaling під це. Математику варто знати на рівні “можу пояснити на пальцях”, а не “можу довести з нуля” — якщо ти не йдеш у Research-роль.

2. “Кількість параметрів” як метрика себе вже майже віджила. MoE-архітектури (де активна лише частина мережі на токен), агресивна квантизація і дистиляція означають, що порівнювати моделі за “16B vs 70B” дедалі менш інформативно — реальна метрика, яку питають у продакшн-командах — це cost per million tokens і latency per token при заданій якості, а не “розмір”.

3. Найбільш недооцінена тема на співбесідах — KV-cache і batching. Дуже мало кандидатів можуть пояснити, чому довгий контекст коштує дорожче по пам’яті, а не лише по часу, і чому provider-и так агресивно батчать запити. Якщо ти єдиний в кімнаті, хто може намалювати, де саме живе бутылочне горло пам’яті при inference — це сильно виділяє.

4. Hype-цикл навколо “AGI” і “агентів, що замінять інженерів” варто розглядати окремо від інженерної реальності. Те, що реально працює в 2026 — це вузькі, добре заскоуплені агенти з чітким tool use і human-in-the-loop на критичних кроках, а не автономні системи без контролю. На співбесіді краще показати тверезий, інженерний погляд (“це інструмент із чіткими лімітами”), ніж або сліпий ентузіазм, або скепсис без аргументів — обидва читаються як брак реального досвіду роботи з цими системами.

5. Якщо хочеш реальну перевагу на технічній співбесіді — піднімі один маленький inference-сервер локально (vLLM чи llama.cpp із квантизованою моделлю на своєму Proxmox-хості, наприклад) і подивись на nvidia-smi, GPU utilization, VRAM під навантаженням. Один вечір практики дає більше інтуїції про “що насправді відбувається”, ніж тиждень читання теорії — це той самий принцип debug-first hypothesis, який ти й так використовуєш у мережевих задачах, просто застосований до нової області.