DEV Community: Sergei Solod

DeepSeek V4 Flash Got Expensive. I Kept the Model and Cut the API Cost Anyway

Sergei Solod — Mon, 17 Aug 2026 13:31:20 +0000

DeepSeek changed its API pricing, and my spending jumped almost overnight. Instead of replacing the model, I tried something simpler: keep the exact same V4 Flash checkpoint and move the inference somewhere else.

On August 17, I checked my API usage and initially assumed something in my application had gone wrong.

The balance was disappearing much faster than usual.

Not a little faster.

Roughly five times faster.

I already knew DeepSeek had announced a pricing change. I had seen the announcement a few days earlier, but I did not expect it to have such a large effect on my actual usage.

A 20% increase would have been annoying.

A 50% increase would have been noticeable.

Even doubling the price would not have surprised me that much.

But this was enough to make me stop and look at the numbers properly.

There was nothing wrong with my billing integration.

The new prices were simply live.

DeepSeek introduced peak and off-peak pricing for V4 Flash and V4 Pro starting at 16:00 UTC on August 16. Reuters had already reported that some DeepSeek prices were increasing anywhere from 50% to 1,100%, depending on the model, token type and time of day.

That was when I remembered an important detail.

DeepSeek V4 Flash is available as an open-weight model.

And that changes the problem completely.

Instead of asking:

Should I replace DeepSeek with another model?

I started asking:

Can I keep exactly the same model and just stop buying the inference from DeepSeek?

That turned out to be the more interesting question.

The old DeepSeek pricing was extremely cheap

Before the change, V4 Flash had pricing that was difficult to complain about.

Token type	Old price per 1M tokens
Input, cache miss	$0.14
Cached input	$0.0028
Output	$0.28

That is the pricing I had become used to.

The current official deepseek-v4-flash, which corresponds to DeepSeek-V4-Flash-0731, now has separate off-peak and peak rates.

Off-peak

Token type	Price per 1M tokens
Input, cache miss	$0.22
Cached input	$0.007
Output	$0.66

Peak

Token type	Price per 1M tokens
Input, cache miss	$0.44
Cached input	$0.014
Output	$1.32

DeepSeek currently lists the peak windows as:

01:00 to 04:00 UTC
06:00 to 10:00 UTC

My own spending being close to five times higher does not mean every possible DeepSeek request is exactly five times more expensive.

The actual increases depend on what kind of tokens you are paying for.

For example:

cache-miss input went from $0.14 to $0.44 at peak, about 3.14x
output went from $0.28 to $1.32 at peak, about 4.71x
cached input went from $0.0028 to $0.014 at peak, exactly 5x

If your application generates a lot of output, a bill that feels close to five times larger is not difficult to explain.

I did not want to keep paying those rates while spending several days slowly evaluating alternatives.

So I started searching immediately.

Changing providers is much easier than changing models

There are plenty of models I could have tested instead.

Qwen.

GLM.

Kimi.

MiniMax.

Mistral.

And many more.

But changing an LLM in a real application is not always a one-line configuration change.

Even when the API format is similar, behavior can move in ways that matter.

Prompts may need adjustment.

Answers may become longer or shorter.

The tone can change.

Sampling settings that worked well before may no longer be ideal.

Long-context behavior can differ.

Edge cases appear.

If the current model already works well, replacing it creates a new testing problem.

I wanted to avoid that problem.

My goal became very specific:

Keep DeepSeek V4 Flash 0731. Change only the infrastructure serving it.

Open weights create a separate inference market

This is the part I think developers sometimes overlook.

DeepSeek published the deepseek-ai/DeepSeek-V4-Flash-0731 checkpoint publicly on Hugging Face under the MIT License.

The weights are available.

Deployment information is available.

DeepSeek even documents a deployment example using vLLM on a single node with four GB300 GPUs.

So an inference company does not necessarily need to purchase API tokens from DeepSeek and resell those tokens to you.

It can operate the model itself.

Conceptually, I used to think about DeepSeek like this:

Application
    |
    v
DeepSeek API
    |
    v
DeepSeek V4 Flash

But with public weights, the picture is closer to this:

                  DeepSeek V4 Flash weights
                           |
          +----------------+----------------+
          |                |                |
          v                v                v
    DeepSeek API        Runware       Other providers
                                            |
                                            v
                                      Self-hosting too

DeepSeek created the model.

That does not mean DeepSeek has to be the only company selling inference for it.

Those are now two separate things.

And once I started looking at the market that way, the pricing became much more interesting.

How I searched for providers

I did not start with a list of famous inference companies.

I wanted to search broadly because smaller providers are often where the interesting prices are.

My process was basically this:

Ask an AI to help me create a very detailed research prompt.
Run that research repeatedly, usually around 15 to 20 separate searches.
Combine the results into one conversation.
Compare the providers.
Remove obviously unsuitable options.
Build a shortlist.
Verify the finalists manually.

I do not treat the AI's final ranking as truth.

That would be a mistake.

The useful part is breadth.

It can surface providers I would probably never discover by manually searching through the same five well-known companies.

Once I get to the shortlist, I check everything myself.

I open the provider's website.

I read the documentation.

I verify the model identifier.

I check the actual pricing.

And if it looks promising, I send real API requests.

That process eventually led me to Runware.

Runware was serving the exact checkpoint

The important part was not merely that Runware supported "DeepSeek."

It offered:

DeepSeek-V4-Flash-0731

That is what I wanted.

I was specifically trying to avoid introducing another model variable into the test.

At the time I checked, Runware's pricing for the checkpoint was:

Token type	Runware per 1M tokens
Input	$0.076
Cached input	$0.014
Output	$0.153

The first time I saw those numbers, I checked them again.

Not because Runware was cheaper than the new DeepSeek pricing.

I expected that.

What surprised me was that it was also substantially cheaper than the old DeepSeek pricing.

It was cheaper than DeepSeek before the increase

Take input first.

Old DeepSeek:

$0.14 / 1M

Runware:

$0.076 / 1M

That makes Runware roughly 45.7% cheaper.

Or viewed from the other direction, the old DeepSeek price was around 1.84x higher.

Now output.

Old DeepSeek:

$0.28 / 1M

Runware:

$0.153 / 1M

That is approximately 45.4% cheaper.

The old DeepSeek rate was about 1.83x higher.

This was the part I did not expect.

Finding a provider cheaper than DeepSeek after a major price increase is not surprising.

Finding the exact same public checkpoint for around 45% less than DeepSeek charged before the increase is much more interesting.

Against the new DeepSeek prices, the gap gets huge

For normal cache-miss input and output, the difference is now much larger.

DeepSeek off-peak vs Runware

Input:

$0.22 / $0.076 = ~2.9x

Output:

$0.66 / $0.153 = ~4.3x

DeepSeek peak vs Runware

Input:

$0.44 / $0.076 = ~5.8x

Output:

$1.32 / $0.153 = ~8.6x

There is one important exception.

DeepSeek's off-peak cached input currently costs:

$0.007 / 1M

Runware's cached input costs:

$0.014 / 1M

So DeepSeek is cheaper for that particular category during off-peak hours.

This is why comparing only one headline number can be misleading.

Your real cost depends on your own traffic.

An application with very high cache-hit rates may reach a different conclusion from an application generating large amounts of output.

Cheap pricing means nothing if the API is unreliable

At this point I still had no reason to trust Runware.

A pricing page is not a benchmark.

And cheap tokens are worthless if requests fail constantly.

So I funded the account, connected the API and started sending actual traffic.

One early dashboard snapshot looked like this:

790 requests
56 success
734 errors

Which looks awful.

Later I checked again:

1,570 requests
836 success
734 errors

The difference between those snapshots was:

+780 requests
+780 successful
+0 new errors

I want to be precise about what I am claiming here.

This does not prove some ridiculous five-nines reliability number.

It also does not tell us why the original 734 requests failed.

What it does tell me is very simple:

During the next batch of 780 requests, the success counter increased by 780 and the error counter did not increase at all.

I continued testing after that.

At the time I am writing this, I have already passed 1,000 successful AI requests through the Runware endpoint.

So far, the experience has been good.

The latency surprised me too

I was mostly looking for price differences.

Latency was secondary.

But the successful requests I checked were generally fast.

Most completed in somewhere between a fraction of a second and roughly 1.5 seconds.

Some of the smaller requests were costing around:

$0.000005

to:

$0.000018

per request.

After hundreds of successful calls, the total displayed spending was still around one cent.

That is when the comparison stopped feeling theoretical.

This was no longer:

Provider A says it costs X and Provider B says it costs Y.

The endpoint was connected to my application.

Requests were completing.

Responses were coming back quickly.

And the cost was tiny.

A necessary disclaimer about Runware

I want to be explicit about this because I am naming one company repeatedly.

This article is not sponsored.

Runware did not contact me.

I did not contact them before writing this.

Nobody asked me to publish anything.

I have no affiliate agreement.

No referral deal.

No discount code.

No free credits.

I found Runware while researching inference providers, created an account, deposited my own money and tested the API.

That is the entire relationship.

There is another important disclaimer.

I have been testing it for one day.

That is nowhere near enough time to declare a provider the best option on the market.

Maybe I discover reliability issues later.

Maybe its pricing changes.

Maybe performance gets worse.

Maybe another provider appears next week with better infrastructure and an even lower price.

If that happens, I will switch again.

I am not loyal to an inference endpoint.

I moved because DeepSeek's new pricing made me reconsider where I was buying compute.

Runware happened to be the provider that looked good enough to test immediately.

So far:

more than 1,000 requests have completed successfully
latency has been good in my testing
pricing is extremely low
the first day has gone well

That is the extent of my claim.

DeepSeek is now competing with companies that run DeepSeek

This is the most interesting part of the whole situation to me.

DeepSeek built the model.

Then it published the weights under a permissive license.

That means infrastructure companies can take the same model and compete on:

GPU utilization
batching
serving software
capacity planning
margins
geographic infrastructure
latency
reliability
pricing

In other words, DeepSeek is not only competing with Qwen, OpenAI, Anthropic, Mistral or other model developers.

For inference revenue, it can also end up competing with companies serving DeepSeek's own model.

When official V4 Flash inference cost $0.14 for input and $0.28 for output, that competition was easy to ignore.

The official API was already extremely cheap.

But when peak pricing becomes $0.44 input and $1.32 output while another provider offers the same checkpoint at $0.076 and $0.153, the infrastructure market starts to matter a lot more.

This is also why I do not think "Runware is reselling DeepSeek" is necessarily the right way to think about it.

If a provider is running public weights on its own hardware, then what you are purchasing is its inference infrastructure.

The model came from DeepSeek.

The compute came from someone else.

Did DeepSeek make a mistake by releasing the weights?

I do not think the answer is obvious.

It is tempting to look at these price differences and say:

DeepSeek created competitors for its own API business.

That is true in one narrow sense.

But open-weight models also gain advantages that closed models do not.

More developers can experiment with them.

More companies can integrate them.

Cloud providers can support them.

Inference platforms can optimize them.

Researchers can use them.

Businesses can deploy them privately.

The model can spread into places where a single proprietary API never would.

That adoption has value.

So I am not arguing that releasing V4 Flash was a bad business decision.

The claim I am comfortable making is much narrower:

Once a model's weights are publicly available under a permissive license, the company that created the model is no longer the only company capable of selling access to its inference.

When the creator's API is the cheapest and easiest option, nobody cares.

When the creator raises prices significantly, people start looking around.

I certainly did.

Why not just self-host V4 Flash?

I also considered the obvious next step.

If Runware can download the model and run it, why not do the same thing myself?

Because running a model like this is not the same thing as deploying a Node.js service onto a $20 VPS.

The model repository itself is large.

DeepSeek's own deployment example mentions four GB300 GPUs on one node.

And GPUs are only one part of the system.

You also need to think about:

enough VRAM
inference engines
model loading
batching
KV cache management
concurrency
networking
monitoring
capacity planning
failover
power
cooling
maintenance
keeping expensive GPUs utilized

Self-hosting can absolutely make sense at sufficient scale.

But there is a huge difference between:

I can download the weights.

and:

I can serve this model economically in production.

An inference provider can spread the cost of its hardware across many customers.

For my current usage, I cannot.

If somebody is willing to serve the model to me for $0.076 per million input tokens, buying the API can be much more rational than building the infrastructure myself.

If I had enough GPUs and capital, though, I would absolutely be interested in this market.

Running open models efficiently and selling inference is an interesting infrastructure business.

I just do not need to own that infrastructure today.

What I am changing after this

The main lesson for me is not specifically "use Runware."

That could change next week.

The bigger change is how I evaluate open-weight APIs.

Before this, my mental model was basically:

DeepSeek built the model
        ↓
DeepSeek sells the API
        ↓
That is the price of DeepSeek

Now I think about it more like:

Model creator
     ↓
Public weights
     ↓
Many companies compete to serve them
     ↓
Different prices, latency and reliability

And the numbers make the distinction hard to ignore.

Old DeepSeek V4 Flash:

Input:  $0.14 / 1M
Output: $0.28 / 1M

New DeepSeek peak pricing:

Input:  $0.44 / 1M
Output: $1.32 / 1M

Runware when I tested it:

Input:  $0.076 / 1M
Output: $0.153 / 1M

And I have already sent more than 1,000 successful AI requests through that endpoint.

Will I still use it a month from now?

Maybe.

Maybe not.

What I will definitely keep doing is this:

When a model has public weights, I will no longer assume that the model creator automatically has the best inference API.

I will identify the exact checkpoint.

I will find out who else serves it.

I will compare the real token pricing.

And then I will send actual requests before making a decision.

That is how I found a cheaper way to keep using DeepSeek V4 Flash without changing the model at all.

deepseek #ai #llm #api

My Next.js Blog: Global in a Week (21 Languages)

Sergei Solod — Tue, 17 Jun 2025 13:04:35 +0000

A little while ago, I decided to try a simple experiment: build a Next.js blog in 21 languages and see how search engines would handle it.

There was no big business plan behind it. I mostly wanted to test multilingual routing, localization, indexing, and SEO on a real project instead of another demo app.

After the first week, Google Search Console showed 439 impressions and 5 clicks.

Yandex had also started picking up some of the pages.

The numbers are obviously small, but for a brand-new personal blog, I was happy to see that Google was already discovering pages and showing them in search.

Why I used Next.js

The blog is built with Next.js, and every article has a separate version for each of the 21 supported languages.

I chose Next.js because it gave me a convenient setup for:

internationalized routing
server-side rendering
static generation
reusable layouts and metadata
generating a large number of localized pages

For this kind of project, that made the implementation much easier.

Of course, using Next.js does not automatically mean better rankings or faster indexing. It just gives you the tools to build pages that are easy for search engines to crawl and understand.

Google still decides what gets indexed and what gets shown in search.

The first search results

After roughly one week, I had:

439 Google impressions
5 clicks
about 1.1% CTR

Five clicks is not much traffic, but traffic was not really the interesting part yet.

What interested me was that the site had already started getting impressions across a large multilingual structure.

One article on my blog can exist as 21 separate URLs.

That creates a lot more possible search entry points than publishing only in English.

It does not mean 21 languages will give you 21 times more traffic. Each page still has to earn its own visibility.

But it does make the site much more interesting to monitor.

Indexing took longer

The next thing I started watching was indexing.

My sitemap.xml is generated automatically, and I submit it through Google Search Console.

A few weeks later, I had 471 pages in the group I was tracking.

Out of those:

436 pages were indexed
35 pages were still not indexed

So around 93% of those pages had made it into Google's index.

That was a useful reminder that discovery, indexing, impressions, and clicks are all different things.

Submitting a sitemap does not mean Google will immediately index every page.

An indexed page also does not mean it will rank or get traffic.

And if a new page has not been indexed yet, that does not automatically mean there is a serious SEO problem.

Multilingual sites scale very quickly

One thing that became obvious pretty fast is how quickly the number of pages grows.

If I publish one article, I am not really publishing one page.

I am publishing 21 localized pages.

Ten articles can become 210 URLs.

Twenty articles can become 420 URLs.

That means small technical mistakes can also get duplicated very quickly.

A problem with metadata, internal links, canonical tags, hreflang, translations, or URL structure can affect dozens or hundreds of pages instead of just one.

So multilingual publishing gives you more opportunities, but it also gives you more things to check.

What I learned so far

The biggest lesson for me is that multilingual SEO is not simply about creating as many translated pages as possible.

The technical side matters, but there are several separate questions:

Can Google discover the URLs?
Can Google crawl them correctly?
Which pages actually get indexed?
Which languages receive impressions?
Which pages receive clicks?
Which localized versions eventually start getting consistent search traffic?

At first, I mostly looked at the total number of impressions.

Now I think it is much more useful to look at each part separately.

Current result

So far, the experiment looks like this:

First week:

439 Google impressions
5 clicks
Yandex started showing some pages

A few weeks later:

471 pages tracked
436 indexed
35 still not indexed

I would not call that proof that multilingual SEO automatically works, or that Next.js gives some special SEO advantage.

But it does show that a small multilingual project can get discovered across a surprisingly large number of pages fairly quickly.

For me, the more interesting question now is not whether Google can find the site.

It is which languages and articles will eventually turn those impressions into consistent organic traffic.

Blog: https://jsvar.com/en/blog