Переход с закрытых моделей на открытые вместе с Together

К счастью, переход с закрытых моделей на открытые разрушает традицию медленной и болезненной миграции, особенно если вы используете управляемый сервис. Такие сервисы успевают за темпами инноваций в сфере ИИ, одновременно снимая с вашего бизнеса большую часть сложностей.

Теперь радиус возможных сбоев стал намного меньше, а технологический стек, требующий миграции, — проще. Обвязки, шлюзы и инструменты созданы с расчетом на работу с самыми разными моделями. Вы можете извлечь из этого максимум выгоды для быстрого и комплексного перехода с закрытых моделей на открытые.

Мы расскажем о стратегии успешной миграции, которую мы наблюдаем у наших клиентов. Это может занять от нескольких недель до месяцев, а не от месяцев до лет. В будущем мы также предоставим материалы, которые помогут вам отслеживать свой прогресс на каждом этапе.

Это лишь общий обзор. Мы подготовим подробные разборы для каждого раздела, где, по нашему мнению, требуется больше деталей, включая рабочие материалы, примеры и пошаговые руководства.

Поиск

Когда вы начинаете искать модели-кандидаты, самое главное — четко понимать, что именно вы оцениваете. Ни одна модель не является универсально лучшей во всем. Разные модели имеют свои сильные стороны в различных областях, и чем лучше вы определите проблемы, которые хотите решить, тем проще будет составить шорт-лист моделей, которые действительно вам подойдут. Начните с описания вашего варианта использования и рабочей нагрузки простыми языком: какие задачи решает модель, как выглядит хороший ответ и из чего на самом деле состоит ваш трафик.

После определения варианта использования существующие бенчмарки становятся полезным инструментом фильтрации. Определите те бенчмарки, которые наиболее актуальны для вашей работы, чтобы показатели в таблицах лидеров коррелировали с результатами выполнения ваших задач. Хорошими источниками бенчмарков являются The Open Frontier, Artificial Analysis, Epoch AI, Vals AI, таблицы лидеров Scale, Intelligence и Arena. Среди них вы можете найти полезными следующие бенчмарки:

• Агенты для написания кода: FrontierCode, DeepSWE, Terminal Bench 4

• Работа в режиме чата и общего ассистента: LMArena, AA-Intelligence Index

• Агенты и использование инструментов: τ-bench, Agent Arena

• Зрение: Vision Arena

Помните, ваша задача — определить, какие из них актуальны для вас, чтобы сузить круг моделей-кандидатов. О кастомных оценках мы поговорим позже. Как правило, вы обнаружите, что для выбора доступны три уровня моделей, как показано выше.

Для основных кандидатов выходите за рамки простой производительности. Оцените стоимость одной задачи, количество токенов, расходуемых моделью на одну попытку, количество необходимых шагов, сквозное время выполнения (end-to-end runtime) и то, как быстро вы можете проверить правильность ответа. Сейчас множество новых бенчмарков сообщают эти показатели для каждой задачи, и мы считаем, что они лучше коррелируют с реальной стоимостью и производительностью моделей. Модель, которая набирает на несколько баллов меньше, но выполняет задачи, используя вдвое меньше токенов и времени, может подойти лучше.

Наконец, проведите практическое тестирование. Возьмите несколько репрезентативных задач в песочницу (playground) и посмотрите, ведут ли себя отобранные модели должным образом. Следите за типами сбоев и задавайте вопрос: сбоит ли сама модель или обвязка и контекст вокруг нее. Также стоит узнать, что говорят о своем опыте другие компании, использующие эти модели. После этого этапа у вас должно остаться от двух до трех моделей, готовых к серьезной оценке.

Оценка

Оценка моделей станет самой трудоемкой частью этого процесса и, безусловно, заслуживает отдельной статьи в блоге, но в общих чертах вы будете оценивать две вещи: точность и производительность.

Точность определяет возможности модели. Сюда может входить следование инструкциям, суммаризация, вызов функций (function calling), работа со зрением и т. д. Это всё, что модель способна делать независимо от того, где она запущена и насколько она быстра. Вам нужно оценить, способна ли она удовлетворить потребности вашей рабочей нагрузки.

Производительность охватывает то, насколько хорошо работает модель. Этот параметр меняется в зависимости от размера модели и ее архитектуры. Для этих тестов нам не важно, насколько хорошо модель отвечает на запросы. Мы оцениваем, соответствует ли она ожиданиям по стоимости, ощущениям пользователя (user-feel) или задержке (latency), необходимым для внедрения открытой модели.

Как для точности, так и для производительности вам потребуется придерживаться единого подхода: бенчмарки полезны для понимания общего направления, но реальные тесты проводятся на настоящих данных. Лучший способ оценить рабочую нагрузку — не искать или запускать общие бенчмарки. У рабочих нагрузок разные профили трафика, специфические требования к ответам и структуры запросов. Ни один бенчмарк не может отразить это так, как ваши собственные данные. К счастью, если вы уже используете закрытые модели, простой повтор (replay) существующего трафика — это все данные, которые вам нужны для бенчмаркинга. Никаких пользовательских наборов, никаких огромных датасетов. Это лучший способ тестирования (и всегда им был) еще до того, как мы начали тестировать современные передовые модели (HPC, базы данных, балансировку нагрузки и т. д.). Убедитесь, что вы все же проводите тестирование с учетом целей, определенных ранее.

Если у данных для повтора нет, это не тупик! Мы все равно можем сориентироваться по общим шаблонам использования, таким как размер ввода и вывода, а также ожидаемый коэффициент попаданий в кэш. Если провайдеры закрытых моделей не предоставляют эти метрики, помочь с их сбором могут такие шлюзы, как LiteLLM. Мы подробно обсудим этот метод в отдельной статье.

Получив данные, определите свои цели. Хотите ли вы сэкономить? Повысить скорость? Улучшить или сохранить качество? Когда вы заново прогоните свои данные на выбранных новых моделях, это и будет ваша целевая линия. Вы стремитесь достичь ее или превзойти. Когда открытые модели пересекают эту линию, вы получаете техническое подтверждение и можете переходить к полномасштабной миграции.

Инвестиции в надежные методы оценки позволят вашей команде в дальнейшем легко и быстро внедрять новые открытые модели. В следующей статье мы гораздо подробнее разберем, как оценивать объем рабочей нагрузки, перезапускать трафик и оценивать результаты. А пока это базовые принципы оценки открытых моделей.

Адаптация

Передовые открытые модели становятся настолько хороши, что обычно работают «из коробки» для большинства приложений, но если модель не прошла ваши тесты, ее придется адаптировать. Это не обязательно означает, что модель бесперспективна. Обычно это значит, что способ ее использования был настроен под другую модель: промпт, параметры сэмплирования, окружающая обвязка. Ваша инфраструктура закрытой модели накопила множество настроек, с которыми открытая модель никогда не сталкивалась, и, скорее всего, вам потребуется ее адаптировать.

У вас есть несколько рычагов влияния, примерно в порядке увеличения трудозатрат:

• Инженерия системных промптов: попробуйте давать модели инструкции иначе. Модели обучаются по-разному и могут требовать другого промптинга для работы на том же уровне, что и ваша текущая закрытая модель.

• Настройки инференса модели: параметры сэмплирования, такие как temperature и top_k, сохранение хода мыслей (preserved thinking) и глубина рассуждений (reasoning effort), могут существенно изменить поведение модели.

• Инженерия контекста и сама обвязка: навыки, инструменты и MCP-серверы, составляющие программное окружение, в котором работает модель.

• Веса модели посредством дообучения (fine-tuning) или дистилляции: самый сложный в реализации путь, поскольку он требует четко определенных оценок, подобранных данных и реальных экспериментов, но он может открыть узкоспециализированный домен и заставит небольшую модель работать значительно эффективнее своего веса.

Какие бы рычаги вы ни задействовали, рассматривайте этот процесс как итеративный цикл. Настраивайте эксперименты, изолирующие одно конкретное изменение, оценивайте его влияние и повторяйте итерации, пока не найдете то, что действительно улучшает результаты оценки. Ваши оценочные тесты должны быть модульными, а эксперименты — простыми. Если вы тестируете слишком много вещей и меняете слишком много переменных одновременно, вы никогда не сможете выделить то, что работает, на фоне мешающих факторов. Набор четко определенных оценочных тестов, о которых говорилось выше, — это самое главное для успешной итерации описанных выше адаптаций.

Принятие решения

Техническое обоснование — это полдела, как и при любой миграции. Как только вы доказали, что открытые модели (OSM) могут не уступать функциональности вашего текущего закрытого решения или превосходить ее, вам нужно упаковать эти результаты и донести суть («почему это нужно») до заинтересованных сторон.

Опишите объем работ, необходимый для перехода на OSM, возможные риски и окупаемость инвестиций (ROI).

Несколько общих рекомендаций, основанных на нашем опыте:

Трудозатраты определят реальный объем работы, необходимый для перехода на OSM. Иногда возникают вопросы совместимости средств тестирования и инструментов, но этот разрыв с каждым днем сокращается. Например, togetherlink, предоставляемый нами инструмент, позволяет легко начать использовать OSM в любых тестовых средах. Задокументируйте любые интеграции или изменения, которые потребуется сделать для полноценного использования OSM в масштабе.

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

Если вы дошли до этого этапа с правильно настроенными тестами, этот шаг может быть значительно упрощен, хотя вы все равно можете рассматривать его как цикл, который подпитывает этап оценки.

ROI можно рассчитать как количественно измеримую величину на основе этапа оценки. Сколько токенов вы можете генерировать на один доллар? Как это соотношение выглядит по сравнению с закрытыми решениями? В некоторых случаях при переходе клиентов на открытый исходный код мы наблюдаем снижение затрат до 70%. Вы можете сделать то же самое и для оценки качества: как качество соотносится с закрытыми решениями? Это поможет определить ROI для заинтересованных сторон.

В идеале, когда определены риски, трудозатраты и ROI, принять решение после этого не составит труда. Внедрение на данном этапе в большей степени связано с обучением, чем с техническими ограничениями.

Продакшн

С момента получения одобрения начинается миграция. Как уже упоминалось, традиционный переход в продакшн после миграции — это долгий и затянутый процесс. Тем не менее, при переходе с закрытых моделей на OSM мы обнаруживаем, что это на самом деле один из самых легких шагов.

Мы можем использовать опыт традиционной миграции, чтобы оценить ее влияние и составить дорожную карту. Во многом это можно основать на разделах обeffort (трудозатратах) и рисковитости из предыдущих шагов. Повлияем ли мы на нисходящие сервисы? Как пройти согласование модели у команд безопасности и комплаенса? Требуются ли какие-либо изменения в инструментах или сервисах, созданных поверх предыдущих моделей? Этот переход тоже не обязательно делать мгновенным. Отличные результаты у наших клиентов показали канареечные развертывания для проверки рабочих сценариев в продакшене, начиная с направления 10% трафика на открытый исходный код.

Дорожная карта включает в себя все шаги, необходимые для внедрения OSM. Сюда должны входить любые вопросы безопасности и комплаенса, изменения в технологиях или изменения в нисходящих сервисах, которые необходимо сделать. Не пугайтесь: техническая реализация может быть такой же простой, как замена эндпоинта!

Мы понимаем, что это очень упрощенный обзор, но в основе своей мы проходили через этот переход десятки раз с нашими крупнейшими клиентами и твердо уверены, что он гораздо менее обременителен, чем традиционная техническая миграция.

Если вы проходите через аналогичную миграцию, мы призываем вас следить за нашими будущими блогами или обращаться по адресу sales@together.ai с любыми вопросами. Мы также будем рады любым отзывам о том, что здесь могло быть упущено. Удачного создания проектов!