DeepSeek V4-Flash-Vision-Exp добавляет поддержку изображений в API: что нужно изменить в вашем routing-слое

21 августа DeepSeek выпустил deepseek-v4-flash-vision-exp — первую модель платформы, принимающую изображения наряду с текстом. По бенчмаркам модель сохраняет паритет с V4-Flash на текстовых agent-задачах и приближается к Opus-4.8 по визуальным способностям. Для routing-команд строчка с бенчмарками наименее важна. Проблема возникает раньше — на уровне формата сообщений.

Что изменилось на уровне API

Идентификатор модели: deepseek-v4-flash-vision-exp. Base URL остался прежним — https://api.deepseek.com. Поддерживаются оба формата: OpenAI-совместимый /chat/completions и Anthropic-совместимый /anthropic/messages.

Изменение касается поля content. Текстовые запросы обычно передают content строкой:

{"role": "user", "content": "Summarize this document."}

Vision-запросы обязаны передавать content массивом типизированных блоков:

{
  "role": "user",
  "content": [
    {"type": "text", "text": "What does this chart show?"},
    {"type": "image_url", "image_url": {"url": "https://example.com/chart.png"}}
  ]
}

Любой прокси-middleware, который нормализует content до строки или обрабатывает только строковый вариант, отправит некорректный запрос и получит в ответ 400. Это касается тонких OpenAI-прокси, написанных до распространения мультимодальности, и любого кода шлюза с content = str(message) для логирования или оценки токенов.

Anthropic-совместимый endpoint использует другой формат image-блока: вместо image_url здесь блок image с объектом source, где type принимает значения base64, url или file. Если ваш routing-pipeline одновременно работает с DeepSeek и Claude, придётся обрабатывать два разных формата изображений в одном коде.

Три способа передачи изображений и их routing-последствия

DeepSeek поддерживает три способа отправки изображений, и выбор правильного для routing-слоя не очевиден из документации.

Inline base64 встраивает данные изображения прямо в тело запроса. Учитывается в лимите 48 МиБ на тело запроса, одно изображение — не более 32 МиБ. Минимальная задержка для одиночных запросов без предварительной загрузки, но тело запроса резко увеличивается и плохо сериализуется через rate-limited прокси.

External URL позволяет модели DeepSeek скачать изображение самостоятельно. URL — не более 8192 символов, изображение — не более 32 МиБ, загрузка должна завершиться за 60 секунд. Если изображения находятся за авторизацией или CDN с ограничениями для краулеров, запросы будут периодически падать. Удобно для публичных ресурсов, ненадёжно для URL с короткоживущей подписью.

Files API file_id оптимален, когда одно изображение используется в нескольких запросах или его размер превышает 32 МиБ. Загруженные через Files API файлы могут достигать 64 МиБ и не учитываются в лимите inline-тела. Недостаток: требуется шаг загрузки перед первым запросом, а file ID привязан к вашему аккаунту DeepSeek и не может передаваться через универсальный прокси с подменой учётных данных.

Максимум изображений на запрос — 600, общий размер — до 200 МиБ при использовании file ID (64 МиБ в остальных случаях). Изображения тарифицируются в токенах: DeepSeek нормализует каждое изображение до ~800×800 пикселей перед подсчётом, поэтому 5000×5000 и 1000×1000 стоят одинаково. Лимит — 384 токена на изображение.

Параметр detail как инструмент дешёвой предварительной фильтрации

Для входных данных типа image_url DeepSeek предоставляет поле detail со значениями low, high, original и auto. При detail: "low" изображение масштабируется до 512×512 пикселей до инференса — быстрее и дешевле, когда точность на уровне пикселей не важна.

Это практически значимо для routing. Если ваш pipeline перед обработкой классифицирует загруженный контент — форма это, график или фотография — можно запустить классификацию с detail: "low", а полное разрешение использовать только когда результат того требует. При большом объёме загрузок, где большинство — простые скриншоты или формы, разница в стоимости существенна.

detail: "high" и detail: "original" эквивалентны — оба сохраняют оригинальное изображение. detail: "auto" в текущей реализации равен original.

Что статус experimental означает для routing-политики

Суффикс exp здесь несёт смысловую нагрузку. У модели нет production SLA, DeepSeek не опубликовал tier по rate limit. Это означает: без fallback её нельзя использовать как прямую замену V4-Flash.

Рабочая политика: deepseek-v4-flash-vision-exp — основной маршрут для запросов, требующих обработки изображений, с fallback на другого vision-capable провайдера (Gemini 3.5 Flash или любую модель с поддержкой image_url) при 429, 503 или ошибке model-not-found. V4-Flash оставить как текстовый маршрут для тех же промптов — тогда при необязательной визуальной составляющей можно деградировать до текстового пути без ошибки.

Формат запросов до и после миграции

До (текстовый routing, работает с любой моделью):

response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[{"role": "user", "content": "Summarize this."}]
)

После (vision routing, модель должна быть vision-вариантом):

response = client.chat.completions.create(
    model="deepseek-v4-flash-vision-exp",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Summarize this document."},
            {"type": "image_url", "image_url": {"url": image_url, "detail": "low"}}
        ]
    }]
)

Изображения поддерживаются только в user-сообщениях. Изображения в system или assistant-сообщениях возвращают 400. Если ваш agent использует изображение в system prompt — например, фирменный заголовок или референсную схему — его нужно перенести в первый user-тёрн.

Что стоит отслеживать пользователям TheRouter

Vision-маршрутизация у DeepSeek пока в начальной стадии: автоматического определения наличия изображений в сообщении нет, модель нужно указывать явно. Разумный подход сейчас: на уровне шлюза проверять каждое сообщение, искать блоки с type: "image_url" или type: "image", и направлять такие запросы на deepseek-v4-flash-vision-exp или предпочтительного vision-провайдера.

Экспериментальный статус и неизвестный rate limit tier — весомые аргументы в пользу мультипровайдерного fallback, а не использования модели как стабильного основного маршрута. Полная таблица лимитов — в документации DeepSeek Vision.