DeepSeek-V4-Pro on Foundry: every request fails with 413 "Max size: 4000 tokens" per-request cap, not TPM

Question

DeepSeek-V4-Pro on Foundry: every request fails with 413 "Max size: 4000 tokens" per-request cap, not TPM

Romir Chekuri 0

My DeepSeek-V4-Pro deployment (Global Standard) returns HTTP 413 on every single request, regardless of input size:

{"error":{"code":"tokens_limit_reached","message":"Request body too large for deepseek-v4-pro model. Max size: 4000 tokens."}}

Even a one-word message fails, because any client with normal system-prompt overhead exceeds 4000 tokens. The model natively supports a 128K+ context window, so this appears to be a deployment-level or backend cap, not a model limitation.

Details:

Resource: flashai-resource (Foundry), region West US 3
Deployment: DeepSeek-V4-Pro, Global Standard, model version 2026-04-23
TPM allocated: 500K (can raise to 1M in the portal — doesn't help)
RPM: 250/1000 used — not throttled
Endpoint: OpenAI-compatible /openai/v1/chat/completions, key auth works fine
The quota dashboard shows only an RPM metric for this model (no TPM metric listed), and no portal setting exposes a per-request/context-length limit

What I've ruled out:

Not client-specific: reproduces via multiple clients and through a LiteLLM proxy
Not TPM/RPM throttling (usage far below limits, and the error is 413 tokens_limit_reached, not 429)
Redeploying and adjusting the TPM slider changes nothing
I've submitted the quota increase form, but it only measures TPM capacity units, which isn't the limit being hit

Use case: agentic coding tools (Cline, Codex CLI) via the OpenAI-compatible endpoint — these carry 10-20K tokens of standard prompt/tool overhead per request, so a 4000-token request cap makes the deployment unusable.

Question: Is the 4000-token per-request limit on DeepSeek-V4-Pro Global Standard deployments intentional, and can it be raised for a subscription/deployment? If it's a backend default, what is the correct channel to request an increase, since the quota form only covers TPM? I've seen the same class of issue reported for other Foundry serverless models (e.g. an 18K cap on Mistral), so a pointer to the right escalation path would help others too.

Thanmayi Godithi 11,565 Reputation points Microsoft External Staff Moderator

2026-07-25T08:31:22.71+00:00

Hi Romir Chekuri,

Based on what you shared, this doesn’t look like a client-side throttling/quota (since you’re getting HTTP 413 with tokens_limit_reached and an explicit “Max size: 4000 tokens” message). In scenarios like this on Azure AI Foundry, there are cases where the enforced token cap is set by the server-side inference/container configuration for that particular serverless “Global Standard” deployment, even if the model’s published context window is much larger.

For Foundry serverless deployments, the request is still validated server-side against an effective max input size enforced by the backend/container. Similar issues have been reported for other Foundry serverless models where:

the effective context/token limit seen by the client is much smaller than what the model spec/catalog advertises

and the cap isn’t configurable via API parameters or deployment settings (no request flag to override it)

So in your case, the consistent 413 with a numeric cap strongly suggests an intentional/active backend limit for that deployment build, not TPM/RPM throttling and not something you can “tune” by increasing allocated tokens/minute.

From the information provided in the docs/snippets above, there isn’t a portal setting or API parameter mentioned that would let you raise an enforced per-request/context cap for serverless Foundry inference. When the limit is enforced by backend configuration, the guidance is typically to correct the backend deployment configuration so could you please provide the details requested over Private message.

1 answer

Your answer

Thanmayi Godithi 11,565 Reputation points Microsoft External Staff Moderator

2026-07-25T08:31:22.71+00:00

Hi Romir Chekuri,

Based on what you shared, this doesn’t look like a client-side throttling/quota (since you’re getting HTTP 413 with tokens_limit_reached and an explicit “Max size: 4000 tokens” message). In scenarios like this on Azure AI Foundry, there are cases where the enforced token cap is set by the server-side inference/container configuration for that particular serverless “Global Standard” deployment, even if the model’s published context window is much larger.

For Foundry serverless deployments, the request is still validated server-side against an effective max input size enforced by the backend/container. Similar issues have been reported for other Foundry serverless models where:

the effective context/token limit seen by the client is much smaller than what the model spec/catalog advertises

and the cap isn’t configurable via API parameters or deployment settings (no request flag to override it)

So in your case, the consistent 413 with a numeric cap strongly suggests an intentional/active backend limit for that deployment build, not TPM/RPM throttling and not something you can “tune” by increasing allocated tokens/minute.

From the information provided in the docs/snippets above, there isn’t a portal setting or API parameter mentioned that would let you raise an enforced per-request/context cap for serverless Foundry inference. When the limit is enforced by backend configuration, the guidance is typically to correct the backend deployment configuration so could you please provide the details requested over Private message.

Answer 1

Hello Romir Chekuri,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your DeepSeek-V4-Pro on Foundry: every request fails with 413 "Max size: 4000 tokens" per-request cap, not TPM.

Regarding your questions:

Is the 4000-token per-request limit on DeepSeek-V4-Pro Global Standard deployments intentional, and can it be raised for a subscription/deployment? If it's a backend default, what is the correct channel to request an increase, since the quota form only covers TPM? I've seen the same class of issue reported for other Foundry serverless models (e.g. an 18K cap on Mistral), so a pointer to the right escalation path would help others too.

It is being enforced by the deployed Foundry endpoint. Whether it is an intentional service limit or a backend defect cannot be determined by the customer and requires Microsoft Support to confirm.
There is no documented self-service method to increase the per-request input limit for Azure AI Foundry serverless model deployments.
No. TPM controls throughput and cannot change a 413 request-size validation limit.
No. It only handles TPM/RPM capacity, not per-request payload limits.

Since you've opened an Azure Support technical case, is the best they will fix 4,000-token rejection.

I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.