DeepSeek API

DeepSeek API là giao diện lập trình ứng dụng cho mô hình ngôn ngữ lớn DeepSeek. Về cơ bản, DeepSeek API tương thích cao với OpenAI API, với cấu trúc request tương tự, nhưng vẫn có một số khác biệt nhỏ tùy theo tính năng, giúp developer chuyển đổi hoặc tích hợp dễ dàng. Thay vì sử dụng OpenAI, bạn có thể trỏ SDK OpenAI tới DeepSeek và gọi các model của DeepSeek. DeepSeek API cho phép bạn gửi prompt (tin nhắn hội thoại) đến mô hình AI và nhận lại phản hồi. Nó phù hợp cho những ai muốn tích hợp trí tuệ nhân tạo của DeepSeek vào ứng dụng, dịch vụ hoặc quy trình tự động của riêng mình.

Ai nên dùng API? Nếu bạn là nhà phát triển hoặc startup muốn đưa AI DeepSeek vào sản phẩm (ví dụ chatbot, trợ lý ảo, phân tích dữ liệu tự động…), DeepSeek API là công cụ dành cho bạn. Ngược lại, nếu bạn chỉ muốn dùng DeepSeek để hỏi đáp thông thường hoặc sáng tạo nội dung mà không cần lập trình, bạn nên sử dụng ứng dụng web hoặc app chính thức của DeepSeek (thay vì API). Người dùng không có nền tảng lập trình thường sẽ thấy giao diện chat hoặc ứng dụng chính thức của DeepSeek dễ sử dụng hơn, còn API chủ yếu hướng đến developer.

Lưu ý: Bài viết này không cung cấp API key DeepSeek. Để sử dụng DeepSeek API, bạn cần đăng ký tài khoản trên nền tảng chính thức của DeepSeek và tạo API key tại platform.deepseek.com.

Tóm tắt nhanh cho developer

• Base URL API: https://api.deepseek.com (tương thích OpenAI). Bạn cũng có thể dùng https://api.deepseek.com/v1 cho mục đích tương thích, endpoint /v1 được cung cấp để tương thích với SDK OpenAI, nhưng không đại diện cho phiên bản model của DeepSeek.
• Các model chính: deepseek-chat và deepseek-reasoner. Theo tài liệu hiện tại, deepseek-chat và deepseek-reasoner tương ứng với model DeepSeek-V3.2 trên API, với context length 128K. Model deepseek-chat là chế độ thường (không “suy luận”) còn deepseek-reasoner là chế độ tư duy (Thinking mode, có chuỗi suy luận).
• Khi nào chọn model nào? Cả deepseek-chat và deepseek-reasoner đều hỗ trợ JSON Output và Tool Calls. Hãy sử dụng deepseek-chat cho các tác vụ hội thoại thông thường, trả lời trực tiếp, khi bạn ưu tiên tốc độ và chi phí. Chọn deepseek-reasoner khi bạn cần suy luận nhiều bước (thinking mode), phân tích sâu hơn hoặc giải quyết các vấn đề phức tạp. Nói ngắn gọn: dùng deepseek-chat cho câu trả lời nhanh, và dùng deepseek-reasoner khi cần logic nhiều bước hoặc phân tích chi tiết hơn.
• chi phí được tính theo số token và có thể thay đổi. Ví dụ tại thời điểm gần nhất: khoảng $0.28 / 1M input tokens và $0.42 / 1M output tokens. Hãy luôn kiểm tra trang Pricing chính thức để biết mức giá mới nhất.
• Tính năng hỗ trợ: Đáp ứng dạng JSON, Gọi hàm (Function Calling / Tool Calls), streaming, chuỗi hội thoại nhiều lượt… được DeepSeek API hỗ trợ với cấu trúc tương tự OpenAI và một số mở rộng riêng.
• Giới hạn tốc độ: DeepSeek không công bố quota cố định (RPM/TPM), nhưng áp dụng giới hạn động dựa trên tải hệ thống và lịch sử sử dụng. Bạn vẫn có thể gặp lỗi 429 khi gửi request quá nhanh. Hãy triển khai retry với exponential backoff và xử lý thêm các lỗi timeout hoặc 503.
• Hình thức stateless: Mỗi request API không lưu trạng thái hội thoại. Nếu bạn muốn hội thoại nhiều lượt, bạn cần gửi kèm lịch sử các tin nhắn trước đó trong mỗi request (chi tiết bên dưới).
• Bảo mật: API key cấp cho bạn cần được giữ bí mật, tuyệt đối không để lộ trong code phía client. (Xem thêm mục bảo mật bên dưới và FAQ cho người mới.)

Cần chuẩn bị gì trước khi gọi API?

Trước khi bắt tay viết code gọi DeepSeek API, bạn cần chuẩn bị một số thứ sau:

• Tài khoản DeepSeek: Hãy đăng ký một tài khoản trên trang chính thức DeepSeek (web hoặc app). Việc đăng ký tài khoản cho phép bạn truy cập vào nền tảng Developer của DeepSeek.
• API Key: Đăng nhập vào nền tảng DeepSeek (trang Developer Platform), truy cập mục quản lý API để lấy API key riêng của bạn. API key là một chuỗi bí mật do DeepSeek cấp để xác thực các request API của bạn. Bạn sẽ dùng nó để xác thực mỗi khi gọi API. (Lưu ý: deepseek-vietnam.chat không cung cấp API key, bạn phải lấy từ trang chính thức DeepSeek).
• Số dư hoặc hạn mức: DeepSeek API hoạt động theo mô hình tính phí theo token. Khi tạo tài khoản, DeepSeek sử dụng hai loại số dư: granted balance và topped-up balance. Tuy nhiên, không nên giả định rằng tài khoản mới luôn có credit miễn phí. Hãy kiểm tra trực tiếp trong trang Billing hoặc qua endpoint GET /user/balance. Kiểm tra số dư trong tài khoản Developer của bạn. Nếu sắp hết, bạn cần nạp tiền (top-up) để tiếp tục sử dụng API. Nếu không, bạn sẽ gặp lỗi 402 (thiếu credit) khi gọi API.
• Môi trường lập trình: Bạn có thể gọi API từ bất kỳ ngôn ngữ nào hỗ trợ HTTP. DeepSeek API tuân thủ chuẩn REST (JSON qua HTTP) tương tự OpenAI, nên có thể dùng ngay các HTTP client (cURL, Axios, requests, v.v.). DeepSeek cũng tương thích với các OpenAI SDK. Ví dụ: bạn có thể dùng SDK OpenAI (tương thích với DeepSeek API) trong Python hoặc Node.js, chỉ cần cấu hình base URL trỏ đến api.deepseek.com. Trong hướng dẫn này, chúng ta sẽ minh họa bằng cURL, Python và Node.js.
• Biến môi trường cho API key: Không nên viết thẳng API key vào mã nguồn. Thay vào đó, lưu API key vào biến môi trường (ví dụ: DEEPSEEK_API_KEY) trên hệ thống hoặc file cấu hình (như .env). Sau đó, trong code bạn đọc giá trị này. Cách này giúp bảo mật khóa và tránh rò rỉ khi chia sẻ code.

Sau khi có những thứ trên, bạn đã sẵn sàng thử gọi DeepSeek API.

First API Call

Giờ chúng ta sẽ thực hiện cuộc gọi DeepSeek API đầu tiên. Ở đây, ta gọi API dạng Chat Completion (hoàn thành hội thoại), tương tự như gọi ChatGPT. DeepSeek API dùng endpoint chat completions gần giống OpenAI (POST /chat/completions). Mỗi request cần gửi mô hình, mảng messages (vai trò + nội dung), và API sẽ trả về message phản hồi.

Chúng ta sẽ thử gửi một lời chào đơn giản đến mô hình để xem phản hồi ra sao. Dưới đây là ví dụ bằng cURL, Python và Node.js. (Trước khi chạy, hãy đảm bảo thay DEEPSEEK_API_KEY bằng API key thật của bạn hoặc đã thiết lập biến môi trường tương ứng).

Gọi API bằng cURL

curl https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${DEEPSEEK_API_KEY}" \
  -d '{
        "model": "deepseek-chat",
        "messages": [
            {"role": "system", "content": "You are a helpful assistant."},
            {"role": "user", "content": "Xin chào!"}
        ],
        "stream": false
      }'

Giải thích: Lệnh trên gửi một POST request đến endpoint chat/completions. Chúng ta đặt header Authorization với Bearer token là API key. Nội dung JSON bao gồm:

• "model": "deepseek-chat" – chọn model chat thường.
• "messages": [...] – mảng hội thoại với một prompt. Ở đây ta thiết lập hệ thống (system) mô tả vai trò AI là “assistant hữu ích”, và một tin nhắn người dùng (user) là “Xin chào!”.
• "stream": false – tắt chế độ streaming cho đơn giản (mặc định nếu không gửi tham số này thì cũng là false).

Kết quả trả về sẽ là JSON chứa phản hồi. Bạn có thể chạy lệnh cURL này trong terminal (sau khi export biến môi trường chứa API key) để kiểm tra. Nếu request thành công, API sẽ trả về một phản hồi từ model.

Gọi API bằng Python

Trong Python, ta có thể dùng thư viện openai để gọi DeepSeek do tính tương thích. Cài đặt bằng pip install openai nếu chưa có. Sau đó:

import os
from openai import OpenAI

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

response = client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Xin chào!"}
    ],
    stream=False,
)

print(response.choices[0].message.content)

Giải thích: Ở đây:

• Ta khởi tạo client OpenAI với apiKey từ biến môi trường DEEPSEEK_API_KEY.
• Thiết lập base_url trỏ đến https://api.deepseek.com để SDK gửi request đến DeepSeek thay vì OpenAI.
• Gọi client.chat.completions.create với model và messages tương tự như cấu trúc JSON ở ví dụ cURL.
• Kết quả trả về dạng object; đoạn code trên in ra nội dung phản hồi đầu tiên.

Ví dụ này sẽ in phản hồi từ DeepSeek (thường là một lời chào lại từ AI). Bạn có thể chạy thử đoạn code (nhớ cài thư viện openai trước).

Gọi API bằng Node.js

Với Node.js, ta cũng có thể dùng SDK OpenAI (npm install openai). Cách dùng tương tự:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.DEEPSEEK_API_KEY,
  baseURL: "https://api.deepseek.com",
});

async function callAPI() {
  const completion = await client.chat.completions.create({
    model: "deepseek-chat",
    messages: [
      { role: "system", content: "You are a helpful assistant." },
      { role: "user", content: "Xin chào!" }
    ],
  });

  console.log(completion.choices[0].message.content);
}

callAPI();

Giải thích: Đoạn code Node.js trên khởi tạo client OpenAI với baseURL trỏ đến DeepSeek API và apiKey lấy từ biến môi trường. Sau đó gọi chat.completions.create tương tự Python. Kết quả in ra console nội dung phản hồi.

Nếu mọi thứ được cấu hình đúng, model sẽ trả về một phản hồi phù hợp với prompt bạn gửi.

Bạn đã thực hiện thành công lời gọi DeepSeek API đầu tiên! Tiếp theo, chúng ta sẽ tìm hiểu sâu hơn về cách chọn model, dùng các tính năng nâng cao và tối ưu hóa.

Chọn model nào: deepseek-chat hay deepseek-reasoner?

DeepSeek cung cấp hai model thông qua API: deepseek-chat và deepseek-reasoner. Theo tài liệu hiện tại, deepseek-chat và deepseek-reasoner cùng ánh xạ tới DeepSeek-V3.2 trên API, nhưng hoạt động ở hai chế độ khác nhau:

• deepseek-chat: Đây là chế độ bình thường (Non-thinking mode). Mô hình sẽ trả lời trực tiếp dựa trên prompt mà không xuất ra chuỗi suy nghĩ. Chế độ này tương tự cách ChatGPT hoạt động – bạn hỏi, nó trả lời một lần. Ưu điểm: trong nhiều trường hợp, model này có thể phản hồi nhanh hơn và tiêu tốn ít output token hơn so với chế độ reasoning, vì không bao gồm phần suy luận nội bộ. Dùng deepseek-chat cho những tác vụ thông thường: hội thoại đơn giản, hỏi đáp nhanh, tóm tắt văn bản, viết nội dung… khi bạn không cần xem bước lập luận bên trong của mô hình.
• deepseek-reasoner: Đây là chế độ Thinking mode (suy luận). Trước khi đưa ra câu trả lời cuối cùng, mô hình sẽ tạo một chuỗi lập luận (chain-of-thought) dưới dạng ẩn (không phải nội dung trả lời cho người dùng) để tự phân tích vấn đề. Sau đó mới dựa trên lập luận đó để trả lời. Với API DeepSeek, bạn thậm chí có thể lấy được chuỗi lập luận này trong kết quả trả về (sẽ đề cập ở phần sau). Chế độ reasoner hữu ích cho các câu hỏi phức tạp, đòi hỏi suy nghĩ nhiều bước, giải toán, suy luận logic, hoặc khi tích hợp với công cụ bên ngoài (Tool Calling). Nhược điểm: do có thêm bước lập luận, mỗi phản hồi tốn nhiều token hơn (có phần reasoning + câu trả lời), chi phí có thể cao hơn một chút và trong một số tác vụ phức tạp có thể mất nhiều thời gian hơn so với chế độ chat thường.

Nên chọn cái nào? Quy tắc đơn giản:

• Hãy thử deepseek-chat trước cho hầu hết các trường hợp. Nó nhanh và tiết kiệm.
• Chuyển sang deepseek-reasoner nếu bạn thấy câu trả lời từ chat thường chưa đủ sâu, hoặc khi bạn muốn khai thác khả năng suy luận, giải thích của mô hình. Ví dụ: trong các bài toán cần từng bước, các câu hỏi cần phân tích lý do, hoặc khi bạn muốn model tự gọi hàm để lấy thông tin.
• Về giá, hai model có cùng đơn giá token. Tuy nhiên, reasoner thường dùng nhiều token đầu ra hơn (vì bao gồm cả giải thích tư duy nếu bạn lấy nó), nên tổng chi phí mỗi request có thể cao hơn chat thường một chút.
• Về giới hạn output: độ dài phản hồi phụ thuộc vào model và tham số max_tokens được cấu hình trong mỗi request. Các model reasoning thường được thiết kế để xử lý các tác vụ yêu cầu suy luận nhiều bước, do đó có khả năng tạo phản hồi dài hơn trong một số trường hợp. Tuy nhiên, giới hạn cụ thể có thể thay đổi theo từng model và cập nhật từ DeepSeek.

Tóm lại: deepseek-chat cho tác vụ thông thường hằng ngày. deepseek-reasoner cho tác vụ phức tạp cần suy nghĩ nhiều bước hoặc yêu cầu đặc biệt.

Streaming response (phản hồi dòng chảy liên tục)

Streaming cho phép nhận phản hồi dần dần theo kiểu dòng sự kiện (SSE), tương tự như cách ChatGPT hiển thị chữ từng chữ. Chế độ này rất hữu ích khi bạn muốn hiển thị kết quả cho người dùng trong thời gian thực thay vì đợi toàn bộ câu trả lời hoàn thành.

Để dùng streaming với DeepSeek API, bạn chỉ cần gửi "stream": true trong payload request. Khi đó:

• API sẽ bắt đầu trả về dữ liệu dưới dạng chuỗi các chunk. Mỗi chunk chứa một phần của câu trả lời (thường vài token một), trả về liên tục qua kết nối HTTP mở.
• Với yêu cầu non-streaming (stream: false), API sẽ đợi có đủ câu trả lời hoàn chỉnh rồi mới trả về JSON một lần. Còn streaming sẽ trả về nhiều phần: ban đầu có thể là thông tin thiết lập, sau đó các chunk với field delta chứa token mới, và kết thúc bằng thông báo [DONE].

Khi dùng SDK OpenAI, thư viện sẽ tự xử lý SSE và cung cấp cho bạn một iterator/generator để duyệt các chunk. Ví dụ trong Python:

response = client.chat.completions.create(
    model="deepseek-chat",
    messages=[...],
    stream=True
)

for chunk in response:
    if chunk.choices[0].delta.get("content"):
        print(chunk.choices[0].delta["content"], end="", flush=True)

Đoạn code trên yêu cầu streaming và duyệt qua từng chunk. Mỗi chunk, ta lấy phần delta.content (nếu có) và in ra liên tục. Kết quả là ta sẽ thấy câu trả lời được in dần từng phần, mô phỏng thời gian thực. Sau khi kết thúc, bạn có thể in dòng mới.

Khi nào nên dùng streaming? Khi bạn xây dựng ứng dụng giao tiếp với người dùng cuối (chatbot UI chẳng hạn) và muốn cải thiện trải nghiệm: hiển thị câu trả lời từng chữ để người dùng không phải chờ lâu. Ngoài ra, streaming giúp bạn hủy request giữa chừng nếu không cần thiết (tiết kiệm token) – ví dụ người dùng đã có câu trả lời mong muốn và bạn muốn ngừng dòng dữ liệu.

Lưu ý: Nếu server quá tải, ngay cả với streaming, bạn có thể thấy độ trễ ban đầu. DeepSeek sẽ gửi các thông điệp giữ kết nối (như : keep-alive) để bạn biết vẫn đang chờ. Kết nối sẽ tự đóng nếu sau 10 phút vẫn chưa có dữ liệu thực. Hãy đảm bảo client của bạn bỏ qua các dòng keep-alive hoặc dòng trống này.

Multi-turn conversation (Hội thoại nhiều lượt)

Như đã đề cập, DeepSeek API không lưu trạng thái hội thoại giữa các lượt gọi. Mỗi khi bạn gửi request, bạn cần bao gồm cả lịch sử cuộc trò chuyện (các messages trước đó) nếu muốn mô hình nhớ ngữ cảnh. Cách thực hiện rất tương tự OpenAI Chat API:

Giả sử bạn muốn có một cuộc trò chuyện qua lại nhiều bước với AI:

1. Ở lượt đầu tiên, bạn gửi một mảng messages chỉ chứa lời nhắc ban đầu (có thể kèm system hướng dẫn và user hỏi). Mô hình trả lời (assistant).
2. Ở lượt thứ hai, khi người dùng hỏi tiếp, bạn phải gửi lại toàn bộ lịch sử: bao gồm cả system message, user message ban đầu, assistant reply từ lượt trước, và user message mới. Mô hình sẽ dựa vào ngữ cảnh cả cuộc hội thoại để trả lời.
3. Tiếp tục như vậy cho các lượt sau: luôn gửi kèm tất cả tin nhắn trước (hoặc ít nhất là những tin nhắn bạn muốn mô hình “nhớ”).

Ví dụ: Lượt 1 hỏi: “Thủ đô của Pháp là gì?” -> (assistant trả lời “Paris”). Lượt 2 hỏi tiếp: “Thế còn Đức?” Khi gọi API lượt 2, messages phải gồm:

[
  {"role": "user", "content": "Thủ đô của Pháp là gì?"},
  {"role": "assistant", "content": "Thủ đô của Pháp là Paris."},
  {"role": "user", "content": "Thế còn Đức?"}
]

Như vậy mô hình mới hiểu “Đức” ở đây là nước Đức trong ngữ cảnh hỏi thủ đô.

Khi dùng Python code:

res1 = client.chat.completions.create(model="deepseek-chat", messages=messages)
answer1 = res1.choices[0].message.content

messages.append({"role": "assistant", "content": answer1})
messages.append({"role": "user", "content": "Thế còn Đức?"})

res2 = client.chat.completions.create(model="deepseek-chat", messages=messages)
answer2 = res2.choices[0].message.content

Như trên, ta duy trì một list messages và append các tin nhắn qua mỗi lượt.

Đối với deepseek-reasoner (thinking mode): Có một điểm cần chú ý. Kết quả trả về của reasoner thường bao gồm hai phần: reasoning_content (chuỗi suy luận nội bộ) và content (câu trả lời cuối).

Trong hội thoại nhiều lượt thông thường, khi bạn đưa phản hồi của assistant vào lịch sử, chỉ nên giữ phần content và bỏ reasoning_content. Điều này giúp tránh việc mô hình hiểu nhầm chuỗi suy luận nội bộ là nội dung đã được “nói ra” với người dùng.

Tuy nhiên, trong quá trình Tool Calls (gọi hàm) ở thinking mode, bạn cần giữ reasoning_content trong các bước trung gian để mô hình có thể tiếp tục suy luận chính xác. Khi hoàn tất vòng xử lý và chuyển sang câu hỏi mới, nên loại bỏ reasoning_content cũ và chỉ giữ lại content trong lịch sử hội thoại.

Tóm lại: chỉ giữ reasoning_content khi đang ở giữa quy trình suy luận/tool use; còn với hội thoại bình thường hoặc lượt hỏi mới, chỉ nên dùng content.

Tóm lại, để hội thoại nhiều lượt: bạn tự quản lý context các lượt trước trong mảng messages. DeepSeek sẽ tính phí cho các token lặp này nhưng nhờ context caching, chi phí sẽ rẻ hơn cho phần lặp lại (xem mục “tối ưu chi phí” bên dưới).

Thinking mode / reasoning (Chế độ suy luận)

Thinking mode (chế độ tư duy) của DeepSeek cho phép mô hình tự tạo ra “dòng suy nghĩ” trước khi trả lời, giúp nâng cao độ chính xác và khả năng suy luận. Đây chính là điểm khác biệt của deepseek-reasoner so với deepseek-chat.

Một số điều developer cần biết khi dùng reasoning mode:

• Bạn có thể kích hoạt thinking mode bằng cách chọn model "deepseek-reasoner" ngay trong request. Hoặc, DeepSeek cho phép một cách khác: nếu dùng model chat thường nhưng muốn bật tư duy, bạn có thể gửi tham số "thinking": {"type": "enabled"} trong payload (đối với OpenAI SDK, tham số này truyền qua extra_body). Tuy nhiên cách đơn giản nhất vẫn là chọn thẳng model reasoner.
• Đầu ra của reasoning mode: Phản hồi JSON của DeepSeek khi dùng deepseek-reasoner sẽ có cấu trúc đặc biệt:
  • message.reasoning_content – chứa chuỗi lập luận (chain-of-thought) mà mô hình tự tạo ra.
  • message.content – chứa câu trả lời cuối cùng mà mô hình đưa ra cho người dùng.
  • message.tool_calls – nếu trong quá trình suy luận mô hình có gọi công cụ nào (function call), danh sách các lần gọi sẽ nằm ở đây (xem phần Tool Calls).
• Nếu bạn chỉ gọi API và hiện kết quả cho người dùng cuối, có thể bạn không cần hiển thị reasoning_content. Thông thường chuỗi suy luận chỉ để tham khảo hoặc debug. Nhưng DeepSeek mở cho bạn lấy chuỗi này, đề phòng trường hợp bạn muốn hiển thị vì lý do nào đó (hoặc dùng cho pipeline xử lý riêng).
• Các tham số không hỗ trợ trong reasoner: Để đảm bảo tính nhất quán của suy luận, DeepSeek vô hiệu hóa một số tham số ngẫu nhiên trong chế độ tư duy. Cụ thể, các tham số như temperature, top_p, presence_penalty, frequency_penalty sẽ bị bỏ qua (dù bạn có gửi thì cũng không ảnh hưởng kết quả). Còn các tham số yêu cầu log như logprobs hay top_logprobs thì bị cấm – gửi chúng sẽ nhận lỗi 422. Nói cách khác, DeepSeek reasoner luôn hoạt động ở một chế độ cố định (có thể tương đương temperature ~0 để ưu tiên chính xác).
• Giới hạn token: giới hạn output phụ thuộc vào model hiện tại và cấu hình max_tokens. Theo tài liệu hiện tại, deepseek-reasoner có mức output mặc định và tối đa cao hơn deepseek-chat, nhưng bạn vẫn nên kiểm tra Models & Pricing để xác nhận giới hạn mới nhất trước khi triển khai.
• Multi-turn với reasoner: Nhắc lại, không đưa reasoning_content của lượt trước vào lượt sau. Chỉ dùng content (câu trả lời cuối) để làm lịch sử hội thoại.

Khi nào nên dùng thinking mode? Khi nhiệm vụ yêu cầu sự chính xác cao, giải quyết vấn đề phức tạp, hoặc bạn muốn mô hình giải thích bước làm. Ví dụ: giải toán nhiều bước, phân tích mã code, suy luận logic, hoặc implement một agent mà mô hình tự quyết định gọi hàm nào trước khi trả lời. Nếu chỉ cần câu trả lời ngắn gọn trực tiếp, chế độ chat thường có thể đủ.

JSON Output (Đầu ra JSON có cấu trúc)

DeepSeek API hỗ trợ chế độ JSON Output để tăng khả năng mô hình trả về kết quả ở dạng JSON hợp lệ, thuận tiện cho việc parse và xử lý tiếp theo. Tính năng này rất hữu ích khi bạn cần parse kết quả bằng chương trình – ví dụ yêu cầu mô hình trả về đáp án dưới dạng object, mảng JSON để tiện xử lý.

Để yêu cầu DeepSeek trả về JSON đúng định dạng, bạn nên thực hiện cả hai bước sau:

1. Đặt tham số đặc biệt "response_format": {"type": "json_object"} trong payload request. Tham số này báo cho API biết bạn mong muốn một chuỗi JSON.
2. Trong prompt (thường là system hoặc user message), hãy nhấn mạnh định dạng JSON. Nên bao gồm từ khóa “JSON” và cung cấp ví dụ mẫu về JSON mong muốn. Việc này giúp mô hình chắc chắn hiểu yêu cầu định dạng. Ví dụ, bạn có thể viết trong system message: “Trả lời dưới dạng JSON. Ví dụ output: { "kết quả": ... }”.
3. Ngoài ra, hãy đặt max_tokens đủ lớn để JSON trả về không bị cắt cụt giữa chừng. JSON thường dài hơn câu trả lời tự nhiên vì có thêm ký hiệu, dấu ngoặc.

Dưới đây là ví dụ: Giả sử ta muốn trích xuất câu hỏi và câu trả lời từ một đoạn văn, kết quả dưới dạng JSON với hai trường "question" và "answer".

import os, json
from openai import OpenAI

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

response = client.chat.completions.create(
    model="deepseek-chat",
    messages=messages,
    response_format={"type": "json_object"}
)

result = response.choices[0].message.content
data = json.loads(result)

Trong ví dụ trên, ta đặt response_format và đưa ví dụ định dạng JSON trong prompt. Mô hình DeepSeek sẽ cố gắng chỉ trả về JSON. Kết quả in ra có thể như:

{
    "question": "Thủ đô của Nhật Bản là gì?",
    "answer": "Tokyo"
}

Ta sau đó dùng json.loads để chuyển nó thành đối tượng (Python dict) và tiếp tục sử dụng.

Lưu ý: Chế độ JSON Output giúp giảm thiểu việc model nói lan man ngoài JSON. Tuy nhiên, đôi khi API vẫn có thể trả chuỗi rỗng hoặc gặp khó khăn (theo tài liệu, thỉnh thoảng có thể trả empty content khi dùng JSON mode). Nếu bạn gặp trường hợp kết quả rỗng hoặc lỗi parse, hãy:

Bổ sung: Nếu bạn bật response_format={“type”:”json_object”} nhưng không yêu cầu rõ trong prompt rằng model phải trả về JSON, request có thể trông như bị “kẹt”. Nguyên nhân là model có thể sinh whitespace liên tục cho đến khi chạm giới hạn token. Để tránh vấn đề này, luôn nhấn mạnh trong prompt rằng output phải là JSON hợp lệ.

• Thử điều chỉnh prompt (cung cấp ví dụ rõ ràng hơn, nhấn mạnh “trả lời JSON”).
• Đảm bảo bạn không để model trả lời quá dài vượt max_tokens (khi đó JSON bị cắt sẽ gây lỗi parse).
• Kiểm tra kỹ định dạng mẫu: JSON yêu cầu dấu ngoặc kép chuẩn, không dùng dấu nháy đơn cho key/value.

Tính năng này rất mạnh khi bạn cần output có cấu trúc – ví dụ trích xuất thông tin (entity extraction), trả lời theo format yêu cầu (danh sách, bảng JSON) mà không muốn viết code xử lý chuỗi phức tạp.

Tool Calls / Function Calling (Gọi hàm tích hợp công cụ)

Tool Calls cho phép mô hình DeepSeek gọi các “công cụ” bên ngoài trong quá trình tạo câu trả lời. Đây tương tự khái niệm Function Calling của OpenAI GPT. Bạn định nghĩa trước một số hàm (hoặc API) với tên, tham số, mô tả… Mô hình có thể quyết định gọi hàm đó với tham số cụ thể để lấy dữ liệu bổ sung rồi tiếp tục trả lời người dùng.

Hãy xem một ví dụ thực tiễn: Bạn muốn AI trả lời về thời tiết hiện tại. Rõ ràng mô hình không tự biết thời tiết theo thời gian thực, nhưng bạn có một API thời tiết hoặc một hàm get_weather(location) để lấy dữ liệu. Bạn có thể định nghĩa get_weather là một “tool” cho mô hình.

Cách định nghĩa tools: Khi gọi API DeepSeek, bạn có thể gửi tham số "tools" chứa danh sách các hàm. Mỗi tool là một đối tượng JSON với định dạng:

{
  "type": "function",
  "function": {
    "name": "tên_hàm",
    "description": "mô tả hàm để model hiểu khi nào dùng",
    "parameters": {
       // JSON Schema mô tả tham số hàm
    }
  }
}

Ví dụ, định nghĩa hàm get_weather:

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Lấy thông tin thời tiết cho một địa điểm do người dùng cung cấp.",
            "parameters": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "Thành phố và quốc gia hoặc tỉnh, ví dụ: Hà Nội, Việt Nam"
                    }
                },
                "required": ["location"]
            }
        }
    }
]

Ở đây, ta mô tả hàm get_weather yêu cầu một tham số location kiểu chuỗi.

Quy trình gọi hàm:

1. Gửi prompt người dùng cùng danh sách tools vào API. Ví dụ:
   messages = [
   {“role”: “user”, “content”: “Thời tiết ở Hà Nội hôm nay thế nào?”}
   ]
   response = client.chat.completions.create(
   model=”deepseek-chat”,
   messages=messages,
   tools=tools
   )
   result_msg = response.choices[0].message
2. Developer thực thi hàm: Lúc này nhiệm vụ của bạn là nhận yêu cầu đó, thực sự gọi hàm get_weather (mà bạn phải tự hiện thực, ví dụ gọi API thời tiết thật). Giả sử bạn gọi hàm và nhận được kết quả "30°C, có mây".
3. Gửi kết quả hàm về cho mô hình: Bạn append vào messages một message mới với vai trò “tool”, kèm tool_call_id để chỉ ra kết quả này thuộc về lời gọi hàm nào:
   result = “30°C, có mây”
   tool = result_msg.tool_calls[0]
   messages.append(result_msg) # assistant message yêu cầu hàm
   messages.append({
   “role”: “tool”,
   “tool_call_id”: tool.id,
   “content”: result
   })
   response2 = client.chat.completions.create(
   model=”deepseek-chat”,
   messages=messages,
   tools=tools
   )
   final_answer = response2.choices[0].message.content
   print(final_answer)
4. Mô hình nhận được kết quả từ tool và bây giờ nó sẽ trả lời người dùng dựa trên dữ liệu đó. final_answer có thể là: “Hôm nay ở Hà Nội khoảng 30°C, trời có mây.”.

Quy trình hơi dài dòng nhưng về cơ bản: mô hình quyết định gọi hàm, developer thực thi, rồi mô hình hoàn thiện trả lời. Toàn bộ quá trình đều qua API DeepSeek.

Thinking mode và Tool Calls: Kể từ DeepSeek-V3.2, chế độ suy luận (reasoner) cũng hỗ trợ gọi tool. Thậm chí trong thinking mode, mô hình có thể thực hiện nhiều vòng gọi công cụ và suy luận nội bộ phức tạp hơn trước khi trả lời cuối cùng.

Strict mode (chế độ nghiêm ngặt) – Beta: DeepSeek cung cấp chế độ strict để model tuân thủ chặt chẽ hơn với JSON Schema khi tạo function call. Tuy nhiên, đây vẫn là tính năng beta và hiệu quả thực tế còn phụ thuộc vào cách bạn định nghĩa schema.

• Để bật strict mode, bạn cần dùng base URL đặc biệt: https://api.deepseek.com/beta thay cho URL thường.
• Trong định nghĩa tools, đặt "strict": true cho mỗi hàm.
• Khi đó, server DeepSeek sẽ kiểm tra JSON output của model cho hàm. Nếu output không phù hợp schema (hoặc bạn khai báo schema sai quy cách), API sẽ trả về lỗi thay vì output đó.

Strict mode giúp bạn yên tâm rằng khi mô hình gọi hàm thì cú pháp JSON sẽ chuẩn. Tuy nhiên đây là tính năng beta, có thể thay đổi.

Tóm lại: Tool Calls cho phép mở rộng khả năng của mô hình bằng cách tích hợp với các công cụ hoặc API bên ngoài. Bạn có thể cho phép nó tra cứu dữ liệu, tính toán hay bất kỳ thao tác nào mà bạn cung cấp qua hàm. DeepSeek API hỗ trợ tính năng này, bạn chỉ cần định nghĩa hàm và xử lý kết quả theo quy trình trên. Nếu không dùng, bạn có thể bỏ qua tham số tools – mô hình sẽ chỉ tạo câu trả lời thuần túy từ dữ liệu trong prompt.

Cách tối ưu chi phí với Context Caching

Một điểm độc đáo của DeepSeek là cơ chế Context Caching (bộ nhớ đệm ngữ cảnh). Hiểu đơn giản, DeepSeek sẽ tự động lưu đệm những phần prompt lặp lại giữa các lần gọi API để tiết kiệm chi phí và tăng tốc độ.

• DeepSeek áp dụng cơ chế context caching để tối ưu các phần input lặp lại giữa các request. Khi xảy ra cache hit, các token đã được xử lý trước đó có thể được tái sử dụng, giúp giảm chi phí và độ trễ. Ngược lại, các token mới sẽ được tính là cache miss. Lưu ý rằng cơ chế này hoạt động theo best-effort, phụ thuộc vào mức độ trùng khớp của prefix và trạng thái hệ thống, và không được đảm bảo trong mọi trường hợp.
• Hoạt động mặc định: Bạn không cần làm gì thêm để dùng context cache – nó được bật sẵn cho tất cả user. Mỗi lần gọi, hệ thống DeepSeek sẽ tự kiểm tra phần prefix của prompt đã xuất hiện trong lần gọi trước chưa.
• Ví dụ tận dụng cache:
  • Bạn có một đoạn hướng dẫn dài trong system message dùng cho nhiều câu hỏi khác nhau. Lần đầu gửi đoạn đó, phần input này thường được tính như cache miss. Nếu các request sau lặp lại cùng prefix và cache hit xảy ra, chi phí cho phần lặp lại đó có thể thấp hơn đáng kể.
  • Trong hội thoại nhiều lượt, các tin nhắn trước (đã gửi ở lượt trước) khi gửi lại ở lượt sau sẽ được cache hit. Ví dụ: lượt 2 bạn gửi lại câu hỏi lượt 1 + câu trả lời lượt 1 + câu hỏi mới, thì phần câu hỏi và trả lời cũ sẽ rẻ hơn so với lần đầu.
  • Khi bạn làm few-shot learning (cung cấp một loạt ví dụ mẫu trong prompt rồi hỏi câu mới tương tự), phần ví dụ mẫu lặp đi lặp lại giữa các lần gọi sẽ chỉ tính giá cache hit.
• Kết quả là: Càng nhiều phần chung lặp lại, chi phí trung bình mỗi request càng giảm. Điều này khuyến khích bạn thiết kế prompt ổn định cho ứng dụng của mình. Ví dụ: hãy sử dụng cùng một chỉ dẫn system nhất quán cho mọi request thay vì thay đổi lung tung – như vậy chi phí cho phần lặp lại có thể giảm rõ rệt ở các request sau nếu cache hit xảy ra.
• Kiểm tra cache hit: Phản hồi API DeepSeek sẽ có kèm thông tin usage gồm số prompt_cache_hit_tokens và prompt_cache_miss_tokens. Bạn có thể xem để biết bao nhiêu token được cache. Nếu prompt_cache_hit_tokens lớn, nghĩa là bạn đang tiết kiệm được nhiều.
• Lưu ý: Cache hoạt động theo đơn vị khối 64 token, và “best-effort” (nỗ lực tối đa nhưng không đảm bảo 100% hit mọi lúc). Dữ liệu cache sẽ tự động giải phóng sau vài giờ hoặc vài ngày nếu không dùng. Ngoài ra, output (phần trả lời) vẫn tính phí bình thường – cache chỉ áp dụng cho phần prompt đầu vào.

Mẹo thiết kế prompt:

• Cố gắng tái sử dụng ngữ cảnh giữa các lần gọi khi có thể. Ví dụ, nếu bạn có một đoạn tài liệu chung mà bạn hay gửi kèm để hỏi, hãy tách nó thành một message cố định.
• Đừng thay đổi những phần không cần thiết giữa các lần gọi. Bất kỳ sự khác biệt nhỏ nào ở prefix cũng có thể khiến cache không nhận diện được (prefix phải trùng chính xác để hit).
• Tận dụng few-shot: nếu bạn cần mô hình học từ ví dụ, hãy cung cấp một bộ ví dụ cố định để không phải trả phí nhiều lần cho chúng.
• Với hội thoại, gửi đầy đủ lịch sử không chỉ giữ ngữ cảnh mà còn giúp cache – vì phần lớn lịch sử lặp lại trong mỗi request mới.

Tóm lại, context caching là một cơ chế giúp tối ưu chi phí và hiệu suất khi có phần input lặp lại. Khi có nhiều phần input lặp lại, cơ chế này có thể giúp giảm chi phí so với các request hoàn toàn mới. Hãy tận dụng nó!

Các lỗi thường gặp và cách sửa

Khi tích hợp DeepSeek API, bạn có thể gặp một số lỗi HTTP đặc trưng. Dưới đây là những lỗi thường thấy nhất và cách khắc phục nhanh:

• 400 – Bad Request: Yêu cầu không hợp lệ, thường do JSON sai định dạng hoặc thiếu trường bắt buộc. Cách xử lý: Kiểm tra kỹ payload gửi lên. Đảm bảo JSON đúng cú pháp, các cặp ngoặc, dấu phẩy. Xem lại bạn đã truyền đủ các trường cần thiết (ví dụ model, messages), đúng kiểu dữ liệu (chuỗi, số…). Nếu dùng JSON trong system message, đảm bảo JSON đó hợp lệ.
• 401 – Unauthorized: Lỗi xác thực, API key không đúng hoặc không được cung cấp. Cách xử lý: Đảm bảo bạn đã gửi header Authorization: Bearer <API_KEY>. Kiểm tra API key có bị thừa/thiếu ký tự hoặc khoảng trắng không. Nếu API key đã hết hạn hoặc bị thu hồi, bạn cần lấy key mới.
• 402 – Payment Required: Tài khoản không đủ tiền (hết credit). Cách xử lý: Đăng nhập trang quản lý để kiểm tra số dư. Bạn có thể cần nạp thêm tiền (top-up) hoặc kích hoạt gói phù hợp. Sau khi nạp, thử gọi lại. Nếu bạn nghĩ còn dư nhưng vẫn lỗi 402, có thể do bạn dùng hết credit miễn phí và cần thiết lập thanh toán.
• 422 – Unprocessable Entity: Tham số không hợp lệ hoặc yêu cầu không thể xử lý. Cách xử lý: Lỗi này thường xảy ra khi bạn gửi giá trị ngoài phạm vi (vd max_tokens quá lớn), hoặc dùng tham số không hỗ trợ cho model đó (vd dùng logprobs cho reasoner). Đọc thông báo lỗi chi tiết trong body (nếu có) để biết cụ thể. Sau đó, sửa lại request theo hướng dẫn tài liệu: loại bỏ tham số không hợp lệ, chỉnh giá trị về phạm vi cho phép.
• 429 – Too Many Requests: Bạn gửi yêu cầu quá nhanh hoặc quá nhiều trong thời gian ngắn, server tạm từ chối. Cách xử lý: Thứ nhất, DeepSeek không công bố quota cố định, nhưng bạn vẫn có thể gặp lỗi 429 nếu gửi request quá nhanh hoặc khi hệ thống quá tải.
• 500 / 503 – Server Error / Service Unavailable: Lỗi từ phía máy chủ DeepSeek. Cách xử lý: Những lỗi này nằm ngoài ứng dụng của bạn. Hãy đợi một chút và thử gửi lại (có thể sau 5-10 giây). Kiểm tra trang trạng thái dịch vụ nếu bạn nghi ngờ hệ thống đang bảo trì hoặc gặp sự cố. Nếu lỗi kéo dài, liên hệ đội ngũ DeepSeek kèm thông tin chi tiết (thời gian, requestId nếu có).

Mẹo chung: Khi gặp lỗi, hãy luôn in/log lại nội dung phản hồi lỗi từ API. DeepSeek thường trả về JSON chứa message mô tả lỗi, rất hữu ích để biết nguyên nhân. Ví dụ lỗi 422 có thể có nội dung “invalid parameter ‘X’ for model Y”. Dựa vào đó sửa sẽ nhanh hơn.

Best practices bảo mật khi dùng DeepSeek API

Sử dụng API đồng nghĩa với việc bạn phải quản lý khóa bí mật và dữ liệu nhạy cảm. Hãy tuân thủ các best practices về bảo mật sau để bảo vệ cả API key lẫn thông tin người dùng:

• Không đưa API key vào code frontend: Tránh tuyệt đối việc nhúng API key DeepSeek vào mã phía client (như JavaScript chạy trên trình duyệt, ứng dụng di động phân phối tới user). Nếu làm vậy, API key của bạn có thể bị lộ và người khác có thể dùng trái phép (tốn tiền của bạn). Thay vào đó, luôn giữ việc gọi API ở phía server do bạn kiểm soát.
• Sử dụng biến môi trường hoặc kho mật mã: Lưu API key trong biến môi trường trên server, hoặc các dịch vụ quản lý secret (vd AWS Secrets Manager, Docker secret…). Tuyệt đối không commit API key vào git hoặc bất kỳ repository nào. Nếu bạn cần cấu hình, dùng file .env và đảm bảo file này không bị lộ ra ngoài.
• Thiết lập proxy backend nếu cần: Nếu bạn phát triển một ứng dụng web nơi người dùng tương tác trực tiếp, hãy xây dựng một lớp backend (hoặc cloud function) làm trung gian. Frontend sẽ gửi yêu cầu đến backend của bạn, backend thêm API key và gọi DeepSeek API rồi trả kết quả. Cách này đảm bảo API key không bao giờ xuất hiện trên trình duyệt người dùng.
• Rotate (thay đổi) API key định kỳ: DeepSeek Platform cho phép bạn thu hồi và tạo API key mới. Hãy tận dụng điều này. Nếu nghi ngờ API key bị lộ, ngay lập tức thu hồi và tạo key mới để tránh bị lợi dụng. Nên có kế hoạch thay API key định kỳ (ví dụ mỗi vài tháng) như một biện pháp an toàn.
• Giới hạn quyền và theo dõi sử dụng: Hiện tại DeepSeek chưa hỗ trợ tạo key với quyền hạn chế, nhưng bạn nên theo dõi log sử dụng. Nếu thấy đột biến hoặc hành vi bất thường, hãy điều tra ngay. Bạn cũng có thể đặt cảnh báo khi chi tiêu vượt ngưỡng cho phép.
• Tránh gửi dữ liệu nhạy cảm không cần thiết: Dù DeepSeek tuân thủ các chính sách bảo mật, bất kỳ dữ liệu nào gửi lên bên thứ ba đều có rủi ro. Chỉ nên gửi những gì cần thiết để mô hình xử lý. Tránh đưa thông tin cá nhân, bí mật kinh doanh, dữ liệu nhạy cảm vào prompt trừ khi thật sự phải làm vậy (và đã chấp nhận rủi ro).
• Đọc kỹ điều khoản: Theo điều khoản nền tảng, bạn có trách nhiệm bảo mật API key và dữ liệu. Nếu làm lộ, bạn chịu mọi phí phát sinh. Hơn nữa, tuân thủ các chính sách sử dụng API (không dùng cho mục đích vi phạm pháp luật, v.v.).

Tóm lại, hãy coi API key như mật khẩu gốc cho tài khoản DeepSeek của bạn. Bảo vệ nó kỹ càng, xây dựng kiến trúc hợp lý để không bao giờ tiết lộ key ra môi trường không an toàn. Điều này giúp bạn tránh mất tiền oan và giữ uy tín ứng dụng.

Khi nào không cần dùng API?

Không phải lúc nào bạn cũng cần tích hợp API – đôi khi sử dụng ứng dụng có sẵn sẽ thuận tiện hơn. Dưới đây là một số trường hợp bạn không cần dùng DeepSeek API:

• Sử dụng giao diện Chat/App chính thức: Nếu mục tiêu của bạn chỉ là trải nghiệm DeepSeek hoặc dùng nó hỗ trợ công việc cá nhân (như viết lách, trả lời câu hỏi đơn lẻ), hãy dùng DeepSeek Chat trên web hoặc ứng dụng di động. Giao diện có sẵn thường dễ sử dụng hơn đối với người dùng phổ thông, nhưng mức sử dụng miễn phí hay điều kiện truy cập có thể thay đổi theo thời gian. API chủ yếu dành cho việc tích hợp vào phần mềm khác.
• Trò chuyện thông thường hoặc thử nghiệm nhanh: một trang web hoặc ứng dụng trung gian có thể cung cấp thông tin, hướng dẫn (và có thể có tích hợp chat demo nếu có). Nếu bạn chỉ cần hỏi vài câu để xem khả năng của DeepSeek, hãy dùng web/app. API thích hợp khi bạn muốn tự động hóa hoặc xây dựng logic phức tạp xung quanh AI.
• Không muốn viết code: Điều này rõ ràng – nếu bạn không phải developer hoặc không muốn đầu tư thời gian lập trình, thì đừng dùng API. Thay vào đó, dùng giao diện đồ họa do DeepSeek cung cấp. API là công cụ cho lập trình viên; người dùng phổ thông có trải nghiệm tốt hơn qua ứng dụng.
• Khối lượng nhỏ và không thường xuyên: Giả sử bạn chỉ thỉnh thoảng cần chạy vài yêu cầu AI, có thể làm thủ công trên web. Việc tích hợp API thường có ý nghĩa khi bạn cần xử lý nhiều yêu cầu tự động, hoặc tích hợp vào sản phẩm chạy liên tục.
• Quan ngại về triển khai hạ tầng: Để dùng API hiệu quả, bạn cần một server hoặc môi trường chạy code, quản lý key, xử lý lỗi… Nếu bạn không sẵn sàng cho điều đó, sử dụng app có sẵn sẽ đỡ phiền hơn.

Tóm lại, DeepSeek API không phải dành cho tất cả mọi người. Nó dành cho developer hoặc tổ chức muốn xây dựng giải pháp tùy biến. Nếu nhu cầu của bạn được đáp ứng tốt bằng ứng dụng sẵn có, hãy sử dụng nó để tiết kiệm thời gian và công sức.

Kết luận

DeepSeek API cung cấp một cách linh hoạt để tích hợp model AI của DeepSeek vào sản phẩm riêng, với hỗ trợ context dài, khả năng đa ngôn ngữ và mô hình tính phí theo token. Qua bài viết này, hy vọng bạn – các nhà phát triển – đã nắm được cách bắt đầu: từ chuẩn bị API key, thực hiện request đầu tiên, đến những tính năng nâng cao như streaming, multi-turn, JSON output, function calling và context caching.

Đối với developer và startup, chúng tôi khuyến khích bạn thử nghiệm DeepSeek API trong dự án của mình. Nếu bạn đang dùng OpenAI API, quá trình chuyển đổi có thể khá thuận tiện trong nhiều trường hợp nhờ mức độ tương thích cao của DeepSeek API. DeepSeek cung cấp context dài và mô hình tính phí theo token, có thể phù hợp với nhiều kiểu ứng dụng khác nhau (ví dụ phân tích tài liệu dài, chatbot hỗ trợ kiến thức sâu…).

Đối với người dùng cá nhân hoặc không chuyên tech, lời khuyên là hãy sử dụng ứng dụng web hoặc app chính thức của DeepSeek thay vì API. Bạn sẽ có trải nghiệm mượt mà hơn mà không phải lo cấu hình kỹ thuật.

Cuối cùng, DeepSeek đang phát triển nhanh chóng – hãy theo dõi các cập nhật mới (ví dụ model mới, tính năng beta) để tận dụng tối đa. Hy vọng hướng dẫn này giúp bạn triển khai DeepSeek API hiệu quả trong dự án của mình.

(Để biết thêm thông tin về giá cả và chính sách, xem trang Pricing. Nếu bạn có thắc mắc cơ bản, hãy xem FAQ chính thức của DeepSeek. Xem tài liệu chính thức của DeepSeek để cập nhật thông tin mới nhất trước khi triển khai.)

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