StepFun Step 3.7 Flash на DashScope: нестандартные поля, которые обязан обрабатывать ваш routing-прокси

Когда новая модель появляется на DashScope, routing-вопрос редко сводится к «стоит ли её использовать?». Важнее другое: «корректно ли мой прокси обрабатывает её API-поверхность?» Step 3.7 Flash от StepFun, добавленный 29 мая, вводит переключатель thinking-режима, который находится за пределами стандартной схемы OpenAI chat completions — и именно в этом зазоре routing-прокси тихо ломаются.

Что произошло

Alibaba Cloud Model Studio добавила stepfun/step-3.7-flash в каталог DashScope 29 мая 2026 года. Модель поставляется напрямую от StepFun (阶跃星辰) и позиционируется как «новый флагман Flash-уровня» с улучшениями в поиске, agent-задачах, кодировании и мультимодальном понимании.

Модель доступна через стандартный OpenAI-совместимый endpoint DashScope:

base_url: https://dashscope.aliyuncs.com/compatible-mode/v1
model: stepfun/step-3.7-flash

Ключевое поведение API: thinking-режим отключён по умолчанию. Чтобы включить его, вызывающая сторона должна передать enable_thinking: true внутри extra_body. При включении модель возвращает ход рассуждений в поле reasoning_content дельты — отдельно от стандартного поля content. Глубину рассуждений можно контролировать через параметр reasoning_effort со значениями low, medium или high.

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

Паттерн extra_body — это способ, которым DashScope (и ряд других китайских provider) передают специфичные для модели параметры, не имеющие аналогов в спецификации OpenAI. При прямом вызове через OpenAI SDK это работает нормально — SDK передаёт поля extra_body в тело запроса без валидации. Но в routing-слоях это создаёт специфический режим отказа.

Большинство OpenAI-совместимых routing-прокси отбрасывают или игнорируют неизвестные поля верхнего уровня запроса. Если ваш прокси пересылает тело запроса, но отбрасывает содержимое extra_body, модель получает вызов без enable_thinking: true, молча откатывается в режим без мышления и возвращает ответ, который выглядит корректным, но не содержит ожидаемого приложением хода рассуждений. Ошибки нет — просто другое поведение модели.

Поле reasoning_content на стороне ответа создаёт симметричную проблему. Если ваш прокси нормализует ответы до стандартной схемы OpenAI перед пересылкой клиентам, он может полностью отбросить reasoning_content. Приложения, разбирающие дельту в поисках хода рассуждений, получат пустые строки.

Это не специфическая проблема StepFun. Тот же паттерн применяется к моделям Qwen3 (enable_thinking, thinking_budget), DeepSeek V4 (thinking.type, reasoning_effort) и другим моделям на DashScope, которые открывают управление thinking-режимом через нестандартные поля. Step 3.7 Flash — последнее пополнение этого класса.

Угол router/operator

Для команд, маршрутизирующих запросы между моделями на DashScope, Step 3.7 Flash вводит точку принятия решений, выходящую за рамки выбора модели:

1. Проверьте обработку extra_body в вашем прокси. Если между приложением и DashScope стоит routing-слой, протестируйте, выживают ли поля extra_body при прохождении через него. Отправьте запрос с enable_thinking: true и проверьте, появляется ли reasoning_content в потоковых дельтах ответа. Если нет — прокси молча отбрасывает thinking-переключатель.

2. Решите, открывать ли thinking-режим вызывающим сторонам или управлять им на уровне routing. Есть две рабочие архитектуры: позволить вызывающим сторонам передавать enable_thinking напрямую (требует прозрачной передачи extra_body прокси) или инжектировать enable_thinking: true на уровне routing-слоя для конкретных маршрутов на основе классификации задач. Второй подход даёт централизованный контроль, но требует, чтобы routing-конфиг знал, какие модели поддерживают это поле.

3. Обрабатывайте reasoning_content при нормализации ответов. Если ваш прокси нормализует потоковые ответы, добавьте явную обработку reasoning_content в объектах дельты. Решите, пересылать ли его клиентам, отбрасывать или логировать отдельно для observability. Молчаливое отбрасывание — худший исход: оно делает отладку поведения thinking-режима невозможной.

4. Рассматривайте thinking-режим как routing-сигнал, а не просто функцию модели. Step 3.7 Flash с reasoning_effort: high ведёт себя иначе, чем Step 3.7 Flash с отключённым мышлением — разная latency, разная стоимость токенов, разное качество вывода. Если вы маршрутизируете по сложности задачи, thinking-переключатель фактически является второй routing-размерностью внутри одной модели. Задача, требующая Flash-уровня, но глубокого рассуждения, может использовать reasoning_effort: high; latency-чувствительная задача на той же модели может оставить мышление выключенным.

5. Региональное ограничение: только Пекин. Документация DashScope указывает, что stepfun/step-3.7-flash сейчас доступен только в регионе China North 2 (Пекин) и требует API-ключа пекинского региона. Если ваша routing-политика охватывает несколько регионов DashScope, эта модель не может использоваться как глобальный fallback — ей нужно отдельное routing-правило для конкретного региона.

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

Проблема прозрачной передачи extra_body — хороший тест-кейс для любого routing-слоя. Если вы оцениваете, корректно ли ваш текущий прокси обрабатывает расширенную параметрическую поверхность DashScope:

• Отправьте тестовый запрос к stepfun/step-3.7-flash с extra_body: { enable_thinking: true } и убедитесь, что в потоковом ответе появляется reasoning_content.
• Если нет — проверьте, есть ли в вашем прокси явная настройка прозрачной передачи extra_body, или нужно ли «уплощить» thinking-параметры в тело запроса верхнего уровня для этого provider.
• Для production routing-политик рассматривайте thinking-mode модели как отдельный tier: при включённом мышлении выше стоимость токенов, выше latency, другая схема ответа. Маршрутизируйте к ним явно для задач, которым нужно расширенное рассуждение, а не как замену стандартным Flash-вызовам.

Более широкая закономерность: экосистема китайских provider сходится к общей API-поверхности thinking-режима — enable_thinking, reasoning_content, reasoning_effort — но имена полей и их расположение достаточно различаются между provider, чтобы каждый требовал явной, отдельной обработки в routing-конфиге. Step 3.7 Flash — последняя модель, пополнившая этот список, и, вероятно, далеко не последняя.