DeepSeek V4 concurrency limits: treat 2500 Flash and 500 Pro as an account contract, not a per-key trick

DeepSeek's official Rate Limit & Isolation page currently lists concurrency by model at the account level: `deepseek-v4-pro` is capped at `500` and `deepseek-v4-flash` at `2500`.

The important word is account. The same official page says the limit is calculated regardless of which API key is used under that account. That means extra keys are not a clean bypass if they still belong to the same account.

DeepSeek says a request counts as one concurrent connection from the moment it is sent until the model response is complete. That matters because slow long-running requests occupy concurrency for the whole response window, not only for the first token.

In practice, that means you should model peak in-flight requests, not only requests per second. A workload with many long completions can hit the concurrency wall even if headline QPS looks modest.

DeepSeek's official failure mode is explicit: when requests go over the concurrency limit, the API returns HTTP `429`. The page does not promise invisible overflow queues or automatic soft bursting beyond the cap.

That means the correct engineering response is to add backpressure, queueing, or controlled retries rather than treating 429 as a mysterious transient bug with no documented cause.

DeepSeek's official page says `user_id` helps with content-safety isolation, KVCache isolation, and scheduling isolation. It also notes that regular API users still have all `user_id` values combined for concurrency-limit calculation.

That is the key operational distinction. `user_id` is useful for tenant separation and scheduling behavior, but it is not a simple escape hatch that makes the base account-level concurrency limit disappear for ordinary accounts.

The page becomes stricter for accounts that receive increased concurrency quotas: DeepSeek says it can also impose per-`user_id` concurrency caps under the higher-quota account, with the same 500 Pro and 2500 Flash numbers applying to each `user_id`.

DeepSeek does document a capacity-expansion request form and says there is no additional cost for capacity expansion. That is useful, but it should be framed conservatively.

The official wording says DeepSeek will match appropriate concurrency based on actual business needs. That is not the same as promising instant approval or unlimited scaling on demand. Treat it as a formal request path, not an automatic entitlement.

Start with measurement before configuration churn. Count in-flight requests, segment Flash versus Pro traffic, and look for long responses that pin concurrency unnecessarily. Then add queueing, shape traffic by tenant, and reserve Pro for work that truly needs it.

If the traffic pattern is healthy but the contract is still too small, use the official capacity-expansion path. If your real problem is cost tradeoffs between Flash and Pro rather than throughput, continue with `/guides/deepseek-v4-pricing-per-million-tokens` and `/guides/deepseek-v4-pro-vs-flash`.