dola-seed-2-1-turbo-260628) — это текстовая модель промышленного уровня, выпущенная командой Seed ByteDance 23 июня 2026 года (название продукта BytePlus: Dola-Seed-2.1-turbo). Она нацелена на корпоративные нагрузки с низкой стоимостью и низкой задержкой при высоком объеме запросов, с контекстным окном 256K, заявленным для всей линейки. APIYI полностью проверила оба эндпоинта (15/15 тестовых случаев пройдены) — Chat Completions и Responses оба готовы к вызову.
dola-seed-2-1-turbo-260628, доступна в группах default / svip. Есть одно отличие от большинства моделей — глубокое рассуждение включено по умолчанию. Для вызовов, чувствительных к задержке или стоимости, явно передавайте thinking: {"type": "disabled"} (см. «Управление глубоким рассуждением» ниже).Key Strengths
Цены уровня production
Два нативных эндпоинта
Управляемое глубокое рассуждение
Двухуровневое кэширование
Информация о модели
Проверенная матрица возможностей
Измеренные результаты APIYI на 21 июля 2026 года (официальные заявления против фактического поведения):Тарифы
Управление глубоким размышлением
Это самое важное свойство этой модели: глубокое размышление включено по умолчанию, поэтому даже один вопрос сначала порождает сотни token рассуждения. В наших тестах одно предложение самопредставления расходовало 444 output tokens (409 из них — рассуждение) и занимало 7–19 секунд без streaming.Три уровня мышления, по измерениям
Снижение затрат с кэшированием
Модель поддерживает два уровня кэширования с разной механикой — не путайте их:Неявное кэширование (автоматическое, оба эндпоинта)
Параметры не нужны: повторяющийся длинный префикс (например, фиксированный system prompt) автоматически попадает в кэш со 2-го запроса. Измерено: при system prompt длиной около 2 600 token запросы 2 и 3 показывали 2 360cached_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 с).
Примеры кода
Chat Completions
Responses (встроенные многораундовые диалоги + явное кэширование)
Лучшие практики
- Thinking off как базовый режим, on — только по исключению: сделайте
thinking: {"type": "disabled"}конфигурацией по умолчанию и переключайтесь на уровниreasoning_effortтолько для действительно сложных задач — не платите за thinking на простых вопросах. - Оставляйте запас для
max_output_tokens: 3000+ при включенном thinking, 4000+ на высоком уровне, чтобы reasoning не вытесняло сам ответ. - Ставьте фиксированные системные prompts первыми: неявное кэширование сопоставляет по префиксу — держите неизменяемую часть в начале и автоматически экономьте деньги уже со 2-го запроса.
- Используйте цепочку Responses для многоходовых диалогов:
previous_response_idпозволяет не отправлять историю заново, а в сочетании с явным кэшированием снижает и стоимость, и задержку в разговорах с длинным контекстом. - Обрабатывайте 503 в логике ошибок: опечатка в имени model или отсутствие разрешения для группы возвращает 503 (нет доступного канала), а не привычный для OpenAI 404 — не привязывайте логику повторных попыток к 404.
Часто задаваемые вопросы
Почему простые вопросы выполняются медленно и расходуют много token?
Почему простые вопросы выполняются медленно и расходуют много token?
"thinking": {"type": "disabled"} в тело запроса; измеренное число reasoning tokens снизится до нуля.Responses возвращает неполный ответ с пустым текстом — что произошло?
Responses возвращает неполный ответ с пустым текстом — что произошло?
max_output_tokens слишком мал, и thinking израсходовал весь бюджет (incomplete_details.reason равно length). Увеличьте бюджет до 1500+ или отключите/уменьшите уровень thinking.Chat Completions или Responses — что выбрать?
Chat Completions или Responses — что выбрать?
Явное кэширование включено, но cached_tokens остается 0 — почему?
Явное кэширование включено, но cached_tokens остается 0 — почему?
previous_response_id предыдущего хода. Независимые повторные запросы с caching.enabled никогда не дают попадания в кэш — и неявный кэш префикса тоже перестает применяться. Если цепочка не подходит для вашего приложения, просто уберите параметр кэширования и полагайтесь на неявное кэширование.Поддерживается ли MCP?
Поддерживается ли MCP?
Я получил 503 — сервис недоступен?
Я получил 503 — сервис недоступен?
default или svip) либо обратитесь в поддержку.