dola-seed-2-1-turbo-260628) は、2026年6月23日にByteDanceのSeedチームがリリースした本番運用向けのテキストモデルです(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 グループで利用できます。ほとんどのモデルと異なる点が1つあります — 深い思考がデフォルトで ON です。レイテンシーやコストに敏感な呼び出しでは、thinking: {"type": "disabled"} を明示的に渡してください(下の「深い思考の制御」を参照)。主な強み
本番環境向けの価格設定
$0.50 入力 / $2.50 出力、1M tokens あたり — 同世代の Seed 2.1 Pro の半額で、高頻度呼び出し向けに作られています。
ネイティブ対応の2つのエンドポイント
Chat Completions と Responses の両方をネイティブにサポートしています: イベントストリーム、推論アイテム、マルチターンの previous_response_id がすべて Responses 側で動作します。
制御可能な深い思考
思考スイッチに加え、reasoning_effort の段階(low と high では計測上の reasoning tokens が 4 倍異なります)により、タスクごとに思考量を配分できます。
2層キャッシング
暗黙的キャッシングは2回目のリクエストから自動的にキャッシュヒットし、Responses での連鎖呼び出しにおける明示的キャッシングは前回のコンテキスト全体にキャッシュヒットして、レイテンシをおよそ半減します。
モデル情報
検証済み機能マトリクス
APIYI の 2026 年 7 月 21 日時点の実測結果(公式の主張 vs 実際の動作):料金
課金メモ: 推論コンテンツは通常の出力 tokens として課金されます。だからこそ、タスクごとに推論の深さを見積もっておくべきです。チャージボーナスにより実質コストはさらに下がるため、チャージプロモーション をご覧ください。
深い推論の制御
このモデルで最も重要な点です: 深い推論はデフォルトでオンになっているため、1行の質問でもまず数百 tokens の推論が生成されます。テストでは、1文の自己紹介で 444 output tokens(そのうち 409 は推論)を消費し、非ストリーミングでは 7〜19 秒かかりました。実測した3つの思考レベル
キャッシュでコストを削減する
モデルはメカニズムの異なる 2 つのキャッシュ層をサポートしています — 混同しないでください。暗黙的キャッシュ(自動、両エンドポイント)
パラメータは不要です。長いプレフィックス(たとえば固定の system prompt)が繰り返されると、2回目のリクエストから自動的にヒットします。計測では、約2,600 tokens の system prompt で、2回目と3回目のリクエストは 2,360cached_tokens と報告されました。ヒットは usage.prompt_tokens_details.cached_tokens(Chat)または usage.input_tokens_details.cached_tokens(Responses)で確認できます。
明示的キャッシュ(Responses のみ、チェーンが必要)
明示的キャッシュを使う正しい方法はcaching: {"type": "enabled"} と previous_response_id を組み合わせたチェーン です。2ターン目で前回の response id を引き継ぐと、前のコンテキスト全体がキャッシュにヒットします(計測では、7,873 tokens が完全にキャッシュされ、レイテンシは 8s から 4s に短縮されました)。
コード例
チャット補完
レスポンス(ネイティブなマルチターン + 明示的キャッシング)
ベストプラクティス
- 推論オフを基本、オンは例外にする:
thinking: {"type": "disabled"}をデフォルト設定にして、本当に複雑なタスクのときだけreasoning_effortの階層に切り替えてください。簡単な質問で推論コストを払う必要はありません。 max_output_tokensに余裕を持たせる: 推論オンなら 3000+、高い階層なら 4000+ を確保し、推論が実際の回答を圧迫しないようにします。- 固定のシステムプロンプトを先頭に置く: 暗黙的なキャッシュはプレフィックスで一致します。変わらない部分を前に置いておけば、2回目のリクエストから自動的にコストを節約できます。
- 複数ターンでは Responses のチェーンを使う:
previous_response_idなら履歴の再送信を避けられ、明示的なキャッシュと組み合わせることで、長いコンテキストの会話でコストとレイテンシの両方を削減できます。 - エラー処理では 503 を扱う: モデル名の টাইポやグループ権限の不足があると、OpenAI で一般的な 404 ではなく 503(利用可能なチャネルなし)が返ります。再試行ロジックを 404 に結び付けないでください。
FAQ
なぜ、単純な質問は遅くて token を多く消費するのですか?
なぜ、単純な質問は遅くて token を多く消費するのですか?
理由は、深い推論がデフォルトで有効だからです。たとえ1行の質問でも、最初に数百の推論 token(測定値は約400)を生成します。遅く、コストも高くなります。リクエストボディに
"thinking": {"type": "disabled"} を追加してください。測定される推論 token は 0 になります。Responses が空のテキストで不完全な結果を返すのはなぜですか?
Responses が空のテキストで不完全な結果を返すのはなぜですか?
max_output_tokens が小さすぎて、推論が予算のすべてを使い切りました(incomplete_details.reason は length です)。予算を 1500 以上に増やすか、推論ティアを無効化するか下げてください。Chat Completions と Responses - どちらを使えばよいですか?
Chat Completions と Responses - どちらを使えばよいですか?
単発のやり取りや、自前で履歴を管理する場合は Chat Completions を使ってください(エコシステム互換性が最も広いです)。複数ターンの会話、明示的キャッシュ、または MCP tools には Responses を使ってください。明示的キャッシュと MCP は Responses 専用です。
明示的キャッシュを有効にしているのに cached_tokens が 0 のままなのはなぜですか?
明示的キャッシュを有効にしているのに cached_tokens が 0 のままなのはなぜですか?
明示的キャッシュには チェーン が必要です。2回目のターン以降は、前のターンの
previous_response_id を必ず渡してください。caching.enabled を使った独立した繰り返しリクエストでは、キャッシュヒットしません。さらに、暗黙のプレフィックスキャッシュも適用されなくなります。チェーンがアプリに合わない場合は、単に caching パラメータを外して暗黙のキャッシュに頼ってください。MCP はサポートされていますか?
MCP はサポートされていますか?
公式の機能一覧では、Responses API に MCP サポートが記載されています。APIYI のテストラウンドでは MCP は未確認でした(外部の MCP サーバーが必要です)— 本番利用前に低トラフィックで検証してください。
503 が返ってきました - サービスは停止していますか?
503 が返ってきました - サービスは停止していますか?
まずモデル名のスペルを確認してください。このモデルは、未知のモデル名に対して 404 ではなく 503(「利用可能なチャネルがありません」)を返します。名前が正しく、それでも 503 が続く場合は、グループ権限(このモデルには
default または svip が必要です)を確認するか、サポートにお問い合わせください。関連リソース
Chat Playground
Chat Completions エンドポイントをインタラクティブにデバッグ
Responses Playground
Responses エンドポイントをインタラクティブにデバッグ
Model Info
利用可能なすべてのモデルとグループを確認
API Manual
API 利用ガイドの完全版