Від найкращого транскрайбера до «кишенькових» LLM: як досвід ElevenLabs формує нову хвилю локальних моделей
У світі генеративного ШІ більшість історій починаються з хмарних дата-центрів, сотень GPU і мільярдів параметрів. Але є й інша траєкторія — від прикладних, жорстко обмежених задач до маленьких, але добре продуманих моделей, які можна тренувати на звичайному ноутбуці. Саме так виглядає шлях Ангелоса Періволаропулоса, керівника команди speech‑to‑text в ElevenLabs, який відповідає за одну з найсильніших систем транскрипції на ринку — Scribe v2 — і паралельно показує інженерам, як із нуля зібрати власну мовну модель локально.
У межах практичного воркшопу на каналі AI Engineer він демонструє, що «тренувати LLM з нуля» — це не обов’язково про кластери в хмарі. Це може бути про PyTorch, ноутбук із 16 ГБ пам’яті, невеликий датасет і дуже чітке розуміння того, які компоненти моделі справді важливі. І цей погляд напряму виростає з досвіду побудови Scribe v2 — системи, яку в ElevenLabs описують як найкращу транскрипційну модель на популярних публічних бенчмарках на момент проведення воркшопу.
Від Scribe v2 до локальних LLM: що дає бекграунд у транскрипції
Поточна роль Ангелоса в ElevenLabs — це не просто «ML-інженер у команді продукту». Він очолює команду, яка займається перетворенням мовлення в текст, і значну частину часу проводить у режимі дослідника: тренує нові моделі, оптимізує інференс, а також частково відповідає за продуктову сторону — від вимог клієнтів до того, як модель поводиться в реальних сценаріях.
Саме його команда тренувала Scribe v2 — модель, яку в компанії позиціонують як найкращу на ринку за результатами популярних публічних бенчмарків для транскрипції. Це не просто маркетингова вивіска: щоб вийти на рівень «state‑of‑the‑art» у speech‑to‑text, доводиться роками відточувати інженерні інстинкти — від вибору токенайзера до побудови пайплайнів інференсу в реальному часі.
Цей досвід помітно впливає на те, як Ангелос підходить до навчання мовних моделей у воркшопі. Він мислить не абстрактними «великими LLM», а конкретними будівельними блоками: токенайзер, архітектура, тренувальний цикл, інференс. І наголошує на тому, що саме ці базові рішення визначають, чи буде модель практично корисною — незалежно від того, чи це багатомовний транскрайбер для агентів у реальному часі, чи крихітний GPT‑2‑подібний LLM на ноутбуці.
У світі голосових технологій вибір токенайзера часто займає місяці, тоді як архітектура — лічені тижні. Для нової TTS‑моделі команда може пів року думати над тим, як саме кодувати текст, і лише потім добудовувати нейромережу навколо цього рішення. Ця «одержимість токенайзером» переноситься й у воркшоп: перший великий блок присвячений саме тому, як представити текст у вигляді токенів так, щоб модель узагалі мала шанс зійтися на маленькому датасеті.
Воркшоп без магії: PyTorch, ноутбук і GitHub замість «чорних скриньок»
Формат сесії принципово відрізняється від класичних конференційних доповідей. Це не набір слайдів про те, як «десь там» тренуються великі моделі, а практичний воркшоп, де учасники мають буквально «забруднити руки» кодом.
Ціль — з нуля натренувати невелику мовну модель у стилі GPT‑2, не використовуючи жодних попередньо натренованих ваг і не покладаючись на високорівневі бібліотеки на кшталт Hugging Face Transformers. Усе будується безпосередньо на PyTorch і кількох базових Python‑бібліотеках. Це навмисне обмеження: воно змушує розібратися, як саме влаштований трансформер, а не просто викликати готовий клас.
Код воркшопу викладений у публічному GitHub‑репозиторії, посилання на який учасники отримують через QR‑код. Далі кожен може обрати свій шлях: тренувати модель локально або піти в хмару.
Локальний сценарій розрахований на доволі реалістичну конфігурацію: ноутбук із приблизно 16 ГБ оперативної пам’яті. За таких умов невелика модель тренується досить швидко, щоб побачити результат у межах сесії. Якщо ж ресурси слабші або немає можливості довго навантажувати локальну машину, передбачений варіант із Google Colab: безкоштовні GPU цілком вистачають для такого масштабу експерименту.
Технічні вимоги залишаються помірними: Python 3.12, базове розуміння мови (хоча за потреби можна й «копіпастити»), підтримка Apple Silicon через MPS, CUDA або просто CPU. Для керування залежностями використовується інструмент UV, який автоматично створює віртуальне середовище й синхронізує пакети. Код можна писати як у локальному редакторі, так і в Colab‑ноутбуці, де одна команда встановлює все необхідне — від PyTorch до NumPy.
Цей підхід добре резонує з тим, як працюють дослідницькі інженери в «великих лабораторіях»: більша частина «магії» — це не екзотичні архітектури, а акуратна реалізація базових компонентів, правильний тренувальний цикл і подальші оптимізації під конкретні сценарії.
Чому досвід Scribe v2 важливий для дизайну маленької LLM
На перший погляд може здатися, що транскрипція мовлення й генерація тексту — це різні світи. Насправді ж обидві задачі спираються на однакові фундаментальні рішення: як представити текст, яку архітектуру обрати, як організувати тренування й інференс.
У випадку Scribe v2 команда Ангелоса працює над реальними часовими обмеженнями: модель має встигати розпізнавати мовлення в режимі реального часу, зберігаючи при цьому високу точність на публічних бенчмарках. Це означає, що кожен компонент — від токенайзера до оптимізації інференсу — має бути виправданим.
Цей спосіб мислення переноситься й у воркшоп:
по‑перше, акцент на токенайзері. У голосових системах вибір токенайзера може визначити, чи буде модель узагалі здатна коректно працювати з різними мовами, акцентами, пунктуацією. У воркшопі це трансформується в прагматичне рішення: замість повноцінного сучасного токенайзера використовується символьний, із дуже маленьким словником. Це дозволяє моделі реально зійтися на обмеженому датасеті, а не «вчитися в нікуди».
по‑друге, увага до інференсу. Хоча демонстраційна модель крихітна й може працювати де завгодно, сам факт, що її автор щодня займається оптимізацією реального часу для транскрипції, впливає на те, як він дивиться на «маленькі LLM». Тут немає культу «чим більше, тим краще» — є розуміння, що модель має відповідати обмеженням платформи, на якій вона працює.
по‑третє, фокус на тренувальному циклі. У великих моделях різниця між поколіннями часто полягає не стільки в архітектурі, скільки в тому, як саме організоване навчання: які дані, які режими fine‑tuning, які пост‑тренувальні етапи. У воркшопі ця думка звучить прямо: базова архітектура GPT‑подібних моделей давно стабілізувалася, а справжні прориви відбуваються в тому, як і на чому їх тренують.
Тому навіть маленький проєкт на Shakespeare‑корпусі стає майданчиком для відпрацювання тих самих принципів, які лежать в основі Scribe v2: уважний вибір представлення даних, продуманий тренувальний цикл, реалістичні обмеження інференсу.
Токенайзер як серце моделі: чому 65 символів кращі за 200 тисяч токенів
Перший великий технічний блок воркшопу присвячений токенайзеру — і це не випадковість. Для будь‑якої трансформерної моделі саме токенайзер визначає, як текст перетворюється на послідовність чисел, із якою працює нейромережа. LLM не «бачать» слова чи речення, вони оперують векторами, а отже, якість цього відображення критично важлива.
У демонстраційному проєкті використовується максимально простий, але стратегічно вдалий підхід: символьний токенайзер. Усі символи, що зустрічаються в тренувальному корпусі (тексти Шекспіра, включені в репозиторій), перетворюються на індекси. У підсумку виходить лише 65 різних токенів — тобто 65 можливих символів.
Це рішення напряму пов’язане з обсягом даних. Для символьного словника з 65 токенів кількість можливих біграм (пар «поточний символ — наступний символ») становить 65 × 65, тобто 4 225. На невеликому корпусі Шекспіра модель має шанс побачити більшість із цих біграм багаторазово, що дозволяє їй навчитися передбачати наступний символ із прийнятною якістю.
Якщо ж спробувати використати сучасний токенайзер із приблизно 200 тисячами токенів, ситуація кардинально змінюється. Кількість можливих пар токенів зростає до порядку 200 000 у квадраті — це вже десятки мільярдів комбінацій. Щоб модель мала шанс добре навчитися на такому словнику «з нуля», потрібні відповідні обсяги даних. На крихітному локальному датасеті така модель просто не зійдеться: тренування може тривати годинами, але якість залишиться незадовільною.
Саме тому воркшоп відверто підкреслює: повноцінний сучасний токенайзер на маленькому локальному датасеті — це шлях у нікуди. Символьний підхід із 65 токенами — це компроміс, який дозволяє побачити робочу модель, зрозуміти механіку трансформера й не потонути в статистичному шумі.
Водночас у такого рішення є очевидні обмеження. Символьні токенайзери погано масштабуються на складніші задачі: модель має вчитися розуміти кореляції між окремими літерами, а не між осмисленими одиницями на кшталт слів чи субслів. Фраза «the sky is blue» у вигляді слів дає моделі чіткі, семантично насичені токени, тоді як у вигляді символів — це довга послідовність, де зв’язки між «s», «k», «y» і пробілами стають набагато менш очевидними.
Для демонстраційної моделі на Шекспірі це прийнятний компроміс: невеликий словник, швидке тренування, зрозуміла поведінка. Але для «серйозних» LLM такий підхід не працює: модель стає надто дорогою в інференсі й тренуванні, а якість не виправдовує витрат. Саме тому в реальних продуктах на кшталт Scribe v2 вибір токенайзера — це окрема, глибока інженерна задача.
Архітектура без прикрас: GPT‑2 як навчальний полігон
Ще одна принципова риса воркшопу — вибір архітектури. Замість того щоб гнатися за найновішими моделями, Ангелос свідомо зупиняється на GPT‑2‑подібному трансформері. Це «старіша» архітектура, але її фундаментальні частини залишаються актуальними: декодер‑only, каузальна self‑attention, MLP‑блоки, layer norm.
Саме такі моделі домінували в період, на якому фокусується воркшоп, і багато сучасних систем усе ще спираються на ті самі базові принципи, просто масштабовані й оптимізовані під довші контексти й більші обсяги даних.
У демонстраційній конфігурації використовується контекстне вікно (block size) у 256 токенів. Це означає, що модель «дивиться» на 256 попередніх символів, коли передбачає наступний. Для символьного токенайзера й невеликого корпусу цього достатньо, щоб уловити локальні патерни стилю й синтаксису.
Трансформер складається з шести шарів, кожен із яких містить кілька голів уваги. Кожна голова може «спеціалізуватися» на різних аспектах послідовності — наприклад, на пунктуації чи граматичних структурах. Хоча в маленькій моделі ця спеціалізація не така виразна, як у великих LLM, сама ідея багатоголової уваги залишається ключовою.
Розмір ембеддингів обрано на рівні 384. Для словника з 65 токенів це дає приблизно 25 тисяч параметрів у таблиці ембеддингів — дуже скромну цифру, яка добре вписується в обмеження локального тренування. Для порівняння, якби взяти типовий GPT‑2‑словник із 50 тисяч токенів і той самий розмір ембеддингів, кількість параметрів у таблиці зросла б до близько 19 мільйонів. І це лише один шар моделі.
Такий контраст добре ілюструє, чому воркшоп наполягає на «крихітній» конфігурації: вона дозволяє побачити повний цикл — від токенізації до інференсу — без необхідності вдаватися до агресивних оптимізацій чи спеціалізованого заліза. І водночас ця архітектура достатньо близька до реальних GPT‑подібних моделей, щоб отримані навички можна було перенести на більші проєкти.
Навіщо інженерам локальні LLM, якщо є хмара
На тлі гігантських хмарних LLM маленька GPT‑2‑подібна модель на ноутбуці може здаватися іграшкою. Але воркшоп Ангелоса показує іншу перспективу: локальні моделі — це не заміна хмарі, а інструмент для розуміння й контролю.
По‑перше, це спосіб навчитися мислити як дослідницький інженер. Коли модель збирається вручну на PyTorch, без готових абстракцій, стає зрозуміло, які саме рішення впливають на поведінку системи. Це знання потім можна застосувати й у роботі з великими моделями — від налаштування fine‑tuning до побудови кастомних токенайзерів.
По‑друге, це шлях до автономії. Не всі задачі потребують гігантських LLM, і не всі компанії готові віддавати дані в хмару. Маленькі моделі, які можна тренувати й запускати локально, відкривають простір для приватних, доменно‑специфічних рішень — від внутрішніх чат‑асистентів до спеціалізованих генераторів тексту.
По‑третє, це місток між різними доменами ШІ. Досвід, накопичений у speech‑to‑text і реальному часі, як у випадку Scribe v2, виявляється напрочуд корисним у світі LLM. Питання про те, як кодувати текст, як організувати інференс на обмежених ресурсах, як будувати тренувальні цикли, — універсальні. І воркшоп показує, як ці принципи можна застосувати в компактному, але повністю прозорому проєкті.
Висновок: маленькі моделі як школа великого ШІ
Історія Ангелоса Періволаропулоса — це приклад того, як робота над високоточними прикладними системами на кшталт Scribe v2 може стати фундаментом для зовсім іншого типу проєктів — освітніх, відкритих, локальних. Керуючи командою speech‑to‑text в ElevenLabs і тренуючи модель, яку вважають найкращою на публічних бенчмарках, він паралельно демонструє, що розуміння ШІ починається не з API до гігантських LLM, а з базових рішень: як ми кодуємо текст, яку архітектуру обираємо, як організуємо тренування.
Практичний воркшоп із тренування GPT‑2‑подібної моделі на ноутбуці — це не спроба конкурувати з хмарними гігантами. Це спроба повернути інженерам відчуття контролю над моделлю, показати, що шлях від сирого тексту до працюючого LLM можна пройти власноруч — із PyTorch, невеликим датасетом і чітким розумінням обмежень.
У час, коли ШІ дедалі частіше сприймається як «чорна скринька», такі ініціативи нагадують: найцікавіше відбувається саме там, де інженери готові розібрати модель до гвинтика — і зібрати її знову, вже під свої задачі.
Джерело
Training an LLM from Scratch, Locally — Angelos Perivolaropoulos, ElevenLabs