Близько місяця я намагався замінити пропрієтарні моделі в нашому конвеєрі розробки на моделі з відкритими вагами.
Цей місяць я міг би витратити на сам продукт. Я зробив цю ставку, бо кожна спеціалізована роль в OwlMeans викликає мовну модель. Зміна тут зачіпає весь процес розробки.
Тоді наш пресет поєднував моделі Anthropic і OpenAI. Я пробував GLM, Kimi, DeepSeek і Qwen через хостинг-провайдерів. Мені хотілося зʼясувати, чи здатен інший пресет надійно виконувати ту саму роботу.
Цей червневий експеримент — не бенчмарк. Перевагу OwlMeans у вартості він не доводить.
Наш конвеєр розбиває продукт на дрібні частини. Окрема роль працює над користувацькою історією, проєктним рішенням або обмеженою зміною в коді. Вона отримує контекст саме для цього завдання, а не прохання вигадати весь застосунок.
Я думав, що така структура може спростити заміну моделей. Якщо завдання досить вузьке, можливо, у моделі буде менше нагод його неправильно зрозуміти.
Це була інженерна гіпотеза, яку я міг перевірити на власній системі. А для засновника-одинака — ще й спокусливий привід звернути з дороги. Удосконалювати механізм здавалося корисним для кожного майбутнього проєкту, тож виправдати ще один день налаштувань було легко.
Мені треба було дивитися на весь запуск, а не лише на застосунок, який він видав.
Порожні відповіді
Першою проблемою стали міркування.
Деякі моделі витрачали доступний ліміт вихідних токенів на внутрішні міркування й не повертали нічого придатного. Роль кодера завершувала запит, але наступному етапу не було чого застосовувати.
Я пробував вимкнути міркування налаштуванням, яке провайдер враховував не завжди. Потім поставив явні обмеження на ролі, яких це стосувалося, і підганяв їх під кожну модель окремо.
Це вимагало більше уваги, ніж обіцяло перемикання пресета. Роль планування й роль кодера потребували різного підходу. Налаштування, що спрацювало для однієї моделі, ще не було правилом, яке я міг би безпечно перенести на інші.
Наступною проблемою став формат відповіді. Наші етапи передають один одному структуровані результати. Відповідь, яка мені здається слушною, все одно може не пройти перевірку схемою, на яку розраховує наступний крок.
Там, де модель не могла надійно повернути очікувану структуру, я додав шлях через виклик інструментів. Ще я змінив те, як код рухається конвеєром. Агент працював із потрібними фрагментами й патчами, а не обробляв раз у раз цілі файли.
Ці зміни стали частиною системи, яку мені доводилося підтримувати. Експеримент уже переріс вибір моделі зі списку.
Провайдер посередині
Назва моделі ще не визначала всього середовища виконання.
Від хоста залежало, які функції доступні і як поводяться запити. Я тестував провайдерів і зрештою взяв для експериментального пресета маршрутизацію й резервне перемикання OpenRouter.
Документація OpenRouter про маршрутизацію між провайдерами пояснює, якими засобами можна вибирати й фільтрувати хости. Мій конвеєр залежав від конкретної форми відповіді, тож ці засоби мали значення. Увесь маршрут, яким я користувався, мені все ж довелося тестувати самому.
Нарешті я міг перемикатися між пресетами й проганяти через них той самий проєкт. Тільки на той час за цим перемиканням уже стояли обмеження на міркування, обробка відповідей, витягування коду й вибір провайдерів.
Застосунок на виході
У тих запусках застосунки на виході загалом були схожі. Я помічав відмінності в CSS і подеколи доповнення інтерфейсу, про які не просив.
Бачив я й те, як сильні моделі прикрашають невелике завдання, коли мені потрібна була буквальна реалізація. Це спостереження стосується моїх завдань і моєї конфігурації. Для загального рейтингу моделей це була б слабка підстава.
Мені як тому, хто керує системою, доводилося мати справу з менш помітними відмінностями. Невдалі структуровані результати вимагали нової спроби, а патчі, які не застосовувалися, — моєї уваги. Навіть звичайний крок міг зупинитися через неузгодженість із провайдером.
Фінальний скриншот цю роботу приховує.
Замінити моделі означало взяти на себе більше роботи всередині конвеєра.
У мене було неформальне порівняння з власного обліку. Проте я не довіряв йому настільки, щоб перетворювати його на загальне твердження про продуктивність.
Моделі були по-різному налаштовані. Поведінка провайдера була частиною результату. Через повторні спроби й кроки виправлення шлях, яким ішов запуск, важив не менше за кінцевий артефакт.
Для коректного порівняння знадобилися б чітко визначене завдання, однакові перевірки приймання, послідовний облік і задокументовані збої. Мої ж запуски дали мені інженерні нотатки.
Тому в цій редакції немає колишнього заголовка з цифрою. Публічна адреса лишилася тією самою, щоб наявні посилання працювали й далі.
Мені все ще треба було вирішити, на що витрачати час. Я міг і далі налаштовувати експериментальний пресет або повернутися до решти продукту. Більше вимірювань допомогло б, лише якби вони стосувалися рішення, яке мені справді треба було ухвалити.
Місяць налаштувань
У мене лишився робочий спосіб пробувати різні моделі. Заодно я знайшов кілька припущень, що ховалися всередині конвеєра: як роль міркує, як повертає результат, скільки вихідного коду отримує й що відбувається, коли відмовляє її провайдер.
Для рушія, який я будую, це корисне знання. Але воно не доводить, що іншому засновникові варто повторювати такий самий експеримент.
Якби я робив це знову, то раніше визначив би умови зупинки. І вирішив би, які типові збої мені треба зрозуміти, перш ніж витрачати ще тиждень на зміну налаштувань.
За цей місяць я краще зрозумів власну систему. А решта OwlMeans через це втратила місяць. Записати треба і те, і те.
Переглянуто 15 жовтня 2026 року. Опис червневого експерименту збережено. Поведінка моделей і провайдерів відтоді не переставала змінюватися; спостереження вище стосуються саме тих запусків.