Hóa đơn DeepSeek API không đơn giản là "số lần gọi nhân đơn giá", mà được quyết định bởi token đầu vào, token đầu ra và tình trạng trúng bộ nhớ đệm. Nhiều đội lập ngân sách theo giá niêm yết, nhưng sau khi lên tuyến lại thấy chi phí thực tế cao hơn một khoảng; nguyên nhân thường không phải đơn giá thay đổi, mà là cấu trúc đầu vào, tỷ lệ trúng bộ nhớ đệm và số lần thử lại khác với lúc ước tính.

Bài viết chia cách tính phí DeepSeek API thành các phần có thể tính toán: token nào bị tính phí, vì sao bộ nhớ đệm lúc có lúc không, cách dùng trường usage trong phản hồi để ước tính, và nên giảm chi phí theo thứ tự nào. Đơn giá cụ thể căn cứ theo bảng giá mô hình trên trang và tài liệu chính thức của DeepSeek.

Lưu ý: DeepSeek là nhãn hiệu của chủ sở hữu tương ứng. Bài viết dựa trên hình thức giao diện phổ biến tính đến tháng 10 năm 2026; giá, tên mô hình và quy tắc tính phí có thể điều chỉnh, vui lòng kiểm tra lại trang chính thức trước khi mua.

1. Chia hóa đơn thành bốn khoản tính phí

Khoản tính phí Khi nào phát sinh Yếu tố ảnh hưởng chính Hướng tối ưu
Đầu vào (trượt bộ nhớ đệm) Nội dung mới lần đầu vào ngữ cảnh Độ dài tài liệu, tin nhắn lịch sử, định nghĩa công cụ Truy xuất, tóm tắt, cắt tỉa
Đầu vào (trúng bộ nhớ đệm) Yêu cầu dùng lại tiền tố đã được đệm trước đó Độ ổn định tiền tố, tỷ lệ trúng Cố định tiền tố, giảm nội dung ngẫu nhiên
Đầu ra Mô hình sinh nội dung và kết quả có cấu trúc Độ dài đầu ra, ràng buộc định dạng max_tokens, ràng buộc JSON
Nội dung suy luận Mô hình suy luận sinh quá trình tư duy Độ khó câu hỏi, mức suy luận Tác vụ đơn giản không dùng mô hình suy luận

Bộ nhớ đệm ngữ cảnh của DeepSeek thường thể hiện ở phía đầu vào: tiền tố trúng được tính theo giá đầu vào thấp hơn, phần trượt tính theo giá đầu vào tiêu chuẩn. Có thu phí lưu trữ bộ nhớ đệm hay không, giữ bao lâu — căn cứ mô tả hiện tại trong tài liệu chính thức, đừng dùng lại quy tắc trong bài cũ.

Một yêu cầu đơn lẻ có thể viết thành công thức chi phí:

Chi phí một lần =
  Token đầu vào trúng đệm × đơn giá trúng
+ Token đầu vào trượt đệm × đơn giá đầu vào
+ Token đầu ra × đơn giá đầu ra

Đưa công thức này vào nhật ký mới trả lời được "tính năng này tốn bao nhiêu một tháng". Chỉ nhìn tổng hóa đơn trên bảng điều khiển thì rất khó xác định dự án nào, loại yêu cầu nào đang làm chi phí phình ra.

2. Vì sao bộ nhớ đệm tiết kiệm, và vì sao thường không có hiệu lực

Logic cơ bản của bộ nhớ đệm ngữ cảnh là: nếu phần đầu của hai yêu cầu giống hệt nhau, máy chủ có thể dùng lại kết quả tính toán trước đó và chỉ tính lại phần mới. Vì vậy bộ nhớ đệm hiệu quả nhất với:

  1. System prompt và thiết lập vai trò cố định.
  2. Định nghĩa công cụ, schema hàm ổn định.
  3. Đoạn cơ sở tri thức, cẩm nang sản phẩm, mẫu hợp đồng dùng lặp lại.
  4. Nửa đầu không đổi trong hội thoại nhiều lượt.

Ngược lại, những cách viết sau khiến bộ nhớ đệm mất hiệu lực thường xuyên:

  • Chèn thời gian hiện tại, ID ngẫu nhiên, biệt danh người dùng vào đầu system prompt.
  • Mỗi yêu cầu lại sắp xếp lại thứ tự công cụ hoặc tài liệu.
  • Đặt toàn bộ tài liệu lên đầu, câu hỏi người dùng để phía sau.
  • Cùng một nghiệp vụ lại chuyển qua lại giữa nhiều mô hình, nhiều điểm vào.
  • Tiền tố quá ngắn, chưa đạt mức có thể dùng lại.

Đặt nội dung thay đổi ở cuối yêu cầu và nội dung ổn định ở đầu là cách đơn giản nhất và hiệu quả nhất. Bộ nhớ đệm thường là nỗ lực tối đa, không cam kết trúng; vì vậy ngân sách nên ước tính theo "trúng một phần", đừng giả định trúng toàn bộ.

3. Dùng trường usage để ước tính thực tế

Đừng đoán token theo số chữ. Ghi lại trường usage trong phản hồi sau mỗi lần gọi, quan sát liên tục một tuần sẽ có được cấu trúc thực tế của nghiệp vụ mình.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

resp = client.chat.completions.create(
    model="deepseek-chat",  # tên mô hình căn cứ trang giá trên site
    messages=[
        {"role": "system", "content": "Bạn là trợ lý chăm sóc khách hàng, trả lời không quá ba câu."},
        {"role": "user", "content": "Sau khi đơn hàng đã gửi, có thể đổi địa chỉ không?"},
    ],
    max_tokens=256,
)

usage = resp.usage
hit = getattr(usage, "prompt_cache_hit_tokens", 0) or 0
miss = getattr(usage, "prompt_cache_miss_tokens", 0) or 0

print("Đầu vào", usage.prompt_tokens)
print("Trúng đệm", hit, "Trượt đệm", miss)
print("Đầu ra", usage.completion_tokens)

Nếu phản hồi không trả về trường chi tiết bộ nhớ đệm, hãy ghi tổng đầu vào và tổng đầu ra, rồi suy ngược từ hóa đơn hoặc trang sử dụng. Điều quan trọng là giữ cách hiểu trường dữ liệu nhất quán, đừng trộn dữ liệu các ngày khác nhau, các điểm vào khác nhau để so sánh.

Khi ước tính nên ghi ít nhất: thời gian, dự án, mô hình, token đầu vào, token đầu ra, trúng bộ nhớ đệm, số lần thử lại, có truyền phát hay không. Số tiền để cuối tháng nhân đơn giá; chỉ số quá trình phải xem mỗi ngày.

4. Cùng lượng gọi, vì sao hóa đơn chênh vài lần

Tình huống Cấu trúc token điển hình Điểm phình chi phí Trọng tâm tối ưu
Bot chăm sóc khách hàng Đầu vào nhiều, đầu ra ngắn Tin nhắn lịch sử truyền lại nhiều lần Tóm tắt, bộ nhớ đệm, chỉ mang vài lượt gần nhất
Trích xuất tài liệu Đầu vào trung bình, đầu ra có cấu trúc Cùng một tài liệu bị đọc lặp lại Đệm tiền tố, xử lý hàng loạt
Trợ lý mã nguồn Đầu vào và đầu ra đều lớn Kết quả công cụ và tệp dài Truy xuất, chia khối, giới hạn đầu ra
Sinh văn bản dài Đầu vào ngắn, đầu ra dài Token đầu ra tích lũy Sinh theo đoạn, max_tokens
Tác vụ suy luận Đầu vào trung bình, đầu ra gồm tư duy Quá trình tư duy tính vào đầu ra Tác vụ đơn giản đổi sang mô hình không suy luận

Khác biệt thường đến từ năm điểm:

  1. Tỷ lệ đầu vào/đầu ra khác nhau: chăm sóc khách hàng và viết văn bản dài có cấu trúc chi phí ngược nhau, không thể ước tính bằng cùng một giá trị trung bình.
  2. Tỷ lệ trúng bộ nhớ đệm khác nhau: tiền tố cố định dùng lại được, nội dung động làm đệm mất hiệu lực.
  3. Độ dài ngữ cảnh khác nhau: mỗi lượt lại nhét toàn bộ tài liệu vào, chi phí đầu vào tích lũy theo số lượt.
  4. Số lần thử lại khác nhau: gửi lại sau 429 hoặc quá thời gian làm tăng lượng yêu cầu; yêu cầu thất bại có bị tính phí hay không căn cứ hóa đơn.
  5. Mức mô hình khác nhau: mô hình suy luận và không suy luận có đơn giá, độ dài đầu ra khác nhau; ghép sai làm ngân sách phình ra.

5. Đừng đảo thứ tự giảm chi phí

  1. Định lượng trước: dùng usage và nhật ký tính cấu trúc token thật của từng chức năng, đừng dựa vào cảm giác.
  2. Tăng tỷ lệ trúng đệm: cố định system prompt, định nghĩa công cụ và tiền tố tri thức, giảm nội dung động ở đầu.
  3. Giảm đầu vào: RAG chỉ truy xuất đoạn liên quan, tóm tắt tin nhắn lịch sử, kết quả công cụ chỉ giữ trường cần thiết.
  4. Giới hạn đầu ra: đặt max_tokens hợp lý, yêu cầu JSON hoặc trường cố định, giảm giải thích lặp lại.
  5. Phân luồng mô hình: phân loại, trích xuất, viết lại dùng mô hình nhẹ; suy luận phức tạp mới nâng cấp.
  6. Bất đồng bộ và xử lý hàng loạt: đánh nhãn, tóm tắt, phân tích ngoại tuyến không cần trả ngay thì đưa vào hàng đợi.
  7. Giám sát và cảnh báo: xem mức dùng theo ba chiều dự án, mô hình, tình huống; đặt hạn mức ngân sách.

Đảo thứ tự thường dẫn đến kết cục: đổi sang mô hình rẻ hơn nhưng đầu vào chưa được quản trị, bộ nhớ đệm không trúng, hóa đơn không giảm mà chất lượng còn đi xuống.

6. Quản lý ngân sách và hóa đơn thế nào

  • Một dự án một khóa, tách kiểm thử và sản xuất để tránh chiếm dụng hạn mức của nhau.
  • Đặt hạn mức chi tiêu và cảnh báo cho khóa, có thể tự cắt lỗ khi gọi bất thường.
  • Đối chiếu hàng tuần theo "dự án, mô hình, tình huống", tìm các lần gọi tăng nhanh nhất.
  • Ghi riêng khoản tiết kiệm từ bộ nhớ đệm và phân luồng mô hình, nếu không sẽ không chứng minh được tối ưu có hiệu quả.
  • Đội cần thanh toán bằng nhân dân tệ và hóa đơn có thể dùng cổng AI trong nước để thống nhất hóa đơn; giá, tỷ giá và quy tắc hóa đơn cụ thể căn cứ theo bảng giá mô hình.

Câu hỏi thường gặp

Bộ nhớ đệm của DeepSeek có cần bật thủ công không?

Thường không cần đánh dấu đoạn đệm rõ ràng; máy chủ tự phán đoán theo tiền tố xem có dùng lại không; cơ chế và thời gian lưu cụ thể căn cứ tài liệu chính thức. Việc bạn cần làm là giữ tiền tố ổn định, chứ không phải thêm cấu hình.

Vì sao tỷ lệ trúng bộ nhớ đệm lúc cao lúc thấp?

Nguyên nhân thường gặp là tiền tố lẫn dấu thời gian, ID ngẫu nhiên, thông tin người dùng, hoặc yêu cầu chuyển giữa các mô hình, điểm vào khác nhau. Hãy đưa nội dung thay đổi xuống cuối trước, rồi quan sát một tuần.

Nội dung tư duy của mô hình suy luận có bị tính phí không?

Token tư duy do mô hình suy luận sinh ra thường được tính vào đầu ra; cách tính cụ thể căn cứ tài liệu chính thức và hóa đơn. Tác vụ phân loại, trích xuất đơn giản không nên mặc định dùng mô hình suy luận.

Đầu vào và đầu ra cái nào đắt hơn?

Đa số mô hình có đơn giá đầu ra cao hơn đầu vào, nhưng giá đầu vào sau khi trúng bộ nhớ đệm thường thấp hơn. Đừng chỉ so hai đơn giá; hãy tính chi phí một yêu cầu theo tỷ lệ đầu vào/đầu ra của chính bạn.

Vì sao ước tính và hóa đơn không khớp?

Các khoản dễ bị bỏ sót gồm tin nhắn lịch sử, định nghĩa công cụ, yêu cầu thử lại, trượt bộ nhớ đệm và đầu ra dài. Dùng ID yêu cầu đối chiếu nhật ký sử dụng mới định vị được chênh lệch.

Bước tiếp theo

Trước hết tạo khóa kiểm thử tại ZSQH AI Gateway, chạy một tuần với tác vụ thật, ghi lại đầu vào, đầu ra và trúng bộ nhớ đệm, rồi quy đổi ngân sách theo bảng giá mô hình. Mô hình khả dụng và giá căn cứ trang giá.

Đọc thêm: