Kiểm tra DeepSeek V4 Pro: So sánh ba định dạng API ChatCompletions, Anthropic Messages và Responses API

DeepSeek-V4-Pro-0813 đã chính thức ra mắt (GA) vào ngày 12 tháng 8 năm 2026, được cung cấp thông qua ID mô hình luôn cập nhật là deepseek-v4-pro tại https://api.deepseek.com, cùng với phiên bản deepseek-v4-flash rẻ hơn (Unite.AI đã đưa tin về thông báo GA này). Các thông số kỹ thuật nổi bật rất mạnh mẽ: cửa sổ ngữ cảnh 1 triệu token, đầu ra tối đa 384K, gọi công cụ, đầu ra có cấu trúc và ba chế độ tư duy giúp hiển thị dấu vết suy luận của mô hình trong trường reasoning_content.

Điểm bất thường không nằm ở các thông số kỹ thuật. Mà là ở chỗ một mô hình có thể trả lời bằng ba phương ngữ API khác nhau. V4 Pro chấp nhận các yêu cầu OpenAI ChatCompletions, yêu cầu Anthropic Messages và yêu cầu đến DeepSeek Responses API riêng của họ. Bạn có thể hướng mã SDK OpenAI hiện có của mình đến nó, hướng một tác nhân được xây dựng bằng Claude đến nó, hoặc kết nối nó vào một vòng lặp tác nhân kiểu Codex, với cùng trọng số và ba định dạng truyền dữ liệu khác nhau.

Chưa ai trình bày ba định dạng API của DeepSeek V4 Pro cạnh nhau, vì vậy hướng dẫn này sẽ làm điều đó. Bạn sẽ thấy một yêu cầu hoạt động cho mỗi định dạng, nơi các cấu trúc thực sự khác biệt, một bảng so sánh và cách kiểm tra cả ba từ một dự án Apidog duy nhất với các biến môi trường được chia sẻ. Nếu bạn muốn thiết lập tài khoản và hướng dẫn cuộc gọi đầu tiên, hãy bắt đầu với cách sử dụng DeepSeek V4 API rồi quay lại đây.

button

Tóm tắt

DeepSeek-V4-Pro-0813 đã chính thức ra mắt (GA) thông qua deepseek-v4-pro tại https://api.deepseek.com; deepseek-v4-flash chia sẻ cùng các giao diện với mức giá thấp hơn.
Nó hỗ trợ ba định dạng API: OpenAI ChatCompletions (hoạt động với SDK openai tiêu chuẩn bằng cách thay đổi base_url), Anthropic Messages (thay thế trực tiếp cho các yêu cầu có hình dạng SDK anthropic, bao gồm Claude Code), và DeepSeek’s Responses API (giao diện mới nhất của nó, được xây dựng cho các tác nhân kiểu Codex và các quy trình công việc có trạng thái).
Thông số kỹ thuật: ngữ cảnh 1M, đầu ra tối đa 384K, gọi công cụ, đầu ra có cấu trúc, ba chế độ tư duy với reasoning_content.
Giá: $0.435/M token đầu vào (cache miss), $0.003625/M khi cache hit, $0.87/M đầu ra.
Các định dạng khác nhau về vị trí lời nhắc hệ thống, ngữ nghĩa của max_tokens, hình dạng lược đồ công cụ và hình dạng sự kiện truyền trực tuyến, chi tiết bên dưới.
Một dự án Apidog với {{DEEPSEEK_API_KEY}} và các biến URL cơ sở cho từng định dạng cho phép bạn gửi cùng một lời nhắc tới cả ba và so sánh các phản hồi thô.

Tại sao một mô hình lại "nói" ba phương ngữ

Đây là một động thái tương thích hệ sinh thái: mỗi định dạng API là một cơ sở công cụ được cài đặt mà DeepSeek có được miễn phí. ChatCompletions là ngôn ngữ chung, hàng nghìn SDK và framework có thể gọi V4 Pro chỉ với một dòng thay đổi base_url. Định dạng Anthropic Messages nhắm mục tiêu đến các nhóm đã xây dựng trên Claude: các tác nhân, công cụ đánh giá và các công cụ như Claude Code có thể hướng đến V4 Pro mà không cần viết lại. Và Responses API là đặt cược của DeepSeek vào các tác nhân: deepseek-v4-flash đã có nó vào tháng 7 để tương thích với kiểu Codex, và V4 Pro được trang bị nó ngay khi ra mắt (GA) cho các quy trình công việc đa bước, có trạng thái.

V4 Pro cũng được liệt kê trên các nền tảng tổng hợp (xem trang OpenRouter cho deepseek-v4-pro-0813), nhưng câu chuyện về ba định dạng này áp dụng cho API chính thức của DeepSeek, đây là những gì bài viết này kiểm tra. Để có cái nhìn rộng hơn về họ V4, hãy xem cách sử dụng DeepSeek V4.

Định dạng 1: OpenAI ChatCompletions

Đây là cấu trúc mà bạn đã biết: một mảng messages trong đó lời nhắc hệ thống (system prompt) đi kèm dưới dạng tin nhắn đầu tiên với role: "system", và một giới hạn token tối đa tùy chọn. Thiết lập giống nhau cho cả ba định dạng, vì vậy chúng ta sẽ nhắc một lần: khóa API của DeepSeek, URL cơ sở của DeepSeek và model được đặt thành deepseek-v4-pro (hoặc deepseek-v4-flash). Chỉ có điểm cuối (endpoint) và cấu trúc phần thân (body shape) là thay đổi.

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_DEEPSEEK_API_KEY",
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {"role": "system", "content": "You are a precise technical writer."},
        {"role": "user", "content": "Explain idempotency keys in two sentences."}
    ],
)

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

Không cần SDK mới, không cần lược đồ xác thực mới. Việc gọi công cụ sử dụng cấu trúc function lồng nhau quen thuộc, và luồng dữ liệu đến dưới dạng các thay đổi chat.completion.chunk được kết thúc bởi data: [DONE], khớp với đặc tả của OpenAI. Một hành vi dành riêng cho V4 cần lưu ý: khi chế độ tư duy được kích hoạt, dấu vết suy luận sẽ xuất hiện trong một trường reasoning_content riêng biệt bên cạnh content, vì vậy các bộ phân tích (parser) nên chấp nhận trường bổ sung này.

Khi nào nên sử dụng: bạn có các công cụ OpenAI hiện có, các framework kiểu LangChain hoặc các thư viện nội bộ đã hỗ trợ ChatCompletions. Đây là con đường ít ma sát nhất và dễ xác minh nhất, cấu trúc yêu cầu giống hệt như những gì được đề cập trong bài viết kiểm tra API ChatGPT với Apidog, chỉ khác là thay đổi máy chủ và mô hình.

Định dạng 2: Anthropic Messages

Định dạng Messages thoạt nhìn có vẻ tương tự nhưng lại khác biệt ở những điểm khiến việc dịch thuật đơn thuần trở nên sai lệch. Ba điểm khác biệt quan trọng nhất, tất cả đều được thừa hưởng từ đặc tả của Anthropic:

Lời nhắc hệ thống (system prompt) không còn nằm trong mảng. Nó là một tham số system cấp cao nhất; mảng messages chỉ chứa các lượt luân phiên giữa user và assistant.
max_tokens là bắt buộc, không phải tùy chọn. Mỗi yêu cầu phải khai báo ngân sách đầu ra rõ ràng. Với đầu ra tối đa 384K của V4 Pro, giới hạn này rất rộng rãi, nhưng bạn vẫn phải chỉ định nó.
Định nghĩa công cụ là dạng phẳng. Mỗi công cụ mang name, description và một input_schema ở cấp cao nhất, không có wrapper function lồng nhau. Các cuộc gọi công cụ trả về dưới dạng các khối nội dung tool_use, và bạn trả về kết quả dưới dạng các khối tool_result bên trong một tin nhắn người dùng.

Python, yêu cầu Messages thông qua SDK anthropic:

import os
import anthropic

client = anthropic.Anthropic(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com/anthropic", # Anthropic-compatible base; confirm current path in DeepSeek's docs
)

message = client.messages.create(
    model="deepseek-v4-pro",
    max_tokens=8192,
    system="You are a precise technical writer.",
    messages=[
        {"role": "user", "content": "Explain idempotency keys in two sentences."}
    ],
)

print(message.content[0].text)

Các phản hồi trả về dưới dạng danh sách các khối nội dung thay vì một chuỗi duy nhất, và luồng dữ liệu sử dụng các sự kiện SSE có kiểu dữ liệu như message_start, content_block_delta, message_stop thay vì các khối đồng nhất. Xác thực tuân theo các quy ước tiêu đề của đặc tả Anthropic thay vì mã token bearer. Tài liệu API của DeepSeek cung cấp các chi tiết hiện tại về giao diện tương thích.

Lợi ích thực tế là dành cho các tác nhân (agents). Bởi vì các công cụ như Claude Code đọc điểm cuối (endpoint) của chúng từ các biến môi trường, bạn có thể hướng một tác nhân được xây dựng bằng Claude đến DeepSeek mà không cần chỉnh sửa mã của nó:

export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_AUTH_TOKEN=$DEEPSEEK_API_KEY
export ANTHROPIC_MODEL=deepseek-v4-pro

Khi nào nên sử dụng: công cụ của bạn được xây dựng để làm việc với Claude. Nếu nhóm của bạn đã gửi các yêu cầu dạng Messages tới các mô hình của Anthropic (cùng cấu trúc được đề cập trong hướng dẫn API Claude Opus 5 của chúng tôi), định dạng này cho phép bạn so sánh A/B DeepSeek với Claude trong cùng một hệ thống, với cùng phần thân yêu cầu và cùng các trình xử lý luồng.

Định dạng 3: DeepSeek Responses API

Responses API là giao diện mới nhất của DeepSeek, và lý do nó tồn tại là để phục vụ các tác nhân (agents). V4 Flash đã tiếp nhận nó vào tháng 7 để các tác nhân kiểu Codex có thể điều khiển các mô hình DeepSeek; V4 Pro ra mắt với nó ngay từ ngày đầu. Cấu trúc yêu cầu tuân theo đặc tả OpenAI Responses: bạn gửi input (một chuỗi hoặc danh sách các mục có kiểu dữ liệu) cùng với instructions cấp cao nhất, thay vì một mảng tin nhắn duy nhất.

curl, yêu cầu Responses API:

curl https://api.deepseek.com/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -d '{
    "model": "deepseek-v4-pro",
    "instructions": "You are an API review agent. Be terse.",
    "input": "Review this OpenAPI diff and list any breaking changes: [diff here]",
    "stream": false
  }'

Ba điều phân biệt định dạng này với hai định dạng kia, tất cả đều tuân theo đặc tả Responses:

Trạng thái có thể tồn tại ở phía máy chủ. Thay vì gửi lại toàn bộ cuộc hội thoại mỗi lượt, một yêu cầu tiếp theo có thể tham chiếu phản hồi trước đó bằng ID (previous_response_id trong đặc tả), điều này giúp các vòng lặp tác nhân đa bước dễ điều phối và tiết kiệm chi phí.
Đầu ra là một danh sách các mục có kiểu dữ liệu, không phải một tin nhắn duy nhất: các mục suy luận, các mục văn bản và các mục gọi công cụ đến dưới dạng các mục riêng biệt, điều này phù hợp với các tác nhân xử lý mỗi loại mục theo cách khác nhau.
Luồng dữ liệu là có ngữ nghĩa. Thay vì các thay đổi văn bản thô, luồng phát ra các sự kiện có tên (response.output_text.delta, response.completed, và các sự kiện liên quan khác), do đó một tác nhân có thể phản ứng với các thay đổi vòng đời mà không cần phân tích các khối bằng regex.

Gọi công cụ cũng tồn tại ở đây, với các định nghĩa công cụ và các mục function_call/function_call_output được định hình theo đặc tả Responses chứ không phải theo định dạng cũ nào. Trong trường hợp chi tiết triển khai của DeepSeek vượt ra ngoài đặc tả, hãy coi api-docs.deepseek.com là nguồn thông tin đáng tin cậy.

Khi nào nên sử dụng: các tích hợp kiểu tác nhân và Codex, các quy trình công việc đa bước dài, hoặc bất kỳ hệ thống nào mà trạng thái hội thoại được quản lý phía máy chủ và các mục đầu ra có kiểu dữ liệu giúp đơn giản hóa mã điều phối của bạn. Đối với một hoàn thành cuộc trò chuyện đơn giản, nó phức tạp hơn mức cần thiết.

Ba định dạng đặt cạnh nhau

	OpenAI ChatCompletions	Anthropic Messages	DeepSeek Responses API
Điểm cuối	`POST /chat/completions` trên `api.deepseek.com`	`POST /v1/messages` trên cơ sở tương thích Anthropic (`/anthropic`)	`POST /responses` trên `api.deepseek.com`
Cấu trúc yêu cầu	Mảng `messages` duy nhất, lời nhắc hệ thống là tin nhắn đầu tiên	`system` cấp cao nhất + tin nhắn `user`/`assistant` xen kẽ	`instructions` cấp cao nhất + chuỗi `input` hoặc danh sách mục
Giới hạn đầu ra	Giới hạn token tối đa tùy chọn	`max_tokens` bắt buộc	Giới hạn tùy chọn theo đặc tả Responses
Định nghĩa công cụ	Lồng nhau: đối tượng `function` với `parameters`	Phẳng: `input_schema` cho mỗi công cụ	Các mục phẳng theo đặc tả Responses
Kết quả công cụ	Tin nhắn `role: "tool"`	Các khối nội dung `tool_result`	Các mục `function_call_output`
Luồng dữ liệu	Các thay đổi `chat.completion.chunk` đồng nhất, kết thúc bằng `[DONE]`	Các sự kiện có kiểu dữ liệu: `message_start` → `content_block_delta` → `message_stop`	Các sự kiện vòng đời có ngữ nghĩa (`response.output_text.delta`, …)
Trạng thái hội thoại	Do máy khách quản lý (gửi lại lịch sử)	Do máy khách quản lý (gửi lại lịch sử)	Tùy chọn phía máy chủ thông qua tham chiếu phản hồi trước đó
Tốt nhất cho	Các công cụ và framework OpenAI hiện có	Các công cụ và tác nhân gốc Claude (Claude Code)	Vòng lặp tác nhân, quy trình công việc kiểu Codex và có trạng thái

Cùng một mô hình, cùng một mức giá, ba hợp đồng. Sự khác biệt hoàn toàn nằm ở cấp độ truyền dữ liệu, đây chính xác là loại khác biệt dễ xác minh bằng thực nghiệm nhất thay vì dựa vào trí nhớ.

Kiểm tra cả ba trong một dự án Apidog

Việc theo dõi cùng một lời nhắc tạo ra ba phản hồi có cấu trúc khác nhau giúp nắm bắt được các chi tiết triển khai mà không bảng so sánh nào có thể làm được. Thiết lập có thể lặp lại:

Tạo một dự án, ba thư mục: chat-completions, anthropic-messages, responses, mỗi thư mục chứa một yêu cầu đã lưu cho mỗi kịch bản (hoàn thành đơn giản, gọi công cụ, luồng dữ liệu).
Chia sẻ thông tin xác thực thông qua các biến môi trường. Định nghĩa {{DEEPSEEK_API_KEY}}, {{BASE_URL}} và {{ANTHROPIC_BASE}} một lần; việc xoay vòng khóa hoặc chuyển sang deepseek-v4-flash chỉ yêu cầu thay đổi một trường.
Gửi lời nhắc giống hệt qua từng định dạng và so sánh phần thân phản hồi thô: choices[0].message.content so với danh sách khối content so với các mục đầu ra có kiểu dữ liệu.
Kiểm tra các luồng dữ liệu với stream: true. Chế độ xem SSE tích hợp sẵn làm cho sự khác biệt trở nên rõ ràng: các khối không tên kết thúc bằng [DONE], các sự kiện Messages có tên, các sự kiện vòng đời Responses. Nếu gỡ lỗi SSE còn mới mẻ đối với bạn, bài viết cách truyền phát phản hồi API bằng SSE sẽ giải thích cơ chế hoạt động.
Thêm các xác nhận (assertions) trên các trường mà tích hợp của bạn thực sự đọc (đường dẫn nội dung, vị trí ID gọi công cụ, lý do kết thúc) và chạy lại bộ sưu tập mỗi khi DeepSeek phát hành bản cập nhật.

Dự án với ba thư mục cũng đóng vai trò là tài liệu sống: câu hỏi “lược đồ công cụ Messages trông như thế nào nhỉ?” trở thành một yêu cầu đã lưu với một phản hồi thực tế được ghi lại.

Lưu ý khi di chuyển

Việc di chuyển mã hiện có sang V4 Pro được thực hiện một cách nhàm chán có chủ đích, và đó chính là mục tiêu.

Từ OpenAI: thay đổi ba giá trị base_url thành https://api.deepseek.com, khóa API và mô hình thành deepseek-v4-pro. Cấu trúc tin nhắn, định nghĩa công cụ và trình xử lý luồng của bạn vẫn giữ nguyên. Hai kiểm tra trước khi bạn triển khai: xác nhận bất kỳ tham số nào ngoài đặc tả cốt lõi đều hoạt động theo cách bạn mong đợi (chạy chúng thông qua bộ sưu tập kiểm thử của bạn thay vì giả định), và đảm bảo việc phân tích cú pháp phản hồi của bạn chấp nhận reasoning_content xuất hiện bên cạnh content.

Từ Anthropic: đổi URL cơ sở sang đường dẫn tương thích với Anthropic, đổi khóa và đặt mô hình. Bởi vì cấu trúc Messages được giữ nguyên, các max_tokens bắt buộc, các khối nội dung, các sự kiện luồng có kiểu dữ liệu, một client tuân thủ đặc tả không cần thay đổi logic. Đối với các tác nhân đọc biến môi trường, việc di chuyển chỉ là ba dòng export đã được hiển thị trước đó.

Đối với Responses API: đây là việc viết lại lớp yêu cầu của bạn chứ không phải thay đổi cấu hình, vì không có định dạng cũ nào có thể dịch một cách tự động. Hãy áp dụng nó khi bạn muốn những gì nó cung cấp độc đáo, trạng thái phía máy chủ và các mục đầu ra có kiểu dữ liệu, chứ không phải vì nó là mới nhất.

Theo mọi hướng, lời khuyên vẫn như nhau: di chuyển cấu hình, sau đó chạy lại bộ sưu tập hồi quy của bạn trước khi tin tưởng nó. Với những mức giá này, một buổi chiều kiểm tra lưu lượng truy cập tốn ít hơn ly cà phê bạn uống trong thời gian đó.

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

Một dự án mới nên chọn định dạng nào? Mặc định là ChatCompletions để có hỗ trợ công cụ rộng rãi nhất. Chọn Messages nếu stack của bạn là gốc Claude. Chọn Responses API nếu bạn đang xây dựng một tác nhân đa bước và muốn trạng thái được quản lý phía máy chủ.
Tôi có thể hướng Claude Code tới DeepSeek V4 Pro không? Có. Đặt ANTHROPIC_BASE_URL thành điểm cuối tương thích Anthropic của DeepSeek, sử dụng khóa DeepSeek của bạn làm token xác thực và đặt mô hình là deepseek-v4-pro. Đó chính là lợi ích thực tế của việc hỗ trợ định dạng Messages.
Gọi công cụ và đầu ra có cấu trúc có hoạt động trong mọi định dạng không? Mô hình hỗ trợ cả hai, và mỗi phương ngữ đều hiển thị việc gọi công cụ theo hình dạng đặc tả riêng của nó, các đối tượng hàm lồng nhau, các công cụ input_schema hoặc các mục kiểu Responses. Hãy xác minh lược đồ cụ thể của bạn với từng giao diện trong một bộ sưu tập kiểm thử trước khi triển khai; các trường hợp biên của hình dạng lược đồ chính là nơi các triển khai tương thích có thể khác biệt.

button