Skip to main content
Seed 2.1 Turbo (dola-seed-2-1-turbo-260628) — это текстовая модель промышленного уровня, выпущенная командой Seed ByteDance 23 июня 2026 года (название продукта BytePlus: Dola-Seed-2.1-turbo). Она нацелена на корпоративные нагрузки с низкой стоимостью и низкой задержкой при высоком объеме запросов, с контекстным окном 256K, заявленным для всей линейки. APIYI полностью проверила оба эндпоинта (15/15 тестовых случаев пройдены) — Chat Completions и Responses оба готовы к вызову.
Seed 2.1 Turbo уже доступен на APIYI: название модели dola-seed-2-1-turbo-260628, доступна в группах default / svip. Есть одно отличие от большинства моделей — глубокое рассуждение включено по умолчанию. Для вызовов, чувствительных к задержке или стоимости, явно передавайте thinking: {"type": "disabled"} (см. «Управление глубоким рассуждением» ниже).

Key Strengths

Цены уровня production

$0.50 за вход / $2.50 за выход на 1M tokens — вдвое дешевле, чем Seed 2.1 Pro того же поколения, рассчитано на частые вызовы.

Два нативных эндпоинта

И Chat Completions, и Responses нативно поддерживаются: потоки событий, элементы рассуждения и многотуровый previous_response_id все работают на стороне Responses.

Управляемое глубокое рассуждение

Переключатель рассуждения плюс уровни reasoning_effort (при low и high измеряемое количество tokens рассуждения отличается в 4 раза) позволяют закладывать бюджет на рассуждение для каждой задачи.

Двухуровневое кэширование

Неявное кэширование автоматически срабатывает со 2-го запроса; явное кэширование в Responses при цепочке вызовов захватывает весь предыдущий контекст и примерно вдвое снижает задержку.

Информация о модели

Проверенная матрица возможностей

Измеренные результаты APIYI на 21 июля 2026 года (официальные заявления против фактического поведения):

Тарифы

Примечание по тарификации: содержимое рассуждения тарифицируется как обычные output tokens — именно поэтому вам следует закладывать глубину рассуждения под каждую задачу. Бонусы за пополнение дополнительно снижают эффективную стоимость, см. Акции пополнения.

Управление глубоким размышлением

Это самое важное свойство этой модели: глубокое размышление включено по умолчанию, поэтому даже один вопрос сначала порождает сотни token рассуждения. В наших тестах одно предложение самопредставления расходовало 444 output tokens (409 из них — рассуждение) и занимало 7–19 секунд без streaming.
Для нагрузок, чувствительных к задержке или стоимости (боты поддержки, частые короткие Q&A, пакетные задачи), явно передавайте "thinking": {"type": "disabled"}. Измеренный результат: token рассуждения падают до нуля, а ответы становятся значительно быстрее.

Три уровня мышления, по измерениям

Дайте max_output_tokens запас: рассуждение учитывается в бюджете вывода. В Responses небольшой бюджет полностью съедается размышлением, и вызов возвращает status: "incomplete" (reason: length) с пустым текстом — это выглядит как отсутствие вывода, но на самом деле проблема в бюджете. Начните с 1500 и используйте 4000+ для высокого уровня.

Снижение затрат с кэшированием

Модель поддерживает два уровня кэширования с разной механикой — не путайте их:

Неявное кэширование (автоматическое, оба эндпоинта)

Параметры не нужны: повторяющийся длинный префикс (например, фиксированный system prompt) автоматически попадает в кэш со 2-го запроса. Измерено: при system prompt длиной около 2 600 token запросы 2 и 3 показывали 2 360 cached_tokens. Проверяйте попадания в usage.prompt_tokens_details.cached_tokens (Chat) или usage.input_tokens_details.cached_tokens (Responses).

Явное кэширование (только Responses, требует chaining)

Правильный способ использовать явное кэширование — caching: {"type": "enabled"} в сочетании с chaining по previous_response_id: когда на втором ходе передается предыдущий response id, весь предыдущий контекст попадает в кэш (измерено: 7 873 token полностью закэшированы, задержка снизилась с 8 с до 4 с).
Включение без chaining проигрывает по обоим направлениям: при установленном caching.enabled, но без previous_response_id, простое повторение того же префикса дает cached_tokens, равный 0, каждый раз — и кэш неявного префикса тоже перестает применяться. Либо не указывайте параметр кэширования и полагайтесь на неявное кэширование, либо включите его и строго используйте chaining.

Примеры кода

Chat Completions

Responses (встроенные многораундовые диалоги + явное кэширование)

Лучшие практики

  1. Thinking off как базовый режим, on — только по исключению: сделайте thinking: {"type": "disabled"} конфигурацией по умолчанию и переключайтесь на уровни reasoning_effort только для действительно сложных задач — не платите за thinking на простых вопросах.
  2. Оставляйте запас для max_output_tokens: 3000+ при включенном thinking, 4000+ на высоком уровне, чтобы reasoning не вытесняло сам ответ.
  3. Ставьте фиксированные системные prompts первыми: неявное кэширование сопоставляет по префиксу — держите неизменяемую часть в начале и автоматически экономьте деньги уже со 2-го запроса.
  4. Используйте цепочку Responses для многоходовых диалогов: previous_response_id позволяет не отправлять историю заново, а в сочетании с явным кэшированием снижает и стоимость, и задержку в разговорах с длинным контекстом.
  5. Обрабатывайте 503 в логике ошибок: опечатка в имени model или отсутствие разрешения для группы возвращает 503 (нет доступного канала), а не привычный для OpenAI 404 — не привязывайте логику повторных попыток к 404.

Часто задаваемые вопросы

Потому что глубокое рассуждение включено по умолчанию. Даже однострочный вопрос сначала генерирует сотни reasoning tokens (~400 по измерениям) — это медленно и затратно. Добавьте "thinking": {"type": "disabled"} в тело запроса; измеренное число reasoning tokens снизится до нуля.
max_output_tokens слишком мал, и thinking израсходовал весь бюджет (incomplete_details.reason равно length). Увеличьте бюджет до 1500+ или отключите/уменьшите уровень thinking.
Используйте Chat Completions для одноходовых запросов или истории, которую вы ведете сами (наибольшая совместимость с экосистемой). Используйте Responses для многоходовых разговоров, явного кэширования или MCP tools — явное кэширование и MCP доступны только в Responses.
Явное кэширование требует цепочки: начиная со второго хода вы должны передавать previous_response_id предыдущего хода. Независимые повторные запросы с caching.enabled никогда не дают попадания в кэш — и неявный кэш префикса тоже перестает применяться. Если цепочка не подходит для вашего приложения, просто уберите параметр кэширования и полагайтесь на неявное кэширование.
Официальная таблица возможностей указывает поддержку MCP в Responses API. Тестовый прогон APIYI не охватывал MCP (для него нужен внешний MCP server) — проверьте при низком трафике перед использованием в production.
Сначала проверьте написание названия model. Эта model возвращает 503 («no available channels») вместо 404 для неизвестных названий model. Если название указано верно, а 503 сохраняется, проверьте разрешение вашей group (для этой model требуется default или svip) либо обратитесь в поддержку.

Связанные ресурсы

Chat Playground

Интерактивная отладка endpoint Chat Completions

Responses Playground

Интерактивная отладка endpoint Responses

Информация о модели

Просмотрите все доступные модели и группы

Руководство по API

Полное руководство по использованию API