10x bigger
DeepSeek V4 is 284 Billion parameters.
Qwen3.8 is 27 Billion parameters.
50x expensive hardware
Qwen3.8 27B FP8 fits on a single RTX 6000 Blackwell (approx 15000 USD - 15 Lakh INR).
DeepSeek V4 generally is hosted using 4x H200. (approx 500000 - 5 crore INR).
API cost measured 5x Cheaper!
But API pricing of DeepSeek V4 is 5x cheaper than Qwen3.8 27B. 50x more expensive hardware, 10x more parameters, but API pricing 5x cheaper!
How? What explains this?
The numbers
This was a browser automation task. Experimented running it using two models. Great news - both finished the simple task effectively - surely usable.
| Model | Calls | Cost | First attempt |
|---|---|---|---|
| Qwen3.8 27B (xhigh) | 10 | $0.0293 | $0.0517 (28 calls) |
| DeepSeek V4 Flash 0731 | 8 | $0.0054 | $0.0052 (8 calls) |
| Total | 18 | $0.0347 | $0.0569 |
Qwen was about 5.4x DeepSeek ($0.0293 against $0.0054).
Answer: Concurrency and token efficiency
Paged attention and Continuous batching are fascinating solutions. Multiple users' tokens are physically in separate pages, but the model processes them all together as a single batched input; the paged attention allows the GPU to work with a contiguous view to perform the matrix operations, while the per-user KV cache and other data in memory are kept isolated.
These techniques are supported both in the RTX 6000 Blackwell as well as in the H200. But 4xH200 is more memory to start with coupled with aggressive KV compression in DeepSeek V4. These are likely contributing to at least 2x-4x more concurrent users.
So what explains the difference? The answer:
Higher token throughput per user and higher number of users
Two techniques change this.
Paged attention. Each request keeps a KV cache, the stored keys and values of every token so far. Reserving one big block per request wastes memory, because most requests never use the full length. Paged attention stores the cache in small fixed pages, allocated as needed. Less waste means more requests fit in memory at once.
Continuous batching. Instead of waiting for a whole batch to finish, the server adds new requests and drops finished ones at every generation step. The weights are read once per step and shared by every request in the batch. So the cost of reading the weights is split across many users, and the GPU stays busy.
Top comments (1)
On a different coding task today. The 5x claim did not hold.
The main takeaway, however, remains: Although DS V4 needs 4x H200, Qwen 27B may be H100 or A100 or such; the cost scaling is also dictated by token throughput, KV cache optimization, MoE effectiveness, Paging attention/continuous batching. Or, in other words, how many concurrent users the service provider is able to accommodate in parallel.
Qwen xhigh
Input: 216,796 | Output: 20,093
Total tokens: 236,889
Output share: 8.5%
Cost: $0.0318 | $0.134/1M tokens
Rounds: 8 | Cost/round: $0.0040
Turn time: 144s
Qwen low
Input: 90,444 | Output: 8,616
Total tokens: 99,060
Output share: 8.7%
Cost: $0.0139 | $0.140/1M tokens
Rounds: 4 | Cost/round: $0.0035
Turn time: 77s
DeepSeek V4 Flash
Input: 184,864 | Output: 3,711
Total tokens: 188,575
Output share: 2.0%
Cost: $0.0201 | $0.107/1M tokens
Rounds: 7 | Cost/round: $0.0029
Turn time: 34s
Some comments may only be visible to logged-in visitors. Sign in to view all comments.