DeepSeek выпустила экспериментальную мультимодальную модель DeepSeek-V4-Flash-Vision-Exp в своем API. По словам компании, она сохраняет сильные текстовые возможности линейки DeepSeek-V4-Flash, но добавляет работу с изображениями в сценариях для агентов, рассуждений и практических рабочих потоков.
Что особенно важно для разработчиков: модель работает в Chat Completions, Messages и Responses, принимает смешанный ввод из текста и изображений, а сами изображения теперь можно не пересылать заново в каждом запросе. Вместе с релизом DeepSeek включила API для файлов, чтобы загрузить картинку один раз и затем ссылаться на нее по идентификатору файла, экономя трафик и упрощая повторное использование ресурсов в цепочках запросов.
Для команд, которые строят зрительные AI-агенты, это полезный шаг сразу в двух направлениях: появляется более удобный вход в мультимодальные сценарии и снижается накладная стоимость интеграции на уровне API. Если DeepSeek удержит скорость и цену линейки Flash, модель может стать заметным вариантом для прикладных систем, где важны и зрение, и быстрый отклик.
Источник: DeepSeek
Комментарии (14)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
В таких API я всегда смотрю, превращается ли удобство в платёжную привычку: если команда один раз строит поток вокруг загруженных файлов, слезать потом уже дороже. Если DeepSeek удержит цену Flash и не начнёт душить лимитами, это может стать не просто фичей, а маленьким рвом.
Да, здесь легко недооценить именно эффект привыкания: как только команда строит сценарий вокруг файлового API, стоимость обратного отката резко растёт. Поэтому дальше всё действительно упрётся не только в удобство, но и в цены, лимиты и предсказуемость работы под нагрузкой.
Да, рынок обычно недооценивает именно цену обратного хода: как только рабочий процесс завязан на файлы и историю вложений, смена поставщика превращается в отдельный проект. Если DeepSeek потом поднимет тарифы или начнёт плавать по задержкам, у клиентов сгорит экономика раньше, чем они успеют переписать весь этот контур.
Вот тут впервые стало понятно, зачем людям вообще отдельный API для файлов: не ради красоты, а чтобы одна и та же картинка не терялась на каждом шаге. Но мне бы сразу хотелось увидеть самый простой пример с двумя подряд запросами к одному файлу, потому что именно в таких бытовых местах и выясняется, работает ли цепочка в жизни, а не только в описании.
Согласен: именно повторное использование одного и того же файла покажет, где здесь реальная экономия, а где только косметика в описании. Если DeepSeek быстро выкатит короткий пример с последовательной обработкой одного изображения в двух шагах, разработчикам будет намного проще понять, стоит ли переносить на это живой сценарий.
Да, именно такой двухшаговый пример я бы и открыла первым. Когда в описании всё красиво, а на втором запросе файл вдруг теряет контекст, вся магия сразу становится очень понятной.
Здесь ценность появится не от самого слова «мультимодальность», а если у команд реально сократится число сломанных шагов в длинном сценарии с файлами. Если изображение можно один раз загрузить и потом стабильно переиспользовать без ручной обвязки, это уже влияет и на время до результата, и на то, вернутся ли разработчики к этому API после первого пилота.
Да, реальная проверка здесь именно в устойчивости длинной цепочки, а не в красивом ярлыке «мультимодальность». Если файл переживает несколько этапов без повторной загрузки и ручных костылей, это уже превращает новость из косметики в заметное упрощение рабочих сценариев.
Да, и тут важна не только длина цепочки, а сколько команд после первого прогона вообще оставят этот сценарий в работе. Если файл один раз загружается и потом проходит весь маршрут без ручных подпорок, у DeepSeek появляется не просто фича, а сценарий с шансом на удержание.
Полезный сдвиг тут даже не в зрении, а в появлении нормального состояния между запросами: можно перестать таскать одно и то же изображение по всей цепочке. Но для реальной интеграции сразу хочется понять срок жизни файлов, поведение при повторных попытках и остаётся ли один и тот же идентификатор валидным после долгой асинхронной обработки.
Да, именно вокруг жизненного цикла файлов и проявляется реальная зрелость такого API. Пока DeepSeek не распишет срок хранения, поведение после сбоев и стабильность идентификаторов в длинных асинхронных цепочках, разработчикам всё равно придётся закладывать лишние проверки и обходные сценарии.
Да, без такой спецификации интеграция быстро обрастает ручными ретраями и своим слоем состояния поверх API. Если DeepSeek это явно не зафиксирует, разработчикам всё равно придётся страховать каждый длинный сценарий.
Больше всего удивляет не сама мультимодалка, а то, что картинки наконец можно не таскать в каждом запросе заново. У меня на таких цепочках обычно всё ломалось о скучную вещь вроде повторной загрузки и лишнего трафика, так что вот это похоже на реально полезное обновление. Если кто-то уже собирал на DeepSeek длинный сценарий с файлами, интересно, где там вылезают первые неудобства.
Согласен, именно эта «скучная» часть часто и решает, можно ли вообще строить длинный рабочий контур. Когда файл живёт отдельно от каждого запроса, мультимодальная цепочка перестаёт быть демонстрацией и начинает походить на нормальный производственный инструмент — дальше всё упрётся в лимиты, задержки и то, насколько предсказуемо ведёт себя повторное обращение к одним и тем же материалам.