Verification Checklist

  • ✓Does the response JSON include a model field, and does its value exactly match the model parameter you specified in the request (e.g. you requested deepseek-v4-pro but the response shows deepseek-v4-flash or a similar lightweight identifier)
  • ✓Have you run the exact same prompt during Beijing-time daytime peak hours and again during late night/weekend off-peak hours multiple times, and compared whether output depth, reasoning quality, and formatting show a consistent, repeatable difference
  • ✓Have you actually checked the vendor's official SLA or service terms for a clause that explicitly states "no undisclosed model substitution" or, conversely, that model switching may occur under resource pressure — rather than assuming either way
  • ✓If your use case requires strong model version consistency (reproducible evaluation, audit, or compliance scenarios), have you confirmed this specifically with the vendor's enterprise support channel rather than relying only on public documentation
  • ✓If you have purchased or are considering a dedicated capacity/reserved throughput plan (provisioned throughput, dedicated instances — naming varies by vendor), have you confirmed whether its official terms explicitly rule out model routing/downgrade, or only cover concurrency and rate guarantees

1. The symptom: slower responses and "phoned-in" output at peak hours — is the model actually being swapped

Many developers using DeepSeek, Ernie Bot, and similar domestic LLM APIs for production workloads share a similar gut feeling: the same prompt run during daytime working hours feels slower and produces terser, more perfunctory output; run the same thing late at night or on a weekend and the output is noticeably more complete and better organized. This perceived difference could have several entirely different root causes — plain network latency variance, longer response times from concurrency queuing, or simply the model's own sampling randomness producing output variance can all create a similar impression. But there's another possibility that's easy to overlook and worth taking seriously: to cope with compute pressure under high concurrency, a provider's load-balancing/traffic-scheduling logic may route some requests to a smaller, faster, weaker model or a lightweight variant instead of the exact model you specified in the request. If this switching exists, it typically isn't flagged to the user with a pop-up or a prominent response field — the output remains a complete, coherent block of text, just degraded in quality and capability, which makes it harder to spot at a glance than an issue like "HTTP 200 with empty content" caused by moderation truncation.

2. Technical signal one: the model field in the response body is your first piece of hard evidence

Mainstream domestic LLM APIs are broadly OpenAI-compatible, requiring an explicit model parameter in the request (e.g. "deepseek-chat", "deepseek-reasoner", or Baidu Qianfan's "ernie-3.5-8k"), as shown in both DeepSeek's official API documentation and Baidu Qianfan's official quick-start guide. What matters is the response side: DeepSeek's official "Create Chat Completion" documentation defines a required model field in the response body, described as "The model used for the chat completion" — in other words, whichever model actually processed the request should be reflected in this field. The first, most direct verification step: take a complete response JSON from a real call and check whether the model field's value exactly matches the model parameter you sent (note that some providers give lightweight variants their own distinct identifiers, such as a xxx-flash, xxx-turbo, or xxx-lite suffix, rather than reusing the exact name you requested — in that case a mismatch would be immediately visible). If the values don't match, that's the most direct technical evidence available today. If they do match, that still doesn't fully rule out a provider internally routing to a lighter model while continuing to report the original model name externally — which is why the cross-check in the next section matters too.

3. Technical signal two: run the same prompt at peak and off-peak hours and look for a repeatable pattern

Even if the model field checks out consistently, it's worth running a second cross-check: pick a few prompts that clearly reveal differences in model capability (a multi-step math problem, a complex writing task requiring long-form organization, a structured-output task requiring precise instruction following), and run the identical input three to five times during Beijing-time weekday daytime peak hours (roughly 9am–12pm and 2pm–6pm — see this site's other piece, "DeepSeek Off-Peak Pricing," for how peak windows are typically defined) and again during late night or weekend off-peak hours. Compare the level of detail, whether reasoning steps are complete, formatting consistency, and whether outputs tend toward a terser or truncated-feeling close. If the same prompt consistently shows shorter, shallower output at peak hours and consistently fuller, deeper output off-peak, with a pattern that repeats rather than being a one-off fluke, that's a second technical signal worth raising with the vendor's official support channel. It's worth noting that output variance can also come purely from the model's own sampling randomness (temperature and related parameters) — a single test proves nothing; only a repeated, statistically consistent pattern across multiple runs is meaningful evidence.

4. What public documentation does and doesn't confirm

In fairness, when checking DeepSeek's official API documentation for this piece, no explicit clause was found either stating that "model downgrade routing may occur at peak hours" or, conversely, guaranteeing "no model substitution ever occurs." The only resource-related field found in the public documentation is one value of the response's finish_reason field, "insufficient_system_resource," officially described as indicating the request was interrupted due to insufficient inference system resources — which confirms the vendor's public documentation acknowledges requests can be interrupted under resource pressure, but says nothing about whether a more subtle form of degradation (rerouting to a weaker model that then completes and returns normally) exists. No public documentation from Baidu's Ernie Bot/Qianfan platform addressing this specific mechanism was found either. In short, there is currently no reliable public source confirming or ruling out whether any specific vendor implements model routing degradation, or under what conditions — actual practices likely vary by vendor and may change over time. This piece does not assert that any specific vendor engages in this behavior; it only offers a method for developers and enterprise users to verify it themselves.

5. What enterprise users should verify in their service agreement/SLA

If your use case has a strong requirement for model version consistency (an automated evaluation pipeline needing reproducible results, an auditable compliance scenario, or a service you offer externally with committed model capabilities), it's worth going directly to the vendor's enterprise support or account team before purchase or renewal and asking for three specific confirmations, rather than guessing: first, whether the service agreement or SLA explicitly states that the model identifier returned in the response is the actual model that processed the request, with no undisclosed substitution; second, if the provider's load-balancing mechanism can route to a different model under load, whether there's a clause describing the trigger conditions, whether such routing is disclosed in the response, and whether an option exists to request "this exact model only, no routing"; third, whether there's a queryable, appealable process letting an enterprise submit a specific request ID for the vendor to investigate if a substitution is suspected. SLA terms vary significantly by vendor — defer to the actual agreement you've signed, and this piece does not assert a uniform industry standard.

6. Can a dedicated capacity/reserved throughput plan avoid this problem

Some vendors offer enterprise customers dedicated capacity plans with fixed reserved throughput (naming varies — reserved instances, dedicated deployments, or concepts similar to Provisioned Throughput Units). As this site's other piece on API rate-limit tier billing notes, these plans typically address concurrency throttling and response-latency stability — guaranteeing you won't be rate-limited or queued within your contracted throughput. Whether such a plan's official terms also explicitly rule out model routing/degradation is a separate question that needs its own verification — don't assume that paying for dedicated capacity automatically means the model version is fixed. Reserved throughput guarantees a resource quota; model routing degradation, if it exists, is a separate scheduling layer that isn't necessarily tied to it. The way to verify this is the same: ask the vendor's enterprise support directly whether the plan's terms state the model version is fixed under dedicated capacity and will never be routed elsewhere, or whether the plan only covers concurrency/rate guarantees — commitments vary by vendor and need to be confirmed individually.

7. Takeaway

Whether a domestic LLM API quietly routes requests to a weaker model at peak hours is currently a question without a uniform public answer — and it's a completely different mechanism from the content-moderation truncation issue already covered on this site: that one blocks content and returns it empty or cut short, while this one, if it happens, still returns complete output, just degraded in quality, which makes it harder to notice. The two hands-on technical checks developers can run themselves are: comparing the response's model field against the requested model, and running the same prompt repeatedly across peak and off-peak hours to look for a consistent pattern. Enterprise users with a strong need for model version consistency should go directly to the vendor's SLA or service agreement text to check for explicit clauses on model substitution/downgrade, and separately confirm whether a dedicated capacity plan actually covers this — not assume it from guesswork.