Примерно месяц я пытался заменить наши проприетарные модели на open-weight.
Не во всей компании — только в машинном отделении. OwlMeans — это пайплайн разработки на основе AI: ты описываешь, чего хочешь, в форме пользовательских историй, а команда специализированных AI-ролей превращает их в полноценное фулстек-приложение, которое принадлежит тебе. Под капотом каждая из этих ролей обращается к языковой модели. Сегодня это связка моделей Anthropic и OpenAI — Claude тянет основную нагрузку, а OpenAI подключается для отдельных ролей. Этой конфигурации я доверяю. У неё есть и своя цена.
Так что я поставил очевидный эксперимент. У open-weight моделей выдался очень громкий год — к середине 2025-го лучшие open-weight LLM выходили из Китая: GLM, Kimi, Qwen и DeepSeek на равных бились с проприетарным фронтиром в кодинге. И стоят они в разы дешевле. Если бы я смог запустить свой пайплайн на open-weight без потери качества результата, математика становилась неотразимой.
Месяц я провёл, встраивая их, прогоняя бенчмарки и подкручивая настройки. Вот что произошло на самом деле — включая ту часть, которой я не ожидал и которая в итоге оказалась самой сутью.
Ставка: пайплайн должен сделать модель взаимозаменяемой
Вот что вообще заставило меня поверить, что это сработает.
OwlMeans не суёт модели расплывчатый prompt и не молится. Он разбивает проект на очень маленькие, узко очерченные задачи, каждая из которых выполняется с минимальным контекстом — одна пользовательская история, одно исправление, изменение в пределах одного файла. Роль бизнес-аналитика формулирует работу, архитектор её проектирует, роль разработчика реализует один срез, фиксер наводит порядок. Никто не просит одну модель «построить приложение». Её просят сделать одну маленькую, чётко заданную вещь.
У такого устройства есть тихий побочный эффект: чем меньше и чётче задача, тем меньше значит выбор модели. Когда контекст крошечный, а инструкция точная, почти любая компетентная модель приходит примерно в одно и то же место. Меньше пространства блеснуть — и меньше пространства уйти не туда. Именно поэтому наши затраты на токены остаются вменяемыми: исследования агентных циклов прямо говорят, что стоимость токенов растёт пропорционально квадрату контекста, который ты переоплачиваешь на каждом шаге, так что держать каждую задачу маленькой — это и есть разница между рабочим счётом и неконтролируемым.
Так что моя гипотеза была проста: если пайплайн уже превращает задачу в commodity, он должен превратить в commodity и модель. Меняешь проприетарную модель на GLM — и приложение, выходящее с другого конца, должно быть по сути тем же самым.
В основном я был прав. И это сыграло не так, как я надеялся.
Что сломалось первым: модели, которые слишком много думают
Путь к open-weight оказался совсем не гладким.
Первой стеной стали «думающие» модели. GLM, Kimi, Qwen — они рассуждают по умолчанию. Звучит отлично, пока ты не ставишь жёсткий потолок на вывод, а модель тратит весь свой бюджет на молчаливое рассуждение и возвращает ничего. Пустой контент. Роль кодера срабатывала, модель додумывалась ровно до токенного потолка и отдавала пустую строку. Пайплайн давился не-ответом.
Я выставил effort: none. Это молча игнорировалось. Модель продолжала думать.
Это не моя личная причуда — это грязный секрет reasoning-моделей в продакшене. Усилие на рассуждение, как метко сформулировано в одном хорошем разборе, — это ручка стоимости, а не качества: выкрути её — и ты можешь утроить токены на размышления ради пары пунктов в бенчмарке, а в нагрузку получишь сюрпризы в счетах и пустые выводы, когда рассуждение съедает место, где должен был жить твой ответ. Решение оказалось неэффектным: жёсткий, абсолютный потолок токенов на рассуждение для каждой роли, настроенный модель за моделью, чтобы размышления не уморили вывод голодом. Кодерам — короткий поводок на рассуждение; ролям планирования — побольше свободы. Универсальной настройки нет. Каждая модель хотела свою.
Второй стеной стал структурированный вывод. Мой пайплайн опирается на то, что модели возвращают чистый, валидный по схеме JSON, чтобы следующая стадия могла на него отреагировать. Проприетарные API сейчас отлично с этим справляются — строгий режим структурированного вывода OpenAI снижает частоту ошибок формата ниже 0,1%. Многие open-weight модели у многих провайдеров до этого не дотягивают. Они выдают некорректный JSON в заметной доле ответов, особенно на длинных выводах и вложенных схемах. Так что я перестал навязывать JSON шатким моделям и дал им использовать вызовы инструментов, а ещё переписал обработку исходников так, чтобы агент извлекал только релевантные фрагменты и применял patch-diff, а не переписывал файлы целиком. Меньше контекста — меньше шансов сломать формат. Это одно изменение сделало для надёжности open-weight больше, чем любая замена модели.
Третьей стеной стали сами провайдеры. Одна и та же open-модель ведёт себя по-разному в зависимости от того, кто её хостит — скорость, надёжность, и даже то, работает ли вообще структурированный вывод. Я прогнал через бенчмарки целую их кучу. Некоторые были великолепны. Некоторые проваливали валидацию схемы на каждом вызове. Некоторые обрезали вывод. Часть просто не могла отдавать нужные мне модели. В итоге я стал маршрутизировать через OpenRouter, который размазывает каждую модель по шестнадцати-двадцати с лишним нижележащим провайдерам и переключается между ними при сбоях, — и опёрся на его вариант :nitro, который сортирует провайдеров по чистой пропускной способности, чтобы отыграть скорость. К концу я мог переключать весь пайплайн между open-weight и проприетарным пресетом одним флагом и прогонять ровно один и тот же проект через оба.
Именно этот переключатель и позволил мне наконец сравнить их честно. А вот в сравнении и началось самое интересное.
Сюрприз: результат вышел практически таким же
Я ожидал, что open-модели выдадут заметно худший код. Они этого не сделали.
Поскольку пайплайн дробит всё на крошечные задачи, итог получался почти одинаковым у всех моделей. Та же структура, то же поведение, то же приложение. Различия были мелкими и почти эстетическими — в основном качество CSS и редкие украшательства. И вот что мне кажется по-настоящему забавным: более продвинутые модели грешили этим сильнее. Дай фронтир-модели маленькую, точную задачу — и она начинает творить: добавит в UI завитушку, которую никто не просил, решит, что твоей форме не хватало анимации. Haiku просто делает то, что нужно. Чем умнее модель, тем вероятнее она начнёт импровизировать ровно там, где импровизация совершенно не нужна.
Так что вопрос качества — тот самый, вокруг которого все рубятся в таблицах лидеров бенчмарков, — в основном растворился. И остались две оси — только две: цена и скорость.
И я бы сказал, что именно сюда честно и должна прийти вся эта индустрия. Нейтральные аналитические площадки уже разносят модели ровно по этим линиям — интеллект, скорость и цена как три разных столбца, — потому что как только интеллекта «достаточно» для задачи, реально живёшь ты со скоростью и ценой.
Где дешёвые модели перестают быть дешёвыми
На бумаге open-weight выигрывают по цене с разгромным счётом. Они стоят за токен долю того, во что обходится пресет из Anthropic и OpenAI. Ради этого вся затея и затевается.
Но цена за токен — это ловушка, и я в неё угодил прямиком.
На проприетарной стороне основную нагрузку тянут модели Anthropic — а Sonnet и Haiku реже ошибаются и делают inference быстрее, чем то, что я получаю через OpenRouter, даже с включённым Nitro. На один запрос разница в скорости не драматична. Но она накапливается. И настоящий налог — это ошибки: с open-weight пресетом агенту чаще приходится останавливаться и чинить. Тут плохой возврат JSON, там запутавшийся diff, retry, перепланирование. Каждое из этого — лишние токены и лишнее время по часам.
Это та математика, которую никто не выносит на страницу с ценами. Модель, которая в пять раз дешевле за токен, но вынуждена делать retry, на практике не дешевле в пять раз — 20% частота сбоев на шаг примерно удваивает твой счёт за токены, а в агентном цикле эти сбои накапливаются от шага к шагу. Вся индустрия тихо переучивает урок: дешёвые токены порождают бо́льшие счета, потому что retry съедают экономию заживо.
Ровно это я и наблюдал. Преимущество по цене на счётчике пережёвывалось циклом остановись-и-почини. И когда я сложил всё вместе — более медленный inference, лишние retry, перепланирование, — реальный разрыв между моим проприетарным и open-weight пресетами вышел около 5x. Не на бенчмарке. На настоящей работе, от начала до конца.
Чтобы было ясно, чего я не утверждаю: дело не в том, что open-weight плохи. Дело в open-weight в моём пайплайне, сегодня, на тех провайдерах, что я тестировал, с той настройкой, что я пока проделал. Что подводит меня к той части, в которой я уверен меньше всего.
Почему я пока не доверяю собственным цифрам
Вот неудобное признание. У меня есть число 5x. Я не вполне ему доверяю и считаю, что и тебе не стоит — не потому, что оно неверно, а из-за того, как такие вещи обычно измеряют.
Эпоха бенчмарков рушится у всех на глазах. Стандартные бенчмарки кодинга насыщены и загрязнены; весь 2025-й отрасль наблюдала, как табель успеваемости перестаёт отражать реальные способности. А ленивый шорткат, к которому все тянутся, — заставить сильную модель оценить вывод — сам по себе ненадёжен: LLM-as-judge показывает большой, чувствительный к порядку разброс на задачах кодинга. Просить одну фронтир-модель сказать, хорош ли код другой, — это не доказательство. Это vibe с доверительным интервалом.
Так что мой следующий ход — не очередной бенчмарк. Это посмотреть на реальный код, который эти модели навайбкодили, собственными глазами и по настоящим метрикам — собирается ли он, проходит ли тесты, поддерживаемый ли он, захотел бы я им владеть. Вполне возможно, что GLM и Kimi окажутся лучше по итоговому результату, когда я буду судить о реальном артефакте, а не о синтетической оценке. Возможно и то, что open-модели просто ещё не докручены — бюджеты на рассуждение и десяток мелких ручек почти наверняка нуждаются в подстройке под каждую модель, а я лишь поскрёб по поверхности. Моё честное ожидание: в тот момент, когда ты сходишь с синтетических бенчмарков и начинаешь сравнивать реальные выводы, вся картина становится мутнее, а не чище.
Я продолжу копать. Но месяц уже научил меня тому, что действительно важно, — и это не модель.
Урок, который стоит больше результата
Отступи на секунду от таблицы лидеров.
Всё, что сделало open-weight пригодными в моём пайплайне — потолки на рассуждение для каждой модели, чтобы размышления не уморили вывод голодом, откат на вызовы инструментов для шаткого JSON, извлечение фрагментов и patch-diff, ужимающие контекст, переключение между провайдерами и маршрутизация по пропускной способности, назначение моделей по ролям, — ничто из этого не модель. Это структура вокруг модели. Это месяц неэффектной инженерии, которая лежит между «дешёвые токены существуют» и «ты выкатил работающий софт».
В этом, по сути, и весь продукт. Coding-агент — это coding-агент, а не команда разработки софта. Модель — это commodity; ты можешь заменить её завтра, и после этого месяца я могу точно сказать тебе, сколько эта замена реально даёт. Ценность никогда не была в модели. Ценность — в пайплайне, который заставляет любую модель выдавать код, которым ты можешь владеть и который можешь поддерживать, и который поглощает retry, сбои формата, настройку под каждую модель, чтобы ты не платил за них своими выходными.
Это то же обещание, которое OwlMeans даёт клиентам, и я только что потратил месяц, доказывая его себе изнутри: OwlMeans — это команда вокруг агента. Ты описываешь свой продукт в виде пользовательских историй. Пайплайн разбивает его, прогоняет, чинит и отдаёт тебе типизированное монорепо, которое принадлежит тебе, — код, который ты продолжаешь развивать любым агентом по вкусу. Стоимость предсказуема в расчёте на историю, потому что предсказуемой её делает именно пайплайн.
Ты можешь пропустить мой месяц
Так что вот честное предложение, и я сделаю его так, как хотел бы, чтобы сделали мне.
Если ты вайбкодишь настоящий продукт, ты столкнёшься ровно с этим вопросом — какая модель, какой провайдер, как удержать счёт без того, чтобы результат развалился. Ты можешь сделать то, что сделал я: потратить недели на сшивание пресетов, обнаружить, что effort: none — это ложь, смотреть, как твои дешёвые токены испаряются в retry, и выяснять для каждой модели, что на самом деле правда. Для меня это того стоило, потому что строить этот движок — и есть моя работа.
Это не твоя работа.
Ты можешь дать пайплайну, который уже отвоевал эту битву, сделать всё за тебя — подобрать экономику модели, съесть retry, обеспечить структуру и вернуть тебе код, которым можно владеть и который можно поддерживать, с предсказуемой стоимостью в расчёте на историю. Вот в чём предложение. Я сжёг месяц и кучу токенов, чтобы найти этот 5x. Ты можешь просто получить пайплайн.
Если задача — сэкономить время и токены на вайбкодинге, то это самый дешёвый месяц R&D, который тебе никогда не придётся пройти.
OwlMeans — это пайплайн разработки на основе AI: опиши, чего хочешь, в виде пользовательских историй и получи фулстек-приложения, чат-ботов, AI-агентов и пайплайны данных — типизированные, готовые к SSO и принадлежащие тебе, чтобы продолжать развивать их любым агентом. Посмотри, на что он способен →