Примерно месяц я пытался заменить проприетарные модели в нашем конвейере разработки моделями с открытыми весами.
Этот месяц я мог бы потратить на сам продукт. Я рискнул, потому что каждая специализированная роль в OwlMeans обращается к языковой модели. Изменение здесь сказывается на всём процессе разработки.
Тогда в нашем пресете сочетались модели Anthropic и OpenAI. Я пробовал GLM, Kimi, DeepSeek и Qwen через хостинг-провайдеров. Хотел понять, сможет ли другой пресет надёжно делать ту же работу.
Июньский эксперимент — не бенчмарк. Никакого преимущества OwlMeans по стоимости он не доказывает.
Наш конвейер дробит продукт на небольшие части. Роль работает над пользовательской историей, проектным решением или ограниченным изменением кода. Она получает контекст для этой работы, а не просьбу придумать всё приложение.
Мне казалось, что при таком устройстве сменить модели будет несложно. Если задача достаточно узкая, у модели, возможно, меньше шансов понять её неправильно.
Это была инженерная гипотеза, которую я мог проверить на собственной системе. И заодно соблазнительный крюк для основателя-одиночки. Казалось, что улучшения механизма пригодятся во всех будущих проектах, поэтому ещё один день настройки было легко оправдать.
Мне нужно было смотреть и на весь прогон, и на приложение, которое он выдал.
Пустые ответы
Первой проблемой стали рассуждения.
Некоторые модели расходовали на внутренние рассуждения весь бюджет токенов, отведённый на ответ, и не возвращали ничего пригодного. Роль кодера завершала запрос, а следующему этапу нечего было применять.
Сначала я пробовал отключить рассуждения настройкой, которую провайдер соблюдал не всегда, а потом поставил явные лимиты для затронутых ролей и подбирал их под каждую модель.
На это ушло больше внимания, чем обещало простое переключение пресета. Роли планирования и кодеру нужен был разный подход. Если настройка работала для одной модели, это ещё не значило, что её можно без опаски скопировать на остальные.
Следующей проблемой стал формат ответов. Наши этапы передают друг другу структурированные результаты. Ответ может казаться мне разумным и всё равно не пройти проверку по схеме, которую ждёт следующий шаг.
Там, где модель не могла надёжно вернуть нужную структуру, я добавил путь через вызов инструментов. Ещё я поменял то, как код движется по конвейеру. Агент стал работать с нужными фрагментами и патчами, а не гонять раз за разом целые файлы.
Эти изменения стали частью системы, которую мне приходилось поддерживать. Эксперимент уже перерос выбор модели из списка.
Провайдер посередине
Название модели не определяло всю среду выполнения.
От хоста зависело, какие возможности доступны и как ведут себя запросы. Я перебирал провайдеров и в итоге включил в экспериментальный пресет маршрутизацию OpenRouter и переключение на запасного провайдера при сбое.
Документация OpenRouter по маршрутизации между провайдерами объясняет, какие есть настройки для выбора и фильтрации хостов. Мой конвейер зависел от определённой формы ответа, так что эти настройки были важны. И всё равно мне пришлось проверять весь маршрут, которым я пользовался.
В конце концов я смог переключаться между пресетами и прогонять через них один и тот же проект, но к тому времени за этим переключением стояли лимиты на рассуждения, обработка ответов, извлечение кода и выбор провайдеров.
Приложение на выходе
В тех прогонах итоговые приложения в целом были похожи. Я замечал различия в CSS и изредка — добавления в интерфейс, о которых не просил.
Ещё я видел, как сильные модели приукрашивают маленькую задачу, когда мне нужна была буквальная реализация. Это наблюдение о моих задачах и моей конфигурации. Составлять по нему общий рейтинг моделей было бы опрометчиво.
Систему запускал я. И менее заметные различия доставались мне. Структурированный результат не проходил — требовалась ещё одна попытка. Патч не применялся — надо было с ним разбираться. Даже обычный шаг мог остановиться из-за несовпадения с провайдером.
На финальном скриншоте этой работы не видно.
Заменить модели значило взять на себя больше работы внутри конвейера.
У меня было неформальное сравнение по собственным замерам, но я не доверял ему настолько, чтобы делать из него общий вывод о производительности.
Модели были настроены по-разному. Поведение провайдера входило в результат. Из-за повторных попыток и шагов исправления то, как шёл прогон, значило не меньше, чем итоговый артефакт.
Для корректного сравнения понадобились бы чётко поставленная задача, одинаковые приёмочные проверки, единообразные замеры и отчёт о сбоях. А у меня после прогонов остались инженерные заметки.
Поэтому в этой редакции нет старого заголовка с цифрой. Публичный адрес остался прежним, чтобы старые ссылки не сломались.
Мне всё ещё нужно было решить, на что тратить время. Я мог и дальше настраивать экспериментальный пресет или вернуться к остальному продукту. Новые замеры помогли бы, только если бы касались решения, которое мне действительно предстояло принять.
Месяц настройки
У меня остался рабочий способ пробовать разные модели. А ещё я нашёл несколько допущений, которые прятались внутри конвейера: как роль рассуждает, как возвращает результат, сколько исходного кода получает и что происходит, когда отказывает её провайдер.
Для движка, который я строю, это полезное знание. Но оно не доказывает, что другому основателю стоит повторять тот же эксперимент.
Если бы я взялся за это снова, то раньше решил бы, когда остановиться. И прежде чем тратить ещё неделю на смену настроек, определился бы, какие типы сбоев мне нужно понять.
За этот месяц я лучше понял собственную систему. И этот же месяц я отнял у остального OwlMeans. Считать нужно и то и другое.
Отредактировано 15 октября 2026 года. Рассказ об июньском эксперименте сохранён. Поведение моделей и провайдеров с тех пор продолжает меняться; наблюдения выше относятся к тем прогонам.