本文提供 由 Azure 銷售的 Foundry 模型 的配額與限制的快速參考和詳細描述。 關於 Azure OpenAI 中 Foundry 模型的特定配額與限制，請參見 Azure OpenAI 中的配額及限制。
2026/05/07 後配額管理的最新情況
Microsoft Foundry 正在推出配額管理更新，以提升配額管理在不同部署間的一致性與可預測性。 從 Realtime Translate 和 Realtime Whisper 開始，部署配額會在訂閱層級追蹤——跨所有資源與區域共享——而非逐資源或區域單獨分配。
此變更將配額整合為共享池：
- Global Standard：相同模型和版本的部署會在訂用帳戶內的所有區域共用一個配額集區。
- 資料區標準：相同模型與版本的部署在每個資料區共用一個配額池（例如美國或歐盟）。
我有什麼改變？
對於已加入新配額管理系統的型號：
- 現在，所有全球標準的同一模型和版本訂閱部署，均從跨所有區域的單一共享配額池中使用資源。
- 所有在訂閱下部署相同型號與版本的資料區標準，現在都會從每個資料區內的共享配額池中提取資料。
- 現有核准配額會被保留，並自動在訂閱層級生效——無需任何行動。
此整合使 Microsoft Foundry 能在所有 Foundry 區域中一致提供支援模型，無論配額如何分配於資源或區域。
重要
更新後的配額管理目前僅適用於即時翻譯和即時耳語。 本文涵蓋的其他 Foundry 模型，配額與限制依區域、訂閱及型號或部署類型管理。 未來，這些配額指引也將適用於部分現有模型及新推出的 Foundry 模型。
配額與限制參考資料
以下章節將快速說明適用於 Foundry 模型的預設配額與限制。 配額和限額在租戶層級並未被強制執行。 相反地，最高等級的配額限制範圍是 Azure 訂閱層級。 每分鐘代幣數（TPM）及每分鐘請求數（RPM）限制依區域、訂閱及型號或部署類型定義。
資源限制 (每個 Azure 訂用帳戶、每個區域)
| 限制名稱 | 極限值 |
|---|---|
| 每個 Azure 訂用帳戶每個區域的 Foundry 資源 | 100 |
| 每個資源的最大專案數 | 250 |
| 每個資源的部署數上限 (Foundry 資源內的模型部署) | 32 |
速率限制
下表列出了鑄造廠模型在以下速率下的限制：
- 每分鐘的代幣數量
- 每分鐘請求數
- 並行要求
| 型號 | 每分鐘的代幣數量 | 每分鐘請求數 | 同時請求 |
|---|---|---|---|
| Azure OpenAI 模型 | 這會因型號和SKU而異。 請參閱 Azure OpenAI 的限制。 | 這會因型號和SKU而異。 請參閱 Azure OpenAI 的限制。 | 情況不一。 請參見 Azure OpenAI 限制。 |
| - DeepSeek-R1 - DeepSeek-V3-0324 |
5,000,000 | 5,000 | 300 |
| - Llama 3.3 70B 指示 - Llama-4-Maverick-17B-128E-Instruct-FP8 - 格羅克3 - Grok 3 迷你版 |
400,000 | 1,000 | 300 |
| - Flux.2-Pro | 不適用 | - 低（預設）：15 - 中型：30 - 高（企業級）：100 |
不適用 |
| - Flux-Pro 1.1 - Flux.1-Kontext 專業版 |
不適用 | 2 個容量單元（每分鐘 6 次請求） | 不適用 |
| 其他型號 | 400,000 | 1,000 | 300 |
要增加配額，請使用 Microsoft Foundry Service： Request for Quota Increase 提交申請。 由於需求量大，增加配額的申請會逐一評估。 欲了解更多配額增加請求，請參閱「 要求增加至預設限額」。
其他限制
| 限制名稱 | 極限值 |
|---|---|
| API 請求中自訂標頭的最大數量1 | 10 |
1 目前的 API 允許最多 10 個自訂標頭，管線會通過並回傳這些標頭。 若超出標頭數，請求將產生 HTTP 431 錯誤。 要解決這個錯誤，請減少標頭音量。 未來的 API 版本將無法通過自訂標頭。 未來系統架構不要依賴自訂標頭。
使用層級
全球標準部署利用 Azure 的全球基礎設施，動態地將客戶流量路由到具備最佳可用性的資料中心，以滿足客戶推論請求的需求。 此基礎設施為低至中等流量客戶提供更穩定的延遲。 持續使用量高的客戶可能會看到回應延遲的變化較大。
使用限制決定了使用量門檻，一旦超過此門檻，客戶可能會看到回應延遲出現較大的波動。 客戶的使用量是根據模型定義的，指的是同一租戶在所有區域所有部署、所有訂閱中所消耗的總令牌數。
請求會增加到預設上限
提交 配額增加申請表，用於申請 由 Azure 銷售的 Foundry 模型、Azure OpenAI 模型及 Anthropic 模型的配額增加。 除了Anthropic模型外，合作夥伴及社群模型不支援配額增加。
配額增加請求依接收順序處理，優先權會給予積極使用現有配額的客戶。 不符合此條件的請求可能會被拒絕。
維持速率限制的一般最佳實務
為了減少與速率限制相關的問題，請採用以下技術：
- 在你的應用程式中實作重試邏輯。
- 避免工作量急劇變化。 逐步增加工作量。
- 測試不同的負載增加模式。
- 增加分配給你部署的配額。 必要時從其他部署調動配額。
設定客戶端時間限制
請依照下列建議明確設定用戶端逾時時間。
註
如果未明確設定，用戶端逾時設定會依所使用的函式庫而定，且其限制可能與上述限制不同。
- 推理模型（在產生摘要回應前產生中間推理標記的模型）：最長可達 29 分鐘。
- 非推理模型：
- 串流時，最長可達 60 秒。
- 非串流請求最多需時29分鐘。
這裡的 29 分鐘並不代表所有請求都需要 29 分鐘，而是根據上下文標記、產生的標記和快取命中率，請求可能需要長達 29 分鐘。
設定一個比這些值更短的超時時間，並根據你的流量模式調整。
對於推理模型（包括串流請求）來說，所有推理標記先被產生，然後彙總，然後再將第一個回應標記回傳給使用者。
你可以修改 推理努力 參數，來控制過程中產生的推理標記數量。
故障排除
| 症狀 | 成因 | 解決方法 |
|---|---|---|
| HTTP 429 請求過多 | 每分鐘代幣或每分鐘請求數超過上限 | 實作帶有指數退縮的重試邏輯。 使用 Retry-After 標頭值。 |
| HTTP 431 請求標頭欄位過大 | 超過 10 個自訂標頭已發送 | 將自訂標頭減少到 10 個或更少。 |
| 配額頁面顯示 0 可用 | 訂閱或區域配額已全額分配 | 將未使用的配額從另一個部署移過去。 要提高你的限額，請 申請提高配額。 |
| 該型號區域內無法取得 | 該模型在所選區域內未被部署或支援 | 查看 型號供應 並選擇可用區域。 |