Малі відкриті моделі стають ключовим інструментом для пошуку, агентів і обробки документів, але більшість продакшн‑інфраструктури досі заточена під один великий модельний контейнер на GPU. У виступі на каналі AI Engineer інженер Superlinked Філіп Макрадулі розповів, як команда побудувала власний inference‑двигун для малих моделей з динамічним завантаженням, hot‑swap’ом і «розумним» вивантаженням з пам’яті — замість класичної схеми «одна модель — один контейнер — один GPU».
Чому малі моделі критичні для агентів і пошуку
Головний контекст — проблема «context rot»: якість відповідей великих моделей погіршується зі зростанням обсягу контексту, навіть якщо збільшувати вікно контексту. Дослідження Chroma показують, що деградація якості неминуча, коли в контексті накопичується забагато інформації.
Малі моделі тут працюють як шар попередньої обробки:
- Контекст‑менеджмент. Невеликі моделі можуть фільтрувати, агрегувати й структурувати дані до того, як вони потрапляють у LLM. Це зменшує кількість токенів і навантаження на основну модель.
- Tool calling. Малі моделі виступають окремими інструментами — наприклад, для класифікації, витягування сутностей чи побудови таксономій. У Superlinked вже використовували такий підхід у продакшні для класифікації товарів в e‑commerce через tool calling.
- Покращення «класичного» пошуку. Попередня обробка даних робить навіть прості інструменти на кшталт grep і файлових індексів ефективнішими.
Спільнота рухається в тому ж напрямку: Андрій Карпатий будує графові бази знань на основі NER‑моделей, Chroma випустила власну модель для фільтрації й управління контекстом, а інші розробники створюють рішення для агресивного скорочення токенів перед викликом LLM.
Чим inference для малих моделей НЕ є
Інтуїтивна відповідь на проблеми inference — «додати ще GPU». Для малих моделей це часто означає масове марнування ресурсів:
- Типові моделі для ембеддингів, реранкінгу чи NER (Stella, GlyNER тощо) займають лише кілька гігабайтів пам’яті.
- Якщо виділяти окремий GPU під кожну таку модель, більшу частину часу він простоює.
Для цього класу задач критичною стає можливість:
- Hot‑swap моделей на одному GPU. Кілька моделей ділять один GPU, завантажуючись і вивантажуючись за потреби.
- Евікція за принципом LRU. Моделі, які давно не використовувалися, вивантажуються з пам’яті, звільняючи місце для нових.
- Швидке перемикання інструментів. Якщо в агенті одна задача потребує реранкера, інша — NER‑моделі, інфраструктура має дозволяти миттєво змінювати набір активних моделей без перепідняття контейнерів.
Ще одна хибна уява: inference — це лише «сервер, який крутить модель». У реальному продакшні потрібен повний ланцюжок:
- роутинг запитів;
- авто‑масштабування;
- черги;
- моніторинг (Prometheus, Grafana);
- керування GPU‑пулами та spot‑інстансами.
На ринку, за оцінкою Superlinked, немає open‑source рішення, яке б з’єднувало inference‑двигун і продакшн‑кластер в одному стеку для малих моделей. Саме цю нішу команда й намагається закрити.
«Інь і ян» inference: моделі проти інфраструктури
Superlinked пропонує дивитися на inference як на поєднання двох рівнозначних частин.
Інь: широка підтримка відкритих моделей
Без підтримки потрібних моделей будь‑яка інфраструктура втрачає сенс. Відкритий простір моделей зростає вибухово:
- На Hugging Face вже мільйони моделей (станом на березень — близько 3 млн).
- Open‑source швидко наздоганяє й переганяє керовані сервіси в точкових задачах: на бенчмарках на кшталт MTEB вузькоспеціалізовані моделі часто показують кращі результати.
- Невеликі моделі на кшталт Gemma з низькою кількістю параметрів демонструють ELO‑рейтинги, вищі за значно більші моделі.
Підтримати «сотні моделей» — нетривіальне завдання, бо:
- Різні реалізації attention. BERT, Qwen, ColBERT та інші використовують різні варіанти flash attention, grouped query attention тощо.
- Різні позиційні кодування. BERT працює з абсолютними позиційними ембеддингами, Qwen — з rotary embeddings; це вимагає різної логіки в forward‑проході.
- Різні вихідні формати.
- ColBERT генерує множину векторів (late interaction).
- Cross‑encoders і реранкери можуть повертати не вектори, а скорингові значення.
Щоб уніфікувати це, Superlinked:
- реімплементує forward‑прохід моделей, адаптуючи attention, padding і роботу з Q/K/V;
- підтримує змінну довжину послідовностей у flash attention, щоб:
- робити токен‑орієнтоване батчування;
- не витрачати обчислення на «порожні» токени при падингу до максимальної довжини в батчі.
Це дозволяє ефективно працювати з моделями різних архітектур, не жертвуючи продуктивністю.
Ян: кластер і API як єдине ціле
Друга половина — інфраструктурна. Superlinked описує її як шар між простим API і реальним залізом.
Базові примітиви API:
encode— отримання ембеддингів;score— обчислення скорів (наприклад, для реранкінгу);extract— витягування структурованої інформації.
Під ними працює:
- Роутер і черги. Розподіляють навантаження між пулами ресурсів залежно від поточного трафіку.
- Різні GPU‑пули. Поєднання spot‑інстансів і потужніших GPU для різних типів задач.
- Авто‑масштабування через KEDA + Prometheus. Метрики з Prometheus використовуються для динамічного масштабування кластерів і перерозподілу моделей, щоб уникати простою GPU.
- Декларативне керування. Моделі описуються в конфігурації; далі достатньо зробити
terraform apply. Для розгортання доступні Helm‑чарти та Docker‑образи.
Ключова ідея — дати розробникам не окремо «двигун для моделей» і «кластер Kubernetes», які треба зшивати власним кодом, а цілісний стек для inference малих моделей.
Від теорії до open source
Результатом цієї роботи став open‑source inference‑двигун Sie (Superlinked inference engine), який поєднує:
- адаптований forward‑прохід для широкого спектра малих моделей (ембеддинги, реранкери, NER, ColBERT‑подібні архітектури);
- кластерну інфраструктуру з роутингом, авто‑масштабуванням і GPU‑менеджментом.
За задумом авторів, це має закрити прогалину між експериментами з малими моделями й реальним продакшном, де важливі не лише FLOPS, а й ефективне використання пам’яті, гнучке завантаження моделей і повноцінний спостережуваний стек.
Джерело
The Small Model Infrastructure Nobody Built (So We Did) — Filip Makraduli, Superlinked