Коли ви в ChatGPT, Claude або DeepSeek вводите текст, модель починає відповідати одне за одним символом за кілька сотень мілісекунд — цей процес здається простим, але насправді є однією з найтонших інженерних задач у сучасних обчисленнях. У цій статті зібрано повний розбір ланцюжка міркувань AI-інженера Akshay Pachaar: від tokenization, embedding, attention до двох етапів prefill/decode, KV cache, квантизації та того, чому DeepSeek V4 скоротив обсяг кешу до 10% від початкового.
Ключова ментальна модель: LLM — це просто «вгадування наступного token», а потім повторення
За своєю суттю великі мовні моделі роблять лише одну річ: прогнозують наступний token. Вони отримують вашу послідовність вхідних token, обчислюють розподіл імовірностей для наступного token, обирають (семплюють) один token, додають його наприкінці до входу, а далі знову прогнозують наступний — і так безперервно, доки модель не видасть маркер зупинки або не досягне ліміту.
Головне питання всього процесу inference не в тому, «як саме вона прогнозує», а в тому, «чому другий token виходить набагато швидше за перший?». Відповідь виводить на два найважливіші поняття сучасного сервісу LLM: етапи prefill і decode та KV cache.
Step 1：Tokenization перетворює текст на числа
Нейромережі не читають текст — вони працюють з векторами. Тому ваш промпт спершу проходить tokenization: текст розбивають на шматочки token, і кожному token відповідає цілий числовий ID. Більшість сучасних LLM використовують BPE (Byte Pair Encoding, байт-парне кодування): від стартових символів послідовно зливають найчастіші пари символів, а врешті формують словник приблизно з 50 тис. найуживаніших token.
Цей крок впливає сильніше, ніж здається більшості. Мови, які в навчальних даних токенізатора мають меншу частку, нарізаються на більше token — тож зростають витрати на inference і падає швидкість. Китайська, зокрема традиційна китайська, у багатьох tokenizer, орієнтованих на англійську, часто перетворюється так, що кожен символ розбивається на 2–3 token — і це одна з причин, чому витрати на inference для китайських користувачів зазвичай вищі.
Step 2：Embedding перетворює цілі ID на вектори й «вшиває» позиційну інформацію
Кожен цілий ID токена звертається до великої «embedding-таблиці». Якщо словник моделі має 50K токенів, а прихована розмірність — 4096, то форма цієї таблиці: [50000, 4096]. Кожен token витягує один рядок, і цей рядок є його 4096-вимірним представленням.
Ці вектори не є випадковими: під час тренування модель «підтягує» токени з близькою семантикою в одну й ту саму ділянку простору — king і queen поруч у певному напрямку, python (мова) і javascript — в іншому, python і snake (змія) — у третьому.
Позиційну інформацію також додають на цьому етапі, бо механізм attention сам по собі не знає, який token стоїть раніше, а який — пізніше. У більшості актуальних моделей застосовують RoPE (Rotary Position Embedding, ротаційне позиційне кодування): вектор повертають на кут залежно від позиції токена, тож упорядкованість прихована у самому векторі.
Step 3：Self-Attention — ядро Transformer
Далі послідовність векторів входить у 32 шари (або більше) transformer. Кожен шар робить дві речі: змішує інформацію між токенами через self-attention, а потім змішує інформацію всередині кожного token через feed-forward.
Як працює self-attention: кожен token пропускають через три навчені матриці ваг Wq, Wk, Wv, отримуючи три вектори — query (запит), key (ключ) і value (значення). Далі query кожного token робить скалярний добуток з key усіх інших токенів: це дає ваги «скільки інформації цей токен має підтягнути з інших позицій», а потім ці ваги використовують, щоб зважено змішати value.
У цьому й магія attention: кожен token сам вирішує, на які позиції в контексті варто звернути увагу, і тягне корисну інформацію у власний вектор. Коли таких шарів 32, модель здатна відстежувати смислові зв’язки через тисячі token. Після attention іде feed-forward, який несе на собі більшу частину «знань» моделі: attention займається переносом інформації, а feed-forward — її опрацюванням.
Prefill і Decode: той самий GPU, але два принципово різні «вузькі місця»
Це найважливіший поділ у цій статті. Генерація відповіді на 200 слів на практиці складається з двох задач з повністю різними характеристиками, які виконуються на тій самій GPU.
Prefill-етап — коли ви надсилаєте промпт, модель має спочатку прогнати всі вхідні token, щоб згенерувати перший token. На цьому етапі можна «паралельно» обробити всі вхідні token: для кожного token Q, K і V рахують одночасно, а attention реалізується як множення великих матриць на матриці. GPU створений саме під такі обчислення: блоки обчислень (Tensor Cores) завантажені на максимум, а вузьким місцем стає «обчислювальна потужність». Цей етап вимірюють показником TTFT (Time to First Token, час до першого token).
Decode-етап — після того, як з’явився перший token, модель перемикається в інший режим. Коли генерується 51-й token, потрібно порахувати лише Q, K і V для цього нового токена: K і V для попередніх 50 token вже пораховані раніше, тож перераховувати їх не треба. Проблема в тому, що обчислення на один token стають невеликими, але GPU все одно мусить з пам’яті (включно з відеопам’яттю) підтягнути ваги всієї моделі та весь історичний KV, виконати маленьку операцію, а потім записати результат назад. Тож вузьке місце переходить від «compute» до «memory bandwidth» (пропускної здатності пам’яті). Показник тут — ITL (Inter-Token Latency, затримка між токенами), і саме він визначає, наскільки «швидко друкує» модель.
Отже, prefill — compute-bound, decode — memory-bound. Та сама модель, та самі апаратні ресурси, але зовсім різні характеристики продуктивності.
KV Cache: ключова оптимізація, що робить inference реалістичним
На decode-етапі «не перераховують» минулі token, а замість цього використовують KV cache. Кожен transformer-шар підтримує два тензори: K і V для всіх попередніх токенів. Після обчислення K і V для нового token їх просто додають (append) у кеш, а при attention читають одразу всю історію.
Без KV cache генерація відповіді на 1 000 token означала б, що на кожному кроці треба б заново перераховувати весь зростаючий послідовний ряд, і складність вибухала б квадратично. З KV cache довгі генерації можна прискорити більш ніж у 5 разів. Але є ціна: кеш зберігається у GPU-відеопам’яті, і щоразу, коли додається новий token, кеш збільшується. Для моделі 13B на кожен token припадає близько 1 МБ; контекст 4K «з’їдає» близько 4 ГБ відеопам’яті лише на зберігання цього cache.
Саме це і є справжньою причиною «довгий контекст повільний і дорогий» — справа не в тому, що модель «не може дотягнути», а в тому, що кеш з’їдає відеопам’ять, і кількість користувачів, яку один GPU може обслуговувати одночасно, падає. Типові методи оптимізації включають: квантизувати cache до INT8 або INT4, викидати надто старі token через sliding window, застосувати grouped-query attention (GQA), щоб кілька attention head спільно використовували K і V, або, як у vLLM, використовувати PagedAttention — розподіляти кеш на сторінки та керувати ним (аналогічно тому, як операційна система керує пам’яттю).
Революція кешу DeepSeek V4: у контексті 1 млн token скорочення до 10% від початкового
Квантизація та paging перетворюють KV cache на «фіксовану вартість». Серія V4 від DeepSeek, яку анонсували наприкінці 2025 року, обрала ще радикальніший шлях: напряму переосмислити attention так, щоб кеш з самого початку був значно меншим.
V4 використовує змішаний механізм, поєднуючи дві варіації компресії attention — sparse і dense — і обидві працюють поверх сильно стисненого потоку KV. У середовищі контексту на 1 млн token звіт V4-Pro показує, що обсяг KV cache становить лише близько 10% від попередників, а обчислення на один token — лише приблизно 27%. Сенс не лише в тому, що «DeepSeek знову став дешевшим», а в тому, що KV cache перетворився на вузьке місце, яке оптимізують у всій галузі LLM: якщо attention-алгоритм сам по собі змінюють, щоб зменшити кеш, то «обмежувальна умова» всієї технічної спільноти змістилась повністю.
Для читачів із Тайваню практично корисна інформація така: DeepSeek V4-Flash вже доступний в Ollama Cloud і на серверах у США (див. abmedia 4/24), а також у Claude Code та OpenClaw — можна одним кліком з’єднати й без власного складного розгортання перевірити переваги нового покоління attention саме в сценаріях довгого контексту.
Quantization：обмінюйте точність на швидкість і відеопам’ять
Тренуванню потрібна висока точність, а inference — ні. У більшості реальних деплойментів відразу переходять із FP32 на FP16 або BF16: це дає подвійний приріст по відеопам’яті та throughput. Найрадикальніший підхід — квантизувати ваги до INT8, а інколи навіть до INT4.
Цифри інтуїтивні: модель на 7B параметрів у FP32 потребує 28 ГБ, у FP16 — 14 ГБ, у INT8 — 7 ГБ, у INT4 — лише 3,5 ГБ. Тому навіть відеокарти на звичайних ноутбуках можуть запускати 7B-моделі. Такі методи, як GPTQ і AWQ, підбирають коефіцієнти масштабування для кожного каналу, щоб мінімізувати втрату якості через компресію з відхиленням — добре спроєктований INT4 у більшості бенчмарків відстає від оригіналу лише в межах 1 відсоткового пункту.
З’єднаймо всі кроки в один ланцюг: повний шлях для одного промпта
Якщо з’єднати всі етапи разом, повний шлях одного inference виглядає так: (1) Tokenize — текст перетворюють на цілі ID. (2) Embed — ID стають векторами й отримують додану позиційну інформацію. (3) Prefill — всі шари паралельно обробляють усі вхідні token; це compute-bound, KV cache створюється, генерується перший вихідний token. (4) Decode loop — кожного кроку проєктують лише новий token: роблять attention до K і V у cache, проганяють через feed-forward, семплюють вихід, записують нові K і V назад у cache; це memory-bound. (5) Detokenize — token ID перетворюють назад у символи й стрімлять вивід на екран.
Фреймворки на кшталт vLLM, TensorRT-LLM, Text Generation Inference додають поверх цього циклу: безперервні пачки (токени різних користувачів можуть переплітатися в одному GPU step), speculative decoding (маленька модель робить «чернетку», велика підтверджує), і тонке керування пам’яттю — і саме так один GPU може обслуговувати десятки користувачів.
Практичний висновок для розробників: що вам важливіше — TTFT чи ITL?
Коли у вас зрозуміла повна картина процесу inference, кілька практичних рішень виникають самі собою:
Довгі промпти підсилюють TTFT, а довгі виходи підсилюють ITL — це різні джерела навантаження, тож не розкладайте ресурси оптимізації «на неправильний» індикатор. Контекст не безкоштовний: збільшення довжини контексту не лише подвоює обчислення, а й стискає те, скільки пачок KV cache здатний вмістити. Квантизація — це зараз кнопка з найбільшим важелем: заміна FP16 на INT8 часто скорочує затримку приблизно наполовину за дуже малого падіння якості. І показник utilization (завантаженість GPU) також часто вводить в оману: prefill може завантажити GPU на максимум, а decode інколи використовує лише 30% — рішення не в тому, щоб додати більше обчислювальної потужності, а в тому, щоб мати швидшу пам’ять або менший cache.
Архітектура Transformer привертає найбільше уваги, але реальна ефективність inference живе в «скучних деталях»: конфігурації пам’яті, керуванні cache, ширині біти. Коли хтось каже «ця модель повільна», наступне питання має бути не «поставимо інший GPU», а «вона повільна на етапі “старту” чи на етапі “стримінгу”?» — саме відповідь визначає весь шлях оптимізації.
Ця стаття з повним підручником з inference для LLM: KV cache та революція кешу DeepSeek V4 — з’явилась найперше у 鏈新聞 ABMedia.
