Іван Нікітін, генеральний директор і співзасновник Fortytwo — серія інтерв’ю

Іван Нікітін — генеральний директор і співзасновник Fortytwo, де він розробляє технологію роєвого інференсу, що об’єднує кілька моделей ШІ для спільного міркування й оцінювання роботи одна одної. Його досвід охоплює ігри, розмовний ШІ, генеративний ШІ та інтерактивні системи в Temporal і Sensorium. У 2011 році він разом із Владом Ларіним, нині співзасновником і технічним директором Fortytwo, заснував Temporal, де здобув досвід роботи з популяціями агентів, що розвиваються, і системами, які поєднують спеціалізовані моделі.

Fortytwo створює інфраструктуру ШІ, що дає змогу моделям співпрацювати під час інференсу. У Fortytwo Engine використовується Swarm Decoder, який спрямовує спільний процес міркування в міру його розгортання, прагнучи підвищити точність і скоротити зайву генерацію токенів під час виконання тривалих завдань. Компанія пропонує розробникам API через Fortytwo Engine, а також можливість розгортання локально через Fortytwo Harbor.

Перш ніж заснувати Fortytwo, ви роками створювали продукти на основі розмовного ШІ, генеративного ШІ та інтерактивних систем у Sensorium і Temporal. Як цей досвід сформував ваше уявлення про обмеження окремих великих мовних моделей і зрештою підштовхнув вас до роєвого підходу, на якому ґрунтується Fortytwo?

Значна частина нашої команди, зокрема й я, прийшла у сферу ШІ через ігри. Ігри стали колискою персональних обчислень і сучасного ШІ: саме завдяки їм з’явилися графічні процесори (GPU), а ігри стали першим серйозним випробувальним середовищем для навчання з підкріпленням. Ігрові світи дали нам практичне середовище для створення агентів, здатних навчатися, адаптуватися й змагатися. У Temporal, яку я заснував у 2011 році разом із Владом Ларіним, нині співзасновником і технічним директором Fortytwo, ми взялися розвивати адаптивний інтелект: популяції агентів змагалися під тиском відбору. Нас цікавило, як популяція може досягти більшого, ніж окремий агент, якщо є дієвий механізм виявлення її найкращих здобутків і подальшого розвитку на їхній основі. Відбір і оцінювання стали центральними поняттями в нашому підході до інтелекту.

Коли з’явилися трансформерні моделі, ми розширили діяльність на сферу розмовного ШІ та створили платформу для керованих ШІ персонажів, здатних вести невимушені, не прописані заздалегідь розмови, маючи пам’ять і власну особистість. Це було за кілька років до появи ChatGPT, а контекстне вікно моделей, з якими ми працювали, становило лише від 512 до 1 024 токенів. Розраховувати, що одна рання мовна модель надійно впорається з усіма вимогами такого досвіду, було неможливо. Нам довелося створити спеціалізований конвеєр моделей, кожна з яких відповідала за вужче коло завдань, а також логіку поєднання їхніх результатів. Ранжування й відбір відповідей стали необхідними для належної роботи всієї системи. Ми зрозуміли, наскільки потужною може бути добре спроєктована система, що поєднує обмежені за можливостями моделі.

Другий урок стосувався ефективності. Ми з’ясували, що спеціалізовані моделі можна ефективніше навчати й запускати для чітко визначених завдань, досягаючи більшого за обмежених обчислювальних ресурсів. Однак масштабування інференсу залишалося складним завданням: з одного боку були ліміти використання API, з іншого — витрати на самостійне розміщення моделей у великому масштабі. Не маючи доступу до найпотужніших обчислювальних ресурсів, ми мусили ретельно продумувати, як отримати більше від наявних. У Fortytwo ми об’єднали ці уроки в концепції роєвого інференсу: кілька моделей або кілька екземплярів однієї моделі беруть участь у міркуванні й водночас оцінюють роботу одна одної. У результаті колектив перевершує за точністю кожного зі своїх учасників.

Fortytwo Engine використовує кілька моделей із відкритими вагами, щоб спрямовувати єдиний процес міркування й перевіряти результати одна одної під час генерації відповіді. Чим цей підхід відрізняється від традиційних багатоагентних систем, ансамблів моделей або простого запуску кількох моделей із подальшим вибором найкращої відповіді?

Ключова відмінність полягає в тому, що роєвий інференс безпосередньо вбудований у розроблений нами рушій інференсу. Ми називаємо його Swarm Decoder: кілька учасників-моделей безперервно формують єдину траєкторію міркування в міру її побудови. Оцінювання та спрямування відбуваються в межах цього процесу, тож моделі можуть впливати на його напрям ще до завершення відповіді.

Альтернативні підходи працюють інакше. В ансамблі, що оперує готовими відповідями, моделі генерують окремі відповіді, які потім ранжують, відбирають або об’єднують. У початковій архітектурі Fortytwo, реалізованій у 2025 році, завершені відповіді ранжували за оцінками інших моделей. Це суттєво підвищило точність відповідей, але збільшило затримку й обчислювальні витрати. У багатьох традиційних багатоагентних системах роботу розподіляють між агентами, а їхню взаємодію координують за допомогою оркестратора та повідомлень природною мовою. Така передача завдань може вимагати додаткових запитів до моделей, повторного передавання контексту й ухвалення рішень про те, яку інформацію передавати від одного агента іншому. У Swarm Decoder немає передачі завдань: учасники працюють над однією траєкторією, а обмінюються лише оцінками того, який напрям кращий.

Swarm Decoder розроблено так, щоб виявляти хибні припущення під час генерації, перш ніж на їхньому розвитку буде витрачено значні зусилля. Мета — зменшити кількість помилок, повернень до попередніх кроків і зайвої генерації; ефективність підвищується тоді, коли завдяки цій перевірці вдається уникнути більшого обсягу роботи, ніж вона сама потребує. Саме тому затримка не зростає: виконання відбувається прямішим шляхом, тож Engine виконує завдання швидше, ніж та сама модель окремо, і використовує загалом менше токенів з урахуванням усіх моделей-учасниць.

Ви назвали дрейф моделі під час тривалих завдань однією з головних проблем. Що саме спричиняє цей дрейф і як він проявляється на практиці — у програмній інженерії, дослідженнях чи автономних агентах ШІ?

Дрейф виникає, коли контекст моделі поступово перестає стосуватися завдання. Під час тривалого запуску контекст заповнюється власними відповідями моделі, результатами роботи інструментів, вмістом файлів і повторними спробами. Початкова інструкція становить дедалі меншу частку того, на чому зосереджується модель, а її попередні помилки вже входять до даних, на основі яких вона міркує. Через це помилки накопичуються, а не нівелюють одна одну. Крім того, сучасні моделі міркування навчають із підкріпленням, щоб вони виконували завдання, і вони засвоюють короткі шляхи, які лише створюють враження завершення: пропустити виклик інструмента, оголосити про успіх, підсумувати замість перевірки. Ми називаємо це лінощами, і передові моделі схильні до них не менше, ніж моделі з відкритими вагами. Першопричина в тому, що окрема модель не має зовнішньої перевірки. Вона сама оцінює свою роботу, а моделі погано вміють точно аналізувати власні дії.

У програмній інженерії це проявляється, коли агент виправляє описану вами помилку, але порушує обмеження, зазначене в першому повідомленні, пише тест, який легко проходить, або чотири рази читає той самий файл, бо забув, що вже з нього дізнався. У дослідженнях це тривалий запуск, під час якого модель відходить від поставленого вами запитання до того, на яке найлегше відповісти, і повертається із загальним підсумком. В автономних агентів це має високу ціну: відхилення від теми, повторні виклики інструментів, повернення до вже пройдених кроків і витрати на токени, що в кілька разів перевищують необхідні для завдання.

Це можна виразити числом. Ми запустили Qwen 3.8 27B на 450 завданнях DeepSWE — реальних завданнях із програмної інженерії, що передбачають використання інструментів упродовж тривалого контексту, — спочатку окремо, а потім через Fortytwo Engine. Під час окремих запусків модель у середньому використовувала 16,3 мільйона токенів за запуск, загалом — 7,4 мільярда. Через Engine та сама модель у середньому використовувала 12,3 мільйона токенів за запуск, загалом — 5,6 мільярда, тобто на 24,7% менше, і водночас розв’язала більше завдань: 47,8% проти 42,2%. У самій моделі нічого не змінилося. Чотири мільйони токенів за запуск, яких вдалося уникнути, припадали на дрейф: повторне перечитування, нові спроби й повернення до попередніх кроків, до яких змушена вдаватися окрема модель, бо ніхто не помічає її хибних поворотів у процесі роботи. Рой виявляє їх, тож моделі не доводиться витрачати на них токени.

Раніше Fortytwo використовувала моделі для оцінювання відповідей одна одної після їх завершення, тоді як нинішня архітектура дає їм змогу впливати на процес міркування ще під час його формування. Чого ви навчилися завдяки попередньому підходу і чому керування в реальному часі ефективніше?

Архітектура 2025 року довела, що завдяки горизонтальному масштабуванню — залученню більшої кількості моделей, а не гонитві за найбільшою з них — ми можемо досягти можливостей рівня передових моделей. Рой моделей із відкритими вагами, які оцінювали повністю сформовані відповіді одна одної, перевершив найкращу окрему модель у цьому рої на 17 відсоткових пунктів. Крім того, він був стійким у ситуаціях, у яких окрема модель такою не є: зашумлені запити, підставні інструкції та більшість неправильних відповідей.

Ця архітектура не могла втручатися в процес. Оцінювання завершених відповідей працює для одного запитання, але запуски агентів складаються із сотень кроків із викликами інструментів між ними, а вирішальні помилки виникають на ранніх етапах і накопичуються. Якщо оцінювати результат наприкінці, кожна модель уже витратила повну кількість токенів, а оцінювач може лише вибирати серед траєкторій, які вже розійшлися. Крім того, витрати на рой зростали пропорційно до кількості моделей. Для одного складного запитання це прийнятно, але для агента програмування такий підхід не підходить.

Керування в реальному часі усуває обидві проблеми. Безперервне ранжування створює тиск відбору впродовж усього запуску, тож хибний поворот виправляється там, де він виникає, перш ніж поширитися далі. Рой не погоджується на недбалий підхід, адже в ранжуванні він поступається ретельнішому. Саме тому цей механізм тепер одночасно забезпечує вищу точність і меншу кількість токенів.

У тестуванні Qwen 3.8 27B компанія Fortytwo повідомляє, що в 450 запусках DeepSWE було використано на 24,7% менше токенів, а результати покращилися за шістьма бенчмарками. Що відбувається всередині рою, завдяки чому він підвищує ефективність і водночас зменшує споживання токенів?

Перевірка роєм має невеликі фіксовані витрати, тоді як обсяг роботи, якої вдається уникнути завдяки виправленню помилок, зростає разом із тривалістю завдання: кожен невиправлений хибний поворот ставить під загрозу все, що на ньому побудовано. Тому що довше триває завдання, то більше можна заощадити. DeepSWE належить до найдовших завдань у цьому спектрі, тож економія становить майже чверть усіх токенів.

Що стосується точності, то йдеться про нерівномірність інтелекту. Покращення моделей зазвичай нерівномірні: в одній галузі модель міркує на рівні PhD, а в іншій продукує цілковиту нісенітницю. Це відбувається тому, що донавчання, навчання з підкріпленням (RL) та інші етапи після навчання покращують модель на даних, на яких її навчали, а ці переваги слабшають, коли реальні завдання віддаляються від цих даних. Swarm Decoder не змінює модель. Він послідовно покращує сам процес міркування, тож шість бенчмарків — це не шість галузей, під які ми оптимізували модель, а шість способів виміряти те саме. Загалом модель стає розумнішою та уважнішою, а завдяки тому, що інші моделі перевіряють кожен крок, здається, ніби вона докладає до вашого завдання значно більше зусиль. Саме тому ми можемо встановити для Engine ціну за токен на рівні базової моделі: клієнт платить не за більший бюджет, а за коротший шлях до правильної відповіді.

Розробники ШІ дедалі більше переймаються витратами на інференс, адже моделі міркування генерують дедалі довші ланцюжки токенів. Як ви вважаєте, чи може підвищення ефективності самого процесу міркування зрештою стати не менш важливим, ніж створення менших, швидших або дешевших окремих моделей?

Так, і я б сказав, що це вже важливіший важіль. Створення менших, швидших і дешевших моделей знижує ціну токена. Але ніхто не купує токени. Люди купують виконане завдання, а в епоху агентів кількість токенів на одне завдання різко зросла: під час виконання реального завдання з програмування модель міркування використовує мільйони токенів, і значна їх частина йде на повторне проходження вже пройденого шляху. Скорочення кількості токенів на завдання на 25% дає рівно стільки ж, скільки й зниження ціни на 25%, але цей ефект додається до кожного вдосконалення апаратного забезпечення, квантування й обчислювальних ядер. До того ж ми можемо застосувати цей підхід до будь-якої моделі з відкритими вагами, доступної на ринку.

У галузі є три важелі. Перший — кращі моделі, тобто навчання, а воно дороге. Другий — дешевші токени, чого можна досягти завдяки апаратному забезпеченню та обслуговуванню моделей; тут можливості всіх поступово зрівнюються, бо всі користуються однаковими графічними процесорами. Третій — менше токенів на завдання, що залежить від способу виконання інференсу й досі майже не досліджено. Досі масштабування означало збільшення моделей і подовження ланцюжків міркувань, причому в обох випадках від однієї моделі вимагалося виконати все в межах одного процесу. Ми вважаємо, що наступний напрям масштабування — колективний: кілька моделей міркують разом, розподіляючи між собою здатність до оцінювання, тож сам процес стає коротшим і надійнішим. Це інший тип масштабування, не пов’язаний зі збільшенням кількості параметрів чи обчислень під час тестування, і саме на нього ми робимо ставку. Ми називаємо це ставкою на взаємодію моделей, а не на кількість параметрів.

Fortytwo Engine сумісний з API OpenAI й водночас використовує моделі з відкритими вагами. Наскільки важливою була сумісність з наявними стеками розробки ШІ та наскільки легко розробникам перенести застосунок зі звичайного API для однієї моделі на архітектуру рою?

Сумісність має вирішальне значення. Екосистема агентів — агенти для програмування, середовища запуску, фреймворки й інструменти оцінювання — побудована на форматі API OpenAI. Тож для розробників, які користуються Fortytwo Engine, перехід не відрізняється від переходу до іншого постачальника інференсу: у сумісному застосунку, агенті, середовищі запуску чи сервісі зазвичай достатньо змінити конфігурацію — адресу кінцевої точки, ключ API та вибір моделі.

Змінюється поведінка, а не інтеграція. Різниця помітна під час тривалих агентних процесів, де витрати визначають кількість використаних токенів і точність із першої спроби: та сама модель у складі Engine виконує завдання швидше, використовує менше токенів і успішніше справляється з більшою їх кількістю. Раджу поставитися до цього як до заміни будь-якої іншої моделі: проведіть оцінювання, яке вже використовуєте для свого агента, порівняйте кількість токенів на завдання та частку успішно виконаних завдань і залиште той варіант, який покаже кращий результат.

Дякуємо за чудове інтерв’ю. Читачам, які хочуть дізнатися більше про ройовий інференс і про те, як оцінювання колегами може підвищити ефективність міркування, варто відвідати Fortytwo.