Используйте любую* LLM с @mux/ai

*Почти любую.

Ещё в мае Джошуа из нашей команды Community Engineering сделал форк @mux/ai, чтобы дообучить собственную модель видеоинтеллекта. Он добавил Ollama, чтобы экспериментировать локально без оплаты токенов, добавил Baseten, чтобы обучать и размещать LoRA-дообучение Mistral Small 3.1, и подключил результат к рабочим процессам @mux/ai. Это отличный пост, но для этого ему понадобился форк SDK.

Когда мы запустили @mux/ai в декабре прошлого года, мы создали его как набор инструментов BYO-LLM, чтобы вы сохраняли контроль над тем, какие провайдеры видят ваш контент. Но «принесите своего» до сих пор означало «принесите своего хостинг-провайдера»: в первую очередь OpenAI, Anthropic или Google. Если вы запускаете собственную инфраструктуру инференса или ваши политики определяют, куда может отправляться ваше видео, этот список, вероятно, был вам не очень полезен, и мы хотели, чтобы @mux/ai тоже стал для вас вариантом.

Так почему же мы добавляем поддержку более широкого круга LLM сейчас? Всё довольно просто — open-weight models have improved dramatically, особенно мультимодальных. Развёртывать их тоже стало гораздо проще: такие провайдеры, как Baseten, обслуживают открытые модели через эндпоинт, совместимый с OpenAI, а если вы предпочитаете самостоятельный хостинг, vLLM и подобные говорят на том же протоколе, совместимом с OpenAI.

Пару недель назад мы выпустили в @mux/ai поддержку обоих (#205): первоклассного провайдера Baseten и универсального провайдера, совместимого с OpenAI, который работает с любым эндпоинтом, говорящим на протоколе OpenAI. Оба внутри построены на пакете @ai-sdk/openai-compatible из AI SDK.

Ссылка: используйте свой эндпоинт

Конфигурация одинакова для всех провайдеров: URL, ключ и модель. Вот универсальный вариант, указывающий на локальную Ollama:

Конфигурация для использования qwen3 с @mux

/ai

И затем рабочие процессы просто работают, точно так же, как с хостинг-провайдерами:

Использование провайдера, совместимого с OpenAI, в @mux

/ai

Или запуск моего любимого вопроса из конвейера модерации stream.new против Kimi K3 на Model APIs от Baseten:

Использование Baseten в @mux

/ai

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

Ссылка: почему два провайдера?

Итак, изначально план был только про Baseten. Форк Джошуа доказал, что интеграция работает (и что с её помощью легко создать что-то действительно ценное), Model APIs от Baseten дают вам каталог открытых моделей за одним эндпоинтом, а их выделенные развёртывания — отличное место для дообученной модели.

В процессе работы мы заметили, что на самом деле создаём не интеграцию с Baseten. Эндпоинты Baseten говорят на протоколе OpenAI, и примерно всё остальное в этой области тоже: vLLM, SGLang, Ollama, Together AI, Fireworks, OpenRouter и любой шлюз, который ваша платформенная команда развернула в прошлом квартале. Прямая работа с совместимым с OpenAI протоколом означала, что одна интеграция покрывает всё, поэтому мы выпустили её как отдельного провайдера, а Baseten оставили в качестве пресета поверх него. Пресет Baseten знает о формах URL Baseten и проверяет их, поэтому неправильно сконфигурированное развёртывание немедленно завершается с полезной ошибкой.

Ссылка: насчёт той звёздочки…

Вот мелкий шрифт: рабочие процессы @mux/ai требуют от модели больше, чем чат-приложение.

Во-первых, четырём рабочим процессам, которые анализируют кадры видео или раскадровки (getSummaryAndTags, askQuestions, hasBurnedInCaptions и generateEngagementInsights), нужна модель с поддержкой зрения. По умолчанию мы передаём модели URL раскадровки, и эндпоинт загружает его на своей стороне; если ваш эндпоинт не может загружать удалённые URL, переданные через параметр image_url (например, Ollama исторически не может), установите imageSubmissionMode: "base64", и мы вместо этого встроим изображение, открывая доступ к гораздо большему числу моделей.

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

Текстовые рабочие процессы (generateChapters, translateCaptions, editCaptions) гораздо менее привередливы: подойдёт почти любая модель со структурированными выводами и окном контекста приличного размера, включая текстовые открытые модели вроде DeepSeek V4 или gpt-oss.

Чтобы избавить вас от проб и ошибок, мы опубликовали заметки о том, какие модели мы проверили, а какие должны работать. Kimi K3, оба варианта Inkling и пара моделей Kimi K2 проверены на совместимость с @mux/ai на Model APIs от Baseten (по состоянию на август 2026 года). Семейство Mistral, Qwen3-VL, Llama 4 и некоторые другие заявлены их вендорами как способные к работе с изображениями, но мы сами их не проверяли, поэтому мы поставляем скрипт, который проверяет оба требования на живом эндпоинте, прежде чем вы доверите ему свой конвейер:

Запуск проверок моделей

Мы также не можем оценивать вашу модель за вас. Каждый хостинг-провайдер в @mux/ai поставляется с покрытием eval, чтобы вы знали, какое качество получаете; ваша дообученная Mistral на вашем собственном GPU невидима для нас, поэтому эти провайдеры исключены из eval-запусков, а оценка стоимости возвращает ноль (мы не знаем ваш счёт за GPU или насколько быстрый ваш GPU для расчёта задержки, и мы не собираемся гадать). Скрипт проверки говорит вам, что модель может запускать рабочие процессы; а хорошо ли она их запускает — это уже вопрос между вами и вашими eval.

В наших тестах открытые модели также имеют некоторые особенности надёжности, которых мы не видели у закрытых моделей, и мы столкнулись с одной из них на Inkling: примерно один запрос из двенадцати вырождался в вывод, обрезанный по лимиту токенов, который затем не проходил проверку схемы, даже при запрошенном json_schema и в остальном здоровом эндпоинте. Этот сбой не детерминирован: повторная отправка того же запроса почти всегда успешна, поэтому withRetry (который уже оборачивает каждый вызов модели в рабочих процессах) теперь считает ответ без вывода повторяемым. Отказы по контент-политике никогда не повторяются, по, надеюсь, очевидным причинам.

Ссылка: и наконец, тонкая настройка

Если вы хотите пойти дальше, пост Джошуа рассказывает, как дообучить собственную модель для этих рабочих процессов: LoRA-настройка Mistral Small 3.1 на синтетических данных рабочих процессов @mux/ai с помощью тренировочного SDK Baseten, а затем размещение её на выделенном развёртывании. Когда он писал это, требовался форк; теперь его развёртывание подключается напрямую к провайдеру baseten. В его сравнении дообученная модель давала более краткие и уверенные сводки, чем вывод LLM по умолчанию. Прочитайте. Это интересно!

Ссылка: попробуйте

@mux/ai полностью открыт под лицензией Apache 2.0, если вы забыли. Эта функция началась как форк Джошуа, и мы будем рады, если следующая начнётся как ваш:

Установка @mux

/ai

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