At 16:00 UTC on 16 August, DeepSeek’s announced V4 tariff crossed its effective clock. [E1] Every minute from that boundary through 21:45 UTC sat outside the published peak windows, so the tariff’s first five hours and 45 minutes were entirely off-peak. [E1][E2] The peak windows are 01:00–04:00 and 06:00–10:00 UTC, seven hours in a day, leaving 17 hours at the off-peak rate. [E2] The first peak window after activation therefore still lay ahead, beginning at 01:00 UTC on 17 August. [E1][E2]
On this part of the bench, the tariff is the mature component: DeepSeek published the effective time and the daily clock that governs it. [E1][E2] Hours outside the two peak blocks carry half-price token rates, making the off-peak relation exactly one-half of the corresponding peak charge. [E2] That creates a clean scheduling incentive for work whose completion time can move across the day, because the same published tariff assigns different prices to different UTC hours. [E2] It does not establish an invoice, a customer response or the exact server-side second at which billing behavior changed. [E1][E2]
The scheduler is one maturity rung lower: it is an opportunity implied by the price table, not observed customer behavior. DeepSeek publishes account concurrency of 2,500 for Flash and 500 for Pro, with no documented time-of-day change in those limits. [E3] An operator that can defer agent work therefore has a price clock to consider while the published concurrency ceiling stays fixed across that clock. [E2][E3] Nothing in the record shows utilization, shortage, migration or customers shifting jobs into the cheaper 17-hour block. [E2][E3]
Three hours, 16 minutes and 46 seconds after the tariff boundary, a different component moved. vLLM merged commit ef43e310 to main at 19:16:46 UTC, implementing a five-file DeepSeek V4 serving change associated with PR #52212. [E5] The merged work adds a sparse-MLA decode optimization gated to gfx950, along with graph-safe adaptive work and tests. [E4][E5] Its maturity label is therefore merged implementation, with qualification bounded to the accelerator path that the code selects. [E4][E5]
That gfx950 gate matters because it keeps the claim inside one cell of the qualification matrix: model, engine, kernel path and accelerator. [E4] PR #52212 describes the target in the MI355X/gfx950 context, so the merge supplies no basis for treating AMD and NVIDIA hardware as fungible or for extending the result across unrelated accelerators. [E4] It also supplies no evidence of a model-quality change. [E4] What landed is target-specific serving machinery for sparse-MLA decode, with tests attached to that machinery. [E4][E5]
Benchmark evidence sits on the loosest screw. In one author-run paired result on 8×MI355X, output throughput increased 2.754% while P90 time to first token regressed 4.092%. [E4] Those two numbers describe that narrow configuration and one paired run; they do not establish a generic V4 speedup. [E4] The useful reading is smaller: the new path changed measured serving behavior on the hardware configuration used by the author, with throughput and tail-start latency moving in opposite directions. [E4]
A boring null remains strong: time-of-day pricing is ordinary price discrimination, while accelerator-specific kernel engineering is routine work in a serving engine. [E1][E2][E4] Nothing in the record connects the tariff decision to PR #52212, and same-day arrival does not supply that causal link. [E1][E4][E5] Their operational connection appears only after deployment, where an operator can combine a time-sensitive API price with a separately qualified serving path and decide which lever matters for a given workload. [E2][E4] V4 now gives the agent scheduler a clock beside the model picker. [E1][E2]