Foundry で Anthropic モデルのデプロイが失敗する理由 ― Quota 構造の整理

Foundry で Anthropic モデルを扱っていると、TPM が残っているのにデプロイが進まないケースがある。最初は設定の問題かと思ったが、複数のサブスクリプションで挙動を比べていくと、表面の数字とは別のレイヤーで制御が分かれていることが見えてきた。自分の環境で挙動を確認しながら、どこで処理が止まっているのかを整理した。

Foundry の TPM 表示はプロジェクト側の利用枠として管理されている。ここで示される値は、あくまで Foundry 内部での上限管理に近い。一方で、Anthropic のモデルを実際に動かす段階では、サブスクリプション単位で割り当てられる Global Standard quota を通過する必要がある。この quota が 0/0 の状態だと、Foundry 側の TPM が残っていてもデプロイは成立しない。両者は同じ値に見えても、更新のタイミングも適用の順序も異なるため、UI の数字だけでは判断が難しい。同じモデルを複数のサブスクリプションで試すと、Foundry の条件が同じでも結果が分かれた。差分を追っていくと、Anthropic quota の割り当てが存在するかどうかが分岐点になっていた。Foundry の TPM はプロジェクト内の枠で、実行経路の最終ゲートはサブスクリプション側にある。割り当てが存在しない場合、ユーザー側で変更できる部分はなく、Foundry の数字がどれだけ残っていても結果は変わらない。

リージョンを変えたり、TPM を小さくしたりしても挙動は変わらなかった。Foundry の表示はあくまで内部管理の値で、実際の実行経路とは独立している。両者のレイヤーが同期していないと、UI の数字と動作が一致しない。この流れを見ていくと、どこが実際のゲートになっているのかが少しずつ浮かび上がってくる。

まとめると、Foundry の TPM とサブスクリプション側の Anthropic quota は別レイヤーで管理されており、後者が割り当てられていない場合はデプロイが成立しない。UI の数字だけでは判断できないため、挙動が合わないときは quota の状態を確認する必要がある。複数のサブスクリプションで結果が分かれる場合、この構造が原因になっていることが多い。レイヤー間の責務を理解しておくと、同じ現象に遭遇した際の切り分けが早くなる。