The entire issue is caching, I tried to write some custom to dump to disk kv-caching using some ideas from their papers and my experience with snapshots and vm checkpoint systems, I must say they must have really squeezed that lemon it's hard.
Atleast me with Sol couldn't figure it out over a couple days, a few hours each day, which isn't much but I did feel a bit stuck with existing solutions and felt like I might have to write something from scratch. But if you are willing to put in the effort into the infra I do think it's doable. But it will be really hard to pull it off.
My congrats to anyone who manages to pull it off, they might be able to kill off most AI labs. Assuming they can find the compute, Deepseek really has killed all models for me other than Sol/Fable/Opus/K3 tier stuff.
And there is no way in hell anyone can afford caching prices same as what DeepSeek is offering, and DeepSeek keeps the cache available for an insane amount of time most providers will flush it in 5-mins like Claude/Anthropic (some offer customizing it but I am not sure of the pricing, it's load based on some like Fireworks, which means assume a couple minutes at most, they say several minutes god knows what that really means).
There is no way to match DeepSeek's current prices, "profitably" if you are renting a GPU and reselling tokens, unless you have some really amazing caching infra or something.
Deepseek's prices are just insanely cheap, I am not saying it's impossible to get there the overall performance suggests it should be feasible, but I will be damned if any provider could match their tps and caching any time soon at those same prices profitably.
I believe even if Deepseek 2-3x their prices across the board even then they would be cheaper for most long running tasks, that's just how good their caching is.
For one I have managed to hit the cache after over 24 hours on their system it's insane, I honestly didn't care because it was so cheap but it truly made me incredibly happy to think about the engineering that must have taken. TTFT is slightly worse, but it's good enough, for those cache prices I can take a few seconds worth of hit on TTFT.
It's interesting that most open models adding 1M context did it in a way that reduces KV cache size (though DeepSeek was the most aggressive, using compressed attention on all layers), but only a couple providers turned it into a discount on cache reads.
Can anyone working at one of the main US labs (Google, OpenAI, Anthropic) comment on WTF they haven't even tried MLA - despite the obvious massive advantages?
I know enough to know they aren't completely incompetent. So there must be a quite good reason.
But it remains a mystery to me.
DeepSeek's MLA is like almost 2 years old at this time. They've got thousands of people working on this stuff. They clearly have the ability to at least try it...
There’s a measurable performance tradeoff versus gqa so there’s reluctance.
For the most part though the new deepseek v4 tech is hca and mhc and people are still catching on like with moe and rl. Wait for 6 12 months, minimum time for next pre train.
The big US labs are opaque and don't publish much of any technical details anymore. We don't know what they are or aren't doing, honestly.
Deepseek charges $0.0028 per cache read on Openrouter. The next cheapest is $0.018.
That's a massive difference and quickly adds up on coding sessions (which often hit 95%+ cached tokens).
- input_cache_hit_tokens: 1,265,646,976 x 0.0000000028 = $3.5438115328
- input_cache_miss_tokens: 18,208,088 x 0.00000014 = $2.54913232
- output_tokens: 9,615,178 x 0.00000028 = $2.69224984
- request_count: 10,837 (no price)
Cache:
- Hit: 1,265,646,976
- Miss: 18,208,088
- Total input tokens: 1,283,855,064
They "can" is the caveat here. Rented GPUs are going up in pricing. I recently got an email that DigitalOcean pricing of GPUs were going up.
So
1. They have to get a hold of them (availability is bad)
2. They have to maintain the pricing
This adds disk as a tier in the HBM → CPU → Disk KV cache hierarchy.
There's also a cluster of related KV-offload FS PRs: #49225 (read/write batching, still open) and #49152 (batch store/load in C, merged Jul 28).
It's hard to say if these are similar to the approach DeepSeek takes but they definitely seem very interesting.