เปรียบเทียบและทดสอบ API ของ DeepSeek V4 Pro: ChatCompletions, Anthropic Messages และ Responses API

DeepSeek-V4-Pro-0813 เปิดให้บริการทั่วไปเมื่อวันที่ 12 สิงหาคม 2026 โดยให้บริการภายใต้รหัสโมเดล deepseek-v4-pro ที่ https://api.deepseek.com ซึ่งจะอัปเดตอย่างต่อเนื่อง ควบคู่ไปกับ deepseek-v4-flash ที่มีราคาถูกกว่า (Unite.AI ได้รายงานข่าวการเปิดให้บริการทั่วไป) คุณสมบัติเด่นของรุ่นนี้แข็งแกร่งมาก ได้แก่ หน้าต่างบริบทขนาด 1M โทเค็น, เอาต์พุตสูงสุด 384K, การเรียกใช้เครื่องมือ, เอาต์พุตแบบมีโครงสร้าง และโหมดการคิดสามแบบที่แสดงร่องรอยการให้เหตุผลของโมเดลในฟิลด์ reasoning_content

ส่วนที่ผิดปกติไม่ใช่เรื่องของสเปก แต่เป็นที่โมเดลเดียวสามารถตอบกลับได้ในสามรูปแบบ API ที่แตกต่างกัน V4 Pro รองรับคำขอ OpenAI ChatCompletions, คำขอ Anthropic Messages และคำขอไปยัง Responses API ของ DeepSeek เอง คุณสามารถชี้โค้ด OpenAI SDK ที่มีอยู่ไปยัง V4 Pro, ชี้เอเจนต์ที่สร้างด้วย Claude ไปยัง V4 Pro หรือเชื่อมต่อเข้ากับลูปเอเจนต์สไตล์ Codex ด้วยน้ำหนักโมเดลเดียวกัน แต่มีสามรูปแบบการสื่อสารข้อมูล

ยังไม่มีใครเปรียบเทียบรูปแบบ API ทั้งสามของ DeepSeek V4 Pro แบบเคียงข้างกัน คู่มือนี้จึงได้นำเสนอสิ่งนั้น คุณจะได้เห็นคำขอที่ทำงานได้จริงสำหรับแต่ละรูปแบบ ซึ่งมีโครงสร้างที่แตกต่างกันอย่างชัดเจน ตารางเปรียบเทียบ และวิธีทดสอบทั้งสามรูปแบบจากโปรเจกต์ Apidog เดียวกันโดยใช้ตัวแปรสภาพแวดล้อมร่วมกัน หากคุณต้องการตั้งค่าบัญชีและดูขั้นตอนการเรียกใช้ครั้งแรก โปรดเริ่มจาก วิธีใช้ DeepSeek V4 API แล้วกลับมาที่นี่

ปุ่ม

สรุปสั้นๆ

DeepSeek-V4-Pro-0813 เปิดให้บริการทั่วไปภายใต้ deepseek-v4-pro ที่ https://api.deepseek.com; deepseek-v4-flash ใช้งานได้ในรูปแบบเดียวกันแต่ราคาถูกกว่า
รองรับรูปแบบ API สามแบบ: OpenAI ChatCompletions (ใช้งานได้กับ openai SDK มาตรฐานโดยเปลี่ยน base_url), Anthropic Messages (ใช้แทนได้โดยตรงสำหรับคำขอที่จัดรูปแบบด้วย anthropic SDK รวมถึง Claude Code) และ Responses API ของ DeepSeek (อินเทอร์เฟซใหม่ล่าสุด สร้างขึ้นสำหรับเอเจนต์สไตล์ Codex และเวิร์กโฟลว์ที่มีสถานะ)
คุณสมบัติ: บริบท 1M, เอาต์พุตสูงสุด 384K, การเรียกใช้เครื่องมือ, เอาต์พุตแบบมีโครงสร้าง, โหมดการคิดสามแบบพร้อม reasoning_content
ราคา: $0.435/M โทเค็นอินพุต (เมื่อไม่มีในแคช), $0.003625/M เมื่อมีในแคช, $0.87/M เอาต์พุต
รูปแบบต่างๆ แตกต่างกันในการจัดวาง system-prompt, ความหมายของ max_tokens, รูปแบบ tool schema และรูปแบบ streaming event รายละเอียดอยู่ด้านล่าง
โปรเจกต์ Apidog เดียวที่มี {{DEEPSEEK_API_KEY}} และตัวแปร base URL สำหรับแต่ละรูปแบบ ช่วยให้คุณสามารถส่งพรอมต์เดียวกันไปยังทั้งสามรูปแบบและเปรียบเทียบผลลัพธ์ดิบได้

ทำไมโมเดลเดียวถึงรองรับสามรูปแบบ

นี่คือกลยุทธ์ความเข้ากันได้ของระบบนิเวศ: ทุกรูปแบบ API เป็นฐานเครื่องมือที่มีอยู่แล้ว ซึ่ง DeepSeek ได้มาฟรี ChatCompletions เป็นภาษากลาง SDK และเฟรมเวิร์กนับพันสามารถเรียกใช้ V4 Pro ได้ด้วยการเปลี่ยน base_url เพียงบรรทัดเดียว รูปแบบ Anthropic Messages มุ่งเป้าไปที่ทีมที่สร้างบน Claude: เอเจนต์, eval harnesses และเครื่องมือเช่น Claude Code สามารถชี้ไปยัง V4 Pro ได้โดยไม่ต้องเขียนใหม่ และ Responses API คือเดิมพันของ DeepSeek กับเอเจนต์: deepseek-v4-flash ได้รับการรองรับในเดือนกรกฎาคมสำหรับความเข้ากันได้แบบ Codex และ V4 Pro มาพร้อมกับ API นี้เมื่อเปิดให้บริการทั่วไปสำหรับเวิร์กโฟลว์แบบมีสถานะและหลายขั้นตอน

V4 Pro ยังมีรายชื่ออยู่ในตัวรวบรวม (ดูที่ หน้า OpenRouter สำหรับ deepseek-v4-pro-0813) แต่เรื่องราวของสามรูปแบบนี้ใช้ได้กับ API ของ DeepSeek โดยตรง ซึ่งเป็นสิ่งที่บทความนี้ทดสอบ สำหรับภาพรวมที่กว้างขึ้นของตระกูล V4 โปรดดู วิธีใช้ DeepSeek V4

รูปแบบที่ 1: OpenAI ChatCompletions

นี่คือโครงสร้างที่คุณคุ้นเคย: อาร์เรย์ messages ที่มี system prompt เป็นข้อความแรกพร้อม role: "system" และการจำกัดจำนวนโทเค็นสูงสุดซึ่งเป็นทางเลือก การตั้งค่าเหมือนกันสำหรับทั้งสามรูปแบบ โดยมีดังนี้: คีย์ DeepSeek API ของคุณ, base URL ของ DeepSeek และ model ที่ตั้งค่าเป็น deepseek-v4-pro (หรือ deepseek-v4-flash) มีเพียง endpoint และโครงสร้าง body เท่านั้นที่เปลี่ยนไป

Python, ผ่าน openai SDK มาตรฐาน:

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)

ไม่ต้องใช้ SDK ใหม่ ไม่ต้องใช้ระบบยืนยันตัวตนใหม่ การเรียกใช้เครื่องมือใช้รูปแบบ function ที่คุ้นเคย และการสตรีมจะมาในรูปของ chat.completion.chunk deltas ที่สิ้นสุดด้วย data: [DONE] ซึ่งตรงตามข้อกำหนดของ OpenAI ข้อควรระวังเฉพาะของ V4: เมื่อเปิดใช้งานโหมดการคิด ร่องรอยการให้เหตุผลจะมาในฟิลด์ reasoning_content แยกต่างหากควบคู่ไปกับ content ดังนั้นตัวแยกวิเคราะห์ควรจะรองรับฟิลด์พิเศษนี้ได้

ควรใช้เมื่อใด: คุณมีเครื่องมือ OpenAI ที่มีอยู่, เฟรมเวิร์กสไตล์ LangChain หรือไลบรารีภายในที่รองรับ ChatCompletions อยู่แล้ว เป็นเส้นทางที่ง่ายที่สุดและตรวจสอบได้ง่ายที่สุด โครงสร้างคำขอเหมือนกับที่อธิบายไว้ใน การทดสอบ ChatGPT API ด้วย Apidog โดยเปลี่ยนเพียงโฮสต์และโมเดลเท่านั้น

รูปแบบที่ 2: Anthropic Messages

รูปแบบ Messages ดูคล้ายกันเมื่อมองแวบแรก แต่มีความแตกต่างในลักษณะที่ทำให้การแปลแบบตรงไปตรงมาใช้งานไม่ได้ มีความแตกต่างสามประการที่สำคัญที่สุด ซึ่งสืบทอดมาจากข้อกำหนดของ Anthropic ทั้งหมด:

system prompt จะย้ายออกจากอาร์เรย์ มันเป็นพารามิเตอร์ system ระดับบนสุด; อาร์เรย์ messages จะเก็บเฉพาะส่วนของ user และ assistant ที่สลับกันเท่านั้น
max_tokens เป็นสิ่งที่จำเป็น ไม่ใช่ทางเลือก ทุกคำขอจะต้องประกาศงบประมาณเอาต์พุตอย่างชัดเจน ด้วยเอาต์พุตสูงสุด 384K ของ V4 Pro ขีดจำกัดนั้นถือว่ากว้างขวาง แต่คุณต้องระบุ
คำจำกัดความของเครื่องมือจะแบนราบ เครื่องมือแต่ละชิ้นมี name, description และ input_schema ที่ระดับบนสุด โดยไม่มี function wrapper ซ้อนกัน การเรียกใช้เครื่องมือจะกลับมาเป็น tool_use content blocks และคุณส่งคืนผลลัพธ์เป็น tool_result blocks ภายในข้อความผู้ใช้

Python, คำขอ Messages ผ่าน anthropic SDK:

import os
import anthropic

client = anthropic.Anthropic(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com/anthropic", # ฐานที่เข้ากันได้กับ Anthropic; ยืนยันเส้นทางปัจจุบันในเอกสารของ DeepSeek
)

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)

การตอบกลับมาในรูปแบบรายการ content blocks แทนที่จะเป็นสตริงเดียว และการสตรีมใช้เหตุการณ์ SSE แบบมีประเภท message_start, content_block_delta, message_stop แทนที่จะเป็นกลุ่มข้อมูลที่เหมือนกัน การยืนยันตัวตนเป็นไปตามข้อกำหนดส่วนหัวของ Anthropic แทนที่จะเป็น bearer token เอกสาร API ของ DeepSeek มีรายละเอียดปัจจุบันของพื้นผิวที่เข้ากันได้

ประโยชน์ในทางปฏิบัติคือเอเจนต์ เนื่องจากเครื่องมือเช่น Claude Code อ่าน endpoint จากตัวแปรสภาพแวดล้อม คุณจึงสามารถชี้เอเจนต์ที่สร้างด้วย Claude ไปยัง DeepSeek ได้โดยไม่ต้องแก้ไขโค้ด:

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

ควรใช้เมื่อใด: เครื่องมือของคุณสร้างขึ้นโดยอิงกับ Claude หากทีมของคุณส่งคำขอในรูปแบบ Messages ไปยังโมเดล Anthropic อยู่แล้ว (โครงสร้างเดียวกันกับที่ครอบคลุมใน คู่มือ Claude Opus 5 API ของเรา) รูปแบบนี้ช่วยให้คุณสามารถเปรียบเทียบ DeepSeek กับ Claude ได้ภายในชุดเครื่องมือเดียวกัน ด้วยโครงสร้างคำขอและตัวจัดการการสตรีมที่เหมือนกัน

รูปแบบที่ 3: Responses API ของ DeepSeek

Responses API เป็นอินเทอร์เฟซใหม่ล่าสุดของ DeepSeek และเหตุผลที่มีอยู่คือสำหรับเอเจนต์ V4 Flash รองรับ API นี้ในเดือนกรกฎาคม เพื่อให้เอเจนต์สไตล์ Codex สามารถขับเคลื่อนโมเดล DeepSeek ได้; V4 Pro เปิดตัวพร้อมกับ API นี้ตั้งแต่วันแรก รูปแบบคำขอเป็นไปตามข้อกำหนด OpenAI Responses: คุณส่ง input (สตริงหรือรายการของรายการที่มีประเภท) พร้อมกับ instructions ระดับบนสุด แทนที่จะเป็นอาร์เรย์ messages เพียงอย่างเดียว

curl, คำขอ 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
  }'

สามสิ่งนี้แยกรูปแบบนี้ออกจากอีกสองรูปแบบ โดยทั้งหมดเป็นไปตามข้อกำหนดของ Responses:

สถานะสามารถอยู่ฝั่งเซิร์ฟเวอร์ได้ แทนที่จะส่งบทสนทนาทั้งหมดซ้ำในแต่ละรอบ คำขอติดตามผลสามารถอ้างอิงการตอบกลับก่อนหน้าด้วย ID (previous_response_id ในข้อกำหนด) ซึ่งช่วยให้การจัดการลูปเอเจนต์แบบหลายขั้นตอนมีค่าใช้จ่ายถูกลง
เอาต์พุตเป็นรายการของรายการที่มีประเภท ไม่ใช่ข้อความเดียว: รายการการให้เหตุผล, รายการข้อความ และรายการการเรียกใช้เครื่องมือจะมาในรูปของรายการที่แตกต่างกัน ซึ่งเหมาะสำหรับเอเจนต์ที่จัดการแต่ละประเภทของรายการแตกต่างกัน
การสตรีมเป็นแบบเชิงความหมาย แทนที่จะเป็น raw text deltas สตรีมจะปล่อยเหตุการณ์ที่มีชื่อ (response.output_text.delta, response.completed และอื่นๆ) ดังนั้นเอเจนต์จึงสามารถตอบสนองต่อการเปลี่ยนแปลงวงจรชีวิตได้โดยไม่ต้องใช้ regex แยกวิเคราะห์กลุ่มข้อมูล

การเรียกใช้เครื่องมือก็มีอยู่ในรูปแบบนี้ด้วย โดยมีคำจำกัดความของเครื่องมือและรายการ function_call / function_call_output ที่จัดรูปแบบตามข้อกำหนดของ Responses แทนที่จะเป็นรูปแบบเก่า หากรายละเอียดการใช้งานของ DeepSeek เกินกว่าข้อกำหนด ให้ถือว่า api-docs.deepseek.com เป็นแหล่งข้อมูลที่ถูกต้องที่สุด

ควรใช้เมื่อใด: การผสานรวมแบบ agentic และ Codex-style, เวิร์กโฟลว์แบบหลายขั้นตอนยาวนาน หรือระบบใดๆ ที่สถานะการสนทนาที่จัดการโดยเซิร์ฟเวอร์และรายการเอาต์พุตแบบมีประเภทช่วยลดความซับซ้อนของโค้ด orchestration ของคุณ สำหรับการสนทนาธรรมดาๆ มันอาจจะซับซ้อนเกินความจำเป็น

สามรูปแบบเคียงข้างกัน

	OpenAI ChatCompletions	Anthropic Messages	DeepSeek Responses API
Endpoint	`POST /chat/completions` บน `api.deepseek.com`	`POST /v1/messages` บนฐานที่เข้ากันได้กับ Anthropic (`/anthropic`)	`POST /responses` บน `api.deepseek.com`
รูปแบบคำขอ	อาร์เรย์ `messages` เดียว, system prompt เป็นข้อความแรก	`system` ระดับบนสุด + ข้อความ `user`/`assistant` สลับกัน	`instructions` ระดับบนสุด + สตริง `input` หรือรายการของรายการ
การจำกัดเอาต์พุต	การจำกัด max-tokens เป็นทางเลือก	`max_tokens` เป็นสิ่งที่จำเป็น	การจำกัดเป็นทางเลือกตามข้อกำหนดของ Responses
คำจำกัดความของเครื่องมือ	ซ้อนกัน: อ็อบเจกต์ `function` พร้อม `parameters`	แบนราบ: `input_schema` ต่อเครื่องมือ	รายการแบบแบนราบตามข้อกำหนดของ Responses
ผลลัพธ์ของเครื่องมือ	ข้อความ `role: "tool"`	`tool_result` content blocks	รายการ `function_call_output`
การสตรีม	`chat.completion.chunk` deltas ที่เหมือนกัน, สิ้นสุดด้วย `[DONE]`	เหตุการณ์แบบมีประเภท: `message_start` → `content_block_delta` → `message_stop`	เหตุการณ์วงจรชีวิตเชิงความหมาย (`response.output_text.delta`, …)
สถานะการสนทนา	จัดการโดยไคลเอนต์ (ส่งประวัติซ้ำ)	จัดการโดยไคลเอนต์ (ส่งประวัติซ้ำ)	ทางเลือกฝั่งเซิร์ฟเวอร์ผ่านการอ้างอิงการตอบกลับก่อนหน้า
เหมาะสำหรับ	เครื่องมือและเฟรมเวิร์ก OpenAI ที่มีอยู่	เครื่องมือและเอเจนต์ที่รองรับ Claude โดยตรง (Claude Code)	ลูปเอเจนต์, เวิร์กโฟลว์สไตล์ Codex และเวิร์กโฟลว์แบบมีสถานะ

โมเดลเดียวกัน, ราคาเดียวกัน, สามรูปแบบการสื่อสาร ความแตกต่างอยู่ที่ระดับการสื่อสารข้อมูลทั้งหมด ซึ่งเป็นความแตกต่างที่ง่ายที่สุดในการตรวจสอบเชิงประจักษ์ แทนที่จะจำเอา

ทดสอบทั้งสามรูปแบบในโปรเจกต์ Apidog เดียว

การดูพรอมต์เดียวกันสร้างการตอบกลับที่มีโครงสร้างแตกต่างกันสามแบบ ช่วยให้คุณเห็นรายละเอียดการใช้งานที่ตารางเปรียบเทียบไม่สามารถแสดงได้ การตั้งค่าที่ทำซ้ำได้:

สร้างหนึ่งโปรเจกต์, สามโฟลเดอร์: chat-completions, anthropic-messages, responses โดยแต่ละโฟลเดอร์เก็บคำขอที่บันทึกไว้หนึ่งรายการต่อสถานการณ์ (การเติมข้อความธรรมดา, การเรียกใช้เครื่องมือ, การสตรีม)
แชร์ข้อมูลรับรองผ่านตัวแปรสภาพแวดล้อม กำหนด {{DEEPSEEK_API_KEY}}, {{BASE_URL}} และ {{ANTHROPIC_BASE}} เพียงครั้งเดียว; การหมุนเวียนคีย์หรือเปลี่ยนไปใช้ deepseek-v4-flash จะเป็นการเปลี่ยนแปลงเพียงฟิลด์เดียว
ส่งพรอมต์ที่เหมือนกันผ่านแต่ละรูปแบบและเปรียบเทียบ raw bodies: choices[0].message.content เทียบกับรายการ content block เทียบกับรายการเอาต์พุตแบบมีประเภท
ตรวจสอบการสตรีมด้วย stream: true มุมมอง SSE ที่มีมาให้จะทำให้เห็นความแตกต่างได้ชัดเจน: กลุ่มข้อมูลที่ไม่ระบุชื่อที่สิ้นสุดด้วย [DONE], เหตุการณ์ Messages ที่มีชื่อ, เหตุการณ์วงจรชีวิตของ Responses หากคุณยังไม่คุ้นเคยกับการดีบัก SSE, วิธีสตรีมการตอบกลับ API ด้วย SSE จะครอบคลุมกลไกการทำงาน
เพิ่ม assertions ในฟิลด์ที่การผสานรวมของคุณอ่านจริง (เส้นทางเนื้อหา, ตำแหน่ง tool-call ID, เหตุผลการสิ้นสุด) และรันคอลเลกชันซ้ำเมื่อใดก็ตามที่ DeepSeek เผยแพร่การอัปเดตสแนปช็อต

โปรเจกต์สามโฟลเดอร์นี้ยังทำหน้าที่เป็นเอกสารประกอบที่มีชีวิต: “Messages tool schema มีลักษณะอย่างไรนะ?” จะกลายเป็นคำขอที่บันทึกไว้พร้อมการตอบกลับที่จับภาพได้จริง

หมายเหตุการย้ายข้อมูล

การย้ายโค้ดที่มีอยู่ไปยัง V4 Pro นั้นตั้งใจให้เป็นเรื่องที่ไม่น่าตื่นเต้น และนั่นคือประเด็นสำคัญ

จาก OpenAI: เปลี่ยนสามค่าคือ base_url เป็น https://api.deepseek.com, API key และโมเดลเป็น deepseek-v4-pro การสร้างข้อความ, คำจำกัดความของเครื่องมือ และตัวจัดการการสตรีมของคุณยังคงเดิม สองสิ่งที่คุณต้องตรวจสอบก่อนใช้งานจริง: ยืนยันว่าพารามิเตอร์ใดๆ ที่อยู่นอกเหนือข้อกำหนดหลักทำงานตามที่คุณคาดหวัง (ทดสอบผ่านคอลเลกชันทดสอบของคุณแทนที่จะคาดเดาเอาเอง) และตรวจสอบให้แน่ใจว่าการแยกวิเคราะห์การตอบกลับของคุณรองรับ reasoning_content ที่ปรากฏถัดจาก content

จาก Anthropic: สลับ base URL ไปยังเส้นทางที่เข้ากันได้กับ Anthropic, สลับคีย์ และตั้งค่าโมเดล เนื่องจากโครงสร้าง Messages ยังคงอยู่, max_tokens ที่จำเป็น, content blocks, เหตุการณ์สตรีมแบบมีประเภท, ลูกค้าที่ปฏิบัติตามข้อกำหนดไม่จำเป็นต้องเปลี่ยนตรรกะใดๆ สำหรับเอเจนต์ที่อ่านตัวแปรสภาพแวดล้อม การย้ายข้อมูลคือการใช้สามบรรทัด export ที่แสดงไว้ก่อนหน้านี้

ไปยัง Responses API: รูปแบบนี้เป็นการเขียนชั้นคำขอใหม่มากกว่าการเปลี่ยนแปลงการตั้งค่า เนื่องจากรูปแบบเก่าทั้งสองไม่สามารถแปลได้โดยอัตโนมัติ ควรนำไปใช้เมื่อคุณต้องการสิ่งที่รูปแบบนี้นำเสนอโดยเฉพาะ เช่น สถานะฝั่งเซิร์ฟเวอร์และรายการเอาต์พุตแบบมีประเภท ไม่ใช่เพราะเป็นรูปแบบใหม่ล่าสุด

คำแนะนำในทุกทิศทางเหมือนกัน: ย้ายการตั้งค่า จากนั้นรัน regression collection ของคุณซ้ำก่อนที่จะเชื่อถือ ด้วยราคาเหล่านี้ การตรวจสอบเพียงช่วงบ่ายจะเสียค่าใช้จ่ายน้อยกว่ากาแฟที่คุณดื่มระหว่างนั้นเสียอีก

คำถามที่พบบ่อย

โปรเจกต์ใหม่ควรเลือกรุ่นใด? ควรใช้ ChatCompletions เป็นค่าเริ่มต้นเพื่อการรองรับเครื่องมือที่กว้างขวางที่สุด เลือก Messages หากสแตกของคุณเป็นแบบ Claude-native เลือก Responses API หากคุณกำลังสร้างเอเจนต์แบบหลายขั้นตอนและต้องการสถานะที่จัดการโดยเซิร์ฟเวอร์

ฉันสามารถชี้ Claude Code ไปยัง DeepSeek V4 Pro ได้หรือไม่? ได้ กำหนด ANTHROPIC_BASE_URL ไปยัง endpoint ที่เข้ากันได้กับ Anthropic ของ DeepSeek ใช้คีย์ DeepSeek ของคุณเป็น auth token และตั้งค่าโมเดลเป็น deepseek-v4-pro นั่นคือประโยชน์ในทางปฏิบัติของการรองรับรูปแบบ Messages

การเรียกใช้เครื่องมือและเอาต์พุตแบบมีโครงสร้างใช้งานได้ในทุกรูปแบบหรือไม่? โมเดลรองรับทั้งสองอย่าง และแต่ละรูปแบบจะเปิดเผยการเรียกใช้เครื่องมือในรูปแบบเฉพาะของข้อกำหนดของตนเอง เช่น อ็อบเจกต์ฟังก์ชันที่ซ้อนกัน, เครื่องมือ input_schema หรือรายการสไตล์ Responses ตรวจสอบ schemas เฉพาะของคุณกับแต่ละรูปแบบในชุดทดสอบก่อนใช้งานจริง; กรณีขอบเขตของ schema-shape คือจุดที่การใช้งานที่เข้ากันได้อาจแตกต่างกันออกไป

ปุ่ม