Усередині крихітного трансформера: як влаштована модель, що поміщається в ноутбук
У спільноті AI-інженерів дедалі більше уваги отримують не лише гігантські хмарні моделі, а й маленькі, зрозумілі системи, які можна тренувати локально. На одному з таких практичних воркшопів дослідник ElevenLabs Ангелос Періволаропулос, який очолює команду speech‑to‑text і стоїть за транскрипційною моделлю Scribe v2, демонструє, як побудувати й навчити з нуля невеликий GPT‑2‑подібний LLM на звичайному ноутбуці.
Цей матеріал розбирає внутрішню будову цієї «іграшкової» моделі: від радикально простого токенайзера до архітектури трансформера та навчальної цілі next‑token prediction. Попри скромні розміри, це практично повноцінний GPT‑2 у мініатюрі — і дуже наочний приклад того, як реально працюють сучасні мовні моделі.
Чому тут символи, а не слова: радикально простий токенайзер
Перший принциповий вибір у будь-якій трансформерній моделі — токенайзер. Саме він визначає, на які «цеглинки» розбивається текст перед тим, як потрапити в нейромережу. У великих промислових LLM зазвичай використовують складні субсловні токенайзери з десятками чи сотнями тисяч токенів. У цьому воркшопі підхід протилежний: використовується чисто символьний токенайзер.
Модель працює на рівні окремих символів, а не слів чи морфем. У корпусі (тексти Шекспіра, що входять до репозиторію) виявляється лише 65 різних символів — літери, пробіли, пунктуація та службові знаки. Відповідно, словник токенайзера — це рівно 65 токенів.
Технічно токенайзер — це просте відображення «символ → ціле число». У Python це реалізується через побудову словника з допомогою enumerate: кожному унікальному символу присвоюється індекс. Далі рядок перетворюється на послідовність індексів, а вже ці індекси в моделі замінюються на вектори через embedding‑шар.
Такий мінімалістичний дизайн має дві ключові переваги для локального навчання:
По-перше, він різко скорочує комбінаторний вибух можливих пар токенів. Для 65 токенів кількість біграм (усіх можливих пар «поточний токен → наступний токен») дорівнює 65 × 65, тобто 4 225. Для невеликого датасету це критично: модель має шанс багаторазово побачити майже всі можливі біграми й навчитися їх статистиці.
По-друге, він радикально зменшує розмір embedding‑таблиці й загальну кількість параметрів, що безпосередньо впливає на те, чи можна взагалі тренувати модель на ноутбуці.
Чому не «нормальний» токенайзер: математика, яка вбиває локальне навчання
На перший погляд, використання символьного токенайзера виглядає кроком назад порівняно з сучасними LLM, які працюють із субсловними одиницями й мають словники на сотні тисяч токенів. Але для навчання «з нуля» на маленькому корпусі це не просто компроміс, а єдиний практичний варіант.
Ключова причина — кількість можливих пар токенів, які модель має побачити, щоб адекватно вивчити статистику мови. Якщо словник містить приблизно 200 000 токенів, то кількість можливих біграм — це 200 000 у квадраті. Це вже десятки мільярдів різних пар. Щоб модель «з нуля» навчилася розуміти такі переходи, їй потрібен корпус відповідного масштабу — порядку 200 000² токен‑пар. Для невеликого шекспірівського датасету це абсолютно нереалістично.
У символьному варіанті ситуація протилежна. 65 токенів дають 4 225 біграм — величину, яку невеликий корпус може покрити не лише один раз, а багаторазово. Це означає, що модель має шанс побачити практично всі можливі переходи «символ → наступний символ» у різних контекстах, а отже, навчитися їх передбачати.
Саме тому в рамках воркшопу підкреслюється: спроба використати «повноцінний» сучасний токенайзер із великим словником на такому маленькому датасеті просто не зійдеться. Навіть якщо запускати навчання годинами, модель не зможе вивчити достатньо статистики, щоб давати осмислені результати. Вона банально не побачить потрібну кількість прикладів для більшості можливих пар токенів.
Це демонструє фундаментальний компроміс у дизайні LLM: чим багатший словник, тим більше даних і обчислень потрібно, щоб модель навчилася ним користуватися. На локальному ноутбуці з обмеженим корпусом доводиться радикально спрощувати токенізацію, щоб зберегти навчання в зоні досяжного.
Вартість словника: як 65 токенів перетворюються на 25 тисяч параметрів
Словник токенайзера безпосередньо впливає на розмір embedding‑шару — першого великого масиву параметрів у будь-якій трансформерній моделі. У воркшопі embedding‑вимірність обрана рівною 384. Це означає, що кожен із 65 токенів представляється вектором із 384 чисел.
Embedding‑таблиця в цьому випадку має розмір 65 × 384. Це приблизно 25 тисяч параметрів. Для сучасних LLM це мізер, але для маленької моделі, яку потрібно тренувати на ноутбуці, це вже відчутна, але цілком підйомна частина загального бюджету параметрів.
Для порівняння, якщо взяти типовий словник GPT‑2 на 50 000 токенів і залишити ту саму embedding‑вимірність 384, embedding‑таблиця матиме вже 50 000 × 384 ≈ 19 мільйонів параметрів. Це на кілька порядків більше, ніж 25 тисяч. І це лише один шар моделі.
Різниця тут не лише в пам’яті. Кожен крок навчання повинен оновлювати ці параметри через зворотне поширення помилки. 19 мільйонів параметрів у одному шарі означають суттєво більші витрати на обчислення, більший час епохи, більші вимоги до GPU/CPU та оперативної пам’яті. Для ноутбука з 16 ГБ ОЗП це вже зона ризику, а для безкоштовного GPU в Google Colab — дуже жорстке обмеження.
Символьний словник із 65 токенів, навпаки, дозволяє тримати embedding‑шар у межах десятків тисяч параметрів, що робить модель придатною для локального навчання. Це ще один приклад того, як архітектурні рішення на рівні токенайзера визначають не лише якість моделі, а й сам факт її технічної здійсненності.
GPT‑2 у мініатюрі: шість шарів, кілька голів і класичні блоки
Архітектурно модель у воркшопі базується на GPT‑2 — класичному decoder‑only трансформері з каузальною самоувагою. Хоча GPT‑2 вже вважається «старою» архітектурою, її фундаментальні елементи залишаються стандартом для багатьох сучасних LLM. У цьому прикладі вони просто масштабовані вниз.
У моделі використовується стек із шести трансформерних шарів. Кожен шар містить модуль самоуваги (self‑attention) і MLP‑блок, а також окремі шари нормалізації (layer normalization). Між компонентами проходять резидуальні з’єднання, які додають вихід підблоку до його вхідного сигналу, полегшуючи навчання глибокої мережі.
Ключовий елемент — багатоголова самоувага. У кожному шарі кілька attention‑голів працюють паралельно, кожна з яких може спеціалізуватися на різних аспектах структури тексту. Навіть у невеликій моделі це дозволяє окремим головам «відловлювати» різні патерни: одна може краще реагувати на пунктуацію, інша — на граматичні конструкції, ще одна — на структуру діалогів.
Це важливо навіть у символьному налаштуванні. Хоча модель бачить лише окремі символи, а не слова, голови самоуваги можуть навчитися відстежувати послідовності символів, які відповідають словам, фразам чи синтаксичним шаблонам. Саме багатоголова увага дає моделі можливість одночасно дивитися на різні «ракурси» контексту.
Повна архітектура включає:
- токен‑ембеддинги, які перетворюють індекси символів на вектори розмірності 384;
- позиційні ембеддинги, які додають інформацію про позицію токена в послідовності;
- стек із шести трансформерних блоків, кожен із власним self‑attention, MLP і layer norm;
- резидуальні з’єднання навколо основних підблоків;
- LM‑head — фінальний лінійний шар, який перетворює приховані стани назад у логіти над словником із 65 токенів.
Це класичний GPT‑2‑подібний дизайн, реалізований без високорівневих бібліотек трансформерів — безпосередньо в PyTorch. Такий підхід дозволяє побачити всі деталі: як дані проходять через шари, де застосовується нормалізація, як організовані резидуальні гілки.
Контекстне вікно 256 токенів: скільки пам’яті потрібно маленькій моделі
Ще один важливий гіперпараметр — розмір контекстного вікна, або block size. У цій моделі він дорівнює 256 токенів. Це означає, що під час навчання й інференсу модель одночасно бачить до 256 попередніх символів, коли прогнозує наступний.
Для символьної моделі 256 символів — це приблизно кілька рядків тексту, залежно від структури. Цього достатньо, щоб охопити короткі репліки, фрази та локальні контексти, але, звісно, замало для довгих сюжетних дуг чи глобальної структури документа. Проте для демонстраційної моделі, яка тренується на ноутбуці, це розумний компроміс між виразністю й обчислювальною вартістю.
Саме контекстне вікно визначає розмір матриць уваги: self‑attention у кожному шарі має працювати з матрицями розміром 256 × 256 для кожної голови. Зі збільшенням block size ці матриці ростуть квадратично, що швидко робить модель важкою для локального навчання. Обмеження на 256 токенів дозволяє зберегти обчислення в межах можливостей ноутбука чи безкоштовного GPU.
У сучасних великих LLM контекстні вікна сягають десятків і навіть сотень тисяч токенів, але це досягається за рахунок складних оптимізацій і спеціалізованих архітектурних трюків. У цьому воркшопі мета інша: показати «чистий» GPT‑2‑подібний трансформер без додаткових ускладнень, тому 256 — природний вибір для наочності й керованої складності.
Як модель вчиться: next‑token prediction і крос‑ентропія
Навчальна ціль моделі — класична для мовних моделей: передбачення наступного токена (next‑token prediction). На вхід подається послідовність із до 256 токенів, а модель має для кожної позиції передбачити, який токен іде наступним.
Форвард‑прохід працює так: послідовність індексів символів перетворюється на ембеддинги, до них додаються позиційні ембеддинги, далі дані проходять через стек із шести трансформерних блоків. На виході LM‑head генерує логіти — необмежені значення, які відповідають «сирим» оцінкам ймовірностей для кожного з 65 токенів у словнику.
Ці логіти подаються в крос‑ентропійний лосс разом із правильними наступними токенами. Крос‑ентропія вимірює, наскільки розподіл ймовірностей моделі відрізняється від «ідеального» розподілу, де вся маса ймовірності зосереджена на правильному токені. Чим ближче модель до правильного передбачення, тим менший лосс.
Кожен трансформерний блок у цьому процесі має власний модуль self‑attention, власний MLP і окремі layer norm. Саме така модульність дозволяє кожному шару поступово уточнювати представлення послідовності: увага вчиться відстежувати залежності між токенами, MLP‑частина — нелінійно трансформувати ці представлення, а нормалізація стабілізує навчання.
Важливо, що модель тренується саме як каузальний мовний модель (causal LM): при передбаченні токена на позиції t вона бачить лише токени з позицій ≤ t, а не майбутні. Це реалізується через маскування в self‑attention, яке забороняє головам уваги дивитися «вперед». Такий підхід відповідає реальній задачі генерації тексту, де майбутні слова невідомі.
Обмеження символьного підходу: чому це не шлях до SOTA‑LLM
Символьний токенайзер і маленький GPT‑2‑подібний стек — чудовий навчальний інструмент, але він має очевидні обмеження, якщо говорити про реальні промислові LLM.
Головна проблема символьного рівня — погана масштабованість семантики. Модель має вчитися не лише тому, що «sky is blue» — послідовність слів, яка часто зустрічається разом, а й тому, що «s», «k», «y», пробіл, «i», «s», пробіл, «b», «l», «u», «e» утворюють цю фразу. З погляду самоуваги, це означає, що корисні залежності розмазуються по довгих ланцюжках символів, а не концентруються на кількох токенах, як у субсловних моделях.
У невеликій демонстраційній моделі це ще працює: корпус обмежений, завдання прості, а очікування від якості — помірні. Але якщо спробувати масштабувати такий підхід до великих датасетів і складних задач, вартість навчання різко зросте, а якість усе одно залишиться нижчою, ніж у моделей із розумно спроєктованими субсловними токенайзерами.
Крім того, символьні моделі неефективні на інференсі: для генерації того самого тексту вони повинні робити більше кроків, оскільки кожен крок відповідає одному символу, а не слову чи його частині. Це збільшує час відповіді й вартість обчислень.
Саме тому в реальних продуктах, на кшталт Scribe v2 від ElevenLabs чи сучасних чат‑моделей, використовуються значно складніші токенайзери й масштабніші архітектури. Але для освітнього воркшопу, де головна мета — зрозуміти принципи, а не побити бенчмарки, символьний GPT‑2‑подібний трансформер виявляється ідеальним компромісом.
Висновок: маленька модель як прозоре вікно в архітектуру LLM
Крихітний GPT‑2‑подібний трансформер із символьним токенайзером, контекстним вікном у 256 токенів і шістьма шарами — це не спроба створити чергову «революційну» модель. Це радше прозоре вікно в те, як насправді влаштовані сучасні LLM.
Через радикально простий токенайзер із 65 символів стає видно, як словник визначає і кількість можливих біграм, і вимоги до даних. Через embedding‑таблицю на 25 тисяч параметрів — як словник масштабу GPT‑2 миттєво перетворює цей шар на 19‑мільйонного монстра. Через шість стекових трансформерних блоків — як багатоголова увага, MLP, layer norm і резидуальні з’єднання складаються в єдину архітектуру.
Нарешті, через просту навчальну ціль next‑token prediction із крос‑ентропійним лоссом стає зрозуміло, що в основі навіть найскладніших моделей лежить та сама базова задача: передбачити наступний токен у послідовності.
У світі, де більшість користувачів взаємодіє з LLM лише через API, такі «іграшкові» моделі відіграють важливу роль. Вони повертають прозорість у галузь, де все частіше домінують закриті чорні скриньки, і показують, що значну частину шляху до робочої мовної моделі можна пройти на звичайному ноутбуці — якщо правильно обрати архітектуру, токенайзер і навчальну ціль.
Джерело
Training an LLM from Scratch, Locally — Angelos Perivolaropoulos, ElevenLabs