Model: deepseek-v4-1-flash, endpoint POST /api/v1/chat/completions, stream: true.
Roughly one in four requests returns nothing for 115-120 s, then the complete response arrives within ~1 s. The other requests finish in 1-2 s. Same prompt, same key, back-to-back. Reproducible with plain curl, no client library involved.
Evidence (2026-09-22, all times UTC):
Two consecutive calls in one agent turn, both ~121 s each: 12:25:58 -> 12:28:00 and 12:28:00 -> 12:30:01.
Via a local logging proxy: request at 12:37:25, 45 KB body, 4 messages, 4 tools. HTTP response headers arrived after 119.98 s, full body 25 ms later. cf-ray a3f15c65ebf22675-MUC. The request right before it (12:37:23, 25 KB) took 1.43 s, cf-ray a3f15c5c3ebcb48e-MUC.
curl, identical 40 KB request three times in a row (~12.7k prompt tokens): 1.5 s / 115 s / 1.5 s. In the slow one every chunk has "created": 1790080914 (12:41:54), i.e. generation started ~1 s before the stream ended, about 114 s after the request was sent. id chatcmpl-c01367c7dcbd44438d11ad5084345c9c (slow), chatcmpl-0266e7a967034b07ad819de012e0a3f0 and chatcmpl-9b524325d3f948878fa900d2e022e180 (fast).
The slow responses carry a different usage schema: "completion_tokens_details": {"accepted_prediction_tokens": 56, "audio_tokens": 0, "reasoning_tokens": 42, "rejected_prediction_tokens": 34} and "cached_tokens": 0, while fast responses only have "reasoning_tokens" and hit the prompt cache. This looks like a second inference backend that takes over after a ~120 s timeout on the primary one.
Prompt size does not seem to matter (25 KB and 45 KB affected, 40 KB twice not). Other Venice models (grok-4-7) were consistently fast in the same period. Happy to provide the full request/response captures.