Зміст
Коротко
Проєкт Colibri демонструє незвичний запуск GLM-5.2 — MoE-моделі на 744 млрд параметрів — на звичайному комп’ютері з 25 ГБ оперативної пам’яті без GPU. Це не робить систему швидким чат-сервером: автор повідомляє про 0,05–0,1 токена за секунду на тестовій конфігурації.
Цінність експерименту в іншому. У пам’яті постійно перебуває лише компактна частина моделі, а потрібні експертні блоки надходять із NVMe-накопичувача на вимогу. Це наочний приклад того, як розріджена архітектура змінює вимоги до обладнання.
Що сталося
Colibri — невеликий рушій на C без зовнішніх залежностей. Згідно з описом автора, щільні шари, спільні експерти та представлення займають близько 9,9 ГБ ОЗП, тоді як 21 504 маршрутизовані експерти загальним обсягом приблизно 370 ГБ зберігаються на NVMe.
Для кожного токена маршрутизатор обирає тільки частину експертів. Тому програмі не потрібно тримати в пам’яті всі ваги моделі: вона зчитує необхідні блоки з диска й залишає часто вживані блоки у вільній пам’яті. Плата за це — очікування дискового читання, особливо коли кеш ще не наповнений.
Автор також додав стиснене збереження контексту розмови, завчасне читання ймовірно потрібних експертів і передбачення кількох токенів за один прохід. Це інженерний дослід із конкретним вузьким місцем — швидкістю NVMe, а не обіцянка універсальної заміни хмарних моделей.
Чому це важливо
MoE-модель не залучає всі параметри на кожному кроці. Для GLM-5.2 автор оцінює активну частину приблизно у 40 млрд параметрів на токен, хоча сумарний розмір суттєво більший. Colibri перетворює цю властивість на ієрархію зберігання: стабільний робочий набір лишається в ОЗП, а вибрані експертні ваги завантажуються зі сховища.
Для розробників це корисний архітектурний приклад. Обмеження визначає не лише число параметрів, а й те, які з них потрібні одночасно, скільки даних слід перемістити та чи можна передбачити наступне звернення. Водночас локальний запуск не означає високої швидкості відповіді.
| Характеристика | Що заявляє автор | Практичний наслідок |
|---|---|---|
| Пам’ять | близько 9,9 ГБ постійно в ОЗП | модель можна запустити на доступній машині |
| Сховище | близько 370 ГБ на NVMe |
потрібен швидкий локальний диск |
| Швидкість | 0,05–0,1 токена/с на тестовій машині | звичний чат буде незручним |
| Код | один файл C без важкого середовища | легше вивчати будову рушія |
На практиці
Colibri варто розглядати для завдань, де результат не потрібен за секунди: нічної пакетної обробки документів, локального дослідження моделі або аналізу конфіденційних текстів, які не можна передавати зовнішньому постачальнику.
Перед таким експериментом слід перевірити обмеження власної машини, а не лише гучне число параметрів:
- Виділити швидкий
NVMeз запасом у кілька сотень гігабайт; мережеве сховище зруйнує перевагу підходу. - Виміряти випадкове читання та споживання пам’яті на власних запитах, а не покладатися на чужі показники.
- Відокремити пакетні завдання від інтерактивних: черга та фонове виконання чесніші за інтерфейс, у якому людина чекає кожен токен.
- Перевірити ліцензію ваг, походження файлів і цілісність завантаження до обробки чутливих даних.
Для сервісу з кількома одночасними користувачами рушій поки не годиться: послідовності виконуються по черзі, а затримка може вимірюватися хвилинами. Проте ідеї кешування експертів і завчасного читання корисні й для швидших систем.
Підсумок
Colibri не доводить, що гігантська LLM стала зручною на кожному комп’ютері. Він показує вужчу, але цікаву річ: розріджену MoE-модель можна розподілити між рівнями пам’яті та запустити локально, якщо повільна відповідь є прийнятним компромісом.
Для розробника це цінний відкритий матеріал про маршрутизацію експертів, квантування та дисковий кеш. Для продукту це привід спочатку визначити допустиму затримку: вражаючий запуск на 25 ГБ ОЗП ще не означає придатність для інтерактивного ШІ.