У світі, де великі мовні моделі асоціюються з дата-центрами, тисячами GPU та мільйонними бюджетами, ідея натренувати LLM з нуля на звичайному ноутбуці звучить майже як жарт. Проте досвідчений інженер ElevenLabs Ангелос Періволаропулос, який очолює команду speech‑to‑text і стоїть за моделлю транскрипції Scribe v2, демонструє протилежне: невелику GPT‑2‑подібну модель цілком реально зібрати й навчити локально, без попередньо натренованих ваг і без важкої хмарної інфраструктури.
Цей матеріал розбирає практичну сторону такого експерименту: які обмеження накладає локальне залізо, як це впливає на вибір архітектури, токенайзера й датасету, чому модель реалізована «голими руками» в PyTorch, а не через високорівневі бібліотеки, і чому спроба відтворити «повноцінний» сучасний стек на маленькому датасеті приречена не зійтися.
Локальний LLM як інженерний експеримент, а не хмарний проєкт
Ключова ідея воркшопу Ангелоса — показати, що «LLM з нуля» не обов’язково означає гігантську інфраструктуру. Йдеться не про конкурент GPT‑4, а про невелику, але повністю прозору GPT‑2‑стиль модель, яку можна:
- натренувати з нуля, без жодних попередніх ваг;
- запустити на ноутбуці з приблизно 16 ГБ оперативної пам’яті;
- або перенести в Google Colab і використати безкоштовний GPU.
Це принципово інший підхід, ніж типовий шлях інженера сьогодні: взяти готову модель із Hugging Face, підключити transformers і зосередитися на fine‑tuning. Тут навпаки — все будується з фундаменту.
Модель реалізована без високорівневих трансформерних фреймворків. Ніяких «чарівних» абстракцій на кшталт AutoModelForCausalLM: лише «чистий» PyTorch і базові бібліотеки. Така постановка задачі змушує розібратися, як саме влаштований GPT‑2‑подібний декодер‑only трансформер, як працює токенізація, як формується навчальна вибірка і як організований тренувальний цикл.
Код воркшопу доступний у публічному GitHub‑репозиторії, посилання на який учасники отримують через QR‑код. Це не демонстраційний фрагмент, а повний робочий проєкт, який можна запустити локально або в Colab, змінювати конфігурацію й експериментувати з гіперпараметрами.
Чому «маленький GPT‑2» і чому саме так: обмеження заліза диктують дизайн
Щойно метою стає навчання моделі на ноутбуці, архітектура перестає бути абстрактною теорією й перетворюється на набір компромісів. У цьому воркшопі використовується GPT‑2‑подібний декодер‑only трансформер, але в сильно зменшеній конфігурації, адаптованій під локальні ресурси.
Модель має:
- контекстне вікно (block size) 256 токенів;
- шість шарів трансформера;
- кілька голів уваги в кожному шарі;
- розмір ембеддингу 384.
Ці цифри не випадкові. Вони визначають як обчислювальну вартість, так і кількість параметрів. Уже на рівні ембеддингів видно, наскільки критичним є масштаб:
- при словнику 65 токенів і розмірі ембеддингу 384 ембеддинг‑таблиця має близько 25 тисяч параметрів;
- якби взяти типовий GPT‑2‑словник у 50 тисяч токенів із тим самим розміром ембеддингу, кількість параметрів ембеддингів зросла б до приблизно 19 мільйонів.
І це лише один шар параметрів. Для ноутбука з 16 ГБ ОЗП та невеликого датасету така різниця принципова. Маленький словник і помірний розмір ембеддингу дозволяють утримати модель у межах, де вона:
- поміщається в пам’ять;
- навчається за прийнятний час;
- не вимагає агресивних оптимізацій чи спеціалізованого заліза.
Шість шарів і кілька голів уваги — це теж компроміс між виразною здатністю й обчислювальною вартістю. Кожна голова уваги вчиться «дивитися» на різні аспекти послідовності: одна може краще відслідковувати пунктуацію, інша — граматичні залежності, ще одна — структуру діалогів. Навіть у маленькій моделі цей розподіл ролей між головами зберігається, але кількість шарів і голів обмежена так, щоб модель не «задушила» ноутбук.
Контекстне вікно 256 токенів — ще один важливий параметр. Воно визначає, скільки попереднього тексту модель враховує при передбаченні наступного символу. Збільшення вікна різко підвищує обчислювальну складність через квадратичну природу self‑attention. Для локального навчання 256 — це баланс між можливістю вловлювати середньострокові залежності в тексті й збереженням прийнятної швидкості.
У сукупності ці рішення формують «профіль» моделі, яка не претендує на універсальність, але є достатньо складною, щоб продемонструвати всі ключові механізми GPT‑2‑подібних систем і при цьому залишатися тренованою на побутовому залізі.
Shakespeare як датасет і чому великий токенайзер тут приречений
Ще один фундаментальний вибір — навчальний датасет. У воркшопі використовується корпус текстів Шекспіра, який входить до репозиторію. Це класичний набір для демонстраційних мовних моделей: компактний, стилістично однорідний, з багатою, але не надмірно різноманітною лексикою.
Однак головна причина вибору не в літературній цінності, а в масштабі. Локальне навчання означає жорстке обмеження на кількість токенів, які модель побачить під час тренування. І саме тут вступає в гру токенайзер.
У воркшопі використовується символьний токенайзер із вокабуляром усього 65 символів. Це всі різні символи, які зустрічаються в шекспірівському корпусі. Такий підхід різко зменшує розмір словника і, відповідно, кількість можливих пар токенів — біграм.
Для 65 токенів кількість біграм дорівнює 65 × 65, тобто 4 225 можливих пар. На невеликому корпусі на кшталт Шекспіра модель має реальний шанс побачити більшість із них багаторазово. Це критично для навчання трансформера, який фактично вчиться моделювати розподіл наступного токена за попереднім контекстом. Чим більше різноманітних пар «поточний токен — наступний токен» модель бачить, тим краще вона оцінює ймовірності.
Якщо ж замінити цей компактний символьний словник на типовий сучасний токенайзер із приблизно 200 тисячами токенів, ситуація кардинально змінюється. Кількість можливих пар токенів зростає до порядку 200 000 у квадраті. Це астрономічне число, яке вимагає відповідного масштабу даних. Щоб модель, навчена з нуля, адекватно оцінювала ймовірності для такого словника, їй потрібно побачити величезну кількість прикладів кожної пари або принаймні значної їх частини.
На маленькому локальному датасеті це нереально. Модель просто не отримає достатньо спостережень, щоб навчитися коректно працювати з таким розрідженим простором токенів. Результат — тренування, яке «не сходиться»: втрата не падає до прийнятних значень, генерація залишається хаотичною, а якість тексту — низькою, незалежно від тривалості навчання.
Саме тому воркшоп наголошує: спроба використати «повноцінний» сучасний токенайзер на кшталт 200‑тисячного словника в такій постановці приречена. Обмежений обсяг даних і локальні обчислювальні ресурси диктують малий масштаб токенайзера й моделі.
Символьний токенайзер: мінімум токенів, максимум контрольованості
Символьний токенайзер, який використовується у воркшопі, реалізований максимально просто. Він працює з рядками, перетворюючи кожен символ на ціле число — індекс у словнику з 65 символів. Далі ці індекси подаються в ембеддинг‑шар, який перетворює їх на вектори фіксованої розмірності (384 у цьому випадку).
Така схема має кілька важливих наслідків.
По‑перше, вона радикально спрощує токенізацію. Не потрібно будувати складні алгоритми на кшталт BPE чи WordPiece, не потрібно думати про багатомовність або рідкісні слова. Усе, що з’являється в тексті, — це послідовність символів із фіксованого набору.
По‑друге, вона зменшує розмір словника до мінімуму, що напряму знижує кількість параметрів у ембеддингах і робить задачу навчання значно більш керованою. Як уже згадувалося, 65 токенів × 384 виміри — це близько 25 тисяч параметрів. Для порівняння, перехід до 50 тисяч токенів за того ж розміру ембеддингу дає приблизно 19 мільйонів параметрів лише в одному шарі.
По‑третє, символьний підхід забезпечує щільне покриття простору біграм. При 4 225 можливих парах і компактному корпусі модель має шанс побачити кожну пару багато разів. Це створює умови для адекватного навчання навіть при відносно невеликій кількості епох.
Однак у символьного токенайзера є й суттєві обмеження. Він погано масштабується до реальних промислових задач. Модель змушена вчитися відстежувати залежності на рівні окремих символів, а не слів чи підслів. Наприклад, замість того, щоб бачити послідовність «sky», «is», «blue» як три осмислені токени, вона бачить «s», «k», «y», пробіл, «i», «s», пробіл, «b», «l», «u», «e». Кореляції між такими послідовностями вловлювати складніше, а навчання стає менш ефективним.
Для демонстраційної моделі на Шекспірі це прийнятний компроміс. Але для великої багатомовної системи з довгими контекстами та складною семантикою символьний токенайзер швидко стає вузьким місцем: модель витрачає значну частину потужності на реконструкцію базових мовних одиниць, замість того щоб оперувати ними напряму.
Саме тому в промислових LLM використовуються складніші токенайзери з великими словниками. Але в умовах локального навчання з нуля та обмеженого датасету символьний підхід виявляється практично єдиним життєздатним варіантом.
PyTorch без «магії»: навіщо відмовлятися від високорівневих бібліотек
Ще одна принципова риса воркшопу — свідоме ігнорування високорівневих трансформерних бібліотек. Модель реалізована без transformers, без готових класів для GPT‑2, без автоматичних конструкторів архітектур. Усе будується на базі «чистого» PyTorch.
Це має кілька важливих наслідків для розуміння й практики.
По‑перше, зникає «чорна скринька». Коли інженер викликає AutoModelForCausalLM.from_pretrained(...), значна частина складності прихована за API. У цьому підході доводиться явно описувати ембеддинг‑шари, блоки self‑attention, MLP‑частини, layer norm, резидуальні з’єднання й тренувальний цикл. Це змушує розібратися, як саме дані проходять крізь модель, де виникають основні обчислювальні витрати й як змінюються розміри тензорів на кожному кроці.
По‑друге, такий підхід ближчий до того, як працюють дослідницькі команди в великих лабораторіях. Високорівневі бібліотеки зручні для швидких експериментів і продакшн‑інтеграцій, але нові архітектури, оптимізації й нестандартні модифікації часто вимагають роботи на рівні «сирого» фреймворку. Воркшоп фактично моделює цей режим роботи, але в зменшеному масштабі.
По‑третє, відсутність «магії» робить обмеження моделі більш очевидними. Коли інженер сам задає розмір ембеддингу, кількість шарів, голів уваги й контекстне вікно, стає зрозуміло, як кожен із цих параметрів впливає на пам’ять, швидкість і якість. Це особливо корисно в умовах локального навчання, де будь‑яке збільшення масштабу відразу відчувається на часі епох і стабільності тренування.
Нарешті, такий підхід полегшує перенос моделі між середовищами. Код воркшопу підтримує Apple Silicon (через MPS), CUDA‑GPU й CPU. Це дозволяє запускати навчання як на MacBook із чипом M‑серії, так і на звичайному ноутбуці з NVIDIA‑GPU або навіть на чистому CPU, якщо прийняти повільніший темп. Для тих, у кого локальне залізо обмежене, завжди залишається варіант Google Colab із безкоштовними GPU.
Локальний ноутбук чи Google Colab: як обрати середовище
Практична сторона навчання LLM з нуля неминуче впирається в питання: де саме це робити. Воркшоп пропонує два основні варіанти — локальний ноутбук або Google Colab.
Локальний варіант орієнтований на машини з приблизно 16 ГБ оперативної пам’яті. На такій конфігурації маленька GPT‑2‑подібна модель із символьним токенайзером і шістьма шарами трансформера тренується досить швидко, щоб воркшоп залишався інтерактивним. Менший обсяг пам’яті теж можливий, але тоді доведеться змиритися з повільнішим навчанням або зменшити розміри батча й інші параметри.
Google Colab пропонує альтернативу для тих, у кого локальне залізо слабше або нестабільне. Безкоштовні GPU дозволяють значно прискорити тренування навіть такої невеликої моделі. У репозиторії передбачені інструкції з встановлення необхідних бібліотек у Colab, тож перехід у хмарне середовище не вимагає складної підготовки.
Важливо, що в обох випадках сценарій роботи однаковий: клонування GitHub‑репозиторію, встановлення залежностей, запуск тренувального скрипта. Це дозволяє учасникам легко перемикатися між локальним і хмарним середовищем, не змінюючи сам код моделі.
Навчання як інженерна дисципліна, а не магія великих цифр
Попри те, що воркшоп зосереджений на маленькій моделі, він торкається ширшого питання: що насправді визначає якість сучасних LLM. Архітектура GPT‑2‑подібного декодера‑only трансформера вже давно стала стандартом, і в багатьох випадках різниця між поколіннями моделей полягає не стільки в базовій структурі, скільки в тому, як саме вони тренуються.
Навіть у межах цього невеликого проєкту видно, що ключові рішення — це не лише кількість шарів чи розмір ембеддингу, а й:
- вибір токенайзера й розміру словника;
- масштаб і структура датасету;
- організація тренувального циклу;
- баланс між обчислювальними ресурсами й цільовою якістю.
У великих моделях ці ж принципи працюють на інших масштабах. Коли виходять нові версії систем на кшталт Gemini, стрибок у бенчмарках часто досягається не радикально новою архітектурою, а «розумнішим» тренуванням: кращим відбором даних, більш ефективним fine‑tuning, складнішими схемами пост‑тренування.
У цьому сенсі маленька GPT‑2‑подібна модель на Шекспірі — це зменшена копія тих самих інженерних задач. Вона показує, що навіть у локальних умовах доводиться думати про збіжність, покриття біграм, компроміси між розміром словника й обсягом даних, а також про те, як організувати тренування так, щоб модель дійсно навчилася, а не просто «крутила градієнти».
Висновок: локальний GPT‑2 як інструмент розуміння, а не заміна хмари
Навчити GPT‑2‑подібну мовну модель з нуля на ноутбуці — це не спосіб уникнути хмарних обчислень у промислових проєктах. Це спосіб повернути контроль над розумінням того, що відбувається всередині LLM.
Воркшоп Ангелоса Періволаропулоса демонструє, що:
- невелику декодер‑only модель можна реалізувати напряму в PyTorch, без високорівневих бібліотек;
- символьний токенайзер із 65 символами й компактний шекспірівський корпус створюють умови, за яких модель реально зійдеться на локальному залізі;
- ноутбук із 16 ГБ ОЗП або безкоштовний GPU в Google Colab достатні, щоб пройти повний цикл — від токенізації до навчання й інференсу;
- спроба відтворити повномасштабний сучасний стек із 200‑тисячним токенайзером на такому датасеті приречена: модель просто не отримає достатньо даних, щоб навчитися.
У підсумку це не «міні‑GPT‑4», а навчальний інженерний інструмент. Він дозволяє побачити, як вибір токенайзера, розмір словника, архітектура й обмеження заліза переплітаються в реальній системі. А головне — показує, що шлях до розуміння великих моделей починається не з гігантських кластерів, а з невеликого, але прозорого експерименту, який можна запустити просто на власному ноутбуці.
Джерело
Training an LLM from Scratch, Locally — Angelos Perivolaropoulos, ElevenLabs