DeepSeek đã xây dựng cộng đồng nhà phát triển dựa trên một đề xuất đơn giản: mô hình gần tiên tiến với mức giá rất thấp. Ngày 6 tháng 8 năm 2026, công ty cảnh báo đề xuất đó sắp thay đổi. Theo thông tin được Dataconomy đưa tin đầu tiên, DeepSeek cho biết giá API sẽ tăng “trong thời gian tới” và mức tăng dự kiến sẽ “đáng kể”. Chưa có con số cụ thể, ngày hiệu lực hay phân tích theo từng mô hình/bậc giá.
Bối cảnh khiến cảnh báo này đáng được xử lý ngay. DeepSeek viện dẫn chi phí tính toán tăng, tắc nghẽn dung lượng và lượng truy cập lớn trên V4-Flash và V4-Pro. Đây là thay đổi giá thứ hai trong chưa đầy một tháng: giá cao điểm/thấp điểm đã được áp dụng vào giữa tháng 7, trong khi V4-Pro 0813 đạt trạng thái khả dụng rộng rãi vào ngày 12 tháng 8. eWeek nhận định đây là phép thử cho lợi thế chi phí thấp từng khiến DeepSeek trở thành lựa chọn mặc định của nhiều nhóm tại APAC và các khu vực khác.
Bạn không kiểm soát được bảng giá mới. Nhưng bạn kiểm soát được số token mua, tỷ lệ cache hit, mô hình sử dụng, thời điểm chạy batch và nhà cung cấp dự phòng. Bài viết này tập trung vào các bước triển khai có thể thực hiện ngay trước khi giá thay đổi.
TL;DR
- DeepSeek đã thông báo tăng giá API “đáng kể” vào ngày 6 tháng 8 năm 2026, nhưng chưa nêu mức tăng hoặc ngày áp dụng.
- Đòn bẩy lớn nhất là prompt prefix caching: token đầu vào cache-hit có chi phí dưới 1% token cache-miss trên V4-Pro.
- Dùng V4-Flash cho tác vụ đơn giản, lưu V4-Pro cho suy luận sâu hoặc luồng tác nhân nhiều bước.
- Đưa workload batch sang khung giờ thấp điểm do DeepSeek công bố.
- Thiết lập nhà cung cấp dự phòng và kiểm thử cùng một bộ request trên cả hai.
- Ngay cả ở kịch bản tăng 3 lần, đầu ra V4-Pro sẽ là $2.61 / triệu token, thấp hơn mức so sánh công khai $25–30 / triệu token của các đối thủ tiên phong.
DeepSeek đã công bố gì và chưa công bố gì
DeepSeek mới xác nhận ba điểm:
- Giá trên toàn bộ API sẽ tăng “trong thời gian tới”.
- Mức tăng sẽ “đáng kể”.
- Nguyên nhân là chi phí tính toán, tắc nghẽn dung lượng và lưu lượng cao trên V4-Flash/V4-Pro.
Tính đến ngày 13 tháng 8, giá hiện tại vẫn được áp dụng.
Các thông tin chưa được công bố gồm:
- Mức tăng cụ thể.
- Ngày có hiệu lực.
- V4-Flash và V4-Pro có tăng cùng hệ số hay không.
- Giá cache-hit có thay đổi tỷ lệ với cache-miss hay không.
- Workload suy luận có bị tính giá khác không.
Các thảo luận trên Hacker News dự đoán mức tăng 2–3 lần, nhưng đây chỉ là suy đoán. Hãy lập kế hoạch theo một khoảng kịch bản thay vì giả định một con số duy nhất.
| Mô hình | Đầu vào cache-miss | Đầu vào cache-hit | Đầu ra |
|---|---|---|---|
| DeepSeek V4-Pro | $0.435 / M token | $0.003625 / M token | $0.87 / M token |
| DeepSeek V4-Flash | $0.14 / M token | $0.28 / M token |
Cả hai mô hình có cửa sổ ngữ cảnh 1 triệu token. Xem thêm hướng dẫn giá API DeepSeek V4 và bảng giá trực tiếp trong tài liệu API DeepSeek.
Hai chênh lệch trong bảng là cơ sở cho toàn bộ kế hoạch:
- Đầu vào cache-hit trên V4-Pro rẻ hơn rất nhiều so với cache-miss.
- V4-Pro có giá khoảng gấp 3 lần V4-Flash ở cả đầu vào lẫn đầu ra.
Bước 1: Đo chi tiêu theo tính năng trước khi tối ưu
Trước khi sửa prompt hoặc đổi model, hãy xác định chính xác feature nào tạo ra chi phí.
Gắn metadata vào mọi lệnh gọi model và lưu token usage trả về từ API:
usage = response.usage
log.info("llm_call", extra={
"feature": "ticket-summarizer",
"model": "deepseek-v4-flash",
"input_tokens": usage.prompt_tokens,
"output_tokens": usage.completion_tokens,
"cache_hit_tokens": usage.prompt_cache_hit_tokens,
})
Tối thiểu, dashboard chi phí của bạn nên nhóm theo:
-
featurehoặc API endpoint. -
model. - Input token và output token.
- Cache-hit token và cache-miss token.
- Thời điểm gọi để tách workload realtime và batch.
Bạn có thể áp dụng mẫu trong bài cách theo dõi chi tiêu API OpenAI theo tính năng cho DeepSeek.
Sau khoảng một tuần dữ liệu, hãy trả lời bốn câu hỏi:
- Feature nào chiếm phần lớn chi phí?
- Tỷ lệ input token cache-hit hiện tại là bao nhiêu?
- Bao nhiêu traffic V4-Pro thực chất có thể chạy trên V4-Flash?
- Ở hệ số tăng giá nào, mỗi feature sẽ phá vỡ unit economics?
Câu trả lời cho câu 4 là ngưỡng chuyển đổi hoặc chia lưu lượng của bạn.
Bước 2: Tối đa hóa prompt cache hit
DeepSeek tự động cache các tiền tố prompt. Nếu phần token mở đầu của request khớp với một request gần đây, phần lặp lại đó được tính theo giá cache-hit.
Trên V4-Pro:
- Cache-miss:
$0.435 / M token - Cache-hit:
$0.003625 / M token
Bạn không có cờ bật/tắt cache hoặc TTL để quản lý. Hiệu quả phụ thuộc vào việc prompt của bạn có ổn định hay không. Nếu cần ôn lại cơ chế, xem prompt caching là gì và cách hoạt động.
Sắp xếp prompt để tiền tố ổn định theo byte
Đưa phần không đổi lên đầu prompt:
System prompt
→ Tool definitions
→ Few-shot examples
→ Policy text
→ User-specific data
→ Retrieved documents
→ Latest user message
Checklist triển khai:
- Giữ system prompt giống hệt nhau giữa các request.
- Giữ thứ tự tool definition cố định.
- Không chèn timestamp, request ID hoặc lời chào cá nhân hóa ở đầu prompt.
- Không serialize object hoặc danh sách tool theo thứ tự không xác định.
- Đẩy dữ liệu phiên, tài liệu RAG và tin nhắn mới nhất xuống cuối.
Ví dụ không nên làm:
system_prompt = f"""
Current time: {datetime.now()}
Request ID: {request_id}
You are a support assistant.
"""
Ví dụ tốt hơn:
system_prompt = """
You are a support assistant.
Follow the support policy below.
"""
Sau đó, truyền dữ liệu động trong message phía sau:
messages = [
{"role": "system", "content": system_prompt},
{"role": "user", "content": user_message},
]
Điều này đặc biệt quan trọng với agent nhiều lượt. Nếu bạn gửi lại toàn bộ lịch sử hội thoại ở mỗi lượt, mọi token trước tin nhắn mới nhất có thể hưởng giá cache-hit — miễn là tiền tố không bị thay đổi.
Theo dõi cache-hit rate từ mỗi phản hồi
DeepSeek trả usage trong response. Tính cache-hit rate và ghi theo feature:
u = response.usage
total_cached_input = (
u.prompt_cache_hit_tokens +
u.prompt_cache_miss_tokens
)
hit_rate = (
u.prompt_cache_hit_tokens / total_cached_input
if total_cached_input else 0
)
Nếu một feature có cấu trúc lặp lại nhưng cache-hit rate thấp, hãy kiểm tra:
- System prompt có bị thay đổi theo request không?
- Tool list có thay đổi thứ tự không?
- Có metadata động ở đầu prompt không?
- RAG context có bị chèn trước phần ổn định không?
Đây thường là tối ưu có thể hoàn thành trong một ngày và tiếp tục mang lại lợi ích ở mọi bảng giá sau này.
Bước 3: Định tuyến theo tác vụ, không theo thói quen
Dùng V4-Pro làm mặc định có thể hợp lý khi prototype, nhưng không hợp lý nếu bạn đang dùng nó để phân loại hoặc format JSON.
| Dạng workload | Nên định tuyến |
|---|---|
| Phân loại, trích xuất, format, intent routing | V4-Flash, suy nghĩ tối thiểu |
| Tóm tắt, trả lời RAG, bản nháp đầu tiên | Ưu tiên V4-Flash; chỉ nâng lên Pro khi eval thất bại |
| Agent nhiều bước, debug khó, phân tích kiến trúc | V4-Pro, có ngân sách suy nghĩ |
Triển khai router đơn giản theo loại tác vụ:
def select_model(task_type: str) -> str:
flash_tasks = {
"classification",
"extraction",
"json_formatting",
"intent_routing",
"summarization",
}
if task_type in flash_tasks:
return "deepseek-v4-flash"
return "deepseek-v4-pro"
Đừng chỉ đo latency hoặc chi phí. Hãy đo chất lượng bằng eval của chính sản phẩm:
result = run_eval_suite(
model="deepseek-v4-flash",
feature="ticket-summarizer",
)
if result.pass_rate >= 0.95:
rollout_model("ticket-summarizer", "deepseek-v4-flash")
Kiểm soát ngân sách suy nghĩ
Token suy luận được tính như token đầu ra. Trên V4-Pro, đây là loại token đắt nhất trong bảng giá: $0.87 / M token.
Nguyên tắc thực tế:
- Tác vụ cơ học: không dùng hoặc dùng suy nghĩ tối thiểu.
- Tác vụ có đánh giá rõ ràng: thử Flash trước.
- Tác vụ cần lập luận nhiều bước: dùng Pro với ngân sách suy nghĩ phù hợp.
Hãy giảm model hoặc ngân sách suy nghĩ dựa trên kết quả eval, không dựa trên cảm tính.
Bước 4: Chuyển workload batch sang giờ thấp điểm
DeepSeek đã giới thiệu giá cao điểm/thấp điểm vào giữa tháng 7. Khung giờ và mức giảm hiện tại nằm trong tài liệu API DeepSeek.
Đưa vào hàng đợi các workload không yêu cầu phản hồi tức thời:
- Chạy eval hằng đêm.
- Backfill embedding.
- Gắn nhãn tập dữ liệu.
- Regression test prompt trong CI.
- Tạo dữ liệu tổng hợp.
- Tóm tắt hoặc xử lý tài liệu hàng loạt.
Thay vì gọi API ngay khi job được tạo, hãy đặt release window:
def should_run_batch_job(now_utc):
return is_deepseek_off_peak_window(now_utc)
if should_run_batch_job(now_utc()):
process_batch_jobs()
else:
enqueue_for_next_window()
Việc này không yêu cầu đánh giá lại chất lượng vì model và token không đổi; chỉ thời gian chạy thay đổi.
Lưu ý: DeepSeek chưa xác nhận mức chênh lệch giá thấp điểm có được duy trì sau lần tăng giá sắp tới hay không. Hãy tận dụng khi còn áp dụng và kiểm tra lại ngay khi bảng giá mới xuất hiện.
Hóa đơn của bạn ở mức tăng 1.5 lần, 2 lần và 3 lần
Đây là các kịch bản minh họa, không phải dự đoán.
Giả sử workload hằng tháng:
- V4-Pro: 400 triệu input token, cache-hit rate 60%, 60 triệu output token.
- V4-Flash: 600 triệu input token, 120 triệu output token.
Chi phí cơ sở:
V4-Pro:
- Cache-miss: $69.60
- Cache-hit: $0.87
- Output: $52.20
= $122.67
V4-Flash:
- Input: $84.00
- Output: $33.60
= $117.60
Tổng: $240.27
Cột “đã tối ưu” giả định bạn thực hiện Bước 2–3:
- Cache-hit rate của Pro tăng từ 60% lên 85%.
- Output token của Pro giảm từ 60 triệu xuống 45 triệu.
- Flash giữ nguyên.
| Kịch bản tỷ lệ | Hóa đơn chưa tối ưu | Đã tối ưu (Bước 2–3) |
|---|---|---|
| Giá hiện tại | $240 | $184 |
| Tăng 1.5 lần | $360 | $276 |
| Tăng 2 lần | $481 | $368 |
| Tăng 3 lần | $721 | $552 |
Điểm chính: workload đã tối ưu ở mức tăng 2 lần ($368) có chi phí gần bằng workload chưa tối ưu ở mức tăng 1.5 lần ($360).
Tối ưu cấu trúc có giá trị tăng theo hệ số giá:
- Tiết kiệm khoảng
$56ở giá hiện tại. - Tiết kiệm khoảng
$168trong kịch bản tăng 3 lần.
Bảng chưa tính mức giảm giá thấp điểm, vì điều đó phụ thuộc vào lịch chạy thực tế. Vì vậy, đây là một ước tính thận trọng.
Khi nào nên chuyển model thay vì tiếp tục tối ưu?
Ngay cả ở kịch bản tăng 3 lần, đầu ra V4-Pro là $2.61 / M token. Các so sánh công khai đặt đầu ra của các đối thủ tiên phong trong khoảng $25–30 / M token. Điều này cho thấy lợi thế chi phí của DeepSeek có thể bị thu hẹp, nhưng chưa biến mất.
Tối ưu và duy trì DeepSeek khi
- DeepSeek vẫn vượt qua eval chất lượng của bạn.
- Chi tiêu tập trung vào traffic có thể cache hoặc route lại.
- Bạn có thể ổn định prompt prefix.
- V4-Flash đáp ứng được một phần workload hiện đang chạy Pro.
- Bạn còn thời gian kỹ thuật trước khi giá mới có hiệu lực.
Chuyển hoặc chia traffic khi
- Cache-hit thấp do bản chất workload: mỗi request chứa tài liệu dài và độc nhất.
- Bạn đang trả giá V4-Pro cho tác vụ mà model nhỏ hơn vượt qua eval.
- Hệ số tăng giá vượt ngưỡng unit economics đã tính ở Bước 1.
- Bạn cần giảm rủi ro phụ thuộc một nhà cung cấp.
Với đa số nhóm, phương án thực tế là kết hợp:
- Giữ DeepSeek ở các route thắng về chi phí trên mỗi kết quả đạt yêu cầu.
- Chuyển các route kém hiệu quả.
- Duy trì test suite tương đương cho nhà cung cấp chính và phương án dự phòng.
Bước 5: Kiểm thử nhà cung cấp dự phòng trước khi cần dùng
Đừng đợi đến khi giá thay đổi hoặc endpoint gặp vấn đề mới xây fallback.
Tạo cùng một collection request cho:
api.deepseek.com- Nhà cung cấp dự phòng của bạn, ví dụ các model DeepSeek được định giá độc lập qua OpenRouter
Dùng environment riêng cho từng nhà cung cấp:
{
"base_url": "https://api.deepseek.com",
"api_key": "{{DEEPSEEK_API_KEY}}",
"model": "deepseek-v4-flash"
}
{
"base_url": "https://provider.example.com",
"api_key": "{{FALLBACK_API_KEY}}",
"model": "fallback-model"
}
Sau đó, chạy cùng một bộ test cho cả hai environment và kiểm tra:
- HTTP status.
- Schema phản hồi.
- Tool-call format.
- Chất lượng đầu ra.
- Token usage.
- Latency.
- Chi phí ước tính theo route.
Bạn có thể dùng Apidog để xây collection một lần, chạy theo environment và lên lịch regression test.
Tổng kết
DeepSeek đã xác nhận giá sẽ tăng nhưng chưa công bố chi tiết. Khoảng thời gian hiện tại là lúc để giảm mức độ phơi nhiễm:
- Đo token usage và chi phí theo feature.
- Ổn định prompt prefix để tăng cache-hit rate.
- Route tác vụ đơn giản sang V4-Flash.
- Giới hạn suy nghĩ cho các tác vụ không cần suy luận sâu.
- Đưa batch job sang giờ thấp điểm.
- Kiểm thử nhà cung cấp dự phòng bằng cùng một bộ request.
Mỗi bước đều có thể đo lường và phần lớn chỉ mất vài ngày triển khai. Để thiết lập kiểm thử dự phòng trong một công cụ, hãy tải Apidog miễn phí: tạo test suite một lần, trỏ tới api.deepseek.com và endpoint dự phòng bằng các environment riêng, rồi lên lịch kiểm tra để phát hiện thay đổi trước khi chúng trở thành sự cố.
Top comments (0)