DeepSeek V4 正式版 7 月中旬上线，API 引入峰谷定价

DeepSeek V4 official version will be launched in mid-July, simultaneously introducing a peak-valley pricing mechanism: on weekdays from 9–12 and 14–18, API prices will double, while regular prices will remain unchanged. This is the first time a domestic large model has explicitly implemented time-based pricing on a public API.

On June 29, multiple DeepSeek API developers shared the official upgrade email they received: the final release of DeepSeek V4 is scheduled to go live in mid-July, accompanied by something rarely seen in public cloud LLM APIs — peak-valley pricing.

The rules are straightforward. Each day, from 9:00 AM to 12:00 PM and from 2:00 PM to 6:00 PM, API prices for V4-Pro and V4-Flash will be charged at twice the regular rate; during other times, current prices remain unchanged. This is based on Beijing time, with no distinction between weekdays and weekends.

Screenshot of DeepSeek V4 official release email notification, including peak-valley pricing description

Price Table: Peak Hours = Direct ×2

The email contained the full price list as follows, units are RMB yuan / million tokens:

deepseek-v4-pro

| Billing Item | Regular Price | Peak Hour Price | | --- | --- | --- | | Input (Cache Hit) | 0.025 | 0.05 | | Input (Cache Miss) | 3 | 6 | | Output | 6 | 12 |

deepseek-v4-flash

| Billing Item | Regular Price | Peak Hour Price | | --- | --- | --- | | Input (Cache Hit) | 0.02 | 0.04 | | Input (Cache Miss) | 1 | 2 | | Output | 2 | 4 |

Peak hours defined: daily 09:00–12:00, 14:00–18:00 (Beijing Time).

Converted to costs, an application running on V4-Pro around the clock with evenly distributed traffic will see daily costs increase by about 29%—because 7 out of 24 hours are billed at twice the rate. If traffic is concentrated during daytime working hours, the actual bill increase will be close to double. This is a significant change.

This Is Not a Price Hike — It’s Pushing Peak Loads Out

If you see this adjustment as purely a price hike, you’ll miss what DeepSeek is actually aiming for.

Over the past six months, the DeepSeek API has often faced rate limiting, queuing, and prolonged first-token latency during weekdays in daytime hours. Community chatter has centered on “batch jobs run steadily at night, but during the day you have to retry three times.” The reason is simple: back in the V3 era, DeepSeek already offered half-price nighttime pricing to guide demand, but the single-direction discount wasn’t enough to get large users to shift traffic — they still had to run jobs during the day.

Now the logic is reversed. Instead of discounting night hours, they’re adding a daytime surcharge — a full 2×. For cost-sensitive workloads like batch processing, offline evaluation, data synthesis, document parsing, and crawler pipelines — the typical “schedulable load” — the price signal is much stronger. Those who can shift traffic naturally will; real-time business that must run during the day is effectively paying a premium for peak resources. This mechanism has been used in power grids for decades, and cloud services’ spot instances follow similar logic. This is the first time an LLM API has made it part of official pricing — DeepSeek is the first.

To judge whether this is good or bad, you have to look both ways.

For developers running to-C real-time apps, bills will definitely look worse. A chat product’s traffic curve naturally peaks during the day and dips at night — you can’t shift users to early morning. These users are essentially subsidizing the whole system’s peak shaving and valley filling.

For teams building Agents, data pipelines, or internal enterprise knowledge bases, the impact is actually controllable and even beneficial — as long as they can write a scheduler to run non-real-time tasks after 6:00 PM or before 9:00 AM, costs will remain unchanged, and they’ll benefit from the freed daytime capacity for a more stable SLA.

What Cards Does the V4 Final Release Hold?

The reason DeepSeek can adjust pricing so boldly is that product strength backs it up.

The V4 preview went open source and live back on April 24, and the community has been using it for over two months, so the basics are clear:

V4-Pro: 1.6 trillion total parameters, 49B active parameters, 33T tokens pretraining dataset, native support for 1M context length, “expert mode” on the web;
V4-Flash: 284B total parameters, 13B active parameters, 32T tokens pretraining dataset, also supports 1M context length, “fast mode” on the web.

Both versions use an MoE architecture, with low activation ratios (Pro ~3%, Flash ~4.6%), reflecting DeepSeek’s cost-control philosophy — plenty of parameters, but only a small subset lit up at any one time.

For mid-July final release, the official stance is “more feature optimization and performance upgrades,” without giving specific benchmark numbers. Between preview and final release, DeepSeek did two notable public things: completed a ¥50 billion new funding round at the end of June, and on June 27 jointly launched the DSpark inference acceleration framework with Peking University.

DSpark: Bringing Speculative Decoding to Engineering Level

DSpark deserves special mention. It’s not a new model, but an inference acceleration layer atop existing V4 models, already fully deployed to online services. The paper includes founder Liang Wenfeng as co-author, and the accompanying full-stack speculative decoding toolchain — DeepSpec — has been open-sourced.

Test results: V4-Flash single-user generation speed improved by 60%–85%, V4-Pro improved by 57%–78%.

Speculative decoding itself is not a new concept — use a small model to quickly draft, then a large model to verify in parallel, accepting consecutive correct prefixes. The engineering challenge is difficult, mainly due to two issues: after parallel generation, suffix errors accumulate (suffix degradation) and full verification wastes compute.

DSpark’s two changes target these pain points:

Semi-autoregressive generation architecture — not purely parallel draft, but “parallel backbone + lightweight serial head.” The backbone preserves speed, while the serial head restores neighboring token dependencies. Data in the paper is somewhat counterintuitive — 2-layer DSpark’s effective acceptance length exceeds the 5-layer pure-parallel DFlash.
Confidence-based scheduled verification — assign confidence scores to draft tokens, then use “sequential temperature scaling” to reduce score error from 3%–8% to ~1%. The system dynamically adjusts verification length based on real-time load — maxing out during idle times, trimming low-value tokens during busy periods.

The second point is especially interesting. It means DSpark is not just “making single requests faster,” but “keeping performance from dropping under high concurrency” — which ties directly to the goal of peak-valley pricing: peak pricing pushes away some demand, DSpark lets remaining demand consume less compute. One soft, one hard — together, they ease daytime resource pressure.

What Should Developers Change?

From an engineering perspective, adapting to this price adjustment boils down to three things:

First, review whether calls truly need to run during the day. Categorize traffic by business type, delay what can be delayed. A simple method is adding a peak_aware flag to the task queue, pushing flagged tasks to the post-6:00 PM window. For most batch-type jobs, this is just dozens of lines of code.

Second, maximize cache hit rate. V4-Pro’s cache hit price is ¥0.025/million tokens, cache miss is ¥3 — a 120× difference. Peak-hour rates double both numbers, but the relative gap remains 120×. In prompt design, place stable prefixes (system prompt, few-shot examples, knowledge base snippets) up front so caching actually works — more important than fussing over peak vs valley.

Third, fine-tune routing between V4-Pro and V4-Flash. Flash’s output price is one-third of Pro’s, and the absolute cost gap widens in peak hours. For steps that don’t require complex reasoning — intent recognition, light summarization, formatted output — use Flash, reserving Pro for tasks that truly need long-chain reasoning.

Fourth, if you have cross-vendor needs, use an aggregation layer to shield against single-supplier pricing fluctuations. Platforms like OpenAI Hub support DeepSeek V4, along with GPT, Claude, Gemini, and other mainstream models — a single key calls them all, OpenAI-compatible format integrates directly, and domestic connectivity avoids network hassle. After this peak-valley pricing is implemented, the cost of A/B routing or automatic downgrades during peak hours will be lower than connecting to DeepSeek’s official API alone.

A Large Model Company Starts Thinking Like a Cloud Vendor

The most noteworthy part of this price adjustment is not the numbers, but the signal.

The LLM API industry has been locked in a price war for the past two years — no one dared make bold moves. DeepSeek was the one driving prices to rock bottom, but now it’s saying “daytime use costs more,” meaning it believes its market position is stable enough to focus on profit as well as share; and it sees itself as an infrastructure company managing resource scheduling, not just a benchmark-chasing model team.

Parameter scale, inference speed, pricing mechanisms, scheduling strategies — all four are being optimized together within one company. This was something AWS did in the 2010s, a hallmark of cloud vendors reaching maturity. Among domestic large models, DeepSeek is the first to reach this stage.

Whether Alibaba Tongyi, Zhipu, or Moonshot will follow with peak-valley pricing remains to be seen. But the underlying logic is irreversible: compute capacity has limits, traffic has cycles, and pricing can be used as a scheduling signal. Once this page is turned, “API price” will no longer be a fixed number — it will be a time function.

Mid-July, the final release launch day is also the effective date of the new policy. Developers currently using DeepSeek are advised to review their billing structure in the next two weeks — see which calls can be shifted, which can’t, and which can be moved to Flash — it will be much more relaxed than scrambling after the final release goes live.