DeepSeek streaming latency: a small, reproducible sample

On 2 November 2026 we made ten real requests to the two DeepSeek routes on the Excession API. The useful finding was how reasoning and output limits change what a streaming client sees. This is a small diagnostic sample, not a speed ranking or a service-level guarantee.

What we measured

Every timing, token count and cost estimate in this post comes from 2 November 2026 and describes that day. Token prices have changed since, so the cost section below shows the old estimate next to a recalculation at current prices.

One macOS ARM client using Node 26.12.1 sent requests sequentially to https://api.excessionlabs.ai/v1/chat/completions. We alternated regular DeepSeek V4.1 Flash and the abliterated variant, with no separate warm-up. Every request used the same short HTTP caching question, temperature 0, streaming with usage, and a 160-token maximum output.

The first run made three requests per model with default reasoning behavior. The second made two requests per model with reasoning.enabled=false and thinking.type=disabled set in the request template. We did not vary prompts, regions, concurrency levels, model providers or output limits.

We measured client wall-clock time from the start of fetch. Time to first content means the first nonempty visible-content delta, excluding reasoning. Total time runs until stream completion. Both include networking, queueing and generation; neither isolates model-server speed.

Conceptual stream from request through reasoning and visible answer to completion, with first-content and total-time spans.
Conceptual timing illustration, not measured data or a scale drawing. Time to first content excludes reasoning; total time ends when the stream completes.

Results with reasoning explicitly disabled

These four requests ran on 2 November 2026, from 16:38:54 to 16:39:02 UTC. The table rounds the raw median milliseconds to whole numbers. With only two observations, each median is the midpoint of those observations.

RouteRequestsStreams completedMedian first visible contentMedian total timeReported completion tokens per request
DeepSeek V4.1 Flash22904 ms2,878 ms160
DeepSeek V4.1 Flash Abliterated22290 ms909 ms124

All four requests returned HTTP 200 and completed their SSE stream. Regular DeepSeek reported finish_reason: stop once and length once; the abliterated route reported stop twice. Both reported 39 prompt tokens per request and zero cached tokens. Neither emitted reasoning in this run.

One regular-model answer stopped at the output limit, so a completed stream is not always a complete answer. The output lengths also differ, which makes total times unequal to compare. The abliterated route had shorter times in these four requests, but this sample cannot show that either model is generally faster, better or more reliable.

Why the first run matters

All six default-reasoning requests exhausted the 160-token completion budget with reasoning and produced no visible answer. Their streams completed, but all reported finish_reason: length. Counting a reasoning delta as the "first token" would have produced an apparently responsive latency number while the user saw no answer at all.

That is why the raw artifact records first_token_ms and first_content_ms separately. The former counts content or reasoning; the latter counts only visible answer content. A request that never shows visible content has an empty first-content value, not zero milliseconds.

When an answer comes back empty, check the reasoning and the finish reason. A small token cap can run out before any visible output. Pick a budget that fits the task, and check that the selected model honors your reasoning controls. The integration guide shows how to read streaming content and usage without treating every event as text.

Cost evidence is separate from latency

On 2 November 2026 the test account had an unlimited entitlement, and each response reported usage.cost: 0. These fields show what this account was charged. They do not show that the API is free.

The script separately estimated token cost using the public catalog captured immediately before each run. That catalog still advertised the earlier rates: $0.28 input, $0.07 cached input and $1.00 output per 1M tokens, for both models. Those rates are historical, not current prices. The table keeps the 2 November estimates and recalculates the same measured tokens at current prices on 3 November 2026. No request used cached tokens, so the cached rate does not enter the arithmetic.

RoutePrice basisInput / output tokens, two requestsCalculation, per 1M tokensEstimate
DeepSeek V4.1 FlashHistorical: catalog of 2 November 202678 / 320(78 × $0.28 + 320 × $1.00) / 1,000,000$0.00034184
DeepSeek V4.1 FlashCurrent prices78 / 320(78 × $0.035 + 320 × $0.50) / 1,000,000$0.00016273
DeepSeek V4.1 Flash AbliteratedHistorical: catalog of 2 November 202678 / 248(78 × $0.28 + 248 × $1.00) / 1,000,000$0.00026984
DeepSeek V4.1 Flash AbliteratedCurrent prices78 / 248(78 × $0.20 + 248 × $0.80) / 1,000,000$0.000214

These figures are token-price estimates, not invoices. A plan adds plan credit, so what you pay can be lower than the estimate. We keep the 2 November catalog snapshot in the raw JSON so the historical calculation can be checked, and we do not rewrite historical measurements when prices change. For current model-specific pricing, use the API pricing page or the live catalog.

Reproduce and inspect the evidence

Run the script with its --help option first. Keep the prompt, output limit, reasoning settings, sample count, runtime and timing definitions with any results you publish. Record actual token counts instead of assuming that equal output caps produce equal output lengths.

What this sample cannot tell you

This is ten requests from one client, with one short prompt, no warm-up and concurrency one. It does not measure sustained throughput, long-context behavior, answer quality, availability over time or regional differences. It provides no p95 latency estimate and no competing-provider comparison. Cache and route behavior can change between runs.

A stronger comparison would repeat a defined prompt set over multiple time windows, keep reasoning settings comparable, report output-length distributions and errors, and separately evaluate answer quality. Until that evidence exists, treat this sample as a look at request behavior and do not pick a model from it.

Continue reading