deepseek-chat выводится из эксплуатации 24 июля: аудит routing-конфигурации, который каждый оператор AI-шлюза обязан завершить на этой неделе

Через семь дней — 24 июля 2026 года в 15:59 UTC — устаревшие алиасы deepseek-chat и deepseek-reasoner перестанут принимать запросы. Любое routing-правило, конфиг провайдера или жёстко прописанный вызов SDK, по-прежнему ссылающийся на эти имена, начнёт возвращать ошибки. Исправление — замена одной строки, но аудит, позволяющий найти все места, где эти строки встречаются в production AI-шлюзе, требует методичного подхода.

Это не предположение. Дата вывода из эксплуатации зафиксирована в официальном журнале изменений DeepSeek API с апреля и подтверждена на главной странице API. 90-дневный переходный период заканчивается.

Что именно меняется

При запуске V4 в апреле DeepSeek переключил два устаревших имени на soft-алиасы:

• deepseek-chat → deepseek-v4-flash (режим без рассуждений)
• deepseek-reasoner → deepseek-v4-flash (режим рассуждений)

После 24 июля оба алиаса будут удалены. Вызовы с этими идентификаторами моделей будут завершаться ошибкой — никакого тихого перенаправления на другой endpoint не произойдёт. Актуальные идентификаторы:

• deepseek-v4-flash — быстрая, экономичная модель, контекст 1M токенов; поддерживает оба режима через параметр thinking
• deepseek-v4-pro — 1,6T-параметрная frontier-модель; оптимизирована для сложных задач рассуждения, agentic-программирования и работы с длинным контекстом

Обе поддерживают интерфейсы OpenAI ChatCompletions и Anthropic API, контекст 1M токенов и параметр reasoning_effort, введённый в V4.

Почему это важно для AI-инженерных команд

Операционный риск — не в самой миграции: deepseek-chat → deepseek-v4-flash — это замена строки. Риск — в неполноте обнаружения: production-системы ссылаются на устаревший алиас в большем числе мест, чем ожидают инженеры.

Типичные источники скрытых ссылок на алиас:

• Записи в routing-таблице — конфиги шлюза или прокси, где имя модели используется как routing-ключ отдельно от вызова SDK
• Цепочки fallback — routing-политики, в которых deepseek-chat или deepseek-reasoner выступают «безопасным умолчанием»
• Слои кэширования — prompt cache с ключами вида (model, messages), где имя модели является частью ключа
• Дашборды наблюдаемости — отслеживание потребления, атрибуция затрат и пороги алертов, фильтрующие по имени модели; после дедлайна эти фильтры будут возвращать нулевые результаты без каких-либо предупреждений
• Нагрузочное тестирование и eval-стенды — любой benchmark или регрессионный тест, вызывающий устаревшие имена, сломается после 24 июля, маскируя реальные сбои оценки ошибками фикстур

Router/operator-угол: трёхуровневый аудит до четверга

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

Уровень 1 — конфигурация провайдера. Найдите в конфиге шлюза строки deepseek-chat и deepseek-reasoner. В большинстве router-ов это YAML-, TOML- или JSON-файл спецификации провайдера. Замените оба на deepseek-v4-flash (или deepseek-v4-pro для нагрузок, оправдывающих разницу в стоимости). Убедитесь, что base_url не изменился: https://api.deepseek.com.

Уровень 2 — политики fallback и routing. Проверьте каждое определение fallback. Если deepseek-reasoner был настроен как экономичный fallback для reasoning-нагрузок, убедитесь, что замена — deepseek-v4-flash с "thinking": {"type": "enabled"} и подходящим значением reasoning_effort ("low", "medium" или "high"). Режим рассуждений теперь является параметром запроса, а не алиасом модели.

Уровень 3 — клиенты нижнего уровня. Перечислите SDK-клиенты и агенты, обращающиеся к endpoint-ам DeepSeek напрямую, минуя шлюз. Сюда относятся coding-агенты — Claude Code, Cursor или OpenCode, — если они настроены на прямой доступ к DeepSeek с жёстко заданным именем модели. Проверьте все файлы .env, settings.json или конфиги провайдеров, которые читает каждый агент. Руководство по интеграции агентов DeepSeek подтверждает, что конфиги на уровне инструментов должны использовать новые идентификаторы моделей.

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

Если ваш routing-профиль TheRouter направляет какие-либо нагрузки к DeepSeek, действуйте на этой неделе:

1. Откройте конфиг провайдера и убедитесь, что указаны идентификаторы deepseek-v4-flash или deepseek-v4-pro, а не устаревшие алиасы.
2. Проверьте цепочку fallback — если deepseek-reasoner был fallback для reasoning-задач, замените его на deepseek-v4-flash и добавьте reasoning_effort: high в параметры запроса.
3. После обновления отправьте тестовый запрос к списку моделей, чтобы убедиться, что новые идентификаторы распознаются.
4. Поставьте напоминание на 23 июля как финальное окно проверки перед дедлайном.

Дедлайн 24 июля — не из тех, что присылают предупреждение, когда срок истёк. Запросы любого оператора, не завершившего аудит до 15:59 UTC в четверг, начнут завершаться ошибками без предупреждения.