Кінцево-кінцеве інференсування LLM: попереднє заповнення, декодування, кеш KV та вибір зразків.

Від натискання клавіші до потокового токена

Цей посібник описує весь процес інференсу — токенізацію, ембеддинги, механізм уваги, кеш KV, вибір зразків та спекулятивне декодування — та відповідає на складні запитання на кожному етапі. Метою є створення чіткої ментальної моделі, готової до використання, а не презентація продукту постачальника.

Частина 1 — Два завдання, а не одне

Питання 1. Що відбувається між натисканням клавіші Enter та першим словом?

Чесний опис процесу від початку до кінця:

1. Вхідні дані. Надходить рядок у форматі UTF-8, наприклад "Що таке гравітація?". Система обробки зазвичай обгортає його у шаблон чату зі спеціальними токенами для черг системи, користувача та асистента.
2. Токенізація. Текст розділяється на частини та приводиться до цілочисельних ідентифікаторів. Цей крок — це чиста обробка рядків; ще немає нейронної мережі.

Вбудоване пошукове знаходження. Кожен ID вибирає рядок з матриці ембеддингів E ∈ ℝ^(V × d_model), що дає тензор розміром (seq_len, d_model). Позиційний сигнал додається тут або пізніше під час механізму уваги (RoPE).

Попереднє заповнення. Кожен токен запиту проходить через усі N шарів трансформера одночасно. Кожен шар зберігає свої проекції K та V у KV-кеші. Цей етап обмежений обчислювальними ресурсами.

Голова LM. Лише прихований стан останньої позиції проектується у розмір словника (~128K логітів).

Вибір зразка. Функція Softmax перетворює логіти на розподіл; політика (греґері, top-k, top-p, температура тощо) вибирає один ID.

Цикл декодування. Цей ID додається, вбудовується та знову передається через стек разом із кешем KV — по одному новому токену на крок — поки не спрацює правило зупинки.

Детокенізація та передача потоком. ID перетворюються на фрагменти тексту; сервер може надсилати часткові рядки клієнту як тільки вони стають коректними.

Час до отримання першого токена майже завжди включає етап попереднього заповнення. Усе, що йде далі, — це процес декодування.

Питання 2. Чому інференс називають двома різними завданнями?

Попереднє заповнення та декодування знаходяться на протилежних сторонах моделі roofline.

Вузьке місце FLOPs / обчислення Ширина пропускної здатності пам’яті Інтенсивність арифметичних операцій Висока ~1–2 FLOPs/байт при пакеті 1 Між токенами Повністю паралельно Суто послідовно Параметр затримки TTFT TPOT / ITL Масштабується з Довжиною запиту Довжиною результату MFU (пакет 1) Часто 40–60% Часто 1–5%

При попередньому завантаженні ви завантажуєте ваги один раз та застосовуєте їх до тисяч векторів токенів. При декодуванні ви знову завантажуєте ті самі ваги для одного вектора — гігабайти даних переміщуються заради мільйонів FLOPs. GPU чекає на дані з HBM.

Майже кожен трюк з обробки даних — групування, кеш KV, квантація, спекулятивне декодування, FlashDecoding, роз’єднане попереднє заповнення/декодування — існує для живлення цього „голодного“ обчислювального пристрою.

Q3. Які показники затримки мають значення, і які параметри їх впливають?

• TTFT — переважно попереднє заповнення; зростає з довжиною запиту (і ще більше, коли домінує механізм уваги). Допомагають кеш префіксів, часткове попереднє заповнення, швидша обробка уваги, коротші запити.
• TPOT / ITL — переважно декодування; приблизно дорівнює bytes_per_step / bandwidth. Допомагають квантація, GQA/MQA, спекулятивне декодування, менші моделі.
• End-to-end ≈ TTFT + TPOT × кількість токенів вихідного результату.
• Пропускна здатність (токени/секунда/GPU) — показник для цілого комплексу; більші групи даних підвищують її, але зазвичай погіршують TPOT на рівні окремого користувача.

Пропускна здатність та затримка взаємно конкурують. Політика обслуговування — це вибір точки на цій кривій.

Q4. Чому декодування не можна паралелізувати, як попереднє заповнення?

Генерація є авторегресивною: кожен новий токен залежить від усіх попередніх. Попереднє заповнення вже знає весь запит, тому позиції можна обчислювати разом за допомогою причинно-наслідкової маски. Під час декодування „майбутнє“ ще не існує.

Спекулятивне декодування є рішенням проблеми: спочатку створюються дешеві припущення, а потім вони перевіряються під час одного паралельного проходу — таким чином послідовна залежність перетворюється на паралельну перевірку (Частина 8).

Частина 2 — Етапи один та два: введення тексту

Q5. Що таке токен — і чому цілі слова чи сирі символи є неправильними крайнощами

Токен — це субсловесна одиниця з фіксованого словника. Чисті крайнощі є недоцільними:

• Словні запаси є необмеженими; опечатки та рідкісні назви перетворюються на <UNK>, що руйнує інформацію та спричиняє збільшення розміру таблиці ембеддингів.
• Запаси символів уникають ситуації OOV, але подовжують послідовності у 4–5 разів, що погіршує ефективність квадратичної уваги та змушує ранні шари заново аналізувати морфологію.

Субслова знаходять компроміс: поширені слова залишаються цілими; рідкісні форми розбиваються на змістовні фрагменти; ніщо насправді не є OOV.

Q6. Як навчається BPE?

Byte-Pair Encoding починається з символів (або байтів) та постійно об’єднує найчастіші сусідні пари, поки не досягаєтьте бажаного розміру словника. Об’єднання зберігаються у вигляді ранжованого списку. Під час інференсу ці ж об’єднання застосовуються ліворуч-праворуч. Навчання ґрунтується на статистиці кількостей, а не на градієнтному спуску — проте отримана сегментація впливає на все подальше оброблення даних.

Q7. BPE проти WordPiece проти Unigram / SentencePiece

• BPE — об’єднання за частотою; декодування є детермінованим за наявності таблиці об’єднань.
• WordPiece (ера BERT) — схоже об’єднання, але оцінювання відбувається за ймовірністю; часто використовує маркери продовження ##.
• Unigram / SentencePiece — починається з великого набору кандидатів та видаляє елементи за допомогою уніграмного LM; може генерувати різні варіанти сегментації та ефективно обробляти необроблені байти/Unicode без використання претокенайзерів, специфічних для певної мови.

Сучасні продакшн-моделі LLM схиляються до варіантів BPE чи SentencePiece на рівні байтів.

Q8. Чому BPE на рівні байтів?

Робота з необробленими байтами гарантує, що кожна стрінг може бути закодована — без несподіваних проблем з Unicode. Словник все одно вивчає поширені багатобайтові фрагменти, тож англійська мова залишається ефективною, тоді як рідкісні писемності грайливо переходять на байтові альтернативи.

Q9. Чому моделі помиляються під час підрахунку літер у слові “strawberry”?

Тому що модель ніколи не бачить символів; вона бачить ID токенів. Якщо "strawberry" складається з одного чи двох токенів, запит “підрахуй ‘r’” стосується структури, яка вже була видалена до першого шару. Завдання на рівні символів вимагають або токенайзера, який зберігає символи, або зовнішнього інструменту.

Q10. Чи мають ID токенів яке-небудь значення окремо?

Ні. ID — це лише індекс у таблиці ембеддингів цієї моделі. ID 100 у одному токенайзері не має відношення до ID 100 у іншому. Ніколи не використовуйте токенайзери різних моделей разом.

Q11. Підводні камені виробничих токенайзерів

• Шаблони чату та спеціальні токени мають відповідати процесу навчання.
• Пробіли на початку часто стають окремими токенами — " Hello" ≠ "Hello".

Обрізання може тихо видаляти системні інструкції, якщо рахувати символи замість токенів.

Багатомовні альтернативи у вигляді байтів збільшують довжину та витрати.

Спеціальні багатомодальні токени для зображень/аудіо змінюють правила пакування.

Q12. Компроміси між розміром словника та продуктивністю

Більший розмір V скорочує послідовності та сприяє підтримці багатьох мов, але збільшує параметри ембеддингів та голови моделі (кожен з них — V × d_model) та витрати на декодування за допомогою softmax. Типові сучасні значення знаходяться в діапазоні 32K–150K; поза цим діапазоном ви платите за пам’ять та пропускну здатність, отримуючи все меншу вигоду.

Q6. Як насправді навчається BPE

Кодування пар байтів використовується як метод стиснення, який потім застосовується для формування словника:

1. Сформуйте словник з базових символів (для BPE на рівні байтів: усі 256 байтів).
2. Виразіть корпус у вигляді послідовностей цих символів.
3. Підрахуйте сусідні пари; оберіть найчастіші.

Об’єднайте цю пару в новий символ, додайте його до словника та зафіксуйте правило об’єднання з визначеним порядком.

Повторюйте цей процес, поки не досягнете бажаного розміру (наприклад, ~100K–128K у сучасних системах).

Артефакти: карта символ→ID та впорядкований список об’єднань. Кодування під час відтворення даних здійснюється шляхом жадібного об’єднання в цьому порядку — детерміновано, без пошуку найкоротших сегментів у всьому об’ємі даних.

Нюанс: об’єднання оптимізують частоту використання, а не лінгвістичні аспекти. ing стає токеном через свою поширеність; морфологічна витонченість є другорядною.

Q7. BPE проти WordPiece проти Unigram / SentencePiece

• BPE (GPT-line, Llama): об’єднання за частотою; детерміноване кодування.

WordPiece (ера BERT): схожий алгоритм, але обирає злиття, які максимізують ймовірність даних навчання в рамках уніграмного моделювання — оцінюючи, наскільки інформативною є пара разом та окремо.

Unigram LM (часто через SentencePiece; клас T5/Gemma): починає з великої кількості токенів та видаляє ті, чия видалення найменше впливає на ймовірність. Ймовірнісна сегментація дозволяє здійснювати регуляризацію підсловами (вибір альтернативних способів розщеплення під час навчання).

SentencePiece — це бібліотека, яка може використовувати алгоритми BPE чи Unigram. Її практичною перевагою є обробка необроблених символів із видимим маркером пробілу, що робить токенізацію зворотною та позбавленою попередньої обробки пробілів — що має вирішальне значення для китайської, японської та тайської мов.

Q8. BPE на рівні байтів важлива тому, що…

Для ініціалів у форматі Unicode-символів знадобиться близько 150 тис. кодів, і все одно буде потрібен <UNK>. Використання UTF-8 байтів означає, що кожен рядок — емодзі, кирилиця, пошкоджені байти — може бути закодований. Жодних випадків OOV.

Витрати: емодзі можуть споживати кілька токенів; нелатинські алфавіти часто коштують у 2–4 рази більше, ніж англійська мова для того самого значення, тому користувачі, які використовують неанглійські мови, швидше досягають обмежень кількості запитів та лімітів контексту. Більші словники (зростання від 32 тис. до 128 тис.) існують частково для зменшення цієї різниці у справедливості.

Q9. Чому запитання „Скільки літер ‘r’ у слові strawberry?“ не спрацьовує?

Мережа ніколи не бачить літер; вона бачить ідентифікатори. Якщо strawberry складається з кількох підслів, для підрахунку символів необхідно відновлювати правопис з ембеддингів та агрегувати дані — відсутня вбудована операція „перебір символів“. Така сама проблема виникає з анаграмами, паліндромами, оберненими послідовностями та примітивною арифметикою, коли групування цифр у різних числах є непослідовним. Сучасні токенайзери іноді примушують розділяти цифри саме для того, щоб арифметичні операції стали можливими.

Q10. Ідентифікатори токенів окремо

Ідентифікатор — це індекс у таблицях того конкретного моделювання. Порівнювати токенайзери між собою не має сенсу. Навіть „спеціальні“ ідентифікатори відрізняються між різними сім’ями токенайзерів.

Q11. Підводні камені у продакшені

Обов’язковим є відповідність навчального шаблону чату та набору спеціальних токенів. Пробіли на початку часто є справжніми токенами. Підрахунок символів під час формування рахунку від API приховано обрізає інструкції. Мультимодальні сентинель-токени змінюють спосіб пакування даних. Ключі кешу мають містити інформацію про версію токенайзера. Неправильна обробка значень BOS/EOS порушує умови зупинки та перевірку значень logprob.

Q12. Компроміси між розміром словника та продуктивністю

Більший розмір V скорочує послідовності та допомагає у багатомовному пакуванні, але збільшує параметри ембеддингів, голови моделі та функції декодування softmax. При розмірі близько 100K–200K зазвичай доводиться платити за пам’ять та пропускну здатність за незначне покращення якості, хіба що це необхідно для підтримки багатьох мов.

Частина 3 — Ембеддинги

Q13. Ембеддинги: метод gather чи matmul

Пошук у рядку еквівалентний множенню вектора one-hot на E. Метод gather використовує спеціальні кернелі; математичні операції залишаються лінійними.

Q14. Чи є ембеддинги контекстуальними?

Рядки вхідних даних є безконтекстними. Контекст формується шляхом уваги між шарами. Ембеддинги, отримані під час пошуку, зазвичай є більш глибокими станами, а не рядком таблиці вхідних даних.

Q15. Зв’язування ваг

Щоб заощадити параметри, ваги ембеддингів діляться з головою LM (шляхом транспозиції) — це поширено у менших моделях. Великі LM часто роз’єднують ваги для покращення якості. Зв’язані голови не є додатковою незалежною матрицею d × V.

Q16. Інформація про позицію

Абсолютні ембеддинги додають вектори для кожного індексу. RoPE обертає Q/K, щоб відносні зсуви відображалися у оцінках та сприяли кешуванню KV. Альтернативами є схеми відносних зміщень; RoPE домінує у нових LLM.

Q17. RoPE та розширення для довгого контексту

Відносна геометрія RoPE дає кращі результати при екстраполяції, ніж примітивні абсолютні таблиці. Розширення (інтерполяція положень, масштабування з урахуванням NTK, YaRN тощо) перескальовують частоти обертання, щоб довші контексти залишалися стабільними без необхідності повторного навчання з нуля.

Q18. Коефіцієнт √d_model

Коли вектори токенів та положень додаються, масштаби можуть конфліктувати; помноження ембеддингів на √d_model допомагає їх збалансувати. У RoPE, заснованих на обертанні, це помноження часто пропускається.

Частина 4 — Блок трансформера

Q19–Q23. Механізми уваги (розширено)

x → MultiHeadSelfAttention → Add & Norm → FFN → Add & Norm → out

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

Запити шукають, ключі рекламують, значення доставляють. Функція Softmax над масштабованими значеннями забезпечує формування ваг для змішування. Ділимо на √d_k, щоб оцінки не сатурували зі збільшенням ширини. Багато голів диверсифікують підпростори. Причинні маски записують −∞ у заборонені майбутні стани, щоб сума значень Softmax дорівнювала рівно нулю — проте нулі в масці все одно можуть спричинити витік інформації. Під час чистого декодування з кешем набір ключів не містить позицій у майбутньому, тож маска є імпліцитною; префілінг все одно потребує маскування (або причинного ядра).

Q24–Q26. Форми, витрати, залишки

Кожен прогноз має розмір приблизно ~d × d (з модифікаціями за GQA). FFNи займають більшу кількість параметрів завдяки майже у 4 рази більшому розширенню. Витрати на увагу зростають за законом O(n² d); FFNи — за законом O(n d²). Короткі запити: обмеження через ваги/FFNи. Довгі контексти: домінують механізми уваги та пам’ять KV. Резидуали дозволяють тренувати глибокі стеки, створюючи «шляхи градієнтів» та додаткові корективи.

Q27–Q30. Нормування, ширина FFNів, активації, MoE

RMSNorm омине центрування за середнім значенням та є дешевшим за LayerNorm. Попереднє нормування стабілізує дуже глибокі мережі порівняно з класичним післянормуванням. Широкі FFNи (~4×) збільшують пропускну здатність між елементами уваги. Нелінійності запобігають занепаду стекованих лінійних моделей; SwiGLU виграв багато тестів на ефективність LLM. MoE спрямовує токени до кількох експертних FFNів, тож параметри зростають швидше, ніж кількість FLOPs на токен — це вимагає багато пам’яті, але має низьку обчислювальну інтенсивність.

Q31–Q32. Глибина/ширина та варіанти механізму уваги

Глибина повторює процес змішування; ширина покращує характеристики. Лабораторії обирають підходи в межах обсягу даних та кількості кластерів. MHA зберігає K/V для кожного елемента; MQA ділиться одним K/V між усіма запитами; GQA ділиться K/V в межах групи; MLA ще більше стискає дані KV. Витрати на обробку спонукали індустрію розвиватися саме в цьому напрямку.

Частина 5 — Кеш KV

Q33. Що таке кеш KV, і чому лише K та V?

На етапі декодування t надходить один новий токен. Його запит q_t має охоплювати ключі та значення для позицій 1..t. Ключі та значення для 1..t−1 залежать лише від попередніх токенів та фіксованих ваг. Принцип причинності гарантує, що введення токена t не може змінити ці попередні тензори K/V — вони є незмінними, тому їх обчислюють один раз та зберігають.

Запити відрізняються: для поточного кроку вам потрібен лише q_t. Старіші запити вже дали старіші результати та більше ніколи не будуть прочитані, тому кешування Q — це марна витрата пам’яті.

Без кешу для генерації токена t доводиться перевиконувати весь префікс — робота, яка стрімко зростає з довжиною. З кешем увага на кожному кроці є лінійною від поточної довжини, а FFN фактично виконує постійну кількість операцій за кожен новий токен. Генерація стає лінійною від кількості кроків декодування замість квадратичної від кількості проходжень.

Q34. Визначте розмір кешу KV за допомогою реального числа

KV bytes = 2 (K and V)
         × n_layers
         × n_kv_heads × d_head
         × seq_len
         × batch_size
         × bytes_per_element

Використайте схему GQA класу Llama-3–70B: вісімдесят шарів, вісім голів ключа/значення, сто двадцять вісім вимірів на кожну голову, збережені у двобайтових числах з плаваючою комою.

Помножте ці коефіцієнти: два тензори (K та V) × вісімдесят × вісім × двадцять вісім одиниць × два байти дають приблизно 320 КБ на кожен токен кожної поточної послідовності.

Якщо розглянути діалог із 8 тисяч токенів, це становить близько 2,6 ГБ на одного користувача. При контексті у 128 тисяч токенів та сама формула вказує на десятки ГБ — достатньо, щоб одна розмова зайняла значну частину пристрою класу H100 ще до того, як будуть враховані ваги.

У гіпотетичному сценарії без GQA (64 KV-голови) показник для 8 тисяч токенів зростає до приблизно ~21 ГБ на послідовність. GQA — це різниця між десятками одночасних користувачів та кількома десятками.

Ваги – це фіксований збір, який сплачується один раз. Кеш KV є незалежним від користувача та токену, без обмежень збором. Він визначає максимальний розмір пакету, що впливає на пропускну здатність, а це, у свою чергу, визначає суму грошей за мільйон токенів. Саме тому на діаграмах його позначають як основну перешкоду в пам’яті.

Q35. Чому декодування обмежене пам’яттю — арифметика

Розглянемо модель 70B у форматі fp16, яка обробляє один токен у пакеті 1:

• Кількість пересуваних байтів: ~140 ГБ ваг плюс кілька ГБ даних KV ≈ 142 ГБ.
• FLOPs: ≈ 2 × 70e9 × 1 = 140 GFLOPs.
• Інтенсивність: ≈ 1 FLOP/байт.

Процесор H100 забезпечує пропускну здатність HBM близько 3,35 ТБ/с та потужність обчислень у форматі fp16 близько 1000 TFLOPs. Точка, де обчислення випереджають пропускну здатність пам’яті, досягається при сотнях FLOPs/байт. При інтенсивності 1 FLOP/байт використовується лише незначна частина максимальних обчислювальних ресурсів – GPU переважно виконує функцію переміщення даних у пам’яті.

Час обробки ≈ 142 ГБ / 3,35 ТБ/с ≈ 42 мс → близько 24 токенів/с лише завдяки пропускній здатності. У реальних системах показники знаходяться в межах двохкратного діапазону цього оцінювання, що свідчить про те, наскільки суворо діють правила, пов’язані з пропускною здатністю.

Висновок: збільшення розміру пакету майже не впливає на навантаження на обчислювальні ресурси, поки не виникне обмеження через потужність процесора. Перехід від пакету розміром 1 до 32 дозволяє використовувати один набір параметрів для 32 послідовностей, що може значно підвищити пропускну здатність за рахунок токенів. Саме це зменшення витрат є ключовим економічним фактором у роботі моделей LLM.

Q36. Якщо обробка в пакетах є „безкоштовною“, чому не обробляти 512 елементів за раз?

Тому що кожна послідовність має власний обсяг даних KV, а об’єм кеш-пам’яті зростає пропорційно пакет × довжина послідовності:

GPU memory = model weights + KV cache + activations + fragmentation overhead

Приклад: 140 ГБ параметрів на 2×H100 (160 ГБ) залишає близько 20 ГБ для кешу. При пропускній здатності 320 КБ/токен це дає близько 65 тис. токенів у всьому пакеті. Шістнадцять користувачів із контекстом розміром 4 КБ вже повністю використовують цей бюджет.

Отже, обмеження розміру KV обмежує розмір пакета даних, що у свою чергу обмежує пропускну здатність. GQA, MLA, квантовання кешу, механізми сторінкування та політики видалення — це функції, що підвищують пропускну здатність, але використовують пам’ять як своєрідний „костюм“.

Q37. PagedAttention та проблема фрагментації

Прості сервери виділяють по одному суміжному блоку KV на запит до значення max_seq_len. Це призводить до проблем у двох аспектах:

• Внутрішня фрагментація — завершення тексту довжиною 100 токенів, для якого було виділено 4096 слотів, призводить до марнування більшої частини виділеної пам’яті.
• Зовнішня фрагментація — звільнені ділянки різної величини залишають „дірки“, куди неможливо розмістити нові блоки.

Рівень марнування пам’яті у простих алокаторах зазвичай становить від 60 до 80% від загального обсягу пам’яті KV.

PagedAttention (популяризований vLLM) копіює концепцію віртуальної пам’яті операційної системи: блоки фіксованого розміру (наприклад, 16 токенів) разом із таблицею блоків, яка відображає логічні позиції до фізичних блоків у будь-якій частині пулу. Блоки виділяються у міру збільшення довжини тексту.

Переваги:

• Зменшується фрагментація → часто можливо обробляти 2–4× більше послідовностей одночасно на тих самих GPU.
• Спільне використання префіксів / копіювання під час запису — багато запитів із одним системним запрошенням ділять фізичні блоки, поки їхні суфікси не стануть різними; ідеально підходить для агентів, інструкцій RAG та сценаріїв з кількома прикладами.
• Промені та паралельні зразки ділять спільний префікс замість того, щоб копіювати його.

Ціною є непрямий доступ та ядро уваги, яке збирає дані з неконтигуальних блоків.

Q38. Статичне vs безперервне батчування

Статичне об’єднання чекає, поки не заповниться набір даних, виконує всі послідовності одночасно з найдовшою з них та доповнює їх недостатніми данами. Короткі запити чекають на довгі; GPU витрачає ресурси на обробку цих доповнень.

Неперервне (на рівні ітерацій) об’єднання перебудовує набір даних на кожному кроці декодування: завершені послідовності видаляються, нові додаються, і GPU працює лише над актуальними токенами. Різниця у затримках зменшується, а продуктивність значно підвищується — це стандарт сучасних двигунів (vLLM, TensorRT-LLM тощо).

Q39. Часткове попереднє заповнення та роз’єднання попереднього заповнення та декодування

Попереднє заповнення на кілька тисяч токенів може монополізувати GPU та уповільнювати декодування для інтерактивних користувачів. Часткове попереднє заповнення розділяє довгі запити на частини, які чергуються з кроками декодування, тож час відгуку зростає трохи, але загальна продуктивність залишається високою.

Розбивка на складові йде ще далі: виконання попереднього заповнення на пулах, оптимізованих для обчислень, та декодування на пулах, оптимізованих для пам’яті, з передачею даних типу KV через мережу. Це збільшує складність оркестрації, але прив’язує кожен етап до обладнання, яке насправді використовується.

Q40. Зменшення об’єму даних типу KV поза межами GQA

Серед методів є:

• MQA / GQA / MLA — менша кількість або стиснуті елементи даних типу KV.
• Кеші, квантовані (у стилі INT8/FP8/NF4) — часто майже без втрат для даних K/V.
• Віконна/зсувна увага — видалення далеких токенів, якщо це дозволяє завдання.
• Політики видалення/стрімування для екстремальних ситуацій.
• Багаторівневе повторне використання — ідеї досліджень, які передають проекції між різними рівнями.

Кожен з цих методів жертвує певною частиною якості або універсальності заради значного збільшення об’єму пам’яті.

Q41. Кешування префіксів — коли змінюється архітектура

Якщо багато викликів мають спільний довгий незмінний префікс (системне запитання, схеми інструментів, отриманий контекст), кешування пар ключ/значення цього префікса дозволяє уникнути їх повторного обчислення. Тому архітектури віддають перевагу стабільним префіксам та змінним суфіксам: нестабільний текст користувача розміщують у кінці, а спільну частину зберігають ідентичною за байтами, щоб ключі кешу відповідали їм. Тексти продуктів та компілятори запитань стають частиною факторів, що впливають на продуктивність.

Q42. Коли кеш ключ/значення стає недійсним?

У будь-який момент, коли попередні токени змінюються, а не просто додаються: під час перегенерації під час розмови, переписування системного запитання, заміни визначень інструментів або застосування некаузальних змін. Кеш префіксів має формуватися на основі точної ідентичності токенів (та версії шаблону). Параметри вибору зразків не роблять пар ключ/значення недійсними — вони лише змінюють спосіб перетворення логітів у наступний ідентифікатор — але зміна адаптера моделі, прототипу моделі чи масштабу RoPE під час роботи може це зробити.

Частина 6 — голова LM (лінійна + softmax)

Питання 43. Що робить голова LM та яка її структура

Останній блок генерує h ∈ ℝ^(seq_len × d_model). Після фінальної нормалізації один лінійний перетворювач створює логітти словника:

logits = h @ W_lm      W_lm ∈ ℝ^(d_model × V)

Для d_model = 4096 та V = 128,000 параметри W_lm налічують 524 млн, і це дає вектор шириною 128K для кожної оцінюваної позиції.

Питання 44. Чи є логітти для кожної позиції під час декодування?

Ні. Для навчання або певних API може використовуватися попереднє заповнення для оцінки багатьох позицій, але звичайне декодування потребує лише стану прихованих змінних останньої позиції. Ранніші позиції вже обрали свої токени.

Питання 45. Вартість обробки головою LM під час декодування

Кожен крок множить вектор d на d × V — це призводить до кількості операцій типу FLOPs на рівні 2 × d × V, а також до повного зчитування потенційно нез’єднаної частини даних. При великих значеннях V це конкурує з використанням шматків FFN, що стимулює використання адаптивного softmax, паралельного розділення словникового запасу та з’єднаних ембеддингів, коли це доцільно.

Q46. Логіти проти ймовірностей

Логіти — це необмежені оцінки. Softmax їх нормалізує:

p_i = exp(z_i) / Σⱼ exp(z_j)

Пам’ятайте про інваріантність до зсуву: додавання константи до всіх логітів не змінює ймовірностей — це основа стабільних реалізацій та використання параметра температури для масштабування різниць.

Q47. Числово стабільний softmax

Проста формула exp(z_i) призводить до переповнення у форматі fp16 для помірних значень логітів, а також може спричинити занурення всього рядка у нулі, що створює ситуацію 0/0. Щоб уникнути цього, спочатку віднімається максимум рядка:

p_i = exp(z_i − max(z)) / Σⱼ exp(z_j − max(z))

Найбільший член дорівнює exp(0) = 1; решта знаходяться в діапазоні (0, 1]. Онлайн-алгоритми (як у FlashAttention) поєднують це з операцією matmul, щоб уникнути створення величезних матриц оцінок.

Q48. Перплекситет

Перплекситет — це exp(середнє значення від’ємного лог-ймовірності) для токенів — ступінь „здивування“ моделі. Його обчислюють на тому самому етапі, що й логітів/softmax. Нижчий перплекситет у певній області свідчить про кращу налаштованість моделі щодо наступних токенів, але це не є прямим показником корисності чи безпеки.

Частина 7 — стратегії вибору елементів

Після блоку LM у вас є вектор логітів. Вибір елементів — це процес, за допомогою якого цей вектор перетворюється на наступний ID.

Q49. Жадібне декодування — та чому воно розчаровує

Алгоритм жадібності завжди обирає argmax. Він детермінований та ефективний, проте часто дає одноманітні результати або проявляє локальну в’язкість: ранні токени з високою ймовірністю можуть ув’язнити послідовність у повторюваних циклах високої ймовірності, які людина вважає гіршими за альтернативи з трохи нижчою ймовірністю. Використовуйте його для завдань екстракції з обмеженими можливостями; уникайте його як стандартного рішення для відкритих текстових форматів.

Q50. Чому не використовувати пошук променем?

Пошук променем зберігає найкращі B часткових гіпотез. Він корисний, коли мета коротка та обмежена (наприклад, під час перекладу). Для відкритих діалогів він зазвичай генерує універсальний, безпечний текст високої ймовірності, вимагає обчислень у кількості B× та погано поєднується з методами різноманітності типу nucleus. Більшість додатків на основі LLM відмовилися від нього на користь методу вибірки.

Q51. Top-k

Зберігайте лише k найбільших логітів, ренормалізуйте їх та виберіть зразок. Це просто, але значення k є нечутливим: іноді ймовірності поза діапазоном „топ-к“ все одно мають значення; іноді „топ-к“ включає непотрібні значення, коли розподіл є гострим. Фіксоване значення k не може адаптуватися до ступеня гостроти розподілу.

Q52. Top-p (ядро)

Впорядкуйте дані за ймовірністю, збережіть найменший набір, чия кумулятивна маса дорівнює або перевищує p, а потім виберіть зразок. Коли модель впевнена, ядро зменшується; коли є невпевненість — розширюється. Саме ця здатність до адаптації призвела до того, що top-p замінив фіксований „топ-к“ як стандарт у багатьох системах. Типове значення p становить приблизно 0,9–0,95; його налаштовують відповідно до продукту.

Q53. Температура — математика та інтуїція

p_i = exp(z_i / T) / Σⱼ exp(z_j / T)

Розділіть логіті на T перед виконанням функції softmax.

• T → 0 — розбіжності значень стрімко зростають; розподіл зводиться до значення argmax (грейдійний підхід).
• T = 1 — розподіл моделі без масштабування.

T > 1 — рівнізація; більше несподіванок та ризик неконгруентності.

У реалізації температура сама по собі не «додає випадковості» — вона змінює розподіл, з якого береться вибірка.

Q54. Порядок дій: температура проти обрізання

Спочатку застосовуйте температуру до логітів, а потім використовуйте метод top-k / top-p для отриманого розподілу (або еквівалентно — обрізайте ймовірності після застосування температури). Обрізання перед застосуванням температури змінює те, які «хвости» розподілу залишаться, і зазвичай є неправильним підходом. Описуйте порядок дій, який використовує ваш сервер; тихе замінювання етапів змінює поведінку системи.

Q55. Штрафи за повторення, частоту та наявність

• Повторення / частота — знижується вага токенів, які вже бачились, часто пропорційно їх кількості.
• Наявність — настає штраф для токену, якщо він хоча б один раз з’являвся, незалежно від кількості його появ.

Вони борються з циклічними структурами під час творчого декодування, але можуть нашкодити навмисному повторенню (коду, поезії, юридичних фраз). Краще використовувати м’які покарання та суворі правила зупинки, ніж агресивні обмеження.

Q56. Понад top-p

Min-p — це порогові значення відносно найвищої ймовірності (p_i ≥ min_p × p_max), які працюють краще при високій температурі та розсіяному розподілі даних. Mirostat та схожі контролери націлені на певний рівень несподіванки. У типових сценаріях використання все ще переважають параметри температура + top-p, проте min-p поступово здобуває популярність.

Q57. Чому температура 0 все одно змінюється?

Nавіть „жадібні“ алгоритми відрізняються за такими параметрами:

• Недетерміністичні операції GPU та об’єднані ядра.
• Різні схеми групування даних/постійних пакетів.
• Експериментальні шляхи обробки та числово різні реалізації функції softmax.
• Стандартні покарання, правила зупинки та шаблони з боку сервера.

Шум маршрутизації MoE, якщо він увімкнений.

Метод „жадібного“ розподілу з бітовою стабільністю вимагає заблокованих ядер, розміру пакета 1 та ідентичних версій програмного забезпечення — що рідко трапляється у флотах з кількома користувачами.

Q58. Примусове використання JSON або схеми

Варіанти розв’язку:

1. Примусове використання JSON (нестабільно).
2. Обмежений декодування / маски граматики — щоразу ігнорування недійсних токенів (regex, схема JSON, CFG).
3. Використання інструментів/функцій, які аналізують бокові канали замість вільного тексту через API.
4. Поправка після події (останній варіант).

Обмежений декодування є надійним рішенням для систем, коли обов’язкова є правильність даних.

Q59. Оцінка налаштувань вибірки

Утримуйте модель нерухомою та перевіряйте параметри температури/топ-п на наборі даних із мітками: успішність завдання, токсичність, різноманітність (distinct-n), частота повторень, затримка. Віддавайте перевагу офлайн-оцінці разом із онлайн-тестуванням типу A/B з чіткими метриками продукту. Не налаштовуйте модель на основі одного вибраного запиту.

Частина 8 — Спекулятивне декодування

Q60. Основна ідея

Дешева проєктна модель пропонує кілька майбутніх токенів; цільова модель перевіряє їх під час одного паралельного проходження по діапазону проєктних токенів. Прийнятий префікс стає результатом; при першій відмові береться замінник із розподілу цільової моделі, а решта відкидається. Ви витрачаєте більшу частину потужності цільової моделі на паралельну перевірку замість послідовних кроків із одним токеном.

Q61. Чому розподіл результату залишається незмінним

Процес прийняття використовує співвідношення між цільовим p та проєктним q, щоб прийняті токени разом із залишковим резамплінгом точно відтворювали p:

P(emit x) = q(x)·min(1, p(x)/q(x)) + P(reject)·p'(x)

Прийнятий шлях внескає min(q,p); залишковий резамплінг заповнює max(0, p−q). Сума дає p. Тому спекулятивне декодування є без втрат порівняно зі звичайним цільовим резамплінгом — це прискорення роботи системи, а не наближення до моделі.

Q62. Очікуване прискорення

Зі швидкістю прийняття α та довжиною проєкту k очікувана кількість токенів на один цільовий крок становить:

E[tokens] = (1 − α^(k+1)) / (1 − α)

Навіть якщо кожен токен проєкту не підходить, ви все одно отримуєте один токен під час перевірки цільового варіанту. З урахуванням витрат на проєкт c порівняно з одним цільовим кроком:

speedup ≈ E[tokens] / (1 + k·c)

Приклад: α=0.8, k=4 → приблизно 3,36 токенів; з c=0,05 → приблизно 2,8×. Опубліковані перемоги зазвичай знаходяться в діапазоні 2–3×. Великі значення k призводять до зменшення ефективності, оскільки ймовірність виживання зменшується за законом α^k.

Q63. Коли спекуляції шкодять

Низький рівень прийняття (складні запити, зміна домену, слабкий чернеток), надто висока вартість створення чернетки або ядра, які не можуть ефективно перевіряти інформацію паралельно. У таких випадках додаткові витрати перевищують користь — необхідно контролювати значення α.

Q64. Буфер KV при відхиленні

Зберігання записів буфера (та чернеток) для відхиленних позицій з метою можливого скасування змін. Реалізації використовують механізми контрольних точок та обрізання даних; помилки в цьому процесі пошкоджують подальшу обробку інформації. Прийняті токени зберігають свої значення K/V.

Q65. Сучасні варіанти

Медуза / багатоголові генератори, генератори на рівні ознак у стилі орла, генератори на основі пошуку у promptах чи n-грамів безпосередньо з контексту та каскадні генератори. Той самий принцип перевірки з використанням цільового результату.

Q66. Увага до дерева

Генератори можуть пропонувати дерево кандидатів, а не лише лінійний ланцюг. Механізм уваги до дерева перевіряє кілька гілок під час одного проходу по цілі, що збільшує кількість успішних результатів за один виклик, коли створення гілок є дешевим.

Частина 9 — Детокенізатор та стрімінг

Q67. Детокенізація — це не просто зворотний мапування

Детокенізатори повинні скасовувати маркери пробілів, обробляти альтернативні варіанти байтів, комбінувати багатотокенові графеми та уникати виведення неповного формату UTF-8. Під час стрімінгової детокенізації дані зберігаються у буфері, поки не буде можливо безпечно вивести повний символ чи фрагмент — інакше клієнти бачитимуть замінники символів.

Q68. Як працює стрімінг та що вимірювати

Сервери випромінюють токени (або частини рядків) у момент їх створення. Вимірюйте TTFT, TPOT та час до першого читабельного символу після детокенізації та буферизації. Для користувацького інтерфейсу клієнта ця остання величина має більше значення, ніж сухі часові позначки токенів.

Q69. Послідовності зупинки є складними

Послідовності зупинки можуть охоплювати межі токенів (\n\n проти одного токена, що містить обидва символи нового рядка). Необхідно перевіряти декодований текст (або ретельно обраний вікно токенів), а не лише збіг ідентифікаторів. У разі перекриття з частково сформованими послідовностями зупинки потрібно виконати скасування, щоб текст зупинки не відображався.

Q70. Що завершує процес генерації?

EOS/спеціальні ідентифікатори зупинки, відповідні рядки зупинки, обмеження кількості токенів, скасування з боку клієнта або механізм стеження сервера. Краще використовувати чітке оброблення сигналу EOS, що відповідає шаблону чату.

Частина 10 — FlashAttention, квантація, roofline

Q71. FlashAttention — точні твердження

FlashAttention обчислює увагу без створення повної матриці оцінок розміром n × n у HBM, використовуючи тайлінг та онлайн-статистику softmax. Це зменшує навантаження на пам’ять та дозволяє працювати з довшими послідовностями/більшими пакетами даних. Він не змінює математичного результату обчислення уваги (з урахуванням числових обмежень); це алгоритм, що враховує обмеження вводу-виводу, а не інший модель.

Q72. Чи допомагає він у декодуванні?

При декодуванні з кешем увага часто спрямовується на ключі з кешу розміром n із довжиною q, що дорівнює 1 — тому класична перевага FlashAttention (величезні квадратні оцінки) зменшується. Варіанти (FlashDecoding тощо) все ще допомагають оптимізувати шляхи передачі даних KV, але декодування залишається залежним від навантаження на ваги, якщо пакет даних невеликий.

Q73. Квантування

Зберігайте/обчислюйте ваги (а іноді також активації/KV) у більш компактних форматах (FP8, INT8, INT4, …). Об’єм пам’яті та пропускна здатність зменшуються приблизно пропорційно ширині біта; втрата якості залежить від методу (GPTQ, AWQ, smooth quant, …). За досвідом: 8-бітний формат зазвичай майже безкоштовний; 4-бітний коштує трохи більше, іноді рівень втрати є прийнятним — завжди тестуйте на власних завданнях.

Q74. Опис концепції Roofline у одному абзаці

Побудуйте графік досяжних значень FLOPs у залежності від арифметичної інтенсивності. Попереднє заповнення даних знаходиться ближче до «стелі обчислень»; декодування в блоках по одному елементу знаходиться ближче до «стелі пропускної здатності» приблизно на рівні 1 FLOP/байт. Оптимізації, які підвищують інтенсивність (блокування операцій, менша кількість бітів за один корисний FLOP), переміщують систему ближче до цієї межі; чисте прискорення ядра не може подолати існуючу стелю обмежень.

Q75. Розподіл великої моделі між GPU

Tensor parallel — розділення шарів на частини (вимагає швидкого взаємозв’язку). Pipeline parallel — призначення діапазонів шарів рангам (ризик „бульбашок“). Expert parallel — розділення експертів MoE на частини. Replica / data parallel — копіювання моделі для підвищення пропускної здатності. У реальних реалізаціях їх поєднують; KV-дані мають бути розділені або скопійовані відповідно до структури уваги.

Частина 11 — Числа з дошки

• Ваги 70B у форматі fp16: 70e9 × 2 ≈ 140 GB.
• KFLOPs для обробки даних: ~2 × параметри × токени (у порядку величини).
• KV на токен (Llama-3-70B-class GQA): ~два · шари · kv_heads · head_dim · dtype_bytes — приблизно третина мегабайта на токен.

Розшифрування в пакетах, пакет 1: ~bandwidth / weight_bytes (процесори класу H100: десятки tok/s у форматі fp16 перед іншими рішеннями).

Ембеддинги та окремий блок LM при V=128K, d=4096: по приблизно 524 млн параметрів кожен.

Параметри механізму уваги та FFN: приблизно 1:2 у стандартному блоку (4d² проти ~8d²).

Частина 12 — Обмеження діаграм

У поширених навчальних діаграмах не показано: шаблони чату перед токенізацією, вплив GQA/MQA на ширину KV-матриць, деталі порядку вибору зразків, буферизацію під час детокенізації, структуру KV-матриць з розділенням на сторінки та цикли спекулятивної перевірки. Розглядайте діаграми як карти, а не контракти.

Закінчення

Інференс — це процес перетворення даних у вигляді байтів на потоковий текст, де попереднє заповнення залежить від обчислювальних можливостей, а декодування — від пропускної здатності; кумулятивна кеш-пам’ять типу KV домінує у меморії багатокористувацьких систем, а кожна значуща оптимізація — GQA, пейджування, безперервне групування даних, квантування, FlashAttention, спекулятивні операції — існує для того, щоб перенести обчислення у найбільш ефективні для апаратного забезпечення режими, не змінюючи математичну модель більше, ніж це необхідно.

Детальний аналіз А — Економіка попереднього заповнення та декодування на практиці

При визначенні кількості пристроїв у флоті почніть з розподілу за висотою. Завдання, що передбачають обробку великих об’ємів даних, охоче використовують тензорні ядра: довгі запити у режимі кодової підтримки чи завантаження даних у форматі RAG можуть показати високу ефективність MFU, якщо ядра працюють ефективно. Результати декодування завдань у першій партії нагадують випадкові тестування продуктивності пам’яті — однакові 70B ваги обробляються через HBM за один крок GEMV. Саме тому продукт, який генерує відповіді довжиною 500 токенів, здається повільним навіть на флагманських GPU, якщо не використовувати пакетну обробку, квантування чи інші техніки оптимізації.

Регресії у показниках TTFT зазвичай означають збільшення обсягу запитів (історія, дані RAG, схеми інструментів) без кешування префіксів. Регресії у показниках TPOT зазвичай викликані розпадом пакетної обробки, зниженням пропускної здатності чи необхідністю використання дуже малих пакетів через тиск на структури KV. Затримка в роботі від початку до кінця — це не єдиний параметр, який можна налаштувати: скорочення довжини відповідей допомагає покращити час виконання завдань типу TPOT у N разів; кешування запитів системи допомагає у випадках TTFT; спекулятивне декодування покращує час виконання завдань типу TPOT, коли ймовірність прийнятності висока.

Метрики пропускної здатності, які відображаються на панелях керування, легко підробити за допомогою великих пакетів даних, що завдає проблем користувачам, які взаємодіють з системою. Слід публікувати обидва показники: кількість токенів за секунду на одну GPU та значення p50/p95 TPOT у реалістичному поєднанні. Постійне оброблення даних у пакетах забезпечує постійну роботу GPU без надмірного навантаження від статичних пакетів; розділене попереднє заповнення запобігає тому, щоб один 32K-запит заблокував процес декодування для всіх інших.

Роздільне попереднє заповнення та декодування є архітектурним визнанням того, що ці два типи завдань вимагають різних пристроїв. Вузли попереднього заповнення можуть мати вищу обчислювальну щільність; вузли декодування потребують об’єму пам’яті та пропускної здатності для обробки даних типу KV. Мережа мусить ефективно передавати дані типу KV, інакше ви програєте. Не кожна команда повинна реалізовувати це вже з першого дня — але кожна команда має розуміти, чому існує така структура.

Детальний аналіз B — Токенайзер та багатомовні витрати

Універсальність BPE на рівні байтів є водночас перевагою та проблемою. Додатки для чату англійською мовою недооцінюють витрати на обробку тексту хінді, тайською чи соціальних повідомлень із великою кількістю емодзі. Якщо ваша модель розрахунку припускає кількість токенів англійською мовою на секунду, багатомовне розширення може тихо спалювати бюджет. Обирайте токенізатори з ширшим багатомовним охопленням, коли цей трафік має значення; вимірюйте кількість токенів на кластер графем у реальних корпусах, а не у тексті lorem ipsum.

Шаблони чату є частиною ідентичності моделі. Один лише пропущений спеціальний кінцевий токен може призвести до неправильно сформованих повідомлень чи їх обрізання. Зберігайте версію шаблону поруч із версією моделі у вашому реєстрі. Під час виправлення проблеми „модель ігнорує системний запит“ токенізуйте обидві сторони та порівняйте їхні ID, перш ніж звинувачувати ваги моделі.

Політики щодо цифр мають велике значення для агентів у таблицях та репетиторів з математики. Якщо числа 1000 та 1,000 обробляються по-різному, алгоритми стовпців перетворюються на лотерейні квитки. При створенні калькуляторів на основі ШІ слід використовувати токенізатори з чіткими правилами щодо цифр або передавати арифметичні операції у спеціалізовані інструменти.

Детальний аналіз C — увага, GQA та пам’ять

Історія багатоголової уваги — це спеціалізація в межах обмеженого бюджету. Історія GQA — це кількість байтів KV. Перехід від MHA до GQA може зменшити розмір кешу приблизно у співвідношенні кількості голів запиту до груп KV — часто у 4–8 разів — з незначною втратою якості під час навчання. MQA є крайнім варіантом; MLA та схожі методи компресії намагаються подолати ту саму проблему за допомогою інших алгоритмів.

Маскування причинності з використанням негативного нескінченності — це не педантизм: будь-яке скінченне значення маски призводить до витоку інформації. Баги під час навчання, які випадково дозволяють майбутню увагу, створюють моделі, які здаються ефективними за метриками, встановленими вчителем, але потім зазнають невдач під час справжнього авторегресивного використання. Кернелі часу декодування, які передбачають певну структуру кешу, повинні відповідати геометрії навчання (кількість блоків, основа RoPE, масштабування).

Резидуали та попереднє нормування — причина того, чому стеки з 80–100 шарів є звичайним явищем. Коли спеціальна архітектура видаляє їх „для спрощення“, очікуйте нестабільності під час навчання, а не інтелектуальних переваг. Механізм керування SwiGLU є параметром якості, який впливає на роботу пам’яті — потрібно знати, чи поєднує його ваш стек.

Детальний аналіз D — стратегія сторінкування KV та префіксів

PagedAttention переосмислює KV як набір блоків. Наслідки цього:

• Фреймворки агентів із величезними спільними системними запитами повинні стандартизувати цей префікс, щоб хеші блоків збігалися.

Бібліотеки з обмеженою кількістю прикладів повинні зберігати екземпляри у стабільному порядку; їх перетасування знижує кількість успішних запитів до кешу.

Поля для персоналізації мають йти після спільної основи.

Інструменти для дебаггінгу повинні відображати показники ефективності роботи таблиць блоків так само, як CDN відображають коефіцієнти успішних запитів до кешу.

Анулювання кешу за допомогою префікса є проблемою коректності, а не лише продуктивності. Якщо схема інструменту змінюється, а ключ кешу це ігнорує, модель буде використовувати застарілі дані KV для нових інструкцій — це тонкі, але серйозні проблеми. До ключа слід включати ID токенайзера, хеш шаблону, ID LoRA та масштаб RoPE.

Для усунення даних під тиском пам’яті потрібна політика: алгоритм LRU для неактивних розмов, жорсткі обмеження на обсяг контексту чи стиснення за допомогою узагальнень. Що б ви не обрали, потрібно зробити це видимим для користувача — тихе обрізання даних є проблемою довіри.

Детальний аналіз E — Softmax, вибірка та детермінізм

У режимах fp16/bf16 обов’язкове використання стабільного алгоритму softmax. Об’єднані ядра приховують операцію max-subtract, але власний дослідницький код все одно стикається з проблемою переповнення. Показник перплексності залишається корисним індикатором для перевірки змін під час заміни ядр чи схем квантування: різкі зміни означають зсув розподілу.

Компоненти процесу вибірки мають пройти тестування на одиницю: спочатку температура, потім обрізка даних, потім штрафи та нарешті вибірка. Змініть порядок етапів у тестовому фіксчері, і ви побачите, як змінюються результати. Декодування JSON у обмежених умовах має пройти тестування на навантаження; генерація маски може стати причиною обмежень продуктивності CPU, якщо її реалізувати необачно.

Твердження про те, що температура нуль дорівнює детермінованому результату, є маркетинговою фразою, а не математичною гарантією на справжніх GPU. Якщо вам потрібен запис даних рівня аудиту, зберігайте ідентифікатори, отримані в результаті вибірки (або насіння генератора випадкових чисел разом із зафіксованими ядрами першої партії). Для більшості додатків достатньо відтворюваності всередині однієї версії — задокументуйте це.

Детальний огляд F — Операції спекулятивного декодування

Безвтратна спекуляція є потужною, тому що власники продуктів бояться зниження якості. Проте операційні підрозділи мають відстежувати рівень прийнятності за категоріями запитів. Завершення коду часто приймається успішно; творчі, відкриті діалоги — можливо, ні. Адаптивна довжина чернетки на основі останніх результатів прийнятності краща за статичні припущення.

Спекуляція у вигляді дерева допомагає, коли чернетка може дешево запропонувати альтернативи. Тести на коректність скасування KV-записів мають бути в системі CI: слід навмисно відхиляти їх під час виконання та перевіряти, чи наступні значення уваги відповідають базовому рівню без спекуляцій.

Моделі чернеток повинні ділитися токенайзером (або сумісним мапуванням) з цільовою системою. Несумісні токенайзери створюють „невидимий сміття“, яке виглядає так, ніби спекуляції зробили модель глупішою.

Детальний аналіз G — потоковий UX та зупинки

Користувачі сприймають плавність роботи системи через детокенізовані символи, а не прямі ідентифікатори. Зберігайте дані до тих пір, поки вони не стануть дійсними у форматі Unicode; при можливості використовуйте пробіли для очищення буфера задля кращого користувацького досвіду у чаті. Послідовності зі збігом токенів вимагають обережного скасування дій, щоб клієнт ніколи не бачив відповідного тексту. Якщо продукт дозволяє продовження обробки, максимальні ліміти токенів повинні додавати чіткий сигнал про продовження.

Детальний аналіз H — FlashAttention та квантація під час обробки даних

FlashAttention дозволяє збільшувати обсяг попереднього заповнення та щільність пакетів даних завдяки економії ресурсів HBM. Варто відзначити, що цей інструмент не змінює основних принципів декодування. Квантація є ключовим елементом декодування: менша кількість байтів на один ваговий елемент підвищує кількість оброблюваних токенів за секунду. Перевірте його на своїй наборі тестів — особливо щодо виклику інструментів та відтворення довгих контекстів — перш ніж стверджувати, що 4-бітна квантація є безкоштовною.

Логіка розрахунку кривої даху забезпечує чесність аргументів: якщо у вас обмежений пропускний потік, купівля більшої кількості TFLOPS без збільшення пропускної здатності (або зменшення кількості байтів) призводить до розчарування. Якщо обмеження полягає у потужності обчислень під час попереднього заповнення, краща ефективність операцій GEMM та планування блоків мають більше значення, ніж скорочення обсягу KV.

Детальний аналіз I — Реалії багатокарткових систем

Для паралелізму тензорів потрібні швидкі з’єднання, інакше процес гальмується під час операцій all-reduce. Для паралелізму через конвеєрну структуру потрібні мікропакети, щоб приховати проблеми. Поєднання цих підходів із безперервним формуванням пакетів та використанням структурованих даних KV є причиною великих розмірів кодових баз інженерій інференсу. Коли хтось пропонує просто розділити модель, потрібно запитати, за якими вимірами це робиться та що станеться зі структурою KV.

Детальний аналіз J — Складання конвеєрної структури

Шлях обробки запиту, який варто запам’ятати:

1. Шаблон та токенізація на CPU
2. Вбудовування даних та попереднє заповнення за допомогою каузальної уваги, запис KV (GPU, обмеження потужністю обчислень)

Голова LM на останній позиції, потім вибір зразка (GPU за політикою CPU)

Цикл декодування з кешем, безперервне групування даних, необов’язкове спекулювання (GPU, обмежене пропускною здатністю)

Детокенізація, перевірки завершення, обробка потоку на CPU

Звільнення або використання блоків KV у механізмі розподілу

Кожна оптимізація відповідає одній стрілці в цьому списку. Якщо ви не можете вказати на стрілку, ви ще не аналізуєте процес інференсу — ви просто збираєте інформацію.

Додаткові пояснення у стилі FAQ

Чи підвищує збільшення параметра температури креативність у вимірюваному вигляді? Воно підвищує ентропію розподілу наступних токенів. Те, чи будуть люди вважати результат креативним, залежить від завдання; вимірюйте це за допомогою показників різноманітності та якості, а не лише відчуттів.

Чи може жадібність бути правильною? Так — класифікація як генерація, структуроване вилучення з обмеженим декодуванням та деякі інструменти оцінки. У випадку діалогу з відкритою структурою це зазвичай не так.

Чи можна видалити кеш KV та перерозрахувати дані? Завжди, але з квадратичними витратами. Пристрої на периферії іноді працюють у коротких циклах без кешу; сервери майже ніколи не повинні цього робити.

Чому на діаграмах показано softmax усередині механізму уваги та ще раз біля головної частини моделі? Це різні форми softmax: одна змішує значення всередині шару; інша перетворює логітти словникового запасу на категоричний розподіл для вибору елементів. Це одна родина функцій, але різні завдання.

Що має спочатку запам’ятати новий інженер? Проблеми, пов’язані з попереднім заповненням даних та процесом декодування, формулу кількості байтів KV на токен, поняття TTFT та TPOT, а також те, що батчування жертвує затримкою заради пропускної здатності. Усе інше ґрунтується на цих чотирьох ідеях.

Розширений огляд — ядра попереднього заповнення та механізми TTFT

Якість попереднього заповнення сервісу переважно залежить від швидкості, з якою можна перетворити запит на готовий KV-кеш. Ядра уваги, об’єднані шляхи MLP та спосіб розділення запиту на частини визначають форму кривої TTFT. Якщо запити мають спільну частину, кешування префіксів перетворює повторні витрати на попереднє заповнення на просте пошукання; якщо ж ні, кожна нова сесія оплачує повну вартість.

Розділене попереднє заповнення є інструментом забезпечення справедливості, а також інструментом зменшення затримок. Без нього обробка одного запиту обсягом 40 к токенів може заблокувати декодування для всіх інших запитів на GPU. З ним інтерактивні потоки продовжують працювати, поки довгий завдання виконується поетапно. Це призводить до трохи вищого значення TTFT для самого довгого завдання — що зазвичай є прийнятним.

Розташування префікса — це рішення, яке приймається щодо продукту. Розміщуйте змінний текст користувача після фіксованої основи, щоб ключі кешу залишалися стабільними. Якщо відділ маркетингу щодня переписує системні запити, вважайте це подією, що руйнує кеш, і очікуйте, що TTFT зростатиме, поки нова основа знову не стане активною.

Розширений огляд — Пояснення математики пропускної здатності словами

Уявіть, що ви читаєте всю сукупність ваг з HBM один раз на кожен створений токен при розмірі пакета один. Інтенсивність обчислень знижується до одного корисного операцію множення-сумування на переміщений байт. Апаратне забезпечення, яке ефективно працює при інтенсивних операціях GEMM, виглядає неактивним, оскільки чекає на керувачі пам’яті. Блокування дозволяє повторно використовувати кожне завантаження ваг у багатьох послідовностях; квантація зменшує саме обсяг завантаження; спекулятивна перевірка перетворює кілька послідовних кроків на одну паралельну перевірку. Це різні способи досягти однієї й тієї самої мети.

Коли хтось стверджує, що ядро працює у 2 рази швидше під час декодування, запитайте, під яким „небом“ вони знаходяться. Якщо продуктивність обмежена пропускною здатністю, чиста оптимізація ALU не може забезпечити подвоєння швидкості. Якщо вони також скорочують кількість переміщених байтів, повірте їм після скріншоту з інструменту профілювання.

Розширений огляд — Політики обслуговування та SLO

Необхідно окремо визначати SLO для TTFT та TPOT. Випуск, який покращує пропускну здатність, але при цьому подвоює значення p95 TPOT, є регресією для користувацького інтерфейсу чату, навіть якщо панель керування ємністю це відзначає як позитив. Параметри безперервної групування (максимальна кількість токенів у групі, максимальна довжина черги очікування, пріоритет декодування порівняно з попереднім заповненням блоків) є практичними засобами для досягнення цих SLO.

Контроль прийому даних має бути реалізований разом із обліком KV: відхиляти або ставити у чергу нові сеанси, коли прогнозована кількість пам’яті кешу перевищує встановлений ліміт. Інакше ситуації, спричинені нестачею пам’яті, для клієнтів виглядатимуть як випадкові збої моделі.

Розширений огляд — Чек-лист операцій токенайзера

Перед підвищенням рівня моделі:

1. Збережіть файли токенайзера та текст шаблону чату в тому самому сховищі артефактів, що й ваги моделі.
2. Протестуйте кілька багатомовних рядків та емодзі, щоб переконатися у правильній довжині токенів.
3. Якщо продукт виконує математичні операції, протестуйте рядки з великою кількістю цифр.
4. Переконайтеся, що ID токенів зупинки збігаються з маркерами кінця шаблону.
5. Переконайтеся, що інструменти для обчислення logprob використовують той самий токенайзер, що й процес інференсу.

Якщо ви пропустите будь-який з цих кроків, ви будете вирішувати проблеми з „якістю моделі“, які насправді є наслідком змін у пакуванні.

Розширений огляд — варіанти Attention у часовій шкалі

Ранні ШІ використовували повні MHA та оплачували їх за допомогою кешу. Тиск умов виробництва призвів до появи MQA, а потім GQA як компромісу, який прийняли більшість передових контрольних пунктів. MLA та схожі ідеї з низькоранговими KV продовжують цю саму історію: зберігати багатство запиту, скорочуючи обсяг даних, які зберігаються за кожен попередній токен. Читаючи наукову статтю, перекладайте твердження у формулювання „байти на токен KV“ та „зміна якості за результатами оцінки“ — маркетингова термінологія про „ефективну увагу“ в іншому випадку є беззмістовною.

Розширений огляд — структура Paged KV та поведінка багатокористувацьких систем

Математика фрагментації є дуже складною при послідовних резерваціях. Система пагінації перетворює це на проблему розподілу з фіксованими блоками. Кластери багатокористувацьких систем повинні відстежувати помилки розподілу, скорочувати затримку за рахунок таблиць блоків та контролювати частоту успішних пошуків. Раптове зниження частоти успішних пошуків часто означає зміну формату пробілів у шаблоні або тихе оновлення механізму токенізації.

Функція спільного використання даних з механізмом копіювання під час запису між різними потоками та паралельними зразками є обов’язковою для декодування у стилі пошуку; без неї пам’ять множиться пропорційно ширині потоку без жодної користі.

Розширений огляд — Вибір зразків для продуктів

Стандартні налаштування для відправки, які відповідають завданню:

• Параметри екстракції/інструменту: низька температура, обмежене декодування, алгоритм „жадібного“ вибору чи метод з маленьким ядром.
• Підтримка чату: помірна температура, ядро близько до загального діапазону 0,9, незначне покарання за повторення у разі появи циклів.
• Творче мозковий штурм: вища температура, врахування параметра min-p, більш чіткі попередження для користувача щодо варіацій.

Записуйте туплу з даними вибору зразків разом із кожною відповіддю для заявок на підтримку. Без цього неможливо відповісти на запитання типу „Модель учора сказала X“.

Розширений огляд — Впровадження спекулятивного декодування

Розгорніть його за прапорцем. Вимірюйте рівень прийнятності за допомогою кінцевої точки. Вимкніть його, коли α опуститься нижче точки беззбитковості, розрахованої на основі вашої початкової вартості c та довжини k. Завжди зберігайте частину трафіку типу canary, яка не є спекулятивною — це ваша основна мірилка якості.

Переконайтеся, що шляхи відхилення очищують KV. Додайте тест на хаос, який спричиняє відхилення посеред послідовності під навантаженням.

Розширений огляд — деталі протоколу стрімінгу

Вирішіть, чи формат даних буде передавати токени, розтокенізовані рядки чи обидва варіанти. Клієнти, які будуть ре-токенізувати інакше, не погодяться щодо меж. Віддавайте перевагу розтокенізації на боці сервера з використанням чітких подій “flush”, коли готовий повний кластер графем. Описайте, як видаляються послідовності зупинки, щоб код інтерфейсу не обробляв їх подвійно.

Розширений огляд — тести прийнятності квантизації

Перш ніж увімкнути 4-бітні ваги в продакшені:

• Запустіть стандартний набір тестів eval.
• Запустіть фікстури для виклику інструментів.
• Запустіть тести з довгим контекстом.
• У разі потреби порівняйте результати тестів на відхилення/безпеку.
• Порівняйте показники p95 TPOT та VRAM.

Якщо якість в межах узгодженого епсилону та результати щодо затримки є реальними, випускайте продукт. Якщо ні, залишайтеся на 8-бітному форматі для цієї моделі.

Розширений огляд — відповіді на завдання у прозі

Пам’ять для чекпоїнта з сімдесятьма мільярдами параметрів у форматі fp16 становить приблизно сто сорок гігабайт лише для ваг. Одна операція передачі даних коштує близько двох FLOPs на параметр та на кожен токен. Зростання обсягу KV-даних є лінійним у залежності від кількості активних токенів та кількості голів ключ/значення, які фактично зберігаються. Швидкість декодування в одній партії залежить від пропускної здатності пам’яті, поділеної на кількість байтів, які обробляються на кожному кроці. Таблиці ембеддингів та незалежні голіви LM можуть споживати сотні мільйонів параметрів при великих словниках — це не помилки округлення. Усередині блоку шлях передачі даних часто має приблизно вдвічі більше параметрів проєкції, ніж механізм уваги.

Розширений огляд — Навчання чесності діаграм

Коли ви малюєте схему обробки даних для початківців, позначте пропущені елементи: шаблони, механізми сторінкування, безперервне групування даних, спекуляції та буфери для детокенізації. Інакше інженери реалізують схему, а потім дивуються її роботі в продакшені.

Заключний додаток — Як виглядає завершення роботи для власника інференсу

Ви можете пояснити, без використання слайдів, чому певний інцидент завдав шкоди TTFT порівняно з TPOT. Ви можете оцінити обсяг пам’яті KV для запропонованої мети конкурентності та контексту. Ви можете вказати, який з механізмів — пакетна обробка, квантування, GQA, спекуляція, кеш префіксів — стосується цього симптому. Ви розглядаєте токенізатори та шаблони як залежності з версіями. Це є оперативною грамотністю для інференсу LLM; все інше — це деталі, які можна знайти в інших джерелах.

Опис кейс-стаді — Інтерактивний сервіс на 70B

Припустимо, ви розгортаєте чат-модель на 70B у форматі fp16 на парі GPU з великою кількістю пам’яті. Лише ваги моделі займають близько ста сорока гігабайт, тож ця пара GPU майже повністю заповнюється ще до початку будь-якої розмови. Залишки пам’яті мають покривати потреби KV для всіх активних сеансів, активацій та управління фрагментацією пам’яті.

Ви встановили цілі для продукту: шістнадцять одночасних користувачів, контексти обсягом чотири тисячі токенів, потокові відповіді. Орієнтовні розрахунки показують, що кількість кілобайт на токен становить кілька сотень, отже, шістнадцять помножені на чотири тисячі дає десятки гігабайт — це занадто для залишкової пам’яті. Одразу з’являються варіанти: перейти на контрольну точку GQA, квантувати кеш, знизити рівень одночасності, скоротити обсяг контексту чи додати GPU. Саме такі арифметичні розрахунки визначають різницю між нечітким запитом «нам потрібно більше GPU» та точним планом щодо пропускної здатності.

Ви також помічаєте сплески TTFT на початку кожної години, коли багато клієнтів під’єднуються знову з ідентичними системними запитами. Кешування префіксів допомагає зменшити ці сплески після фіксації основної частини запиту. Нездатність фіксувати основну частину після зміни запиту відображається у панелі метрик як регресія моделі.

Опис кейс-стаді — цикли агента та ключі кешу

Агент надсилає однакову схему інструменту на кожному кроці. Якщо JSON-схема серіалізується з нестабільним порядком ключів, префіксні хеші не спрацьовують, і доводиться повторно заповнювати тисячі токенів на кожен крок. Канонічне кодування JSON стає засобом оптимізації обробки даних. Аналогічно, вставка профілю користувача перед схемою ускладнює спільне використання інструменту між користувачами; вставка після неї зберігає можливість спільного використання інструменту.

Опис випадку використання — Спекулятивне декодування коду та чату

На ендпоїнті для автодоповнення коду невелика модель, навчена на схожих даних, приймає більшість токенів; час виконання операції зменшується приблизно вдвічі. На ендпоїнті для творчості з відкритим форматом прийнятність даних різко падає, і та сама модель марнує ресурси. Використання флагів функцій для кожного маршруту є кращим рішенням, ніж глобальний перемикач спекулятивного режиму.

Опис випадку використання — Баги у послідовностях зупинки

Команда встановлює межу для розділової рамки Markdown. У половині випадків ця рамка складається з одного токена; у іншій половині вона розділена. Користувачі бачать закінчення у вигляді символів backticks. Виправлення перевіряє вікна декодованого тексту та скасовує встановлену межу. Проблемою були межі, що визначалися лише за ID токена.

Опис кейс-стаді — несподіванка квантування

Ваги у форматі 4 біти покращили швидкість обробки токенів приблизно на 40% у сценарії декодування з обмеженою пам’яттю. Оцінки, отримані шляхом виклику інструментів, знизилися на три пункти. Компроміс: використовувати 8 біт для інструментальних шляхів та 4 біти для проєктів довгих блог-статей. Один артефакт моделі, два профілі обслуговування — це стало можливим завдяки маршрутизації через шлюз.

Практичний чек-лист — готовність до запуску

• [ ] Опис процесу обробки даних задокументовано для автозаповнення та декодування
• [ ] Кількість байтів KV на токен виміряна на реальному контрольному пункті
• [ ] Кількість одночасних операцій та обсяг контексту відповідають пам’яті GPU з запасом
• [ ] Увімкнено безперервне групування даних із політикою пріоритету декодування

[ ] Ключі кешу з префіксом включають шаблон, токенайзер, LoRA, масштаб RoPE

[ ] Кортеж вибірки записується за кожною відповіддю

[ ] Обмежений декодування для будь-якого контракту JSON

[ ] Стрімингове детокенізація буферів з неповним UTF-8

[ ] Послідовності зупинки тестуються через межі токенів

[ ] Спекулятивне декодування активується за показниками прийнятності

[ ] Квантація перевіряється за допомогою оцінок для конкретних завдань

[ ] План паралельної обробки тензорів/пайплайнів відповідає реальності взаємозв’язків

Практичний чек-лист — триаж інцидентів

1. Чи не працює TTFT або TPOT?
2. Чи змінилася довжина запиту або склад пакета?
3. Чи меморія KV близька до ліміту?
4. Чи змінилися версії токенайзера/шаблону?
5. Чи змінився статус ядра/флагу квантації?
6. Чи погано працює спекулятивне декодування?
7. Чи обмежений ми пропускною здатністю чи обчислювальними ресурсами?

Обробляйте список у порядку; більшість сторінок типу „модель сьогодні не працює“ вирішуються на четвертому кроці.

Глосарій у одному місці

TTFT — час до видачі першого токена після початку запиту. TPOT / ITL — середній час між наступними токенами. Prefill — паралельна обробка запиту для заповнення структури KV. Decode — авторегресивні кроки, які генерують нові токени. KV cache — збережені ключі/значення попередніх токенів. GQA — групована увага до запитів, що зменшує кількість елементів KV. PagedAttention — розподіл структури KV за блоками. Nucleus (top-p) — адаптивне обрізання частини імовірностей з хвоста. Speculative decoding — прискорення шляхом створення чернетки та її перевірки. Roofline — модель, яка пов’язує інтенсивність обчислень з максимальною кількістю операцій FLOPs та пропускною здатністю.

Останній абзац з узагальненням

Розглядайте процес висновків як виробничу лінію. Токенізатори визначають контейнери для компонентів. Ембеддинги та блоки є машинами. Кеш KV — це інвентар у процесі обробки, який займає простір на складі за кожним відкритим замовленням. Вибірка даних — це контроль якості кожної одиниці. Стрімінг — це причал для відвантаження. Спекулятивне декодування — це паралельна лінія перевірки. Якщо оптимізувати певну станцію, не стежачи за запасами та пропускною здатністю, виникнуть купи незавершеної роботи та розлючені клієнти — навіть якщо кожна станція „виглядає швидшою“ окремо.

Додаток — Порівняння ментальних моделей, про які ви почуєте під час інтерв’ю

Інтерв’юери часто просять вас узгодити три гасла: «трансформери працюють паралельно», «декодування є послідовним» та «увага має квадратичний характер». Усі вони є правдивими, але у різних контекстах. Навчання та попереднє заповнення використовують паралелізм між вже наявними позиціями. Декодування не може заздалегідь створити майбутні токени без спекуляцій. Квадратичний член у формулі уваги має найбільше значення, коли довжина послідовності велика порівняно з операціями множення, зумовленими шириною. Хороша відповідь вказує на контекст перед наведенням гасла.

Ще одна поширена пастка — ототожнення кількості параметрів із швидкістю декодування. Параметри впливають на кількість байтів, які переміщуються на кожному кроці; розташування (GQA), тип даних та групування визначають, як ці байти перетворюються на токени за секунду. Два моделі об’ємом 70 мільярдів можуть відрізнятися у часі виконання операцій у 2 рази після врахування цих факторів.

Третя підступність полягає у тому, що люди сприймають відбір зразків як „просто RNG“. Температура, обрізання даних, штрафи та обмеження кожен з них змінюють категоричний розподіл; RNG лише обирає з того, що залишилося. Для виявлення дивних результатів спочатку потрібно задокументувати цю кортежну структуру.

Додаток — Мінімальні рівняння, які варто запам’ятати

KV bytes ≈ 2 × layers × kv_heads × head_dim × bytes × seq_len × batch. Інтенсивність декодування для batch-1 ≈ 2 × params / weight_bytes ≈ O(1) FLOP/byte для щільних даних у форматі fp16. Очікувана кількість спекулятивних токенів на перевірку ≈ (1 − α^(k+1)) / (1 − α). Стабільність функції Softmax: відніміть максимум перед обчисленням exp. Каузальна маска: записуйте −∞, а не нуль, у заборонені оцінки.

Якщо ви можете перевивести ці формули на дошці та пояснити кожен символ, ви вже перевершуєте більшість нечітких пояснень.

Додаток — Куди рухатися далі для глибшого вивчення

Після цього огляду потокової обробки природними наступними кроками є: читання шляху до алокатора у стилі PagedAttention у запущеному двигуні, профілювання одного кроку попереднього заповнення та одного кроку декодування за допомогою інструментів виробника, а також реалізація невеликого циклу декодування з використанням явного кешу KV у NumPy чи PyTorch для ознайомлення зі структурами даних. Ці вправи перетворюють описану вище лексику на м’язову пам’ять без необхідності використання повного набору інструментів для навчання.

Коли у заявці на підтримку йдеться про те, що «ШТИРЬ повільний», потрібно це проаналізувати. Якщо індикатор завантаження з’являється перед будь-яким текстом, потрібно перевірити фактори TTFT: довжину запиту, «холодні» префікси, перевантаження під час попереднього заповнення чи відсутність кешу. Якщо текст з’являється швидко, але потім обробка сповільнюється, потрібно перевірити фактори TPOT: збільшення розміру пакетів, необхідність використання дуже малих пакетів через обмежений кеш KV, неквантовані ваги на картці з обмеженою пропускною здатністю чи вимкнення спекуляцій на маршруті, який раніше давав хороші результати.

Коли у заявці сказано «відповіді погіршилися після вівторка», порівняйте туплі вибірки, хеші шаблонів та флаги квантування перед тим, як перенавчати щось. Регресії у роботі моделей постійно маскуються під регресії інтелекту.

Якщо у заявці зазначено «модель сама створює JSON», припиніть налаштовувати параметр температури та використовуйте обмежений режим декодування. Вибірка не може забезпечити дотримання граматики; маскування — може.

Зустрічі з плануванням потужностей проходять краще, коли хтось пише три числа на дошці: кількість байтів на токен KV, цільова одночасність та цільовий контекст. Помножте їх, додайте вагу, порівняйте з пам’яттю GPU. Суперечки про «чари ШІ» закінчуються; починається математика закупівель.

Ось у чому сенс усього цього огляду процесів: замінити таємниці на показники, а показники — на ручки керування, які вам дозволено використовувати.

Заключні зауваження щодо обсягу роботи

Цей перепис залишається в межах процесу інференсу: те, що відбувається після створення ваг, коли клієнт надсилає текст, та до того, як команда з операцій починає обговорювати процес файн-тюнінгу. Питання, пов’язані з процесом навчання — змішування даних, оптимізатори, графіки паралельного навчання — мають величезне значення, але це вже інший напрямок. Якщо ви можете під тиском запам’ятати розподіл даних між попереднім заповненням та декодуванням, «податок» KV та склад вибірки, у вас вже є основа, до якої можуть приєднатися інші аспекти.

Вправа для читача

Візьміть одну запит на обробку з ваших журналів. Запишіть кількість токенів у вхідному повідомленні, кількість токенів у вихідному результаті, а також значення TTFT/TPOT, якщо вони є. Оцініть обсяг пам’яті KV за формулою, що враховує кількість токенів, для шарів та структури голови вашої моделі. Визначте, чи був запит більше спрямований на обчислювальну частину процесу попереднього заповнення даних чи на розшифрування, обмежене пропускною здатністю. Вкажіть один фактор — кеш префіксів, розмір пакета даних, квантацію, GQA чи спекулятивні операції — який міг би вплинути на показник, який для вас найважливіший. Якщо ви зможете виконати це завдання, не переглядаючи знову цю статтю, значить редагування виконало свою функцію.

Тримайте короткий особистий посібник: різниця між попереднім заповненням та декодуванням, формула для байтів KV, відмінності між TTFT та TPOT, а також порядок вибору зразків. Переглядайте його перед аналізом пропускної здатності та перед тим, як звинувачувати модель у появі помилок. Такі невеликі звички сприяють формуванню надійної інтуїції.