DeepSeek V4のレート制限：大量リクエストの本番運用パターン

こんにちは、Doraです。先週、ちょっとしたことで躓きました。メモアプリに新しいツールを組み込んでいたところ、無害なバッチプロンプトの処理中に429エラーが連発するのを見ていました。大したことではないのですが、作業の流れを断ち切るには十分でした。そのひと押しで、おなじみのループに引き込まれました。Deepseek V4のレート制限はどうなるのか、そしてどちらに転んでも問題ないようにどうシステムを設計すべきか、という問いです。

私は派手なスペックを追いかけません。スペックが変わっても安定し続けるシステムを作ることを目指しています。そこで、今の時点でDeepseek V4のレート制限についてどう考えているか、そして上限が曖昧だったり変動したりするときに頼りにしているパターンをここでお伝えします。

予想されるレート制限

単一の魔法の数字を求めてここに来たなら、残念ながら持っていません。2026年1月の時点でのテストでは、Deepseek V4のレート制限について、明確に公開された数値は確認できていません。仮にあったとしても、プロバイダーはアカウントティア、リージョン、不正利用の兆候によって制限を変更します。また、リクエスト毎分とトークン毎分を別々に管理し、同時ストリーム数に上限を設けることもあります。

私が代わりに注目しているのは次の点です。

リクエスト毎分（RPM）：何回の呼び出しを開始できるか。
トークン毎分（TPM）：より重要な隠れた制約で、特に長いコンテキストを使う場合。
同時実行数：APIが許容するリクエストの同時処理数。
リトライのセマンティクス：Retry-AfterやX-RateLimit-*といったヘッダーが存在し、信頼できるかどうか。

私はこれらを天気のように扱います。確認する価値はありますが、晴れが続くと思い込むのは危険です。

現在のV3制限に基づいた予測

2025年後半のメモによると、v3は現代的なLLM APIの多くと同様に、低ボリュームでは予測可能で、エッジ付近では敏感な挙動をしていました。上限はRPMとトークンバジェットの両方で表現されており、ヘッダーはバックオフの指針として十分な情報を提供していました。また、長いプロンプトは紙の上で計算していた以上に速くヘッドルームを消費することがわかりました。

したがって、v4がv3のパターンを踏襲するとすれば、私が計画しているのは以下の通りです。

桁のパリティ：v4はリリース時にv3よりも大幅に緩くはならないと仮定しています。新モデルは最初に制限を厳しくし、後で緩和する傾向があります。
トークン優先の考え方：RPMよりTPMに多くのバジェットを割り当てます。1つの長いリクエストが、多くの小さなリクエストと同等になることがあります。
バーストvs持続負荷：短いスパイクは、安定したトリクルよりも429エラーを引き起こしやすい。バーストはクライアント側で平滑化します。

実際には、キューのサイズをリクエスト数ではなくトークンで設定することを意味します。ユーザーが30ページの文書を貼り付けた場合、それが1リクエストであっても、次の数分間は「コストが高い」状態になると予想します。また、制限は時間帯やIPによって異なる可能性があるという事実を受け入れています。当たり前のように聞こえますが、すべてが順調なときに忘れていて、問題が起きてから気づくことがよくあります。

クライアント側のパターン

このような設定を素早く再現したい場合——最初のチャットから繰り返し可能なAPIループまで——私の短いDeepSeek V4クイックスタートガイドをご覧ください。

これらは、サポートに上限の引き上げを依頼する前に私が使うパターンです。退屈なのが肝心です。精神的な負荷を軽減し、制限をバックグラウンドノイズのように感じさせます。

指数バックオフ

最初のアプローチはジッターを含むシンプルなバックオフです。特別なことは何もありません。

観察したこと：

最初の数回は遅く感じました。やめようかと思いました。しかし、スパイク時にリトライストームで詰まらなくなったことに気づきました。
ジッターは重要でした。ジッターなしでは、バッチジョブが「サンダーハード」を引き起こし、すべてが同時にリトライしていました。
Retry-Afterが存在する場合に従うことで、小賢しく動くよりも多くの時間を節約できました。サーバーがいつ再試行すべきかを教えてくれたとき、それに従います。

日々のチューニング方法：

小さく始める：ベース遅延は250〜500ミリ秒。
指数：リトライごとに上限（8〜16秒）まで2倍にします。上限に2回達したら、コンテキスト付きでログに記録します。
適切に諦める：4〜6回試みた後、ヒント付きの型付きエラーを表示します（小さいバッチや後でのリトライを提案）。

助かった細かい点：429のリトライと5xxのリトライを分けていることです。それぞれ異なる話です。429は「あなたが押しすぎている」を意味し、5xxは「サービスが不安定」を意味します。5xxではより長くバックオフします。

リクエストキューイング

UIやcronジョブに「ただのテキストだから」という理由で無制限の呼び出しをさせません。それがレート制限を個人的な問題のように感じさせる方法です。

期待以上に効果があったこと：

トークン重み付きキュー。N個のリクエストを同時に処理する代わりに、トークンバジェットが満たされるまでリクエストを受け入れます。その後、キューを呼吸させます。
小さなバッチウィンドウ。リクエストを短いウィンドウ（200〜500ミリ秒）にグループ化して、アプリを遅くすることなくマイクロバーストを平滑化します。
優先レーン。ユーザーがトリガーするアクションが先に処理され、バックグラウンドの同期は待機します。それだけで最悪のスパイクが解消されました。

遭遇した摩擦：

トークンの推定は完璧ではありません。クライアントに安価な推定器を保持し、レスポンスが返ってきたときに実際の使用量で修正します。精確さより十分さが勝ります。
キャンセル。ユーザーがナビゲートして離れた場合、キューされた呼び出しをキャンセルして、画面上に表示されているものにバジェットを解放します。基本的に聞こえますが、実際のサイクルを節約しました。

私が従うシンプルなルール：キューが閾値（長さではなく時間ベース）を超えた場合、静かな通知を表示します。大げさにならずに。「着実に処理中」という一行だけです。ユーザーはスピードと同様にトーンを読み取ります。

サーキットブレーカー

制限が締まったりエラーが積み重なったりしたとき、何千ものリトライが役に立つふりをしてほしくありません。サーキットブレーカーはシステムに休む許可を与えます。

使い方：

持続的な失敗率でトリップ：例えば、ローリング1分間で25〜30%の呼び出しが429/5xxの場合。
ハーフオープン状態：一時停止の後、いくつかのカナリアリクエストを通します。成功すれば、ブレーカーが閉じます。
UIの挙動：「APIがスロットリングしています。まもなく再開します。」のような穏やかなバナーを表示します。進捗がないのに進捗を示唆するスピナーは避けます。

静かな驚き：制約を率直に認めたとき、ユーザーは親切でした。ブレーカーはアプリを壊れやすく見せませんでした。むしろ正直に見せました。

モニタリングとアラート

以前はレート制限をエッジケースとして扱っていたので、ログが薄かったです。それは間違いでした。v4が登場する前に、ガードレールを先に構築し、制限は何であれ受け入れるようにしています。

今記録していること：

ステータスコードと理由。エンドポイントと呼び出し元（ユーザーvs.ジョブ）別に分けた429。5xxは別途追跡。
実効トークンコスト。リクエストごとのプロンプト＋完了トークン。RPMだけより多くの動作を説明します。
レイテンシパーセンタイル。ルートごとのP50、P95、P99。スパイクはしばしばスロットリングに先行します。
リトライメタデータ。試行回数、合計バックオフ時間、Retry-Afterが尊重されたかどうか。
クライアントの同時実行数。429が発生した瞬間のフライト中の呼び出し数。

また、小さな日次ロールアップも保持しています：「リクエスト、トークン、エラーレート、追加された平均バックオフ」。独自のダッシュボードが必要なダッシュボードを構築せずに、トレンドを確認するのに十分です。

煩わしくなかったアラート：

フロアを超えた429レート、スパイクではなく。例えば10分間で429が2〜3%を超えた場合に関心を持ちます。一時的な急上昇では通知しません。
バックオフタイムバジェット。ユーザーがセッションごとに平均でX秒以上のバックオフを待っている場合、知りたいです。
トークンの異常。プロンプトサイズの中央値が3倍に跳ね上がった場合、誰かが変更をリリースしたか、ユーザーの行動が変わったことを意味します。

人間的な側面では、制限をバックエンドの問題だけでなく、プロダクトの制約として扱います。大きなコンテキストのアップロードのためのインターフェースを作る場合、ヒントを表示します：

「大きなファイルはバックグラウンドで処理される場合があります。完了したらお知らせします。」
「最初に短い要約、次に詳細な分析。」

これは単に礼儀正しいだけではありません。レート制限が許容できるパターンに使用を誘導します。

ドキュメントについて一言：可能な場合、公式ドキュメントやヘッダーに対して動作を確認します。v4が明確なレートヘッダー（Retry-After、X-RateLimit-Remaining、またはトークンカウンター）と共にリリースされた場合、そのまま記録します。欠落していたり曖昧だった場合、十分な安全マージンを持った観測された上限にフォールバックします。

なぜこれが重要か

開発者にとって：正確な数字がなくても自信を持ってリリースできます。変動に備えて設計し、リトライを静かに保ちましょう。
スケールで運用するチームにとって：クライアントが現在の制限を尊重していることを証明した後に、より高い制限を依頼しましょう。適切なバックオフとクリーンなログが見えているとき、ほとんどのプロバイダーはより良く反応します。
ソロの方にとって：シンプルに保ちましょう。小さなキュー、ジッター付きの基本的なバックオフ、1〜2個のアラートで十分です。

おそらく楽しめない方