dola-seed-2-1-turbo-260628)是字节跳动 Seed 团队于 2026 年 6 月 23 日发布的高频生产型文本模型(BytePlus 产品名 Dola-Seed-2.1-turbo),主打低成本、低延迟的企业级高并发场景,家族标称 256K 上下文。API易已完成双端点全量实测(15/15 用例通过),Chat Completions 与 Responses 均可直接调用。
API易已接入 Seed 2.1 Turbo:模型名
dola-seed-2-1-turbo-260628,default / svip 分组可用。与多数模型不同的是——该模型默认开启深度思考,对延迟和成本敏感的场景请显式传 thinking: {"type": "disabled"} 关闭(详见下方「深度思考控制」)。核心优势
生产级性价比
输入 $0.50、输出 $2.50 每 1M tokens,是同代 Seed 2.1 Pro 的一半价格,适合高频调用。
双端点原生支持
Chat Completions 与 Responses 均为原生适配:Responses 端事件流、reasoning item、多轮 previous_response_id 全部可用。
深度思考可控
thinking 开关 + reasoning_effort 分档(low/high 实测思考量差 4 倍),按任务精确控制思考成本。
双层缓存降本
隐式缓存自动命中(第 2 次请求即生效);Responses 端显式缓存链式调用可整轮命中、延迟约减半。
模型信息
实测能力矩阵
以下为 API易 2026 年 7 月 21 日的实测结果(官方能力声明 vs 实际表现):定价
价格说明:思考(reasoning)内容按输出 tokens 正常计费——这也是为什么建议按需控制思考深度。叠加充值加赠后实际成本更低,详见 充值优惠。
深度思考控制
这是使用本模型最重要的一件事:默认开启深度思考,即使一句话的简单问题也会先输出数百 tokens 的思考内容。实测一句话自我介绍消耗 444 输出 tokens(其中思考 409),非流式总耗时 7–19 秒。三种思考档位实测
缓存降本
模型支持两层缓存,机制不同,注意区分:隐式缓存(自动,两端点均有)
无需任何参数,相同长前缀(如固定的 system prompt)第 2 次请求即自动命中。实测约 2,600 tokens 的 system prompt,第 2/3 次请求cached_tokens 达 2,360。命中量可在响应 usage.prompt_tokens_details.cached_tokens(Chat)或 usage.input_tokens_details.cached_tokens(Responses)中查看。
显式缓存(仅 Responses,需链式调用)
显式缓存的正确姿势是caching: {"type": "enabled"} 配合 previous_response_id 链式调用:第 2 轮携带上一轮响应 id 时,上一轮全部上下文整体命中(实测 7,873 tokens 全量命中,耗时从 8 秒降到 4 秒)。
调用示例
Chat Completions
Responses(原生多轮 + 显式缓存)
最佳实践
- 默认关思考,按需开启:把
thinking: {"type": "disabled"}作为基线配置,只在复杂推理任务上换成reasoning_effort分档,避免为简单问题支付思考成本。 max_output_tokens给足余量:开思考时建议 3000+,high 档 4000+,防止正文被思考挤掉。- 固定 system prompt 放最前:隐式缓存按前缀匹配,把不变的内容放消息最前面,第 2 次请求起自动省钱。
- 多轮对话用 Responses 链式:
previous_response_id免去重发历史消息,叠加显式缓存后长上下文多轮的成本与延迟都显著下降。 - 错误处理留意 503:模型名拼写错误或分组无权限时返回 503(无可用渠道),不是 OpenAI 惯例的 404,重试逻辑请勿按 404 判断。
常见问题
为什么简单问题响应也很慢、tokens 消耗很高?
为什么简单问题响应也很慢、tokens 消耗很高?
因为模型默认开启深度思考。一句话问题也会先生成数百 tokens 的思考内容(实测约 400),既慢又费钱。在请求体加
"thinking": {"type": "disabled"} 即可关闭,实测关闭后思考 tokens 归零。Responses 返回 incomplete、正文是空的,怎么回事?
Responses 返回 incomplete、正文是空的,怎么回事?
max_output_tokens 太小,配额被思考内容吃满了(incomplete_details.reason 为 length)。把配额提到 1500 以上,或关闭/调低思考档位。Chat Completions 和 Responses 怎么选?
Chat Completions 和 Responses 怎么选?
单轮或自管历史的场景用 Chat Completions(生态兼容最广);多轮对话、需要显式缓存、或要用 MCP 工具的场景用 Responses——显式缓存和 MCP 仅 Responses 端支持。
开了显式缓存为什么 cached_tokens 一直是 0?
开了显式缓存为什么 cached_tokens 一直是 0?
显式缓存必须链式调用:第 2 轮起携带上一轮的
previous_response_id 才会命中。只开 caching.enabled 而每次独立发请求不会命中——而且此时连隐式前缀缓存也不生效。若不想改造成链式,直接去掉 caching 参数用隐式缓存即可。支持 MCP 吗?
支持 MCP 吗?
官方能力图声明 Responses API 支持 MCP 工具。API易本轮实测未覆盖 MCP 场景(需外部 MCP server),如有需求建议小流量验证后再上生产。
请求报 503 是服务挂了吗?
请求报 503 是服务挂了吗?
先检查模型名拼写。该模型对不存在的模型名返回 503「无可用渠道」而非 404,模型名正确但仍 503 时再考虑分组权限(本模型需
default 或 svip 分组)或联系客服。相关资源
Chat 在线调试
在 Playground 中直接调试 Chat Completions 端点
Responses 在线调试
在 Playground 中直接调试 Responses 端点
模型信息
查看所有可用模型及分组
API 基础手册
查看完整的 API 使用指南