В мире искусственного интеллекта скорость — это не просто преимущество, это вопрос выживания. Для команд, разрабатывающих продукты на базе больших языковых моделей (LLM), каждый день простоя или задержки в интеграции новой модели может означать упущенное конкурентное преимущество. Классическая проблема, с которой сталкиваются почти все технологические компании, — это «очередь на доступ». Когда доступ к моделям привязан к прямым контрактам с провайдерами (такими как OpenAI, Anthropic или Google), процесс тестирования превращается в бюрократический лабиринт. Инженеры тратят дни на настройку API-ключей, написание обвязки и согласование ресурсов, прежде чем смогут просто проверить, работает ли новая модель лучше старой.
Компания Descript, известная своими инновационными платформами для редактирования видео и аудио с использованием ИИ, столкнулась с этой проблемой во время разработки своего агента по редактированию видео Underlord. До перехода на новую архитектуру тестирование новой модели занимало всего пару часов чистой работы, но требовало недели ожидания. Сегодня этот процесс занимает один-два часа, и никто не просит инженеров выделять время на рутинную настройку. В этой статье мы подробно разберем, как Descript перестроил свой рабочий процесс, какие технические решения они применили и что это значит для индустрии в целом.
01Проблема «очереди»: цена ожидания в инженерии
Чтобы понять масштаб проблемы, нужно взглянуть на старый процесс Descript. Ранее команда поддерживала три прямые интеграции с крупными провайдерами: OpenAI, Anthropic и Google. Для каждой из этих моделей они писали собственную логику переключения (fallback logic). На первый взгляд, это звучит как стандартная практика, но на практике это создавало серьезное узкое место.
Добавление новой модели в систему требовало от двух до четырех часов инженерных усилий. Это включает в себя настройку аутентификации, обработку ошибок сети, форматирование запросов и тестирование стабильности. Однако самая дорогая часть процесса была не в коде, а в ожидании. Чтобы выделить эти часы работы у инженеров, запрос нужно было объяснить, запланировать в их календаре и дождаться, пока у специалиста появится свободное окно. В результате перспективная новая модель могла «сидеть» в очереди неделю, прежде чем кто-либо узнал, стоит ли она усилий.
Это привело к тому, что команда Descript тестировала только те модели, которые были достаточно важными, чтобы прервать работу инженера. Менее очевидные или экспериментальные модели просто игнорировались. Это создавало искаженную картину рынка: команда видела только «большую тройку» и упускала из виду нишевые, но мощные решения, которые могли бы решить конкретные задачи лучше.
02Новый цикл оценки: от твита до результата за пару часов
Александр Мистратов (Aleks Mistratov), руководитель направления AI-продуктов в Descript, описывает новый рабочий процесс как радикально упрощенный. Раньше процесс был линейным и зависимым от людей. Теперь он стал событийно-ориентированным и автоматизированным.
«Я гуляю, я очень онлайн, и замечаю твит о выходе новой модели. Я захожу в Slack, пишу команду: "запусти оценки (evals) этой модели в OpenRouter" и оставляю ссылку. Через час-два у нас уже есть результаты наших тестов в нашей системе оценки», — делится Мистратов.
Ключевым элементом здесь является интеграция Claude Tag от Anthropic, которую Descript настроили специально для этого цикла. Когда сотрудник отправляет запрос в Slack, система автоматически запускает оценки модели в их собственной тестовой среде (harness). После завершения тестов система автоматически создает pull request (запрос на слияние кода), который человек просто просматривает и утверждает.
Что сделало этот процесс автоматизируемым? Главное изменение заключается в том, что попытка протестировать модель больше не требует предварительного создания интеграции с провайдером. Тестирование одной модели больше не означает открытие отношений с вендором, настройку новых API-эндпоинтов и написание нового кода подключения. Работа все еще существует (нужно запустить тесты, проанализировать результаты), но никто не должен «просить» кого-то об этом. Инженерное время больше не является ограничивающим фактором.
03Что изменилось в еженедельной оценке моделей
Переход на новую архитектуру привел к трем фундаментальным изменениям в культуре и процессах разработки Descript.
1. Выбор моделей стал эмпирическим
Раньше команда часто стандартизировала выбор модели рано и возвращалась к этому решению только тогда, когда что-то заставляло их это сделать (например, падение качества или рост цен). Теперь Descript измеряет новые релизы против своих собственных тестовых кейсов. Они меняют то, что отправляют в продакшн, только когда новая модель преодолевает определенный порог качества. Это переход от интуитивного выбора к выбору на основе данных.
2. Новые релизы перестали быть событиями
Раньше выход новой версии модели от Anthropic или OpenAI был большим событием, требующим мобилизации команды. Теперь переход от анонса до использования в продакшне занимает пару часов. Оставшиеся шаги — внутренние: запуск оценок, решение, превосходит ли модель текущую, добавление её в пикер моделей, развертывание. Большинство этих шагов зависят от структуры собственного кода Descript, а не от сложности подключения к модели.
3. Поле возможностей расширилось
Благодаря отказу от прямых интеграций, Descript больше не ограничен кругом крупных вендоров. Например, компания никогда не строила прямую интеграцию с xAI. Тем не менее, Grok 4.5 теперь работает в продакшене, добавленная тем же путем, что и любая другая модель. Это позволяет команде экспериментировать с инновациями от меньших или новых игроков на рынке, которые могут предложить лучшее соотношение цены и качества для специфических задач.
04Как Descript запускает модели, которые они выбирают
Важно подчеркнуть: использование единой шины для тестирования не означает, что вся нагрузка идет через один общий endpoint с приемкой всего, что приходит. Descript сохраняет высокий уровень контроля и надежности для продакшн-окружения.
Для моделей, которые команда решает оставить, Descript использует собственную ключевую инфраструктуру. Например, для развертывания open-weight моделей они используют Baseten. В этой схеме OpenRouter маршрутизирует запросы сначала в Baseten, а другие провайдеры настроены как резервные варианты (fallbacks). Эти резервные варианты меняют поставщика инференса, но оставляют модель неизменной. Таким образом, сбой у одного хостинг-провайдера не меняет то, какая модель отвечает на запрос, обеспечивая стабильность сервиса.
Мистратов дает короткий совет другим инженерам, которые рассматривают аналогичные изменения:
«Это гораздо проще, чем пытаться разобраться во всех этих разных подключениях. Вы делаете это один раз, а все остальное становится просто параметром».
Descript использует одну и ту же интеграцию как для тестирования новых моделей, так и для запуска тех, которые они оставляют. Тестирование — это способ найти модель. Конфигурация маршрутизации — это способ её запустить. Разделение этих двух процессов позволяет масштабировать эксперименты, не усложняя архитектуру.
05Технические детали и архитектура
Полная архитектура Descript, включая то, как они устанавливают приоритет поставщиков инференса для каждой модели, что происходит, когда провайдер деградирует во время трафика, и как выглядит их система дежурств (on-call) теперь, подробно описано в их кейс-стади. Однако можно выделить несколько ключевых технических принципов, которые делают эту систему устойчивой:
- Абстракция провайдера: Код приложения не знает о конкретных API-интерфейсах OpenAI или Anthropic. Он работает с абстрактным интерфейсом, который реализует OpenRouter. Это позволяет менять «движок» под капотом без переписывания бизнес-логики.
- Автоматизированные тесты: Тестовая среда (harness) настроена на запуск стандартизированных наборов данных. Это гарантирует, что сравнение моделей объективно, а не основано на субъективном впечатлении.
- Гибкая маршрутизация: Возможность быстро переключаться между провайдерами для одной и той же модели позволяет оптимизировать затраты и надежность в реальном времени.
06Что это значит на практике
История Descript — это не просто история об одном продукте. Это пример того, как правильно выстроенная инфраструктура может ускорить инновации. Для команд, работающих с ИИ, это означает несколько важных выводов:
- Снизьте барьер входа для экспериментов. Если тестирование новой модели требует недели подготовки, вы будете тестировать только самые очевидные варианты. Сделайте тестирование быстрым и дешевым, и вы откроете для себя скрытые возможности.
- Автоматизируйте рутину. Использование инструментов, которые автоматически запускают тесты и создают pull request, освобождает инженеров от рутины и позволяет им сосредоточиться на анализе результатов.
- Разделяйте тестирование и продакшн. Используйте гибкие шлюзы для тестирования, но сохраняйте контроль над продакшн-инфраструктурой. Это позволяет экспериментировать без риска для стабильности сервиса.
- Доверяйте данным, а не интуиции. Эмпирический подход к выбору моделей позволяет принимать решения на основе реальных показателей, а не маркетинговых обещаний.
В конечном итоге, Descript показал, что «очередь» — это не неизбежное зло, а результат плохой архитектуры. Убрав эту очередь, компания не только ускорила разработку, но и расширила свой арсенал инструментов, получив доступ к более широкому спектру моделей, которые раньше были недоступны из-за логистических барьеров. Для любой компании, стремящейся оставаться на передовой AI-разработки, этот опыт является ценным руководством к действию.
Источник: OpenRouter ↗