Моделі та платформи ШІ
Together AI запроваджує безперервну компіляцію для промислового інференсу

4 листопада 2026 року Together AI оголосила про Polymorphic Inference і представила Together Compiler як першу реалізацію цієї концепції. Система на основі агентів безперервно переналаштовує інференс відповідно до змін моделей, трафіку й апаратного забезпечення та вже працює з багатьма найважливішими промисловими навантаженнями інференсу компанії й на деяких популярних безсерверних кінцевих точках.
За даними Together AI, менш ніж за 24 години компілятор забезпечив від 1,3 до 3 разів більше токенів за секунду, ніж високоефективні базові конфігурації з відкритим кодом, у тестах із Kimi K3, GLM 5.3, MiniMax M3.1-Flash і DeepSeek v4.1-Flash. Ці результати відображають головну ідею анонсу: оптимізація може бути безперервним процесом пошуку, прив’язаним до конкретного розгортання, а не одноразовим ручним налаштуванням, яке фіксують під час запуску.
Зміни моделей, трафіку й апаратного забезпечення
Polymorphic Inference — це термін Together AI для інфраструктури обслуговування запитів, яка адаптується до швидшого випуску моделей, різноманітних архітектур, мінливих профілів трафіку й вимог до рівня обслуговування, а також частіших змін апаратного забезпечення. На противагу цьому статичний підхід передбачає незмінну конфігурацію рушія. Конфігурація, налаштована для одних умов, не обов’язково підійде для інших, особливо коли змінюються поведінка моделі й розподіл запитів.
Спостереження компанії за роботою системи у виробничому середовищі дають конкретні приклади. За даними Together AI, під час робочого часу в одній країні обсяг промптів сягав приблизно 97 000 токенів проти 70 000 в інших регіонах, а протягом двох тижнів після випуску однієї моделі довжина промптів зросла на 80%, оскільки використання змістилося в бік агентних навантажень. Різке зростання кількості запитів від клієнтів також може подвоїти довжину промптів і знизити частоту влучань у кеш, змінюючи умови, для яких було налаштовано наявну конфігурацію.
В анонсі також переглянуто попередній акцент Together AI на мегаядрах, які об’єднують операції в одне ядро. Після запуску ранніх версій у виробничому середовищі компанія дійшла висновку, що саме по собі об’єднання операцій не є універсальною метою проєктування: для архітектур суміші експертів і динамічних навантажень можуть знадобитися інші методи. Так само ядра, розроблені з розрахунком на фіксований або випадковий трафік, можуть бути неналежно налаштовані для виробничого трафіку, де маршрутизація залежно від даних впливає на те, які оптимізації виявляються найефективнішими.
Як працює безперервна компіляція
Together Compiler отримує на вхід профіль трафіку, модель і апаратне забезпечення, а потім за допомогою агентів генерує та вимірює ефективність можливих оптимізацій рушія інференсу. Постійно запущений рушій завантажує модель один раз і динамічно перезавантажує кандидатні проходи прямого поширення, не перезапускаючи весь рушій. Паралельні агенти генерують кандидатні варіанти й обмінюються повідомленнями на спільній дошці, підтримуючи експерименти в черзі, поки інші агенти міркують або користуються інструментами.
Два рівні вимірювання дають змогу збалансувати кількість експериментів і реалістичність оцінювання. Швидкі рушії завантажують частину шарів для швидких ітерацій і вимірювань із низькою дисперсією; повільніші завантажують більше шарів, щоб перевірити, чи зберігають кандидатні варіанти ефективність на реалістичних розподілах даних. Окрема модель вартості поєднує характеристики апаратного забезпечення, мікротести продуктивності й вимірювання проходів прямого поширення, щоб звузити пошук конфігурацій паралелізму до того, як агенти витратять час на оптимізацію кандидатних варіантів.
У технічній статті зазначено, що кандидатні варіанти-переможці проходять перевірки на забруднення кешу KV і якість результатів, перш ніж їх можна буде використовувати для обслуговування запитів. Ці перевірки запускають після вичерпання бюджету на оптимізацію, коли остаточний вихідний код готують до інтеграції в рушій обслуговування запитів.
У дописі про запуск наведено порівняння часу до готовності обслуговувати запити: 467 секунд для послідовності дій у звичайному режимі проти 9,0 секунди з конфігурацією Together Compiler. Ці показники стосуються запуску рушія під час оптимізації, а не затримки окремого запиту, і допомагають зрозуміти, чому динамічне перезавантаження є ключовим для пропускної здатності експериментальної системи.
Обсяг оцінювання та доступ для клієнтів
Для порівняння рушіїв у статті використано провідні відкриті конфігурації станом на 30 жовтня 2026 року; базову стратегію паралелізму залишили незмінною, щоб окремо оцінити вплив оптимізації за допомогою агентів. Заявленим винятком із типового набору навантажень для оцінювання був Trainium2: для нього використали синтетичний набір даних із кількома ходами, оскільки наявна реалізація ще не підтримувала більшу кількість паралельних запитів у межах доступного обсягу HBM.
За словами Together AI, на результати оптимізації частково вплинуло те, що пропускна здатність експериментів у 252 рази вища, ніж у базових систем оптимізації на основі агентного рекурсивного самовдосконалення.
Окрім інференсу мовних моделей, у статті повідомляють про прискорення від 1,5 до 6,4 раза для протестованих моделей погоди, біології, часових рядів і рівнянь у частинних похідних, зі збереженням побітово точних результатів у зазначених тестах.
Кінцеві клієнти можуть подати заявку на ранній доступ у межах обмеженого бета-тестування. Together AI планує додати оптимізацію виділених кінцевих точок в один клік, а дорожня карта досліджень компанії передбачає спекулятивне декодування з адаптацією до предметної області, запиту, токена й завантаженості трафіку, а також динамічну маршрутизацію між робочими вузлами й конфігураціями розгортання для різнорідного безсерверного трафіку.
Після запуску основним принципом побудови стека інференсу Together AI стає вимірювання для кожного конкретного розгортання, а не пошук універсально оптимального ядра. Найважливіше для клієнтів питання зараз — чи зможе обмежене бета-тестування відтворити заявлений приріст продуктивності на їхніх власних моделях, за їхнього трафіку й на їхньому обладнанні, водночас пройшовши ті самі перевірки якості. Саме цю мінливість і покликана усунути Continuous Compilation.












